Bug#826297: offer a shutdowm logging service

[積丹尼 Dan Jacobson]

Package: systemd
Version: 230-2
Severity: wishlist

In https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
one sees it is quite possible to save a /shutdown-log.txt .

Alas the method there does not work on Debian. No /shutdown-log.txt is
produced.

Please:
1. Make it work on Debian.
2. Offer it as a convenient service that one can just enable / disable.

By the way, it would be great if boot logs could also be kept in such a
fashion too.

Bug#826296: directory '/usr/share/doc/imagemagick' not empty so not removed

[積丹尼 Dan Jacobson]

Package: imagemagick
Vesrion: 8:6.9.2.10+dfsg-1

Removing imagemagick (8:6.9.2.10+dfsg-1) ...
update-alternatives: warning: alternative /usr/bin/compare-im6.q16 (part of 
link group compare) doesn't exist; 
removing from list of alternatives ...
update-alternatives: warning: alternative /usr/bin/animate-im6.q16 (part of 
link group animate) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/animate is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/convert-im6.q16 (part of 
link group convert) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/convert is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/composite-im6.q16 (part of 
link group composite) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/composite is dangling; it will 
be updated with best choice
update-alternatives: warning: alternative /usr/bin/conjure-im6.q16 (part of 
link group conjure) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/conjure is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/import-im6.q16 (part of link 
group import) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/import is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/identify-im6.q16 (part of 
link group identify) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/identify is dangling; it will 
be updated with best choice
update-alternatives: warning: alternative /usr/bin/stream-im6.q16 (part of link 
group stream) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/stream is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/display-im6.q16 (part of 
link group display) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/display is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/montage-im6.q16 (part of 
link group montage) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/montage is dangling; it will be 
updated with best choice
update-alternatives: warning: alternative /usr/bin/mogrify-im6.q16 (part of 
link group mogrify) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/mogrify is dangling; it will be 
updated with best choice
dpkg: warning: while removing imagemagick, directory 
'/usr/share/doc/imagemagick' not empty so not removed
Removing imagemagick-6.q16 (8:6.9.2.10+dfsg-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...

Bug#826157: duplicity: Cannot back up files with capital letters when using ignorecase:

[Alexander Zangerl]

On Thu, 02 Jun 2016 21:35:38 +0200, Malte Schröder writes:
>The attached patch fixes the issue for me.

thanks for the patch; i'll pass it on to duplicity's upstream and
prep a duplicity release later today.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/
"[pause. too long pause] 
SIGINT SIGINT SIGINT FUCKFUCKFUCK" -- Nix is having a near-death experience


signature.asc
Description: Digital Signature

Bug#826106: Please close

[Erik de Castro Lopo]

It seems jeknins is no longer packaged by Debian which makes this
bug invalid.

Thanks,
Erik

-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

Bug#826295: ITP: apprecommender -- A package recommender application for Debian systems

[Lucas Albuquerque Medeiros de Moura]

Package: wnpp
Severity: wishlist
Owner: Lucas Albuquerque Medeiros de Moura 

* Package name: apprecommender
  Version : 0.5.2
  Upstream Author : Tassia Camoes Araujo 
* URL : https://github.com/tassia/AppRecommender
* License : GPL
  Programming Lang: Python
  Description : A package recommender application for Debian systems

The user provides a set of applications installed in her/his system and the 
recommender suggests a set of programs that she/he might also be interested in, 
based on the profile deduced from the his previous choices and other similar
users choices. The recommendations are composed using classification and
information retrieval techniques using debtags, apt-xapian-index and Popcon
as data sources

Bug#643595: Quick review for snes9x

[Sérgio Benjamim]

Hey,

Adrian:

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

It's the libretro core of Snes9x, basically you use a frontend like 
RetroArch to get access to the core, no gtk or legacy CLI stuff. Wanna 
move the sponsoring from this package to there?


cheers,
sergio-br2



On Mon, 14 Sep 2015 16:02:52 -0300 =?UTF-8?Q?S=c3=a9rgio_Benjamim?= 
 wrote:

> Take a look again, I updated the package. Thanks.
>
> sergio-br2
>
>
> On 14/09/2015 10:53, ChangZhuo Chen wrote:
> > Hi,
> >
> > I just found some issues in the package in mentor:
> >
> > 1. The version 1.53~git20150819-1 is smaller than 1.53. You probability
> > need to use 1.53+git20150819-1 if the snapshot is taken after version
> > 1.53.
> >
> > 2. There is a lintian warning outdated-autotools-helper-file. You can
> > use dh-autoreconf to regenerate configure to fix this problem.
> >
> >
>
>
>

Bug#820644: RFS: libretro-snes9x [ITP]

[Sérgio Benjamim]

Ok, they are fixed.

Copyright stuff fixed too; libretro folder should be the same license as 
the core, since libretro.c/cpp is based in the main loop file of the 
emulators (snes9x.cpp for example).


cheers,
sergio-br2


On Thu, 2 Jun 2016 17:28:00 +0200 Gianfranco Costamagna 
 wrote:

> control: owner -1 !
> control: tags -1 moreinfo
>
> can you please fix the lintian stuff?
>
> 
http://debomatic-amd64.debian.net/distribution#unstable/libretro-snes9x/1.53+git20151206-1/lintian

>
> specially the copyright stuff.
>
> G.

Bug#826294: DDPO: remove package information not updated

[Hideki Yamane]

Package: qa.debian.org
Severity: normal

Dear Maintainer,

 As https://qa.debian.org/developer.php?login=henrich ttf-cjk-compact package
 still exists but it was already removed.

 Could you check it, please?

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

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

Bug#825129: closed by Scott Kitterman <deb...@kitterman.com> (Re: RM: ttf-cjk-compact -- replaced by fonts-droid)

[Hideki Yamane]

On Wed, 25 May 2016 16:45:11 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:
> Package already removed from unstable and testing.

 Thanks, I saw https://qa.debian.org/developer.php?login=henrich=yes
 and somehow it has not been updated.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#826115: mirror submission for debian.redimadrid.es

[Donald Norwood]

Hello,

Thank you for your support and for mirroring Debian.

You mirror needs to update once every 6 hours or 4 times per day in
order to be in sync with the archive. Otherwise the mirror looks good
for addition to the master list.

Please confirm when have made this change and we can add you to official
mirrors listing.

Best regards,

Donald Norwood
-Debian Mirrors Team



On Thu, 02 Jun 2016 11:12:33 + "REDIMadrid NOC" 
wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: debian.redimadrid.es
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
> Archive-http: /debian/
> IPv6: no
> Archive-upstream: ftp.de.debian.org
> Updates: once
> Maintainer: REDIMadrid NOC 
> Country: ES Spain
> Location: Madrid
> Sponsor: REDIMadrid http://www.redimadrid.es
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#806065: libxml2: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Salvatore Bonaccorso]

Hi Simon,

On Fri, Jun 03, 2016 at 09:05:47AM +0100, Simon McVittie wrote:
> Control: tags -1 + patch
> 
> On Tue, 24 Nov 2015 at 15:27:06 +, Santiago Vila wrote:
> > I tried to build this package with "dpkg-buildpackage -A"
> > (i.e. only architecture-independent packages), and it failed
> 
> This also affects Salvatore Bonaccorso's recent security-fix NMU.

Yes unfortunately I got aware only after the upload, but then wanted
to wait for #826128 before doing any other upload.
> 
> > * If not, debian/rules should be modified so that the binary-indep
> > target works in all cases, even when binary-arch is not used (this is
> > what the "Architecture: all" autobuilder does).
> 
> See attached patch, also available from:
> 
> ssh://git.debian.org/git/users/smcv/libxml2.git -b arch-all-only

Do you plan to do the NMU for it yourself?

Thanks for having worked on it.

Regards,
Salvatore

Bug#826293: RFS: bit-babbler/0.5~bpo8+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my trivial backport of "bit-babbler".
I have already gotten Ron Lee's blessing to maintain the backport, and
to add myself to Uploaders for the backport.  We also discussed the
Lintian I, P, and W warnings, and I fully support Ron's reasoning for
why these do not or should not be fixed.

Package name: bit-babbler
Version: 0.5~bpo8+1
Section: admin

It builds those binary packages:

bit-babbler - BitBabbler hardware TRNG and kernel entropy source support
bit-babbler-dbg - debugging symbols for BitBabbler tools

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

https://mentors.debian.net/package/bit-babbler

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bit-babbler/bit-babbler_0.5~bpo8+1.dsc

Regards,
Nicholas D Steeves

Bug#826018: installation-reports: Stretch Alpha 6 successful installation, but no touchpad during install

[Tim Heaney]

Sure! Attached is my /var/log/installer/syslog file compressed with xz.

Tim

On Fri, Jun 3, 2016 at 8:53 PM, Cyril Brulebois  wrote:

> Hi Tim,
>
> Tim Heaney  (2016-06-01):
> > Dear Maintainer,
> >
> > My install was successful and I am very happy as described here
> >
> >   https://oylenshpeegul.wordpress.com/2016/05/31/hello-stretch/
> >
> > The only issue I've had so far was tiny. During the install, the
> > touchpad was dead. I plugged in a usb mouse and proceeded. When the
> > install was complete and I booted into debian from the hard disk, the
> > touchpad worked. I didn't do anything to fix it.
> >
> > Thanks to everyone on the Debian team! The Stretch Alpha 6 installer
> > looks like a winner!
>
> Thanks for your report. Can you please attach your installer's sylog
> file (maybe compressed) in a group-reply? It can be found under the
> /var/log/installer directory.
>
> > /proc/bus/input/devices: I: Bus=0011 Vendor=0002 Product=0007
> Version=01b1
> > /proc/bus/input/devices: N: Name="SynPS/2 Synaptics TouchPad"
> > /proc/bus/input/devices: P: Phys=isa0060/serio1/input0
> > /proc/bus/input/devices: S:
> Sysfs=/devices/platform/i8042/serio1/input/input2
> > /proc/bus/input/devices: U: Uniq=
> > /proc/bus/input/devices: H: Handlers=mouse0 event3
> > /proc/bus/input/devices: B: PROP=9
> > /proc/bus/input/devices: B: EV=b
> > /proc/bus/input/devices: B: KEY=6420 3 0 0 0 0
> > /proc/bus/input/devices: B: ABS=26080001103
>
> I would expect a synaptics touchpad to get at least basic support with
> evdev, and maybe there's a bug somwhere to be fixed. But maybe I'm out
> of sync with reality. :)
>
> Also, wondering whether it would make sense to maybe have a synaptics
> udeb at some point? Or maybe libinput will save us all?
>
> Putting -x@ in cc for input (no pun intended).
>
>
> KiBi.
>


syslog.xz
Description: application/xz

Bug#825244: nslcd: Allow arbitrary maps via getent.ldap(1)

[Daniel Richard G.]

On Fri, 2016 Jun  3 14:21+0200, Arthur de Jong wrote:
>
> The tricky bit here is that autofs, while partially configured in
> /etc/nsswitch.conf does not use the C library NSS layer for these
> lookups. You can use LDAP to export automounter maps but these will
> not go through nslcd.
>
> Maybe I don't understand your use case completely.

The goal is, as you later mention, to centralize the LDAP configuration
in nslcd. I want /etc/nslcd.conf to have all the LDAP server-related
configuration (including SSL cert info in my setup), and have everything
else talk to the Unix socket.

I don't know about autofs not using proper NSS calls, but in theory
you can point it to nslcd's Unix socket as well. (I already do this
with nscd.)

For autofs, I'm using "program" maps (i.e. a script that, given a key,
returns a mount path), which are more flexible. What I want is a command
I can call in there that will do an LDAP query via nslcd---instead of,
say, a standalone invocation of ldapsearch(1) with most of the config
stuff in nslcd.conf duplicated.

> The problem here is that this also does not go through the NSS
> subsystem so will not reach nslcd.

Note that part of my request is to enable getent.ldap(1) to query these
custom maps, so the query *would* go through nslcd, even though NSS has
no concept of them. Making it possible to set up arbitrary maps [without
needing to hard-code them in] is the goal.

> Extracting these pictures and updating local copies should be pretty
> simple with a small script.

Not so simple when the company has over 10K users :]

> A long time ago I made something like that for gdm (probably no longer
> works with the most recent version), see
> https://arthurdejong.org/ldapgdmfaces/

I was thinking of something along these lines for LightDM. But it
would be something that returns just a single photo, not all the
photos in LDAP.

> At one point I did have a look into providing an autofs lookup module
> that would direct requests to nslcd but the main benefit would be to
> centralise configuration while that may not always be what you want
> (e.g. having automounter maps on a different LDAP server than user
> accounts).

This would be worthwhile. Centralizing configuration is very helpful,
especially for a fire-and-forget system facility like LDAP. If you have
mount maps on a different server, then, well, you can't centralize two
(or more) configs into one... that's less of a counterargument than it
is an orthogonal use case. And at least in my (quite large)
organization, it's still one all-powerful LDAP server, not a bunch of
LDAP fiefdoms.

> I would gladly help integrating an autofs lookup module and
> automounter map support in nslcd but for me personally the current
> software solution works without any real problems.

Well, what I'm asking for is something more general. It could be used to
implement an autofs backend, or the user-photo lookup, or any number of
other things. At present, the best I can do is call ldapsearch(1) with a
dozen or so arguments, post-process it with Perl, and return the requested
nugget of information.

> For some background see:
>   https://bugs.debian.org/638007

In theory, arbitrary maps could be used to implement support for
sudo-ldap without requiring modifications to nslcd.

> Anyway, patches for implementing automounter lookups in nslcd and
> perhaps an autofs lookup module are welcome and I will do my best to
> try to integrate them into nss-pam-ldapd.

Again, automount maps are just an example. What I'm after is a
general facility. I think quite a few folks would find that useful.

Bug#826291: apt: [INTL:ja] Japanese translation of po file update

[Takuma Yamada]

Package: apt
Version: 1.0.9.8.3
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese translation of po (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into po/ja.po.

Kind regards.
--
Takuma Yamada


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/sources.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.18-7+deb8u1
ii  libapt-pkg4.12  1.0.9.8.3
ii  libc6   2.19-18+deb8u4
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.6.11-1+b1
pn  dpkg-dev
ii  python-apt  0.9.3.12
ii  synaptic0.81.2

-- no debconf information


ja.po.gz
Description: application/gzip

Bug#826018: installation-reports: Stretch Alpha 6 successful installation, but no touchpad during install

[Cyril Brulebois]

Hi Tim,

Tim Heaney  (2016-06-01):
> Dear Maintainer,
> 
> My install was successful and I am very happy as described here
> 
>   https://oylenshpeegul.wordpress.com/2016/05/31/hello-stretch/
> 
> The only issue I've had so far was tiny. During the install, the
> touchpad was dead. I plugged in a usb mouse and proceeded. When the
> install was complete and I booted into debian from the hard disk, the
> touchpad worked. I didn't do anything to fix it.
> 
> Thanks to everyone on the Debian team! The Stretch Alpha 6 installer
> looks like a winner!

Thanks for your report. Can you please attach your installer's sylog
file (maybe compressed) in a group-reply? It can be found under the
/var/log/installer directory.

> /proc/bus/input/devices: I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
> /proc/bus/input/devices: N: Name="SynPS/2 Synaptics TouchPad"
> /proc/bus/input/devices: P: Phys=isa0060/serio1/input0
> /proc/bus/input/devices: S: Sysfs=/devices/platform/i8042/serio1/input/input2
> /proc/bus/input/devices: U: Uniq=
> /proc/bus/input/devices: H: Handlers=mouse0 event3 
> /proc/bus/input/devices: B: PROP=9
> /proc/bus/input/devices: B: EV=b
> /proc/bus/input/devices: B: KEY=6420 3 0 0 0 0
> /proc/bus/input/devices: B: ABS=26080001103

I would expect a synaptics touchpad to get at least basic support with
evdev, and maybe there's a bug somwhere to be fixed. But maybe I'm out
of sync with reality. :)

