Bug#737953: itstool: FTBFS: configure: error: no suitable Python interpreter found

[Daniel Schepler]

Source: itstool
Version: 2.0.2-1
Severity: serious

>From my pbuilder build log:

...
 debian/rules build
dh build
   dh_testdir
   dh_auto_configure
configure: WARNING: unrecognized options: --disable-maintainer-mode, 
--disable-dependency-tracking
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version >= 2.6... none
configure: error: no suitable Python interpreter found
==> config.log <==
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by itstool configure 2.0.2, which was
generated by GNU Autoconf 2.66.  Invocation command line was

  $ ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir=${prefix}/share/man 
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--libexecdir=${prefix}/lib/itstool --disable-maintainer-mode 
--disable-dependency-tracking

## - ##
## Platform. ##
## - ##

hostname = frobozz
uname -m = x86_64
uname -r = 3.11-1-amd64
uname -s = Linux
uname -v = #1 SMP Debian 3.11.6-1+x32 (2013-10-29)

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin


## --- ##
## Core tests. ##
## --- ##

configure:1720: checking for a BSD-compatible install
configure:1788: result: /usr/bin/install -c
configure:1799: checking whether build environment is sane
configure:1849: result: yes
configure:1990: checking for a thread-safe mkdir -p
configure:2029: result: /bin/mkdir -p
configure:2042: checking for gawk
configure:2072: result: no
configure:2042: checking for mawk
configure:2058: found /usr/bin/mawk
configure:2069: result: mawk
configure:2080: checking whether make sets $(MAKE)
configure:2102: result: yes
configure:2223: checking for a Python interpreter with version >= 2.6
configure:2240: python -c import sys # split strings by '.' and convert to 
numeric. Append some zeros # because we need at least 4 digits for the hex 
conversion. # map returns an iterator in Python 3.0 and a list in 2.x minver = 
list(map(int, '2.6'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not 
present in Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < minverhex)
./configure: line 2241: python: command not found
configure:2243: $? = 127
configure:2240: python2 -c import sys # split strings by '.' and convert to 
numeric. Append some zeros # because we need at least 4 digits for the hex 
conversion. # map returns an iterator in Python 3.0 and a list in 2.x minver = 
list(map(int, '2.6'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not 
present in Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < minverhex)
./configure: line 2241: python2: command not found
configure:2243: $? = 127
configure:2240: python3 -c import sys # split strings by '.' and convert to 
numeric. Append some zeros # because we need at least 4 digits for the hex 
conversion. # map returns an iterator in Python 3.0 and a list in 2.x minver = 
list(map(int, '2.6'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not 
present in Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < minverhex)
./configure: line 2241: python3: command not found
configure:2243: $? = 127
configure:2240: python3.0 -c import sys # split strings by '.' and convert to 
numeric. Append some zeros # because we need at least 4 digits for the hex 
conversion. # map returns an iterator in Python 3.0 and a list in 2.x minver = 
list(map(int, '2.6'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not 
present in Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < minverhex)
./configure: line 2241: python3.0: command not found
configure:2243: $? = 127
configure:2240: python2.5 -c import sys # split strings by '.' and convert to 
numeric. Append some zeros # because we need at least 4 digits for the hex 
conversion. # map returns an iterator in Python 3.0 and a list in 2.x minver = 
list(map(int, '2.6'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not 
present in Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < minverhex)
./configure: line 2241:

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Jan Nordholz]

Hi Daniel,

> I agree this is a bad error message for the situation where the digest
> isn't supported.
> 
> Have you tested this against libgnutls28?  GnuTLS 3.2.10-2 is the latest
> version in jessie and sid, and 3.2.8.1-2~bpo70+1 is in wheezy-backports.
>  I believe you'll find it resolved in this version.

well, I tested against gnutls-serv, which indeed seems to work (and that
one's linked to gnutls28). However my original problem occurred with exim,
and I was reluctant to recompile those packages as I don't know how much of
the gnutls API has changed and would need fixing in exim.

Good to know that the library migration will eventually take care of this.


Thanks,

Jan


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

Bug#737884: debian-handbook: typo in Appendix B.2.2

[Raphael Hertzog]

Hello,

On Thu, 06 Feb 2014, Anders Jonsson wrote:
> Dear Maintainer,
> having finished reading the Debian Administrator's Handbook I found
> one more typo.
> This time in Appendix B.2.2 (The User's Home Directory).
> "Traditionnally" should be replaced by "Traditionally". The attached
> patch fixes the typo in all places.

Thanks, applied.

> Thank you for writing this book! It was very informative.

It would be nice if you could write a review and share it somewhere
(on a blog, on google+ or whatever you happen to use) and then share
the link with me. :)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ 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#736760: debian/upstream vs. debian/upstream/signing-key.pgp

[Andreas Tille]

Hi James,

thanks for your patch.  While this is welcome I guess this is the least
of Charles' problems.  I guess he was more concerned about the umegaya
package which probably needs some more love than the simple shell
script.  We also need to fix the UDD importer (but this is similarly
easy to do like the patch you provided) and lintian check for upstream
metadata files.

I keep on wondering if we are doing the right thing to not include
debian-devel into this discussion.  IMHO it does have an additional
advantage to talk about this since this would enhance the awareness of
readers to both things - the debian/upstream directory with the
signature you just included and the metadata.  It could not harm if
people might learn about this since you could conclude from your own
experience if not knowing the debian/upstream file that people just
do not know about things that exist for years.

So I'm tempted to move this thread to debian-devel if nobody else will
be faster.

Kind regards

  Andreas.

On Fri, Feb 07, 2014 at 12:47:30AM -0500, James McCoy wrote:
> On Mon, Feb 03, 2014 at 09:48:43PM -0500, James McCoy wrote:
> > On Sun, Feb 02, 2014 at 11:44:51AM +0900, Charles Plessy wrote:
> > > Le Thu, Jan 30, 2014 at 05:06:22PM +0100, Andreas Tille a écrit :
> > > >   * working on the needed changes for UDD machine readable files 
> > > > gatherer
> > 
> > Attached patch should allow that to work on both debian/upstream and
> > debian/upstream/metadata, which is a name I've heard suggested and what
> > first came to mind when the issue was initially raised.
> 
> Updated patch attached which fixes detection of debian/upstream/metadata
> in git repositories.

-- 
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#737952: nmu: gammaray_1.3.0-1

[Felix Geyer]

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

gammaray was sitting in NEW for a while so on amd64 it's still
built against Qt 5.2 (depends on libqt5core5 and qtbase-abi-5-1-0).
Please schedule a binNMU for gammaray:

nmu gammaray_1.3.0-1 . amd64 . -m "Rebuild against Qt 5.2."


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

Bug#737950: Actually it's not even ncurses, supposedly just cli but ends up with imagemagick, libx*, and ghostscript

[Daniel Dickinson]

Actually it's not even ncurses, supposedly just cli but ends up with
imagemagick, libx*, and ghostscript



signature.asc
Description: OpenPGP digital signature

Bug#736721: Incorrect dependencies

[Dmitry Shachnev]

Hi Clint,

See http://docs.python.org/3/library/ctypes.html for description of
how ctypes works. As Python programs are interpreted, the only way to
access external shared libraries from Python code is by dlopen()ing
them. By looking at attic code, it only accesses libc (in xattr.py)
and libcrypto (in attic/crypto.py).

Of course, this is not the best practice, a simplier solution will be
to use existing modules like python-xattr and python-crypto, or
writing a Python extension where you can use C code.

--
Dmitry Shachnev

On Thu, Feb 6, 2014 at 9:00 PM, Clint Adams  wrote:
> On Sun, Jan 26, 2014 at 01:04:09PM +0100, Jonas Borgström wrote:
>> Attic uses ctypes to interact with libcrypto and does not use
>> python3-openssl. So the python3-openssl dependency should be replaced
>> with a dependency on libssl1.0.0.
>
> I assume this means this cdll thing is calling dlopen() on
> libcrypto.  Maybe one of the Python folks can tell me how to detect
> that and correlate it with shlibs in an automated fashion, or better
> yet adopt the package.


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

Bug#737951: mdadm: udev rules files ignores raid=noautodetect kernel parameter

[Michael Tokarev]

Control: tag -1 + moreinfo
Control: severity -1 wishlist

07.02.2014 11:21, Michael Prokop wrote:
> Package: mdadm
> Version: 3.3-2
> Severity: normal
> 
> Quoting from kernel's Documentation/md.txt:
> 
> , [ https://www.kernel.org/doc/Documentation/md.txt ]
> | Boot time autodetection of RAID arrays
> | --
> |
> | When md is compiled into the kernel (not as module), partitions of
> | type 0xfd are scanned and automatically assembled into RAID arrays.
> | This autodetection may be suppressed with the kernel parameter
> | "raid=noautodetect".  As of kernel 2.6.9, only drives with a type 0
> | superblock can be autodetected and run at boot time.
> `
> 
> The udev rules file /lib/udev/rules.d/64-md-raid-assembly.rules
> shipped by mdadm ignores that kernel parameter and tries to assemble
> mdadm RAIDs without honoring the raid=noautodetect setting.
> 
> It would be nice if there would be some way (maybe just checking for
> raid=noautodetect in /proc/cmdline?) to disable auto assembly
> without having to manually delete/override the udev file.

I don't think that using raid=noautodetect is a good way of doing
this.  It is for the really obsolete in-kernel array assembly, and
it is described as such in the documentation you quoted above.

In debian we have another parameter in initrd, --

  mdassemble=all|none|list

which is copied from a debconf question.  Maybe this one is better
suited for this need, at least it is more flexible.  It is sort
of trivial to get this parameter from kernel command line in the
initrd script.

But.

It is all about early-boot environment.

None of these parameters, at my point of view, should be considered
after pre-boot is done and we're in the main system.  If you're
talking about main udev rules of mdadm, I disagree, there should
be entirely separate option, if at all.

What is your usage case?  What are you trying to achieve?

Note that we're moving (very slow) towards assembling everything
using those rules, including your boot arrays, so if you disable
those, your system wont boot anymore.

Adding linux-raid list to Cc.  Please describe your situation
in more detail, and maybe together we will be able to come to
some solution.

Marking your bugreport as a wishlist for now in debian.

Thanks,

/mjt


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

Bug#727708: Call for votes on init system resolution

[Russ Allbery]

Adrian Bunk  writes:

> Leaving tactical aspects aside, IMHO the important point is that there
> is a compromise line that seems reasonable for all members of the TC:

> For the upstart side of the TC, the most important question is T/L.
> For the systemd side of the TC, the most important question is D/U.

I don't agree with this analysis.

I consider the L option as currently written to be a commitment to a
course of action that is technically broken and unsustainable.  I also
think the effect of L is contrary to its intended goal and will make it
less likely, not more likely, that Debian will provide working support for
any init system other than the default in the long run.  (More on that
below.)

L is only "less important" to me because I believe it is unworkable and
unimplementable in the long run, so it doesn't matter *that* much if it
wins, since it will naturally get dropped over time.  Eventually, package
maintainers will realize that the sysvinit scripts everyone has been
keeping around to give lip service to L don't actually work and aren't
actually maintained, and it will end up like other similar Debian features
that are "required" but uninteresting to nearly everyone and therefore
bitrot and are effectively non-functional.

L will cause less short-term damage with systemd as the default init than
with upstart or OpenRC as the default init, so I'm grudgingly willing to
vote DL above FD because the results wouldn't be quite as absurd as the
results of UL would be, but I'm quite far from happy with it.  In
practice, I expect any of the L options to require another round of this
discussion post-jessie to get rid of L again so that we can move forward
without keeping sysvinit scripts.  I certainly hope they will, since the
alternative is to have a decision on the books that maintainers are
supposed to comply with but, in practice, won't, which is an embarassing
and annoying situation to be in.

L makes it less likely that Debian will support anything other than the
default init system in the long run because it undermines the process of
adding native configuration for non-default init systems.  If we said that
packages are required to support the default init system and strongly
encouraged to merge support for those with active communities, I think we
still wouldn't get 100% archive coverage for the non-default, but I do
think we'd get coverage for most or all of the packages that people using
the non-default init system care the most about.  That would probably be
in the form of native configurations for the init systems that people care
about, since all the native configurations are simpler and easier to
maintain than sysvinit scripts.  Packages would then depend on the set of
init systems that they support.  I think that's about the best solution we
can hope for in the long run: strong support for the default init system,
and workable but incomplete support for the other init systems, with clear
indication in the package dependency structure of what init systems are
supported.

L instead requires everyone maintain sysvinit scripts forever, even if
they never use them.  That (a) significantly reduces the incentive to add
the superior native configuration for whatever of systemd, upstart, or
OpenRC are not the default, since it's "handled" by the sysvinit script,
and (b) makes it much less likely that those configurations will actually
be maintained since they're complicated and annoying to try to debug and
harder to write "blind" without running them.  So I believe L is directly
destructive to the stated motives of the people who are in favor of L,
which is one of the reasons why it boggles me that it has so much support.

My preference would be to vote on Bdale's ballot, and I'm unhappy that we
didn't just continue with that vote.  However, I'm almost entirely out of
spoons to keep arguing wording and procedural issues, and I think we're at
the point where this process is starting to cause active damage by
continuing to drag on.  But apparently I'm failing to keep my mouth shut,
so, well, here you go.

Neither T nor L actually imply what I think will happen in practice.  The
T option gives explicit blessing to adding dependencies on non-default
init systems, which I think is something that's only appropriate on a
case-by-case basis for edge packages and cooperating package groups and
isn't appropriate general advice.  It also doesn't distinguish between
right now and after the jessie release, which I think is inappropriate.  I
think there's a huge difference between depending on an init system right
now for the jessie release, which is something I think we should only do
if there's really no technical alternative available at all, and depending
on an init system or set of init systems after jessie, which I think is a
reasonable way of handling the long-term migration path away from
supporting sysvinit scripts.

I tried to raise these issues multiple times and was roundly ignored, so I
gave up 

Bug#737951: mdadm: udev rules files ignores raid=noautodetect kernel parameter

[Michael Prokop]

Package: mdadm
Version: 3.3-2
Severity: normal


Quoting from kernel's Documentation/md.txt:

, [ https://www.kernel.org/doc/Documentation/md.txt ]
| Boot time autodetection of RAID arrays
| --
|
| When md is compiled into the kernel (not as module), partitions of
| type 0xfd are scanned and automatically assembled into RAID arrays.
| This autodetection may be suppressed with the kernel parameter
| "raid=noautodetect".  As of kernel 2.6.9, only drives with a type 0
| superblock can be autodetected and run at boot time.
`

The udev rules file /lib/udev/rules.d/64-md-raid-assembly.rules
shipped by mdadm ignores that kernel parameter and tries to assemble
mdadm RAIDs without honoring the raid=noautodetect setting.

It would be nice if there would be some way (maybe just checking for
raid=noautodetect in /proc/cmdline?) to disable auto assembly
without having to manually delete/override the udev file.

regards,
-mika-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014-02-07t08-14...@devnull.michael-prokop.at

Bug#737950: nmap: Unexpectedly heavy dependencies through liblinear1 recommending liblinear-tools (gnuplot/ghostscript/imagemagick/fontconfig/libx*/hicolor-icon-theme)

[Daniel Dickinson]

Package: nmap
Version: 6.00-0.3+deb7u1
Severity: minor

nmap as an ncurses-based command line network discovery tool has some heavy and 
unexpected dependencies since Debian has made installation of 'Recommends' the 
default for packages

nmap Depends on liblinear1
liblinear1 Recommends liblinear-tools
liblinear-tools Recommends libsvm-tools
libsvm-tools Depends on gnuplot
gnuplot Depends on gnuplot-nox (or gnuplot-x11 or gnuplot-qt but I take the 
lightest path)
gnuplot-nox Depends on libcairo2
libcairo2 Depends on libfontconfig1 and various libx*
libconfig1 Depends on fontconfig-config
fontconfig-config depends on a choice of four font packages
gnuplot-nox Recommends fonts-liberation
gnuplot-nox Recommends groff
groff Recommends ghostscript
groff Recommends imagemagick
imagemagick Depends on hicolor-icon-them and Depends and Recommends a bunch of 
other cruft (from the point of view of nmap; it all makes sense for 
imagemagick's purposes which are graphics creation/manipulation)



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

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

Versions of packages nmap depends on:
ii  libc62.13-38
ii  libgcc1  1:4.7.2-5
ii  liblinear1   1.8+dfsg-1
ii  liblua5.1-0  5.1.5-4
ii  libpcap0.8   1.3.0-1
ii  libpcre3 1:8.30-5
ii  libssl1.0.0  1.0.1e-2+deb7u3
ii  libstdc++6   4.7.2-5
ii  python   2.7.3-4+deb7u1

nmap recommends no packages.

nmap 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#737572: libqmi-glib-dev: Please package upstream version 1.8.0

[Guido Günther]

blocks 737572 731851
thanks

Hi,
On Tue, Feb 04, 2014 at 10:21:43AM +0100, Marius Kotsbak wrote:
> Hi
> 
> It is actually almost ready in the git repo I have pushed.
> 
> The remaining thing is to find out how to handle the qmi-proxy binary,
> which is used by the lib.

The binary is libexecdir so it ends up in /usr/lib/ on Debian,
so which not just ship it in the libqmi-glib itself? It useless without
the lib anyway.

Cheers,
 -- Guido


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

Bug#737708: isync: Mailbox path corruption

[Oswald Buddenhagen]

On Fri, Feb 07, 2014 at 10:54:12AM +0400, Eugene Berdnikov wrote:
> On Wed, Feb 05, 2014 at 12:44:01PM +0100, Oswald Buddenhagen wrote:
> > this appears to be an upstream bug in the compatibility wrapper.
> > 
> > you can migrate to the "proper" mbsync by running "isync -w" and fixing
> > the broken .mbsyncrc by hand.
> 
>  Tried: run "isync -w" from 1.1.0-1 package.
>  Resultimg .mbsyncrc does not contain dots in file paths.
>  However, running "mbsync -a" on it gives the same result
>  (errors messages about broken file paths).
> 
>  Change paths in .mbsyncrc to absolute does not help.
> 
the problem must be that you have a path in the mailbox name, while it
should be only in the Path element. i.e., the local_root hack just
doesn't work any more.
i can't give you a complete config, because you didn't, either...


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

Bug#736398: gap-dev: multi-architecture support

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 29/01/14 17:34, Bill Allombert wrote:
> On Thu, Jan 23, 2014 at 09:46:45AM +0100, Jerome Benoit wrote:
>> Package: gap-dev
>> Version: 4r6p5-3.1
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>>  please provide multiarch support for gap-dev:
>>  the distributed object files in /usr/lib/gap/bin/
>>  should be placed into an architecture dependent subfolder as
>>  /usr/lib/gap/bin// , while the GAP environment
>>  variable GAPInfo.Architecture should be set up arccordingly
>>  (for this example, to ).
>>  This will bring multiarch support to GAP 
> 
> Hello J￩rome, 
> Multiarch is only intended to cover shared library.

Strictly speaking or sticking to the definition, this is correct.

 There is currently no
> support in Debian for multiarch executables. GAP does not provide any shared
> libraries, but an executable, so is outside the scope of multiarch, and I 
> do not think it is worth the effort to have multiarch support for GAP at
> this stage. The .o files are only meant to be used by the GAC compiler.

But the .o files are architecture dependent, so a multiarch support make sense:
as a library is before all a rationalized archive of object, these .o may be 
gathered
into an archive: this will render this part of GAP more contemporary, and this 
will
allow a clean multiarch support.

> 
> If we move toward using multiarch path (irrespectively of actual multiarch
> support), then we should use /usr/lib//gap and not a GAP
> specific path.

I am agree. But the GAP specific setup,
/usr/lib/gap/pkg//bin//.so
for the  binary module (if any), does not fit well with Debian 
customs.

A possibility will be to ply with links, as it is currently done for 
documentation,
to full fill both Debian policy and GAP expectation.

The  is set up in the /usr/lib/gap/sysinfo.gap :
I guess that a good idea would be to replace the  by the .
So let assume that the  is replaced by the .
Then, wrt the current documentation scheme (for example gapdoc), we can set up 
the following:
/usr/lib//gap/ -> /usr/lib/gap/pkg//bin/
This favours GAP scheme, the alternative that favours Debain instead can be 
chosen too:
/usr/lib/gap/pkg//bin/ -> 
/usr/lib//gap/


> 
>>   and it will also
>>  satisfy some GAP expectation as expressed in the ac_find_gap.m4
>>  used by some GAP packages with binary modules.
> 
> I do not intent to support such expectation. The value of GAParch is
> something like x86_64-pc-linux-gnu-x86_64-linux-gnu-gcc-default64
> and change each time the compiler name change.

> This is too fragile to be used by Debian. 

Agree.

I am working with upstream
> to improve this (in particular: not include the compiler name in the ABI).
> In the mean time, my plan is to use /usr/share/gap/pkg//bin instead.
> This can be a symlink to /usr/lib//gap/pkg/ 

Can you also ask them to gather the object files into a library ?

>>  Note that the configure header /usr/include/gap/config.h
>>  (current Debian package location)
>>  is architecture dependent as well:
>>  ac_find_gap.m4 expects to find it in
>>  /usr/lib/gap/bin//.
> 
> Yes, I know. There is a trade-off between keeping file where upstream
> expect them and put them where Debian expect them. 
> Upstream do not provide a 'make install' target as a guidance.

A good idea would be to ask to the upstream team to provide an autotools
machinery that is respect better Linux customs:
the GAP autotools set ups mainly cast autotools to GAP,
it should be the reverse; GAP should provide an autotools machinery
that follows Linux custom. This is rather a choice because the effort to
do so is not that huge.

> If the current location prove to be too much an issue, I am willing to
> reconsider it, or add work-arounds.
> 
>>  (I guess that the current gap-dev package
>>  must be split.)
> 
> The multiarch specification for header files are not fully specified yet,
> but I do not think splitting the package is necessary (However some headers
> would need to be moved to /usr/include//).

If the set of objects files is considered as a pre-library, the package must be 
split:
grossly, one containing the headers, the second the library (and the config.h 
headers). 

> 
> Cheers,
> Bill.
> 

Best wishes,
Jerome
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJS9IMeAAoJEIC/w4IMSybjgGoH/03FIV2M/LErLoVkW29anjBo
iuNTUcgaOXUfE45rksvTzto6EVW2g13ExDvsx0td3AFJaO95IkqiUkHFP8yrc5Z1
JozDZ4B/dx+IyWM+zWcu8Motw26x0hGT7ON8QskEetuJ6mL0OUzUCbv5AYBLfEh0
/b7D7tNM3X9S+9gKw0DVH/KDLPa87eu+SEBn4Uch3dWt6K+zlSRkOLnuNZ54Igaz
uqwVN+T5q6xNJHwhZx/ny8yT7uefZdg6fYjazh2evfE59+YDr2AwK2qg2CB2y2b+
mZx6zVK2V4H1OxZC6ryXQ5GihNoVZrx8Qg6vQhxMv/ivAccrWdUEcDQFs8rIqLI=
=8t3D
-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#737708: isync: Mailbox path corruption

[Eugene Berdnikov]

On Wed, Feb 05, 2014 at 12:44:01PM +0100, Oswald Buddenhagen wrote:
> this appears to be an upstream bug in the compatibility wrapper.
> 
> you can migrate to the "proper" mbsync by running "isync -w" and fixing
> the broken .mbsyncrc by hand.

 Tried: run "isync -w" from 1.1.0-1 package.
 Resultimg .mbsyncrc does not contain dots in file paths.
 However, running "mbsync -a" on it gives the same result
 (errors messages about broken file paths).

 Change paths in .mbsyncrc to absolute does not help.
-- 
 Eugene Berdnikov


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

Bug#679755: wkhtmltopdf: new upstream release

[Ashish Kulkarni]

On Thu, Feb 6, 2014 at 11:46 PM, Emmanuel Bouthenot wrote:

> Good news !
>
> I will start to work on this new release soon.
>
> Regards,
>

How do you plan to package it? With the system QT (i.e. a lot of features
will be disabled) or with the patched QT? FreeBSD has packaged it [1] with
the patched QT, but I know that Debian has a policy which may apply in this
scenario [2]. Without the patched QT, a lot of the additional functionality
is disabled.

We are planning to integrate the patched QT directly into the source code
in a future version (so that it is easier to patch/enhance), effectively
becoming a fork -- would that run afoul of the "No convenience copies" rule?

Regards,
Ashish

[1] http://www.freshports.org/converters/wkhtmltopdf/
[2] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Bug#737949: rurple-ng: incorrect URL in “Homepage” field

[Ben Finney]

Package: rurple-ng
Version: 0.5+16-1
Severity: normal

Dear Maintainer,

The current package has a “Homepage” field with a URL that leads to a 404
Not Found response:

=
$ curl --head http://dev.lshift.net/paul/rurple | head -n 1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:--  0:00:06 --:--:-- 0
HTTP/1.1 404 Not Found

=

Please find the current homepage URL for this package and correct the
field.

-- 
 \  “Yesterday I saw a subliminal advertising executive for just a |
  `\   second.” —Steven Wright |
_o__)  |
Ben Finney 


signature.asc
Description: Digital signature

Bug#737658: Time to drop the eject package?

[Christian PERRIER]

Quoting Phillip Susi (ps...@ubuntu.com):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2/5/2014 1:02 AM, Christian PERRIER wrote:
> > It would need that util-linux provides an eject-udeb package to
> > avoid breakage in Debian Installer.
> 
> How about just putting it in the util-linux-udeb and drop the
> eject-udeb dependency from d-i?

Certainly the best to do, yes..;-)




signature.asc
Description: Digital signature

Bug#727708: Call for votes on init system resolution

[Adrian Bunk]

On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> On 7 February 2014 08:44, Adrian Bunk  wrote:
> > If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
> > then T is dead.
> 
> It's really pretty terrible to actively use FD to try to block options
> that aren't your favourite. Honestly, I would have expected the tech
> ctte to be able to come to a consensus on a set of proposals
> considered reasonable by all the members, and accept whatever a
> majority decided. I'd certainly hope that tech ctte members won't
> tactically change their vote to try to hack the process.
>...

When you are saying "a set of proposals considered reasonable by all the 
members", that basically implies "don't offer the T rider options" since 
these are options that are not considered reasonable by at large part 
(at least 3 members) of the TC.

Leaving tactical aspects aside, IMHO the important point is that 
there is a compromise line that seems reasonable for all members
of the TC:

For the upstart side of the TC, the most important question is T/L.
For the systemd side of the TC, the most important question is D/U.

What we see in the combined vote is actually that DL is an option
that makes both sides win in what they consider their most important
question - and that seems considered reasonable by all TC members.

This is much more possible consensus than what I'd have expected before 
the voting started.


> Cheers,
> aj

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#737948: could you package the latest version

[Picca Frédéric-Emmanuel]

Source: omniorb-dfsg
Severity: wishlist

Hello,

it seems that omniorg 4.1.7 is available.

could package it ?

thanks


Frederic



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

Kernel: Linux 3.12-1-486
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#736760: [Debian-med-packaging] debian/upstream vs. debian/upstream/signing-key.pgp

[James McCoy]

On Mon, Feb 03, 2014 at 09:48:43PM -0500, James McCoy wrote:
> On Sun, Feb 02, 2014 at 11:44:51AM +0900, Charles Plessy wrote:
> > Le Thu, Jan 30, 2014 at 05:06:22PM +0100, Andreas Tille a écrit :
> > >   * working on the needed changes for UDD machine readable files gatherer
> 
> Attached patch should allow that to work on both debian/upstream and
> debian/upstream/metadata, which is a name I've heard suggested and what
> first came to mind when the issue was initially raised.

Updated patch attached which fixes detection of debian/upstream/metadata
in git repositories.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 
From b3019a7ee3632b8f670aae7dae12283d57560fff Mon Sep 17 00:00:00 2001
From: James McCoy 
Date: Mon, 3 Feb 2014 21:33:48 -0500
Subject: [PATCH] fetch-machine-readable: Support debian/upstream and
 debian/upstream/metadata

---
 misc/machine_readable/fetch-machine-readable | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/misc/machine_readable/fetch-machine-readable b/misc/machine_readable/fetch-machine-readable
index f905243..a0d1c8a 100755
--- a/misc/machine_readable/fetch-machine-readable
+++ b/misc/machine_readable/fetch-machine-readable
@@ -42,7 +42,7 @@ svn_checkout_machine_readable () {
   TMPLIST=`mktemp`
   svn list --verbose svn://localhost/$1 --recursive | \
 grep -v -e '/tags/' -e '/branches/' -e '/patches/' | \
-grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" | \
+grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" -e "/upstream/metadata$" | \
 sed 's/^.*[[:space:]]\([^[:space:]]\+\)/\1/' \
 > $TMPLIST
   # debug
@@ -78,31 +78,31 @@ svn_checkout_machine_readable () {
   echo "Vcs-Svn: svn://svn.debian.org/$1/$vcslocation" > $TARGETDIR/$firstletter/${srcname}.vcs
   echo "Vcs-Browser: http://svn.debian.org/wsvn/$1/$vcslocation"; >> $TARGETDIR/$firstletter/${srcname}.vcs
   echo "Blend: `echo $1 | sed 's?/.*??'`" >> $TARGETDIR/$firstletter/${srcname}.vcs
-  for file in control copyright upstream ; do
+  for file in control copyright upstream upstream/metadata ; do
+srcfile=${file#upstream/}
+destfile=${file%/metadata}
 getfile=`grep -e "/$pkg/trunk/debian/$file$" -e "^$pkg/trunk/debian/$file$" -e "^$pkg/debian/$file$" -e "trunk/$pkg/debian/$file$" -e "/$pkg/[a-z]\+/trunk/debian/$file$" $TMPLIST 2>/dev/null`
 if [ "" != "$getfile" ] ; then
   svn export svn://localhost/$1/$getfile >/dev/null 2>/dev/null
-  if [ -e $file ] ; then
-mv $file $TARGETDIR/$firstletter/${srcname}.$file
+  if [ -e $srcfile ] ; then
+mv $srcfile $TARGETDIR/$firstletter/${srcname}.$destfile
   else
 echo "ERR 1: Can not obtain file ${file} of source ${srcname} of team $1 from ${getfile}" >> $ERRLOG
   fi
 else
   if ! `echo $vcslocation | grep -q trunk` ; then
-if [ "$file" != "upstream" ] ; then
+if [ "$destfile" != "upstream" ] ; then
   echo "Package $pkg is lacking trunk directory in vcslocation ${vcslocation}. Try to find file $file anyway." >> $ERRLOG
   getfile=`grep -e "$vcslocation/debian/$file$" $TMPLIST 2>/dev/null`
   if [ "" != "$getfile" ] ; then
 svn export svn://localhost/$1/$getfile >/dev/null 2>/dev/null
-if [ -e $file ] ; then
-  mv $file $TARGETDIR/$firstletter/${srcname}.$file
+if [ -e $srcfile ] ; then
+  mv $srcfile $TARGETDIR/$firstletter/${srcname}.$destfile
 else
   echo "ERR 2: Can not obtain file ${file} of source ${srcname} of team $1 from ${getfile}" >> $ERRLOG
 fi
   else
-if [ "$file" != "upstream" ] ; then
-  echo "Did not found $file for package $pkg (`grep "$pkg" $TMPLIST | grep "$file"`)" >> $ERRLOG
-fi
+echo "Did not found $file for package $pkg (`grep "$pkg" $TMPLIST | grep "$file"`)" >> $ERRLOG
   fi
 fi
   fi
@@ -135,8 +135,9 @@ git_checkout_machine_readable () {
 echo "Vcs-Git: git://git.debian.org$1" > $TARGETDIR/$firstletter/${srcname}.vcs
 echo "Vcs-Browser: http://git.debian.org"`echo $1 | sed 's+^/git/+/?p=+'` >> $TARGETDIR/$firstletter/${srcname}.vcs
 echo "Blend: `echo $2 | sed 's?/.*??'`" >> $TARGETDIR/$firstletter/${srcname}.vcs
-for file in `git ls-tree HEAD debian/ 2>/dev/null | grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" | sed 's/^[0-9]\+[[:space:]]\+blob[[:space:]]\+[0-9a-f]\+[[:space:]]\+//'` ; do
-  target=$TARGETDIR/$firstletter/${srcname}.`echo $file | sed 's?debian/??'`
+for file in `git ls-t

Bug#737835: CVE Request: Capture::Tiny: insecure use of /tmp

[cve-assign]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> open("/tmp/5KKGPDNyy0", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE,

Use CVE-2014-1875.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJS9GHnAAoJEKllVAevmvms3t0IAKqhldJQYiAv3EwHVYI5hL7b
CaIDJ4wIQXfSoqs9ewV1phqNVSnKsgYS6WOp5AjqZZ3+CqSDLS2Jz7kThx7g7mo4
fOFcftX4tjrVrZ4dyoiKuCCGL8R/4Mo3ObmomZ1SbaVb4jtFVqxCOc4Kh52Ca/88
C9peyeQqpWV3kzM9+1sEgQatNTVNIonJiTg23XGSAY3wzLMiGP+teVfygZOO6Xxj
4S4IAx1PNg8GFR/qOEywPE3baWNttTL2RejwoqxUZn908+GXfWZdlCJn+Ku5xOeO
Wwawwv4lRRgrPGCPil5rhSdlIeSs08HCoEbcrOLMb5RFsI9FceOpCv7QUt5/gog=
=5gFh
-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#737947: bsdmainutils: Patch for bootstrapping without python

[Daniel Schepler]

Source: bsdmainutils
Version: 9.0.5
Severity: wishlist
Tags: patch

In the process of bootstrapping Debian, bsdmainutils is needed early in the 
process: debhelper Depends on man-db, which Depends on bsdmainutils.  So, 
here's a patch to make it possible to do this bootstrapping without python 
which has a significantly heavier dependency chain.
-- 
Daniel Schepler
diff -urN bsdmainutils-9.0.5.old/debian/control bsdmainutils-9.0.5/debian/control
--- bsdmainutils-9.0.5.old/debian/control	2013-01-10 06:04:10.0 -0800
+++ bsdmainutils-9.0.5/debian/control	2013-05-25 13:10:16.419727959 -0700
@@ -3,7 +3,7 @@
 Priority: important
 Maintainer: Debian Bsdmainutils Team 
 Uploaders: Giacomo Catenazzi , Michael Meskes 
-Build-Depends: debhelper (>= 7), libncurses5-dev, quilt (>= 0.40), python, python-hdate
+Build-Depends: debhelper (>= 7), libncurses5-dev, python, python-hdate
 Standards-Version: 3.9.3
 Vcs-Git: git://git.debian.org/git/bsdmainutils/bsdmainutils.git
 Vcs-Browser: http://git.debian.org/?p=bsdmainutils/bsdmainutils.git
diff -urN bsdmainutils-9.0.5.old/debian/rules bsdmainutils-9.0.5/debian/rules
--- bsdmainutils-9.0.5.old/debian/rules	2012-05-16 08:20:51.0 -0700
+++ bsdmainutils-9.0.5/debian/rules	2013-05-25 13:12:03.617933821 -0700
@@ -3,8 +3,6 @@
 SHELL+= -e
 #export DH_VERBOSE=1
 
-include /usr/share/quilt/quilt.make
-
 DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
@@ -23,13 +21,17 @@
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
-build-stamp: patch
+build-stamp:
 	dh_testdir
 	$(MAKE) $(CROSS)
+ifneq ($(DEB_BUILD_PROFILE),stage1)
 	python $(CURDIR)/debian/calendarJudaic.py > $(CURDIR)/debian/calendars/calendar.judaic
+else
+	touch $(CURDIR)/debian/calendars/calendar.judaic
+endif
 	touch build-stamp
 
-clean: unpatch
+clean:
 	dh_testdir
 	$(MAKE) clean
 	-rm -f $(CURDIR)/debian/calendars/calendar.judaic
diff -urN bsdmainutils-9.0.5.old/debian/source/format bsdmainutils-9.0.5/debian/source/format
--- bsdmainutils-9.0.5.old/debian/source/format	2012-01-22 23:13:09.0 -0800
+++ bsdmainutils-9.0.5/debian/source/format	2013-05-25 13:10:42.536265394 -0700
@@ -1 +1 @@
-1.0
+3.0 (quilt)

Bug#737946: Patch for bootstrapping ncurses without multilib

[Daniel Schepler]

Source: ncurses
Version: 5.9+20140118-1
Severity: wishlist
Tags: patch

As the subject says: the attached patch allows for bootstrapping ncurses, at 
an early stage of the process when multilib compilers and libraries are not 
yet available.
-- 
Daniel Schepler
diff -urN ncurses-5.9+20130608.old/debian/rules ncurses-5.9+20130608/debian/rules
--- ncurses-5.9+20130608.old/debian/rules	2013-06-09 13:29:29.0 -0700
+++ ncurses-5.9+20130608/debian/rules	2013-06-10 19:10:15.757766650 -0700
@@ -63,6 +63,16 @@
 		 debian/libtinfo5.install debian/libtinfo-dev.install \
 		 debian/libtermcap.so
 
+ifeq ($(DEB_BUILD_PROFILE),stage1)
+
+bootstrap_dh_flags = -N$(package-lib-32) -N$(package-lib-64) \
+	-N$(package-ti-32) -N$(package-ti-64) \
+	-N$(package-libw-32) \
+	-N$(package-dev-32) -N$(package-dev-64) \
+	-N$(package-devti-32) -N$(package-devw-32)
+
+else
+
 ifeq ($(DEB_HOST_ARCH),i386)
 build_64_target = x86_64-$(DEB_HOST_GNU_SYSTEM)
 build_64 = build-64
@@ -101,6 +111,8 @@
 with_gpm = --with-gpm
 endif
 
+endif  # DEB_BUILD_PROFILE != stage1
+
 CONFARGS =	--prefix=/usr \
 		--build=$(DEB_BUILD_GNU_TYPE) \
 		--with-shared \
@@ -421,7 +433,7 @@
 binary-arch: build install $(autogen-files)
 	dh_testdir
 	dh_testroot
-	dh_install -s --fail-missing
+	dh_install -s --fail-missing $(bootstrap_dh_flags)
 	dh_installman -s
 	dh_installdocs -p$(package-bin) -p$(package-ti) -p$(package-examples) debian/FAQ
 	dh_installdocs -s -N$(package-bin) -N$(package-ti) -N$(package-examples) \
@@ -440,18 +452,18 @@
 	dh_installdocs -p$(package-lib-64) -p$(package-dev-64) \
 		   --link-doc=$(package-ti-64)
 endif
-	dh_installchangelogs -s NEWS
-	dh_installdirs -s
+	dh_installchangelogs -s NEWS $(bootstrap_dh_flags)
+	dh_installdirs -s $(bootstrap_dh_flags)
 
 	# Strip the packages, shipping detached debugging symbols.
-	dh_strip -s -N$(package-libw) -N$(package-ti) --dbg-package=$(package-dbg)
+	dh_strip -s -N$(package-libw) -N$(package-ti) $(bootstrap_dh_flags) --dbg-package=$(package-dbg)
 	dh_strip -p$(package-libw) --dbg-package=$(package-dbgw)
 	dh_strip -p$(package-ti) --dbg-package=$(package-dbgti)
-	dh_lintian -s
+	dh_lintian -s $(bootstrap_dh_flags)
 	dh_compress -p$(package-examples) usr/lib/ncurses/examples/README
-	dh_compress -s -N$(package-examples)
-	dh_fixperms -s
-	dh_link -s
+	dh_compress -s -N$(package-examples) $(bootstrap_dh_flags)
+	dh_fixperms -s $(bootstrap_dh_flags)
+	dh_link -s $(bootstrap_dh_flags)
 	dh_makeshlibs -p$(package-ti) -V "$(package-ti) $(sodepver)" -- -c4
 	dh_makeshlibs -p$(package-lib) -V "$(package-lib) $(sodepver)" -- -c4
 	dh_makeshlibs -p$(package-libw) -V "$(package-libw) $(sodepver)" -- -c4
@@ -464,11 +476,11 @@
 	dh_makeshlibs -p$(package-ti-64) -V "$(package-ti-64) $(sodepver)" -- -c4
 	dh_makeshlibs -p$(package-lib-64) -V "$(package-lib-64) $(sodepver)" -- -c4
 endif
-	dh_shlibdeps -s
-	dh_gencontrol -s
-	dh_installdeb -s
-	dh_md5sums -s
-	dh_builddeb -s
+	dh_shlibdeps -s $(bootstrap_dh_flags)
+	dh_gencontrol -s $(bootstrap_dh_flags)
+	dh_installdeb -s $(bootstrap_dh_flags)
+	dh_md5sums -s $(bootstrap_dh_flags)
+	dh_builddeb -s $(bootstrap_dh_flags)
 
 binary-indep: build install $(autogen-files)
 	dh_testdir

Bug#737363: higan: crashes when importing or loading unheadered NES ROM

[Michael Gold]

On Thu, Feb 06, 2014 at 23:41:27 +0100, Tobias Hansen wrote:
> Thank you very much Michael! byuu has quite high standards regarding the
> databases so I don't want to mess with that and deviate from what he
> puts in. You could ask him to put it in the next release but I doubt he
> will because the databases are meant to contain verified information.

OK.  The first database support patch (with the blank DB) may still be
useful--it will use .config/ananke/database/Famicom.bml if present.

-- Michael


signature.asc
Description: Digital signature

Bug#727708: I'd like to voice my opinion

[Cameron Norman]

El Thu, 6 de Feb 2014 a las 7:41 PM, Schlacta, Christ 
 escribió:
I'd like to request that upstart be chosen over systemd mainly 
because there's already a large availability of deb packages that 
support init mainly due to ubuntu.  Ubuntu acts as a gateway distro 
to the debian universe, and is a basis upon which numerous other 
distros are based as well.


As such, a lot of packages are developed for ubuntu instead of 
debian.  Making upstart the default init package allows for 
compatibility with the majority of these ubuntu specific packages.


Furthermore, I know upstart is capable of maintaining backward 
compatibility with systemvinit scripts as debian implements them 
currently.



Hello Christ.

systemd proponents have been hard at work in getting systemd units 
packaged up and installed. Just load up Sid to see how many there are. 
Furthermore, systemd supports sysv scripts just like Upstart (actually, 
they are integrated into systemd's dependency chain, so the 
implementation is better in that way).


I understand that you had the best of faith in writing this, but I 
assure you that the availability of init configurations will not be a 
problem for systemd, Upstart, or OpenRC (OpenRC supports sysv scripts).


That said, Upstart could be a good choice because of the number of 
desktop environments that have their main focus as Ubuntu (Pantheon, 
Cinnamon, MATE) and could be encouraged to adopt Upstart as a session 
init if Debian goes with it. The same could be said of systemd, though 
(with GNOME and KDE instead of Pantheon and Cinnamon), though.


Have a great day,
Cameron

Bug#737945: acpi-support: Recommends xscreensaver however this is not supposed to be a desktop-requiring package

[Daniel Dickinson]

Package: acpi-support
Version: wheezy
Severity: normal
Tags: d-i

acpi-support is part of task-laptop which is used by d-i and live-build to 
create what are supposed to be command line only installations, however 
acpi-support Recommends xscreensaver.  This should be a Suggests and/or 
Enhances.

Perhaps an acpi-support-desktop would be in order for things that don't belong 
in cli installation?

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

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


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

Bug#737944: RFS: flashproxy/1.5-1 [ITP]

[Ximin Luo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

Package name: flashproxy
Version : 1.5-1
Upstream Author : David Fifield 
URL : https://crypto.stanford.edu/flashproxy/
License : Expat
Section : net

It builds these binary packages:

flashproxy-client - Pluggable transport for ephemeral IP addresses - client 
transport
flashproxy-common - Pluggable transport for ephemeral IP addresses - common 
library
flashproxy-facilitator - Pluggable transport for ephemeral IP addresses - 
facilitator
flashproxy-proxy - Pluggable transport for ephemeral IP addresses - browser 
proxy
node-flashproxy - Pluggable transport for ephemeral IP addresses - nodejs proxy

These are available on mentors.debian.net:

http://mentors.debian.net/package/flashproxy
dget -x 
http://mentors.debian.net/debian/pool/main/f/flashproxy/flashproxy_1.5-1.dsc

It has already been through a review by a DD and he is satisfied with it, but
does not have time to test it properly:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721845 (ITP and code review)

I have written a shell script to do an end-to-end test of the core functions of
all the components of the system. You may first familiarise yourself with the
system by reading the summary on the project website, then try to run this test
against the built packages above.

https://gitweb.torproject.org/debian/flashproxy.git/blob/HEAD:/debian/flashproxy-end-to-end-test.sh

(node-ws, one of the dependencies, is currently in NEW so you might need to add
the custom APT repo mentioned in the introductory comments of the script.)

Regards,
Ximin Luo

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

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


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

Bug#737943: gdbm: Patch for bootstrapping without texinfo

[Daniel Schepler]

Source: gdbm
Version: 1.8.3-12
Severity: wishlist
Tags: patch

In the process of bootstrapping Debian, one needs to be able to build gdbm 
fairly early: debhelper Depends on man-db, which Build-Depends on libgdbm-dev.  
On the other hand, texinfo is somewhat heavier in terms of what dependencies 
it needs.  So, the attached patch makes it possible to do a bootstrap build of 
gdbm without texinfo available.
-- 
Daniel Schepler
diff -urN gdbm-1.8.3.old/debian/rules gdbm-1.8.3/debian/rules
--- gdbm-1.8.3.old/debian/rules	2012-06-10 01:59:52.0 -0700
+++ gdbm-1.8.3/debian/rules	2013-05-25 12:11:02.606651344 -0700
@@ -54,7 +54,11 @@
 	echo "/* We use fcntl locking (POSIX) instead of flock (BSD) */" >> autoconf.h
 	echo "#undef HAVE_FLOCK" >> autoconf.h
 	CFLAGS="$(CFLAGS)" LIBS="$(LDFLAGS)" $(MAKE)
+ifeq ($(DEB_BUILD_PROFILE),stage1)
+	touch gdbm.info
+else
 	$(MAKE) gdbm.info
+endif
 	touch build
 
 binary-indep:	checkroot build

Bug#737942: cura-engine: FTBFS - pkg-config: not found

[Aaron M. Ucko]

Source: cura-engine
Version: 14.01-1
Severity: serious
Justification: fails to build from source

Builds of cura-engine in minimal environments, as on the autobuilders,
have been failing:

  g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -c -Wall -Wextra -O3 -fomit-frame-pointer `pkg-config 
--cflags polyclipping` bridge.cpp -o bridge.o
  /bin/sh: 1: pkg-config: not found
  In file included from sliceDataStorage.h:5:0,
   from bridge.h:5,
   from bridge.cpp:2:
  utils/intpoint.h:12:23: fatal error: clipper.hpp: No such file or directory
   #include 
 ^
  compilation terminated.

Please declare a build dependency on pkg-config (without which the
compiler won't know to look in /usr/include/polyclipping), and confirm
with pbuilder or the like that you haven't missed any others.

Thanks!


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

Bug#737882: atheme-services: status on the init script fails

[Mike Mestnik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Attached find two patch files, one bug/lintian and the other
incorporates features.

sha256
e5369efb01c70e788bae53b3b5797c03b84bcd3b1e895b27d95f354f07851e84 
0001-This-fixes-the-bug-and-corrects-init.d-script-does-not.txt
a38e9712c0f5dcd44cc7f656b2223d52a6f332eb228564bf56ec84e9376e5038 
0002-Simplify-with-status_of_proc.txt

size
861 0001-This-fixes-the-bug-and-corrects-init.d-script-does-not.txt
927 0002-Simplify-with-status_of_proc.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS9DMZAAoJEOPRqa2O3KuKRUIQALpWXie3+V47lpv7cRvBLkXV
71kn4homZu1Ta8E4wyLVNPaMHd8tvXycHx2t9UZ/ch9bC1FtLQcKjRPwOLPEmu9c
dPP6ZtJfnDr8z4PCb/OCuP0/kuj/yZpif16KYW30weDKTkdyVOOWj14lukfFeqfP
70t0kleUP2t5cJDN26lWJMYkVMnJLieiz0gNBVvSVKMXhdhP0f3ZyVv3AlO1KfPQ
UiiX+xkNgzTxHrbv9RoqYssJBpLQr4IlKQQis1/cDKF3ODil/zsJGBTocFZN01PX
IneYfPX+SiLl6yUtKBTX7jSfiEgmBZKH0kETTFnXnG/IdMpeTsF0prmsJASA++FA
R2DtflqobhoGGDLwRVfiA4A8zvTcCNthLWhjsjhLteK3EtMJwSCEcMNSWcDDXFys
Cw2EbzdSOh86U8TxiyrWW7azJR3/8UhRhBk8XH2sdXzPL3H5nHNp+9CR0IssnuZP
mCVs40sadTc7orOPFugW3N2nCS8Ly1g9tnrrh8OIKxyYbqYHg8nURUTLwRBYY+c2
iCjs0eSm8e0mPl6uEyLmK8MT+g1ENsDwRmv1fVOiSi6BwH0eulzJW5FJOFxxqu5H
SCyRhBQyXWx62yyt86MvKsPukeXKMLwhrFllsCYBg/5ZdEyL2OUZNnIioPbjGNdP
xu8qELS+EIbxvItxOWvp
=uMMO
-END PGP SIGNATURE-

>From 527072f15bce400836b039d0ddb23a127a5086bf Mon Sep 17 00:00:00 2001
From: Mike Mestnik 
Date: Thu, 6 Feb 2014 18:20:16 -0600
Subject: [PATCH 1/2] This fixes the bug and corrects
 init.d-script-does-not-source-init-functions.

---
 debian/init.d |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/init.d b/debian/init.d
index c026287..89bad8d 100644
--- a/debian/init.d
+++ b/debian/init.d
@@ -29,6 +29,7 @@ if [ "$ENABLED" != "1" ] ; then
 fi
 
 set -e
+. /lib/lsb/init-functions
 
 case "$1" in
   start)
@@ -104,12 +105,11 @@ case "$1" in
exit 3
else
if [ -f "$RUNDIR/atheme.pid" ]; then
-   ( set +e
+   set +e
start-stop-daemon --status --quiet --pidfile 
$RUNDIR/atheme.pid
ext=$?
echo "."
exit $ext
-   )
fi
echo "pid file missing."
exit 3
-- 
1.7.9.5

>From 069db216dad5abea83cc84e637d1166b955f07f9 Mon Sep 17 00:00:00 2001
From: Mike Mestnik 
Date: Thu, 6 Feb 2014 18:22:16 -0600
Subject: [PATCH 2/2] Simplify with status_of_proc.

---
 debian/init.d |   18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/debian/init.d b/debian/init.d
index 89bad8d..77e9452 100644
--- a/debian/init.d
+++ b/debian/init.d
@@ -99,23 +99,7 @@ case "$1" in
echo "."
;;
   status)
-   echo -n "Status $DESC: $NAME "
-   if [ ! -d "$RUNDIR" ]; then
-   echo "run folder missing!"
-   exit 3
-   else
-   if [ -f "$RUNDIR/atheme.pid" ]; then
-   set +e
-   start-stop-daemon --status --quiet --pidfile 
$RUNDIR/atheme.pid
-   ext=$?
-   echo "."
-   exit $ext
-   fi
-   echo "pid file missing."
-   exit 3
-   fi
-   echo unknown.
-   exit 4
+   status_of_proc -p $RUNDIR/atheme.pid $DAEMON $NAME
;;
   *)
N=/etc/init.d/$NAME
-- 
1.7.9.5

Bug#727708: I'd like to voice my opinion

[Schlacta, Christ]

I'd like to request that upstart be chosen over systemd mainly because
there's already a large availability of deb packages that support init
mainly due to ubuntu.  Ubuntu acts as a gateway distro to the debian
universe, and is a basis upon which numerous other distros are based as
well.

As such, a lot of packages are developed for ubuntu instead of debian.
 Making upstart the default init package allows for compatibility with the
majority of these ubuntu specific packages.

Furthermore, I know upstart is capable of maintaining backward
compatibility with systemvinit scripts as debian implements them currently.

Bug#737940: xul-ext-adblock-plus fails when adding/updating filters subscription

[Bugiver Bugiver]

Package: xul-ext-adblock-plus

Version: 2.4.1+dfsg-1


Dear Maintainer,

Clicking in 'Filters preferences' ---> 'Add filter subscription' ---> 'Add
another subscription'
the filters list is displayed but "Error:download error" is shown after
adding any filter subscription
or when updating any filter subscription added previously. This error
affects 'EasyList' filter too.
This issue persists for a week or so. Reinstalling doesn't help. Same thing
happen on my other computer wich runs Jessie.
Sorry for my bad english :)

Thanks for your job,

Awal

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

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

Versions of packages xul-ext-adblock-plus depends on:
ii  iceweasel  24.3.0esr-1

xul-ext-adblock-plus recommends no packages.

xul-ext-adblock-plus suggests no packages.

Bug#737941: libtool: Move texi2html and texinfo from Build-Depends to Build-Depends-Indep

[Daniel Schepler]

Source: libtool
Version: 2.4.2-1.6
Severity: wishlist
Tags: patch

As part of the bootstrapping process, one needs to be able to build libtool 
before the somewhat heavier depedency chains of texinfo and texi2html become 
available.  The attached patch should make this possible by moving those 
dependencies into Build-Depends-Indep.  (Of course, one will also need to 
build without gfortran being installable at such an early stage, but this 
isn't really an issue.)
-- 
Daniel Schepler
diff -urN libtool-2.4.2.old/debian/control libtool-2.4.2/debian/control
--- libtool-2.4.2.old/debian/control	2014-01-01 15:19:31.0 -0800
+++ libtool-2.4.2/debian/control	2014-02-06 18:41:35.216281447 -0800
@@ -1,5 +1,6 @@
 Source: libtool
-Build-Depends: debhelper (>= 8.1.3~), texi2html, texinfo, file, gfortran | fortran95-compiler, automake (>= 1:1.11.1), autoconf (>= 2.62), autotools-dev, help2man, zlib1g-dev
+Build-Depends: debhelper (>= 8.1.3~), file, gfortran | fortran95-compiler, automake (>= 1:1.11.1), autoconf (>= 2.62), autotools-dev, help2man, zlib1g-dev
+Build-Depends-Indep: texi2html, texinfo
 Build-Conflicts: automake1.9, gcj-jdk
 Section: devel
 Priority: optional
diff -urN libtool-2.4.2.old/debian/rules libtool-2.4.2/debian/rules
--- libtool-2.4.2.old/debian/rules	2011-10-29 11:09:59.0 -0700
+++ libtool-2.4.2/debian/rules	2014-02-06 18:53:34.823823994 -0800
@@ -7,6 +7,13 @@
 
 DEBIAN_REVISION=$(strip $(shell dpkg-parsechangelog | awk -F: '/^Version:/ {print $$NF}'))
 
+# if doing a binary-arch build, the Makefiles still want to update the
+# info files; force them not to
+ifeq (,$(wildcard /usr/bin/makeinfo))
+MAKEINFO=true
+export MAKEINFO
+endif
+
 # libltdl needs to conform to policy
 CFLAGS = -Wall -g
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -43,7 +50,7 @@
 clean: 
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp config-stamp
+	rm -f build-stamp build-indep-stamp config-stamp
 	dh_clean
 
 	[ ! -f Makefile ] || $(MAKE) -k distclean
@@ -85,7 +92,9 @@
 	touch config-stamp
 
 
-build: build-stamp
+build: build-arch build-indep
+
+build-arch: build-stamp
 build-stamp: config-stamp
 	dh_testdir
 
@@ -128,10 +137,6 @@
 #	Make libtool executable again
 	chmod 755 libtool
 
-#	This generated HTML page goes into libtool-doc.
-	cd doc && makeinfo libtool.texi
-	cd doc && texi2html -monolithic libtool.texi
-
 
 ifeq ($(make_check), yes)
 #	Now make sure it works
@@ -143,7 +148,15 @@
 
 	touch build-stamp
 
-install: build
+build-indep: build-indep-stamp
+build-indep-stamp:
+#	This generated HTML page goes into libtool-doc.
+	cd doc && makeinfo libtool.texi
+	cd doc && texi2html -monolithic libtool.texi
+
+	touch build-indep-stamp
+
+install: build-arch
 	dh_testdir
 	dh_testroot
 	dh_prep
@@ -152,7 +165,7 @@
 	$(MAKE) prefix=`pwd`/debian/tmp/usr install
 
 # Build architecture-independent files here.
-binary-indep: build install
+binary-indep: build-indep install
 	dh_testdir -i
 	dh_testroot -i
 
@@ -171,7 +184,7 @@
 	dh_builddeb -i
 
 # Build architecture-dependent files here.
-binary-arch: build install
+binary-arch: build-arch install
 	dh_testdir -a
 	dh_testroot -a
 
@@ -202,4 +215,4 @@
 	dh_builddeb -a
 
 binary: binary-indep binary-arch
-.PHONY: build clean config patch unpatch binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean config patch unpatch binary-indep binary-arch binary install

Bug#737936: autoconf: Patch to bootstrap without texinfo or texlive-*

[Daniel Schepler]

Source: autoconf
Version: 2.69-2
Severity: wishlist
Tags: patch

The attached patch allows bootstrapping autoconf without the much
heavier dependency chains introduced by texinfo and especially
texlive-*.
-- 
Daniel Schepler
diff -urN autoconf-2.69.old/debian/rules autoconf-2.69/debian/rules
--- autoconf-2.69.old/debian/rules  2012-04-29 14:41:46.0 -0700
+++ autoconf-2.69/debian/rules  2013-05-24 10:53:54.170448650 -0700
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 %:
+ifeq ($(DEB_BUILD_PROFILE),stage1)
+   dh $@ -Nautoconf-doc
+else
dh $@
+endif
 
 override_dh_auto_clean:
[ ! -f Makefile ] || $(MAKE) distclean
@@ -12,13 +16,18 @@
 
 override_dh_auto_build:
dh_auto_build
+ifneq ($(DEB_BUILD_PROFILE),stage1)
$(MAKE) html info pdf ps
+endif
 
 override_dh_auto_test:
 
 override_dh_auto_install:
+   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
+ifneq ($(DEB_BUILD_PROFILE),stage1)
$(MAKE) DESTDIR=$(CURDIR)/debian/tmp \
-   install install-html install-info install-pdf install-ps
+   install-html install-info install-pdf install-ps
+endif
perl -pi -e 's/^my \$$VERSION.*/my \$$VERSION = "'"`date`"'";/;' \
debian/tmp/usr/share/autoconf/Autom4te/C4che.pm 
 

Bug#737937: automake-1.14: Patch to bootstrap without texinfo

[Daniel Schepler]

Source: automake-1.14
Version: 1:1.14.1-2
Severity: wishlist
Tags: patch

As the subject says: the attached patch allows bootstrapping the
automake package without needing texinfo, which would be significantly
harder to bootstrap without automake available on its dependency
chain.
-- 
Daniel Schepler
diff -urN automake-1.14-1.14.old/debian/rules automake-1.14-1.14/debian/rules
--- automake-1.14-1.14.old/debian/rules 2013-08-18 19:28:45.0 -0700
+++ automake-1.14-1.14/debian/rules 2013-09-18 21:23:32.225885876 -0700
@@ -7,14 +7,25 @@
 %:
dh $@
 
+ifeq ($(DEB_BUILD_PROFILE),stage1)
+MAKEINFO=true
+export MAKEINFO
+
+override_dh_auto_build:
+   touch doc/automake.info
+   dh_auto_build
+endif
+
 override_dh_auto_install:
dh_auto_install --destdir=$(CURDIR)/debian/tmp
 #  remove automake's versions
rm -f $(CURDIR)/debian/tmp/usr/share/automake-$(version)/config.sub
rm -f \
$(CURDIR)/debian/tmp/usr/share/automake-$(version)/config.guess
+ifneq ($(DEB_BUILD_PROFILE),stage1)
 # Rebuild the info files   
cd $(infodir) && makeinfo automake.texi
+endif
 
 override_dh_auto_clean:
[ -f Makefile ] && dh_auto_clean || true

Bug#730596: geeqie: crash (SIGABRT) when loading files with extensions geeqie doesn't know about

[Paul Wise]

Control: retitle -1 geeqie: crash (SIGABRT) when loading files with extensions 
geeqie doesn't know about

On Wed, 2013-11-27 at 10:09 +0800, Paul Wise wrote:

> geeqie reproducibly crashes with a SIGABRT when loading PDF files, backtrace:

I get the exact same issue when loading a PNG file that has a strange
extension. Known extensions like jpg work but geeqie is buggy with
extensions that it doesn't know about. The file type is completely
unrelated to this crash, just the file name. Since geeqie doesn't know
about the .pdf extension it crashes there too.

pabs@chianamo ~ $ wget -q http://www.google.com/images/google_favicon_128.png
pabs@chianamo ~ $ geeqie google_favicon_128.png 
Could not init LIRC support
pabs@chianamo ~ $ cp google_favicon_128.png google_favicon_128.jpg
pabs@chianamo ~ $ geeqie google_favicon_128.jpg
Could not init LIRC support
pabs@chianamo ~ $ cp google_favicon_128.png google_favicon_128.flibble
pabs@chianamo ~ $ geeqie google_favicon_128.flibble
Could not init LIRC support
**
ERROR:filedata.c:1101:file_data_new_group: assertion failed: (fd)
Aborted (core dumped)
pabs@chianamo ~ $ cp google_favicon_128.png google_favicon_128
pabs@chianamo ~ $ geeqie google_favicon_128
Could not init LIRC support
**
ERROR:filedata.c:1101:file_data_new_group: assertion failed: (fd)
Aborted (core dumped)
pabs@chianamo ~ $ gdb -batch -n -ex run -ex bt -ex 'thread apply all bt full' 
--args geeqie google_favicon_128
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Could not init LIRC support
[New Thread 0x7fffe3a29700 (LWP 24258)]
**
ERROR:filedata.c:1101:file_data_new_group: assertion failed: (fd)

Program received signal SIGABRT, Aborted.
0x73cb61d5 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x73cb61d5 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x73cb9388 in __GI_abort () at abort.c:90
#2  0x75ca6c16 in g_assertion_message (domain=domain@entry=0x0, 
file=file@entry=0x4d9414 "filedata.c", line=line@entry=1101, 
func=func@entry=0x4d9f90 <__PRETTY_FUNCTION__.53497> "file_data_new_group", 
message=) at /tmp/buildd/glib2.0-2.36.4/./glib/gtestutils.c:1912
#3  0x75ca6c74 in g_assertion_message_expr (domain=domain@entry=0x0, 
file=file@entry=0x4d9414 "filedata.c", line=line@entry=1101, 
func=func@entry=0x4d9f90 <__PRETTY_FUNCTION__.53497> "file_data_new_group", 
expr=expr@entry=0x4d9376 "fd") at 
/tmp/buildd/glib2.0-2.36.4/./glib/gtestutils.c:1923
#4  0x00453974 in file_data_new_group (path_utf8=) at 
filedata.c:1101
#5  0x00464c18 in layout_set_path (lw=0x7ee420, path=0x5eb4 ) at layout.c:855
#6  0x00468186 in layout_new_from_config 
(attribute_names=attribute_names@entry=0x7fffd630, 
attribute_values=attribute_values@entry=0x7fffd510, use_commandline=1) at 
layout.c:2427
#7  0x0049ef3f in options_parse_toplevel (parser_data=0x7d02d0, 
context=, element_name=, 
attribute_names=0x7fffd630, attribute_values=0x7fffd510, 
data=, error=0x7fffd750) at rcfile.c:1121
#8  0x0049c517 in start_element (context=0x7d1fc0, 
element_name=0x7d80b0 "layout", attribute_names=0x7fffd630, 
attribute_values=0x7fffd510, user_data=0x7d02d0, error=0x7fffd750) at 
rcfile.c:1186
#9  0x75c85631 in emit_start_element (context=context@entry=0x7d1fc0, 
error=error@entry=0x0) at /tmp/buildd/glib2.0-2.36.4/./glib/gmarkup.c:1029
#10 0x75c86f90 in g_markup_parse_context_parse 
(context=context@entry=0x7d1fc0, text=, text_len=, text_len@entry=20261, error=error@entry=0x0) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmarkup.c:1366
#11 0x0049fffd in load_config_from_buf (buf=, 
size=20261, startup=startup@entry=1) at rcfile.c:1231
#12 0x004a00ac in load_config_from_file 
(utf8_path=utf8_path@entry=0x7da730 "/home/pabs/.config/geeqie/geeqierc.xml", 
startup=startup@entry=1) at rcfile.c:1253
#13 0x00477e3e in load_options (options=) at 
options.c:265
#14 0x00418c73 in main (argc=2, argv=0x7fffda88) at main.c:827

Thread 2 (Thread 0x7fffe3a29700 (LWP 24258)):
#0  0x73d5e95d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x75c83194 in g_main_context_poll (priority=2147483647, n_fds=3, 
fds=0x87bba0, timeout=-1, context=0x87b7c0) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3995
poll_func = 0x75c91dd0 
#2  g_main_context_iterate (context=0x87b7c0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3696
max_priority = 2147483647
timeout = -1
   

Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build

[James McCoy]

On Mon, Feb 03, 2014 at 06:18:40PM +0400, Vitaliy Filippov wrote:
> subversion build still depends on GCJ. I think OpenJDK should be used instead,
> because GCJ is a very outdated compiler.

Does the use of GCJ cause any actual problems?  Is the OpenJDK jre
unable to load the GCJ-built modules?

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


signature.asc
Description: Digital signature

Bug#737935: m4: Move texinfo from Build-Depends to Build-Depends-Indep

[Daniel Schepler]

Source: m4
Version: 1.4.17-2
Severity: wishlist
Tags: patch

For the purposes of bootstrapping, it would be nice to be able to
build m4 without texinfo installed, as m4 is much easier to bootstrap
than texinfo is.  The attached patch implements this.

(Note that there's also a dependency cycle that m4 Build-Depends on
libsigsegv-dev, which Build-Depends on autoconf, which Depends on m4.
But the autoconf script seems to handle building without libsigsegv
automatically with no further changes needed.)
-- 
Daniel Schepler
diff -urN m4-1.4.17.old/debian/control m4-1.4.17/debian/control
--- m4-1.4.17.old/debian/control2013-10-12 04:52:54.0 -0700
+++ m4-1.4.17/debian/control2014-02-06 17:01:36.463733266 -0800
@@ -3,7 +3,8 @@
 Priority: standard
 Maintainer: Santiago Vila 
 Standards-Version: 3.9.4
-Build-Depends: debhelper (>= 9.20120311), texinfo, libsigsegv-dev
+Build-Depends: debhelper (>= 9.20120311), libsigsegv-dev
+Build-Depends-Indep: texinfo
 Homepage: http://www.gnu.org/software/m4/
 
 Package: m4
diff -urN m4-1.4.17.old/debian/rules m4-1.4.17/debian/rules
--- m4-1.4.17.old/debian/rules  2013-12-01 04:53:30.0 -0800
+++ m4-1.4.17/debian/rules  2014-02-06 17:02:22.316712792 -0800
@@ -14,7 +14,9 @@
 override_dh_auto_configure:
dh_auto_configure -- --disable-rpath
 
-override_dh_installdocs:
+override_dh_installdocs-indep:
cd doc && makeinfo --html $(package).texi
dh_installdocs -i doc/$(package)/*.html
+
+override_dh_installdocs-arch:
dh_installdocs -a NEWS README TODO THANKS

Bug#653008: sasl2-bin backup database prompt does not seem to default as intended

[Roberto C . Sánchez]

tags 653008 + unreproducible
thanks

Ian,

I have tried several times to reproduce this bug, but I cannot seem to
observe the behavior you reported.  Can you confirm if this is still a
bug for you?

Regards,

-Roberto

On Thu, Dec 22, 2011 at 06:20:55PM +, Ian Jackson wrote:
> Package: sasl2-bin
> Version: 2.1.23.dfsg1-7
> 
> I installed this package (just because I wanted saslauthd) and it
> asked me where to put some backup database.  It refused to take
> "return" to mean the default value.
> 
> See the transcript below.
> 

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#737939: postinst requires /etc/{passwd, group}, but doesn't depend on base-passwd, breaking cdebootstrap

[Stefan Lippers-Hollmann]

Package: base-files
Version: 7.2
Severity: important
Tags: patch
X-Debbugs-Cc: Bastian Blank , 
 Debian Install System Team , 
 Colin Watson 

Hi

[ CC'ing the maintainers of the other involved packages, cdebootstrap, 
  base-passwd and cdebconf/ libdebconfclient0 ]

Trying to cdebootstrap Debian unstable fails starting with the 
2014-01-10 22:01:06[2] dinstall (2014-01-10 16:12:15[1]) is still o.k.)
by throwing the following error condition:

# cdebootstrap --arch=amd64 --flavour=minimal --debug --verbose sid /mnt/ 
http://ftp.de.debian.org/debian/
[…]
O: Setting up libdebconfclient0:amd64 (0.187) ...
P: Configuring package libdebconfclient0:amd64
O: Setting up base-files (7.2) ...
P: Configuring package base-files
D: Updating base-files to status 3
O: chown: invalid user: 'root:root'
O: dpkg: error processing package base-files (--configure):
O:  subprocess installed post-installation script returned error exit status 1
[…]
O: Processing triggers for libc-bin (2.17-97) ...
O: Errors were encountered while processing:
O:  base-files
O:  bash
D: Status: 256
E: Internal error: install

The cause for this appears to be a subtile change of the implicit 
package configuration order under cdebootstrap, triggered by 
libdebconfclient0 gaining multi-arch qualifiers with 0.186 --> 0.187. 
This results in base-passwd now being configured after base-files, 
while base-files already depends on /etc/passwd and /etc/group from its
postinst:

--- 20140110T161215Z
+++ 20140110T220106Z
@@ -245,7 +245,7 @@ P: Unpacking package tar
 P: Unpacking package libtinfo5:amd64
 P: Unpacking package mawk
 P: Unpacking package base-files
-P: Unpacking package libdebconfclient0
+P: Unpacking package libdebconfclient0:amd64
 P: Unpacking package base-passwd
 P: Unpacking package sensible-utils
 P: Unpacking package debianutils
@@ -309,8 +309,6 @@ P: Configuring package debianutils
 P: Configuring package bsdutils
 P: Configuring package perl-base
 P: Configuring package diffutils
-P: Configuring package libdebconfclient0
-P: Configuring package base-passwd
 P: Configuring package mawk
 P: Configuring package hostname
 P: Configuring package findutils
@@ -324,9 +322,11 @@ P: Configuring package libsepol1:amd64
 P: Configuring package tzdata
 P: Configuring package zlib1g:amd64
 P: Configuring package libgcc1:amd64
+P: Configuring package libdebconfclient0:amd64
 P: Configuring package base-files
 P: Configuring package libattr1:amd64
 P: Configuring package e2fslibs:amd64
+P: Configuring package base-passwd
 P: Configuring package libcomerr2:amd64
 P: Configuring package libacl1:amd64
 P: Configuring package libslang2:amd64

I think this should be solvable by declaring a dependency on 
base-passwd to base-files, so base-passwd gets configured before
base-files' postinst tries to use chown:

diff -Nrup a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Package: base-files
 Provides: base
 Architecture: any
 Pre-Depends: awk
+Depends: base-passwd
 Essential: yes
 Priority: required
 Replaces: base, miscutils, dpkg (<= 1.15.0)

Given that this cdebootstrap breakage affects the first bootstrap 
phase, I have not been able to actually test this patch, but I hope
it fixes the problem.

Regards
Stefan Lippers-Hollmann

[1] http://snapshot.debian.org/archive/debian/20140110T161215Z/debian/ [ok]
[2] http://snapshot.debian.org/archive/debian/20140110T220106Z/debian/ 
[broken]


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

Bug#737882: atheme-services: status on the init script fails

[Antoine Beaupré]

On 2014-02-06 20:13:03, Mike Mestnik wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Attached find two patch files, one bug/lintian and the other
> incorporates features.

Hi!

First, thanks for the patches! It's always appreciated.

Can you clarify a little more why those patches are necessary?

For example, here:

> diff --git a/debian/init.d b/debian/init.d
> index c026287..89bad8d 100644
> --- a/debian/init.d
> +++ b/debian/init.d
> @@ -29,6 +29,7 @@ if [ "$ENABLED" != "1" ] ; then
>  fi
>  
>  set -e
> +. /lib/lsb/init-functions
>  
>  case "$1" in
>start)
> @@ -104,12 +105,11 @@ case "$1" in
>   exit 3
>   else
>   if [ -f "$RUNDIR/atheme.pid" ]; then
> - ( set +e
> + set +e
>   start-stop-daemon --status --quiet --pidfile 
> $RUNDIR/atheme.pid
>   ext=$?
>   echo "."
>   exit $ext
> - )
>   fi
>   echo "pid file missing."
>   exit 3

How do those two chunks relate? I understand sourcing init-functions may
be a good idea, but why remove the subshell?

It seems to me that we disable error-checking for the whole script
there, and only in this case... a little messy. If we want to avoid the
subshell, we should probably "|| true" somewhere on the critical section
instead of removing the subshell.

> diff --git a/debian/init.d b/debian/init.d
> index 89bad8d..77e9452 100644
> --- a/debian/init.d
> +++ b/debian/init.d
> @@ -99,23 +99,7 @@ case "$1" in
>   echo "."
>   ;;
>status)
> - echo -n "Status $DESC: $NAME "
> - if [ ! -d "$RUNDIR" ]; then
> - echo "run folder missing!"
> - exit 3
> - else
> - if [ -f "$RUNDIR/atheme.pid" ]; then
> - set +e
> - start-stop-daemon --status --quiet --pidfile 
> $RUNDIR/atheme.pid
> - ext=$?
> - echo "."
> - exit $ext
> - fi
> - echo "pid file missing."
> - exit 3
> - fi
> - echo unknown.
> - exit 4
> + status_of_proc -p $RUNDIR/atheme.pid $DAEMON $NAME
>   ;;
>*)
>   N=/etc/init.d/$NAME

This one makes a little more sense, but maybe the init function sourcing
belongs here?

Thanks again,

A.

-- 
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sebastien Faure


pgpRoPWYNmY8P.pgp
Description: PGP signature

Bug#737938: BUG: unable to handle kernel paging request at 000008000000001c

[Stephen Powell]

Package: linux
Version: 3.11.10-1

[38587.355263] BUG: unable to handle kernel paging request at 081c
[38587.355328] IP: [] find_get_page+0x29/0x90
[38587.355382] PGD 0
[38587.355401] Oops:  [#1] SMP
[38587.355430] Modules linked in: tun bnep rfcomm bluetooth rfkill parport_pc 
ppdev lp parport nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc 
fuse loop usb_storage ata_generic snd_hda_codec_realtek kvm crc32c_intel 
ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul 
glue_helper evdev edac_mce_amd psmouse edac_core pcspkr radeon serio_raw 
fam15h_power k10temp sp5100_tco ttm drm_kms_helper drm i2c_algo_bit wmi button 
snd_hda_intel sg snd_hda_codec acpi_cpufreq snd_hwdep mperf snd_pcm processor 
snd_page_alloc snd_seq snd_seq_device snd_timer sr_mod ohci_pci cdrom ohci_hcd 
snd pata_atiixp i2c_piix4 ehci_pci ehci_hcd i2c_core usbcore alx thermal_sys 
shpchp usb_common soundcore
mdio ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata scsi_mod 
microcode
[38587.356087] CPU: 2 PID: 4050 Comm: hercules Not tainted 3.11-2-amd64 #1 
Debian 3.11.10-1
[38587.356151] Hardware name: Gigabyte Technology Co., Ltd. 
GA-78LMT-S2P/GA-78LMT-S2P, BIOS F3 10/18/2012
[38587.356223] task: 8801f42b1140 ti: 8801f436c000 task.ti: 
8801f436c000
[38587.356281] RIP: 0010:[]  [] 
find_get_page+0x29/0x90
[38587.356348] RSP: 0018:8801f436dd80  EFLAGS: 00010246
[38587.356390] RAX: 880101caf718 RBX: 8801e06379f8 RCX: fffa
[38587.356445] RDX: 0800 RSI: 000444c4 RDI: 
[38587.356499] RBP: 000444c4 R08: 0800 R09: 880101caf718
[38587.356554] R10: 0006 R11: 0293 R12: 000e
[38587.356608] R13: eac3b920 R14:  R15: 8801f4233580
[38587.356664] FS:  7f2c70237700() GS:88020fc8() 
knlGS:
[38587.356726] CS:  0010 DS:  ES:  CR0: 80050033
[38587.356770] CR2: 081c CR3: 0001f434c000 CR4: 000407e0
[38587.356825] Stack:
[38587.356842]  8801e06379f0 000444c4 8110c720 
8801e06378a0
[38587.356904]   8801f42335f8 000444d2 
810abac2
[38587.356965]  000444c3 000444c4  
8801f436de68
[38587.357027] Call Trace:
[38587.357053]  [] ? generic_file_aio_read+0x250/0x6f0
[38587.357108]  [] ? do_sync_read+0x67/0x90
[38587.357154]  [] ? vfs_read+0x94/0x160
[38587.357199]  [] ? SyS_read+0x43/0xa0
[38587.357244]  [] ? system_call_fastpath+0x16/0x1b
[38587.357291] Code: 00 00 55 48 89 f5 53 48 8d 5f 08 48 89 ee 48 89 df e8 ac 
e5 14 00 48 85 c0 49 89 c1 74 34 48 8b 10 48 85 d2 74 26 f6 c2 03 75 45 <8b> 4a 
1c 85 c9 74 d9 8d 71 01 48 8d 7a 1c 89 c8 f0 0f b1 72 1c
[38587.357502] RIP  [] find_get_page+0x29/0x90
[38587.357551]  RSP 
[38587.360506] CR2: 081c
[38587.363626] ---[ end trace a69c5e0ca2716703 ]---

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


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

Bug#737819: [Openstack-devel] Bug#737819: nova: Newly introduced templates should get a review by debian-l10n-english

[Thomas Goirand]

On 02/06/2014 06:58 PM, Justin B Rye wrote:
>This value will be the static address for this compute node, and
>must use IPv4 unless use_ipv6 is manually set to "True".

No, it will always be an IPv4, because that's what is used to contact
the node. IPv6 has to do with the VM ran inside the node. I don't think
it's possible to use an IPv6 for my_ip, but that's not really a problem
since this is all inside a private IPv4 range.

Cheers,

Thomas


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

Bug#700461: android-tools-adb: does not support > 2GB files (adb backup, etc)

[Norman Ramsey]

Package: android-tools-adb
Version: 4.2.2+git20130529-3
Followup-For: Bug #700461

Followup: it does no good to be able to write a large backup file
without later being able to read it.  Attached is a patch that enables
reading. 


-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash

Versions of packages android-tools-adb depends on:
ii  libc62.17-97
ii  libssl1.0.0  1.0.1e-2
ii  zlib1g   1:1.2.7.dfsg-13

android-tools-adb recommends no packages.

android-tools-adb suggests no packages.

-- no debconf information
Description: put O_LARGEFILE into adb_open and adb_open_mode
 You need this or you can't restore from a large file.
Author: Norman Ramsey 
Bugs-Debian: 700461

--- android-tools-4.2.2+git20130529.orig/core/adb/sysdeps.h
+++ android-tools-4.2.2+git20130529/core/adb/sysdeps.h
@@ -341,7 +341,7 @@ static __inline__ int  unix_open(const c
 
 static __inline__ int  adb_open_mode( const char*  pathname, int  options, int  mode )
 {
-return TEMP_FAILURE_RETRY( open( pathname, options, mode ) );
+return TEMP_FAILURE_RETRY( open( pathname, options | O_LARGEFILE, mode ) );
 }
 
 static __inline__  int  adb_creat(const char*  path, int  mode)
@@ -360,7 +360,7 @@ static __inline__  int  adb_creat(const
 
 static __inline__ int  adb_open( const char*  pathname, int  options )
 {
-int  fd = TEMP_FAILURE_RETRY( open( pathname, options ) );
+int  fd = TEMP_FAILURE_RETRY( open( pathname, options | O_LARGEFILE ) );
 if (fd < 0)
 return -1;
 close_on_exec( fd );

Bug#685083: Acknowledgement (special characters in Subject mess up terminal)

[Adam Lee]

Another example, really annoying:

Subject: We Have A Package For You,Contact For More 
=?utf-8?b?RGV0YWlsc+KAj+KAjw==?=

060: 6361 6369 6f2e 636f 6d3e 0a54 6f3a 0a53  cacio.com>.To:.S
070: 7562 6a65 6374 3a20 5765 2048 6176 6520  ubject: We Have
080: 4120 5061 636b 6167 6520 466f 7220 596f  A Package For Yo
090: 752c 436f 6e74 6163 7420 466f 7220 4d6f  u,Contact For Mo
0a0: 7265 2044 6574 6169 6c73 e280 8fe2 808f  re Details..
0b0: 0a52 6570 6c79 2d74 6f3a 2066 6564 6578  .Reply-to: fedex

-- 
Adam Lee


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

Bug#727708: Call for votes on init system resolution

[Nikolaus Rath]

Russ Allbery  writes:
> Don Armstrong  writes:
>> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
>
>>> So let me expand on that a little.  Image the following options
>>> - A: something that doesn't overrule the ctte (1:1)
>>> - B: something that does overrule the ctte (2:1)
>>> - FD
>
>> In this case, I don't know A could be anything but 2:1, baring riders
>> from the CTTE. If A is technical, it needs the power of the CTTE under
>> §4.1.4 which requires 2:1. [I suppose something could be written which
>> would fall under the DPL's remit.]
>
>> As I understand it, we'd like to make everything be 1:1, and the method
>> we're trying is to write a proposal in such a way that it automatically
>> enshrouds a non-technical statement by the project in the power of the
>> CTTE.
>
>> It may be that we can't actually do that, and should instead just have
>> an agreement between CTTE members to enact a decision which followed a
>> position statement GR under §4.1.5.
>
> I think what we're trying to say looks something like this:
>
> If the project holds a GR vote on the topic of the default init
> system, the winning option of that vote replaces this text in its
> entirety and becomes the decision of the Technical Committee.  The
> winning option of the GR vote for this purpose will be decided
> following the normal rules for deciding the outcome of a General
> Resolution, with the exception that the 2:1 majority normally required
> to overule the Technical Committee will not be taken into account.
>
> I think this works, although it does create the possibility of a rather
> odd situation, and I'm not quite sure how it would work procedurally.
[more complicated stuff snipped]

It is not at all clear to me why the CTTE so desperately wants to
automatically defer to a GR in their resolution. If there is consensus
to defer to a GR with simple majority among the CTTE, surely it would be
easy enough to revoke or change the resolution if/when a GR has actually
happened?


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


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

Bug#731265: confirmed

[Nils Goroll]

I believe this report is correct, i am having the same problem. The issue here 
is that the nvidia xrandr provider does not have "cap: 0x1, Source Output"


slink@haggis:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x32e cap: 0x0 crtcs: 4 outputs: 2 associated providers: 0 
name:NVIDIA-0
Provider 1: id: 0x48 cap: 0x2, Sink Output crtcs: 3 outputs: 6 associated 
providers: 0 name:modesetting


I do not yet understand why this is happening.

This is on a lenovo thinkpad w540 with nvidia K2100M.

root@haggis:~# uname -a
Linux haggis 3.13-trunk-amd64 #1 SMP Debian 3.13-1~exp1 (2014-01-20) x86_64 
GNU/Linux


also reproduced on 3.12-1

nvidia driver 331.38 and 319.76

This thread has good coverage of the topic: 
https://forums.gentoo.org/viewtopic-p-7413808.html


Nils


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

Bug#737933: kicad-common includes trash footprint documentation

[Arian Sanusi]

Package: kicad-common
Version: 0.20131208+bzr4024-1
Severity: normal

as of this version kicad-common packages many footprint documentation
files that bloat the package from 133MB to 416MB installed size. These
appear to be autogenerated eps-files that are actually bitmaps and
despite their size are of unusable quality. They do not offer more
information than the footprint files themself. On my laptop this bloat
precludes the installation of this version of kicad due to size
constraints. Please remove the files or change them to some more
appropriate format.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'stable'), (550, 'unstable'), (500, 
'raring'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

kicad-common depends on no packages.

Versions of packages kicad-common recommends:
ii  kicad  0.20130727+bzr4024-2

kicad-common 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#737934: kcheckers: please provide a desktop file and icons

[Markus Koschany]

Package: kcheckers
Version: 0.8.1-3
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently kcheckers does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737903: Correction

[Paul]

Meant to say "... upgraded the libtotem-plparser17 package from 3.4.5-4+b1
to
libtotem-plparser18 3.10.0-1 using the experimental repo.

Paul

Bug#727708: Call for votes on init system resolution

[Russ Allbery]

Anthony Towns  writes:

> It's really pretty terrible to actively use FD to try to block options
> that aren't your favourite. Honestly, I would have expected the tech
> ctte to be able to come to a consensus on a set of proposals considered
> reasonable by all the members, and accept whatever a majority
> decided. I'd certainly hope that tech ctte members won't tactically
> change their vote to try to hack the process.

> (The obvious counter is for the four members who prefer T to L to vote
> all the L options below FD in the same way as Andi, Ian and Steve have
> voted all the T options below FD)

Exactly.

I've been trying to refrain from tactical voting of that sort.  I don't
think that's a slippery slope we should start diving down.

I also flatly disagree with Adrian over whether we're deadlocked.  I don't
see any point in discussing it, though.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#737932: jigzo: menu file needs absolute icon path

[Markus Koschany]

Package: jigzo
Version: 0.6.1-6
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

jigzo's file needs an absolute icon path otherwise the icon won't be
displayed on the user's desktop.

See also

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#734019: RFS: python-nagiosplugin/1.2-1 -- Python class library for writing Nagios (Icinga) plugins

[Jordan Metzmeier]

On Thu, Feb 6, 2014 at 6:16 PM, Jan Dittberner  wrote:
> On Thu, Jan 02, 2014 at 10:23:32PM -0600, Jordan Metzmeier wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "python-nagiosplugin":
>
> Hello Jordan,
>
> I'll have a look at the packaging and will sponsor an upload if it is fine.
>
> What do you think about co-maintenance with the Python Modules Packaging
> team? This usually improves the chances for sponsorship.
>
>
> Best regards
> Jan

Hi Jan,

I am open to team maintenance of the package. I have already joined
the team on Alioth in anticipation of that. Do I need to change the
maintainer field or is that something typically done by the uploader?

-- 
Regards,
Jordan Metzmeier


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

Bug#700461: android-tools-adb: does not support > 2GB files (adb backup, etc)

[Norman Ramsey]

Package: android-tools-adb
Version: 4.2.2+git20130529-3
Followup-For: Bug #700461

Dear Maintainer,

This bug still exists.  I have attached an updated patch (which I am
now testing).  If the bug could be fixed, that would be just lovely.


-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash

Versions of packages android-tools-adb depends on:
ii  libc62.17-97
ii  libssl1.0.0  1.0.1e-2
ii  zlib1g   1:1.2.7.dfsg-13

android-tools-adb recommends no packages.

android-tools-adb suggests no packages.

-- no debconf information
Description: add O_LARGEFILE support to adb_creat
 Summary says it all.
 .
 android-tools (4.2.2+git20130529-3) unstable; urgency=low
 .
Author: Norman Ramsey 
Bug-Debian: http://bugs.debian.org/700461


--- android-tools-4.2.2+git20130529.orig/core/adb/sysdeps.h
+++ android-tools-4.2.2+git20130529/core/adb/sysdeps.h
@@ -344,6 +344,19 @@ static __inline__ int  adb_open_mode( co
 return TEMP_FAILURE_RETRY( open( pathname, options, mode ) );
 }
 
+static __inline__  int  adb_creat(const char*  path, int  mode)
+{
+int  fd = open(path, O_CREAT | O_WRONLY | O_TRUNC | O_LARGEFILE, mode);
+
+if ( fd < 0 )
+return -1;
+
+close_on_exec(fd);
+return fd;
+}
+
+#undef   creat
+#define  creat  ___xxx_creat
 
 static __inline__ int  adb_open( const char*  pathname, int  options )
 {
@@ -400,19 +413,6 @@ static __inline__  intadb_unlink(con
 #undef  unlink
 #define unlink  ___xxx_unlink
 
-static __inline__  int  adb_creat(const char*  path, int  mode)
-{
-int  fd = TEMP_FAILURE_RETRY( creat( path, mode ) );
-
-if ( fd < 0 )
-return -1;
-
-close_on_exec(fd);
-return fd;
-}
-#undef   creat
-#define  creat  ___xxx_creat
-
 static __inline__ int  adb_socket_accept(int  serverfd, struct sockaddr*  addr, socklen_t  *addrlen)
 {
 int fd;

Bug#737931: RM: u-boot [amd64 i386 ia64 s390x sparc hurd-i386 kfreebsd-amd64 kfreebsd-i386 mipsel] -- RoQA; NBS; u-boot .deb now only built on architectures which generate images

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

u-boot (2013.10-3) unstable; urgency=low
  * Disable mipsel builds of u-boot, as it no longer has any targets.

u-boot (2013.10-1) unstable; urgency=low
  * Only build u-boot on architectures which generate images (Closes: #635050).
  * Drop i386 builds of u-boot, as the only target (eNET) was removed upstream.


I'm not sure about the status of the uboot-envtools and uboot-mkimage
packages in sid. They are no longer built and should be removed as well.

u-boot (2013.01.01-4) unstable; urgency=low
  * Drop transitional packages uboot-envtools and uboot-mkimage.


Andreas


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

Bug#734019: RFS: python-nagiosplugin/1.2-1 -- Python class library for writing Nagios (Icinga) plugins

[Jan Dittberner]

On Thu, Jan 02, 2014 at 10:23:32PM -0600, Jordan Metzmeier wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-nagiosplugin":

Hello Jordan,

I'll have a look at the packaging and will sponsor an upload if it is fine.

What do you think about co-maintenance with the Python Modules Packaging
team? This usually improves the chances for sponsorship.


Best regards
Jan

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://www.dittberner.info/


signature.asc
Description: Digital signature

Bug#737930: holdingnuts: please provide a menu file and icons

[Markus Koschany]

Package: holdingnuts
Version: 0.0.5-4
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently holdingnuts does not supply a menu file and no menu icons.
Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#578563: Package review

[Samuel Lidén Borell]

2014-02-06 23:27, Per Andersson skrev:
>>> There are some problems with the test page. It blocks 64-bit browsers
>>> by the User-Agent HTTP header as you discovered. There are also some
>>> other problems. It's probably not possible to fix completely, but it
>>> should be documented in the manpage anyway.
>>
>> Does faking the User-Agent HTTP header help (as in
>> xul-ext-useragentswitcher) make any difference?  It seems to me the
>> User-Agent HTTP header is an incompetent/lame way (on the server side)
>> to assess ability.
> 
> Tried this, after first visiting a page stating
> 
> Checking your version of BankID Security Application...
> 
> I just got another error message
> 
> An unknown error has occurred.
> An unpredicted error has occurred.

These errors happen because of unimplemented functions in FriBID (some
proprietary challenge/response schemes). These are needed by the test
web site but not by most (any?) other web sites that use BankID.

Since there are a lot of problems with the official test web site, it's
probably easier to simply create our own test page that does not use
these functions. I'll do that this weekend.

--
Samuel


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

Bug#737929: robot-player: Playerc++ pkg-config depends on playerwkb but there is no debian package interdependency

[Jose Luis Rivero]

Package: robot-player
Severity: minor

The current .pc file provided by playerc++ define a 'Require' on
playerwkb but this dependency is not declared in debian playerc++3.0-dev
package (on playerwkb3.0-dev). 

This could lead to systems where playerc++3.0-dev is installed but the
pkgconfig file (verified using cmake FindPkgConfig) is not able to work
fine if playerwkb.pc file is not present (CMakeCache.txt PLAYER
variables are empty).

For reference, the issue in our bug tracker:
  https://bitbucket.org/osrf/gazebo/issue/1018


A test case is as simple as:

-- 8< --
cmake_minimum_required(VERSION 2.8)
include (FindPkgConfig)

pkg_check_modules(PLAYER playerc++>=3.0)
-- 8< --

and check CMakeCache.txt for PLAYER_INCLUDE_DIRS variable.


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


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

Kernel: Linux 3.2.0-58-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash


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

Bug#737928: hexxagon: please provide a desktop file and icons

[Markus Koschany]

Package: hexxagon
Version: 1.0pl1-3.1
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently hexxagon does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737895: twinkle: Twinkle UI does not show at all

[Enrico Zini]

On Thu, Feb 06, 2014 at 08:36:18PM +, Martín Ferrari wrote:

> I don't know how this happens; possibly some configuration in my user is
> creating this situation (as otherwise nobody would be able to use twinkle), 
> but
> in any case it seems serious enough to warrant a bug report.

It's not just you, I get the same.

stracing shows that twinkle is trying to read from stdin. Indeed if I
press enter, a prompt appears for the twinkle shell. Closing stdin makes
the program try to quit (at least, here it tries to deregister from the
current SIP server), but then it hangs and requires a SIGQUIT to quit
(^C is not enough).

Looking at the manpage, I tried twinkle --show, but it doesn't seem to
work as documented:

  $ twinkle --show
  Critical: Cannot open file for reading: /home/enrico/.twinkle/--show


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


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

Bug#616163: running multiple instances of memcached

[Jon Daley]

I believe this is already fixed, isn't it?  I forgot that this bug was 
opened.  But, the last time I installed memcached, I was able to use a 
memcached_server1.conf and is loaded properly.  Is the patch to 
/usr/share/memcached/scripts/start-memcached needed?


I'm using 1.4.13-0.3.

On Thu, 6 Feb 2014, Rabus Andreas wrote:


There is a partial fix in the 1.4.5-1+deb6u1 Version.

It seems to be from this site, (in german)
http://blog.nevalon.de/de/wie-kann-ich-mehrere-instanzen-von-memcached-auf-einem-server-laufen-lassenhow-can-i-run-multiple-instances-of-memcached-on-one-server-20090729

It's just missing a patch to /usr/share/memcached/scripts/start-memcached


26,30d25


if (scalar(@ARGV) == 2) {
 $etcfile = shift(@ARGV);
 $pidfile = shift(@ARGV);
}



With this in place  running multipl instances works fine.
config are kept in /etc/memcached_*.conf.

Best regards,

Andreas



--
Jon Daley
http://jon.limedaley.com
~~
The ultimate measure of a man is not where he stands in
moments of comfort, but where he stands at times of challenge.
-- Martin Luther King, Jr.


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

Bug#737927: gweled: please provide a menu file and icons

[Markus Koschany]

Package: gweled
Version: 0.9.1-3
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gweled does not supply a menu file and no menu
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737926: gtkpool: please provide a desktop file and icons

[Markus Koschany]

Package: gtkpool
Version: 0.5.0-9
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gtkpool does not supply a desktop file and no desktop and menu
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737925: gtkboard: missing menu icon entry

[Markus Koschany]

Package: gtkboard
Version: 0.11pre0+cvs.2003.11.02-6
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gtkboard does not supply a menu icon hence the
game is not well integrated into the user's desktop environment.
Please consider adding an icon entry to your menu file.

Please refer to

https://wiki.debian.org/Games/JessieReleaseGoal

for further information.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Daniel Kahn Gillmor]

Hi Jan--

On 02/06/2014 06:14 PM, Jan Nordholz wrote:
> Package: gnutls26
> Version: 2.12.23-10
 [...]
> Better not be an early adopter and create certificates with SHA512...
> downgraded the certificate's hash algorithm, and it works flawlessly again.
> 
> This error message "Insufficient credentials for that request" *really* has
> to go away or to be replaced with something more meaningful. Calling this
> "misleading" is still euphemistic...

I agree this is a bad error message for the situation where the digest
isn't supported.

Have you tested this against libgnutls28?  GnuTLS 3.2.10-2 is the latest
version in jessie and sid, and 3.2.8.1-2~bpo70+1 is in wheezy-backports.
 I believe you'll find it resolved in this version.

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#737924: gsalliere: please provide a desktop file and icons

[Markus Koschany]

Package: gsalliere
Version: 0.10-1
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gsalliere does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737923: groundhog: please provide a desktop file and icons

[Markus Koschany]

Package: groundhog
Version: 1.4-9
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently groundhog does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737791: RFS: vimhelp-de/7.4.130818-3 [ITA]

[Julian Göstl]

Hi,

thank you very much!

I updated the package.

Regards,
Julian

Am 06.02.2014 07:40, schrieb Dariusz Dwornikowski:

Hi,

I cannot be your sponsor but here are some advices. On [1] you can see 
lintian warning and errors. You should fix them. For example: Package 
uploaded for the unreleased distribution means that you need to change 
your changelog entry so the distribution is unstable not UNRELEASED. 
Also you should have Build-Depends: debhelper (>= 9.0), in control 
file, as lintian suggests.



A good practice is to make lintian checks locally with the same level 
of details as on mentors, in ~/.config/lintian/lintianrc:


pedantic=yes
display-info=yes

[1] http://mentors.debian.net/package/vimhelp-de


On 6 February 2014 00:59, Julian Goestl > wrote:


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vimhelp-de"

  Package name: vimhelp-de
  Version :7.4.130818-3  
  Upstream Author :Florian 'eix' Rehnisch
  <
/span>
  URL :http://www.florianrehnisch.de/vimhelp/
  License : Open Publication License without any options v1.0, 8 
June 1999
  Section : doc

It builds those binary packages:

   vimhelp-de - Vi IMproved - Documentation files (German translation)

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

   http://mentors.debian.net/package/vimhelp-de


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

   dget 
-xhttp://mentors.debian.net/debian/pool/main/v/vimhelp-de/vimhelp-de_7.4.130818-3.dsc


Changes since the last upload:

   Clean up and update Standards version to 3.9.5


Regards,
  Julian Goestl




--
Pozdrawiam,
Dariusz Dwornikowski, Assistant
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/ 


room 2.7.2 BTiCW | tel. +48 61 665 29 41

Bug#737922: granule: please provide a menu file and icons

[Markus Koschany]

Package: granule
Version: 1.4.0-7-2
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently granule does not supply a menu file and no menu
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Jan Nordholz]

Package: gnutls26
Version: 2.12.23-10
Severity: minor

Dear GnuTLS maintainers,

I've just spent several hours debugging a problem which I think should be
stated somewhere. (Severity minor as it's a documentation issue.)

After replacing some expired certificates, I wondered why satellite exim4
instances would no longer talk to the one that had just received a new
certificate. With s_client and gnutls-cli-debug I could narrow the problem
down to a problem with TLS1.2 - albeit the reason was completely opaque.
The only output on the server side was the infamous

] (gnutls_handshake): Could not negotiate a supported cipher suite.

After single-stepping through exim and hotpatching _gnutls_log_level and
_gnutls_log_func to meaningful values I found that the library was
removing all the ciphers, accompanied by another, even more cryptic
message about the server certificate:

] Feb  6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:3348
] Feb  6 23:19:58 $HOST exim4: Could not find an appropriate certificate: 
Insufficient credentials for that request.
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_ARCFOUR_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_3DES_EDE_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_AES_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_AES_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_CAMELLIA_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_CAMELLIA_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_AES_128_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_DSS_AES_256_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_3DES_EDE_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_AES_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_AES_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_CAMELLIA_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_CAMELLIA_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_AES_128_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
DHE_RSA_AES_256_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_ARCFOUR_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_ARCFOUR_MD5
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_3DES_EDE_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_AES_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_AES_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_CAMELLIA_128_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_CAMELLIA_256_CBC_SHA1
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_AES_128_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite: 
RSA_AES_256_CBC_SHA256
] Feb  6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:921
] Feb  6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:586
] Feb  6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:2358
] Feb  6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:2991

$SEARCHING revealed that I might have set improper keyUsage extensions on the
certificate - however there were none, and as I generated another certificate
with explicit keyUsage just to check, sure enough the problem persisted.

So another round of digging into GnuTLS source code, until I finally
stumbled across this gem:

] int
] _gnutls_server_select_cert (gnutls_session_t session,
] gnutls_pk_algorithm_t requested_algo)
] {
] [...]
]   for (i = 0; i < cred->ncerts; i++)
] {
]   /* find one compatible certificate
]*/
]   if (requested_algo == GNUTLS_PK_ANY ||
]   requested_algo == cred->cert_list[i][0].subject_pk_algorithm)
] {
]   /* if cert type and signature algorithm matches
]*/
]   /* *INDENT-OFF* */
]   if (session->security_parameters.cert_type
]   == cred->cert_list[i][0].cert_type
]   && (cred->cert_list[i][0].cert_type == GNUTLS_CRT_OPENPGP
]   ||/* FIXME: make this a check for certificate
]type capabilities */
]   !_gnutls_version_has_selectable_sighash
]   (gnutls_protocol_get_version (session))
]   ||
]   _gnutls_sessio

Bug#726591: vim-common: mailcap vim -R

[Kevin Ryde]

James McCoy  writes:
>
>>   vim -R %s
>
> There was some discussion about the view alternative on debian-devel
> last year and the mime-support maintainer had agreed that /usr/bin/see
> shouldn't be part of that alternative set.

I agree see should not be view, but I'd meant this particular bug to be
among the actual vi's -- ie. to be sure of getting vim and not say nvi.


(I've thought further that there's probably no need for the generic "vi"
rules presently in /usr/lib/mime/packages/vim-common.  If each vi
flavour has rules then all are covered.  Or if the rule is present then
it ought to check that a vi exists, and perhaps ought to be in
mime-support package so as not to depend on vim-common in case you've
removed it in favour of nvi etc.)


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

Bug#737920: gpsshogi: please provide a desktop file and icons

[Markus Koschany]

Package: gpsshogi
Version: 0.6.0-2
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gpsshogi does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737919: gnurobots: please provide a desktop and menu file and icons

[Markus Koschany]

Package: gnurobots
Version: 2:1.2.0-6
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnurobots does not supply a desktop and menu file and no
desktop and menu icons. Hence the game is not well integrated into the
user's desktop environment. Please consider helping to improve the
desktop integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737918: gnugo: missing icons for menu and desktop file

[Markus Koschany]

Package: gnugo
Version: 3.8-7
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnugo does not supply a menu and desktop file icon hence the
game is not well integrated into the user's desktop environment.
Please consider adding these icons.

Please refer to

https://wiki.debian.org/Games/JessieReleaseGoal

for further information.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 7 February 2014 08:44, Adrian Bunk  wrote:
> If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
> then T is dead.

It's really pretty terrible to actively use FD to try to block options
that aren't your favourite. Honestly, I would have expected the tech
ctte to be able to come to a consensus on a set of proposals
considered reasonable by all the members, and accept whatever a
majority decided. I'd certainly hope that tech ctte members won't
tactically change their vote to try to hack the process.

(The obvious counter is for the four members who prefer T to L to vote
all the L options below FD in the same way as Andi, Ian and Steve have
voted all the T options below FD)

(Longer term, it seems to me the vote system would be improved by only
allowing voters to cast a vote that ranks the proposed options between
themselves, or to vote for Further Discussion (with no ability to
express preferences amongst the proposals). Quorum would then be
satisfied by having Q votes ranking the options, and a vote would only
be blocked if there was 50% or more of voters voting for FD. A similar
idea to supermajority requirements could be achieved by allowing
proposals to be blocked by 1/N voters voting for FD where N > 2)

Cheers,
aj

-- 
Anthony Towns 


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

Bug#737917: ntop phones home every time it's started

[Jaap Keuter]

Package: ntop
Version: 3:5.0.1+dfsg1-1
Severity: important

Dear Maintainer,

When working on configuring NTOP I was tweaking parameters through the 
/etc/default/ntop variable GETOPT. Reading the help and man page one thing I 
found was --skip-version-check.
This sparked my interest to look at the network traffic generated. Indeed when
starting the ntop service there's HTTP traffic going to kpn.ntop.org, which is
the CNAME for version.ntop.org. A bunch of data is pushed to it and a version
check returned. 

Adding the --skip-version-check option should prohibit this. It does not. NTOP
comes back with the error that it needs a parameter for the option, which is 
not documented. Adding the parameter (like '=yes', or ' yes') allows NTOP to 
start. But looking at the log and the network traffic the version check is 
still performed. 

A telltail sign comes when one freshly installs the package. This is what 
appears in the syslog.

--8<---

 ntop[]:   CHKVER: **PRIVACY**NOTICE**
 ntop[]:   CHKVER: * ntop instances may record individually identifiable *
 ntop[]:   CHKVER: * information on a remote system as part of the version   *
 ntop[]:   CHKVER: * check.  *
 ntop[]:   CHKVER: * *
 ntop[]:   CHKVER: * You have requested - via the --skip-version-check   *
 ntop[]:   CHKVER: * option that this check be skipped and so no *
 ntop[]:   CHKVER: * individually identifiable information will be recorded. *
 ntop[]:   CHKVER: * *
 ntop[]:   CHKVER: * In general, we ask you to permit this check because it  *
 ntop[]:   CHKVER: * benefits both the users and developers of ntop. *
 ntop[]:   CHKVER: * *
 ntop[]:   CHKVER: * Review the man ntop page for more information.  *
 ntop[]:   CHKVER: * *
 ntop[]:   CHKVER: **PRIVACY**NOTICE**
 ntop[]:   CHKVER: Checking current ntop version at version.ntop.org/version.xml
 ntop[]:   CHKVER: Version file is from 'version.ntop.org'
 ntop[]:   CHKVER: as of date is '2012-10-16T11:00:47'
 ntop[]:   CHKVER: This version of ntop is the CURRENT stable version

--8<---

So first a notice that the version check is skipped, and then it's done anyway?
This cannot be right, on various levels.

What I would expect is that the version check is inhibited by default, since
we're relying on the Debian distribution channels for updates, not on 
in-application checks (which should be a general Debian Packager policy IMHO). 
And then centainly not those checks which flag out to the world every time 
when my Debian box boots up. For me enough reason to remove ntop from my box.


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

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

Versions of packages ntop depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  libgdbm3   1.8.3-12
ii  libgeoip1  1.6.0-1
ii  libpcap0.8 1.5.3-1
ii  libpython2.7   2.7.6-5
ii  librrd41.4.7-2+b1
ii  net-tools  1.60-25
ii  ntop-data  3:5.0.1+dfsg1-1
ii  passwd 1:4.1.5.1-1
ii  python-mako0.9.1-1
ii  zlib1g 1:1.2.8.dfsg-1

ntop recommends no packages.

Versions of packages ntop suggests:
ii  graphviz  2.26.3-16.1
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.2

-- debconf information:
  ntop/password_reset: false
* ntop/interfaces: none
* ntop/password_empty:
  ntop/password_mismatch:
  ntop/user: ntop


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

Bug#737916: gnuchess: please provide a desktop file and icons

[Markus Koschany]

Package: gnuchess
Version: 6.1.1-1
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnuchess does not supply a desktop file and no desktop and
menu icons. Hence the game is not well integrated into the user's
desktop environment. Please consider helping to improve the desktop
integration of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737778: [oss-security] CVE request: f2py insecure temporary file use

[Murray McAllister]

On 02/06/2014 02:59 PM, Murray McAllister wrote:

Hello,

Jakub Wilk reported insecure temporary file use in f2py. From
:

""
numpy/f2py/__init__.py contains this code:

  from numpy.distutils.exec_command import exec_command
  import tempfile
  if source_fn is None:
  fname = os.path.join(tempfile.mktemp()+'.f')
  else:
  fname = source_fn

  f = open(fname,'w')
""

Can a CVE please be assigned if one hasn't been already?

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737778
https://bugzilla.redhat.com/show_bug.cgi?id=1062009

Thanks,


Thomas Spura noted in the Red Hat Bugzilla that a patch has been merged 
upstream:


https://github.com/numpy/numpy/pull/4262


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

Bug#737915: xnest: segv on mouse entering second nest screen

[Kevin Ryde]

Package: xnest
Version: 2:1.14.5-1
Severity: normal
File: /usr/bin/Xnest

If Xnest is run with two screens then when the mouse pointer is moved
into the second screen it dies with a segfault.  Eg.

Xnest -scrns 2 :1
move mouse into second screen
=>
segv

If the mouse is already in the second screen window then move out and
then back in to provoke the problem.

(EE) Backtrace:
(EE) 0: Xnest (xorg_backtrace+0x49) [0xb7721389]
(EE) 1: Xnest (0xb7613000+0x112114) [0xb7725114]
(EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb75f140c]
(EE) 3: Xnest (0xb7613000+0x1c934) [0xb762f934]
(EE) 4: Xnest (miPointerUpdateSprite+0x178) [0xb763e908]
(EE) 5: Xnest (0xb7613000+0x2bc8e) [0xb763ec8e]
(EE) 6: Xnest (0xb7613000+0x2470b) [0xb763770b]
(EE) 7: Xnest (0xb7613000+0xe2955) [0xb76f5955]
(EE) 8: Xnest (miPointerWarpCursor+0xee) [0xb763e6fe]
(EE) 9: Xnest (0xb7613000+0x2bb72) [0xb763eb72]
(EE) 10: Xnest (0xb7613000+0xe10a6) [0xb76f40a6]
(EE) 11: Xnest (0xb7613000+0xe13ca) [0xb76f43ca]
(EE) 12: Xnest (0xb7613000+0x1d41a) [0xb763041a]
(EE) 13: Xnest (0xb7613000+0x1faf4) [0xb7632af4]
(EE) 14: Xnest (WakeupHandler+0x6a) [0xb76efe0a]
(EE) 15: Xnest (WaitForSomething+0x18b) [0xb771e75b]
(EE) 16: Xnest (0xb7613000+0xd866e) [0xb76eb66e]
(EE) 17: Xnest (0xb7613000+0x1a53a) [0xb762d53a]
(EE) 18: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xf5) 
[0xb70d68c5]
(EE) 19: Xnest (0xb7613000+0x1a918) [0xb762d918]
(EE) 
(EE) Segmentation fault at address 0x0


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

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xnest depends on:
ii  libaudit1   1:2.3.3-1
ii  libc6   2.17-97
ii  libgcrypt11 1.5.3-3
ii  libpixman-1-0   0.32.4-1
ii  libselinux1 2.2.2-1
ii  libx11-62:1.6.2-1
ii  libxau6 1:1.0.8-1
ii  libxdmcp6   1:1.1.1-1
ii  libxext62:1.3.2-1
ii  libxfont1   1:1.4.7-1
ii  xserver-common  2:1.14.5-1

Versions of packages xnest recommends:
ii  libgl1-mesa-dri  9.2.2-1

xnest 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#737914: gnubg: missing menu icon entry

[Markus Koschany]

Package: gnubg
Version: 1.02.000-2
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnubg does not supply a menu icon hence the
game is not well integrated into the user's desktop environment.
Please consider adding an icon entry to your menu file.

Please refer to

https://wiki.debian.org/Games/JessieReleaseGoal

for further information.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#727708: Call for votes on init system resolution

[Adrian Bunk]

On Thu, Feb 06, 2014 at 02:20:51PM -0800, Russ Allbery wrote:
>...
> This is one of the major reasons why I'm voting GR second.  I see Bdale's
> point that we shouldn't abdicate our responsibility to make the best
> decision that we can, and I followed that maxim by voting my preference
> first.  But the reality is that, regardless of whether Condorcet is
> capable of spitting out some technical compromise, we are deadlocked, and
> sufficiently so that we're running into edge case failure modes of the
> standard resolution method.
>...

No, looking at the votes so far you are absolutely not deadlocked since 
you might have a winner that is considered acceptable by all 8 members 
of the TC:

The most problematic option for many TC members is not D or S,
the most problematic option is T.

If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
then T is dead.

But DL might beat FD 8:0, and will likely be the overall winner since it 
is expected to beat UL through the casting vote of the chairman.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#737363: higan: crashes when importing or loading unheadered NES ROM

[Tobias Hansen]

Thank you very much Michael! byuu has quite high standards regarding the
databases so I don't want to mess with that and deviate from what he
puts in. You could ask him to put it in the next release but I doubt he
will because the databases are meant to contain verified information.

I'll probably get around to include your other patches in two weeks or so.

Cheers,
Tobias

Am 06.02.2014 05:35, schrieb Michael Gold:
> 
> Here are some patches.  The first shows an error if there's no header.
> But that's annoying, so the others add database support.  The DB has
> everything from the 20140124-114835 no-intro set, except for those noted
> below.  Most of the information was autogenerated by higan so it's not
> as detailed or clean as the SFC DB.
> 
> -- Michael
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#737912: gnome-hearts: please provide a menu file and icons

[Markus Koschany]

Package: gnome-hearts
Version: 0.3-2.1
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnome-hearts does not supply a menu file and no menu
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#578563: Package review

[Per Andersson]

>> > Tried visiting http://test.bankid.com and got this error.
>> >
>> > BankID Security Application can not be installed.
>> > yOUR PLATFORM Linux 64-bit is not supported. You find information
>> > about supported platforms here.
>> >
>> > I don't have a working BankID so maybe this is expected behaviour?
>>
>> There are some problems with the test page. It blocks 64-bit browsers
>> by the User-Agent HTTP header as you discovered. There are also some
>> other problems. It's probably not possible to fix completely, but it
>> should be documented in the manpage anyway.
>
> Does faking the User-Agent HTTP header help (as in
> xul-ext-useragentswitcher) make any difference?  It seems to me the
> User-Agent HTTP header is an incompetent/lame way (on the server side)
> to assess ability.

Tried this, after first visiting a page stating

Checking your version of BankID Security Application...

I just got another error message

An unknown error has occurred.
An unpredicted error has occurred.


--
Per


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

Bug#737913: exonerate and dnaclust: error when trying to install together

[Ralf Treinen]

Package: dnaclust,exonerate
Version: dnaclust/3-1
Version: exonerate/2.2.0-6
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2014-02-06
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libboost-program-options1.54.0:amd64.
(Reading database ... 10921 files and directories currently installed.)
Preparing to unpack .../libboost-program-options1.54.0_1.54.0-4+b1_amd64.deb ...
Unpacking libboost-program-options1.54.0:amd64 (1.54.0-4+b1) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.0.13-12_amd64.deb ...
Unpacking libffi6:amd64 (3.0.13-12) ...
Selecting previously unselected package libglib2.0-0:amd64.
Preparing to unpack .../libglib2.0-0_2.36.4-1_amd64.deb ...
Unpacking libglib2.0-0:amd64 (2.36.4-1) ...
Selecting previously unselected package dnaclust.
Preparing to unpack .../dnaclust_3-1_amd64.deb ...
Unpacking dnaclust (3-1) ...
Selecting previously unselected package exonerate.
Preparing to unpack .../exonerate_2.2.0-6_amd64.deb ...
Unpacking exonerate (2.2.0-6) ...
dpkg: error processing archive 
/var/cache/apt/archives/exonerate_2.2.0-6_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/fastasort', which is also in package dnaclust 3-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.6.6-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/exonerate_2.2.0-6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/bin/fastasort

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


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

Bug#737911: gnome-chess: please provide a menu file and icons

[Markus Koschany]

Package: gnome-chess
Version: 1:3.8.3-1
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gnome-chess does not supply a menu file and no menu
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#727708: Call for votes on init system resolution

[Russ Allbery]

Adrian Bunk  writes:
> On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:

>> Presuming everyone votes, where you put F only has an impact in either
>> case only if at least three other ctte members will also vote FD above
>> T or DT (given UT is irrelevant); which based on the already expressed
>> preferences and votes, isn't actually going to happen.

> Why not?

> I am not sure whether Colin is aware that it currently depends on him 
> whether or not DT can win - and whether that might make him consider 
> changing his vote.

> If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
> his ballot, then DT cannot pass FD and is dead.

Which is just a concrete way of pointing out that Debian's standard
resolution method fails later-no-harm.

https://en.wikipedia.org/wiki/Later-no-harm_criterion

This is a known weakness in Condorcet, which I suspect we have made worse
with the way that Debian treats FD.

This is one of the major reasons why I'm voting GR second.  I see Bdale's
point that we shouldn't abdicate our responsibility to make the best
decision that we can, and I followed that maxim by voting my preference
first.  But the reality is that, regardless of whether Condorcet is
capable of spitting out some technical compromise, we are deadlocked, and
sufficiently so that we're running into edge case failure modes of the
standard resolution method.

In that situation, the TC recusing itself is not the worst thing that
could happen.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#737897: Please follow the MIA process instead of asking for package removal

[Christian Hofstaedtler]

Hi Adrian, ftpmasters,

* Adrian Bunk  [140206 22:33]:
> please follow the MIA process [1] instead of requesting the removal of 
> packages you consider "Apparently unmaintained".

As apparently you've got a lot of free time, I invite you to help us
with fixing or reporting-to-qa or whatever the packages in red
listed on the ruby1.8-removal tracker [1]. Most of them are in bad
shape, and you could do a lot of good work here.

ftpmasters: libnet-netrc-ruby and libzip-ruby also appear dead
upstream.
(libzip-ruby has two new "upstreams", that by coincidence share the
same name, but have no ancestor in libzip-ruby as currently shipped in
Debian.)


[1] https://release.debian.org/transitions/html/ruby1.8-removal.html

Regards,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Bug#709922: ITP: svtplay-dl -- media downloader for play sites (e.g. SVT Play)

[Per Andersson]

>> Streaming from UR Play is not possible at all. upstream commit a7c9043301
>> fixes this. Please include at least that in a new package.
>
> This is not quite correct. Some videos lack a HD stream exposed via
> flash.  See bug report here: https://github.com/spaam/svtplay-dl/issues/61
> But nonetheless, I agree, should be part of the upload.

I did try downloading non-HD streams, i.e. without the -H option.


>> root@saturn:~# svtplay-dl http://tv.nrk.no/program/koid75007313/lysleite
>> ERROR That site is not supported. Make a ticket or send a message
>
> Works with latest upstream.

Good.


>> root@saturn:~# svtplay-dl http://www.tv4.se/snn-news/avsnitt/avsnitt-4-169107
>> ERROR Something wrong with that url
>> ERROR Error code: 404
>
> Premium content? Not sure. Can reproduce with your URL, but not with
> randomly chosen video.

I don't know either.


>> The site tv3play.lv redirects to tvplay.lv. Does not work even if
>> service URL is added
>> to supported_domains.
>>
>> root@saturn:~# svtplay-dl
>> http://www.tvplay.lv/parraides/go4speed-tv/353643?autostart=true
>> ERROR That site is not supported. Make a ticket or send a message
>
> What link for tv3play did you use? I tried one at random, and had no
> issues, and there were no redirects to tvplay.lv.

I used http://tv3play.lv/ Still get the redirects to tvplay.lv.


>> I could not find any configuration or arguments to change behaviour. If 
>> special
>> care needs to be taken for some services I think it should be
>> reflected in the docs
>> some, preferably accompanied with examples.
>
> I don't think that's the case, usually.

Ok.


>> Please check with upstream if it is possible to fix issues before an upload 
>> to
>> Debian. If the timeframe for fixes is too long, I think we should go forth 
>> and
>> upload it anyway; of course forwarding bugs upstream.
>
> I've spoken to upstream. Hopefully we can get a new release, with as
> many of these issues fixed as possible within the next few days.
> Thanks a lot for the review (and the bug reports :-)).

Neat!


--
Per


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

Bug#737820: grub-pc: postinst fails when ‘grub-mkconfig’ has non-zero exit status

[Ben Finney]

On 06-Feb-2014, Colin Watson wrote:
> On Thu, Feb 06, 2014 at 06:59:47PM +1100, Ben Finney wrote:
> > […] the process is aborted when ‘grub-mkconfig’ exits with status 1.
> > This is apparently not an error, though, and the process should not
> > fail.
> 
> Could you please expand on your chain of reasoning here?

I say “apparently not an error” because the output doesn't indicate any
kind of error, even though the exit status is non-zero:

=
$ sudo /etc/kernel/postinst.d/zz-update-grub
Generating grub.cfg ...
Found background: /usr/local/share/backgrounds/grub/winkler-gnu-blue.1024.tga

$ echo $?
1
=

> grub-mkconfig exiting non-zero is absolutely an error as far as I'm
> concerned - it might for instance mean that it was unable to generate a
> syntactically-correct configuration file - and we should find out why
> that's happening

Okay. I mistakenly assumed that an error would normally result also in an
error message, but in a ‘set -e’ shell script that won't necessarily be the
case.

> (for instance, by looking through the error output of
> "sh -x /usr/sbin/grub-mkconfig >/dev/null").

Attached is a ‘script’ session.

* ‘/usr/sbin/grub-mkconfig’ exits with status 1, because
* ‘/etc/grub.d/05_debian_theme’ exits with status 1, because
* ‘test -d "${GRUB_PREFIX}"’ exits with status 1, because
* ‘GRUB_PREFIX’ is empty.

I can't see where that variable should be getting its value from, nor why
it's empty in this case.

-- 
 \ “I went over to the neighbor's and asked to borrow a cup of |
  `\   salt. ‘What are you making?’ ‘A salt lick.’” —Steven Wright |
_o__)  |
Ben Finney 
Script started on Fri 07 Feb 2014 08:48:55 EST

$ sudo sh -x /usr/sbin/grub-mkconfig > /dev/null
+ set -e
+ transform=s,x,x,
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ prefix=/usr
+ exec_prefix=/usr
+ sbindir=/usr/sbin
+ bindir=/usr/bin
+ sysconfdir=/etc
+ PACKAGE_NAME=GRUB
+ PACKAGE_VERSION=2.00-22
+ host_os=linux-gnu
+ datadir=/usr/share
+ [ x = x ]
+ pkgdatadir=/usr/share/grub
+ grub_cfg=
+ grub_mkconfig_dir=/etc/grub.d
+ basename /usr/sbin/grub-mkconfig
+ self=grub-mkconfig
+ echo grub-probe
+ sed s,x,x,
+ grub_probe=/usr/sbin/grub-probe
+ sed s,x,x,
+ echo grub-editenv
+ grub_editenv=/usr/bin/grub-editenv
+ sed s,x,x,
+ echo grub-script-check
+ grub_script_check=/usr/bin/grub-script-check
+ export TEXTDOMAIN=grub
+ export TEXTDOMAINDIR=/usr/share/locale
+ . /usr/share/grub/grub-mkconfig_lib
+ transform=s,x,x,
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ datadir=/usr/share
+ bindir=/usr/bin
+ sbindir=/usr/sbin
+ pkgdatadir=/usr/share/grub
+ test x/usr/sbin/grub-probe = x
+ test x = x
+ sed s,x,x,
+ echo grub-mkrelpath
+ grub_mkrelpath=/usr/bin/grub-mkrelpath
+ which gettext
+ :
+ test 0 -gt 0
+ fgrep -qs ${GRUB_PREFIX}/video.lst /etc/grub.d/00_header
+ [ x = x ]
+ id -u
+ EUID=0
+ [ 0 != 0 ]
+ set /usr/sbin/grub-probe dummy
+ test -f /usr/sbin/grub-probe
+ :
+ /usr/sbin/grub-probe --target=device /
+ GRUB_DEVICE=/dev/sda1
+ /usr/sbin/grub-probe --device /dev/sda1 --target=fs_uuid
+ GRUB_DEVICE_UUID=7423af23-7742-41da-a662-0e66d631aa62
+ /usr/sbin/grub-probe --target=device /boot
+ GRUB_DEVICE_BOOT=/dev/sda1
+ /usr/sbin/grub-probe --device /dev/sda1 --target=fs_uuid
+ GRUB_DEVICE_BOOT_UUID=7423af23-7742-41da-a662-0e66d631aa62
+ /usr/sbin/grub-probe --device /dev/sda1 --target=fs
+ GRUB_FS=ext2
+ test -f /etc/default/grub
+ . /etc/default/grub
+ GRUB_DEFAULT=0
+ GRUB_TIMEOUT=5
+ lsb_release -i -s
+ GRUB_DISTRIBUTOR=Debian
+ GRUB_CMDLINE_LINUX_DEFAULT=quiet
+ GRUB_CMDLINE_LINUX=
+ GRUB_FONT=/boot/grub/dejavu-sans-mono.16.pf2
+ GRUB_GFXMODE=640x480x16;1280x1024x32;1024x768x32;800x600x16;640x480
+ GRUB_GFXPAYLOAD_LINUX=keep
+ GRUB_BACKGROUND=/usr/local/share/backgrounds/grub/winkler-gnu-blue.1024.tga
+ [ -e /etc/default/grub.d/*.cfg ]
+ [ x != x ]
+ termoutdefault=0
+ [ x = x ]
+ GRUB_TERMINAL_OUTPUT=gfxterm
+ termoutdefault=1
+ GRUB_ACTUAL_DEFAULT=0
+ [ x0 = xsaved ]
+ [ x = x ]
+ GRUB_RECOVERY_TITLE=recovery mode
+ export GRUB_DEVICE GRUB_DEVICE_UUID GRUB_DEVICE_BOOT GRUB_DEVICE_BOOT_UUID 
GRUB_FS GRUB_FONT GRUB_PRELOAD_MODULES GRUB_ACTUAL_DEFAULT
+ export GRUB_DEFAULT GRUB_HIDDEN_TIMEOUT GRUB_HIDDEN_TIMEOUT_QUIET 
GRUB_TIMEOUT GRUB_TIMEOUT_STYLE GRUB_DEFAULT_BUTTON GRUB_HIDDEN_TIMEOUT_BUTTON 
GRUB_TIMEOUT_BUTTON GRUB_TIMEOUT_STYLE_BUTTON GRUB_BUTTON_CMOS_ADDRESS 
GRUB_BUTTON_CMOS_CLEAN GRUB_DISTRIBUTOR GRUB_CMDLINE_LINUX 
GRUB_CMDLINE_LINUX_DEFAULT GRUB_CMDLINE_XEN GRUB_CMDLINE_XEN_DEFAULT 
GRUB_CMDLINE_LINUX_XEN_REPLACE GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT 
GRUB_CMDLINE_NETBSD GRUB_CMDLINE_NETBSD_DEFAULT GRUB_CMDLINE_GNUMACH 
GRUB_TERMINAL_INPUT GRUB_TERMINAL_OUTPUT GRUB_SERIAL_COMMAND 
GRUB_DISABLE_LINUX_UUID GRUB_DISABLE_RECOVERY GRUB_VIDEO_BACKEND GRUB_GFXMODE 
GRUB_BACKGROUND GRUB_THEME GRUB_GFXPAYLOAD_LINUX GRUB_DISABLE_OS_PROBER 
GRUB_INIT_TUNE GRUB_SAVEDEFAULT GRUB_ENABLE_CRYPTODISK GRUB_BADRAM 
GRUB_RECORDFAI

Bug#737910: gltron: please provide a desktop file and icons

[Markus Koschany]

Package: gltron
Version: 0.70final-12
Severity: wishlist
User: pkg-games-de...@lists.alioth.debian.org
Usertags: desktop-integration goals not-gamesteam

Dear maintainer,

currently gltron does not supply a desktop file and no desktop
icons. Hence the game is not well integrated into the user's desktop
environment. Please consider helping to improve the desktop integration
of games in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#737608: closed by Sergey B Kirpichev (reply to skirpic...@gmail.com) (Re: Bug#737608: monit: my root shell isn't a browser, I'm sure of that‽)

[Sergey B Kirpichev]

On Thu, Feb 06, 2014 at 10:34:46PM +0100, Dominik George wrote:
> That's a bad excuse for dumping error messages intended for browsers to
> the shell, isn't it :)?

The current message intended for any user agent, including
monit itself.  Actually, you can't distinguish them, User-Agent
string can be easily spoofed.

Do you suggest another wording of this error message?
For some user-agents?  What exactly?


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

Bug#727708: Call for votes on init system resolution

[Adrian Bunk]

On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:
> On 7 February 2014 06:20, Ian Jackson  wrote:
> > Don Armstrong writes ("Bug#727708: Call for votes on init system 
> > resolution"):
> >> Given the already stated preferences of the CTTE, and the previous votes
> >> we've already had, openrc and sysvinit are clearly not going to defeat
> >> any option, so their position in your vote is largely irrelevant.
> > If we held the votes separately in the other order, T-vs-L first, and
> > T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
> > first, l don't know whether to rank systemd above GR.
> 
> Based on your initial vote on your own ballot and the above, your
> votes would be:
> 
>   1.  LFT
>   2a. (L wins): UDF
>   2b. (T wins): FUD (*cough*)
> 
> or:
> 
>   1. UD  ("where do I put F?")
>   2. LFT
> 
> Presuming everyone votes, where you put F only has an impact in either
> case only if at least three other ctte members will also vote FD above
> T or DT (given UT is irrelevant); which based on the already expressed
> preferences and votes, isn't actually going to happen.

Why not?

I am not sure whether Colin is aware that it currently depends on him 
whether or not DT can win - and whether that might make him consider 
changing his vote.

If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
his ballot, then DT cannot pass FD and is dead.

> Cheers,
> aj

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#737876: flare: menu icon entry missing

[Markus Koschany]

On 06.02.2014 22:44, Manuel A. Fernandez Montecelo wrote:
[...]
> According to recent conversations in mailing lists, I got the
> impression that the Debian menu is going to be killed (and if it's
> not, I think that it will be due to lack of enthusiasm to make the
> necessary changes in the policy).
> 
> Either way, since the fix is easy, we can incorporate it, no problem.
> 

Indeed the discussion is here:

http://bugs.debian.org/707851

The original intention of the bug submitter was to "soften the
wordening" about menu files. The current policy still recommends that
every package should have a menu file. As I have pointed out in that bug
report, I support the submitter's point of view that the freedesktop
standard has superseded Debian's menu system but I think lowering the
menu system to "suggest" would be fine since it still provides value to
lightweight and custom desktop environments.

However we are closer than ever to support both menu systems equally
good in all game packages. Most (meaning more than 90%) games packages
ship already both, a desktop and menu file. I'm convinced that the menu
package and the menu system will not go away for Jessie, meaning at
least three years of additional support. I think that's already worth
the (little) trouble.

Thanks for considering it!

Cheers,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#737850: crawl: menu icon entries missing

[Adam Borowski]

On Thu, Feb 06, 2014 at 10:49:19PM +0100, Guus Sliepen wrote:
> On Thu, Feb 06, 2014 at 10:38:47PM +0100, Adam Borowski wrote:
> 
> > Current state:
> > crawl(text) crawl-tiles(SDL)
> > menuYY
> > menu icon   --
> > XDG -Y
> > XDG icon-Y
> > 
> > However, I wonder about the inconsistency between menu and XDG: the text
> > version ships a menu entry but no XDG.  I think we should either drop the
> > menu from the non-graphical version (the user can start it from her
> > favourite terminal), or add XDG for it as well.  Any advice which would
> > be better?
> 
> Since it is a roguelike, it is not unlikely that someone would like to play it
> with real ASCII art instead of tiles. So I think it is best to have menu and
> XDG and icons for both text and tiles versions.

Yes, but people using a terminal are likely to have one already open, rather
than using mouse to start a mouse-less text game.

I looked at our most direct competition: just like us, NetHack currently
provides a menu entry for both console and tiles, and an XDG only for tiles.

-- 
A tit a day keeps the vet away.


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

Bug#737909: stevedore: Please package version 0.14.1

[Etienne Millon]

Source: stevedore
Severity: wishlist

Hi,

I'm packaging the guessit library (ITP - #729870), which uses the
newer features of stevedore (namely the "on_load_failure_callback"
parameter to ExtensionManager.__init__).

Can you consider packaging the newest version?

Thanks!

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

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Etienne Millon


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

Bug#737850: crawl: menu icon entries missing

[Guus Sliepen]

On Thu, Feb 06, 2014 at 10:38:47PM +0100, Adam Borowski wrote:

> Current state:
> crawl(text) crawl-tiles(SDL)
> menuYY
> menu icon   --
> XDG -Y
> XDG icon-Y
> 
> What you report here is the lack of .xpm, that's a trivial fix (there's a
> .png nearby already).
> 
> However, I wonder about the inconsistency between menu and XDG: the text
> version ships a menu entry but no XDG.  I think we should either drop the
> menu from the non-graphical version (the user can start it from her
> favourite terminal), or add XDG for it as well.  Any advice which would
> be better?

Since it is a roguelike, it is not unlikely that someone would like to play it
with real ASCII art instead of tiles. So I think it is best to have menu and
XDG and icons for both text and tiles versions.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#737850: crawl: menu icon entries missing

[Adam Borowski]

On Thu, Feb 06, 2014 at 02:35:08PM +0100, Markus Koschany wrote:
> currently crawl does not supply a menu icon hence the
> game is not well integrated into the user's desktop environment.
> Please consider adding an icon entry to your menu file.

Current state:
crawl(text) crawl-tiles(SDL)
menuYY
menu icon   --
XDG -Y
XDG icon-Y

What you report here is the lack of .xpm, that's a trivial fix (there's a
.png nearby already).

However, I wonder about the inconsistency between menu and XDG: the text
version ships a menu entry but no XDG.  I think we should either drop the
menu from the non-graphical version (the user can start it from her
favourite terminal), or add XDG for it as well.  Any advice which would
be better?

-- 
A tit a day keeps the vet away.


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