Bug#792545: python-setuptools: Newer upstream release required for python-mock (>= 17.1)

[Michael Fladischer]

Package: python-setuptools
Version: 17.0-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

python-mock-1.1.3 requires a newer release of setuptools than is currently
available in the Debian archive. It would be great if you could package the
latest setuptools release 18.0.1 and upload it to unstable.

Cheers,
Michael

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

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

Versions of packages python-setuptools depends on:
ii  python-pkg-resources  17.0-1
pn  python:any

python-setuptools recommends no packages.

python-setuptools suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVp1IPAAoJEGlMre9Rx7W2GhgP/iFgScf8Vw4K8hoEbSsLqPaa
xpJVOrT2UNcWejx8SN9UnIWWW3m4caoCJWqKcn3cSSNa632Xi+ortMDO00vZhfFU
VS4J8HAN/+rSP4O1g4G4NRAibRqzjf1PNeXQhiXaY6hENfYTcrK1CcTlB7UbAM3E
rbBFUO4Zx2I5whtbep2WU66+4fUndTiEkEYmcIdNidPeklYHcADOD8BMPB2+waHi
NShRHV3E+r6vJ7U6+GuTkNl707bXJGILkBnvY6NouiZkc9S1Hl4bgOnPthG8u7Ux
RHtUAjbzXsvkfmN6RVqKQj1ARhYxjQN59qob7fOJTSW5d+L84amkO+38JNOKF8xt
Nnh5xTRYwNtAl2bqrvNI8+bgArodnAsL+zdQ2P4AiG3c6dXX2TVbW3DxyoyQTSpx
lkis/e2vmiz+sx+jJfJvnjgi6ZZPxUO+RAqsFFCR6a2Dk6BkfQLFs163cdiBQZmy
0zlV3HNwCTTqp7i9aDxgKQxbfdcZfNDXQDOwAPyEO8Jlqa59eQTgg7kkGTeOOrra
WfyqOFJS8z4Y6nova66r0wJU+59sI0ccfy5adh54sAzBsmDxvD8XEAiueK1Lxvfd
6gHS9QK5MPlRbwLm8RDLbA/dr3TrEDLhZJmea3vhKgE4oT40x7yZvPwBIxpujiBN
ZY/GkClVDO10gfAdcGXw
=zwad
-END PGP SIGNATURE-


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

Bug#789786: jessie-pu: package ejabberd/14.07-4+deb8u2

[Cyril Brulebois]

Control: tag -1 confirmed

Philipp Huebner  (2015-07-16):
> On 15.07.2015 17:52, Adam D. Barratt wrote:
> > On Wed, 2015-07-15 at 15:24 +0200, Cyril Brulebois wrote:
> >> I'm not going to pretend I read erlang, but patches look OK, and I've
> >> just got some feedback w/o then w/ this update, and it seems things are
> >> getting better with it, so I'm tempted to give you a green light here.
> >>
> >> Adam, I don't think you'd have any objections?
> > 
> > Nope. I only queried the logrotate change as it wasn't immediately
> > obviously correct, but the rest looked sane enough (admittedly also as
> > someone who doesn't read erlang).
> 
> 
> So I can go ahead with the upload then?

Looks like a yes. Please ao ahead. :)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#777916: Fix for ioapps gcc5 build failures

[Ritesh Raj Sarraf]

On Thursday 16 July 2015 08:29 AM, Potter, Tim (Cloud Services) wrote:
> tags 777916 + patch
> thanks
>
> Hi there.  Here’s a quick patch to fix the gcc5 build failures for the ioapps 
> package.  Since upstream appears to be unmaintained and doesn’t use autoconf 
> I’m proposing a patch to modify the Makefile directly.
>
> Patch is attached which appends “-std=gnu89” flag to the CFLAGS to address 
> the semantic change in the definition of inline functions in C11.

Hello Tim,

Thanks for the patch.  Upstream is active, just that he is slower than
usual in responding.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System




signature.asc
Description: OpenPGP digital signature

Bug#789786: jessie-pu: package ejabberd/14.07-4+deb8u2

[Philipp Huebner]

On 15.07.2015 17:52, Adam D. Barratt wrote:
> On Wed, 2015-07-15 at 15:24 +0200, Cyril Brulebois wrote:
>> I'm not going to pretend I read erlang, but patches look OK, and I've
>> just got some feedback w/o then w/ this update, and it seems things are
>> getting better with it, so I'm tempted to give you a green light here.
>>
>> Adam, I don't think you'd have any objections?
> 
> Nope. I only queried the logrotate change as it wasn't immediately
> obviously correct, but the rest looked sane enough (admittedly also as
> someone who doesn't read erlang).


So I can go ahead with the upload then?


Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#792148: ejabberd: why is ejabberdctl.cfg moved to /etc/default/ejabberd

[Philipp Huebner]

Hi,

being the only active maintainer of ejabberd in Debian for almost 2
years, my decision stands: I won't change this back.

If you don't want to divert from upstream, you shouldn't use this
package at all. Although I brought it much closer to upstream, it still
diverts in quite a few ways.

Now, you can either accept that and let it go, or ask the Debian
Technical Committee to override my decision.

The latter would probably lead to me stopping all my work on ejabberd
and it's erlang dependencies. I do this work completely voluntarily and
frankly, you're getting on my nerves.

If you like to do things differently, nobody's stopping you to do it
yourself as you please.


Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#777857: fsvs: ftbfs with GCC-5

[Potter, Tim (Cloud Services)]

On Thu, 12 Feb 2015 12:05:00 +0100 Philipp Marek  wrote:
> (errors) fixed in r2472, builds with GCC 5.

Hi Phillip.  I noticed that you committed this fix to the branches/fsvs-1.2.x 
but haven’t released a new version of fsvs containing it. 

Would you be interested in cutting a 1.2.6 release containing just the gcc5 
fix?  I can get it uploaded to Debian as a NMU and this bug closed out.


Regards,

Tim.

smime.p7s
Description: S/MIME cryptographic signature

Bug#777856: FTBFS appears to be fixed in freetype 2.5.2-3 or 2.5.2-4

[Potter, Tim (Cloud Services)]

Hi Steve.  Looks like this bug is no longer reproducible in one of the previous 
two uploads that Keith made.

I wasn’t able to reproduce on my gcc5 test system so was wondering if you could 
close out this bug.


Regards,

Tim.

smime.p7s
Description: S/MIME cryptographic signature

Bug#792530: closed by Donald Norwood (Re: mirrors: mirror submission for debian.redparra.com)

[Luis Miguel Parra]

Hi,

I see that the server is now in the list but just one details, loosk like
the architecture in the list are "amd64 armel"  and must be "amd64 i386"
 could you please correct it?

Thanks!

LuisMi



2015-07-15 21:03 GMT+02:00 Debian Bug Tracking System :

> This is an automatic notification regarding your Bug report
> which was filed against the mirrors package:
>
> #792530: mirrors: mirror submission for debian.redparra.com
>
> It has been closed by Donald Norwood .
>
> 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 Donald Norwood <
> dnorw...@portalus.com> by
> replying to this email.
>
>
> --
> 792530: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792530
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Mensaje reenviado --
> From: Donald Norwood 
> To: 792530-d...@bugs.debian.org
> Cc:
> Date: Wed, 15 Jul 2015 15:00:03 -0400
> Subject: Re: mirrors: mirror submission for debian.redparra.com
> Hi Luis,
>
> Thank you for your patience, your mirror and corrections have been added
> to the official mirror listing.
> The entry will show in a few hours.
>
>
> On Wed, 15 Jul 2015 14:50:21 -0400 Donald Norwood
>  wrote:
> > Package: mirrors
> > Severity: wishlist
> >
> >
> > Hi again Donald,
> >
> > I see that my request is still on validating process so I would like
> to change the
> > Archive-architecture just to amd64 i386.
> >
> > The reason for this change is that I see most of needed relays (based
> in bandwidth and use)
> > are just for this 2 architectures and I think I will be able to offer
> a better service I I
> > offer just this 2 architectures.
> >
> > So do you want me to raise a new request or can you modify it?
> >
> > Thanks
> >
> > Luis Miguel Parra
> >
>
> Best regards,
>
> Donald Norwood
>
>
>
> -- Mensaje reenviado --
> From: Donald Norwood 
> To: Debian Bug Tracking System 
> Cc:
> Date: Wed, 15 Jul 2015 14:50:21 -0400
> Subject: mirrors: mirror submission for debian.redparra.com
> Package: mirrors
> Severity: wishlist
>
>
> Hi again Donald,
>
> I see that my request is still on validating process so I would like to
> change the
> Archive-architecture just to amd64 i386.
>
> The reason for this change is that I see most of needed relays (based in
> bandwidth and use)
> are just for this 2 architectures and I think I will be able to offer a
> better service I I
> offer just this 2 architectures.
>
> So do you want me to raise a new request or can you modify it?
>
> Thanks
>
> Luis Miguel Parra
>
>
> 2015-07-07 0:16 GMT+02:00 Luis Miguel Parra :
>
> Hi,
>
> I think the problem is solved now,
>
> I need to change the Archive-upstream:to ftp.fr.debian.org
>
>
> Please let me know if you see any other issue.
>
> Thanks
>
> Luis Miguel Parra
>
> 2015-07-06 13:43 GMT+02:00 Luis Miguel Parra :
>
> Hi,
>
> Thanks for your answer I am sorry my bad! The problem was I thought my
> master server had "all" and looks like
> just have the "amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
> kfreebsd-i386" I am working to get
> this fixed asap and I will answer you again. :)
>
>
> Luis Miguel Parra
> Redparra Administrator
>
>
> 2015-07-01 20:15 GMT+02:00 Donald Norwood :
>
> tag -1 +moreinfo
>
> Hi,
>
> Thank you for your support and mirroring Debian.
>
> In checking your mirror there is a discrepancy between the archives in
> your submission and those served in your directory:
>
> Submission: All
> Server: amd64, armel, hurd, i386, ia64,  kfreebsd-amd64, and  kfreebsd-i386
>
> Could you please check your configuration?
>
> On 06/20/2015 10:07 AM, Luis Miguel Parra wrote:
> > Submission-Type: new
> > Site: debian.redparra.com
> > Aliases: mirrors.redparra.com
> > Type: leaf
> > Archive-architecture: ALL amd64 armel armhf hurd-i386 i386
> kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc
> > Archive-http: /debian/
> > IPv6: no
> > Archive-upstream: ftp.es.debian.org
> > Updates: once
> > Maintainer: Luis Miguel Parra 
> > Country: ES Spain
> > Location: España, Madrid
> > Sponsor: Redparra Networks http://www.redparra.com
> > Comment: Server status: http://status.redparra.com
> >  Server bandwidth: 200Mbps
> >
> >
> Best regards,
>
> Donald Norwood
>
>

Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Sebastiaan Couwenberg]

On 07/16/2015 12:45 AM, Jérémy Lal wrote:
> 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg :
> 
>> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
>>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
>>>
 On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
>> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
>>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort >> :
>>>
 (Moving the discussion to #788533; #756867 bcc'ed)

 On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
> The mips* FTBFS are a recurring problem for the mapnik package,
>> previous
> builds were no different. I'll try to get it to build on a
>> porterbox,
> but I expect intervention from the buildd admins will be required
 like
> last time to make sure only the buildds with the most resources try
 to
> build mapnik.
>
> See: https://bugs.debian.org/742149
>  https://bugs.debian.org/729121

 I'm not sure there are buildds with more RAM. Note that the package
>> failed
 in
 the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of
 swap.
 Since
 all these arches are 32bits, more memory is probably not going to
 help.

 Instead, perhaps you can make the build take less memory, e.g. by
>> reducing
 the
 optimizations (-O1?) or using some flags such as the linker's
 --no-keep-memory.
>>>
>>>
>>> Mapnik 2.2 used to pass builds with some of those options, also with
>>> removing
>>> -ftemplate-depth-300.
>>> That last option i restored with mapnik 3.0, to see what would happen
>> with
>>> upstream options,
>>> since so much has changed in that project.
>>> I'm preparing now an upload with that option removed.
>>
>> The new uploaded didn't resolve the build failures, it still failed on
>> {hurd,kfreebsd}-i386 & mips*.
>>
>> Since it's a recurring problem on mips*, maybe exclude these
>> architectures and request removal of the package on mips*.
>
> I've requested removal of the old mapnik 2.2 libs on the three
 architectures
> where it fails. I've been told that's the only thing needed to allow
> migration to testing.
> https://bugs.debian.org/789720

 The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same
 archs again. I've just pushed a change to exclude mips* from the list of
 architectures that will prevent them from building mapnik.

 mapnik still can't migrate because the old python-mapnik binaries
 (#790043) and the outstanding RC bugs.

 https://release.debian.org/migration/testing.pl?package=mapnik

 I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to
 get the mips* exclusion and static libraries for the python-mapnik build
 into the archive. After that we can request removal of the mapnik
 package for mips & mipsel.

 Jérémy, do you have anything you want to add before the upload?

>>>
>>> ok for python-mapnik (and the transition package python-mapnik2)
>>>
>>> As far as i understand, you just need
>>> Architecture: any
>>> and removal of the previous 2.2 versions on mips and mipsel that were in
>>> testing
>>> to get mapnik to go in testing on other architectures again.
>>> That is already done...
>>
>> So do you want to revert the Architecture change?
>>
>>
> Yes.
> Unless someone explains how i'm wrong, of course :)

Failing to build on a release architecture is generally an RC bug, which
prevents testing migration.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Bug#792487: vpnc-scripts: Improve dependencies

[Mike Miller]

On Wed, Jul 15, 2015 at 12:12:53 +0200, Andreas Henriksson wrote:
> The upstream scripts already seems to always prefer iproute2 over
> net-tools. For basic functionality it can fall back on net-tools when
> lacking iproute2.

Ack. To fully document here, the commands used from net-tools are
ifconfig, netstat, and route.

> Please consider applying the attached patch.

LGTM, thanks for investigating and providing a patch, will apply to the
next upload.

-- 
mike


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

Bug#791869: 2.02.122-2 breaks booting, mounting LVs other than / fails

[Achim Schaefer]

Package: lvm2
Version: 2.02.122-2
Followup-For: Bug #791869

Dear Maintainer,

just to confirm, this bug is still in the latest version

Regards

Achim

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.99-2
ii  dmsetup   2:1.02.99-2
ii  init-system-helpers   1.23
ii  initscripts   2.88dsf-59.2
ii  libc6 2.19-19
ii  libdevmapper-event1.02.1  2:1.02.99-2
ii  libdevmapper1.02.12:1.02.99-2
ii  liblvm2app2.2 2.02.122-2
ii  libreadline5  5.2+dfsg-3
ii  libudev1  222-2
ii  lsb-base  4.1+Debian13+nmu1

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  

-- Configuration Files:
/etc/lvm/lvm.conf changed:
config {
# Configuration option config/checks.
# If enabled, any LVM configuration mismatch is reported.
# This implies checking that the configuration key is understood
# by LVM and that the value of the key is the proper type.
# If disabled, any configuration mismatch is ignored and the default
# value is used without any warning (a message about the
# configuration key not being found is issued in verbose mode only).
checks = 1
# Configuration option config/abort_on_errors.
# Abort the LVM process if a configuration mismatch is found.
abort_on_errors = 0
# Configuration option config/profile_dir.
# Directory where LVM looks for configuration profiles.
profile_dir = "/etc/lvm/profile"
}
devices {
# Configuration option devices/dir.
# Directory in which to create volume group device nodes.
# Commands also accept this as a prefix on volume group names.
# This configuration option is advanced.
dir = "/dev"
# Configuration option devices/scan.
# Directories containing device nodes to use with LVM.
# This configuration option is advanced.
scan = [ "/dev" ]
# Configuration option devices/obtain_device_list_from_udev.
# Obtain the list of available devices from udev.
# This avoids opening or using any inapplicable non-block
# devices or subdirectories found in the udev directory.
# Any device node or symlink not managed by udev in the udev
# directory is ignored. This setting applies only to the
# udev-managed device directory; other directories will be
# scanned fully. LVM needs to be compiled with udev support
# for this setting to apply.
obtain_device_list_from_udev = 1
# Configuration option devices/external_device_info_source.
# Select an external device information source.
# Some information may already be available in the system and
# LVM can use this information to determine the exact type
# or use of devices it processes. Using an existing external
# device information source can speed up device processing
# as LVM does not need to run its own native routines to acquire
# this information. For example, this information is used to
# drive LVM filtering like MD component detection, multipath
# component detection, partition detection and others.
# Possible options are: none, udev.
# none - No external device information source is used.
# udev - Reuse existing udev database records. Applicable
# only if LVM is compiled with udev support.
external_device_info_source = "none"
# Configuration option devices/preferred_names.
# Select which path name to display for a block device.
# If multiple path names exist for a block device,
# and LVM needs to display a name for the device,
# the path names are matched against each item in
# this list of regular expressions. The first match is used.
# Try to avoid using undescriptive /dev/dm-N names, if present.
# If no preferred name matches, or if preferred_names are not
# defined, built-in rules are used until one produces a preference.
# Rule 1 checks path prefixes and gives preference in this order:
# /dev/mapper, /dev/disk, /dev/dm-*, /dev/block (/dev from devices/dev)
# Rule 2 prefers the path with the least slashes.
# Rule 3 prefers a symlink.
# Rule 4 prefers the path with least value in lexicographical order.
# Example:
# preferred_names = [ "^/dev/mpath

Bug#776964: Headers installed by zsh-dev packages miss critical pieces

[ZyX]

04.02.2015, 07:49, "ZyX" :
> 04.02.2015, 01:58, "Frank Terbeck" :
>>  Hey there!
>>
>>  ZyX wrote:
>>  [...]
>>>   To use zsh headers in some module at least `config.h` file is needed
>>
>>  Finally, someone who actually wants to use zsh's facilities to load
>>  third party modules. Yay. ;)
>>>   in addition to those already present in the package. `config.h` files
>>>   contains defines guessed by ./configure script and including it prior
>>>   to `zsh.h` is the only sane variant to include `zsh.h` (insane variant
>>>   is using module’s own configure script which will create those
>>>   defines). Without `config.h` including `zsh.h` will fail due to
>>>   missing defines, and even if it was not failing it would make #include
>>>    do the wrong thing because of the bits like
>>
>>  [...]
>>
>>  I agree.
>>>   (configure.h-driven definition of zlong and zulong which has the 
>>> potential of breaking ABI compatibility in some cases).
>>>
>>>   In addition to this file it is good to have a patched `zsh.mdh` file
>>>   which glues together all zsh includes and is a single entry point.
>>>   Patch needed to include this file in the distribution may be performed
>>>   with the following script:
>>>
>>>   for file in Src/{zsh.mdh,*.h} ; do
>>
>>  We'd probably want to do that in a POSIX compatible way, so we'd refrain
>>  from using brace expansion but that's just cosmetics.
>>>   sed -i 's@\.\./config\.h@config.h@' "$file"
>>>   sed -i 's@#\(\s*\)include "\([^"]\+\)"@#\1include 
>>> @' "$file"
>>
>>  Sed's -i option requires GNU sed. But then, I don't know if debian even
>>  ships another version of sed. ...I think it doesn't; but I also don't
>>  know about the policy with respect to non-POSIX features in packaging.
>>>   done
>>>
>>>   . I am doing this in a Gentoo ebuild and the result works just fine.
>>
>>  Yeah, I think this could work.
>>
>>  Do you think it would make sense to include the other header files with
>>  zsh-dev as well? Like "zshterm.h" etc?
>
> In my ebuild I am simply doins all *.h files from Src, passed throught these
> filters, so zshterm.h gets caught as well. But I think that all of them are
> #included by zsh.mdh, at least zshterm.h does (zsh.mdh includes zsh_system.h
> and that includes zshterm.h). Did not know you do not do the same thing (I
> mean, adding Src/*.h).
>
>>  Regards, Frank

Any progress on this? Gentoo have fixed their instance of the similar bug.


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

Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java

[Mike Miller]

On Wed, Jul 15, 2015 at 08:59:32 -0400, Mike Miller wrote:
> On Wed, Jul 15, 2015 at 10:00:33 +0200, Alois Schloegl wrote:
> > Octave should not have a strong dependency on openjdk. Any of the
> > following solutions would do:
> > 1) the dependency should be changed to "recommended", and/or
> > 2) it should allow for some alternative java engine (e.g. gcj or
> > whatever). (see also [4] ),
> > 3) keeping the java dependency in a octave package "octave-java" as it
> > was before 3.8.x
> 
> Before #1 or #3 are feasible, some upstream work will need to be done to
> allow Octave to detect the (presence of / version of / path to) JRE at
> runtime. Please see upstream bug #40111.

Minor clarification: currently, when Octave is compiled with Java
support but the JRE is not actually present, the error is handled and
reported:

  octave:1> javaMethod ("getRuntime", "java.lang.Runtime")
  error: javaMethod: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: failed to 
load: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: cannot 
open shared object file: No such file or directory
  octave:2> 

So Octave does handle this to some degree. The error reporting is not
ideal and could be improved as part of #40111. But it does look feasible
to be able to run Octave without a JRE. Users who opt out of installing
default-jre-headless will see errors like the above if they try to use
java functions, or functions that rely on java such as those in the
octave-io package.

Thoughts?

-- 
mike


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

Bug#792544: ping6: error while loading shared libraries: libnettle.so.4

[Brian Minton]

Package: iputils-ping
Version: 3:20121221-5+b2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

   When trying to verify ipv6 connectivity, I encounter the following
   error trying to start ping6:

   $ ping6 google.com
   ping6: error while loading shared libraries: libnettle.so.4: cannot
   open shared object file: No such file or directory


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

Kernel: Linux 4.0.0 (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 iputils-ping depends on:
ii  libc62.19-18
ii  libcap2  1:2.24-9
ii  libgnutls-openssl27  3.3.15-7

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.24-9

iputils-ping suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlWnNfUACgkQa46zoGXPuqkLJwD+Psjxarsife274SlV1dO+24dk
ac47V/Kcx8H3KL3iEc4A/j/SiOPytNOrAJNY9ohnvXCswidBL1j0dSbYi0f/3FzV
=IeQ9
-END PGP SIGNATURE-


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

Bug#777917: Fix for ipgrab FTBFS error with gcc5

[Potter, Tim (Cloud Services)]

tags 777917 + patch
thanks

Hi there.  Here’s a small patch to fix the FTBS with gcc5.  It simply adds 
-std=gnu89 to CFLAGS in debian/rules which is picked up by autoconf.


Regards,

Tim.


777917-gcc5-fixes.patch
Description: Binary data
 

smime.p7s
Description: S/MIME cryptographic signature

Bug#792540: Wifi netinstall fails with flashing screen on Lenovo X220

[Cyril Brulebois]

Control: tag -1 - d-i

Hi,

W. Martin Borgert  (2015-07-16):
> I tried to install Jessie on a Lenovo X220 using netinst on USB
> flash drive, without Ethernet connection, but with the non-free
> iwlwifi drivers .deb on an SD card (either internal slot or USB
> adaptor).
> 
> After the very early step of selecting the keyboard layout, the
> installer seems to try to start X or something, but seems to fail.

Are you using the text mode installer or the graphical installer?
There's no X in the former, and X is started at the very beginning
(after syslinux prompt, but before any questions are asked) in the
latter.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#792543: ITP: javawriter -- utility class which aids in generating Java source files.

[Komal Sukhani]

Package: wnpp
Severity: wishlist
Owner: Komal Sukhani 

* Package name: javawriter
  Version : 2.5.1
  Upstream Author : Jesse Wilson
* URL : http://github.com/square/javawriter/
* License : Apache-2.0
  Programming Lang: Java
  Description : utility class which aids in generating Java source files.

  This is dependency of Android Gradle Plugin on which I am currently working.

Bug#792443: RFS: mirage/0.9.5.1-4 [QA]

[lucas castro]

All right now. Uploaded to mentors,

On Tue, Jul 14, 2015 at 10:05 PM, Eriberto Mota  wrote:

> tags 792443 moreinfo
> thanks
>
>
> Hi Lucas,
>
> I will try help you. My considerations:
>
> 1. I can see some changes not registered in d/changelog. An example of
> this is DH level change (from 7 to 9). I used the 'debdiff' command to
> see the changes. Other files: debian/mirage.postinst,
> debian/patches/remove_gimp_remote.patch, debian/pycompat
>
> 2. d/changelog:
>
> - I suggest you to organize better the ideas. Try to use a logical
> order. You can sort the itens by events (Added, Changed, Removed,
> Updated, etc) or by main events followed by files (debian/control,
> debian/copyright, etc). For the latter case, you can see an example
> here[1].
>
> - Please, remove the unnecessary double spaces.
>
> - Use debian/ for all files inside the debian/ directory, as
> debian/watch ans debian/patches/desktop_entry_issue.patch.
>
> - Use '$ spell changelog | sort -u' and '$ spell control | sort -u' to
> search for spelling errors, as 'Dependeces'.
>
> [1]
> http://metadata.ftp-master.debian.org/changelogs/main/l/lime-forensics/unstable_changelog
>
> 3. d/control: you found a new upstream homepage to use in d/watch. So,
> why you removed the Homepage field from d/control?
>
> 4. debian/copyright:
>
> - The "updated" notice in d/changelog is a bit generic because you did
> several modifications.
>
> - I found this text in upstream source code:
>
> mirage-Mirage is free software; you can redistribute it and/or modify
> mirage-it under the terms of the GNU General Public License as published by
> mirage-the Free Software Foundation; either version 3 of the License, or
> mirage-(at your option) any later version.
>
> mirage.py-Mirage is free software; you can redistribute it and/or modify
> mirage.py-it under the terms of the GNU General Public License as
> published by
> mirage.py-the Free Software Foundation; either version 3 of the License, or
> mirage.py-(at your option) any later version.
>
> So, the source code is GPL-3+, not GPL-3. You need to use the
> following command to check this situation:
>
> $ egrep -sriA25 '(copyright|public dom)' *
>
> - There are several authors in po/ directory.
>
> - You must to list all packagers in debian/* block. You can use the
> following command to search for all:
>
> $ egrep '(--|\[)' debian/changelog
>
> 5. d/watch: your configuration produces notices about invalid
> character in version number (two underscores).
>
> 6. You must always check the PTS[2] to search for bugs, tips etc. In
> bugs list I can see a relevant bug that you can close: #773997.
>
> [2] https://packages.qa.debian.org/m/mirage.html
>
> Thanks for your work.
>
> Regards,
>
> Eriberto
>
>
> 2015-07-14 17:09 GMT-03:00 Lucas Castro :
> > Package: sponsorship-requests
> > Severity: normal
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "mirage"
> >
> >This orphaned packages required some lintian corrections and I had
> done,
> >it already has two P lintians, but it is its homepage fields and
> signature
> >that I didn't found.
> >
> > * Package name: mirage
> >   Version : 0.9.5.1-4
> >   Upstream Author : [fill in name and email of upstream]
> >   * URL : [fill in URL of upstreams web site]
> >   * License : [fill in]
> >   Section : graphics
> >
> >   It builds those binary packages:
> >
> > mirage - fast and simple GTK+ image viewer
> >
> >   To access further information about this package, please visit the
> following URL:
> >
> >   http://mentors.debian.net/package/mirage
> >
> >   Alternatively, one can download the package with dget using this
> command:
> >
> > dget -x
> http://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.9.5.1-4.dsc
> >
> >   More information about hello can be obtained from
> http://www.example.com.
> >
> >   Changes since the last upload:
> >
> > * QA upload.
> > * Updated watch
> > * debian/control
> > - Bumped Standards-Version to 3.9.6
> > - Homepage removed
> > * debian/copyright updated
> > * Added desktop_entry_issue.patch: Avoid
> desktop-entry-lacks-keywords-entry.
> > * Build-Dependeces: added  dh-python.
> >
> > -- System Information:
> > Debian Release: 8.1
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> > Archive:
> https://lists.debian.org/20150714200940.16904.7.reportbug@debian
> >
>



-- 
contatos:
Celular: ( 99 ) 9143-5954 - Vivo
skype: lucasd3castro

Bug#777916: Fix for ioapps gcc5 build failures

[Potter, Tim (Cloud Services)]

tags 777916 + patch
thanks

Hi there.  Here’s a quick patch to fix the gcc5 build failures for the ioapps 
package.  Since upstream appears to be unmaintained and doesn’t use autoconf 
I’m proposing a patch to modify the Makefile directly.

Patch is attached which appends “-std=gnu89” flag to the CFLAGS to address the 
semantic change in the definition of inline functions in C11.


Regards,

Tim.



777916-gcc5-fixes.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

Bug#777910: Fix for gcc5 compile failure

[Potter, Tim (Cloud Services)]

tags 488159 + patch
thanks

Ironically, the code that checks for the C99 “restrict” keyword does not 
compile because “restrict” cannot be used as a variable name.  Attached is a 
patch that fixes this by renaming the local variable in this case.

The maintainer has signed up for LowThresholdNMU so I recommend that this 
package be NMU’d with this patch to close this bug.


Thanks,

Tim.


777910-gcc5-fixes.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

Bug#792148: ejabberd: why is ejabberdctl.cfg moved to /etc/default/ejabberd

[Christoph Anton Mitterer]

On Tue, 2015-07-14 at 07:24 +0200, Philipp Huebner wrote:
> No. It's changed already for Jessie which is fixed at this point in
> time,
Well there's always coming a next release.


>  I don't see any benefit in switching back with the next release.
What about
- not unnecessarily diverting from upstream
- placing config files into locations where it shouldn't be as per DP


> ejabberdctl serves as the actual init script for ejabberd, so IMO
> /etc/default/ejabberd is perfectly fine, especially if you look at
> what's configured inside: absolute basic settings like the location 
> of
> the pid-file or the location of the config-file.
As you can see from ejabberdctl.cfg, there's far more options in it
which go way beyond what configures the init script or even typical
start/stop behaviour of programs:
POLL, SMP, ERL_MAX_PORTS, FIREWALL_WINDOW, INET_DIST_INTERFACE,...
basically all options except perhaps:
EJABBERD_PID_PATH and EJABBERD_CONFIG_PATH

...are clearly non init related.
I wouldn't know a single package in Debian, where corresponding options
would be artificially moved to a new config file in /etc/default, when
the daemon itself already has a config file and well-known name where
these are handled.

And even PID file options are quite often in the daemon's native config
file (ssh, postgresql, and so on).


> Plus a symlink in /etc/default/ would probably confuse the hell out 
> of
> the config file handling.
Quite frankly said, nothing should be in /etc/default here.


I wouldn't see a single reason why the upstream config file with an
existing well-known name should be renamed here, and even less reason
why it should go to /etc/default.

ejabberdctl is also by far more than just the start/stop program, it's
the complete maintenance interface to ejabberd.
So the "justification" that ejabberdctl would be more or less equal to
the init script is simply wrong.


Don't get me wrong,... having that config file in a wrong location with
another name than upstream uses won't stop the world from turning...
there's just no good reason for it.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#787914: nano: new multi-edit detection segfaults when I say no

[Paul Wise]

On Tue, 2015-07-14 at 21:28 +0200, Benno Schulenberg wrote:

> One of the differences I see with a strace of mine is that you
> have extra calls to mprotect() in there.  What compiler does
> Debian use?  And what CFLAGS?

You can see the compiler commands used by clicking the Result column
for the architectures on this page.

https://buildd.debian.org/status/logs.php?pkg=nano

As the amd64 binaries are compiled on the package maintainer's machine,
the logs aren't available but the compiler commands should be the same.

Jordi, these days Debian supports almost-source-only uploads; you just
have to upload the arch all binary packages but not the amd64 ones. For
nano that means you only have to upload the source package.

> Can you reproduce this crash when you compile nano yourself?
> Or was it already self-compiled?

The original backtrace was reported with a version of nano from a
Debian binary package I built with disabling stripping debug symbols
from the Debian source package. I can still reproduce the problem with
the normal build from the Debian archive too.

> Oh, by the way: your nano reads several syntaxes twice.  You
> may wish to trim your ~/.nanorc or /etc/nanorc.  (This might
> even be at the base of the segfault.)

Thanks for the suggestion, done. Unfortunately still segfaults.

Interestingly if I run nano under valgrind it doesn't segfault but
there are definitely some coding problems; several uninitialised
values, memory leaks and reading into unaddressable bytes.

I'd strongly recommend running the latest cppcheck over the nano source
code. You could also run flawfinder and others. I would not want to
view a malicious file and have a flaw in nano result in arbitrary code
execution. I have a tool for running lots of check tools here:

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#792542: nmu: syslog-ng_3.6.1+git20141206-g4d90138-4

[Andreas Beckmann]

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

nmu syslog-ng_3.6.1+git20141206-g4d90138-4 . ALL . experimental . -m "Rebuild 
against libhiredis0.13"

hiredis transition, experimental side.


Andreas


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

Bug#777819: Partial fix for FTBFS error

[Thomas Pierson]

Hi Tim,

Le 30/06/2015 03:46, Potter, Tim (Cloud Services) a écrit :
> Hi there.  I’ve made a partial fix for building clementine under GCC5.  The 
> patch is attached and it’s a simple rearrangement of operands to prevent an 
> error/bug due to operator precedence.  The fix has already made it into the 
> master branch of upstream.

Thanks for your help. I work on this issue and I plan to make an upload
including your fix soon.

> This doesn’t completely fix the FTBFS though.  I had to rebuild libprotobuf 
> using GCC5 to allow linking using the new C++ ABI but that should fix itself 
> over time.  The latest problem is a link problem against 
> TagLib::String::String.
> This doesn’t look like an ABI problem and I don’t have a fix yet, but thought 
> I would post my work so far.

Your tagreader error seems related to protobuf too. I just rebuild
clementine with GCC-5 and protobuf rebuild with GCC-5 too and it seems
to works. But I have to install all the fresh protobuf packages and not
only libprotobuf9, maybe this is why you got this linking issue?

Regards,

Thomas Pierson



signature.asc
Description: OpenPGP digital signature

Bug#738758: [PATCH] ext4: optimize Hurd tests when reading/writing inodes

[Gabriele Giacone]

>From #hurd@freenode:

00:01 < gnu_srs> gg0: I wrote to Ted Tso about the ext4 bug and he
replied: Huh?  This patch (ext4: kill i_version support for
Hurd-castrated file
00:01 < gnu_srs> systems) landed upstream over a year ago, in Linux
3.15.  It is git commit c4f65706056e9f0c.

Just tested reproducer at https://bugs.debian.org/738758#5 with Jessie
3.16 kernel, fsck doesn't detect unexpected inconsistency anymore.

Has "ext4: optimize Hurd tests when reading/writing inodes" patch at
https://bugs.debian.org/738758#57 been applied too?
Any reason to keep it open?


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

Bug#789266: nouveau: unable to locate usable image (regression)

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=89047

There seems to be a fix, but available in 4.1 only, which has another
blocking problem (kernel hangs):

  https://bugs.freedesktop.org/show_bug.cgi?id=90626

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


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

Bug#717451: Backups broken when "ssh_args" are set

[Michel]

Package: rsnapshot
Version: 1.3.1-7
Followup-For: Bug #717451


Dear Maintainer,

After upgrading rsnapshot to 1.3.1-7, remote backups still fail. Local
backups work as expected. The upgrade occurred on 06/24/2015, and every
remote backup since then have failed. Have been extremely busy and have
not checked local email, until today. To my surprise, have no remote
backups since 06/24.

# rsnapshot -c /etc/rsnapshot/x220-rsnapshot.conf hourly

Unexpected remote arg: root@x220:/
rsync error: syntax or usage error (code 1) at main.c(1348)
[sender=3.1.1]

rsnapshot encountered an error! The program was invoked with these
options:
/usr/bin/rsnapshot -c /etc/rsnapshot/x220-rsnapshot.conf hourly

ERROR: /usr/bin/rsync returned 1 while processing root@x220:/


As before[0], downgrading to rsnapshot 1.3.1-3 and remote backups are
working again.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717451#17


Perhaps bug #786854 is related to this one?

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


Thank You


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

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

Versions of packages rsnapshot depends on:
ii  liblchown-perl  1.01-3
ii  logrotate   3.8.7-2
ii  perl5.20.2-6
ii  rsync   3.1.1-3

Versions of packages rsnapshot recommends:
ii  openssh-client [ssh-client]  1:6.7p1-6

rsnapshot suggests no packages.

-- no debconf information


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

Bug#792328: info: can no longer find the Emacs manual

[Norbert Preining]

Hi Gavin,

> Here's my attempt at making this work, which internally prefixes file
> paths with "./" when they truly are relative to the current directory
> and should not be looked up in the search path.

Looks fine to me.

What works is selecting the
emacs-24/emacs
node in the dir file (start plain info without args, then select
emacs-24/emacs).

What not works is doing
info emacs-24/emacs
on the command line

Let me know if I can test other things, and again thanks a lot!

Norbert


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



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

Bug#791879: Fwd: Re: Bug#791879: influxdb-python: Please package and upload version 2.6.0

[Alexandre Viau]

Hello Thomas,

> Well, I tried again to "git pull" from all branches, and I still don't
> have a tag for upstream 2.6.0:

Doh! I forgot to push the tag.

I have now pushed it.

Just in case - I have also uploaded the package to mentors (signed).

Links:
-
http://mentors.debian.net/debian/pool/main/i/influxdb-python/influxdb-python_2.6.0-1.dsc
- http://mentors.debian.net/package/influxdb-python

Thanks,

-- 
Alexandre Viau
alexan...@alexandreviau.net



signature.asc
Description: OpenPGP digital signature

Bug#510466: [PATCH v2] Currently, jobs run by at are run in the crond_t domain and not transitioned outside of it.

[Laurent Bigonville]

From: Laurent Bigonville 

With this patch, the jobs are transitioned in the same domain as the
jobs that are run by the cron daemon:

- When cron_userdomain_transition is set to off, a process for an
  unconfined user will transition to unconfined_cronjob_t. For confined
  user, the job is run as cronjob_t.

- When cron_userdomain_transition is set to on, the processes are run
  under the user default context.

This patch is based on Marcela Mašláňová  work
---
 Makefile.in  |  3 ++-
 atd.c| 87 
 config.h.in  |  3 +++
 configure.ac |  8 ++
 daemon.c | 16 +++
 daemon.h |  3 +++
 6 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/Makefile.in b/Makefile.in
index 5dd2767..2bddc13 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -40,6 +40,7 @@ LIBS  = @LIBS@
 LIBOBJS= @LIBOBJS@
 INSTALL= @INSTALL@
 PAMLIB  = @PAMLIB@
+SELINUXLIB  = @SELINUXLIB@
 
 CLONES = atq atrm
 ATOBJECTS  = at.o panic.o perm.o posixtm.o y.tab.o lex.yy.o
@@ -73,7 +74,7 @@ at: $(ATOBJECTS)
$(LN_S) -f at atrm
 
 atd: $(RUNOBJECTS)
-   $(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB)
+   $(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB) $(SELINUXLIB)
 
 y.tab.c y.tab.h: parsetime.y
$(YACC) -d parsetime.y
diff --git a/atd.c b/atd.c
index d0b422e..e70caf0 100644
--- a/atd.c
+++ b/atd.c
@@ -83,6 +83,12 @@
 #include "getloadavg.h"
 #endif
 
+#ifdef WITH_SELINUX
+#include 
+#include 
+int selinux_enabled = 0;
+#endif
+
 /* Macros */
 
 #define BATCH_INTERVAL_DEFAULT 60
@@ -195,6 +201,72 @@ myfork()
 #define fork myfork
 #endif
 
+#ifdef WITH_SELINUX
+static int
+set_selinux_context(const char *name, const char *filename) {
+security_context_t user_context = NULL;
+security_context_t file_context = NULL;
+int retval = 0;
+char *seuser = NULL;
+char *level = NULL;
+
+if (getseuserbyname(name, &seuser, &level) == 0) {
+retval = get_default_context_with_level(seuser, level, NULL, 
&user_context);
+free(seuser);
+free(level);
+if (retval < 0) {
+lerr("execle: couldn't get security context for user %s\n", name);
+retval = -1;
+goto err;
+}
+}
+
+/*
+ * Since crontab files are not directly executed,
+ * crond must ensure that the crontab file has
+ * a context that is appropriate for the context of
+ * the user cron job.  It performs an entrypoint
+ * permission check for this purpose.
+ */
+if (fgetfilecon(STDIN_FILENO, &file_context) < 0) {
+lerr("fgetfilecon FAILED %s", filename);
+retval = -1;
+goto err;
+}
+
+retval = selinux_check_access(user_context, file_context, "file", 
"entrypoint", NULL);
+freecon(file_context);
+if (retval < 0) {
+lerr("Not allowed to set exec context to %s for user  %s\n", 
user_context, name);
+retval = -1;
+goto err;
+}
+if (setexeccon(user_context) < 0) {
+lerr("Could not set exec context to %s for user  %s\n", user_context, 
name);
+retval = -1;
+goto err;
+}
+err:
+if (retval < 0 && security_getenforce() != 1)
+retval = 0;
+if (user_context)
+freecon(user_context);
+return retval;
+}
+
+static int
+selinux_log_callback (int type, const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+vsyslog (LOG_ERR, fmt, ap);
+va_end(ap);
+return 0;
+}
+
+#endif
+
 static void
 run_file(const char *filename, uid_t uid, gid_t gid)
 {
@@ -424,6 +496,13 @@ run_file(const char *filename, uid_t uid, gid_t gid)
 
nice((tolower((int) queue) - 'a' + 1) * 2);
 
+#ifdef WITH_SELINUX
+   if (selinux_enabled > 0) {
+   if (set_selinux_context(pentry->pw_name, filename) < 0)
+   perr("SELinux Failed to set context\n");
+   }
+#endif
+
if (initgroups(pentry->pw_name, pentry->pw_gid))
perr("Cannot initialize the supplementary group access list");
 
@@ -707,6 +786,14 @@ main(int argc, char *argv[])
 struct passwd *pwe;
 struct group *ge;
 
+#ifdef WITH_SELINUX
+selinux_enabled=is_selinux_enabled();
+
+if (selinux_enabled) {
+selinux_set_callback(SELINUX_CB_LOG, (union selinux_callback) 
selinux_log_callback);
+}
+#endif
+
 /* We don't need root privileges all the time; running under uid and gid
  * daemon is fine.
  */
diff --git a/config.h.in b/config.h.in
index 4d7dc91..681d68e 100644
--- a/config.h.in
+++ b/config.h.in
@@ -192,6 +192,9 @@
. */
 #undef UMAX4_3
 
+/* Define if you are building with_selinux */
+#undef WITH_SELINUX
+
 /* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a
`char[]'. */
 #undef YYTEXT_POINTER
diff --git a/configure.ac b/configure.ac
index f3d2e35..1f6494a 100644
--- a/configure.ac
+++ b/configure.ac
@@ 

Bug#792541: 502 Connection closed

[Carlos Maddela]

Package: apt-cacher-ng
Version: 0.8.4-1
Severity: important
Tags: patch
Control: found -1 apt-cacher-ng/0.8.2-1

Hello,

Often, when performing 'apt-get update' with apt-cacher-ng, it would
fail with lots of '502 Connection closed' errors, as shown in the attached
apt-cacher.err snippet.  I don't know why no one else has reported this yet,
but maybe it has something to do with slower internet connections.

I thought the bug may have been related to Bug #787289, so I tried different
PipelineDepth values, but it didn't change anything.

I did a bit of debugging and found that the problem first crops up after
this commit:

https://anonscm.debian.org/cgit/apt-cacher-ng/apt-cacher-ng.git/commit/?h=debian/sid&id=1716a7a94c0e6bfc0635f2aef6e281c10a30a96c

Without understanding the code entirely, I tried reverting some of the
changes that I thought were suspect, and it seemed to do the trick.
I have attached this patch.  Hopefully, it doesn't cause problems for others.

Best regards,

Carlos

-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.18.1
ii  init-system-helpers1.23
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.19-19
ii  libgcc11:5.1.1-13
ii  liblzma5   5.1.1alpha+20120614-2.1
ii  libssl1.0.01.0.2d-1
ii  libstdc++6 5.1.1-13
ii  libsystemd0222-1
ii  libwrap0   7.6.q-25
ii  zlib1g 1:1.2.8.dfsg-2+b1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.31-5
ii  doc-base  0.10.6
ii  libfuse2  2.9.4-1

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed [not included]
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
u'/etc/apt-cacher-ng/security.conf'
/etc/cron.daily/apt-cacher-ng [Errno 2] No such file or directory: 
u'/etc/cron.daily/apt-cacher-ng'

-- debconf information excluded
Sun Jul 12 16:04:11 2015|created socket, fd: 5
Sun Jul 12 16:04:11 2015|Not creating Unix Domain Socket, fifo_path not 
specified
Sun Jul 12 16:04:11 2015|Listening to incoming connections...
Sun Jul 12 16:05:02 2015|Detected incoming connection from the TCP socket
Sun Jul 12 16:05:02 2015|Client name: 192.168.0.1
Sun Jul 12 16:05:02 2015|Detected incoming connection from the TCP socket
Sun Jul 12 16:05:02 2015|Client name: 192.168.0.1
Sun Jul 12 16:05:02 2015|Detected incoming connection from the TCP socket
Sun Jul 12 16:05:02 2015|Client name: 192.168.0.1
Sun Jul 12 16:05:02 2015|Decoded request URI: 
http://ftp.debian.org/debian/dists/experimental/InRelease
Sun Jul 12 16:05:02 2015|Decoded request URI: 
http://www.deb-multimedia.org/dists/sid/InRelease
Sun Jul 12 16:05:02 2015|Decoded request URI: 
http://security.debian.org/dists/testing/updates/InRelease
Sun Jul 12 16:05:02 2015|Processing new job, GET 
http://ftp.debian.org/debian/dists/experimental/InRelease HTTP/1.1
Sun Jul 12 16:05:02 2015|Processing new job, GET 
http://www.deb-multimedia.org/dists/sid/InRelease HTTP/1.1
Sun Jul 12 16:05:02 2015|Processing new job, GET 
http://security.debian.org/dists/testing/updates/InRelease HTTP/1.1
Sun Jul 12 16:05:03 2015|Download started, storeHeader for 
security.debian.org/dists/testing/updates/InRelease, current status: 1
Sun Jul 12 16:05:03 2015|known data hit, don't write to: 
security.debian.org/dists/testing/updates/InRelease
Sun Jul 12 16:05:03 2015|Response header to be sent in the next cycle: 
HTTP/1.1 304 Not Modified
Content-Length: 0
Date: Sun Jul 12 06:05:03 2015
Server: Debian Apt-Cacher NG/0.8.4
X-Original-Source: http://security.debian.org/dists/testing/updates/InRelease
Connection: Keep-Alive


Sun Jul 12 16:05:03 2015|Returning to last state, 6
Sun Jul 12 16:05:03 2015|Download started, storeHeader for 
debmul/dists/sid/InRelease, current status: 1
Sun Jul 12 16:05:03 2015|known data hit, don't write to: 
debmul/dists/sid/InRelease
Sun Jul 12 16:05:03 2015|Response header to be sent in the next cycle: 
HTTP/1.1 304 Not Modified
Content-Length: 0
Date: Sun Jul 12 06:05:03 2015
Server: Debian Apt-Cacher NG/0.8.4
X-Original-Source: http://www.deb-multimedia.org/dists/sid/InRelease
Connection: Keep-Alive


Sun Jul 12 16:05:03 2015|Returning to last state, 6
Sun Jul 12 16:05:04 2015|Decoded request URI: 
http://security.debian.org/dists/testing/updates/main/source/Sources.xz
Sun Jul 12 16:05:04 2015|Processing new job, GET 
http://security.debian.org/dists/testing/updates/main/source/Sources.xz HTTP/1.1
Sun Jul 12 16:05

Bug#792538: vlc: When playing a video, screen gets black for a fraction of second every 30 seconds

[Vincent Lefevre]

Control: retitle -1 When a video is playing or paused, vlc execs 
"xdg-screensaver reset" every 30 seconds, flickering the screen

Thanks to strace, I've found the problem: vlc executes
"xdg-screensaver reset" every 30 seconds, which executes
"xset dpms force on", which flickers the screen.

Then, I wonder whether executing "xdg-screensaver reset" is the right
thing to do. "xdg-screensaver suspend ..." has the same problem, but
if I understand correctly, it can be done only at the beginning, so
that the problem becomes minor. Firefox and MPlayer don't have any
flickering problem, so that there may be something better.

Also, disabling the screensaver while is video is paused is incorrect,
IMHO.

The fact that xset flickers the screen may be another bug.

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


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

Bug#792473: cups: After updating to 2.0.3-6 in testing cups interface no longer works

[Brad Rogers]

On Wed, 15 Jul 2015 07:09:47 +0100 John Talbut  wrote:

> After the recent update Firefox can't establish a connection to the 
> server at localhost:631.  Also, LibreOffice only shows a generic
> printer but other packages (Firefox, Mousepad) print OK.

I've seen this myself.  There's a simple workaround;

As root, run 'cupsd'

It's as simple as that.  For whatever reason, cups is not being started,
or falls over, when the system is booted.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Walking through town is quite scary
I Predict A Riot - Kaiser Chiefs


pgp14QKLOXFEr.pgp
Description: OpenPGP digital signature

Bug#791879: Fwd: Re: Bug#791879: influxdb-python: Please package and upload version 2.6.0

[Thomas Goirand]

On 07/13/2015 03:18 PM, Alexandre Viau wrote:
> Hello Thomas,
> 
> Thank you very much for the review :)
> 
> I have made all recommended changes.
> 
>> You haven't uploaded the version 2.6.0 in the pristine-tar branch.
> 
> I did. 'gbp buildpackage --git-pristine-tar' worked fine for me.

Well, I tried again to "git pull" from all branches, and I still don't
have a tag for upstream 2.6.0:

# git tag
debian/0.1.12-1
upstream/0.1.12
upstream/0.1.13

If the changes were uploaded, the upstream/2.6.0 tag would appear, but
it doesn't. So you may have missed something (like git push --tags?).

Please fix this. Alternatively, just upload the package to mentors, and
I'll just dget the .dsc file.

Cheers,

Thomas Goirand (zigo)


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

Bug#792311: blueman: Silently fails to receive files beamed into accentuated incoming folder

[Christopher Schramm]

Please see https://bugzilla.redhat.com/show_bug.cgi?id=1227868#c3 and
check if it helps.


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

Bug#792519: systemd-logind fails to start on system using LDAP

[Michael Biebl]

Am 15.07.2015 um 20:15 schrieb Felipe Sateler:
> Jul 15 09:35:31 deb-dschepler dbus[836]: [system] Activating systemd
> to hand-off: service name='org.freedesktop.login1'
> unit='dbus-org.freedesktop.login1.service'
> Jul 15 09:35:33 deb-dschepler dbus[836]: [system] Failed to activate
> service 'org.freedesktop.nm_dispatcher': timed out
> 
> Type=dbus units like bluetooth and avahi are also failing. Could you
> test downgrading dbus?
> 
> DBus being problematic could also account for your post-login woes.

Are any of the system groups/accounts stored in LDAP i.e. not accessible
during early boot?

There are quite a few bug reports regarding D-Bus and LDAP, e.g. [1].
That you didn't hit this problem with an older systemd version might be
the result of a race condition, which you didn't hit with older versions.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=28355

-- 
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#792540: Wifi netinstall fails with flashing screen on Lenovo X220

[Steve McIntyre]

On Thu, Jul 16, 2015 at 12:27:22AM +0200, W. Martin Borgert wrote:
>Package: debian-installer
>Version: debian-8.1.0-amd64-netinst.iso
>Severity: important
>Tags: d-i
>
>I tried to install Jessie on a Lenovo X220 using netinst on USB
>flash drive, without Ethernet connection, but with the non-free
>iwlwifi drivers .deb on an SD card (either internal slot or USB
>adaptor).
>
>After the very early step of selecting the keyboard layout, the
>installer seems to try to start X or something, but seems to fail.
>The screen flashes "for ever" and installation cannot be
>continued.
>
>Workaround:
>
>If I use Ethernet instead of Wifi and do not use the SD card,
>the installation continues.
>
>Btw, debian-7.8.0-amd64-netinst.iso shows the same behaviour.

Ok, that's *really* weird. I've been doing test installations
regularly on various X220 machines for *ages* and never seen this. Is
there anything special at all about your SD card? Is the machine
locked, or can you get to logs?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...


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

Bug#790815: (no subject)

[Christopher Schramm]

blueman auto powers on adapters. You can disable this in the settings of
the PowerManager plugin.


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

Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Jérémy Lal]

2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg :

> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> > 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
> >
> >> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> >>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
>  On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> > 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort  >:
> >
> >> (Moving the discussion to #788533; #756867 bcc'ed)
> >>
> >> On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
> >>> The mips* FTBFS are a recurring problem for the mapnik package,
>  previous
> >>> builds were no different. I'll try to get it to build on a
> porterbox,
> >>> but I expect intervention from the buildd admins will be required
> >> like
> >>> last time to make sure only the buildds with the most resources try
> >> to
> >>> build mapnik.
> >>>
> >>> See: https://bugs.debian.org/742149
> >>>  https://bugs.debian.org/729121
> >>
> >> I'm not sure there are buildds with more RAM. Note that the package
>  failed
> >> in
> >> the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of
> >> swap.
> >> Since
> >> all these arches are 32bits, more memory is probably not going to
> >> help.
> >>
> >> Instead, perhaps you can make the build take less memory, e.g. by
>  reducing
> >> the
> >> optimizations (-O1?) or using some flags such as the linker's
> >> --no-keep-memory.
> >
> >
> > Mapnik 2.2 used to pass builds with some of those options, also with
> > removing
> > -ftemplate-depth-300.
> > That last option i restored with mapnik 3.0, to see what would happen
>  with
> > upstream options,
> > since so much has changed in that project.
> > I'm preparing now an upload with that option removed.
> 
>  The new uploaded didn't resolve the build failures, it still failed on
>  {hurd,kfreebsd}-i386 & mips*.
> 
>  Since it's a recurring problem on mips*, maybe exclude these
>  architectures and request removal of the package on mips*.
> >>>
> >>> I've requested removal of the old mapnik 2.2 libs on the three
> >> architectures
> >>> where it fails. I've been told that's the only thing needed to allow
> >>> migration to testing.
> >>> https://bugs.debian.org/789720
> >>
> >> The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same
> >> archs again. I've just pushed a change to exclude mips* from the list of
> >> architectures that will prevent them from building mapnik.
> >>
> >> mapnik still can't migrate because the old python-mapnik binaries
> >> (#790043) and the outstanding RC bugs.
> >>
> >> https://release.debian.org/migration/testing.pl?package=mapnik
> >>
> >> I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to
> >> get the mips* exclusion and static libraries for the python-mapnik build
> >> into the archive. After that we can request removal of the mapnik
> >> package for mips & mipsel.
> >>
> >> Jérémy, do you have anything you want to add before the upload?
> >>
> >
> > ok for python-mapnik (and the transition package python-mapnik2)
> >
> > As far as i understand, you just need
> > Architecture: any
> > and removal of the previous 2.2 versions on mips and mipsel that were in
> > testing
> > to get mapnik to go in testing on other architectures again.
> > That is already done...
>
> So do you want to revert the Architecture change?
>
>
Yes.
Unless someone explains how i'm wrong, of course :)

Jérémy.

Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Sebastiaan Couwenberg]

On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
> 
>> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
>>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
 On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
>
>> (Moving the discussion to #788533; #756867 bcc'ed)
>>
>> On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
>>> The mips* FTBFS are a recurring problem for the mapnik package,
 previous
>>> builds were no different. I'll try to get it to build on a porterbox,
>>> but I expect intervention from the buildd admins will be required
>> like
>>> last time to make sure only the buildds with the most resources try
>> to
>>> build mapnik.
>>>
>>> See: https://bugs.debian.org/742149
>>>  https://bugs.debian.org/729121
>>
>> I'm not sure there are buildds with more RAM. Note that the package
 failed
>> in
>> the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of
>> swap.
>> Since
>> all these arches are 32bits, more memory is probably not going to
>> help.
>>
>> Instead, perhaps you can make the build take less memory, e.g. by
 reducing
>> the
>> optimizations (-O1?) or using some flags such as the linker's
>> --no-keep-memory.
>
>
> Mapnik 2.2 used to pass builds with some of those options, also with
> removing
> -ftemplate-depth-300.
> That last option i restored with mapnik 3.0, to see what would happen
 with
> upstream options,
> since so much has changed in that project.
> I'm preparing now an upload with that option removed.

 The new uploaded didn't resolve the build failures, it still failed on
 {hurd,kfreebsd}-i386 & mips*.

 Since it's a recurring problem on mips*, maybe exclude these
 architectures and request removal of the package on mips*.
>>>
>>> I've requested removal of the old mapnik 2.2 libs on the three
>> architectures
>>> where it fails. I've been told that's the only thing needed to allow
>>> migration to testing.
>>> https://bugs.debian.org/789720
>>
>> The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same
>> archs again. I've just pushed a change to exclude mips* from the list of
>> architectures that will prevent them from building mapnik.
>>
>> mapnik still can't migrate because the old python-mapnik binaries
>> (#790043) and the outstanding RC bugs.
>>
>> https://release.debian.org/migration/testing.pl?package=mapnik
>>
>> I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to
>> get the mips* exclusion and static libraries for the python-mapnik build
>> into the archive. After that we can request removal of the mapnik
>> package for mips & mipsel.
>>
>> Jérémy, do you have anything you want to add before the upload?
>>
> 
> ok for python-mapnik (and the transition package python-mapnik2)
> 
> As far as i understand, you just need
> Architecture: any
> and removal of the previous 2.2 versions on mips and mipsel that were in
> testing
> to get mapnik to go in testing on other architectures again.
> That is already done...

So do you want to revert the Architecture change?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Jérémy Lal]

2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :

> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> > 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
> >> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> >>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
> >>>
>  (Moving the discussion to #788533; #756867 bcc'ed)
> 
>  On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
> > The mips* FTBFS are a recurring problem for the mapnik package,
> >> previous
> > builds were no different. I'll try to get it to build on a porterbox,
> > but I expect intervention from the buildd admins will be required
> like
> > last time to make sure only the buildds with the most resources try
> to
> > build mapnik.
> >
> > See: https://bugs.debian.org/742149
> >  https://bugs.debian.org/729121
> 
>  I'm not sure there are buildds with more RAM. Note that the package
> >> failed
>  in
>  the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of
> swap.
>  Since
>  all these arches are 32bits, more memory is probably not going to
> help.
> 
>  Instead, perhaps you can make the build take less memory, e.g. by
> >> reducing
>  the
>  optimizations (-O1?) or using some flags such as the linker's
>  --no-keep-memory.
> >>>
> >>>
> >>> Mapnik 2.2 used to pass builds with some of those options, also with
> >>> removing
> >>> -ftemplate-depth-300.
> >>> That last option i restored with mapnik 3.0, to see what would happen
> >> with
> >>> upstream options,
> >>> since so much has changed in that project.
> >>> I'm preparing now an upload with that option removed.
> >>
> >> The new uploaded didn't resolve the build failures, it still failed on
> >> {hurd,kfreebsd}-i386 & mips*.
> >>
> >> Since it's a recurring problem on mips*, maybe exclude these
> >> architectures and request removal of the package on mips*.
> >
> > I've requested removal of the old mapnik 2.2 libs on the three
> architectures
> > where it fails. I've been told that's the only thing needed to allow
> > migration to testing.
> > https://bugs.debian.org/789720
>
> The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same
> archs again. I've just pushed a change to exclude mips* from the list of
> architectures that will prevent them from building mapnik.
>
> mapnik still can't migrate because the old python-mapnik binaries
> (#790043) and the outstanding RC bugs.
>
> https://release.debian.org/migration/testing.pl?package=mapnik
>
> I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to
> get the mips* exclusion and static libraries for the python-mapnik build
> into the archive. After that we can request removal of the mapnik
> package for mips & mipsel.
>
> Jérémy, do you have anything you want to add before the upload?
>

ok for python-mapnik (and the transition package python-mapnik2)

As far as i understand, you just need
Architecture: any
and removal of the previous 2.2 versions on mips and mipsel that were in
testing
to get mapnik to go in testing on other architectures again.
That is already done...

Jérémy.

Bug#791445: [Ceph-maintainers] Bug#791445: ceph: uses bundled "libjerasure" library again

[Thomas Goirand]

On 07/15/2015 06:30 PM, Loic Dachary wrote:
> On 15/07/2015 16:43, Thomas Goirand wrote:
>> On 07/09/2015 11:35 PM, Loic Dachary wrote:
>>> On 07/07/2015 18:24, James Page wrote:
 I dug into this in a bit more detail today; the Ceph package builds a
 number of difference loadable erasure coding plugins, enabling
 different cpu feature sets (generic, neon, sse3, sse4); each time
 Jerasure and gf-complete are statically linked into the module, built
 with the required flags to enable the right CPU instruction codes
 (build time, not runtime enablement).
>>>
>>> Yes, and depending on which CPU features are available at runtime,
>>> the plugin that can take advantage of them is loaded. All variants
>>> are verified to encode / decode exactly in the same way (with a set
>>> of data) each time a new Ceph version is published, to protect
>>> against regression or corruption.
>>
>> Such a feature should be upstreamed in gf-complete and jerasure.
>>
 Unless I'm reading the packaging wrong, the jerasure and gf-complete
 packages current disable any CPU specific extensions in order to have
 a completely generic library that works on any CPU.  So using the
 system libraries effectively cripples any CPU optimization that might
 be achievable at runtime in Ceph.
>>>
>>> Yes. I could fix that without sacrificing test coverage / data
>>> integrity, simply by moving part of the above in the package, and
>>> running integration and non regression tests on the resulting package.
>>> The package could be used in the current Ceph integration suites,
>>> before being uploaded to Debian GNU/Linux. That's the most effective
>>> way to protect jerasure users against data loss right now.
>>
>> Could you please share your patches and open a bug against the
>> gf-complete and jerasure packages?
> 
> Hi Thomas,
> 
> I'm offended by the mails you sent to me on that topic. They were
> disrespectful, condescending and uncooperative. Given that's the
> first and only time you chommunicated with me since you started
> packaging jerasure, it would be wise of you to hand over the package
> to someone better able to establish a productive and friendly
> discussion with upstream.

Well, disrespect is what you get when you are disrespectful yourself.
Asking to hand-over the package for no valid reason, with no bug opened
at all, after all the effort and time I spent on these was really
disrespectful indeed. You still haven't opened any bug btw, please do so
if you have any concern.

Now I fail to see how uncooperative I have been. I've been here asking
you to share your work within the packages of gf-complete, and jerasure,
but it doesn't seem like you want to. In what way is this an
uncooperative attitude from my side? Just because I refuse to hand-over
the packages to you (only, without a team)? Or is this because I've told
you that it should be upstream to do runtime CPU feature detection? The
only answer I get is that I'm "disrespectful, condescending and
uncooperative" in return. This isn't going in the right direction.

I by the way would like to point out that you are still a member of the
OpenStack packaging group on Alioth, where all of these packages are
maintained. So if you would like to contribute, the git repositories are
wide open to you. I don't understand why I would have to just give-up
the packages to you and you only. No, these packages are *not* getting
away from the OpenStack packaging group. Yes, you can help or even take
care of them if you wish. I've always been very welcoming contributors,
but we need to keep this kind of key package in the group to make sure
they are well integrated with everything else in OpenStack.

In the past, communicating with you was done in a very friendly way. I
don't understand what happened suddenly. What I feel from my side is
aggressiveness from yours. So I propose that we both forget it, and try
to reboot all. If I offended you, I'm sorry about it. I hope you'll
forget it, and I'll try to forgive you too.

Shall we move on? Can we have a constructive conversation from now on?

Let me do another attempt, and see how it goes: what's your plan for the
packages to do CPU feature detection at runtime, and get Ceph to use
that, instead of embedding the libs?

I also have plans myself, btw, but I was lacking time. I know there's
some ways to add CPU features built in libs (dropped in specific
folders). Another way would be to have another binary including the
optimizations (which we could call for example libgf-complete1-sse4, and
which would Provides: and Breaks: libgf-complete1).

I'd prefer the first approach, but I never had time to investigate how
it's done in Debian. There's also the issue that some buildd may not
have the SSE4 features, and therefore, they may not be able to build the
packages. This would have to be investigated too.

I'm looking forward to read your answer, then let's see together how it
can happen.

Cheers,

Thomas Goirand (z

Bug#792540: Wifi netinstall fails with flashing screen on Lenovo X220

[W. Martin Borgert]

Package: debian-installer
Version: debian-8.1.0-amd64-netinst.iso
Severity: important
Tags: d-i

I tried to install Jessie on a Lenovo X220 using netinst on USB
flash drive, without Ethernet connection, but with the non-free
iwlwifi drivers .deb on an SD card (either internal slot or USB
adaptor).

After the very early step of selecting the keyboard layout, the
installer seems to try to start X or something, but seems to fail.
The screen flashes "for ever" and installation cannot be
continued.

Workaround:

If I use Ethernet instead of Wifi and do not use the SD card,
the installation continues.

Btw, debian-7.8.0-amd64-netinst.iso shows the same behaviour.


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

Bug#792539: ITP: python-mapnik -- Python interface to the mapnik library

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: python-mapnik
  Version : 0.0~20150708-c005502
  Upstream Author : Mapnik Developers
* URL : https://github.com/mapnik/python-mapnik
* License : LGPL-2.1+
  Programming Lang: C++/Python
  Description : Python interface to the mapnik library

Mapnik is an OpenSource C++ toolkit for developing GIS
(Geographic Information Systems) applications. At the core is a C++
shared library providing algorithms/patterns for spatial data access and
visualization.

Essentially a collection of geographic objects (map, layer, datasource,
feature, geometry), the library doesn't rely on "windowing systems" and
is intended to work in multi-threaded environments

This package contains the bindings for Python. It used to be built from
the mapnik source, but has been split off into its own project since
mapnik 3.0.0.

The package will be maintained within the Debian GIS team.


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

Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Sebastiaan Couwenberg]

On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
>> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
>>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
>>>
 (Moving the discussion to #788533; #756867 bcc'ed)

 On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
> The mips* FTBFS are a recurring problem for the mapnik package,
>> previous
> builds were no different. I'll try to get it to build on a porterbox,
> but I expect intervention from the buildd admins will be required like
> last time to make sure only the buildds with the most resources try to
> build mapnik.
>
> See: https://bugs.debian.org/742149
>  https://bugs.debian.org/729121

 I'm not sure there are buildds with more RAM. Note that the package
>> failed
 in
 the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of swap.
 Since
 all these arches are 32bits, more memory is probably not going to help.

 Instead, perhaps you can make the build take less memory, e.g. by
>> reducing
 the
 optimizations (-O1?) or using some flags such as the linker's
 --no-keep-memory.
>>>
>>>
>>> Mapnik 2.2 used to pass builds with some of those options, also with
>>> removing
>>> -ftemplate-depth-300.
>>> That last option i restored with mapnik 3.0, to see what would happen
>> with
>>> upstream options,
>>> since so much has changed in that project.
>>> I'm preparing now an upload with that option removed.
>>
>> The new uploaded didn't resolve the build failures, it still failed on
>> {hurd,kfreebsd}-i386 & mips*.
>>
>> Since it's a recurring problem on mips*, maybe exclude these
>> architectures and request removal of the package on mips*.
> 
> I've requested removal of the old mapnik 2.2 libs on the three architectures
> where it fails. I've been told that's the only thing needed to allow
> migration to testing.
> https://bugs.debian.org/789720

The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same
archs again. I've just pushed a change to exclude mips* from the list of
architectures that will prevent them from building mapnik.

mapnik still can't migrate because the old python-mapnik binaries
(#790043) and the outstanding RC bugs.

https://release.debian.org/migration/testing.pl?package=mapnik

I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to
get the mips* exclusion and static libraries for the python-mapnik build
into the archive. After that we can request removal of the mapnik
package for mips & mipsel.

Jérémy, do you have anything you want to add before the upload?

> It doesn't forbid trying builds with suggested flags above (-O1,
> --no-keep-memory).

I suspect the failure on kfreebsd-i386 is caused by exhausting the 32bit
address space, but since it's not a release architecture we don't have
to worry about it much.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Bug#791680: A crash of Qgis Desktop occurs when I try to "save as" a vector layer

[Sebastiaan Couwenberg]

Hi Etienne,

On 07/15/2015 11:50 PM, Etienne MAHE wrote:
> I have followed your instructions but the crash still occurs with just the
> following message in terminal :
> 
> *Erreur de segmentation*
> 
> The problem with EPSG has vanished but the segmentation error is here yet.

The segmentation fault is caused by the deprecated spatialite_init()
method, this is fixed in QGIS 2.8.3. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788101#10
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790224#33

As noted in the second bug, we now have spatialite 4.3.0 in unstable. It
should migrate to testing in 5 days if no RC bug or uncoordinated
transition blocks it.

And as noted in the first bug, QGIS 2.8.3 contains the changes to use
the thread-safe spatialite_init_ex() method, but it hasn't been released
yet.

If getting the QGIS 2.8.3 release out takes too long, I'll include the
spatialite changes as a patch in the qgis 2.8.2 package.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Bug#789543: It was fixed

[Bryan Sutula]

On Wed, 2015-07-15 at 11:45 -0600, Mohan wrote: 
> make rpm and installing the rpm's works well with 755 permissions. make
> install creates /usr/local/var/lib/openhpi with 777 permissions. This
> was fixed. 
> https://sourceforge.net/p/openhpi/bugs/1883/

Thanks, Mohan.  So it's fixed in upstream and the next Debian version
will have the fix.

-Bryan


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

Bug#778051: Patch for GCC5 build issue.

[Nicholas Luedtke]

tags 778051 + patch
thanks

Here's a fix for the GCC 5 build issue. Added "extern" to
inline functions in stuff.c . The package builds and links with GCC 5 
with this change.


Upstream may prefer to move to C99 instead, please see section
"Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Nicholas Luedtke
Linux for HP Helion OpenStack, Hewlett-Packard
Description: Fixed GCC5 build issue.
 ADD "extern" to xpart and ypart functions
 .
 overgod (1.0-4.1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Fixed Gcc5 build issue. (closes 778051)
Author: Nicholas Luedtke 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

Index: overgod-1.0/stuff.c
===
--- overgod-1.0.orig/stuff.c
+++ overgod-1.0/stuff.c
@@ -51,7 +51,6 @@ float decoy_table [ANGLE_FULL]; // not u
 float cos_table [ANGLE_FULL];
 float sin_table [ANGLE_FULL];
 
-inline int xpart(int angle, int length);
 
 void init_trig(void)
 {
@@ -66,13 +65,13 @@ void init_trig(void)
  
 }
 
-inline int xpart(int angle, int length)
+extern inline int xpart(int angle, int length)
 {
 // return (lcos(angle) * length);// / ANGLE_FULL;
  return (cos_table [angle & 1023] * length);// / ANGLE_FULL;
 }
 
-inline int ypart(int angle, int length)
+extern inline int ypart(int angle, int length)
 {
  return (sin_table [angle & 1023] * length);// / ANGLE_FULL;
 }

Bug#790256: libsysactivity: FTBFS: Test failures

[Eriberto Mota]

Hi,

After some days without a reply, I think that the problem is solved.
So, I will upload a new revision to 1-delay queue.

Thanks!

Eriberto


2015-07-02 23:59 GMT-03:00 Eriberto Mota :
> tags 790256 moreinfo
> thanks
>
>
> Hi Daniel,
>
> Thanks for your report.
>
> Note that you got 'Operation not supported' in all tests. I think you have a 
> local problem, because my cowbuilder builds the libsysactivity fine.
>
> Do you have a tip to make this issue reproducible? Can you test again in 
> other computer, using pbuilder or cowbuilder?
>
> After your reply, I will disable the network test to avoid problems.
>
> Regards,
>
> Eriberto


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

Bug#792538: vlc: When playing a video, screen gets black for a fraction of second every 30 seconds

[Vincent Lefevre]

Something else interesting:

If I pause the video (I mean "pause" by clicking on the || button,
not "stop"), then the same problem still occurs every 30 seconds.

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


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

Bug#792538: vlc: When playing a video, screen gets black for a fraction of second every 30 seconds

[Vincent Lefevre]

On 2015-07-15 23:19:02 +0200, Vincent Lefevre wrote:
> original file taken from:
> 
>   https://commons.wikimedia.org/wiki/File:1_hour_Wilhelmshoeher_Allee.ogg

If I play the video from this page directly in Firefox (i.e. not
using VLC), then I haven't noticed any problem.

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


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

Bug#791579: cruft: Running cruft generates error messages

[Rogério Brito]

Hi, Alexandre,

I forgot to give you the feedback and here it is. Sorry for not replying
earlier.

On Jul 06 2015, Alexandre Detiste wrote:
> 2015-07-06 14:11 GMT+02:00 Rogério Brito :
> > # cruft -d / -d /boot -r report.log --ignore /home --ignore /var --ignore 
> > /tmp
> > /usr/lib/cruft/explain/USERS: 160: [: /usr/lib/cruft/cruft_find: unexpected 
> > operator
> > /usr/lib/cruft/explain/USERS: 160: [: /usr/lib/cruft/cruft_find: unexpected 
> > operator
> 
> now fixed:
> https://github.com/a-detiste/cruft/commit/b38b19c74c3dd11812b2991dc04a8642395401c0.
> 
> Can you please directly edit /usr/lib/cruft/common.sh and remove the
> extraneous "$@"
> to check that it solves your problem ?

Yes, that solves it. Sorry for not diving too much into the code to find the
issue and supplying you with a patch, but I've been in a hurry with lots of
stuff to do.

> I see you are using "--ignore /home", which is what well everybody should do
> to avoid that /home got scanned *twice* only just to detect broken symlinks
> & non-owned files.

I didn't know that the current implementation of cruft did these things
twice, which I guess that could be done in just one pass (that could be done
with essentially a few lines with just a few calls to stat).

Besides that, doing those things in two passes requires going to the disk
twice, which is bad from both the latency and caching (if many files are to
be scanned), especially if the system is constrained in memory (like my NAS
with only 128MB of which there is essentially 10MB usable at any given time,
due to the kernel reserving memory and other programs running).

> (cruft computes a huge list with these items, another huge one without
> these items but well all regular files, the compare the two.)

Didn't know that.

> I was really tempted to make it the default behaviour, but I don't want to
> break users expectations either.

Do a few releases of cruft and state (when the user executes the program)
that the current behavior is going to be deprecated and changed in a future
release with the "space" between the deprecation warning being one Debian
release (i.e., jessie+1).

> It's not like I can send a survey to "registrated customers"
> to get a feeling of what they think about it.

I also don't know my users think of my packages (but I am upstream only for
programs that I *don't* have packaged in Debian, anyway). But for one that
changes a lot (youtube-dl) what I usually do is to put behavior changes in
the NEWS file.

Note that a note in the NEWS file *may* be insufficient for the users, but a
runtime warning that things are going to change is much more informative,
*when* it can be done.

> For cruft-ng (my rewrite of the shell/perl/c engine in C++);
> I just never scan further that the first level in /home;
> and avoid /tmp altogether.

That sounds like a good plan, but please, state clearly the differences in
behavior in the documentation.

> Well, speed was priority & command lines are not implemented at all at
> the moment, but the defaults are saner;

Which is the good way to go.

> and tool can be indirectly configured by tweaking mlocate's
> /etc/updatedb.conf .

Hummm, here we have a problem: not all users have even mlocate installed
(it's one of the first packages that I purge from my systems whenever I
install them).

I wouldn't want to have a cron job running every day to update the list of
files that I have. The "one time" hit of running cruft (or cruft-ng, or
whatever) every now and then is acceptable, but the hit of running a cron
job every day (or weekly or whatever) is not something that I like to have.

But I guess that we can discuss these tangential points in another thread,
so as to not pollute this but report. :)

I'm happy to give you my intended usage patterns, so that you can
incorporate them into cruft-ng.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#792537: bugs.debian.org: Internal Server Error

[Victor Porton]

Package: bugs.debian.org
Severity: important

Dear Maintainer,

Loading this URL in Iceweasel

http://bugs-search.debian.org/cgi-bin/search.cgi?phrase=Gimp&search=search&skip=0&attribute_field=%40author&attribute_operator=STRBW&attribute_value=porton%40narod.ru&order_field=&order_operator=STRA&max_results=10

produces "Internal Server Error".

It was a non-nonsense query from
http://bugs-search.debian.org/cgi-bin/search.cgi

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

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


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

Bug#792538: vlc: When playing a video, screen gets black for a fraction of second every 30 seconds

[Vincent Lefevre]

Package: vlc
Version: 2.2.1-2+b1
Severity: important

When playing a video (I've tried both MP4 and OGG), the screen gets
black for a fraction of second every 30 seconds: at 0:00 (not always),
0:29, 0:59, 1:29, etc. This also occurs even when the VLC window is
completely off-screen.

As an example (video randomly taken on Wikimedia commons):

  
https://upload.wikimedia.org/wikipedia/commons/6/64/1_hour_Wilhelmshoeher_Allee.ogg

original file taken from:

  https://commons.wikimedia.org/wiki/File:1_hour_Wilhelmshoeher_Allee.ogg

But this seems to occur with every video, and this seems to be always
reproducible.

The fraction of second is very short. Sometimes the whole screen is
affected, sometimes only the bottom part.

I've attached "vlc -vvv ..." output.

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

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

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-43
ii  libavcodec566:11.4-2
ii  libavutil54 6:11.4-2
ii  libc6   2.19-19
ii  libcaca00.99.beta19-2
ii  libcairo2   1.14.2-2
ii  libegl1-mesa [libegl1-x11]  10.5.9-2
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreetype62.5.2-4
ii  libfribidi0 0.19.6-3
ii  libgcc1 1:5.1.1-14
ii  libgl1-mesa-glx [libgl1]10.5.9-2
ii  libgles1-mesa [libgles1]10.5.9-2
ii  libgles2-mesa [libgles2]10.5.9-2
ii  libglib2.0-02.44.1-1.1
ii  libpulse0   6.0-2
ii  libqt5core5a5.4.2+dfsg-4
ii  libqt5gui5  5.4.2+dfsg-4
ii  libqt5widgets5  5.4.2+dfsg-4
ii  libqt5x11extras55.4.2-2
ii  librsvg2-2  2.40.9-2
ii  libsdl-image1.2 1.2.12-5+b5
ii  libsdl1.2debian 1.2.15-11
ii  libstdc++6  5.1.1-14
ii  libva-drm1  1.6.0-1
ii  libva-x11-1 1.6.0-1
ii  libva1  1.6.0-1
ii  libvlccore8 2.2.1-2+b1
ii  libvncclient1   0.9.10+dfsg-3
ii  libx11-62:1.6.3-1
ii  libxcb-composite0   1.10-3+b1
ii  libxcb-keysyms1 0.4.0-1
ii  libxcb-randr0   1.10-3+b1
ii  libxcb-shm0 1.10-3+b1
ii  libxcb-xv0  1.10-3+b1
ii  libxcb1 1.10-3+b1
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.11-1+b1
ii  vlc-nox 2.2.1-2+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.1-2+b1
ii  vlc-plugin-samba   2.2.1-2+b1
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages vlc suggests:
pn  videolan-doc  

Versions of packages vlc-nox depends on:
ii  liba52-0.7.4   0.7.4-18
ii  libasound2 1.0.29-1
ii  libass50.12.3-1
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libavc1394-0   0.5.4-2
ii  libavcodec56   6:11.4-2
ii  libavformat56  6:11.4-2
ii  libavutil546:11.4-2
ii  libbasicusageenvironment0  2014.01.13-1
ii  libbluray1 1:0.8.1-1
ii  libc6  2.19-19
ii  libcddb2   1.3.2-5
ii  libcdio13  0.83-4.2
ii  libchromaprint01.2-1
ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-11
ii  libdbus-1-31.8.18-1
ii  libdc1394-22   2.2.3-1
ii  libdca00.0.5-7
ii  libdirectfb-1.2-9  1.2.10.0-5.1
ii  libdvbpsi101.3.0-2
ii  libdvdnav4 5.0.1-4
ii  libdvdread45.0.0-1
ii  libebml4   1.3.1-3
ii  libfaad2   2.8.0~cvs20150510-1
ii  libflac8   1.3.1-2
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-4
ii  libfribidi00.19.6-3
ii  libgcc11:5.1.1-14
ii  libgcrypt201.6.3-2
ii  libgnutls-deb0-28  3.3.16-1
ii  libgpg-error0  1.19-2
ii  libgroupsock1  2014.01.13-1
ii  libjpeg62-turbo1:1.4.0-7
ii  libkate1   0.4.1-4
ii  liblircclient0 0.9.0~pre1-1.2
ii  liblivemedia23 2014.01.13-1
ii  liblua5.2-05.2.3-1

Bug#778122: patch for gcc5 bug

[Alexander Balderson]

tags 778122 + patch
thanks

Here's a fix for the GCC 5 build issue. Added extern to inline functions 
in ppc_fpu.c, ppc_mmu.c, and emul.c


Upstream may prefer to move to C99 instead, please see section
"Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Alexander Balderson
Linux for HP Helion OpenStack, Hewlett-Packard
--- skyeye-1.2.5/arch/ppc/common/ppc_fpu.c	2007-06-17 02:22:22.0 +
+++ ppc_fpu.c	2015-07-15 20:49:30.86000 +
@@ -29,7 +29,7 @@
 
 
 #define PPC_FPR_TYPE2(a,b) (((a)<<8)|(b))
-inline void ppc_fpu_add(ppc_double *res, ppc_double *a, ppc_double *b)
+extern inline void ppc_fpu_add(ppc_double *res, ppc_double *a, ppc_double *b)
 {
 	switch (PPC_FPR_TYPE2(a->type, b->type)) {
 	case PPC_FPR_TYPE2(ppc_fpr_norm, ppc_fpr_norm): {
@@ -134,7 +134,7 @@
 	}
 }
 
-inline void ppc_fpu_quadro_mshr(ppc_quadro *q, int exp)
+extern inline void ppc_fpu_quadro_mshr(ppc_quadro *q, int exp)
 {
 	if (exp >= 64) {
 		q->m1 = q->m0;
@@ -147,7 +147,7 @@
 	q->m1 |= t<<(64-exp);
 }
 
-inline void ppc_fpu_quadro_mshl(ppc_quadro *q, int exp)
+extern inline void ppc_fpu_quadro_mshl(ppc_quadro *q, int exp)
 {
 	if (exp >= 64) {
 		q->m0 = q->m1;
@@ -160,7 +160,7 @@
 	q->m0 |= t;
 }
 
-inline void ppc_fpu_add_quadro_m(ppc_quadro *res, const ppc_quadro *a, const ppc_quadro *b)
+extern inline void ppc_fpu_add_quadro_m(ppc_quadro *res, const ppc_quadro *a, const ppc_quadro *b)
 {
 	res->m1 = a->m1+b->m1;
 	if (res->m1 < a->m1) {
@@ -170,7 +170,7 @@
 	}
 }
 
-inline void ppc_fpu_sub_quadro_m(ppc_quadro *res, const ppc_quadro *a, const ppc_quadro *b)
+extern inline void ppc_fpu_sub_quadro_m(ppc_quadro *res, const ppc_quadro *a, const ppc_quadro *b)
 {
 	res->m1 = a->m1-b->m1;
 	if (a->m1 < b->m1) {
@@ -181,7 +181,7 @@
 }
 
 // res has 107 significant bits. a, b have 106 significant bits each.
-inline void ppc_fpu_add_quadro(ppc_quadro *res, ppc_quadro *a, ppc_quadro *b)
+extern inline void ppc_fpu_add_quadro(ppc_quadro *res, ppc_quadro *a, ppc_quadro *b)
 {
 	// treat as 107 bit mantissa
 	if (a->type == ppc_fpr_norm) ppc_fpu_quadro_mshl(a, 1);
@@ -317,14 +317,14 @@
 	}
 }
 
-inline void ppc_fpu_add_uint64_carry(uint64 *a, uint64 b, uint64 *carry)
+extern inline void ppc_fpu_add_uint64_carry(uint64 *a, uint64 b, uint64 *carry)
 {
 	*carry = (*a+b < *a) ? 1 : 0;
 	*a += b;
 }
 
 // 'res' has 56 significant bits on return, a + b have 56 significant bits each
-inline void ppc_fpu_mul(ppc_double *res, const ppc_double *a, const ppc_double *b)
+extern inline void ppc_fpu_mul(ppc_double *res, const ppc_double *a, const ppc_double *b)
 {
 	res->s = a->s ^ b->s;
 	switch (PPC_FPR_TYPE2(a->type, b->type)) {
@@ -404,7 +404,7 @@
 
 // 'res' has 'prec' significant bits on return, a + b have 56 significant bits each
 // for 111 >= prec >= 64
-inline void ppc_fpu_mul_quadro(ppc_quadro *res, ppc_double *a, ppc_double *b, int prec)
+extern inline void ppc_fpu_mul_quadro(ppc_quadro *res, ppc_double *a, ppc_double *b, int prec)
 {
 	res->s = a->s ^ b->s;
 	switch (PPC_FPR_TYPE2(a->type, b->type)) {
@@ -496,7 +496,7 @@
 // FIXME: There is a bug in this code that shows up in Mac OS X Finder fwd/bwd
 // button: the top line is not rendered correctly. This works with the jitc_x86
 // FPU however...
-inline void ppc_fpu_mul_add(ppc_double *res, ppc_double *m1, ppc_double *m2,
+extern inline void ppc_fpu_mul_add(ppc_double *res, ppc_double *m1, ppc_double *m2,
 	ppc_double *s)
 {
 	ppc_quadro p;
@@ -539,7 +539,7 @@
 		ppc_fpu_get_fpr_type(res.type));*/
 }
 
-inline void ppc_fpu_div(ppc_double *res, const ppc_double *a, const ppc_double *b)
+extern inline void ppc_fpu_div(ppc_double *res, const ppc_double *a, const ppc_double *b)
 {
 	res->s = a->s ^ b->s;
 	switch (PPC_FPR_TYPE2(a->type, b->type)) {
@@ -601,7 +601,7 @@
 	}
 }
 
-inline void ppc_fpu_sqrt(ppc_double *D, const ppc_double *B)
+extern inline void ppc_fpu_sqrt(ppc_double *D, const ppc_double *B)
 {
 	switch (B->type) {
 	case ppc_fpr_norm:
@@ -682,7 +682,7 @@
 /*
  *	a and b must not be NaNs
  */
-inline uint32 ppc_fpu_compare(ppc_double *a, ppc_double *b)
+extern inline uint32 ppc_fpu_compare(ppc_double *a, ppc_double *b)
 {
 	if (a->type == ppc_fpr_zero) {
 		if (b->type == ppc_fpr_zero) return 2;
--- skyeye-1.2.5/arch/ppc/common/ppc_mmu.c	2007-11-16 03:16:22.0 +
+++ ppc_mmu.c	2015-07-15 20:49:38.28400 +
@@ -1347,7 +1347,7 @@
 	return r;
 }
 
-inline int FASTCALL ppc_read_physical_qword(uint32 addr, Vector_t *result)
+extern inline int FASTCALL ppc_read_physical_qword(uint32 addr, Vector_t *result)
 {
 	if (addr < boot_romSize) {
 		// big endian
@@ -1422,7 +1422,7 @@
 	return r;
 }
 
-inline int FASTCALL ppc_read_effective_qword(uint32 addr, Vector_t *result)
+extern inline int FASTCALL ppc_read_effective_qword(uint32 addr, Vector_t *result)
 {
 	uint32 p;
 	int r;
@@ -1463,7 +1463,7 @@
 	return r;
 
 }
-inline int FASTCALL ppc_write_physical_qword(uint32 addr, Vector_t *data)
+extern inl

Bug#792536: missing license in debian/copyright

[Thorsten Alteholz]

Package: libdap
Version: 3.14.0-3~exp1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

please add the missing licenses of:
 gl/*
to debian/copyright.

Thanks!
  Thorsten


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

Bug#777907: Patch for GCC5 build issue

[Nicholas Luedtke]

tags 777907 + patch
thanks

Here's a fix for the GCC 5 build issue. Removed "extern" from
inline functions in hunt.h. The package builds and links with GCC 5 with 
this change.


Upstream may prefer to move to C99 instead, please see section
"Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Nicholas Luedtke
Linux for HP Helion OpenStack, Hewlett-Packard
--- ../hunt.h	2015-07-15 20:47:03.634664806 +
+++ hunt.h	2015-07-15 20:47:43.506664459 +
@@ -291,20 +291,20 @@
 #define TCP_HDR_LENGTH(tcph) ((tcph)->doff << 2)
 
 
-extern inline unsigned int generate_key(unsigned long saddr, unsigned long daddr,
+inline unsigned int generate_key(unsigned long saddr, unsigned long daddr,
 			   unsigned short source, unsigned short dest)
 {
 	return saddr + daddr + source + dest;
 }
 
 #if 0
-extern inline unsigned int generate_key_from_packet(struct packet *p)
+inline unsigned int generate_key_from_packet(struct packet *p)
 {
 	return generate_key(ntohl(p->p_iph->saddr), ntohl(p->p_iph->daddr),
 		ntohs(p->p_hdr.p_tcph->source), ntohs(p->p_hdr.p_tcph->dest));
 }
 #endif
-extern inline unsigned int uci_generate_key(struct user_conn_info *uci)
+inline unsigned int uci_generate_key(struct user_conn_info *uci)
 {
 	return generate_key(ntohl(uci->src_addr), ntohl(uci->dst_addr),
 		ntohs(uci->src_port), ntohs(uci->dst_port));

Bug#791860: Appstream-glib doesn't properly parse INF files for ESRT

[Mario_Limonciello]

When you do bring in this patch, also can you please build depend on 
libgcab-dev to enable the cab support this fixes?  I noticed that it wasn't on 
previously.

Thanks,


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

Bug#774149: udisks2

[Rogério Brito]

Hi.

On Jul 08 2015, Jürgen Braun wrote:
> I don't think you can cover all functionality with udisks2. I got the
> same problem as shirish.

Yes, you guys convinced me that usbmount still has its uses.

> I was thinking about a udev rule to issue the udisksctrl command, but I
> need to know the filesystem type before the mount to be able to specify
> different mount options on vfat than on ntfs or ext2. This leads to a
> more complex script which will basically look like usbmount, I think.

I think that yes. Not really sure, but I guess that you are correct.

> Besides, I do not like the way udisks2 is creating the mountpoints. I'd
> like my flash drive on /media/usb0 and not some unpredictable
> /media//

Yes, this was one of the selling points of usbmount, since I wanted
something simple for my systems that *don't* have a full-blown desktop
environment installed (e.g., one NAS with 128MB and another with only 64MB
of memory).


Thanks for the feedback,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#774149: mounting and unmounting manually.

[Rogério Brito]

Hi.

On Jul 08 2015, shirish शिरीष wrote:
> On 7/8/15, jean-marc montanier  wrote:
> > If udisks2 is covering the functionalities of usbmount and has an active
> > development, may be the usbmount package should be removed from the future
> > versions of debian ?
>
> What I ended up doing was getting both usbmount and pmount purged from
> the system and just use udisks2.

OK.

(...)
> [$] mount | grep /dev/sd
> 
> /dev/sda6 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
> /dev/sda8 on /data type ext4 (rw,relatime,data=ordered)
> /dev/sda7 on /home type ext4 (rw,relatime,data=ordered)
> /dev/sdb1 on /media/shirish/shirish type vfat
> (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

So, this means that you are/were also having problems with kernel-provided
filesystems like vfat? I thought that the problem only manifested when using
fuse filesystems.

I also don't like the flush option that is passed compulsorily to the
filesystems by udisks2, especially for USB thumb/flash/pen drives. And I
don't like the relatime option also on my systems.

(...)
> because auto-mounting doesn't work :( .

I'm still undecided about the future of usbmount (see my previous message
about moving things to github). If I were to kill usbmount, then I guess
that we should have a good documentation of how to migrate.

And, perhaps, some work on the udisks2 side of things would be needed to
support our use case, but good luck convincing the developers of udisks2 to
change their mind to behave like we want to (I believe that they would
resist to changes, but one can try, at least).

> For the above to work user has to be part of plugdev group.

Yes. With pmount, you wouldn't need to.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#774149: Workaround working

[Rogério Brito]

Hi.

On Jul 08 2015, jean-marc montanier wrote:
> Just a quick message to report that the nasty workaround is anyway
> efficient. It's working on my Jessie, thanks.

The basic idea behind using at is not that bad at all.

I have investigated (a very tiny bit) of the behavior of fuse mounts and the
thing is that the fuse filesystems stay with their respective fuse programs
running until the filesystems are unmounted, which, apparently, leads udev
to think that they are stuck (which is not necessarily the case).

With the current workaround with at, we "offload" the task of a long running
process to at and udev then sees the whole procedure being "completed" in a
short time, and does not complain or kill the subprocess.

What I believe is a clener solution is that, instead of using at, we can
simply use a program that "daemonizes" the processes that we want. Perhaps a
very thin wrapper written in C around the daemon(2) function would be
sufficient for our needs.

Or, perhaps, we can stick with at, since it is a proven tool that stood the
test of the time (and the usbmount package would still continue to be arch:
all).

> If udisks2 is covering the functionalities of usbmount and has an active
> development, may be the usbmount package should be removed from the future
> versions of debian ?

I *think* that udisks2 *may* cover the functionalities of usbmount, but I
had a very bad time telling udisks2 that I want my NTFS filesystems mounted
with the options that I want (in particular, noatime, nodiratime, and
big_writes), but, apparently from what I read on blogs and other sites,
those *seem* to be hardcoded behavior, which is very unpleasant.

Nevertheless, I am thinking of moving the development of usbmount to my
github account and accepting all the pull requests there.

It is much easier (read: I can react much more quickly) to me to accept pull
requests there than receiving patches via e-mail and applying them (of
course, I will still be willing to receive patches by e-mail, but that's not
my preferred option).

I will keep the git repository in Debian mirrored with the github repo, so
that if github goes away (which I sincerely doubt), then we don't lose much.

How does that sound?

BTW, one very important question: are the problems with usbmount only
apparent when using fuse filesystems or are they also apparent when using
filesystems supported by the kernel (e.g., vfat or ext4)?


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#767880: Debien-installer does not install lvm

[neonknight]

Package: debian-installer
Version: 20150422+deb8u1
Followup-For: Bug #767880

Same problem here, though it only seems to appear in the graphical installer 
but not in text installer. And cryptsetup is also missing in initramfs.

Steps to reproduce:

I just reinstalled a system using a currently downloaded version  
debian-live-8.1.0-amd64-xfce-desktop.iso from USB stick. 

I tried setting up the system using the graphical installer by clicking the 
installer icon on the desktop of the live system. I could create my encrypted 
disks (with LVM on top) using the partition tool provided by the installer. 
After the installation finished successfully I was unable to boot because 
initramfs was missing both LVM and cryptsetup.

I then tried the text installer provided on the same installation media, erased 
all data on the disk. I again created an encrypted disk with LVM on top. After 
installation Iwas able to boot the system without any trouble. 


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

Bug#792524: desktop crash

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/07/15 22:09, Michael Biebl wrote:
> Am 15.07.2015 um 21:17 schrieb Daniel Pocock:
>> 
>>> That looks like a crash in the Xorg server originating in the 
>>> (proprietary) nvidia driver.
>> 
>>> Any reason you filed this against gnome-session?
>> 
>> 
>> The first line in the log comes from gnome-session and it is one 
>> second before the Xorg crash:
>> 
>> 
>> 
>> 19:36:19  gnome-session[2616]: (gnome-shell:10887):
>> mutter-CRITICAL **: meta_window_focus: assertion
>> '!window->override_redirect' failed 19:36:20  gdm-Xorg-:0[1805]:
>> (EE) 19:36:20  gdm-Xorg-:0[1805]: (EE) Backtrace:
>> 
>> 
>> Does that line indicate that gnome-session (or something else)
>> caused the crash?  Or it is just co-incidence or maybe just the
>> Xorg logs coming more slowly?
> 
> That message is from mutter/gnome-shell. gnome-session is only 
> responsible for logging it.
> 

Should the bug be re-assigned to one of those packages then and if so,
can you suggest which one?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVpsIAAAoJEOm1uwJp1aqDt58QAKBb/Fg8AGuscv9Vx+uJfrtM
0GX/xPunYrMkzUP5Sb/3a/Mixiio6/1NNeT+zsb2O2/qy1+wo/5LOksV9mi6gzft
0Jfqp6ZQ3mfdjNmNrY2YZ3Sclf4QBYpGXIYEGX8JeevQF+XjKO9eB+1yU1RlqkF1
QW9rSSOXn+liomPJyl4zb/3KSOPnEoTXc9CBFh/aU4M08OQX2bSY2qa1BSR+dUyQ
IqA7gjol8DZbLP3knvbTpa8dB7MbUQR0Scw2CUgfucvL23H+qETKIpPwwkm/1gYI
rX4e+1eR4jiG3o/i9daqXzJsgtJuFzv6ZHE0QGYz6ihFdwQFfU9bDLdJD0zIj+dj
1KPS2JoMZRTvedD7bi4rFy/Cuxau20noEmFCD1EToHQF9ifmLKbX+or3HX4KhBRS
UrLEECbPTiOzzkiFIvMO9sp8FUn+gEoeb9NzCiXWC0mss/2jne7z23yhkANwwpM/
RDUWYOBk4dbZHEK2yvCiwCwhO4sYX7gaXZ5mr5IaSnQ82aNU8Llw6efiSPjFl7no
ZbY5pABvVeuS4h+p2oNBycksMgR+Yc6Q3LKAiU7cRL2S2Jmj0h03dChp8WaLbJCk
gz3V1TSmX7CgXPPO2IX2AD6Z4klTeasHfOXGglsPV0+NsuagC3jEEBXgx/DqXrh5
EwNCi92AsPkp24hE/d6/
=VXRR
-END PGP SIGNATURE-


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

Bug#792535: makepasswd: Is GPL-2 licensed, but (explicitly) uses OpenSSL

[Julian Andres Klode]

Package: makepasswd
Version: 1.10-9
Severity: serious

The program in your package makes use of the OpenSSL
library, but is GPL-licensed. Depending on interpretation,
this might mean that the package is not redistributable.
(And a core dump of a process is definitely not distributable,
preventing debugging)

I'd advise switching to something else instead that
has a GPL-compatible license.

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

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

Versions of packages makepasswd depends on:
ii  libcrypt-openssl-random-perl  0.04-2+b1
ii  libcrypt-passwdmd5-perl   1.3-10
ii  perl  5.20.2-6

makepasswd recommends no packages.

makepasswd suggests no packages.

-- no debconf information

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.


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

Bug#790865: [htcondor-debian] Bug#790865: FTBFS: Error: Unknown float option `H'.

[Tim Theisen]

Thank you for the bug report. Our document specialist has constructed a 
slightly different patch. This has been incorporated into our official 
HTCondor source code. It will be in the 8.2.9 release which is expected 
at the end of the month.


...Tim

On 07/02/2015 08:34 AM, Martin Michlmayr wrote:

Package: condor
Version: 8.2.8~dfsg.1-1
Severity: serious
Tags: patch

condor fails to build because of the new tetex.

You're using the "H" float option.  According to
https://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions you
need \usepackage{float} for that, but it seems simpler solution is to
replace it with "!h" or "h".

I have attached one possible patch.


sbuild (Debian sbuild) 0.64.1 (13 Oct 2013) on m400-c2n1.hlinux.usa.hp.com

...

./misc/numbers.tex:18: LaTeX Error: Unknown float option `H'.
See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
  ...

l.18 \begin{table}[H]

Output written on ref.dvi (988 pages, 3400200 bytes).
Transcript written on ref.log.
Makefile:74: recipe for target 'ref.html' failed




___
htcondor-debian mailing list
htcondor-deb...@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian


--
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

diff --git a/doc/misc/numbers.tex b/doc/misc/numbers.tex
index 1d63c2e0fb56d489eda0b813889f8534b6aed963..722613b22f90d6a8cccb97220edf94acc88644fa 100644
--- a/doc/misc/numbers.tex
+++ b/doc/misc/numbers.tex
@@ -15,7 +15,7 @@ where the exit code is the value 100.
 Table~\ref{table:shadow-exit-codes} lists these codes.
 % shadow error codes
 \begin{center}
-\begin{table}[H]
+\begin{table}[ht]
 \caption{\label{table:shadow-exit-codes}\Condor{shadow} Exit Codes}
 \begin{tabular}{|c|l|l|} \hline
 \emph{Value} & \emph{Error Name} & \emph{Description} \\ \hline \hline
@@ -55,7 +55,7 @@ the first field within a job event log file.
 See more detailed descriptions of these values in
 section~\ref{sec:job-log-events}.
 \begin{center}
-\begin{table}[H]
+\begin{table}[ht]
 \caption{\label{table:user-log-event-codes}Event Codes in a Job Event Log}
 \begin{tabular}{|l|c|} \hline
 \emph{Event Code} & \emph{Description}   \\ \hline \hline
@@ -100,7 +100,7 @@ section~\ref{sec:job-log-events}.
 
 
 \begin{center}
-\begin{table}[H]
+\begin{table}[ht]
 \caption{\label{well-known-port-numbers}Well-Known Port Numbers}
 \begin{tabular}{|l|c|} \hline
 \emph{Server} & \emph{Port Number}   \\ \hline \hline
@@ -115,7 +115,7 @@ GT4 web services  &   8443  \\ \hline
 
 
 \begin{center}
-\begin{table}[H]
+\begin{table}[ht]
 \caption{\label{daemoncore-commands}DaemonCore Commands}
 \begin{tabular}{|l|c|} \hline
 \emph{Number} & \emph{Name}   \\ \hline \hline
@@ -144,7 +144,7 @@ GT4 web services  &   8443  \\ \hline
 
 
 \begin{center}
-\begin{table}[H]
+\begin{table}[ht]
 \caption{\label{daemon-exit-codes}DaemonCore Daemon Exit Codes}
 \begin{tabular}{|l|c|} \hline
 \emph{Exit Code} & \emph{Description}   \\ \hline \hline

Bug#790545: [htcondor-debian] Bug#790545: htcondor lacks python bindings in jessie

[Tim Theisen]

I'll be looking into this in the next few days.

...Tim

On 06/29/2015 10:09 PM, Nathan D. Smith wrote:

Package: htcondor
Severity: normal

Dear Maintainer,

htcondor-8.2.3~dfsg.1-6 is missing python bindings in jessie. Based on
the presence of the "enable_pythonbindings" patch in the Debian
tarball, I presume that this was unintentional.

Steps to reproduce:
Install htcondor
$ python

import htcondor

Traceback (most recent call last):
   File "", line 1, in 
ImportError: No module named htcondor
   



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/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)



--
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736


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

Bug#786566: [buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private

[Roger Leigh]

On 15/07/2015 17:47, Tyler Hicks wrote:

Hello - I'm sending a friendly poke in hopes that I can get a review for
my proposed patch. The unpatched behavior is a considerable usability
issue on systems that use systemd, schroot, and a filesystem mounted at
/home/$USER. I'd prefer upstream review before I apply the patch to
schroot in Ubuntu. Thanks!


It looks reasonable for you to apply in Ubuntu, but I'm not yet sure if 
it's safe to apply upstream.  It might well be safe for Debian as well, 
but I can't make that determination myself.


Is this safe to use on systems not using systemd?

Does it require a specific version of util-linux for the 
--make-[r]private options to mount?  If so, it probably needs a proper 
functional check for them, and using those as conditionals rather than 
just __linux__.



Regards,
Roger


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

Bug#792524: desktop crash

[Michael Biebl]

Am 15.07.2015 um 21:17 schrieb Daniel Pocock:
> 
>> That looks like a crash in the Xorg server originating in the 
>> (proprietary) nvidia driver.
> 
>> Any reason you filed this against gnome-session?
> 
> 
> The first line in the log comes from gnome-session and it is one
> second before the Xorg crash:
> 
> 
> 
> 19:36:19  gnome-session[2616]: (gnome-shell:10887): mutter-CRITICAL **:
> meta_window_focus: assertion '!window->override_redirect' failed
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: (EE) Backtrace:
> 
> 
> Does that line indicate that gnome-session (or something else) caused
> the crash?  Or it is just co-incidence or maybe just the Xorg logs
> coming more slowly?

That message is from mutter/gnome-shell. gnome-session is only
responsible for logging it.

-- 
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#778165: vxl: ftbfs with GCC-5

[Brett Johnson]

On 07/15/2015 01:48 PM, Andreas Tille wrote:
> The gcc5 build is now successful - I just created a package using gcc5.
> Thus the upload closed both RC bugs - basically thanks to your patch.

w00t! Good job! Glad I could help a little bit :).

-- 
Brett Johnson 


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

Bug#792528: dict-foldoc: please make the build reproducible

[Iustin Pop]

On 2015-07-15 20:26:43, Reiner Herrmann wrote:
> Source: dict-foldoc
> Version: 20150318-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: locale
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!
> 
> We noticed another variation in dict-foldoc.
> A different date is embedded depending on the language/locale.
> The attached patch fixes this by using the C locale.

Ah, interesting! Thanks for the patch. Will apply, but not right away -
the build for this package quite heavy so I'll batch it with some other
work.

thanks!
iustin


signature.asc
Description: Digital signature

Bug#778165: vxl: ftbfs with GCC-5

[Andreas Tille]

Hi Brett,

On Wed, Jul 15, 2015 at 11:35:39AM -0600, Brett Johnson wrote:
> 
> Oh, thanks Andreas, it's good to know the problem is not gcc5 related,
> nor caused by the patch I submitted. :).
> 
> It might be good to add #788559 as a block on this bug, as this
> one probably shouldn't be closed until there is a successful gcc5 build.

The gcc5 build is now successful - I just created a package using gcc5.
Thus the upload closed both RC bugs - basically thanks to your patch.

Kind regards
 
Andreas.

-- 
http://fam-tille.de


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

Bug#792534: ITP: pd-flext -- Flext C++ external layer for Pd (and similar)

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-flext
  Version : 0.5.1
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/flext/
* License : GPL
  Programming Lang: C++
  Description : Flext C++ external layer for Pd (and similar)

Flext is a C++ layer for programming externals for Pure Data (Pd)
as well as the proprietary Max/MSP.
It provides an object oriented abstraction layer to writing Pd objects.


pd-flext is a dependency of a number of pd-externals, that have not been
packaged up until now because pd-flext has been removed from the archives in
2009.
This is a second round for this nice API...


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

Bug#779920: [Debconf-devel] Bug#779920: Bug#779920: debconf: questions sourced from a template owned by another package block purge/install of other package

[Paul Gevers]

I have security issues with cacti that I am first trying to iron out. I
did my previous checks with the changes you proposed applied locally and
all seems to work just fine.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#792533: ITP: r-cran-bradleyterry2 -- GNU R package for using Bradley-Terry models

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist

* Package name: r-cran-bradleyterry2
  Version : 1.0-6
  Upstream Author : Heather Turner and David Firth
* URL : http://bradleyterry2.r-forge.r-project.org
* License : GPL-2.0+
  Programming Lang: R
  Description : GNU R package for using Bradley-Terry models

Specify and fit the Bradley-Terry model, including structured versions
in which the parameters are related to explanatory variables through a
linear predictor and versions with contest-specific effects, such as a
home advantage.


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

Bug#663126: sonata: deleting chars during filesystem search causes segfault

[Clément Calmels]

Hi,

This bug is already addressed here:
http://codingteam.net/project/sonata/bugs/show/1959

A patch is attached in this bug report:
http://codingteam.net/project/sonata/upload/bugs/0002-fix-1959-library-search-makes-sonata-crash.patch.fcdb9

I tested the patch and it corrects the segfault issue.

Regards,
C.


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

Bug#792519: systemd-logind fails to start on system using LDAP

[Felipe Sateler]

On 15 July 2015 at 16:09, Daniel Schepler  wrote:
> On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler 
> wrote:
>>
>> Hmm. Could you please attach the upgrade logs since some time before
>> the problems occurred?  Might network manager have been updated in the
>> meantime?
>
>
> Attaching /var/log/dpkg.log.  I think the first failed boot was 2015-07-08
> or 2015-07-09.  From the previous history, the last upgrade of dbus was:
>
> 2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1
>
>>
>> Also, how do you manage your connections?
>>
>> I also found this old redhat bug[1]. Could you try adding a conf
>> snippet to order the ldap components before dbus? Use systemctl edit
>>  and add Before=dbus.service.
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=502072
>
>
> OK, it will be a while before I can test it because I'm doing work using the
> machine right now.
>
> It would appear to me from the logs that NetworkManager can't successfully
> start before dbus is available - and I would probably want to make nslcd
> dependent on networking being up.  Would that mean that I'd have to set
> things up so it manually connects eth0 over DHCP, then starts nslcd, then
> starts dbus?  And then NetworkManager would be left only managing wlan0?
> And if so, where would I look for documentation on setting up the unit to
> connect eth0?  (Sorry for the last very basic question.)

I think (but I'm not sure) that nm will still connect without dbus
available yet, but it will of course not answer any dbus requests. So
it should only be necessary to order ldap before dbus.

However, this solution may prove brittle. Reading the linked redhat
bug there are two promsing suggestions:

1. Add 'bind_policy soft' to /etc/ldap.conf.
2. Set nss_initgroups_ignoreusers to at least
'root,dirsrv,gdm,rtkit,pulse,haldaemon,polkituser,avahi,dbus'

It seems the problem is that nss_ldap is trying to query ldap for
system users. That seems wrong to me, as the system should be able to
work without network.

-- 

Saludos,
Felipe Sateler


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

Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging

[Brad King]

On 06/23/2015 10:51 AM, Sylvestre Ledru wrote:
> I guess 3.6.1-1 didn't fix the issue... sorry about that.

For reference, upstream has made changes that affect the packaging of
CMake files for llvm 3.7.  See this thread/message for the changes
needed in Debian:

 [PATCH] Make CMake files generated by the Autoconf build system relocatable.
 http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/255502/focus=255724

That does not affect this issue for llvm 3.6 packaging though.

-Brad


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

Bug#792328: info: can no longer find the Emacs manual

[Eli Zaretskii]

> Date: Wed, 15 Jul 2015 20:08:47 +0200
> From: Vincent Lefevre 
> Cc: Norbert Preining , gavinsmith0...@gmail.com,
>   792...@bugs.debian.org, bug-texi...@gnu.org
> 
> > > Then one could do
> > >   info emacs-24::emacs
> > > etc?
> > 
> > Please don't make characters other than slashes magic in file names.
> > Next thing we will hear is someone asking how to use a file name with
> > a real colon.
> 
> However using a real colon in a filename may not be a good idea due
> to potential conflict with URL schemes, for programs that accept both
> filenames and URL's as arguments.

Users are entitled to do as they please, even if they are not good
ideas.


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

Bug#778135: syrthes: ftbfs with GCC-5

[Brett Johnson]

tags 778135 +patch
thanks

gcc5 has changed inline function semantics to match C99 standard,
but packages does not conform to C99. Fix by telling gcc to use
gnu89 standard instead.

--- syrthes-4.3.0-dfsg1.orig/debian/rules   2015-07-13 14:39:20.0 
+
+++ syrthes-4.3.0-dfsg1/debian/rules2015-07-15 19:05:11.228512040 +
@@ -4,6 +4,8 @@
 DPKG_EXPORT_BUILDFLAGS := yes
 include /usr/share/dpkg/buildflags.mk
 
+CFLAGS += -std=gnu89
+
 # Which MPI implementation (requested by libhdf5-mpi-dev)
 ifneq (,$(shell ls /usr/share/mpi-default-dev/debian_defaults))
 include /usr/share/mpi-default-dev/debian_defaults 

-- 
Brett Johnson 


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

Bug#792524: desktop crash

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


> That looks like a crash in the Xorg server originating in the 
> (proprietary) nvidia driver.
> 
> Any reason you filed this against gnome-session?
> 

The first line in the log comes from gnome-session and it is one
second before the Xorg crash:



19:36:19  gnome-session[2616]: (gnome-shell:10887): mutter-CRITICAL **:
meta_window_focus: assertion '!window->override_redirect' failed
19:36:20  gdm-Xorg-:0[1805]: (EE)
19:36:20  gdm-Xorg-:0[1805]: (EE) Backtrace:


Does that line indicate that gnome-session (or something else) caused
the crash?  Or it is just co-incidence or maybe just the Xorg logs
coming more slowly?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVprHaAAoJEOm1uwJp1aqDBOUQAI1jOp4FmRDfFbsW/ch0tZMC
LLd5jqrolzrN1T3bKp3cuM1SVmWkKgrbheB6lz9fJqOGsGP3gZWH9xq7Mty6LDNJ
HH93NSko0WVrT7y3eyLUOjt/dv323XdZSCJgRB0Rh1CRNIQsd/vIiqBETSRXfKJo
Ha2aZsX1ozEbJ9TKRl0X0/xDHl+bi1wINq99wCkY4zYYJJ/taiTd49WU1YN6iMLl
dr8r4zzvGR0dTc0V8v1ROmHxss6iLf4KLV6bbL6DiR9QkR0NaUkO4Ov9VKd/b4ot
kQ3Dm6+lYGty5vzwXnj0gt2DQkKL0rOM0NmlrtY4rda/2yVtI62/604uDXv71bL2
75mLby1Hpqne2MGlXl4JQUk7xxwEaI51/0V/s7A1FJLp07+iSpr89to7S6VCztyJ
sq0dVBFaAn10oqFNfIi4366WEbAsDcTCqkFWluUWzSQD4gKoALiQftjyiD7JwbqK
vGFUNqtQlT7ZGHJocf/BhJNCmweqEwvYDVX3IZDoChKscveI4s2PXoueqHcjFx5+
4ZBV5yfhO+teK8GprEvWYYdlP1i4fOoTG3Syr7wxvgAebCCor06veKYuy3bZVX3K
5gWudKpclp6TfxaG47XoQE4UPxGSI0pn2hRce7/i/woM008de4oLugwguanrX3Hi
Tcz3JAQAKczc/tNfdxvW
=n0uH
-END PGP SIGNATURE-


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

Bug#777837: Patch for GCC5 build issue

[Nicholas Luedtke]

tags 777837 + patch
thanks

Here's a fix for the GCC 5 build issue. I added "extern" to
inline function in jcode.c. The package builds and links with GCC 5 with 
this change.


Upstream may prefer to move to C99 instead, please see section
"Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Nicholas Luedtke
Linux for HP Helion OpenStack, Hewlett-Packard
--- ebview-0.3.6.2/src/jcode.c	2015-07-15 18:49:36.866726205 +
+++ jcode.c	2015-07-15 18:48:09.530726966 +
@@ -275,7 +275,7 @@
 	return(result);
 }
 
-inline gboolean isjisp(const gchar *buff){
+extern inline gboolean isjisp(const gchar *buff){
 g_assert(buff != NULL);
 
 if((buff[0] >= 0x21) && (buff[0] <= 0x74) &&

Bug#792524: desktop crash

[Michael Biebl]

Am 15.07.2015 um 19:50 schrieb Daniel Pocock:
> Package: gnome-session
> Version: 3.14.0-2
> Severity: serious
> 
> My whole desktop crashed and went back to the login screen.  It happened
> when I right clicked a link in a web site I was viewing with iceweasel.
> 
> This type of thing wasn't happening with wheezy / GNOME classic.
> 
> The log shows a message from gnome-session about 1 second before a crash
> in the X server.
> 
> 19:36:19  gnome-session[2616]: (gnome-shell:10887): mutter-CRITICAL **:
> meta_window_focus: assertion '!window->override_redirect' failed
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: (EE) Backtrace:
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x56)
> [0x7f0c91eb9d46]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 1: /usr/bin/Xorg
> (0x7f0c91d03000+0x1baf29) [0x7f0c91ebdf29]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
> (0x7f0c8f9f7000+0x35180) [0x7f0c8fa2c180]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 3:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x5cbfa6)
> [0x7f0c8a3ccfa6]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 4:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x5aa4b9)
> [0x7f0c8a3ab4b9]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 5:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x14eccf)
> [0x7f0c89f4fccf]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 6:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x150566)
> [0x7f0c89f51566]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 7:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x1514e6)
> [0x7f0c89f524e6]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 8:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x152f4f)
> [0x7f0c89f53f4f]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 9:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x149042)
> [0x7f0c89f4a042]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 10:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x153171)
> [0x7f0c89f54171]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 11:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x15510b)
> [0x7f0c89f5610b]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 12:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x12aa62)
> [0x7f0c89f2ba62]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 13:
> /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f0c89e01000+0x5962bd)
> [0x7f0c8a3972bd]
> 19:36:20  gdm-Xorg-:0[1805]: (EE) 14:
> /usr/lib/xorg/modules/extensions/libglx.so (0x7f0c8d678000+0x6f0c6b)
> [0x7f0c8dd68c6b]
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: (EE) Segmentation fault at address 0x0
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: Fatal server error:
> 19:36:20  gdm-Xorg-:0[1805]: (EE) Caught signal 11 (Segmentation fault).
> Server aborting
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:20  gdm-Xorg-:0[1805]: Please consult the The X.Org Foundation support
> 19:36:20  gdm-Xorg-:0[1805]: at http://wiki.x.org
> 19:36:20  gdm-Xorg-:0[1805]: for help.
> 19:36:20  gdm-Xorg-:0[1805]: (EE) Please also check the log file at
> "/var/log/Xorg.0.log" for additional information.
> 19:36:20  gdm-Xorg-:0[1805]: (EE)
> 19:36:21  gdm-Xorg-:0[1805]: (EE) Server terminated with error (1).
> Closing log file.


That looks like a crash in the Xorg server originating in the
(proprietary) nvidia driver.

Any reason you filed this against gnome-session?


-- 
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#792532: lynx: Add a CLI fail-safe option to specify a proxy (e.g. "--proxy")

[Jack Ryan]

Package: lynx
Version: 2.8.9dev1-2
Severity: wishlist

Dear Maintainer,

It is risky to rely on an environment variable to specify a proxy.
Any number of things can wrong, as we know from bug 791452.  E.g., a
user may think incorrectly that a proxy will be used, and have no idea
of any failure.

Having a commandline "--proxy" option would ensure that the users
expectation is known to the tool.  Then if anything is wrong with the
users syntax or something goes wrong with the proxy, lynx can fail
safely and print an error.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.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 lynx depends on:
ii  lynx-cur  2.8.9dev1-2+b1

lynx recommends no packages.

lynx suggests no packages.

-- no debconf information


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

Bug#792519: systemd-logind fails to start on system using LDAP

[Daniel Schepler]

On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler 
wrote:

> Hmm. Could you please attach the upgrade logs since some time before
> the problems occurred?  Might network manager have been updated in the
> meantime?
>

Attaching /var/log/dpkg.log.  I think the first failed boot was 2015-07-08
or 2015-07-09.  From the previous history, the last upgrade of dbus was:

2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1


> Also, how do you manage your connections?
>
> I also found this old redhat bug[1]. Could you try adding a conf
> snippet to order the ldap components before dbus? Use systemctl edit
>  and add Before=dbus.service.
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=502072


OK, it will be a while before I can test it because I'm doing work using
the machine right now.

It would appear to me from the logs that NetworkManager can't successfully
start before dbus is available - and I would probably want to make nslcd
dependent on networking being up.  Would that mean that I'd have to set
things up so it manually connects eth0 over DHCP, then starts nslcd, then
starts dbus?  And then NetworkManager would be left only managing wlan0?
And if so, where would I look for documentation on setting up the unit to
connect eth0?  (Sorry for the last very basic question.)
-- 
Daniel Schepler


dpkg.log.xz
Description: application/xz

Bug#792531: base: When I plug my mouse, I can't focus another window anymore

[Pierre Rudloff]

Package: base
Severity: normal

Hello,

When I plug my Mad Catz Rat 7 mouse, I can't click on everything outside the
currently focused window. The application with focus still accept mouse clicks,
but every other apps or desktop manager elements ignores clicks.

If I switch to another TTY screen then switch back to my desktop, everything
works fine.

Regards,



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

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


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

Bug#792530: mirrors: mirror submission for debian.redparra.com

[Donald Norwood]

Package: mirrors
Severity: wishlist


Hi again Donald,

I see that my request is still on validating process so I would like to change 
the 
Archive-architecture just to amd64 i386.

The reason for this change is that I see most of needed relays (based in 
bandwidth and use) 
are just for this 2 architectures and I think I will be able to offer a better 
service I I 
offer just this 2 architectures.

So do you want me to raise a new request or can you modify it?

Thanks

Luis Miguel Parra


2015-07-07 0:16 GMT+02:00 Luis Miguel Parra :

Hi,

I think the problem is solved now,

I need to change the Archive-upstream:to ftp.fr.debian.org


Please let me know if you see any other issue.

Thanks

Luis Miguel Parra

2015-07-06 13:43 GMT+02:00 Luis Miguel Parra :

Hi,

Thanks for your answer I am sorry my bad! The problem was I thought my master 
server had "all" and looks like 
just have the "amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 
kfreebsd-i386" I am working to get 
this fixed asap and I will answer you again. :)


Luis Miguel Parra
Redparra Administrator 


2015-07-01 20:15 GMT+02:00 Donald Norwood :

tag -1 +moreinfo

Hi,

Thank you for your support and mirroring Debian.

In checking your mirror there is a discrepancy between the archives in
your submission and those served in your directory:

Submission: All
Server: amd64, armel, hurd, i386, ia64,  kfreebsd-amd64, and  kfreebsd-i386

Could you please check your configuration?

On 06/20/2015 10:07 AM, Luis Miguel Parra wrote:
> Submission-Type: new
> Site: debian.redparra.com
> Aliases: mirrors.redparra.com
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc
> Archive-http: /debian/
> IPv6: no
> Archive-upstream: ftp.es.debian.org
> Updates: once
> Maintainer: Luis Miguel Parra 
> Country: ES Spain
> Location: España, Madrid
> Sponsor: Redparra Networks http://www.redparra.com
> Comment: Server status: http://status.redparra.com
>  Server bandwidth: 200Mbps
>
>
Best regards,

Donald Norwood


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

Bug#792519: systemd-logind fails to start on system using LDAP

[Felipe Sateler]

On 15 July 2015 at 15:30, Daniel Schepler  wrote:
> On Wed, Jul 15, 2015 at 11:15 AM, Felipe Sateler 
> wrote:
>>
>> On 15 July 2015 at 14:38, Daniel Schepler  wrote:
>> > On Wed, Jul 15, 2015 at 10:18 AM, Felipe Sateler 
>> > wrote:
>> >>
>> >> This contains a massive amount of:
>> >>
>> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: could not connect
>> >> to any LDAP server as (null) - Can't contact LDAP server
>> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: failed to bind to
>> >> LDAP server ldap://dirsrv.snt.loc: Can't contact LDAP server
>> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: reconnecting to
>> >> LDAP server (sleeping 1 seconds)...
>> >>
>> >> But with the service varying.
>> >>
>> >> I note that the NetworkManager service is started after many of those
>> >> messages. And after a while:
>> >>
>> >> Jul 15 09:35:09 deb-dschepler nscd[851]: nss_ldap: reconnected to LDAP
>> >> server ldap://dirsrv.snt.loc after 2 attempts
>> >> Jul 15 09:35:10 deb-dschepler ntpd[893]: Listen normally on 4 eth0
>> >> 10.10.3.14 UDP 123
>> >> Jul 15 09:35:10 deb-dschepler ntpd[893]: peers refreshed
>> >>
>> >>
>> >> So it looks like the problem is with your dns resolution?
>> >
>> >
>> > Of course, networking has to be up before nslcd can connect to the LDAP
>> > server.  But I didn't make any configuration changes related to this,
>> > and
>> > the setup was working just fine until last week.  Checking
>> > /var/log/dpkg.log, about the only other package upgrade which seems like
>> > it
>> > could be remotely related is the upgrade of dbus to 1.8.18-1 at the same
>> > time.
>> >
>> > When I check network connectivity within the broken boot, it appears
>> > that
>> > eth0 is left up and configured even through the constant restarts of
>> > NetworkManager; and "getent passwd" includes entries from LDAP.
>>
>> Hmm, these messages look relevant as well:
>>
>> Jul 15 09:35:31 deb-dschepler dbus[836]: [system] Activating systemd
>> to hand-off: service name='org.freedesktop.login1'
>> unit='dbus-org.freedesktop.login1.service'
>> Jul 15 09:35:33 deb-dschepler dbus[836]: [system] Failed to activate
>> service 'org.freedesktop.nm_dispatcher': timed out
>>
>> Type=dbus units like bluetooth and avahi are also failing. Could you
>> test downgrading dbus?
>>
>> DBus being problematic could also account for your post-login woes.
>
>
> Whoops, it looks like I actually had dbus 1.8.18-1 installed since before
> 2015-07-01 when my dpkg.log starts - which is well before the boot failures
> started.  I must have been reading dpkg.log too quickly before and seeing
> trigger entries for dbus.  Sorry about that.

Hmm. Could you please attach the upgrade logs since some time before
the problems occurred?  Might network manager have been updated in the
meantime?

Also, how do you manage your connections?

I also found this old redhat bug[1]. Could you try adding a conf
snippet to order the ldap components before dbus? Use systemctl edit
 and add Before=dbus.service.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=502072



-- 

Saludos,
Felipe Sateler


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

Bug#792328: (fwd) Bug#792328: info: can no longer find the Emacs manual

[Gavin Smith]

On 15 July 2015 at 19:50, Gavin Smith  wrote:
> Here's my attempt at making this work
Attached this time.
Index: ChangeLog
===
--- ChangeLog	(revision 6432)
+++ ChangeLog	(working copy)
@@ -1,5 +1,21 @@
 2015-07-15  Gavin Smith  
 
+	* info/nodes.c (info_find_file): If filename has slash, look for
+	it in search path if it does not begin "./".
+	* info/filesys.c (info_find_fullpath): Don't look for a filename 
+	beginning "./" in the search path, but otherwise look for the 
+	filename in the search path even if it contains a slash.
+	(info_file_find_next_in_path): Prefix returned path with "./" if 
+	it is relative to the current directory.
+	(info_add_extension): Allow second argument to be null.
+
+	* info/info.c (main) <--file or slash in argument>: If argument 
+	not an absolute path, prefix it with "./".  Call 
+	info_add_extension instead of info_find_fullpath for arguments 
+	other than simple filenames.
+
+2015-07-15  Gavin Smith  
+
 	* info/t/dir-entry-to-subdir.sh: New test.
 
 2015-07-15  Gavin Smith  
Index: info/filesys.c
===
--- info/filesys.c	(revision 6430)
+++ info/filesys.c	(working copy)
@@ -77,8 +77,7 @@ static COMPRESSION_ALIST compress_suffixes[] = {
   { NULL, NULL }
 };
 
-/* Expand the filename in PARTIAL to make a real name for this operating
-   system.  This looks in INFOPATH in order to find the correct file.
+/* Look for the filename PARTIAL in INFOPATH in order to find the correct file.
Return file name and set *FINFO with information about file.  If it
can't find the file, it returns NULL, and sets filesys_error_number.
Return value should be freed by caller. */
@@ -101,7 +100,8 @@ info_find_fullpath (char *partial, struct stat *fi
   /* IS_SLASH and IS_ABSOLUTE defined in ../system.h. */
 
   /* If path is absolute already, see if it needs an extension. */
-  if (IS_ABSOLUTE (partial))
+  if (IS_ABSOLUTE (partial)
+  || partial[0] == '.' && IS_SLASH(partial[1]))
 {
   fullpath = info_add_extension (0, partial, finfo);
 }
@@ -113,12 +113,6 @@ info_find_fullpath (char *partial, struct stat *fi
   fullpath = info_add_extension (0, partial, finfo);
 }
 
-  /* If filename has a slash in it (for example, begins with "./" or "../", or
- if there are intermediate directories) interpret it as relative to current
- directory.  This may be from the command line, or in the subfiles table of
- a split file. */
-  else if (HAS_SLASH (partial))
-fullpath = info_add_extension (0, partial, finfo);
   /* If just a simple name element, look for it in the path. */
   else
 fullpath = info_file_in_path (partial, finfo);
@@ -168,11 +162,24 @@ info_file_find_next_in_path (char *filename, int *
   with_extension = info_add_extension (dirname, filename, finfo);
 
   if (with_extension)
-return with_extension;
+{
+  if (!IS_ABSOLUTE (with_extension))
+{
+  /* Prefix "./" to it. */
+  char *s;
+  asprintf (&s, "%s%s", "./", with_extension);
+  free (with_extension);
+  return s;
+}
+  else
+return with_extension;
+}
 }
   return NULL;
 }
 
+/* Return full path of first Info file known as FILENAME in
+   search path.  If relative to current directory, precede it with './'. */
 static char *
 info_file_in_path (char *filename, struct stat *finfo)
 {
@@ -189,7 +196,11 @@ info_add_extension (char *dirname, char *filename,
 {
   char *try_filename;
   register int i, pre_suffix_length = 0;
+  struct stat dummy;
 
+  if (!finfo)
+finfo = &dummy;
+
   if (dirname)
 pre_suffix_length += strlen (dirname);
 
Index: info/info.c
===
--- info/info.c	(revision 6430)
+++ info/info.c	(working copy)
@@ -825,7 +825,7 @@ There is NO WARRANTY, to the extent permitted by l
  for a matching entry. */
   if (!user_filename && argv[0] && HAS_SLASH (argv[0]))
 {
-  user_filename = argv[0];
+  user_filename = xstrdup (argv[0]);
   argv++; /* Advance past first remaining argument. */
   argc--;
 }
@@ -873,7 +873,7 @@ There is NO WARRANTY, to the extent permitted by l
   /* --all */
   if (!user_filename && argv[0])
 {
-  user_filename = argv[0];
+  user_filename = xstrdup (argv[0]);
   argv++; argc--;
 }
   else if (!user_filename)
@@ -904,10 +904,29 @@ There is NO WARRANTY, to the extent permitted by l
   /* User used "--file". */
   if (user_filename)
 {
-  initial_file = info_find_fullpath (user_filename, 0);
-  if (!initial_file && filesys_error_number)
-error = filesys_error_string (user_filename, filesys_error_number);
+  if (!IS_ABSOLUTE(user_filename) && HAS_SLASH(user_filename)
+

Bug#792328: (fwd) Bug#792328: info: can no longer find the Emacs manual

[Gavin Smith]

On 15 July 2015 at 00:23, Norbert Preining  wrote:
> down here at Debian a certain inconvenience has arrived: Namely that
> info cannot follow links to info files in sub-directories it seems:
> In our case this is the emacs manual in the emacs-24 subdirectory:
> /usr/share/info/emacs-24/emacs.info.gz
>
> The respective dir entry looks like
> * Emacs: (emacs-24/emacs).  The extensible self-documenting text 
> editor.
> but trying to enter into that node gives:
> emacs-24/emacs: No such file or directory

Here's my attempt at making this work, which internally prefixes file
paths with "./" when they truly are relative to the current directory
and should not be looked up in the search path.

Hopefully this applies without much trouble to Texinfo 6.0. It would
be great if people would test this patch and post if it works, then we
should be able to amend this patch if necessary and get an acceptable
fix.


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

Bug#778128: spectools: ftbfs with GCC-5

[Raphael Hertzog]

On Wed, 15 Jul 2015, Francois Marier wrote:
> I'm not going to be able to do it for another week or so. Feel free to
> upload now.

Thanks, doing it now.

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


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

Bug#792529: tomatoes: please make the build reproducible

[Reiner Herrmann]

Source: tomatoes
Version: 1.55-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that tomatoes could not be built reproducibly.
The build date is embedded into the binary.

The attached patch fixes this by using the date from the latest entry
in the changelog instead.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds

diff --git a/debian/rules b/debian/rules
index 25f2641..2a03e55 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-DEBIAN_RULES_VERSION = \"$(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ')\ $(shell date --rfc-3339=date)\"
+DEBIAN_RULES_VERSION = \"$(shell dpkg-parsechangelog -S Version)\ $(shell date -u --rfc-3339=date -d \"$(shell dpkg-parsechangelog -S Date)\")\"
 export DEB_CFLAGS_MAINT_APPEND += `sdl-config --cflags` -DVERSION=$(DEBIAN_RULES_VERSION)
 export DEB_LDFLAGS_MAINT_APPEND += `sdl-config --libs` -lSDL_image -lSDL_mixer -lGL -lGLU
 


signature.asc
Description: OpenPGP digital signature

Bug#792433: dgit sbuild should not failed without build-deps

[Ian Jackson]

PICCA Frederic-Emmanuel writes ("Bug#792433: dgit sbuild should not failed 
without build-deps"):
> >   dgit -wg sbuild
> 
> Yes it works.

OK, thanks.

Ian.


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

Bug#792519: systemd-logind fails to start on system using LDAP

[Daniel Schepler]

On Wed, Jul 15, 2015 at 11:15 AM, Felipe Sateler 
wrote:

> On 15 July 2015 at 14:38, Daniel Schepler  wrote:
> > On Wed, Jul 15, 2015 at 10:18 AM, Felipe Sateler 
> > wrote:
> >>
> >> This contains a massive amount of:
> >>
> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: could not connect
> >> to any LDAP server as (null) - Can't contact LDAP server
> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: failed to bind to
> >> LDAP server ldap://dirsrv.snt.loc: Can't contact LDAP server
> >> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: reconnecting to
> >> LDAP server (sleeping 1 seconds)...
> >>
> >> But with the service varying.
> >>
> >> I note that the NetworkManager service is started after many of those
> >> messages. And after a while:
> >>
> >> Jul 15 09:35:09 deb-dschepler nscd[851]: nss_ldap: reconnected to LDAP
> >> server ldap://dirsrv.snt.loc after 2 attempts
> >> Jul 15 09:35:10 deb-dschepler ntpd[893]: Listen normally on 4 eth0
> >> 10.10.3.14 UDP 123
> >> Jul 15 09:35:10 deb-dschepler ntpd[893]: peers refreshed
> >>
> >>
> >> So it looks like the problem is with your dns resolution?
> >
> >
> > Of course, networking has to be up before nslcd can connect to the LDAP
> > server.  But I didn't make any configuration changes related to this, and
> > the setup was working just fine until last week.  Checking
> > /var/log/dpkg.log, about the only other package upgrade which seems like
> it
> > could be remotely related is the upgrade of dbus to 1.8.18-1 at the same
> > time.
> >
> > When I check network connectivity within the broken boot, it appears that
> > eth0 is left up and configured even through the constant restarts of
> > NetworkManager; and "getent passwd" includes entries from LDAP.
>
> Hmm, these messages look relevant as well:
>
> Jul 15 09:35:31 deb-dschepler dbus[836]: [system] Activating systemd
> to hand-off: service name='org.freedesktop.login1'
> unit='dbus-org.freedesktop.login1.service'
> Jul 15 09:35:33 deb-dschepler dbus[836]: [system] Failed to activate
> service 'org.freedesktop.nm_dispatcher': timed out
>
> Type=dbus units like bluetooth and avahi are also failing. Could you
> test downgrading dbus?
>
> DBus being problematic could also account for your post-login woes.
>

Whoops, it looks like I actually had dbus 1.8.18-1 installed since before
2015-07-01 when my dpkg.log starts - which is well before the boot failures
started.  I must have been reading dpkg.log too quickly before and seeing
trigger entries for dbus.  Sorry about that.
-- 
Daniel Schepler

Bug#792528: dict-foldoc: please make the build reproducible

[Reiner Herrmann]

Source: dict-foldoc
Version: 20150318-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

We noticed another variation in dict-foldoc.
A different date is embedded depending on the language/locale.
The attached patch fixes this by using the C locale.

Regards,
 Reiner

diff --git a/debian/rules b/debian/rules
index 15f7401..9d92e07 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ build-stamp:
 	set -ex ; \
 	uver=$$(dpkg-parsechangelog |\
 	sed -rn -e 's/^Version: ([0-9]+)-.*$$/\1/p') ; \
-	udate=$$(date -d "$$uver" +"%d %B %Y"); \
+	udate=$$(LC_ALL=C date -d "$$uver" +"%d %B %Y"); \
 	perl debian/condense newdict | \
 	  /usr/bin/dictfmt -f --headword-separator %%% --break-headwords \
 	  --allchars -u http://foldoc.org/Dictionary.gz \


signature.asc
Description: OpenPGP digital signature

Bug#792527: presage tests fails when built with GCC 5

[Matthias Klose]

Package: src:presage
Version: 0.9-1
Severity: important
Tags: sid stretch fixed-upstream
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-5

presage tests fails when built with GCC 5, not seen with the 0.9.1 upstream 
version.

make  check-TESTS
make[7]: Entering directory '/«PKGBUILDDIR»/test/lib/core'
make[8]: Entering directory '/«PKGBUILDDIR»/test/lib/core'
../../../test-driver: line 107: 31324 Segmentation fault  "$@" > $log_file 
2>&1
FAIL: coreTestRunner

Testsuite summary for presage 0.9

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See test/lib/core/test-suite.log
Please report to matteo.vesc...@yahoo.co.uk

make[8]: *** [test-suite.log] Error 1


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

Bug#792433: dgit sbuild should not failed without build-deps

[PICCA Frederic-Emmanuel]

>   dgit -wg sbuild


Yes it works.

Thanks

Frederic

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

Bug#792518: Manual page for the docker-compose executable is missing

[Carl Chenet]

On 15/07/15 19:21, Felipe Sateler wrote:
> Control: severity -1 wishlist
> Control: tags -1 newcomer upstream
> 
> On 15 July 2015 at 11:26, Carl Chenet  wrote:
>> Package: docker-compose
>> Version: 1.3.1-1
>> Severity: serious
>>
>> The manual page for the docker-compose executable is missing.
> 
> Upstream unfortunately does not have a man page. I welcome patches
> converting the current cli.md to a man page, but I will not spend time
> on this.

You should care, it's not pedantic, it's not a wishlist (a manual page
is not a feature request or really difficult to implement [1]), it's a
bug per Debian Policy Manual and should be reported to the upstream.

"If no manual page is available, this is considered as a bug and should
be reported to the Debian Bug Tracking System (the maintainer of the
package is allowed to write this bug report themselves, if they so
desire). Do not close the bug report until a proper man page is
available.[110]" [2]

Here is a page with information about the manual pages [3].

[1] : https://www.debian.org/Bugs/Developer
[2] : https://www.debian.org/doc/debian-policy/ch-docs.html
[3] : https://qa.debian.org/man-pages.html

Regards,
-- 
Carl Chenet

Blog : https://carlchenet.com
https://identi.ca/carlchenet | https://twitter.com/carl_chenet
FOSS contributions : https://www.ohloh.net/accounts/chaica


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

Bug#780996: kscreen: Prevents using "xset dpms force suspend"

[Thibaut Renaux]

After an unrelated system reinstall, I've noticed that Kscreen does work 
as intended and allows the screen to sleep.


However, after I installed bumblebee/primus for my Nvidia card, the 
behavior I described in the bug report shows up again, and the screen 
can't be put to sleep unless Kscreen is disabled.


Should I open a new bug on the bumblebee package instead of here?


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

Bug#778020: Patch for GCC 5 build issue

[Josh Gadeken]

tags 778020 + patch
thanks

Here's a fix for the GCC 5 build issue. I added "-std=gnu89" to 
CMakeLists.txt. The package builds and links with GCC 5 with this change.


Upstream may prefer to move to C99 instead, please see section
"Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Josh Gadeken
Linux for HP Helion OpenStack, Hewlett-Packard
Description: Resolve GCC5 build errors.
 Add "-std=gnu89 to CMAKE_C_FLAGS in CMakeLists.txt"
 .
 mz (0.40-1.1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Resolve GCC5 build errors.
Author: Joshua Gadeken 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- mz-0.40.orig/CMakeLists.txt
+++ mz-0.40/CMakeLists.txt
@@ -5,7 +5,7 @@ if(COMMAND cmake_policy)
 	cmake_policy(SET CMP0003 NEW)
 endif(COMMAND cmake_policy)
 
-SET(CMAKE_C_FLAGS "-Wall -pipe -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables")
+SET(CMAKE_C_FLAGS "-Wall -pipe -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables -std=gnu89")
 
 ADD_CUSTOM_TARGET(uninstall
 	COMMAND ${CMAKE_COMMAND} -E echo Use 'xargs rm < install_manifest.txt' to uninstall this program

Bug#792433: dgit sbuild should not failed without build-deps

[Ian Jackson]

Control: tags 792433 - patch

Ian Jackson writes ("Re: Bug#792433: dgit sbuild should not failed without 
build-deps"):
> PICCA Frederic-Emmanuel writes ("Bug#792433: dgit sbuild should not failed 
> without build-deps"):
> > by -D what do you mean exactly, replace the -d by -D in the patch ?
> 
> I mean this rune
> 
>   LANG=C dgit -D sbuild --clean=git

Oh, I am an idiot.

The problem here is that you are passing --clean=git after sbuild.
But arguments after `sbuild' are passed to sbuild.  So dgit thinks
--clean=git is an sbuild option.  You don't discover this because you
don't get as far as running sbuild (which would, naturally, complain).

I think

   dgit -wg sbuild

ought to work for you.  (Without the patch I previously sent you.)


Having discovered that sid's dpkg-buildpackage -S insists on
build-deps, I now think it isn't right to have dgit override that.  So
I won't be releasing that patch.

Instead I think I will provide an option to more conveniently provide
-d to dpkg-buildpackage, and I will add something to the docs.

Ian.


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