Also, wondering whether it would make sense to maybe have a synaptics
udeb at some point? Or maybe libinput will save us all?

Putting -x@ in cc for input (no pun intended).


KiBi.


signature.asc
Description: Digital signature

Bug#826146: /usr/bin/uscan: uscan errors out on watchfile that is OK in stable

[James McCoy]

On Thu, Jun 02, 2016 at 05:44:34PM +0100, Wookey wrote:
> The watch file in couchdb is like this:
> debian/watch
> version=3
> http://couchdb.apache.org/ \
> (?:.*/|.*=|)apache-couchdb[\-\._](\d\S*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)(?:/\S*)?
> 
> Testing in a fresh, clean, unstable with couchdb build-deps
> installed, in the current couchdb (1.4.0-3), we find:
> 
> $ uscan
> Undefined subroutine ::uscan_die called at /usr/bin/uscan line 1713.
> BEGIN failed--compilation aborted at /usr/bin/uscan line 1718.
> 
> I assume that's a bug? Should uscan fail in this way? Even with an
> oldish watch file?

This is a bug, yes, in the part of the code that's trying to tell you
that you don't have LWP::UserAgent installed.

I'll fix it shortly.

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


signature.asc
Description: PGP signature

Bug#738608: MY BLESSINGS TO YOU

[Malin Broman]

$2m donated to you, reply to; lilianebettnco...@outlook.com for details

Bug#759584: fixed in gearmand 1.0.6-6

[Steev Hise]

was this version ever installed?  Can't find it anywhere.

looks like it's been uploaded to Ubuntu repos but not Debian?

steev

Steev Hise
Senior Engineer, The Freecycle Network
st...@freecycle.org

On Wed, 13 Apr 2016 19:54:52 + Alexandre Mestiashvili 
 wrote:
> Source: gearmand
> Source-Version: 1.0.6-6
>
> We believe that the bug you reported is fixed in the latest version of
> gearmand, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 759...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Alexandre Mestiashvili  (supplier of updated 
> gearmand package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Thu, 07 Apr 2016 16:22:59 +0200
> Source: gearmand
> Binary: libgearman7 libgearman-dev libgearman-doc gearman-job-server 
> gearman-tools gearman
> Architecture: source amd64 all
> Version: 1.0.6-6
> Distribution: unstable
> Urgency: medium
> Maintainer: Alexandre Mestiashvili 
> Changed-By: Alexandre Mestiashvili 
> Description:
>  gearman- Distributed job queue
>  gearman-job-server - Job server for the Gearman distributed job queue
>  gearman-tools - Tools for the Gearman distributed job queue
>  libgearman-dev - Development files for the Gearman Library
>  libgearman-doc - API Documentation for the Gearman Library
>  libgearman7 - Library providing Gearman client and worker functions
> Closes: 744022 759584
> Changes:
>  gearmand (1.0.6-6) unstable; urgency=medium
>  .
>* New maintainer. Many thanks to Stig Sandbeck Mathisen for all his work.
>* Fixed systemd service, read parameters from defaults file (Closes: 
> 759584)
>* Updated d/copyright
>  - added myself to debian/* stanza
>  - add BSD-3-clause text
>* Quote $PARAMS in the init script, thanks to Michael Kröll (LP: #1067316)
>* Enabled hardening flags
>* Updated patch header for d/patches/gcc5.diff
>* Added patch to correct for typos detected by lintian
>* Drop of -dbg packages
>* Added documentation key to the service file
>* Added symbols file for libgearman7
>* Added copytruncate option to logrotate file (Closes: #744022)
> Checksums-Sha1:



-
"The objects are pretty; their stories are hideous, so you get to choose
between an alienated and ultimately meaningless world and one that makes
terrible demands on you. Most consumers prefer meaningless over
complicated, and therefore prefer that objects remain silent."
- Rebecca Solnit









signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822326: ITP: smoviecat -- scan for movies, query imdb and generate a catalog

[Herbert Fortes (hpfn)]

Issues to be solved[0]. See thread.

[0] - https://lists.debian.org/debian-legal/2016/05/msg8.html

Bug#826290: libc6-i686: Neither "$ aptitude show" or "$ apt-cache show" says libc6-i686 is a virtual package

[Kingsley G. Morse Jr.]

Package: libc6-i686
Version: 2.22-7
Severity: minor

Hey guys,

I hope you're well.


* What led up to the situation?

   While installing security patches, aptitude
   asked if it would be OK to remove libc6-i686,
   and neither

$ apt-cache show libc6-i686

or

$ aptitude show libc6-i686

reported that libc6-i686 is now a virtual
package.

Instead, they said libc6-i686 contains the
standard libraries that are used by nearly all
programs on the system.


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

With some help from awwal and Alam_Squeeze on
OFTC's #debian-next channel, I saw that
libc6-i686's web page at

https://packages.debian.org/sid/libc6-i686

says it's a virtual package.

So I removed libc6-i686.


* What was the outcome of this action?

It worked, at least for the (about) half hour
between removal and typing this bug report.


* What outcome did you expect instead?

I expected 

"$ aptitude show libc60i686"

and 

"$ apt-cache show libc6-i686" 

to report that libc6-i686 is a virtual
package, and not that it contains the standard
libraries that are used by nearly all programs
on the system.

Thanks,
Kingsley

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

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

Versions of packages libc6-i686 depends on:
ii  libc6  2.22-10

libc6-i686 recommends no packages.

libc6-i686 suggests no packages.

Bug#825182: Please which tasks should be installed at a default installation of the blend

[Markus Koschany]

On Tue, 24 May 2016 13:50:19 +0200 Ole Streicher  wrote:
> Package: src:debian-games
> Severity: wishlist
> X-Debbugs-Cc: debian-devel-ga...@lists.debian.org
> 
> Dear Debian Games maintainers,
> 
> in the alpha-6 release of the Debian installer, a preliminary way was
> introduced to install a default package selection for each Debian Pure
> Blend:
> 
> https://lists.debian.org/debian-devel-announce/2016/05/msg4.html
> 
> To get this alive, it is needed to define which tasks shall be included
> into the package selection. The easiest way here is to put a keyword
> 
> Install: true
> 
> into the headers of all tasks which should be installed by default if
> the Debian Games blend is selected. 
[...]

Hello Ole,

thank you for working on this. I believe making games-finest available
would be the best option. I have added Install: true to tasks/finest and
I intend to upload a new revision of debian-games soon.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#826288: info-beamer: please use glfw3

[James Cowgill]

Source: info-beamer
Version: 1.0~pre3-1.1
Severity: wishlist
Tags: fixed-upstream
Forwarded: https://github.com/dividuum/info-beamer/issues/16

Hi,

Please build-depend on glfw3 (libglfw3-dev) instead of libglfw-dev. The
old version of glfw is no longer maintained upstream and I would like
to remove it at some point.

info-beamer appears to have already been ported to glfw3 upstream.

Thanks,
James

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

Bug#826289: build a python3-lldb-3.8 package

[Matthias Klose]

Package: python-lldb-3.8
Version: 1:3.8-2

Please build a python3-lldb-3.8 package, instead of a python-lldb-3.8 package (I
assume you don't want to build both).

Bug#826287: cegui-mk2: please use glfw3

[James Cowgill]

Source: cegui-mk2
Version: 0.8.7-1
Severity: wishlist

Hi,

Please build-depend on glfw3 (libglfw3-dev) instead of libglfw-dev. The
old version of glfw is no longer maintained upstream and I would like
to remove it at some point.

cegui-mk2 appears to already have support for glfw3 so changing the
build-dependency should be all that's needed.

Thanks,
James

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

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

[Martin Pitt]

Hello Michael,

Michael Biebl [2016-06-03 13:22 +0200]:
> As you can see, the start request is not redirected to systemctl, so the
> systemd integration is broken.
> 
> I suspect this happens because init-functions is sourced before $1 is
> shifted, so the systemd lsb init hook get's the wrong parameters.

Correct:

+ set /etc/init.d/apache-htcacheclean start
[...]
+ prog=apache-htcacheclean
+ service=apache-htcacheclean.service

Thus $0 is okay (from the "set" in init-t-script)

+ systemctl -p CanReload show apache-htcacheclean.service
+ [ CanReload=no = CanReload=no ]
+ [ /etc/init.d/apache-htcacheclean = reload ]

This corresponds to [ "${1:-}" = "reload" ], thus this check is
broken. Apparenlty the "set" (first traced line) doesn't assign
"$start" to $1, but to $2, and the script name to $1 as well.

This then finally fails when init-functions.d/40-systemd tries to act
on the action $1:

+ [ x/etc/init.d/apache-htcacheclean = xstart -o 
x/etc/init.d/apache-htcacheclean = xstop -o x/etc/init.d/apache-htcacheclean = 
xrestart -o x/etc/init.d/apache-htcacheclean = xreload -o 
x/etc/init.d/apache-htcacheclean = xforce-reload -o 
x/etc/init.d/apache-htcacheclean = xstatus ]

I tried to add something like

  if [ "$0" = "$1" ]; then shift; fi

above the sourcing of /lib/lsb/init-functions and adjust the
scriptname= assignment; that works when calling it as an init script
then, but the systemd redirection is then broken. Also, this wouldn't
do anything to fix #826215, so changing only init-d-script by itself
wouldn't be a complete solution anyway.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#826286: O: libnih -- NIH Utility Library

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: normal

The former maintainer is apparently not active anymore.  The last upload was
already a QA upload, effectively orphaning the package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

--
Manuel

Bug#821377: gitlab: update fails

[Hanspeter Kunz]

On Don, 2016-06-02 at 21:51 +0530, Pirate Praveen wrote:
> On Mon, 18 Apr 2016 10:10:04 +0200 Xavier Bestel  fr>
> wrote:
> > rake aborted!
> > TypeError: no implicit conversion of Pathname into String
> > /usr/share/gitlab/lib/tasks/migrate/add_limits_mysql.rake:1:in
> > ` > (required)>'
> 
> are you using mysql?

I see exactly the same error as Xavier, and yes, I am using mysql.

Best,
Hp

> We have tested so far only with postgresql.
> 
> > /usr/share/gitlab/Rakefile:10:in `'
> > (See full trace by running task with --trace)
> > 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)
> 
-- 
Hanspeter Kunz  University of Zurich
Systems Administrator   Department of Informatics
Email: hk...@ifi.uzh.ch Binzmühlestrasse 14
Tel: +41.(0)44.63-56714 Office 2.E.07
http://www.ifi.uzh.ch   CH-8050 Zurich, Switzerland

Spamtraps: hkunz.bo...@ailab.ch hkunz.bo...@ifi.uzh.ch
---
Would ye both eat your cake and have your cake?
-- John Heywood

Bug#826285: O: libiec61883 -- partial implementation of IEC 61883

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: normal

The former maintainer is apparently not active anymore.  The last upload was
already a QA upload, effectively orphaning the package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

--
Manuel

Bug#826284: O: apngopt -- optimize APNG animated images

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: normal

The former maintainer is apparently not active anymore.  The last upload was
already a QA upload, effectively orphaning the package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

--
Manuel

Bug#826283: O: apngdis -- deconstruct APNG file into a sequence of PNG frames

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: normal

The former maintainer is apparently not active anymore.  The last upload was
already a QA upload, effectively orphaning the package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

--
Manuel

Bug#826282: O: apngasm -- assemble APNG animation from PNG/TGA image sequence

[Manuel A. Fernandez Montecelo]

Package: wnpp
Severity: normal

The former maintainer is apparently not active anymore.  The last upload was
already a QA upload, effectively orphaning the package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

--
Manuel

Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

[Thorsten Glaser]

Aurelien Jarno dixit:

>EastAsian.txt explicitly lists the hexagrams as neutral width, so I don't

Yes it does, but neutral does NOT always mean 1. I even looked
it up today, as I was not familiar enough with neutral yet.

>Looking at the behaviour from other systems, freebsd and netbsd both
>return -1 here, while openbsd returns 1. None of them returns 2.

-1 is utterly wrong, it’s returned for a control character… likely
missing locale support. The last time I looked at OpenBSD, they did
not have any support for anything resembling UTF-8 either, but from
what I’ve heard, they’re working on changing it.

>Therefore, can you please give a pointer explaining while the width
>should be 2 instead of 1?

I can give two pointers.

One being the presence of 4DC0 (et al.) in src:unifont (= 1:8.0.01-1)
in font/plane00/unifont-base.hex as a fullwidth (“wide”, in Unicode
speak; as I learnt today, UAX #11 “fullwidth” is a subset of “wide”
that only applies when it has a “ decomposition”) character,
i.e. one with 64 nybbles, like 3000, and unlike 0041.

Two being src:xterm (= 324-2) wcwidth.c, the function mk_wcwidth has
codepoints 2E80‥0xA4CF, excluding 303F, as wide.

The xterm argument is actually extremely strong – it’s t̲h̲e̲ single
most widespeadly used wcwidth() implementation, copied into lots
of code that doesn’t (or can’t) rely on the system’s implementation.

Similarily, GNU libutf8 uses (relevant part of the if construct):
|| (c >= 0x2e80 && c < 0xa4d0  /* CJK ... Yi */
&& !((c & ~0x0011) == 0x300a || c == 0x303f))

This is almost the same as xterm, with the additional exception of
300A, 300B, 301A, 301B added (which I contest, they are W(ide) in
a random EastAsianWidth file I’ve got lying around, but that’s a
different topic and correct in glibc already anyway).

AFAICT glibc currently has Unicode 7.0.0 data in use. When I run
my script on UCD+EAW 7.0.0, I get the following output. The format
is: bsearch form, i.e. a list of (low, high) tuples; the code first
checks for NUL, DEL, C0 and C1 control characters, then bsearches
mb_ucs_combining, then mb_ucs_fullwidth, and if it’s still not found,
the width is 1 (UAX #11 “ambiguous” is assumed narrow):

static const struct mb_ucsrange mb_ucs_combining[] = {
{ 0x0300, 0x036F },
{ 0x0483, 0x0489 },
{ 0x0591, 0x05BD },
{ 0x05BF, 0x05BF },
{ 0x05C1, 0x05C2 },
{ 0x05C4, 0x05C5 },
{ 0x05C7, 0x05C7 },
{ 0x0600, 0x0605 },
{ 0x0610, 0x061A },
{ 0x061C, 0x061C },
{ 0x064B, 0x065F },
{ 0x0670, 0x0670 },
{ 0x06D6, 0x06DD },
{ 0x06DF, 0x06E4 },
{ 0x06E7, 0x06E8 },
{ 0x06EA, 0x06ED },
{ 0x070F, 0x070F },
{ 0x0711, 0x0711 },
{ 0x0730, 0x074A },
{ 0x07A6, 0x07B0 },
{ 0x07EB, 0x07F3 },
{ 0x0816, 0x0819 },
{ 0x081B, 0x0823 },
{ 0x0825, 0x0827 },
{ 0x0829, 0x082D },
{ 0x0859, 0x085B },
{ 0x08E4, 0x0902 },
{ 0x093A, 0x093A },
{ 0x093C, 0x093C },
{ 0x0941, 0x0948 },
{ 0x094D, 0x094D },
{ 0x0951, 0x0957 },
{ 0x0962, 0x0963 },
{ 0x0981, 0x0981 },
{ 0x09BC, 0x09BC },
{ 0x09C1, 0x09C4 },
{ 0x09CD, 0x09CD },
{ 0x09E2, 0x09E3 },
{ 0x0A01, 0x0A02 },
{ 0x0A3C, 0x0A3C },
{ 0x0A41, 0x0A42 },
{ 0x0A47, 0x0A48 },
{ 0x0A4B, 0x0A4D },
{ 0x0A51, 0x0A51 },
{ 0x0A70, 0x0A71 },
{ 0x0A75, 0x0A75 },
{ 0x0A81, 0x0A82 },
{ 0x0ABC, 0x0ABC },
{ 0x0AC1, 0x0AC5 },
{ 0x0AC7, 0x0AC8 },
{ 0x0ACD, 0x0ACD },
{ 0x0AE2, 0x0AE3 },
{ 0x0B01, 0x0B01 },
{ 0x0B3C, 0x0B3C },
{ 0x0B3F, 0x0B3F },
{ 0x0B41, 0x0B44 },
{ 0x0B4D, 0x0B4D },
{ 0x0B56, 0x0B56 },
{ 0x0B62, 0x0B63 },
{ 0x0B82, 0x0B82 },
{ 0x0BC0, 0x0BC0 },
{ 0x0BCD, 0x0BCD },
{ 0x0C00, 0x0C00 },
{ 0x0C3E, 0x0C40 },
{ 0x0C46, 0x0C48 },
{ 0x0C4A, 0x0C4D },
{ 0x0C55, 0x0C56 },
{ 0x0C62, 0x0C63 },
{ 0x0C81, 0x0C81 },
{ 0x0CBC, 0x0CBC },
{ 0x0CBF, 0x0CBF },
{ 0x0CC6, 0x0CC6 },
{ 0x0CCC, 0x0CCD },
{ 0x0CE2, 0x0CE3 },
{ 0x0D01, 0x0D01 },
{ 0x0D41, 0x0D44 },
{ 0x0D4D, 0x0D4D },
{ 0x0D62, 0x0D63 },
{ 0x0DCA, 0x0DCA },
{ 0x0DD2, 0x0DD4 },
{ 0x0DD6, 0x0DD6 },
{ 0x0E31, 0x0E31 },
{ 0x0E34, 0x0E3A },
{ 0x0E47, 0x0E4E },
{ 0x0EB1, 0x0EB1 },
{ 0x0EB4, 0x0EB9 },
{ 0x0EBB, 0x0EBC },
{ 0x0EC8, 0x0ECD },
{ 0x0F18, 0x0F19 },
{ 0x0F35, 0x0F35 },
{ 0x0F37, 0x0F37 },
{ 0x0F39, 0x0F39 },
{ 0x0F71, 0x0F7E },
{ 0x0F80, 0x0F84 },
{ 0x0F86, 0x0F87 },
{ 0x0F8D, 0x0F97 },
{ 0x0F99, 0x0FBC },
{ 

Bug#825937: sysvinit-utils: Please drop startpar dependency

[Martin Pitt]

Control: tag -1 patch

Martin Pitt [2016-06-03 12:09 +0200]:
> > Could you please drop the dependency which AFAICS was only necessary for
> > smooth upgrades from Wheezy to Jessie?  It seems sufficient that sysv-rc
> > depends on startpar.

> So IMHO we should move the dependendy to either sysvinit-core or
> initscripts, both of which can be (now or soon) uninstalled on a
> system with systemd-sysv. I think moving it to sysvinit-core is
> conceptually "more correct".

This wasn't correct after all -- sysv-rc can be replaced with openrc
or file-rc, in neither case startpar is needed. So leaving it at
sysv-rc and dropping it from sysvinit-utils is correct indeed.

Trivial patch attached.

Note that I'd like to NMU this together with bug #826205. While this
is just cleanup, #826205 is to avoid breakage once procps gets
uploaded and initscripts' priority gets dropped so that it drops from
the default install.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>From f959bee0fd68d57b1881f32d5362a2c1f8890bed Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Sat, 4 Jun 2016 00:21:32 +0200
Subject: [PATCH 2/2] Drop startpar dependency from sysvinit-utils

It's only being used by sysv-rc and remains a dependency of that.

Closes: #825937
---
 debian/changelog | 2 ++
 debian/control   | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 7478e60..551189c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,8 @@ sysvinit (2.88dsf-60) UNRELEASED; urgency=medium
 specific to initscripts, but API for other init scripts similar to
 /lib/init/init-d-script. This will allow initscripts to drop from the
 default installation. (Closes: #826205)
+  * Drop startpar dependency from sysvinit-utils. It's only being used by
+sysv-rc and remains a dependency of that. (Closes: #825937)
 
  -- Andreas Henriksson   Wed, 25 May 2016 15:58:32 +0200
 
diff --git a/debian/control b/debian/control
index 4002416..2f6d379 100644
--- a/debian/control
+++ b/debian/control
@@ -58,7 +58,6 @@ Architecture: any
 Conflicts: last, sysvconfig, chkconfig (<< 11.0-79.1-2), startpar (<< 0.58-2)
 Replaces: last, sysvinit (<= 2.86.ds1-65), initscripts (<< 2.88dsf-59.5)
 Depends: ${shlibs:Depends}, ${misc:Depends}, init-system-helpers (>= 1.25~)
- , startpar
 # sulogin, last, lastb and mesg was moved to the util-linux package
  , util-linux (>> 2.28-2~)
 Breaks: upstart (<< 1.5-0ubuntu5), systemd (<< 215), initscripts (<< 2.88dsf-59.5)
-- 
2.8.1

Bug#826205: Please move /lib/init/{vars.sh, init-d-script} to sysv-rc

[Martin Pitt]

Control: retitle -1 Please move /lib/init/vars.sh to sysvinit-utils
Control: tag -1 patch

Hello again,

Martin Pitt [2016-06-03 13:01 +0200]:
> So the part from this proposal/my current patch that remains valid is
> to move vars.sh out of initscripts. We are one procps upload away from
> dropping initscripts out of the default install, and initscripts is by
> far the biggest package. AFAICS we could move this to sysvinit-utils
> for now without breaking any of openrc/file-rc/sysvinit-core/systemd.

Attached git formatted patch does that.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>From 0dac2bb4a4f412bf011dfdc0809dace04ad3d399 Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Sat, 4 Jun 2016 00:18:48 +0200
Subject: [PATCH 1/2] Move /lib/init/vars.sh from initscripts to sysvinit-utils

It's not specific to initscripts, but API for other init scripts similar to
/lib/init/init-d-script.

This will allow initscripts to drop from the default installation.

Closes: #826205
---
 debian/changelog  | 7 +++
 debian/control| 4 ++--
 debian/sysvinit-utils.install | 1 +
 debian/{src/initscripts/lib/init => }/vars.sh | 0
 4 files changed, 10 insertions(+), 2 deletions(-)
 rename debian/{src/initscripts/lib/init => }/vars.sh (100%)

diff --git a/debian/changelog b/debian/changelog
index 13e602c..7478e60 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,14 @@
 sysvinit (2.88dsf-60) UNRELEASED; urgency=medium
 
+  [ Andreas Henriksson ]
   * bootlogd: mention it won't do anything under systemd (Closes: #791907)
 
+  [ Martin Pitt ]
+  * Move /lib/init/vars.sh from initscripts to sysvinit-utils. It's not
+specific to initscripts, but API for other init scripts similar to
+/lib/init/init-d-script. This will allow initscripts to drop from the
+default installation. (Closes: #826205)
+
  -- Andreas Henriksson   Wed, 25 May 2016 15:58:32 +0200
 
 sysvinit (2.88dsf-59.4) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 7add446..4002416 100644
--- a/debian/control
+++ b/debian/control
@@ -56,12 +56,12 @@ Package: sysvinit-utils
 Essential: yes
 Architecture: any
 Conflicts: last, sysvconfig, chkconfig (<< 11.0-79.1-2), startpar (<< 0.58-2)
-Replaces: last, sysvinit (<= 2.86.ds1-65)
+Replaces: last, sysvinit (<= 2.86.ds1-65), initscripts (<< 2.88dsf-59.5)
 Depends: ${shlibs:Depends}, ${misc:Depends}, init-system-helpers (>= 1.25~)
  , startpar
 # sulogin, last, lastb and mesg was moved to the util-linux package
  , util-linux (>> 2.28-2~)
-Breaks: upstart (<< 1.5-0ubuntu5), systemd (<< 215)
+Breaks: upstart (<< 1.5-0ubuntu5), systemd (<< 215), initscripts (<< 2.88dsf-59.5)
 Suggests: bootlogd, sash
 Description: System-V-like utilities
  This package contains the important System-V-like utilities.
diff --git a/debian/sysvinit-utils.install b/debian/sysvinit-utils.install
index ed531fa..0b65091 100644
--- a/debian/sysvinit-utils.install
+++ b/debian/sysvinit-utils.install
@@ -4,3 +4,4 @@ usr/share/man/man8/fstab-decode.8
 usr/share/man/man8/killall5.8
 usr/share/man/man8/pidof.8
 debian/init-d-script lib/init
+debian/vars.sh lib/init
diff --git a/debian/src/initscripts/lib/init/vars.sh b/debian/vars.sh
similarity index 100%
rename from debian/src/initscripts/lib/init/vars.sh
rename to debian/vars.sh
-- 
2.8.1

Bug#826273: [pkg-gnupg-maint] Bug#826273: gnupg2: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Daniel Kahn Gillmor dijo [Fri, Jun 03, 2016 at 05:06:43PM -0400]:
> So i'd actually be happier with "keyid-format none" or "keyid format
> fingerprint" [1] than with "keyid-format long" but i agree that "long"
> or "0xlong" is still superior to the current situation.

Umh... There's something wrong in this suggestion:

$ gpg2 --keyid-format none --list-keys gwolf.org
gpg: unknown keyid-format 'none'
$ gpg2 --keyid-format fingerprint --list-keys gwolf.org
gpg: unknown keyid-format 'fingerprint'

I get the same results with gpg instead of gpg2, FWIW. The man page
mentions:

   --keyid-format short|0xshort|long|0xlong
 Select how to display key IDs. "short" is the
 traditional 8-character key ID. "long" is the
 more accurate (but less convenient) 16-character
 key ID. Add an "0x" to either to include an "0x"
 at the beginning of the key ID, as in 0x99242560.
 Note that this option is ignored if the option
 --with-colons is used.
 

Bug#821354: Bug#821352: Acknowledgement (Edge-scrolling and tap-to-click no longer working)

[Michael Biebl]

Am 04.06.2016 um 00:07 schrieb Anthony Callegaro:
> Hey Michael,
> 
> Just want to add to this bug report.
> 
> Tap to click does not work for me either since the upgrade to 3.20.

Atm, this doesn't work if you have xserver-xorg-input-synaptics
installed, since that driver has a higher priority then libinput.

Uninstall xserver-xorg-input-synaptics and you should be able again to
configure tap-to-click via gnome-control-center.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#826215: [Pkg-sysvinit-devel] Bug#826215: SysV init scripts using init-d-script have a hard dependency on sysvinit-utils

[Michael Biebl]

Am 03.06.2016 um 23:54 schrieb Petter Reinholdtsen:
> [Michael Biebl]

> What about moving the init-d-script file to the same package containing
> /lib/init/vars.sh, which is needed by most init.d scripts and should be
> available on all Debian installations? 

/lib/init/vars.sh is currently shipped by initscripts and we were
actually discussing that moving that to sysvinit-utils because moving it
to sysv-rc doesn't really work (see pitti's bug report in that regard).

This doesn't solve the problem though, that such SysV init scripts have
a hard dependency on a sysvinit provided package, even if they ship a
native service file and we'd have to keep that package installed forever
in the future.
The redirection of /etc/init.d/foo  to systemctl  foo
would fail otherwise.
We could accept that breakage, but maybe we can do better. Moving the
inclusion of /lib/lsb/init-functions before /lib/init/init-functions-d
was an idea in that regard.
Do you have any concerns regarding that change?

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#820975: flashplugin-nonfree: Update to 11.2.202.616 silently does nothing (ERROR 404: Not Found)

[Leo L. Schwab]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
Followup-For: Bug #820975

Dear Maintainer,

Some problem here, only I'm trying to update from .616 to .621.  The
script is attempting to fetch a PGP signature from
https://people.debian.org/~bartm/... to validate the download from Adobe.
However, the signature for .621 doesn't appear to exist yet:


bash$ sudo update-flashplugin-nonfree --install --verbose
[sudo] password for ewhac: 
options :  --install --verbose --
temporary directory: /tmp/flashplugin-nonfree.tigCH0EoJp
importing public key ...
selected action = --install
installed version = 11.2.202.616
upstream version = 11.2.202.621
wgetoptions= -nd -P .   -v --progress=dot:default 
downloading 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.amd64.pgp.asc
 ...
URL transformed to HTTPS due to an HSTS policy
--2016-06-03 15:01:46--  
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.amd64.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30, 
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... 
connected.
HTTP request sent, awaiting response... 404 Not Found
2016-06-03 15:01:47 ERROR 404: Not Found.

wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.amd64.pgp.asc
[ ... ]


Perhaps someone should poke ~bartm?  .616 has been on Firefox's
shitlist for nearly a week now.

Schwab


-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.6.1+b1
Adobe Flash Player version: LNX 11,2,202,616
MD5 checksums:
160a01dd00527304e5291e65eb0c65e2  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
18271ef4389464f5236e415a8f140872  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
cb4968ab3f52b73a05590ecd87a83bd5  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Jun  2 15:00 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

Kernel: Linux 4.5.0-2-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 flashplugin-nonfree depends on:
ii  binutils   2.26-9
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  1.4.20-6
ii  libatk1.0-02.20.0-1
ii  libcairo2  1.14.6-1+b1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.4
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.1.1-4
ii  libglib2.0-0   2.48.1-1
ii  libgtk2.0-02.24.30-2
ii  libnspr4   2:4.12-2
ii  libnss32:3.23-2
ii  libpango1.0-0  1.40.1-1
ii  libstdc++6 6.1.1-4
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-2

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  fonts-dejavu   2.35-1
pn  hal
pn  iceweasel  
pn  konqueror-nsplugins
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#821354: Bug#821352: Acknowledgement (Edge-scrolling and tap-to-click no longer working)

[Anthony Callegaro]

Hey Michael,

Just want to add to this bug report.

Tap to click does not work for me either since the upgrade to 3.20.

On Mon, 18 Apr 2016 02:47:38 +0200 Michael Biebl  wrote:
> Am 18.04.2016 um 02:40 schrieb Michael Biebl:
> > Apparently tap-to-click requires that xserver-xorg-input-libinput is
> > installed, so I guess we need to make some package
> > (gnome-settings-daemon?) pull that package in.

It was already installed :

apt search xserver-xorg-input-libinput

xserver-xorg-input-libinput/unstable,testing,now 0.19.0-1 amd64 [installed]

  X.Org X server -- libinput input driver


> > Still, the option to configure tap-to-click has been removed from
> > gnome-control-center. I think this is a regression and we should report
> > that upstream.
>
> I need to correct that. Tap-to-click can still be configured, it just
> needs xserver-xorg-input-libinput

Check attached screenshot but even with xserver-xorg-input-libinput
installed the option is missing from the settings dialog.


Worse I checked in gsettings and the option was still set :

org.gnome.desktop.peripherals.touchpad tap-to-click true

So far the only workaround is to run synclient manually :

synclient TapButton1=1 TapButton2=3 TapButton3=2

The touchpad hardware model is a :

egrep -i 'synap|alps|etps' /proc/bus/input/devices
N: Name="ETPS/2 Elantech Touchpad"


Hope this help.

Let me know what other information I can give you to help debugging this.
Cheers
LeTic

Bug#826104: ieee-data: standards-oui.ieee.org is unavailable on the 1st of the month

[Luciano Bello]

On Thursday 02 June 2016 11.34.52 Geert Lorang wrote:
> So it looks like standards.ieee.org is being DoS'd every 1st of the month, 
not
> unlikely  if all Debian systems connect on the same day at the same time to
> standards.ieee.org ?

Thanks for the heads-up on this. Probably I will disable the cron update. It's 
a bit pointless to update regularly these file anyway.

thanks, luciano

Bug#826215: [Pkg-sysvinit-devel] Bug#826215: SysV init scripts using init-d-script have a hard dependency on sysvinit-utils

[Petter Reinholdtsen]

[Michael Biebl]
> Petter, do you have any preference regarding those two proposals or do
> you have another suggestion how we could address this?

I wrote
http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
 >
to explain the background for the init-d-script setup.

The goal is to avoid code in the individual init.d scripts that is not
_required_ to get them working, to make it possible to fix bugs in many
scripts by modifying one file.  Moving code from init-d-script to the
individual init.d scripts thus seem like a step backwards.

What about moving the init-d-script file to the same package containing
/lib/init/vars.sh, which is needed by most init.d scripts and should be
available on all Debian installations?  It seem like a better idea to
me.  The init-d-script approach is used by several packages in Debian
already.

--
Happy hacking
Petter Reinholdtsen

Bug#826281: Term "language" in package description is ambiguous

[Chris Waters]

Source: libexttextcat
Version: 3.4.4-1
Severity: minor

Package descriptions for the various libexttextcat packages say: "It
was primarily developed for language guessing". It's unclear whether
this refers to computer languages (C vs. Python) or natural languages
(English vs. Estonian). Given that it's a software library, it could
easily be either one.

Mentioning Cavnar & Trenkle, "N-Gram-Based Text Categorization" is
*suggestive*, but users who aren't familiar with that work shouldn't
have to guess what it implies.

If it can recognize natural languages, it would be really nice if the
description said so. In addition to being more clear, it would
probably help package searches if the string "natural language"
appeared in the package description.

For bonus points, the common abbreviation "NLP" (for "natural language
processing") could appear as well, which would probably aid
computational linguists, if no one else. But that's much less
important.

Bug#826256: locales: wrong width for hexagrams (and possibly others) in 2.22

[Aurelien Jarno]

control: tag -1 + moreinfo

On 2016-06-03 19:29, Thorsten Glaser wrote:
> Package: locales
> Version: 2.22-0experimental0
> Severity: normal
> Tags: upstream
> 
> Starting with locales 2.22-0experimental0, some chars have the wrong
> width; downgrading locales to 2.21-9 fixes the bugs.
> 
> Test program:
> 
> tglase@tglase:~ $ cat x.c
> #define _XOPEN_SOURCE
> #include 
> #include 
> #include 
> 
> #define D(x) printf("%04X %d\n",(x),wcwidth(x))
> 
> int
> main(void)
> {
>   setlocale(LC_ALL, "");
> 
>   D(0x41);
>   D(0x0300);
>   D(0x3000);
>   D(0x4DC0);
>   D(0xFFFD);
>   return (0);
> }
> tglase@tglase:~ $ gcc x.c
> tglase@tglase:~ $ rm -rf tloc; mkdir tloc 
>  
> tglase@tglase:~ $ localedef -i en_US -c -f UTF-8 tloc/en_US.UTF-8 
>  
> tglase@tglase:~ $ LOCPATH=$PWD/tloc LC_ALL=en_US.UTF-8 ./a.out
>  
> 0041 1
> 0300 0
> 3000 2
> 4DC0 1
> FFFD 1
> 
> Output while locales_2.21-9_all.deb was installed during localedef:
> 
> tglase@tglase:~ $ LOCPATH=$PWD/tlocx LC_ALL=en_US.UTF-8 ./a.out   
>  
> 0041 1
> 0300 0
> 3000 2
> 4DC0 2
> FFFD 1
> 
> This is because /usr/share/i18n/charmaps/UTF-8.gz now lacks
> entries for 4DC0‥4FFF.
> 
> According to my own code implementing Unicode in another operating
> system, with focus on wcwidth(3), after parsing EastAsianWidth.txt
> special handling is needed to set widths of 0xFF00, 0x3248‥0x324F,
> and 0x4DC0‥0x4DFF to “wide”, as they’re “neutral” normally – which

EastAsian.txt explicitly lists the hexagrams as neutral width, so I don't
think there is a bug there. Version from unicode 3.0 and earlier didn't
specify those characters, and the behaviour from glibc 2.21 is probably
coming from there and is probably wrong.

Looking at the behaviour from other systems, freebsd and netbsd both
return -1 here, while openbsd returns 1. None of them returns 2.

Therefore, can you please give a pointer explaining while the width
should be 2 instead of 1?

Aurelien

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

Bug#806208: src:gegl: FTBFS on sparc64, tools/introspect segfaults

[John Paul Adrian Glaubitz]

On 06/03/2016 10:25 PM, John Paul Adrian Glaubitz wrote:
> Ok, there is unfortunately more of these broken pointer arithmetics throughout
> babl. That will take some time to get all of these fixed. *sigh*

Ok, after applying the suggested changes above, the following bus errors which 
occur
when building babl [1] will actually go away:

Making all in graphics
/bin/bash: line 1: 11007 Bus error   
../tests/babl_fish_path_fitness > BablFishPath.txt
UTF8: BablFishPath.txt Fail
HTML: index.html. [OK]
/bin/bash: line 1: 11445 Bus error   ../tests/babl_fish_path_dhtml 
> BablFishPath.html
HTML: BablFishPath.html Fail

So, maybe we're lucky and just the above patch will be enough :).

Will build gegl now to verify this.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#825290: aptitude: (h)old packages should need to be specifically "unhold" to accept further actions on them

[Manuel A. Fernandez Montecelo]

Control: forcemerge 452589 -1


Hi,

2016-05-25 16:14 Christoph Anton Mitterer:

Package: aptitude
Version: 0.8.1-1
Severity: wishlist
Tags: upstream


Hi.

Currently, when I mark a package as hold (= key in the UI) it will get the
hold status, which is however automatically overridden, when I e.g. do a
"+" for upgrade on the package or the whole collapsed tree element.

I think this makes the behaviour quite unfortunate as it easily happens
that the "hold" flag is automatically overridden, e.g. just by saying
"upgrade all".

It would be nice, if a hold package needs to be specifically "unhold" first
before other actions like upgrade/remove/purge/etc. would be accepted on
it.


This part is basically a duplicate of #452589.



To make thinks easier to work with:
- there could be UI and/or command line options that allow to
 - simply ignore this one time
 or
 - clear
 any hold flags on packages.


It's possible / easy to hide packages "on hold" with patterns, to change
the main view either temporarily or permanently (if used very often, or
if desired as the default).

Same for showing only the hold ones or "unholding" them.



- The action overview could feature a special section which features all
 packages (either marked as hold or not), which are kept in the current
 state *because of* the hold flag on some packages.
 E.g. *other* (non-hold) packages which are not not auto-upgraded or not
 auto-removed or hold packages that are not upgraded/removed/etc. (even
 though the user tried to perform the action on them) because of the flag.


Overview already has something similar:

 --\ Packages being held back (3)
 ...
 --\ Packages being automatically held in their current state (4)


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#826208: util-linux: ionice: clarify documentation of -n,--classdata option

[Daniel Shahaf]

Control: forwarded -1 util-li...@vger.kernel.org

Daniel Shahaf wrote on Fri, Jun 03, 2016 at 21:04:30 +:
> Andreas Henriksson wrote on Fri, Jun 03, 2016 at 14:30:06 +0200:
> > Could you please submit this patch upstream (either as a github
> > pull request or via vger.kernel.org mailing list) please?

I've submitted the patch upstream in
Message-ID: <1464989269-6761-1-git-send-email-danie...@apache.org>

Cheers,

Daniel

Bug#825932: freeorion: Segfault on entry of dead_macron

[Markus Koschany]

On Tue, 31 May 2016 10:16:26 -0400 Thanasis Kinias
 wrote:
> Package: freeorion
> Version: 0.4.5+git20160501-1
> Severity: normal
> Tags: l10n
> 
> Dear Maintainer,
> 
> I’m seeing an odd crash resulting from typing a dead_macron (i.e.,
> typing a macron deadkey).
> 
> What I’m doing:  Try to rename a fleet after the star system ‘Fehū’.
> 
> What happens:  As soon as I hit the macron deadkey, attempting to type
> the ‘ū’, FreeOrion segfaults.  The following appears on the console:
> 
> > terminate called after throwing an instance of 'utf8::invalid_utf8'
> >   what():  Invalid UTF-8
> > Aborted

Hi,

Thank you for the report. This looks like a bug in FreeOrion but I need
at least your freeorion.log and freeoriond.log which are located in your
~/.freeorion directory before I can forward this issue upstream.

At the moment I can't reproduce the bug because I don't know how to type
such a character. How can I enter this character on a standard keyboard
without special keys?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#680782:

[Unit 193]

I've been using this patch for a while and I don't recall seeing any issues 
with it.

Bug#680782: [PATCH 1/8] Allow re-installing same version packages.

[Unit 193]

---
 mini-dinstall | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mini-dinstall b/mini-dinstall
index 6e0ea84..db6938f 100755
--- a/mini-dinstall
+++ b/mini-dinstall
@@ -1127,7 +1127,7 @@ class ArchiveDirIndexer(threading.Thread):
 if nodb_mode:
 cmdline = ['apt-ftparchive', type, dir]
 else:
-cmdline = ['apt-ftparchive', type, dir, '--db', '%s.db' %dir]
+cmdline = ['apt-ftparchive', type, dir, '-o', 
'APT::FTPArchive::AlwaysStat=true', '--db', '%s.db' %dir]
 
 self._logger.debug("Running: " + string.join(cmdline, ' '))
 if no_act:
-- 
2.7.4

Bug#816652: RFS: compiz/1:0.9.12.2 [ITP:722451]

[Gianfranco Costamagna]

control: tags -1 moreinfo

Setting moreinfo tags, until the first review is fixed.

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#816683: RFS: cloudabi-utils/0.8-1 [ITP]

[Gianfranco Costamagna]

control: tags -1 moreinfo

Setting moreinfo until the blocking bug is resolved.

G.



signature.asc
Description: OpenPGP digital signature

Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover

[Gianfranco Costamagna]

control: tags -1 moreinfo

Hi,
On Wed, 9 Mar 2016 20:48:46 -0800 Afif Elghraoui  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi, Marko,
> 
> On الأحد  6 آذار 2016 14:53, Marko Dimjašević wrote:
> > 
> > On Fri, 2016-02-26 at 17:42 -0800, Afif Elghraoui wrote:
> >> Something like the following:
> >> 
> [...]
> > Thank you Afif for this!
> > 
> 
> No problem.
> 
> > I am not sure what is the cause (maybe incorrect paths in
> > debian/rules), but when I try to build with gbp like this:
> > 
> [...]
> > 
> > Any clue what went wrong?
> > 
> > I looked at the tests/query-files/lit.cfg config file/script in 
> > question, but I don't see why it would fail.
> > 
> > 
> 
> The second tarball gets extracted to outputcheck/ (directory name is
> based on the name of the subcomponent according to the 3.0 format). It
> looks like your code expects it in a subdirectory of utils, so I would
> put a symlink there as part of the build process or adjust the script
> to find it in outputcheck/ rather than utils/.
> 
> I believe you can also get rid of the code to extract the outputcheck
> tarball in the first place. The conventions for the package format
> should take care of preparing the source tree.
> 
> regards
> Afif
> 

any news on this?

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#826273: [pkg-gnupg-maint] Bug#826273: gnupg2: Defaults to using insecure short key IDs (32 bits)

[Daniel Kahn Gillmor]

On Fri 2016-06-03 15:25:36 -0400, Gunnar Wolf wrote:
> GnuPG2 defaults to returning short key IDs when listing keys. Short
> key IDs are quite vulnerable to collisions, and their use should be
> strongly discouraged.
>
> I wrote the following with a progression of attacks; this is all
> well-known for years.
>
> http://gwolf.org/node/4070
>
> So, in short: Please add "keyid-format 0xlong" to
> /usr/share/gnupg2/gpg-conf.skel

I've repeatedly suggested to upstream that we should change this default
(in the software, not just in gpg-conf.skel), but it hasn't happened
yet.  see the changes i've posted here:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030742.html

If upstream decides to not do this, we've discussed having the debian
packages diverge from upstream in some specific circumstances, and i
think this might be one place to do it.  I certainly have no objections
to changing the default keyid-format in debian.

However, I'm a little torn about what to change it to.  the long keyID
itself is only 64 bits, which means it's trivial to mount a collision
attack, and that a pre-image is definitely in range of a
moderately-well-funded attacker.

So i'm inclined to think the actual Right Thing is either to use the
full fingerprint (in cases where cryptographic integrity is desired) or
to show nothing cryptographic at all, leaving only the non-cryptographic
(and obviously forgeable) human-readable details.

I've explored this thinking in a little more detail on my blog [0].

So i'd actually be happier with "keyid-format none" or "keyid format
fingerprint" [1] than with "keyid-format long" but i agree that "long"
or "0xlong" is still superior to the current situation.

   --dkg


[0] https://www.debian-administration.org/users/dkg/weblog/105
[1] https://bugs.gnupg.org/gnupg/issue1445


signature.asc
Description: PGP signature

Bug#826278: gedit: This issue only occurs when Gedit opens in a maximized window.

[Mike]

Package: gedit
Version: 3.14.0-3
Followup-For: Bug #826278

Dear Maintainer,

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

   * What led up to the situation?
Discovered that the bug is only reporduceable if gedit opens in a maximized 
window.

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

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


-- Package-specific info:
Active plugins:
  - 'time'
  -  'modelines'
  -  'docinfo'
  -  'spell'
  -  'filebrowser'

No plugin installed in $HOME.

Module versions:
  - glib  
  - gtk+  
  - gtksourceview 
  - pygobject 
  - enchant   
  - iso-codes 3.57


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

Kernel: Linux 3.16.0-4-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 gedit depends on:
ii  gedit-common   3.14.0-3
ii  gir1.2-peas-1.01.12.1-2
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  iso-codes  3.57-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u4
ii  libcairo-gobject2  1.14.0-2.1+deb8u1
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libenchant1c2a 1.6.0-10.1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii  libgirepository-1.0-1  1.42.0-2.2
ii  libglib2.0-0   2.42.1-1+b1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libgtksourceview-3.0-1 3.14.1-1
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpeas-1.0-0  1.12.1-2
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u2
ii  python3-gi 3.14.0-1
ii  python3-gi-cairo   3.14.0-1
pn  python3:any

Versions of packages gedit recommends:
ii  yelp3.14.1-1
ii  zenity  3.14.0-1

Versions of packages gedit suggests:
ii  gedit-plugins  3.14.0-2

-- no debconf information

Bug#811426: RFS: golang-github-kennygrant-sanitize/1.0-1 [ITP]

[Gianfranco Costamagna]

control: tags -1 moreinfo

On Sun, 15 May 2016 15:59:09 + Mattia Rizzolo  wrote:
> On Mon, Jan 18, 2016 at 12:09:14PM -0800, Nathan Osman wrote:
> > I am looking for a sponsor for my package
> > "golang-github-kennygrant-sanitize"
> 
> >   http://mentors.debian.net/package/golang-github-kennygrant-sanitize
> 
> please consider getting in touch with the pkg-go team, maintain the
> package within the team and ask sponsorship there.



setting moreinfo until the question is answered.

G.

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



signature.asc
Description: OpenPGP digital signature

Bug#826208: util-linux: ionice: clarify documentation of -n,--classdata option

[Daniel Shahaf]

Andreas Henriksson wrote on Fri, Jun 03, 2016 at 14:30:06 +0200:
> Could you please submit this patch upstream (either as a github
> pull request or via vger.kernel.org mailing list) please?
> 

Sure.  I guess I'll send a patch to the list, since howto-pull-request.txt
line 131 et seq says pull requests are frowned upon.

Thanks for the prompt reply,

Daniel

> For detailed instructions please see:
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-contribute.txt
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-pull-request.txt
> (Primarily you'd need to sign off on your changes.)
> 
> Regards,
> Andreas Henriksson

Bug#826280: notmuch: shortcut to list tags

[Jameson Graef Rollins]

Package: notmuch
Version: 0.22-1
Severity: wishlist

I occaissionally want to grep through all tags used in my store:

notmuch search --output=tags '*' | grep 

It would be nice if there was a shortcut to output all tags to stdout:

notmuch tag | grep ...

Just utilizing the notmuch tag command when called with no arguments
would be the most intiuitive (just like git) and simplest.

Thanks.

jamie.

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

Kernel: Linux 4.5.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 notmuch depends on:
ii  libc6   2.22-7
ii  libglib2.0-02.48.1-1
ii  libgmime-2.6-0  2.6.20-1+b1
ii  libnotmuch4 0.22-1
ii  libtalloc2  2.1.6-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages notmuch recommends:
ii  alot   0.3.6-1
ii  gnupg-agent2.1.11-7
ii  gpgsm  2.1.11-7
ii  notmuch-emacs  0.22-1
ii  notmuch-mutt   0.22-1
ii  notmuch-vim0.22-1

notmuch suggests no packages.

-- no debconf information

Bug#826278: gedit: Gedit will not display the last line of content when opening file

[Mike]

Package: gedit
Version: 3.14.0-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Gedit will NOT display the last line of content if it is set to READ ONLY. More 
generally, I installed Debian 8.4 from scratch and noticed that when opening a 
text file that is too long to fit entirely on the screen (i.e., the file must 
be scrolled to view all content), Gedit will not display the last line of 
content until the "enter" key is pressed. If the file happens to have been 
marked READ ONLY, pressing the "enter" key does not work and the last line of 
content is NEVER viewable. If I have 100 lines of content, only 99 lines is 
viewable when opening Gedit. Using cursor key, Page Down, Ctrl+End, all fails 
to show the last line (i.e., the 100th line of content).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
If the file is not marked READ ONLY, pressing the "enter" key causes Gedit to 
show the last line of content.

   * What was the outcome of this action?


   * What outcome did you expect instead?
Gedit should display all content (including empty lines) at the end of the 
file. Nothing should be hidden from view. 


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


-- Package-specific info:
Active plugins:
  - 'time'
  -  'modelines'
  -  'docinfo'
  -  'spell'
  -  'filebrowser'

No plugin installed in $HOME.

Module versions:
  - glib  
  - gtk+  
  - gtksourceview 
  - pygobject 
  - enchant   
  - iso-codes 3.57


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

Kernel: Linux 3.16.0-4-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 gedit depends on:
ii  gedit-common   3.14.0-3
ii  gir1.2-peas-1.01.12.1-2
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  iso-codes  3.57-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u4
ii  libcairo-gobject2  1.14.0-2.1+deb8u1
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libenchant1c2a 1.6.0-10.1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii  libgirepository-1.0-1  1.42.0-2.2
ii  libglib2.0-0   2.42.1-1+b1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libgtksourceview-3.0-1 3.14.1-1
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpeas-1.0-0  1.12.1-2
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u2
ii  python3-gi 3.14.0-1
ii  python3-gi-cairo   3.14.0-1
pn  python3:any

Versions of packages gedit recommends:
ii  yelp3.14.1-1
ii  zenity  3.14.0-1

Versions of packages gedit suggests:
ii  gedit-plugins  3.14.0-2

-- no debconf information

Bug#826279: ITP: node-map-obj -- Map object keys and values into new objects

[Jonathan Ulrich Horn]

Package: wnpp
Severity: wishlist
Owner: Jonathan Ulrich Horn 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name   : node-map-obj
  Version: 1.0.1
  Upstream Author: Sindre Sorhus 
* URL: https://github.com/sindresorhus/map-obj
* License: Expat
  Description: Map object keys and values into new objects

Map property values of an object to keys in a new object.
.
Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#806208: src:gegl: FTBFS on sparc64, tools/introspect segfaults

[John Paul Adrian Glaubitz]

On 06/03/2016 09:44 PM, John Paul Adrian Glaubitz wrote:
> Which seems to fix the problem. In any case, I'll re-assign this to src:gegl.

Ok, there is unfortunately more of these broken pointer arithmetics throughout
babl. That will take some time to get all of these fixed. *sigh*

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)

[Gianfranco Costamagna]

Hi

>Spaces are not allowed in license names. But here the license name is 

>just “GPL-2+”.
>
>Let me quote the relevant part of the spec:
>“An exception or clarification to a license is signalled in plain text, 
>by appending ‘with  exception’ to the short name.”


probably when I tried
a) this wasn't implemented
b) I made some typo that triggered lintian warning.

Happy to see this works correctly, so to the sponsoree, nevermind this part :)

Thanks Jakub!

Gianfranco

Bug#826227: Acknowledgement (gnome-session: Mouse Acts Strange After Awhile)

[Stephen Allen]

Further investigation has lead me to believe that this is a hardware
issue. Think replacing the mouse is in order.

So, AFAIC this bug report may be closed. Excuse the noise.

Bug#826277: banshee fails to start

[Jameson Graef Rollins]

Package: banshee
Version: 2.9.1-5
Severity: grave
Justification: renders package unusable

banshee completely fails to start.  This is currently happening for
both the unstable and experimental versions, but I post the terminal
log for the experimental version here:

servo:~ 0$ banshee --debug --debug-sql --debug-addins --no-gtkrc
** Running Mono with --debug  --profile=gui-thread-check **
The 'gui-thread-check' profiler wasn't found in the main executable nor could 
it be loaded from 'mono-profiler-gui-thread-check'.
[1 Debug 13:00:29.772] Bus.Session.RequestName ('org.bansheeproject.Banshee') 
replied with InQueue

Unhandled Exception:
System.ArgumentException: Cannot create a struct with no fields
Parameter name: signature
at DBus.Protocol.Signature.MakeStruct (Signature signature) <0x41d7de90 + 
0x000cf> in :0
at DBus.Protocol.Signature.GetSig (System.Type type) <0x41d46770 + 0x00303> in 
:0
at DBus.TypeImplementer.SigsForMethod (System.Reflection.MethodInfo mi, 
DBus.Protocol.Signature& inSig, DBus.Protocol.Signature& outSig) <0x41d46430 + 
0x00253> in :0
at DBus.TypeImplementer.GenHookupMethod (System.Reflection.Emit.ILGenerator 
ilg, System.Reflection.MethodInfo declMethod, System.Reflection.MethodInfo 
invokeMethod, System.String interface, System.String member) <0x41d43b50 + 
0x00aa3> in :0
at DBus.TypeImplementer.Implement (System.Reflection.Emit.TypeBuilder typeB, 
System.Type iface, System.String interfaceName) <0x41d42ec0 + 0x0031b> in 
:0
at DBus.TypeImplementer.GetImplementation (System.Type declType) <0x41d41000 + 
0x0025b> in :0
at DBus.BusObject.GetObject (DBus.Connection conn, System.String bus_name, 
DBus.ObjectPath object_path, System.Type declType) <0x41d40db0 + 0x00037> in 
:0
at DBus.Connection.GetObject (System.Type type, System.String bus_name, 
DBus.ObjectPath path) <0x41d3f510 + 0x0007f> in :0
at DBus.Connection.GetObject[T] (System.String bus_name, DBus.ObjectPath path) 
<0x41d3f4a0 + 0x00037> in :0
at Banshee.ServiceStack.DBusServiceManager.FindInstance[T] (System.String 
serviceName, Boolean isFullBusName, System.String objectPath) <0x41d7c130 + 
0x00137> in :0
at Banshee.ServiceStack.DBusServiceManager.FindInstance[T] (System.String 
objectPath) <0x41d7c0e0 + 0x00033> in :0
at Halie.Client.HandlePlayerCommands () <0x41d7ce90 + 0x00073> in :0
at Halie.Client.Main () <0x41d7bb60 + 0x000d7> in :0
at (wrapper managed-to-native) System.AppDomain:ExecuteAssembly 
(System.AppDomain,System.Reflection.Assembly,string[])
at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly a, 
System.String[] args) <0x7fdbc012de10 + 0x00044> in :0
at System.AppDomain.ExecuteAssembly (System.String assemblyFile, 
System.Security.Policy.Evidence assemblySecurity, System.String[] args) 
<0x7fdbc012dd10 + 0x00034> in :0
at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly 
(string,System.Security.Policy.Evidence,string[])
at System.AppDomain.ExecuteAssembly (System.String assemblyFile) 
<0x7fdbc012dcb0 + 0x0001c> in :0
at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly 
(string)
at Booter.Booter.BootClient (System.String clientName) <0x41d7b5e0 + 0x00092> 
in :0
at Booter.Booter.Main () <0x41d31d50 + 0x00047> in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: Cannot create a 
struct with no fields
Parameter name: signature
at DBus.Protocol.Signature.MakeStruct (Signature signature) <0x41d7de90 + 
0x000cf> in :0
at DBus.Protocol.Signature.GetSig (System.Type type) <0x41d46770 + 0x00303> in 
:0
at DBus.TypeImplementer.SigsForMethod (System.Reflection.MethodInfo mi, 
DBus.Protocol.Signature& inSig, DBus.Protocol.Signature& outSig) <0x41d46430 + 
0x00253> in :0
at DBus.TypeImplementer.GenHookupMethod (System.Reflection.Emit.ILGenerator 
ilg, System.Reflection.MethodInfo declMethod, System.Reflection.MethodInfo 
invokeMethod, System.String interface, System.String member) <0x41d43b50 + 
0x00aa3> in :0
at DBus.TypeImplementer.Implement (System.Reflection.Emit.TypeBuilder typeB, 
System.Type iface, System.String interfaceName) <0x41d42ec0 + 0x0031b> in 
:0
at DBus.TypeImplementer.GetImplementation (System.Type declType) <0x41d41000 + 
0x0025b> in :0
at DBus.BusObject.GetObject (DBus.Connection conn, System.String bus_name, 
DBus.ObjectPath object_path, System.Type declType) <0x41d40db0 + 0x00037> in 
:0
at DBus.Connection.GetObject (System.Type type, System.String bus_name, 
DBus.ObjectPath path) <0x41d3f510 + 0x0007f> in :0
at DBus.Connection.GetObject[T] (System.String bus_name, DBus.ObjectPath path) 
<0x41d3f4a0 + 0x00037> in :0
at Banshee.ServiceStack.DBusServiceManager.FindInstance[T] (System.String 
serviceName, Boolean isFullBusName, System.String objectPath) <0x41d7c130 + 
0x00137> in :0
at Banshee.ServiceStack.DBusServiceManager.FindInstance[T] (System.String 
objectPath) <0x41d7c0e0 + 0x00033> in :0
at Halie.Client.HandlePlayerCommands () <0x41d7ce90 + 0x00073> in :0
at Halie.Client.Main () <0x41d7bb60 + 0x000d7> in :0
at 

Bug#826276: Manpage does not document all arguments being passed to the customize script

[Wolodja Wentland]

Package: vmdebootstrap
Version: 1.5-1
Severity: minor

Dear Maintainer,

the manpage of vmdebootstrap documents the customize option as:

  --customize=SCRIPT
  [...]
  Thes cript needs to be executable and is passed the root directory of the
  debootstrap as the only argument.
  [...]

while the call to the customize script looks like:

  cliapp.runcmd([script, rootdir, self.settings['image']], stdout=tty, 
stderr=tty)

It would be great if you could document the second argument (i.e. name of the
image) that is being passed to the script.

Thank you for your consideration and time!

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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.81
ii  extlinux3:6.03+dfsg-13
ii  kpartx  0.5.0+git1.656f8865-9
ii  libjs-sphinxdoc 1.3.6-2
ii  mbr 1.1.11-5+b1
ii  parted  3.2-15
ii  python-cliapp   1.20160316-1
ii  python-distro-info  0.14
ii  python2.7   2.7.11-9
pn  python:any  
ii  qemu-utils  1:2.6+dfsg-1+b1

Versions of packages vmdebootstrap recommends:
ii  grub2-common  2.02~beta2-36
pn  python-guestfs
ii  qemu-system   1:2.6+dfsg-1+b1
ii  qemu-user-static  1:2.6+dfsg-1+b1
ii  squashfs-tools1:4.3-3

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
pn  pandoc
pn  u-boot:armhf  

-- no debconf information

Bug#826275: vmdebootstrap: documentation for --customize is outdated

[Antonio Terceiro]

Package: vmdebootstrap
Version: 1.5-1
Severity: minor

--customize=SCRIPT
   run  SCRIPT  after  setting up system. If the script does not
   exist in the current working directory,  /usr/share/vmdeboot‐
   strap/examples/  will  be  checked  as a fallback. The script
   needs to be executable and is passed the  root  directory  of
   the  debootstrap as the only argument. Use chroot if you need
   to execute binaries within the debootstrap.

It fails to mention that the name of the output image is passed as the second
argument. maybe this is intentional, and kept undocumented on purpose?

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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.81
ii  extlinux3:6.03+dfsg-13
ii  kpartx  0.5.0+git1.656f8865-9
ii  libjs-sphinxdoc 1.3.6-2
ii  mbr 1.1.11-5+b1
ii  parted  3.2-15
ii  python-cliapp   1.20160316-1
ii  python-distro-info  0.14
ii  python2.7   2.7.11-11
pn  python:any  
ii  qemu-utils  1:2.6+dfsg-1+b1

Versions of packages vmdebootstrap recommends:
ii  grub2-common  2.02~beta2-36
ii  python-guestfs1:1.32.5-1
ii  qemu-system   1:2.6+dfsg-1+b1
ii  qemu-user-static  1:2.6+dfsg-1+b1
ii  squashfs-tools1:4.3-3

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  pandoc1.17.0.3~dfsg-1
pn  u-boot:armhf  

-- no debconf information

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#826090: mate-terminal broken after todays upgrade (debian testing)

[John Paul Adrian Glaubitz]

On 06/03/2016 09:50 PM, Le Déchaîné wrote:
> Well, you've done way more damage than me: I haven't broken any packages.

People who don't touch anything, also cannot break anything.

Furthermore, there was NOTHING broken - at ALL.

> I tried to help by warning others, you cried like a baby. And instead
> of leaving legitimate bug reports alone, which would have cost you
> zero seconds, you spent hours of your life telling me, a random
> stranger, how oh so valuable was your spare time.

Are you feeling bored that you have to keep annoy others?

> I get it: Bug reports for Mate are worthless, and Mate is worthless
> because you are. So, for all your "help" for "mate": Fuck off. Signed,
> an actual user. You know, because people use testing, and you "work"
> for testing.

I don't need script kiddies like you to write bug reports. Your bug
report is - again - useless. Learn to write bug reports, it is
documented in many places.

> Oh, "god help us all", you contribute to systemd too. That's scary.

Haha, I can't believe it but it always seem to be the same uninformed
idiots who are attacking systemd. You can basically bet on it. Hilarious!

> I hope everyone seeing this will roll up their sleeves and get you
> banned from "testing" because of your "unstable" mentality. That's
> all.

You're funny because you don't understand how Debian works. There
is no such thing as banning me from testing.

> Now I got it, I'll spend my precious spare time doing more useful
> things than talking to you, like, everything else. Farewell.

How about you actually start contributing to open source yourself?

What have you been contributing to except for annoying others?

Anything?

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#826090: mate-terminal broken after todays upgrade (debian testing)

[Le Déchaîné]

> Seriously, fuck off! Either roll up your sleeves and help or stop
> annoying others.
>
> I have probably done way more in Debian than you will ever have,
> so I don't have to accept some random stranger telling me off.

Well, you've done way more damage than me: I haven't broken any packages.
I tried to help by warning others, you cried like a baby. And instead
of leaving legitimate bug reports alone, which would have cost you
zero seconds, you spent hours of your life telling me, a random
stranger, how oh so valuable was your spare time.

I get it: Bug reports for Mate are worthless, and Mate is worthless
because you are. So, for all your "help" for "mate": Fuck off. Signed,
an actual user. You know, because people use testing, and you "work"
for testing.

Oh, "god help us all", you contribute to systemd too. That's scary.

I hope everyone seeing this will roll up their sleeves and get you
banned from "testing" because of your "unstable" mentality. That's
all.

Now I got it, I'll spend my precious spare time doing more useful
things than talking to you, like, everything else. Farewell.

Bug#806208: src:gegl: FTBFS on sparc64, tools/introspect segfaults

[John Paul Adrian Glaubitz]

Control: reassign -1 src:babl

On 06/03/2016 09:17 PM, John Paul Adrian Glaubitz wrote:
> Program received signal SIGBUS, Bus error.
> 0xfff8000101a21378 in ?? () from /usr/lib/sparc64-linux-gnu/babl-0.1/gggl.so
> (gdb) bt
> #0  0xfff8000101a21378 in ?? () from 
> /usr/lib/sparc64-linux-gnu/babl-0.1/gggl.so
> #1  0xfff8000100bc5970 in babl_conversion_process () from 
> /usr/lib/sparc64-linux-gnu/libbabl-0.1.so.0
> #2  0xfff8000100bc7868 in babl_process () from 
> /usr/lib/sparc64-linux-gnu/libbabl-0.1.so.0
> #3  0xfff8000100bc5d9c in babl_conversion_error () from 
> /usr/lib/sparc64-linux-gnu/libbabl-0.1.so.0
> #4  0xfff8000100bc7a58 in ?? () from 
> /usr/lib/sparc64-linux-gnu/libbabl-0.1.so.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

Which seems to be:

Program received signal SIGBUS, Bus error.
0xfff80001009d5338 in conv_rgb8_rgba8 (
src=0x22b7d3
"\373\327\253\276\242\\܄c\373\247\330\306\376\306\311{\347\340h\202G\374\316\323(d\246\205b\266\210\237\321\063g(\332\327\363\270\210ζ\271\261Y\333a\353\213K\246\313\320\371\374\375\\\265\350i\315\317\353\366\367\317\356\264_ĻlIW8\247k\355N\376\330\324\302\a\355\353\343Ψ\267\350ʢ\245\275\262~\271\313ױ\341ɱ\207\070\210\362\354Ӵ\354\367\322\362\016\215\314\333\351`\253\347\352ī\220ә\373}\347\374\213\351\363\264\346\332C\226\374`U\372\362\345\244yӯ\373\251\340{\334\062\300\367\321ݞ\262ӭý\274\223\221\325옍\232\325H\264幘\255\372\224\225\337\366n\265\334\373\031G\326",
...,
dst=0x22ec14 "", samples=128) at gggl.c:758
758   *(unsigned int *) dst = (*(unsigned int *) src) | (255 << 24);

I have replaced this with:

  unsigned int tmp;
  memcpy(, src, sizeof(unsigned int));
  tmp = tmp | (255 << 24);
  memcpy(dst, , sizeof(unsigned int));

Which seems to fix the problem. In any case, I'll re-assign this to src:gegl.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#826039: liblwp-protocol-https-perl: Two versions of https.pm (6.06) have different contents and one always checks certificates

[Adrian Edwards]

Thanks for the info, that makes sense.

I tried a clean install, loaded the package, then tried to add the "working"
version via CPAN, however it reports "up to date" but the module isn't
actually in the local tree, only the share tree. I then tried a cpan force
install but that still reported it was up to date. If it had installed it
would solve my particular problem, but as it refuses to install via CPAN it
is difficult to get the CPAN version and for that to become available in the
path as the first referenced module.

I guess on one of my earlier installs I loaded via CPAN before apt-get and
that's why that happened to work.


- - -  - -  - - 

# perldoc -lm LWP::Protocol::https
/usr/share/perl5/LWP/Protocol/https.pm

# cpan install LWP::Protocol::https
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/root/.cpan/Metadata'
  Database was generated on Wed, 01 Jun 2016 14:54:02 GMT
Fetching with LWP:
http://www.cpan.org/authors/01mailrc.txt.gz
Reading '/root/.cpan/sources/authors/01mailrc.txt.gz'

DONE
Fetching with LWP:
http://www.cpan.org/modules/02packages.details.txt.gz
Reading '/root/.cpan/sources/modules/02packages.details.txt.gz'
  Database was generated on Fri, 03 Jun 2016 18:53:42 GMT

DONE
Fetching with LWP:
http://www.cpan.org/modules/03modlist.data.gz
Reading '/root/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /root/.cpan/Metadata
LWP::Protocol::https is up to date (6.06).

# perldoc -lm LWP::Protocol::https
/usr/share/perl5/LWP/Protocol/https.pm

# ls -l /usr/local/share/perl/5.20.2/LWP/Protocol/https.pm
ls: cannot access /usr/local/share/perl/5.20.2/LWP/Protocol/https.pm: No
such file or directory


- - -  - -  - - 

# cpan force install LWP::Protocol::https
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/root/.cpan/Metadata'
  Database was generated on Fri, 03 Jun 2016 18:53:42 GMT
Warning: Cannot install force, don't know what it is.
Try the command

i /force/

to find objects with matching identifiers.
Running install for module 'install'
Fetching with LWP:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/install-0.01.tar.gz
Checksum for
/root/.cpan/sources/authors/id/D/DA/DAGOLDEN/install-0.01.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring D/DA/DAGOLDEN/install-0.01.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for install
Writing MYMETA.yml and MYMETA.json
  DAGOLDEN/install-0.01.tar.gz
  /usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for D/DA/DAGOLDEN/install-0.01.tar.gz
cp lib/install.pm blib/lib/install.pm
Manifying blib/man3/install.3pm
  DAGOLDEN/install-0.01.tar.gz
  /usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib',
'blib/arch')" t/*.t
t/install.t .. ok
All tests successful.
Files=1, Tests=1,  0 wallclock secs ( 0.04 usr  0.02 sys +  0.04 cusr  0.00
csys =  0.10 CPU)
Result: PASS
  DAGOLDEN/install-0.01.tar.gz
  /usr/bin/make test -- OK
Running make install
Installing /usr/local/share/perl/5.20.2/install.pm
Installing /usr/local/man/man3/install.3pm
Appending installation info to
/usr/local/lib/x86_64-linux-gnu/perl/5.20.2/perllocal.pod
  DAGOLDEN/install-0.01.tar.gz
  /usr/bin/make install  -- OK
LWP::Protocol::https is up to date (6.06).



-Original Message-
From: Niko Tyni [mailto:nt...@debian.org] 
Sent: 03 June 2016 14:16
To: Adrian Edwards; 826...@bugs.debian.org
Subject: Re: Bug#826039: liblwp-protocol-https-perl: Two versions of
https.pm (6.06) have different contents and one always checks certificates

Control: severity -1 normal
Control: tags -1 =

On Wed, Jun 01, 2016 at 08:27:10PM +0100, Adrian Edwards wrote:
> Package: liblwp-protocol-https-perl
> Version: 6.06-2
> Severity: grave
> Tags: newcomer patch
> Justification: renders package unusable

> Trying to use $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; within perl 
> script to prevent verification of a self signed certificate, the 
> script worked sometimes and not others on different Debian 8 installs. 
> Did a bunch of installs of minimal system, added packages and modules
(apt-get and CPAN) and the module ALWAYS wanted to verify the cert and
didn't honour the environment variable to ignore the check.

> After a huge amount of wasted time I discovered there are two version 
> of the protocol module, both have the same version number 6.06 but the
contents of the files are different.
> 
>   /usr/local/share/perl/5.20.2/LWP/Protocol/https.pmCorrect/Works
>   /usr/share/perl5/LWP/Protocol/https.pmIn Error / Always fails
the check

Hi, first of all: packages installed with apt get installed in /usr/share
and /usr/lib (vendorlib 

Bug#826034: dolphin: No icons, even if XDG_CURRENT_DESKTOP=KDE

[Maximiliano Curia]

¡Hola Marcus!

El 2016-06-03 a las 15:48 +0200, Marcus Frings escribió:

On Wed, 01 Jun 2016 21:08:04 +0300 Victor Porton 
wrote:

Dolphin (the same applies to Kate) was not showing icons. 
But recently after a system upgrade, XDG_CURRENT_DESKTOP=KDE does not 
help anymore. Dolphin does not show any icons even if started with 
XDG_CURRENT_DESKTOP=KDE



I can fully confirm this (on a Fluxbox system here).


Please install plasma-integration, which has the platformplugin that qt5 is 
looking for (when XDG_CURRENT_DESKTOP=KDE is configured).


Happy hacking,
--
"The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time."
-- Tom Cargill
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#826274: chromium: Chromium web browser cannot be set as the Default browser. Absolutely nothing can be done to get Chromium to be set as the default web browser.

[Mike]

Package: chromium
Version: 51.0.2704.63-1~deb8u1
Severity: important

Dear Maintainer,

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

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

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


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

Kernel: Linux 3.16.0-4-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 chromium depends on:
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcups2 1.7.5-11+deb8u1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libexpat12.1.0-6+deb8u2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libharfbuzz0b0.9.35-2
ii  libjpeg62-turbo  1:1.3.1-12
ii  libnspr4 2:4.10.7-1+deb8u1
ii  libnss3  2:3.17.2-1.1+deb8u2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpci3  1:3.2.1-3
ii  libspeechd2  0.8-7
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxml2  2.9.1+dfsg1-5+deb8u1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxslt1.1   1.1.28-2+b2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+2
ii  xdg-utils1.1.0~rc1+git20111210-7.4

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-inspector  
pn  chromium-l10n   

-- no debconf information

Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)

[Jakub Wilk]

* Gianfranco Costamagna , 2016-06-02, 17:07:

"License: GPL-2+ with librtas exception"

maybe something like
License: GPL-2+-with-librtas-exception


"FOO with BAR exception" is a valid licence syntax in DEP-5.
If it is not appropriate to use it in this case, then you should 
explain why, because it's not obvious.


the difference is just removing the spaces, IIRC lintian was triggering 
issues on dep-5 format when spaces were used.


Spaces are not allowed in license names. But here the license name is 
just “GPL-2+”.


Let me quote the relevant part of the spec:
“An exception or clarification to a license is signalled in plain text, 
by appending ‘with  exception’ to the short name.”


--
Jakub Wilk

Bug#826273: gnupg2: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Package: gnupg2
Version: 2.1.11-7
Severity: normal
Tags: security

GnuPG2 defaults to returning short key IDs when listing keys. Short
key IDs are quite vulnerable to collisions, and their use should be
strongly discouraged.

I wrote the following with a progression of attacks; this is all
well-known for years.

http://gwolf.org/node/4070

So, in short: Please add "keyid-format 0xlong" to
/usr/share/gnupg2/gpg-conf.skel

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

Kernel: Linux 4.5.0-2-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 gnupg2 depends on:
ii  dpkg   1.18.7
ii  gnupg-agent2.1.11-7
ii  install-info   6.1.0.dfsg.1-8
ii  libassuan0 2.4.2-3
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.22-10
ii  libgcrypt201.7.0-2
ii  libgpg-error0  1.22-2
ii  libksba8   1.3.4-3
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.13.0-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg2 recommends:
ii  dirmngr  2.1.11-7

Versions of packages gnupg2 suggests:
pn  gnupg-doc   
ii  parcimonie  0.10.1-1
pn  xloadimage  

-- no debconf information

Bug#826272: ITP: node-camelcase -- Convert a string to camelCase

[Jonathan Ulrich Horn]

Package: wnpp
Severity: wishlist
Owner: Jonathan Ulrich Horn 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name   : node-camelcase
  Version: 3.0.0
  Upstream Author: Sindre Sorhus 
* URL: https://github.com/sindresorhus/camelcase
* License: Expat
  Description: Convert a string to camelCase

 Convert a dash, dot, underscore or space separated string to camelCase.
 I.e. foo-bar -> fooBar.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#826271: prosody-modules: please add mobile focused modules

[Jamie McClelland]

Package: prosody-modules
Severity: wishlist

Dear Maintainer,

Thank you for your work packaging prosody modules!

There is a very compelling blog by the maintainer of the conversations android
XMPP client (https://gultsch.de/xmpp_2016.html) in which he outlines some of
the modules that are important in order to support mobile XMPP clients.

These are:

 * Message Archive Management (https://modules.prosody.im/mod_mam.html) aka
XEP-0313 - prevents your messages from disappearing into the ether if you are
temporarily offline when a message comes in.

 * Client State Indication (https://modules.prosody.im/mod_csi.html) aka
XEP-0352 - allows your client to request that it not be notified for minor
things like presence updates. Unfortunately, this one also requires at least
one of the two throttle modules - mod_throttle_presence and/or
mod_filter_chatstates

 * HTTP File UPload (https://modules.prosody.im/mod_http_upload.html) aka
XEP-0363 - Ensure files sent can be received on all devices. This one seems
less stable in prosody and also less important.

Thank you!



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

Kernel: Linux 4.5.0-2-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)

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Dmitry Bogatov]

> >http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc
> 404

Sorry. Should work now.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#826270: gnupg: Defaults to using insecure short key IDs (32 bits)

[Gunnar Wolf]

Package: gnupg
Version: 1.4.20-6
Severity: normal

GnuPG defaults to returning short key IDs when listing keys. Short key
IDs are quite vulnerable to collisions, and their use should be
strongly discouraged.

I wrote the following with a progression of attacks; this is all
well-known for years.

http://gwolf.org/node/4070

So, in short: Please add "keyid-format 0xlong" to
/usr/share/gnupg/options.skel

Thanks,

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

Kernel: Linux 4.5.0-2-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 gnupg depends on:
ii  gpgv  1.4.20-6
ii  libbz2-1.01.0.6-8
ii  libc6 2.22-10
ii  libreadline6  6.3-8+b4
ii  libusb-0.1-4  2:0.1.12-30
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  gnupg-curl 1.4.20-6
ii  libldap-2.4-2  2.4.42+dfsg-2+b2

Versions of packages gnupg suggests:
pn  gnupg-doc 
ii  imagemagick   8:6.8.9.9-7.1
ii  libpcsclite1  1.8.17-1
ii  parcimonie0.10.1-1

-- no debconf information

Bug#806208: src:gegl: FTBFS on sparc64, tools/introspect segfaults

[John Paul Adrian Glaubitz]

Hi Matteo!

On 11/25/2015 06:35 PM, Matteo F. Vescovi wrote:
> Having a look at [1] seems like sparc64 is out of luck since a looong time ;-)
> 
> Hope to have some spare time to investigate further on the issue.

I have had some time now and according to gdb, it's actually crashing in 
libbabl:

root@deb4g:~/gegl/docs# GEGL_SWAP=RAM GEGL_PATH=../operations 
../tools/operation_reference --json-db > operations.json
+ sed_quote_subst='s|\([`"$\\]\)|\\\1|g'
+ test -n ''
+ case `(set -o) 2>/dev/null` in
+ set -o posix
+ BIN_SH=xpg4
+ export BIN_SH
+ DUALCASE=1
+ export DUALCASE
+ unset CDPATH
+ relink_command='(cd /root/gegl/tools; { test -z "${LIBRARY_PATH+set}" || 
unset LIBRARY_PATH || { LIBRARY_PATH=; export LIBRARY_PATH; }; }; { test -z
"${COMPILER_PATH+set}" || unset COMPILER_PATH || { COMPILER_PATH=; export 
COMPILER_PATH; }; }; { test -z "${GCC_EXEC_PREFIX+set}" || unset 
GCC_EXEC_PREFIX || {
GCC_EXEC_PREFIX=; export GCC_EXEC_PREFIX; }; }; { test -z "${LD_RUN_PATH+set}" 
|| unset LD_RUN_PATH || { LD_RUN_PATH=; export LD_RUN_PATH; }; }; { test -z
"${LD_LIBRARY_PATH+set}" || unset LD_LIBRARY_PATH || { LD_LIBRARY_PATH=; export 
LD_LIBRARY_PATH; }; };
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; export PATH; 
gcc -pthread -I/usr/include/json-glib-1.0 -I/usr/include/gio-unix-2.0/
-I/usr/include/glib-2.0 -I/usr/lib/sparc64-linux-gnu/glib-2.0/include 
-I/usr/include/babl-0.1 -g -O3 -Wall -Wdeclaration-after-statement 
-Wmissing-prototypes
-Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition 
-DG_LOG_DOMAIN=\"GEGL-\"__FILE__ -Wl,--export-dynamic -pthread -pthread -o
$progdir/$file operation_reference.o  ../gegl/.libs/libgegl-0.3.so 
-lgmodule-2.0 -ljson-glib-1.0 -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 
-lbabl-0.1 -lm
-pthread -Wl,-rpath -Wl,/root/gegl/gegl/.libs)'
+ test '' = '%%%MAGIC variable%%%'
+ test '' '!=' '%%%MAGIC variable%%%'
+ file=../tools/operation_reference
+ ECHO='printf %s\n'
+ lt_option_debug=
+ func_parse_lt_options ../tools/operation_reference --json-db
+ lt_script_arg0=../tools/operation_reference
+ shift
+ for lt_opt in '"$@"'
+ case "$lt_opt" in
+ test -n ''
++ printf '%s\n' ../tools/operation_reference
++ /bin/sed 's%/[^/]*$%%'
+ thisdir=../tools
+ test x../tools = x../tools/operation_reference
++ ls -ld ../tools/operation_reference
++ /bin/sed -n 's/.*-> //p'
+ file=
+ test -n ''
+ WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no
+ test no = yes
++ cd ../tools
++ pwd
+ absdir=/root/gegl/tools
+ test -n /root/gegl/tools
+ thisdir=/root/gegl/tools
+ program=lt-operation_reference
+ progdir=/root/gegl/tools/.libs
+ test '!' -f /root/gegl/tools/.libs/lt-operation_reference
++ ls -1dt /root/gegl/tools/.libs/lt-operation_reference 
/root/gegl/tools/.libs/../lt-operation_reference
++ /bin/sed 1q
+ file=/root/gegl/tools/.libs/lt-operation_reference
+ test X/root/gegl/tools/.libs/lt-operation_reference '!=' 
X/root/gegl/tools/.libs/lt-operation_reference
+ test -f /root/gegl/tools/.libs/lt-operation_reference
+ test '' '!=' '%%%MAGIC variable%%%'
+ func_exec_program --json-db
+ case " $* " in
+ func_exec_program_core --json-db
+ test -n ''
+ exec /root/gegl/tools/.libs/lt-operation_reference --json-db
Bus error
root@deb4g:~/gegl/docs# /root/gegl/tools/.libs/lt-operation_reference
Bus error
root@deb4g:~/gegl/docs# gdb /root/gegl/tools/.libs/lt-operation_reference
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 "sparc64-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 /root/gegl/tools/.libs/lt-operation_reference...done.
(gdb) run
Starting program: /root/gegl/tools/.libs/lt-operation_reference
BFD: /usr/lib/debug/.build-id/4a/2be3888dfebbf721816e4df21fa6546ccf8e59.debug: 
unable to initialize decompress status for section .debug_aranges
BFD: /usr/lib/debug/.build-id/4a/2be3888dfebbf721816e4df21fa6546ccf8e59.debug: 
unable to initialize decompress status for section .debug_aranges
warning: File 
"/usr/lib/debug/.build-id/4a/2be3888dfebbf721816e4df21fa6546ccf8e59.debug" has 
no build-id, file skipped
BFD: /usr/lib/debug/.build-id/32/5145ec18ef1f1729dd9480cb374706fb208225.debug: 
unable to initialize decompress status for section .debug_aranges
BFD: /usr/lib/debug/.build-id/32/5145ec18ef1f1729dd9480cb374706fb208225.debug: 
unable to initialize decompress status for section .debug_aranges
warning: File 

Bug#813096: AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Gianfranco Costamagna]

Hi

> I still don't see "python" in build-dependencies.



>I tried that already, but somehow it did not work out (that's why the manual 
>"python2.6 | python2.7" is kept).

the reason should be the missing python dependency and the missing dh_python2 
call

>I'll stay on that one (see todos), at the moment I am trying to figure out 
>with strace what the rule
>
>/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner 
>usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
>
>is doing and why it does not detect the correct version to pass it on to 
>dpkg-gencontrol.


don't know, dh --python2 should do the job.
not sure why you override that



>You are good! Funny, how dumb one can be ... Just used the stubs from previous 
>packages without thinking ...


:)

IIRC I did the same mistake some years ago :D


>Would that split of old postinst solve all problems without provoking new 
>ones?


I guess so
>a) new preinst: the user/creation (with #DEBHELPER#)
>b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)


with DEBHELPER too.

preinst <-- user creation
postinst <-- systemd start (automatically)


prerm <-- systemd stop (automatically)
postrm <-- user del and whatever

I'm not completely sure, just try, test and look at the policy
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
>OK, I have deleted for now. What about the suggestion with the CHANGELOG?
>
>Currently debian/changelog is the "packaging changelog". But the software has 
>also a "feature/version changelog". Where should that be kept best? Options:


dh_installchangelogs is your friend :)
(but files that has similar names are added automatically I guess, just check if
it is added or not

>I have removed that part, both unused options and the error handling.


it should already be handled in the DEBHELPER macro, right?
>Thanks for the pointer to quilt. Seems to make sense, is on the todo list.

ok

>Understood, quilt will do here also.

yes
>OK, I will change. There is only one question open at the moment: what is the 
>Debian policy for versioning of those Debian-specific build files? Could they 
>be hosted just anywhere, e.g. adding them to the same upstream repository, 
>used to build the source.tar.gz or should the go to a separate repository, 
>perhaps even under control of Debian folks like the "Debian collab platform"? 
>Would https://wiki.debian.org/Alioth/PackagingProject make sense?


whenever you want, a "debian" branch in upstream packaging, a directory on your 
pc
whenever is convenient for you (also alioth, collab-maint, github)

having a different branch on git will make the packaging of new releases easy as
git checkout debian
git merge vVERSION-tag
dch
and so on
(YMMW)

>Thank you very much for your answers and patience, I will do a clean package 
>build after doing some more reading/testing.

keep your time :)

>Todos:
>* Fix: " dh --with=systemd,python2" somehow fails to substitute 
>dependencies/version in control
>* Check transition to "pybuild" and possible side effects (see mails 
>~2016-06-02) after solving the dependency problem
>* Enable quilt mode to patch upstream Launchpad source.tar.gz after deciding 
>about versioning of Debian-specific patches.


irc/OFTC and #debian-python/#debian-mentors channels might be your friends,
as well as manpages :)
(or the debian-mentors mail list)
G.

Bug#826269: ITP: classpath-explorer -- Java library which allows you to discover classes at runtime.

[George Bateman]

Package: wnpp
Severity: wishlist
Owner: George Bateman 

* Package name: classpath-explorer
  Version : 1.0
  Upstream Author : Miško Hevery 
* URL : http://code.google.com/p/classpath-explorer
* License : Apache 2.0
  Programming Lang: Java
  Description : Java library which allows you to discover classes at 
runtime.

This package is a dependency of Processing ,
, which is why
I'm packaging it; I am currently working on Processing's ITP.

I would like this to be under the Debian Java Team's auspices.

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,
>http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc



404

G.

Bug#826268: RFS: diskscan/0.19-1~bpo8+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an updated bpo of "diskscan", and I
filed a bpo request for it about two weeks ago.  Please upload to
delayed/15 to give Joao Eriberto Mota Filho pently of time to
review/respond.

Package name: diskscan
Version: 0.19-1~bpo8+1
Section: utils

It builds this binary package:

diskscan   - scan storage media for bad or near failure sectors

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/diskscan/diskscan_0.19-1~bpo8+1.dsc

Changes since the last upload:

  * Rebuild for jessie-backports. (Closes: #824812)


Regards,
Nicholas D Steeves

Bug#826090: mate-terminal broken after todays upgrade (debian testing)

[John Paul Adrian Glaubitz]

On 06/03/2016 07:46 PM, Jordi Burguet Castell wrote:
> It's a bad experience enough to have your system, which worked fine for years,
> suddenly unusable because of a change in testing. No hard feelings, mistakes
> happen, and one can check the bug reports that people have kindly provided.

Excuse me, but how often are you upgrading from GTK2 to GTK3? Are you honestly
expecting this to happen without zero issues while on a development branch?

And you can turn it anyway you want, but testing is definitely not intended
for production use, so I have no idea why people keep complaining.

Are you also expecting that your house will be free of dust and dirt while the
construction company is there? There is an old saying which applies here very 
well:
You can't make an omelette without breaking eggs.

> Now, there being a maintainer that ignores them and talks with no education 
> is a whole different level.

As I said before: There are people who are reporting bugs which document actual
bugs. And there are people who are experiencing temporary issues because they
are using a development release of a Linux distribution without understanding
the ramifications of it.

There are plenty of distributions which cater everyone's need and set of skills
and if you don't have the skills to fix issues with a development version of
a distribution yourself, well, then you shouldn't be using one.

You can turn this argument any way you want: I will never agree with anyone
who is complaining about issues with a development release. It's complete
and utter non-sense to do that and so are those "distributions" who are
based on Debian testing.

Really, why are we even discussing? I don't get it.

> Mike, thanks a lot for your understanding. Much love for your tone and your 
> work.

Jordi, if you got the flood of repetitive and absolutely pointless bug reports
like we did the past week, you would be upset, too. I have taken care of all
these bug reports so Mike wouldn't have to.

Please do not prejudge me as a bad person and someone who is not willing to
help, I am the complete opposite. I simply have a problem with entitled users
who apparently overestimate their own skills.

Bug reports like these are the reasons why the bug trackers of most other
open source projects require to register a user account with a verified
email before you are able to post anything. The threshold to be able to
report a bug in Debian is simply too low and people are abusing this.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#813096: AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Fiedler Roman]

> From: Gianfranco Costamagna [mailto:locutusofb...@debian.org]
>
> > E: logdata-anomaly-miner: python-script-but-no-python-dep
> >Tried to follow the guidelines, seems that everything works but lintian is 
> >still
> complaining. Changes recommended from various forums:
>
> >Any ideas would be appreciated. Otherwise I'll just add a workaround to get
> rid of the lintian error.
>
> I still don't see "python" in build-dependencies.
>
> BTW your rules hack is wrong, please just call dh --with=systemd,python2
>
> BTW "python2.6 | python2.7" <-- please remove dh_python2 should handle
> them too

I tried that already, but somehow it did not work out (that's why the manual 
"python2.6 | python2.7" is kept).
   dh_gencontrol
dpkg-gencontrol: warning: Depends field of package logdata-anomaly-miner: 
unknown substitution variable ${python:Depends}
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: package logdata-anomaly-miner: unknown substitution 
variable ${python:Versions}
   dh_md5sums
   dh_builddeb


I'll stay on that one (see todos), at the moment I am trying to figure out 
with strace what the rule

/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner 
usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl

is doing and why it does not detect the correct version to pass it on to 
dpkg-gencontrol.


> > W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:30
> > W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:31
>
> Gone by following changes  (BUT read below):
>
> >CAVEAT: Although lintian is happy, there are two issues with that change,
> that may/are problematic:
> >
> >a) I moved the DEBHELPER in prerm BEFORE my code to delete the users. Is
> the DEBHELPER code really intended to be run before or may this cause other
> issues?
>
> what about a "postrm" script?

You are good! Funny, how dumb one can be ... Just used the stubs from previous 
packages without thinking ...

> >b) In postinst DEBHELPER will automatically activate the systemd unit. But 
> >this
> was not done INTENTIONALLY! Therefore documentation included a section,
> what to >check/do before activating the service to avoid any risks. Are 
> there
> means to get to that state also with the dh-systemd components?
>
> preinst?

Would that split of old postinst solve all problems without provoking new 
ones?

a) new preinst: the user/creation (with #DEBHELPER#)
b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)

> >Thanks for the hint. If I understand correctly, pybuild will only care 
> >about
> maintaining the dependencies to the python packages and which interpreter
> to use but it >will NOT require the software to load from site-packages or 
> to
> create/use pyc files, which is currently avoided due to security reasons?
>
> I'm not sure :( sorry

No problem, kept as todo.

> >According to Debian manual, this should be used to automatically include
> files from uppermost directory of the unpacked source. Currently there are
> no useful files >at this location, all documentation is included directly 
> from
> source/root/usr/share/doc/aminer/. Would following files be sufficient?
>
> an empty file can be deleted, if you have no documentation, but having an
> empty file should be avoided
> (I don't like them, they overcomplicate packaging and are just useless)

OK, I have deleted for now. What about the suggestion with the CHANGELOG?

Currently debian/changelog is the "packaging changelog". But the software has 
also a "feature/version changelog". Where should that be kept best? Options:

* only upstream tar-ball but dropped during packaging
* in tar and package at same location
* in tar and package at different location

> [Snip]
>
> >Current content is "root/* ." There is no compiling involved, so this 
> >copies
> just the plain files into the package. Is there something else to be used 
> for this
> >purpose?
>
> not sure, does dh_systemd correctly handle the service file?

Yes, it seems so: from generated #DEBHEL:

# Automatically added by dh_systemd_enable
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask aminer.service >/dev/null || true

# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled aminer.service; then


> >How should that work? In generated DEBHELPER code I do not see any
> commands that would create the users? If you mean the length of " >abort-
> >upgrade|abort->remove|abort-deconfigure": this is from dh-make, should
> that be changed?
>
> yes, just override what you need, don't put default stuff there
> (and open a built-deb file, you will see the #DEBHELPER# macro substituted

I just kept it as it seemed to me to be a second line of defence against 
typos: everything not handled will end up in the "exit 1", so the first 
attempt to install the package during testing/continuous integration 

Bug#826175: xargs: Segfaults on hurd

[Samuel Thibault]

Samuel Thibault, on Fri 03 Jun 2016 19:56:00 +0200, wrote:
> Andreas Metzler, on Fri 03 Jun 2016 19:10:12 +0200, wrote:
> > I suspect a broken build.
> 
> I don't think that's it. The whole testsuite passes except
> 
> ../build-aux/test-driver: line 107:  9207 Aborted (core 
> dumped) "$@" > $log_file 2>&1
> FAIL: test-faccessat

Ah, no, sorry, that's only the test/ directory. We do get failures in
other directories.

Anyway, let's just fix this.

Samuel

Bug#826267: ITP: pyeapi -- Python Client for eAPI

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

* Package name: pyeapi
  Version : 0.6.1
  Upstream Author : Arista EOS+ CS 
* URL : https://github.com/arista-eosplus/pyeapi
* License : BSD-3
  Programming Lang: Python
  Description : Python API to interact with Arista EOS network devices

 The Python Client for eAPI (pyeapi) is a native Python library wrapper around
 Arista EOS eAPI.  It provides a set of Python language bindings for configuring
 Arista EOS nodes.
 .
 The Python library can be used to communicate with EOS either locally
 (on-box) or remotely (off-box). It uses a standard INI-style configuration file
 to specify one or more nodes and connection profiles.
 .
 The pyeapi library also provides an API layer for building native Python
 objects to interact with the destination nodes. The API layer is a convenient
 implementation for working with the EOS configuration and is extensible for
 developing custom implementations.

Bug#826266: RFS: dvtm/0.15-1~bpo8+1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: dvtm
  Version : 0.15-1~bpo8+1
  Upstream Author : Marc Andre Tanner 
* Url : http://www.brain-dump.org/projects/dvtm
* Licenses: MIT/X
  Section : utils

It builds those binary packages:

dvtm -- Tiling window management for the console

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

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

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

http://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-1~bpo8+1.dsc

Alternatively, you can access package debian/ directory via git from URL:

Sorry, git repository is not availiable

More information about dvtm can be obtained from 
http://www.brain-dump.org/projects/dvtm

Changes since last upload:

  * Rebuild for jessie-backports.

Regards,
  Dmitry Bogatov

Bug#826261: caja: rename problem

[John Paul Adrian Glaubitz]

Control: tags -1 unreproducible
Control: tags -1 moreinfo

On 06/03/2016 08:04 PM, Max wrote:
> I can rename files only on first column, other column doesn't work.

I cannot reproduce this problem. Renaming works as expected.

We have had other users report this before and it turned out to be a
local configuration problem [1]. Please try with a new user account.

I'll let this bug report open and wait for your feedbkack. Unless I
hear from you again, I'm going to close this bug report.

Please be advised that this is a bug tracker, not a support forum!

Thanks,
Adrian

> [1] http://bugs.debian.org/825685

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#826265: ITP: napalm-eos -- Network Automation and Programmability Abstraction Layer with Multivendor suppor

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

* Package name: napalm-eos
  Version : 0.2.0
  Upstream Author : David Barroso 
* URL : https://github.com/napalm-automation/napalm-eos
* License : Apache-2.0
  Programming Lang: Python
  Description : abstraction layer for multivendor network automation - EOS 
support

Binary package names: python-napalm-eos

 NAPALM (Network Automation and Programmability Abstraction Layer with
 Multivendor support) is a Python library that implements a set of
 functions to interact with different router vendor devices using a
 unified API.
 .
 NAPALM supports several methods to connect to the devices, to
 manipulate configurations or to retrieve data.
 .
 This module provides support for Arista EOS-based devices.

Bug#826264: libjetty8-extra-java: Softlink to asm jars are broken

[Andreas Feldner]

Package: libjetty8-extra-java
Version: 8.1.19-2
Severity: important

Dear Maintainer,

a recent update of the package changed dependency on libasm version 5. However, 
the package contains softlinks under /usr/share/jetty8/lib/annotations.
Here the relevant ones are org.objectweb.asm.commons.jar and 
org.objectweb.asm.jar. Problem is that these links point to asm4.jar and 
asm4-commons.jar, 
respectively.

In result, any wars fail to deploy.

I suggest to change the links to point to asm.jar and asm-commons.jar, which 
are themselves softlinks to the currently installed versions.

Best regards,
Andreas.



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

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

Versions of packages libjetty8-extra-java depends on:
ii  libasm-java   5.1-1
ii  libjakarta-taglibs-standard-java  1.1.2-4
ii  libjetty8-java8.1.19-2
ii  libjstl1.1-java   1.1.2-4
ii  libmail-java  1.5.5-1
ii  libservlet3.0-java7.0.69-1
ii  libtomcat7-java   7.0.69-1

libjetty8-extra-java recommends no packages.

Versions of packages libjetty8-extra-java suggests:
ii  jetty8  8.1.19-2

-- no debconf information

Bug#826252: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Re: Bug#826252: virtualbox: VM hangs when switching to graphical mode, locking up the VirtualBox GUI for all VMs)

[Boylan, Ross]

Everything was working with this kernel and version of VirtualBox; I  think the 
only changes since then have been security updates.

The host is not on jessie but wheezy and so the most recent virtualbox on 
backports is 4.3, which I'm running.

Finally, is VB 5 a drop in replacement  for 4, in that all my VMs should just 
work?

Thanks.
Ross

From: Debian Bug Tracking System [ow...@bugs.debian.org]
Sent: Friday, June 03, 2016 10:45 AM
To: Boylan, Ross
Subject: Bug#826252 closed by Gianfranco Costamagna  
(Re: Bug#826252: virtualbox: VM hangs when switching to graphical mode, locking 
up the VirtualBox GUI for all VMs)

This is an automatic notification regarding your Bug report
which was filed against the virtualbox package:

#826252: virtualbox: VM hangs when switching to graphical mode, locking up the 
VirtualBox GUI for all VMs

It has been closed by Gianfranco Costamagna .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Gianfranco Costamagna 
 by
replying to this email.


--
826252: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826252
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#826263: libcork: FTBFS on non-Linux: Unknown endianness

[Aaron M. Ucko]

Source: libcork
Version: 0.15.0+ds-1
Severity: important
Justification: fails to build from source

Builds of libcork on kFreeBSD failed with the errors

  /«BUILDDIR»/libcork-0.15.0+ds/include/libcork/core/byte-order.h:46:2: error: 
#error "Unknown endianness"
   #error "Unknown endianness"
^
  /«BUILDDIR»/libcork-0.15.0+ds/include/libcork/core/hash.h: In function 
'cork_stable_hash_buffer':
  /«BUILDDIR»/libcork-0.15.0+ds/include/libcork/core/byte-order.h:176:44: 
error: implicit declaration of function 'CORK_UINT32_LITTLE_TO_HOST' 
[-Werror=implicit-function-declaration]
   #define CORK_UINT32_HOST_TO_LITTLE(__u32)  CORK_UINT32_LITTLE_TO_HOST(__u32)
  ^
  /«BUILDDIR»/libcork-0.15.0+ds/include/libcork/core/hash.h:90:24: note: in 
expansion of macro 'CORK_UINT32_HOST_TO_LITTLE'
   uint32_t  k1 = CORK_UINT32_HOST_TO_LITTLE(*curr);
  ^

I strongly suspect the Hurd build will fail in the same fashion.

Could you please take a look?

Thanks!

Bug#826262: libcork: FTBFS: Unexpected hash value 0xac7d28cc (64-bit BE)

[Aaron M. Ucko]

Source: libcork
Version: 0.15.0+ds-1
Severity: important
Justification: fails to build from source

Builds of libcork on 64-bit big-endian platforms (s390x and ppc64, so
far) have failed with the test suite error

  /«BUILDDIR»/libcork-0.15.0+ds/tests/test-core.c:341:F:hash:test_hash:0: 
Unexpected hash value 0xac7d28cc (expected 0x74bde19d)

Could you please take a look?

Thanks!

Bug#826173: Debian Testing/Unstable MIPS Installer Kernel Panic

[Mike]

I've discovered that the corresponding mipsel testing and development
releases work fine. Its only the mips testing and development versions.
On Jun 3, 2016 2:18 PM, "Ben Hutchings"  wrote:

> On Fri, 2016-06-03 at 14:07 -0400, Mike wrote:
> > I set the memory to 1024. I can try higher if need be.
>
> That should be more than enough.
>
> Ben.
>
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>

Bug#826173: Debian Testing/Unstable MIPS Installer Kernel Panic

[Ben Hutchings]

On Fri, 2016-06-03 at 14:07 -0400, Mike wrote:
> I set the memory to 1024. I can try higher if need be.

That should be more than enough.

Ben.

--
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.


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

Bug#825895: [Pkg-octave-devel] Bug#825895: octave-interval: FTBFS: debian/rules:10: *** target file 'install-docs' has both : and :: entries. Stop.

[Rafael Laboissière]

* Sébastien Villemot  [2016-05-31 10:45]:


Le mardi 31 mai 2016 à 10:34 +0200, Oliver Heimlich a écrit :

On 31.05.2016 10:11, Chris Lamb wrote:

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

Dear Maintainer,

octave-interval fails to build from source in unstable/amd64:


This is caused by the new version of octave-pkg-dev in unstable and gets 
fixed by Rafael's last commit (58eb05c71b08bd57b5141ab49574745d0577d323).


How urgent is it to upload a new version of octave-interval to unstable? 
Version 1.5.0 is already on its way, but I would like to wait until the 
release is approved upstream.


It's a bug of severity serious, so I'd say it's rather urgent. And the 
fix is trivial. But of course it can wait a few days.


So it's up to you to decide whether uploading 1.4.1-2 or 1.5.0-1.


This is partly my fault.  I should have coordinated the releases of 
octave-pkg-dev 1.4.0 and octave-interval 1.4.1-2.  At any rate, I think 
this problem will be fixed soon.


Rafael

Bug#825937: [Pkg-sysvinit-devel] Bug#825937: sysvinit-utils: Please drop startpar dependency

[Martin Pitt]

Steve Langasek [2016-06-03 10:41 -0700]:
> On Fri, Jun 03, 2016 at 12:12:43PM +0200, Martin Pitt wrote:
> > In Ubuntu we never supported startpar (it's incompatible with upstart)
> 
> It's not incompatible with upstart; this was implemented years ago.

startpar doesn't work with upstart "task" jobs. I don't remember the
details any more, but we had to disable it in
https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu15
as it caused boot lockups.

Anyway, the message to take here was "not installing startpar doesn't
cause any apparent problems".

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#826261: caja: rename problem

[Max]

Package: caja
Version: 1.14.1-1
Severity: normal

Hello,
I can rename files only on first column, other column doesn't work.
Thanks

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

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

Versions of packages caja depends on:
ii  caja-common   1.14.1-1
ii  desktop-file-utils0.22-1
ii  gvfs  1.28.2-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-9
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcaja-extension11.14.1-1
ii  libexempi32.3.0-2
ii  libexif12 0.6.21-2
ii  libgail-3-0   3.20.5-4
ii  libgdk-pixbuf2.0-02.32.3-2
ii  libglib2.0-0  2.48.1-1
ii  libglib2.0-data   2.48.1-1
ii  libgtk-3-03.20.5-4
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.14.1-1
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libselinux1   2.5-3
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrender1   1:0.9.9-2
ii  mate-desktop  1.14.1-1
ii  shared-mime-info  1.6-1

Versions of packages caja recommends:
ii  gvfs-backends  1.28.2-1

Versions of packages caja suggests:
ii  engrampa1.14.1-1
ii  gstreamer1.0-tools  1.8.1-1
ii  meld3.16.0-1

-- no debconf information

Bug#826173: Debian Testing/Unstable MIPS Installer Kernel Panic

[Mike]

I set the memory to 1024. I can try higher if need be.
On Jun 3, 2016 2:04 PM, "Ben Hutchings"  wrote:

> On Fri, 2016-06-03 at 19:03 +0100, Ben Hutchings wrote:
> > Control: reassign -1 debian-installer 20160516+b1
> >
> > On Fri, 2016-06-03 at 08:48 +, Mattia Rizzolo wrote:
> > > control: reassign -1 src:linux  4.5.4-1
> > >
> > > On Thu, Jun 02, 2016 at 07:13:04PM -0400, Mike wrote:
> > > > Package: kernel
> > >
> > > this is not a valid package name.
> > >
> > > > Version: Testing
> > >
> > > and this is not a valid version
> > >
> > > >
> > > > I am working on installing Debian under a QEMU MIPS emulator. I was
> able to
> > > > get the Debian Stable branch to install and run properly using this:
> > > >
> > > >
> http://ftp.de.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/
> > > >
> > > > However, when I attempt to use unstable or testing, I receive a
> kernel
> > > > panic immediately on boot for install. I cannot really give a
> package name
> > > > because it appears there's a problem in the kernel or init somewhere.
> > > >
> > > >
> http://ftp.de.debian.org/debian/dists/unstable/main/installer-mips/current/images/malta/netboot/
> > > >
> > > > The error I get it as follows:
> > > > [2.463767] Kernel panic - not syncing: Attempted to kill init!
> > > > exitcode=0x0004
> > > > [2.463767]
> > > > [2.464725] ---[ end Kernel panic - not syncing: Attempted to
> kill init!
> > > > exitcode=0x0004
> >
> > That usually means something is wrong with the initrd.  So reassigning
> > to the installer.
>
> *Or* the VM is too small for the kernel to even unpack the initrd.   I
> think that may be true with the default QEMU memory size now.
>
> Ben.
>
> > Ben.
> >
> > > > At no point do I get to a location in the installer for me to
> interact with.
> > > >
> > > > Best,
> > > >
> > > > Mike
> > >
> > Ben Hutchings
> > Nothing is ever a complete failure; it can always serve as a bad
> > example.
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>