Bug#741031: I can confirm this bug, too

2014-05-05 Thread Aurelien Jarno
On Mon, May 05, 2014 at 10:13:51AM +0200, Robert Waldner wrote:
> 
> Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got 
>  libc6-amd64:i386 into a state where it seems impossible to continue.
>  Removing libc6-amd64:i386 fails because the package is "in a bad 
>  state", reinstalling doesn't work, either, nor das apt-get -f install:
> 
> At first failure, I tried with the steps outlined in #736097, and (like 
>  Francesco) hosed my system - luckily I had sash installed and could 
>  revocer via that.
> 
> Now it seems I'm stuck in a loop:
> 
>  # apt-get -f install
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Correcting dependencies... Done
> The following extra packages will be installed:
>   libc-bin libc6 libc6-amd64:i386
> Suggested packages:
>   glibc-doc
> The following packages will be upgraded:
>   libc-bin libc6 libc6-amd64:i386
> 3 upgraded, 0 newly installed, 0 to remove and 1235 not upgraded.
> 12 not fully installed or removed.
> Need to get 0 B/8,518 kB of archives.
> After this operation, 115 kB disk space will be freed.
> Do you want to continue? [Y/n] 
> Preconfiguring packages ...
> (Reading database ... 294301 files and directories currently installed.)
> Preparing to unpack .../libc6-amd64_2.18-5_i386.deb ...
> Unpacking libc6-amd64 (2.18-5) over (2.17-97) ...
> Replaced by files in installed package libc6:amd64 (2.17-97) ...
> dpkg: warning: subprocess old post-removal script was killed by signal 
> (Segmentation fault)
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb (--unpack):
>  subprocess new post-removal script was killed by signal (Segmentation fault)
> dpkg: error while cleaning up:
>  subprocess installed pre-installation script was killed by signal 
> (Segmentation fault)
> Preparing to unpack .../libc6_2.18-5_amd64.deb ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Warning: found a potentially broken dynamic loader symlink,
> disabling ldconfig to avoid a possible system breakage. It
> will be reenabled when a new version of libc-bin is unpacked.
> Unpacking libc6:amd64 (2.18-5) over (2.17-97) ...
> dpkg: warning: subprocess old post-removal script was killed by signal 
> (Segmentation fault)
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive /var/cache/apt/archives/libc6_2.18-5_amd64.deb 
> (--unpack):
>  subprocess new post-removal script was killed by signal (Segmentation fault)
> dpkg: error while cleaning up:
>  subprocess installed pre-installation script was killed by signal 
> (Segmentation fault)
> Errors were encountered while processing:
>  /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb
>  /var/cache/apt/archives/libc6_2.18-5_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> :( root@fsck->/usr/local/src/games # apt-get remove libc6-amd64:i386
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these:
> The following packages have unmet dependencies:
>  libc-bin : Depends: libc6 (< 2.18) but 2.18-5 is to be installed
> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
> a solution).
> :( root@fsck->/usr/local/src/games # apt-get --reinstall install libc6-amd64- 
> libc6 libc-bin
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Suggested packages:
>   glibc-doc
> The following packages will be REMOVED:
>   libc6-amd64:i386
> The following packages will be upgraded:
>   libc-bin libc6
> 2 upgraded, 0 newly installed, 1 to remove and 1235 not upgraded.
> 12 not fully installed or removed.
> Need to get 0 B/5,927 kB of archives.
> After this operation, 11.0 MB disk space will be freed.
> Do you want to continue? [Y/n] 
> Preconfiguring packages ...
> dpkg: error processing package libc6-amd64 (--remove):
>  package is in a very bad inconsistent state; you should
>  reinstall it before attempting a removal
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> :( root@fsck->/usr/local/src/games # dpkg -r libc6-amd64 
> dpkg: error processing package libc6-amd64 (--remove):
>  package is in a very bad inconsistent state; you should
>  reinstall it before attempting a removal
> Errors were encountered while processing:
>  libc6-amd64
> :( root@fsck->/usr/local/src/games # apt-get --reinstall install 
> libc6-amd64:i386
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these:
> The following packages have unmet dependencies:
>  libc-bin : Depends: libc6 (< 2.18) but 2.18-5 is to be installed
> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
> a solution).
> :( root@fs

Bug#747165: update compass to depend on a compatible version of sass

2014-05-05 Thread Pirate Praveen
package: ruby-compass
version: 0.12.3~dfsg-2
severity: important

I get the following error when I bundle install --local for diaspora
(I'm preparing its package),

Could not find gem 'sass (= 3.2.14) ruby', which is required by gem
'compass-rails (>= 1.0.3) ruby', in any of the sources.

compass-0.12.3.gemspec has this line,

s.add_runtime_dependency(%q, ["= 3.2.14"])

but debian already has a newer version of sass in the archive

pravi@savannah:~/forge/debian/git/pkg-ruby-extras/diaspora$ gem list sass

*** LOCAL GEMS ***

sass (3.2.19)
sass-rails (3.2.5)

0.12.6 version of compass lists *sass* ~> 3.2.19
as dependency. Updating ruby-compass to
this version will fix this issue.


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



Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

2014-05-05 Thread Michael Stapelberg
Hi Zack,

Zack Weinberg  writes:
> Note that coinstallability is not enough -- the bulletproof procedure
> (e.g. "update-init-system") must also be implemented, shipped, and
> documented.
Your tone is way out of line. Who are you to tell us what we _must_ do?
That’s not how it works.

Either you do the work and convince us we should merge it or you make
suggestions. But you cannot tell us what we must do in our spare time.

-- 
Best regards,
Michael


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



Bug#741340: python3-chardet: Depends on Python 3.4

2014-05-05 Thread Mohammed Stern
I also confirm that the dependency is indeed explicit on python3.4 and not
only on python3, as simply checked.


> I don't understand what's the problem (python3-chardet requires python3
>  >= 3.1.2-8~, python3 is currently python3.3, BTW).
>

The problem is that python3-chardet DOES indeed depend on python3.4 .

Have a look to:

https://packages.debian.org/sid/python3-chardet

or type the following command:

aptitude show python3-chardet/unstable


Bug#741031: I can confirm this bug, too

2014-05-05 Thread Robert Waldner

On Mon, 05 May 2014 10:13:51 +0200, Robert Waldner writes:
>Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got 
> libc6-amd64:i386 into a state where it seems impossible to continue.
> Removing libc6-amd64:i386 fails because the package is "in a bad 
> state", reinstalling doesn't work, either, nor das apt-get -f install:
>
>At first failure, I tried with the steps outlined in #736097, and (like 
> Francesco) hosed my system - luckily I had sash installed and could 
> revocer via that.
>
>Now it seems I'm stuck in a loop:

FWIW, after some experimentation in a chrooted copy of the system I was 
 able to revover, here's a snippet of my shell history:

  588  LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ apt-get -f install

Didn't help. every new process would just segfault, until (ldconfig 
 had been symlinked to /bin/true before):
  589  /sbin/ldconfig.real 

Seems the apt-get -f install with LD_LIBRARY_PATH set got me far enough 
 so that now it was possible to continue w/o errors:
  590  apt-get -f install
  591  apt-get -s remove libc6-amd64
  592  apt-get -s --purge remove libc6-amd64
  593  apt-get --purge remove libc6-amd64

Now I'm in a state without broken/half-installed libc6* packages, finally
 could get rid of libc6-amd64, and can continue with upgrading:

:) waldner@fsck->~ $ COLUMNS=72 dpkg -l | grep libc6 | egrep ^i
ii  libc6:amd642.18-5   amd64Embedded GNU C Library: Shared li
ii  libc6:i386 2.18-5   i386 Embedded GNU C Library: Shared li
ii  libc6-dbg:amd6 2.18-5   amd64Embedded GNU C Library: detached 
ii  libc6-dev:amd6 2.18-5   amd64Embedded GNU C Library: Developme
ii  libc6-dev:i386 2.18-5   i386 Embedded GNU C Library: Developme
ii  libc6-dev-i386 2.18-5   amd64Embedded GNU C Library: 32-bit de
ii  libc6-dev-x32  2.18-5   amd64Embedded GNU C Library: X32 ABI D
ii  libc6-i386 2.18-5   amd64Embedded GNU C Library: 32-bit sh
ii  libc6-x32  2.18-5   amd64Embedded GNU C Library: X32 ABI S

Kind regards,
robert
-- 
-- Too much is just enough.
-- Mark Twain (on whiskey)




signature.asc
Description: Digital Signature


Bug#747099: Please update dependency to libxine2-x

2014-05-05 Thread Alexandre Rossi
Hi,

> please depend on libxine2-x instead of libxine1-x.

I've just uploaded a fixed package with minimal changes on mentors.d.n
for libxine1 removal to proceed.

FYI, upstream (which I'm part of) has dropped the xine dependency. The
packaging of the newer version should be ready in a few days but there
are a lot of changes that you might not want to review, thus the
upload of a minor version.

Thanks,

Alex


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



Bug#732796: ProposalL /usr/bin/open as an alternative for xdg-open and run-mailcap.

2014-05-05 Thread Charles Plessy
Le Tue, Apr 29, 2014 at 05:05:59PM +0900, Charles Plessy a écrit :
> Hello kbd maintainers, xdg-utils maintainers and everybody,
> 
> The “kbd” package ships a symbolic link from /bin/open to /bin/openvt.

Hi again,

so far there has been only one answer to my question on debian-devel about
recycling the “open” command.

“Please don't, or if you insist, get kbd to stop shipping it, wait for at
 least two releases and then introduce it with a new name.”

Would you agree to remove /bin/open and let others introduce an unrelated
program as /usr/bin/open in Jessie+1 ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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



Bug#737803: chocolate-doom: FTBFS: race during parallel installation

2014-05-05 Thread Andreas Beckmann
On 2014-05-05 10:44, Fabian Greffrath wrote:
> Dear Andreas,
> 
> this bug is fixed in GIT since the day you reported it. However,
> unfortunately my regular sponsor is short of time and has somwhow thrown
> the towel for package uploads in the short term. Since I don't want to
> keep this (otherwise perfectly fine) package from testing any longer and
> since you reported that bug, would you mind sponsoring the upload?
> 
> The package can be found here, it builds with git-buildpackage:
> http://anonscm.debian.org/gitweb/?p=pkg-games/chocolate-doom.git

the pristine-tar branch contains info about a 2.0.0 .tar.gz, but the
previous upload was done with a .tar.xz, please fix the pristine-tar
branch: checkout pristine-tar & delete the incorrect files, thereafter
import the .tar.xz found on ftp.d.o

standards-version could be bumped (check upgrade checklist!)

lintian reports a few issues that could be worked on ...

Anyway, these are minor nitpicks, so I would have uploaded it, but
Vincent beat me by a few minutes :-)


Andreas


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



Bug#747164: spidermonkey-bin: please, bring back spidermonkey-bin for newer iceweasel versions

2014-05-05 Thread Rogério Brito
Package: spidermonkey-bin
Severity: wishlist

Dear Mike,

I saw that you stopped creating packages with the spidermonkey interpreter
at the 28.0 release of iceweasel.

Would it be possible to bring back these packages? I know that many people
may not care, but this package was really handy and it is a pity to have it
missing from Debian. :(


Thank you very much for your efforts,

Rogério Brito.

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

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

Versions of packages spidermonkey-bin depends on:
ii  libc6 2.18-5
ii  libffi6   3.1~rc1+r3.0.13-12
ii  libnspr4  2:4.10.4-1
ii  libreadline6  6.3-6
ii  libstdc++64.9.0-2
ii  zlib1g1:1.2.8.dfsg-1

spidermonkey-bin recommends no packages.

spidermonkey-bin suggests no packages.

-- no debconf information

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


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



Bug#737803: chocolate-doom: FTBFS: race during parallel installation

2014-05-05 Thread Vincent Cheng
On Mon, May 5, 2014 at 1:44 AM, Fabian Greffrath  wrote:
> Dear Andreas,
>
> this bug is fixed in GIT since the day you reported it. However,
> unfortunately my regular sponsor is short of time and has somwhow thrown
> the towel for package uploads in the short term. Since I don't want to
> keep this (otherwise perfectly fine) package from testing any longer and
> since you reported that bug, would you mind sponsoring the upload?
>
> The package can be found here, it builds with git-buildpackage:
> http://anonscm.debian.org/gitweb/?p=pkg-games/chocolate-doom.git

Built, signed, and uploaded. Don't forget that the Debian Games team
has a sponsorship queue [1] that you can use if you're looking for a
sponsor within the team; I aim to regularly check the queue for
packages to sponsor.

Regards,
Vincent

[1] https://wiki.debian.org/Games/Sponsors/Queue


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



Bug#747132: libreoffice: The metapackage libreoffice should not recommend liberation fonts

2014-05-05 Thread Rene Engelhard
severity 747132 wishlist
found 747132 1:4.1.5-2
thanks

On Mon, May 05, 2014 at 03:21:37PM -0500, Karl O. Pinc wrote:
> The libreoffice metapackage (in wheezy and experimental)
> recommends the liberation fonts.  These fonts should
> instead be recommended by the individual libreoffice
> components.  The components need them, even when
> installed individually.

If you have stuff using Arial, yes. So you suggest every component
doing anything with fonts (so everything except Base recommend it)?

Will think about it: if we did it it probably should be -core recommending
it (as it does all the font stuff.)

> Installing just the components and not the metapackage
> (and, I presume, not the ttf-liberation fonts or whatever

Yes, but doing that should be done by people who know what they do.

> the package is in experimental) leads to the following
> situation:
> 
> Opening a .doc document made in MS Word displays
> fine on the screen, but exporting to PDF or
> printing results in display of only the bolded or italic
> or otherwise changed fonts.  (I didn't
> investigate in detail exactly what it was
> that displayed.)  The "regular" text of the
> document disappears.

Depends on the font probably and if that font is "substituted"
by liberation or not.

> This is fixed by installing the libreoffice
> metapackage, I presume because the liberation
> fonts are then installed.

The original idea why this is in the metapackage is that the metapackage is 
supposed
to install everything LO ships in their upstream distribution if possible. That 
also
includes fonts. (So liberation, Devaju, Gentium..) I didn't update that list 
for longer,
though...

Regards,

Rene


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



Bug#747115: [Pkg-shadow-devel] Bug#747115: /etc/pam.d/login: typos

2014-05-05 Thread Christian PERRIER
Quoting Jakub Wilk (jw...@debian.org):
> Package: login
> Version: 1:4.2-2
> Severity: minor
> Tags: patch
> 
> Typos:
> succesful -> successful
> restrainst -> restraint

I imagine you reading each and every changed file in new packages and
finding out typos..;-)

Thanks for reporting, it's fixed in git.



signature.asc
Description: Digital signature


Bug#747115: Pending fixes for bugs in the shadow package

2014-05-05 Thread pkg-shadow-devel
tag 747115 + pending
thanks

Some bugs in the shadow package are closed in revision
4a2fadfa215ae12a7d455866950afd96bb1710ad in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=4a2fadf

Commit message:

Fix typos in login.pam (thanks to Jakub Wilk for reporting) Closes: #747115


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



Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

2014-05-05 Thread Martin Pitt
Zack Weinberg [2014-05-05 20:29 -0400]:
> I contend that, therefore, "systemd-sysv", "sysvinit-core", *and*
> "systemd-shim" (and "upstart" as well) (quotation marks indicate package
> names) should *all* be coinstallable; an upgrade from wheezy should
> install *both* "systemd-sysv" and "systemd-shim" if not already present,
> and leave "sysvinit-core" installed; and a mechanism independent of
> package management should control which init brings up the system on the
> next boot.

Isn't the "sysvinit" package now meant to provide this "selector"? I
don't know if it's debconfified or similar, but having such a selector
package was the reason for moving the old sysvinit to s-core, wasn't
it?

> I did a bit more digging into how it works right now in response to
> Tolleef's message.  First, "systemd-shim" currently doesn't conflict
> with "systemd-sysv" or "systemd", or vice versa.  I don't know how
> "systemd-shim" works.  Does it properly get out of the way if the
> running PID 1 is in fact systemd?

Yes, it does, that's how it was designed. It provides a D-BUS
activatable, and heavily reduced, interface for things like suspend or
setting the time zone. But if you run the "real" systemd, those D-BUS
objects already exists, and thus the D-BUS .service file is entirely
ignored.

> Second, it might simplify matters to split the programs 'telinit',
> 'halt', 'poweroff', 'reboot', 'runlevel', and 'shutdown', and their
> manpages, to a separate package shared among all supported init
> implementations.

Would that actually work? I thought that the implementation of these
depended on the current init system in use? At least when I tried to
move from upstart to sysvinit on a fresh vserver that I got recently,
all these (reboot, etc.) were broken.

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


signature.asc
Description: Digital signature


Bug#608248: slapd lenny->squeeze upgrade failure: still affected?

2014-05-05 Thread Martin Šín
Hi, 
once I will have some time, I guess to solve it again. I
have repeatedly (about a year ago) tried to update, but without
any success. What I remember, (and maybe I'm wrong) as problematic place
proved directory /etc/ldap/schema/, which is either deleted during
the update or ignoring the contents of the file samba.schema and it lead
into error during upgrade - not to recognize certain entries contained
in LDAP directory.

Sorry for English, I am using translator and a little bit my
improvements.. :-)

Many thanks and best regards,
Martin Sin.

V Mon, 05 May 2014 21:08:27 -0700
Ryan Tandy  napsáno:

> tags 608248 + moreinfo
> thanks
> 
> Hi Martin,
> 
> Thanks for reporting this bug, several years ago. I'm sorry it hasn't
> had an answer until now.
> 
> From the message "Error, entries missing!" in your original report, it
> seems to me that your database was probably already corrupted somehow
> when you did the upgrade.
> 
> Do you still experience this bug in more recent releases, or can you
> provide more information about the configuration that led to it?
> 
> thanks,
> Ryan


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



Bug#745356: [Pkg-openldap-devel] Bug#745356: Depend on heimdal-multidev rather than heimdal-dev

2014-05-05 Thread Ryan Tandy
tags 745356 + pending
thanks

On 05/05/14 07:31 PM, Jelmer Vernooij wrote:
> It seems like one way to work around this should be to change the
> order of the libraries in the smb5pwd Makefile, i.e. this line:
> 
> LIBS = $(LDAP_LIB) $(HEIMDAL_LIB) $(SSL_LIB)
> 
> to
> 
> LIBS = $(HEIMDAL_LIB) $(LDAP_LIB) $(SSL_LIB)

Right, of course. For some reason I thought the offending LIBS were
coming from somewhere else, but you're right and that does fix it.

Steve already committed your original patch, and I've now amended it
with that change and a comment. Thanks!



signature.asc
Description: OpenPGP digital signature


Bug#712763: /lib/lsb/init--functions.d/70-upstart

2014-05-05 Thread Cameron Norman
El Mon, 5 de May 2014 a las 9:52 PM, Steve Langasek  
escribió:

On Mon, May 05, 2014 at 03:49:38AM -0007, Cameron Norman wrote:


 2) More than just init scripts source lsb init functions. Most
 notably: many of the ifupdown scripts. Using basename would give you
 problems because /etc/network/ifup.d/openvpn is different from
 /etc/init.d/openvpn, but I think the change to ${0#/etc/init.d/}
 will cover this. If $0 is the ifup thing, it will remain the full
 path, and initctl status will fail.


What version of openvpn is this in?  The version in unstable certainly
doesn't source /lib/lsb/init-functions from its ifupdown hook.  If it 
did,

I'm not sure we should regard that as anything but a bug anyway.



Sorry, I just used the openvpn one as an example of a file in if-up.d 
that matched a init script. One that matches and sources 
/lib/lsb/init-functions is mountnfs.


Cheers,
--
Cameron


Bug#747163: apt-offline: does not work by default due to ignoring /etc/apt/trusted.gpg.d/*.gpg

2014-05-05 Thread Paul Wise
Package: apt-offline
Version: 1.3.1
Severity: important
Control: found -1 1.2

This issue is present in both Debian wheezy and Debian jessie. I think
that this issue needs to be fixed in both Debian wheezy and jessie.

By default apt-offline does not work because debian-archive-keyring
installs the files listed below and apt-offline ignores them and only
uses /etc/apt/trusted.gpg. The code has an option to allow using a
different keyring but it only allows one keyring and the option isn't
possible to enable from command-line parameters.

/etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apt-offline depends on:
ii  apt1.0.1
ii  less   458-2
ii  libpython2.7-stdlib [python-argparse]  2.7.6-8
ii  python 2.7.5-5

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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


Bug#623688: cannot reproduce pcache configuration failure

2014-05-05 Thread Ryan Tandy
tags 623688 + moreinfo
thanks

Hi Markus,

Thanks for reporting this bug. I tried to reproduce it with slapd 2.4.28
and 2.4.31, but with no success. I used the pcache database
configuration you provided when you reported the bug, but no other
databases or overlays.

If you still experience this bug with slapd from wheezy or jessie, can
you provide a complete configuration that reproduces it?

thanks,
Ryan


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



Bug#746086: tiemu: diff for NMU version 3.03-nogdb+dfsg-2.1

2014-05-05 Thread dai
tags 746086 + patch
tags 746086 + pending
thanks

Dear maintainer,

I've prepared an NMU for tiemu (versioned as 3.03-nogdb+dfsg-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
diff -Nru tiemu-3.03-nogdb+dfsg/debian/changelog tiemu-3.03-nogdb+dfsg/debian/changelog
--- tiemu-3.03-nogdb+dfsg/debian/changelog	2013-08-28 02:38:29.0 +0900
+++ tiemu-3.03-nogdb+dfsg/debian/changelog	2014-05-06 13:48:49.0 +0900
@@ -1,3 +1,11 @@
+tiemu (3.03-nogdb+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix FTBFS on amd64 (Closes: #746086).
+- debian/control: add libarchive-dev to B-D.
+
+ -- HIGUCHI Daisuke (VDR dai)   Tue, 06 May 2014 13:44:06 +0900
+
 tiemu (3.03-nogdb+dfsg-2) unstable; urgency=low
 
   * Fix debian/watch.  Cleanup.
diff -Nru tiemu-3.03-nogdb+dfsg/debian/control tiemu-3.03-nogdb+dfsg/debian/control
--- tiemu-3.03-nogdb+dfsg/debian/control	2013-08-28 02:38:29.0 +0900
+++ tiemu-3.03-nogdb+dfsg/debian/control	2014-05-06 13:48:41.0 +0900
@@ -15,6 +15,7 @@
libticalcs-dev (>= 1.1.8),
libticonv-dev (>= 1.1.4),
libtifiles-dev (>= 1.1.6),
+   libarchive-dev,
texinfo,
zlib1g-dev
 Standards-Version: 3.9.4


signature.asc
Description: Digital signature


Bug#712763: /lib/lsb/init--functions.d/70-upstart

2014-05-05 Thread Steve Langasek
On Mon, May 05, 2014 at 03:49:38AM -0007, Cameron Norman wrote:
> El Fri, 2 de May 2014 a las 8:12 PM, Dimitri John Ledkov
>  escribió:
> >On 3 May 2014 03:55, Cameron Norman  wrote:
> >> El Fri, 2 de May 2014 a las 7:46 PM, Dimitri John Ledkov
> >>
> >> escribió:

> >> Would you like any help, or do you got it?

> >Save attached file as /lib/lsb/init-functions.d/01-upstart-lsb . This
> >is what i'm currently planning to do, this should mimic how service
> >command operates on upstart jobs at the moment.

> I hit two issues with this.

> 1) It uses basename, which is in /usr/bin. A number of scripts are
> not booted after remote_fs, so they must set their path to not
> include anything from /usr and the call to basename fails even when
> /usr is mounted. I used ${0#/etc/init.d/} instead (note the trailing
> "/", I always forget).

Yep, that makes sense.

> 2) More than just init scripts source lsb init functions. Most
> notably: many of the ifupdown scripts. Using basename would give you
> problems because /etc/network/ifup.d/openvpn is different from
> /etc/init.d/openvpn, but I think the change to ${0#/etc/init.d/}
> will cover this. If $0 is the ifup thing, it will remain the full
> path, and initctl status will fail.

What version of openvpn is this in?  The version in unstable certainly
doesn't source /lib/lsb/init-functions from its ifupdown hook.  If it did,
I'm not sure we should regard that as anything but a bug anyway.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#622960: O: freemind -- Java Program for creating and viewing

2014-05-05 Thread Willem van den Akker
Hi,

No time to maintain this in a short time. So if anyone wants to pick it
op. Go ahead.
If not then I will reconsider if I have more time for maintaining it.

Greetings,
Willem

On Thu, 2014-03-27 at 22:43 +0100, Markus Koschany wrote:

> Hello Willem,
> 
> do you still intend to adopt Freemind? I'm asking because I haven't seen
> any progress on this bug report yet.
> 
> If you are not interested anymore, I suggest to revert the status back
> to RFA. What do you think?
> 
> Regards,
> 
> Markus
> 




Bug#747162: /usr/bin/vdr-sxfe: vdr-sxfe hanging and freezing

2014-05-05 Thread Stefan Zechner
Package: xineliboutput-sxfe
Version: 1.1.0-1
Severity: important
File: /usr/bin/vdr-sxfe

Dear Maintainer,

I recently updated from wheezy to latest jessie.
But watching TV on my local VDR machine is not running smoothly since the 
update.

When switching the channels it takes much longer (5 to 10 seconds) than before.
After switching 10 times it regularly even freezes and I have to kill and 
restart vdr-sxfe.

I receive a lot of h264 error ("decode_slice_header error" ...). Don't remember 
if I had this before but as long as vdr is tuning the channel and I am waiting 
for the image a lot of these errors are printed.

Sometimes when starting vdr-sxfe I receive warnings like: "xine-engine setting 
"engine.buffers.video_num_frames":15 is too small for some HD channels".
I stopped vdr, updated the parameters in .xine/config_xineliboutput, but next 
time the file is overwritten with the same default values.
I removed write permission on the file and increased the buffers. So now the 
file is untouched but I still get the warning the second time I start vdr-sxfe.
This is all mysterious to me. Where are xine parameters set and overwritten. 
And does it relate to my instbility issue?

Any ideas?

Best regarads,
Stefan


[~] vdr-sxfe 
vdr-sxfe 1.1.0  (build with xine-lib 1.2.3, using xine-lib 1.2.5)


VDR server not given, searching ...
[31182] [discovery] Replacing broadcast source address 192.168.178.22 with 
server-given address 127.0.0.1
Found VDR server: host 127.0.0.1, port 37890
[31182] [scrnsaver] Error: The name org.gnome.SessionManager was not provided 
by any .service files
[31182] [scrnsaver] Error: The name org.gnome.ScreenSaver was not provided by 
any .service files
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object 
file: No such file or directory
vo_vdpau: Can't create vdp device : No vdpau implementation.
[31182] [vdr-fe]Detected 4 CPUs
[31182] [vdr-fe]Enabling FFmpeg multithreaded video decoding
[31182] [input_vdr] Connecting (control) to tcp://127.0.0.1:37890 ...
[31182] [input_vdr] Server greeting: VDR-2.0.2 xineliboutput-1.1.0 READY
[31182] [input_vdr] Connected (control) to tcp://127.0.0.1:37890
[31182] [input_vdr] Connecting (data) to 
pipe:///var/lib/vdr/plugins/xineliboutput/pipes.24100/pipe.0
[31182] [input_vdr] Data stream connected (PIPE)


Press Esc to exit

xv_set_property: property=8, value=100
xv_set_property: property=2, value=0
xv_set_property: property=3, value=0
xv_set_property: property=5, value=0
xv_set_property: property=24, value=0
xv_set_property: property=25, value=0
xv_set_property: property=4, value=0
xv_set_property: property=1, value=0
[31194] [input_vdr] WARNING: xine-engine setting 
"engine.buffers.video_num_frames":15 is too small for some HD channels
xv_set_property: property=0, value=0
[h264 @ 0x7fcb3008f660] non-existing PPS 0 referenced
[h264 @ 0x7fcb3008f660] decode_slice_header error
[h264 @ 0x7fcb3008f660] no frame!
[h264 @ 0x7fcb3008f660] non-existing PPS 0 referenced
[h264 @ 0x7fcb3008f660] decode_slice_header error
[h264 @ 0x7fcb3008fdc0] no frame!
xv_set_property: property=0, value=0
[h264 @ 0x7fcb3008f660] non-existing PPS 0 referenced
[h264 @ 0x7fcb3008f660] decode_slice_header error   


  
[h264 @ 0x7fcb30143e00] no frame!   


  
[h264 @ 0x7fcb3008f660] non-existing PPS 0 referenced   


  
[h264 @ 0x7fcb3008f660] decode_slice_header error   


  
[h264 @ 0x7fcb3008f660] no frame!   


  
[h264 @ 0x7fcb3008f660] non-existing PPS 0 referenced   


  
[h264 @ 0x7fcb3008f660] decode_slice_header error   

Bug#747161: fityk: new upstream version 1.2.9

2014-05-05 Thread Andres Cimmarusti
Package: fityk
Version: 1.2.1-0.1
Severity: wishlist

Dear Maintainer,

I just wanted to report that version 1.2.9 of fityk is available from 
its git repository. Please consider upgrading!

Thanks

Andres

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

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

Versions of packages fityk depends on:
ii  libbz2-1.0  1.0.6-5
ii  libc6   2.18-5
ii  libgcc1 1:4.9.0-1
ii  liblua5.1-0 5.1.5-5
ii  libreadline66.3-6
ii  libstdc++6  4.9.0-1
ii  libwxbase3.0-0  3.0.0-2
ii  libwxgtk3.0-0   3.0.0-2
ii  libxy3  1.3-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages fityk recommends:
ii  gnuplot  4.6.5-1

Versions of packages fityk suggests:
ii  libjs-sphinxdoc  1.2.2+dfsg-1

-- 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#416501: nfdump: can't customize behaviour

2014-05-05 Thread Denis Volkov

Hello
7 years later I've faced the same problem.
This is how script should start nfcapd:
+ start-stop-daemon --start --quiet --pidfile /var/run/nfcapd.pid 
--exec /usr/bin/nfcapd -- ... -x '/root/nfrotate-args %f'

If we check command line in /proc//cmdline, we can see:
00 2D 78 │ 00 2F 72 6F │ 6F 74 2F 6E │ 66 72 6F 74 │ 61 74 65 2D  | 61 
72 67 73 │ *20* 25 66 00 || -x./root/nfrotate-args %f.
"0x00" is the delimiter between args, 0x20 (space) is the delimiter 
between command and arguments for -x option


Default init script does this:

DAEMON_ARGS=" ... -x '/root/nfrotate-args %f'"


+ start-stop-daemon --start --quiet --pidfile /var/run/nfcapd.pid 
--exec /usr/bin/nfcapd -- ... -x ''\''/root/nfrotate' '%f'\'''

From /proc:
2D 78 │ 00 27 2F 72 │ 6F 6F 74 2F │ 6E 66 72 6F │ 74 61 74 65 | 2D 61 72 
67 │ 73 *00 *25 66 │ 27 00 || -x.'/root/nfrotate-args.%f'.
Delimiter between command and argument - 0x00, not 0x20, so nfcapd does 
not see %f, and it thinks it does not belong to -x option


I'm not very good at init scripts, so the only way I've found is add 
options in default file for command and it's arguments.













--- /etc/default/nfdump.old 2014-05-06 10:11:34.115628154 +0600
+++ /etc/default/nfdump 2014-05-06 10:13:00.572421179 +0600
@@ -2,3 +2,5 @@
 nfcapd_start=yes
 
 DAEMON_ARGS=" -l /srv/nflow/ -T all -S 1 -t 60 -D -P /var/run/nfcapd.pid -w"
+PROCESS_SCRIPT=""
+PROCESS_ARGS=""
--- /etc/init.d/nfdump.orig 2014-05-06 10:14:32.357509577 +0600
+++ /etc/init.d/nfdump  2014-05-06 10:14:56.630855246 +0600
@@ -53,9 +53,16 @@
#   2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 
--test > /dev/null \
|| return 1
-   start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
-   $DAEMON_ARGS \
-   || return 2
+   if [ x"$PROCESS_SCRIPT" = x ]
+   then
+   start-stop-daemon --start --quiet --pidfile $PIDFILE --exec 
$DAEMON -- \
+   $DAEMON_ARGS\
+   || return 2
+   else
+   start-stop-daemon --start --quiet --pidfile $PIDFILE --exec 
$DAEMON -- \
+   $DAEMON_ARGS -x $PROCESS_SCRIPT\ $PROCESS_ARGS\
+   || return 2
+   fi
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one.  As a last resort, sleep for some time.


Bug#648688: emacs23-lucid: package description is unhelpful

2014-05-05 Thread Rob Browning
Jonathan Nieder  writes:

> Package: emacs23-lucid
> Version: 23.3+1-4
> Severity: minor
> X-Debbugs-Cc: debian-l10n-engl...@lists.debian.org
>
> Hi,
>
> "apt-cache show emacs23-lucid" tells me:
>
> | Description: The GNU Emacs editor
> |  GNU Emacs is the extensible self-documenting text editor.
> |  This package contains a version of Emacs with a Lucid user interface.

If 24.3+1-3 doesn't sufficiently address your concerns, just shout.

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


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



Bug#608248: slapd lenny->squeeze upgrade failure: still affected?

2014-05-05 Thread Ryan Tandy
tags 608248 + moreinfo
thanks

Hi Martin,

Thanks for reporting this bug, several years ago. I'm sorry it hasn't
had an answer until now.

>From the message "Error, entries missing!" in your original report, it
seems to me that your database was probably already corrupted somehow
when you did the upgrade.

Do you still experience this bug in more recent releases, or can you
provide more information about the configuration that led to it?

thanks,
Ryan


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



Bug#747158: gnu-efi: new upstream version breaks compatibility with -nostdinc

2014-05-05 Thread Steve Langasek
Package: gnu-efi
Version: 3.0v-1
Severity: serious

Hi Daniel, Nigel,

The new upstream version of gnu-efi, 3.0v, introduced a dependency from
efilib.h on efistdarg.h and from there to stdarg.h.  This makes gnu-efi
incompatible with -nostdinc, which is a typical way to build for EFI (in
order to avoid accidental external dependencies), as you probably know.

  2014-01-13 Nigel Croxon 
   Implement VSPrint function, prints a formatted unicode string to a buffer.

Signed-off-by: Jeremy Compostella 
Signed-off-by: Nigel Croxon 

This causes a build failure in gummiboot in unstable:

gcc  -I. -include config.h -I/usr/include/efi -I/usr/include/efi/x86_64 
-DMACHINE_TYPE_NAME=\"x64\"  -Wall -Wextra -nostdinc -ggdb -O0 -fpic 
-fshort-wchar -nostdinc -ffreestanding -fno-strict-aliasing 
-fno-stack-protector -Wsign-compare -mno-sse -mno-mmx -mno-red-zone 
-DEFI_FUNCTION_WRAPPER -DGNU_EFI_USE_MS_ABI -c src/efi/util.c -o src/efi/util.o
In file included from /usr/include/efi/efilib.h:27:0,
 from src/efi/util.c:19:
/usr/include/efi/efistdarg.h:22:20: fatal error: stdarg.h: No such file or 
directory
 #include "stdarg.h"
^
compilation terminated.
make[2]: *** [src/efi/util.o] Error 1

(It also causes a build failure in shim, which has not been uploaded to
Debian yet since Debian doesn't have a key to embed with it - so this is an
Ubuntu-specific build failure for the moment.)

I don't think efilib.h should fail with -nostdinc.  Perhaps VPrint and
VFPrint should be moved out of this header.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#742829:

2014-05-05 Thread Daniel Richard G.
clone 742829 -1
reassign -1 lightdm
thanks

The lightdm package includes an AppArmor abstraction

/etc/apparmor.d/abstractions/lightdm_chromium-browser

that also needs to be adapted for the Debian packaging of the
Chromium browser [in the same way as the main Chromium profile
/etc/apparmor.d/usr.bin.chromium-browser].


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



Bug#747157: libunwind: FTBFS on ppc64: Please use /usr/lib instead of /usr/lib64

2014-05-05 Thread Hiroyuki Yamamoto
Source: libunwind
Version: 1.1-2.2
Severity: important
Tags: patch
Usertags: ppc64

libunwind fails to build on ppc64.
http://buildd.debian-ports.org/status/package.php?p=libunwind&suite=sid
http://buildd.debian-ports.org/status/fetch.php?pkg=libunwind&arch=ppc64&ver=1.1-2.2&stamp=1394608509

Please use /usr/lib instead of /usr/lib64 on Debian.
Here is a patch and a buildlog attached.

Regards,
-- 
Hiroyuki Yamamoto
A75D B285 7050 4BF9 AEDA  91AC 3A10 59C6 5203 04DC
diff -Nurd libunwind-1.1.orig/configure.ac libunwind-1.1/configure.ac
--- libunwind-1.1.orig/configure.ac	2014-05-06 11:25:17.0 +0900
+++ libunwind-1.1/configure.ac	2014-05-06 11:41:35.0 +0900
@@ -164,12 +164,6 @@
 AM_CONDITIONAL(USE_DWARF, [test x$use_dwarf = xyes])
 AC_MSG_RESULT([$use_dwarf])
 
-if test x$target_arch = xppc64; then
-libdir='${exec_prefix}/lib64'
-AC_MSG_NOTICE([PowerPC64 detected, lib will be installed ${libdir}]);
-AC_SUBST([libdir])
-fi
-
 AC_MSG_CHECKING([whether to restrict build to remote support])
 if test x$target_arch != x$host_arch; then
   CPPFLAGS="${CPPFLAGS} -DUNW_REMOTE_ONLY"


libunwind_1.1-2.2_ppc64.build.xz
Description: application/xz


Bug#747127: opensp: Please use dh-autoreconf at build time

2014-05-05 Thread Neil Roeth
I will take a look at incorporating this into the build.  Thanks.

On 05/05/2014 03:54 PM, Steve Langasek wrote:
> Package: opensp
> Version: 1.5.2-11
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu utopic ubuntu-patch
>
> Hi Neil,
>
> The opensp package in Ubuntu has been patched to use dh-autoreconf at build
> time, to force full regeneration of all autoconf-generated files.  As has
> been discussed recently on debian-devel, this is necessary in order for
> opensp to build on the new ppc64el port (because an updated libtool is
> needed), and there's a growing consensus that we should do this by default
> wherever possible.
>
> Please consider applying the attached patch to the Debian package.
>
> Thanks,


-- 
Neil Roeth


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



Bug#747156: crawl: New upstream release (0.14.1) available

2014-05-05 Thread Vincent Cheng
Package: crawl
Version: 2:0.13.1-1
Severity: wishlist

Dear Maintainer,

Please consider packaging the latest upstream release (0.14.1). Thanks!

Regards,
Vincent

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

Kernel: Linux 3.14-2-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
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 crawl depends on:
ii  crawl-common  2:0.13.1-1
ii  libc6 2.18-5
ii  libgcc1   1:4.9.0-1
ii  liblua5.1-0   5.1.5-5
ii  libncursesw5  5.9+20140118-1
ii  libsqlite3-0  3.8.4.3-1
ii  libstdc++64.9.0-1
ii  libtinfo5 5.9+20140118-1
ii  zlib1g1:1.2.8.dfsg-1

crawl recommends no packages.

crawl 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#747155: tt-rss: New upstream release (1.12) available

2014-05-05 Thread Vincent Cheng
Package: tt-rss
Version: 1.11+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider packaging the latest upstream release (1.12). Thanks!

Regards,
Vincent

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

Kernel: Linux 3.14-2-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
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#745356: [Pkg-openldap-devel] Bug#745356: Depend on heimdal-multidev rather than heimdal-dev

2014-05-05 Thread Jelmer Vernooij
Hi Ryan,

On Sun, May 04, 2014 at 02:16:52PM -0700, Ryan Tandy wrote:
> Thanks for the patch!
> 
> Unfortunately, based on a test build with libkrb5-dev and
> heimdal-multidev installed, #705884 seems to be reintroduced.
> 
> The build log says:
> 
> libtool: relink: cc -shared  -fPIC -DPIC  .libs/smbk5pwd.o
> -L/home/rtandy/Packages/work/openldap/openldap/debian/tmp/usr/lib/x86_64-linux-gnu
> -L/usr/lib/x86_64-linux-gnu -lldap_r -llber
> -L/usr/lib/x86_64-linux-gnu/heimdal -lkadm5srv -lgcrypt  -O2 -Wl,-z
> -Wl,relro -Wl,-z -Wl,now   -pthread -Wl,-soname -Wl,smbk5pwd.so.0 -o
> .libs/smbk5pwd.so.0.0.0
> 
> I see /usr/lib/x86_64-linux-gnu ahead of
> /usr/lib/x86_64-linux-gnu/heimdal, and with libkrb5-dev installed I
> suppose -lkadm5srv is being picked up from the former location.
> 
> I'm totally new to libtool. Do you know of a way to resolve this?

Unfortunately my familiarity with libtool is also limited.

It seems like one way to work around this should be to change the
order of the libraries in the smb5pwd Makefile, i.e. this line:

LIBS = $(LDAP_LIB) $(HEIMDAL_LIB) $(SSL_LIB)

to

LIBS = $(HEIMDAL_LIB) $(LDAP_LIB) $(SSL_LIB)

Cheers,

Jelmer



signature.asc
Description: Digital signature


Bug#727171: mime-support: /etc/mime.types of pcf font

2014-05-05 Thread Charles Plessy
Control: tag -1 - upstream
Control: tag -1 pending

Le Tue, May 06, 2014 at 10:59:09AM +1000, Kevin Ryde a écrit :
> Charles Plessy  writes:
> >
> > I think that for the moment I will solve the problem by removing the pcf 
> > suffix
> > from application/x-font, or remove this media type altogether.
> 
> x-font seems unlikely to be much good as it doesn't say anything about
> the format.  But I think x-font-pcf is reasonable and gnome is using it.

Indeed, I noticed this and what I would like to avoid is people shunting the
IANA and “registering” unregistered types to the FreeDesktop project because it
looks easier.  Then we will have two registrations authorities with different
scopes and policies, and it will be a mess.

This said, I will add x-font-pcf, as it is old enough that it will be hard to
find somebody willing to register something else to the IANA.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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



Bug#90483: [mime-support] Add it to documentation

2014-05-05 Thread Charles Plessy
Le Mon, May 05, 2014 at 10:23:51AM -0700, bastien ROUCARIES a écrit :
> >There is a good explanation in http://bugs.debian.org/745141#17 that %s 
> >should
> >not be quoted in /etc/mailcap because a program can not rely on it blindly.  
> >I
> >am therefore closing this bug (#90483).
> 
> Hi charles,
> 
> Do you have added it to documentation (manpage) ?

Hi Bastien,

I am adding a link to RFC 1524 in the mailcap manpage.

I have mixed feelings about improving this manpage.  Quite obviously, it was
not made in Debian.  But I can not find an upstream source anymore.  In that
sense, I would like to avoid divergence with other platforms.

I will contact the maintainer of the mailcap package in Fedora to see if we can
join forces and become upstream with other distibutions if there is no
alternatives.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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



Bug#747154: Backspace and delete keys dysfunctional in gedit

2014-05-05 Thread Gunnar Hjalmarsson
Package: scim
Version: 1.4.14-6

This is a forward of the Ubuntu bug https://launchpad.net/bugs/1315579

When using an IM via scim with the GNOME text editor gedit, the
backspace and delete keys do not work properly. This problem makes scim
effectively useless together with gedit.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


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



Bug#747079: xfsdump: new upstream release (2013-05-08 v3.1.3)

2014-05-05 Thread Nathan Scott


- Original Message -
> Package: xfsdump
> Version: 3.1.1
> Severity: wishlist
> 
> Hello there,
> 
> please consider updating the package to the newest upstream release, see

I have one debian-specific patch to get merged and then hope to convince
the XFS folks to make a new xfsdump release shortly thereafter, and then
upload that one.

Thanks for the reminder note, Florian.

cheers.

--
Nathan


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



Bug#747080: xfsprogs: new upstream release (2013-05-08 v3.1.11)

2014-05-05 Thread Nathan Scott


- Original Message -
> Package: xfsprogs
> Version: 3.1.9
> Severity: wishlist
> 
> Hello there,
> 
> please consider updating the package to the newest upstream release, see
> 

Hi Flo,

There is a pending xfsprogs-3.2.0 release - I've been working on ensuring
the build and packaging and clean there.  I'm planning to upload that right
after its released, which I'm led to believe is just days away.

cheers.

--
Nathan


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



Bug#747110: systemd: non-booting post d-u with "systemd"

2014-05-05 Thread c d
Good,

But some program figured out  a new ip-address, after
/etc/network/interfaces was commented out.

The "...start job for LSB" was indeed affected by the
/etc/network/interfaces  not commented out.

Cheers,

Pela


On Mon, May 5, 2014 at 5:50 PM, Michael Stapelberg wrote:

> Hi Pela,
>
> c d  writes:
> > I have no nfs-mount in fstab and did not think my problem to be related.
> > It may well be the same problem, with different causes, or not.
> > I don't know if this is a contention between the old network system and
> > "NetworkManager"?
> Please keep the bug address in CC, otherwise your messages won’t show
> up.
>
> I don’t think NetworkManager is related to this problem.
>
> --
> Best regards,
> Michael
>


Bug#747153: [libokteta1core1] "This package the core part" in extended description

2014-05-05 Thread Filipus Klutiero

Package: libokteta1core1
Version: 4:4.12.4-1
Severity: minor

The extended description contains:

This package the core part of the Okteta libraries.


A verb is missing. This could read:

This package contains the core part of the Okteta libraries.


By the way, I recommend to review the descriptions of all libraries built from 
okteta for the same error and because short descriptions can be confusingly 
similar.

--
Filipus Klutiero
http://www.philippecloutier.com


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



Bug#747152: [libkonqsidebarplugin4a] "contains base library" in extended description

2014-05-05 Thread Filipus Klutiero

Package: libkonqsidebarplugin4a
Version: 4:4.12.4-1
Severity: minor

The extended description starts with:

This package contains base library for Konqueror sidebar plugins.


A determiner is missing between "contains" and "base". I suggest:

This package contains the base library for Konqueror sidebar plugins.


--
Filipus Klutiero
http://www.philippecloutier.com


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



Bug#746592: I'd Say Grave

2014-05-05 Thread Jeremy Einsweiler
Yahoo, MSN, & Google. Kind of covers all the big players.


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



Bug#747070: ITP: apt-venv -- apt virtual environment

2014-05-05 Thread Paul Wise
On Tue, May 6, 2014 at 12:57 AM, Leo Iannacone wrote:

> It has been developed to provide user with a full virtual environment,
> where you can run any command/script you want.
> If fact, it launches a new `bash` session with a custom APT_CONFIG
> environment variable, which forces apt to use a different
> sources.list.

chdist also sets APT_CONFIG, it doesn't however run bash but it would
be trivial to add that.

Some more similar things:

http://modules.sourceforge.net/ (sets PATH/PYTHONPATH etc)
https://packages.debian.org/sid/proot (fake chroot using ptrace)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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



Bug#747151: linux-tools: FTBFS: __u32 and __u64 shoud be used instead of u32 and u64

2014-05-05 Thread Hiroyuki Yamamoto
Source: linux-tools
Version: 3.14-1
Severity: important
Tags: patch upstream
Usertags: ppc64 alpha

FTBFS on ppc64 and alpha of linux-tools is brought by using u32 and u64.
http://buildd.debian-ports.org/status/package.php?p=linux-tools&suite=sid
http://buildd.debian-ports.org/status/fetch.php?pkg=linux-tools&arch=ppc64&ver=3.14-1&stamp=1399098596
http://buildd.debian-ports.org/status/fetch.php?pkg=linux-tools&arch=alpha&ver=3.14-1&stamp=1398794797

I think that __u32 and __u64 should be used in kernel headers instead of u32 
and u64.

Here is a patch and buildlog attached.

Regards,
-- 
Hiroyuki Yamamoto
A75D B285 7050 4BF9 AEDA  91AC 3A10 59C6 5203 04DC
diff -Nurd linux-tools-3.14.orig/include/linux/types.h linux-tools-3.14/include/linux/types.h
--- linux-tools-3.14.orig/include/linux/types.h	2014-03-31 12:40:15.0 +0900
+++ linux-tools-3.14/include/linux/types.h	2014-05-06 09:02:25.0 +0900
@@ -127,8 +127,8 @@
  * blkcnt_t is the type of the inode's block count.
  */
 #ifdef CONFIG_LBDAF
-typedef u64 sector_t;
-typedef u64 blkcnt_t;
+typedef __u64 sector_t;
+typedef __u64 blkcnt_t;
 #else
 typedef unsigned long sector_t;
 typedef unsigned long blkcnt_t;
@@ -143,9 +143,9 @@
 #endif
 
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
-typedef u64 dma_addr_t;
+typedef __u64 dma_addr_t;
 #else
-typedef u32 dma_addr_t;
+typedef __u32 dma_addr_t;
 #endif /* dma_addr_t */
 
 #ifdef __CHECKER__
@@ -159,9 +159,9 @@
 typedef unsigned __bitwise__ oom_flags_t;
 
 #ifdef CONFIG_PHYS_ADDR_T_64BIT
-typedef u64 phys_addr_t;
+typedef __u64 phys_addr_t;
 #else
-typedef u32 phys_addr_t;
+typedef __u32 phys_addr_t;
 #endif
 
 typedef phys_addr_t resource_size_t;


linux-tools_3.14-1_ppc64.build.xz
Description: application/xz


Bug#727171: mime-support: /etc/mime.types of pcf font

2014-05-05 Thread Kevin Ryde
Charles Plessy  writes:
>
> I think that for the moment I will solve the problem by removing the pcf 
> suffix
> from application/x-font, or remove this media type altogether.

x-font seems unlikely to be much good as it doesn't say anything about
the format.  But I think x-font-pcf is reasonable and gnome is using it.


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



Bug#747150: non-obvious password lockout? [st...@einval.com: Re: [Debconf-team] SSO problems?]

2014-05-05 Thread Steve Langasek
Package: sso.debian.org

Hi guys,

Please see below.  It seems that users can get locked out of sso.debian.org
(temporarily? permanently?) as a result of too many bad password attempts,
and that it's not obvious to the user that this will happen, when it will
happen, or that it has happened.

Even assuming that this is actually what's going on in the problem described
here.  Given that Steve reports he was still seeing the problem in one
browser, but able to log in successfully with another, maybe the problem
lies elsewhere?


- Forwarded message from Steve McIntyre  -

Date: Tue, 6 May 2014 00:04:37 +0100
From: Steve McIntyre 
To: Steve Langasek , debconf-t...@lists.debconf.org
Subject: Re: [Debconf-team] SSO problems?
User-Agent: Mutt/1.5.21 (2010-09-15)

On Mon, May 05, 2014 at 03:30:55PM -0700, Steve Langasek wrote:
>On Mon, May 05, 2014 at 10:19:11PM +0100, Steve McIntyre wrote:
>> I've tried to log in a couple of times using my SSO password, now I'm
>> getting this:
>
>> Forbidden
>
>> You don't have permission to access /o/authorize on this server.
>> Apache Server at sso.debian.org Port 443
>
>Someone else has reported this on IRC, but gone idle before I could get any
>details.  Maybe helpful if you can drop in one of the appropriate channels
>so we can debug this in realtime.

It's getting too late here for me to jump into IRC tonight, I'm
afraid. So here's as much detail as I can give by mail...

>I'm not able to reproduce the described problem.  Can you please give:
>
> - the URL of the page on summit.debconf.org that you followed the link from

Following a link from

  http://debconf14.debconf.org/registration.xhtml

, pointing at

   https://summit.debconf.org/debconf14/registration/ 

. That redirected to

  
https://sso.debian.org/o/authorize?scope=openid+email+profile&state=WRVFSOMpGbT2Gsd0wBlSsZYqnnF5Tc1q&redirect_uri=https://summit.debconf.org/complete/debian-oauth2/&response_type=code&client_id=HUL=1jMcEEjGjYJecEI@xuJKF2N8i!LmVXpaeusm

which is the page with the 403.

> - the full URL of the link you were following
> - if you had failed login attempts before hitting the error, how many times
>   that happened before you got the Forbidden error (i.e., is this an
>   account lockout kind of thing)

I think it may well be that. I couldn't remember my SSO password
(maybe 2 attempts there), so went and changed it. I tried again with
the new password a couple of times (I'm guessing before settings had
synced somewhere?), and that's when I started getting the 403
page. I'm still seeing it now if I try again from the same browser
(iceweasel). Switching to chromium a little later, I was able to log
in successfully using the new SSO password.

>Sorry for the trouble.  It seems that DebConf registration is really finding
>the corner cases on the new SSO service.  Assuming the SSO team don't go on
>strike in protest, I'm sure we'll have it all sorted out before too much
>longer.

Hopefully... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray


- End forwarded message -

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#746799: [Pkg-alsa-devel] Bug#746799: alsa-base: Depends: kmod but it is not going to be installed

2014-05-05 Thread Marco d'Itri
On May 05, Elimar Riesebieter  wrote:

> So yes, why not orphan alsa-base for Jessie?
It is useful to have a dummy package around because it can clean up its 
own config files.
Otherwise you risk keeping them around forever (and maybe causing issues 
with kmod in the future).

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#727171: mime-support: /etc/mime.types of pcf font

2014-05-05 Thread Charles Plessy
Le Tue, May 06, 2014 at 09:18:14AM +1000, Kevin Ryde a écrit :
> Charles Plessy  writes:
> >
> > Ideally, to give a new media type to PCF fonts, one would submit this new 
> > media
> > type to the IANA.
> 
> Yes.
> 
> > Do you think that it has chances to happen ?
> 
> Not immediately I wouldn't think.  I imagine usually it would be whoever
> defined the format who would submit it.  Is it from X11 somewhere?
> Maybe it pre-dates the existence of MIME.

I think that for the moment I will solve the problem by removing the pcf suffix
from application/x-font, or remove this media type altogether.

I just added application/font-sfnt for TrueType and OpenType fonts.  It looks
like applications/x-font is quite misleading as it is only for legacy formats.
I hope I can remove it eventually.

Have a nice day,

-- 
Charles


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



Bug#745719: kdebase: KDE device notifier does not reattach USB drives

2014-05-05 Thread Valerio Vanni
Package: kdebase
Followup-For: Bug #745719

>I have seen this as well but I though that this was a problem in udisks or
>some other system daemon.
>
>The reason for this assessment was that the device is gone, e.g. if I check
>which device is mounted while the mount is active, the same device (as in
>/dev/sdXX) is no longer present when the unmount has happend.

In the kde bug report the component is identified as "libsolid-udisks".



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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



Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

2014-05-05 Thread Zack Weinberg
On 05/05/2014 03:43 PM, Michael Stapelberg wrote:
> Hi Zack,
> 
> Fundamentally we agree with you of course. The devil is in the detail,
> though: sysvinit-core and systemd are coinstallable, for all the reasons
> you explained.
> 
> However, you seem to be using a package which depends on libpam-systemd,
> which, translated to English, means the package is using some
> functionality that can only be provided when logind is running. To
> ensure that logind is running, we had to make libpam-systemd depend on
> “systemd-sysv | systemd-shim”. It had to be systemd-sysv to not just
> ensure systemd is _present_, but to ensure it is _running_. If we don’t
> add this dependency, the package in question is broken, which may well
> be the bigger deal to most users than being able to roll back and forth
> between init systems :).

I understand this.

I contend that, therefore, "systemd-sysv", "sysvinit-core", *and*
"systemd-shim" (and "upstart" as well) (quotation marks indicate package
names) should *all* be coinstallable; an upgrade from wheezy should
install *both* "systemd-sysv" and "systemd-shim" if not already present,
and leave "sysvinit-core" installed; and a mechanism independent of
package management should control which init brings up the system on the
next boot.

I did a bit more digging into how it works right now in response to
Tolleef's message.  First, "systemd-shim" currently doesn't conflict
with "systemd-sysv" or "systemd", or vice versa.  I don't know how
"systemd-shim" works.  Does it properly get out of the way if the
running PID 1 is in fact systemd?  I hope so.  If it doesn't, that might
be more of a hassle to sort out than anything else.

Second, it might simplify matters to split the programs 'telinit',
'halt', 'poweroff', 'reboot', 'runlevel', and 'shutdown', and their
manpages, to a separate package shared among all supported init
implementations.  I observe that if you do install "systemd-sysv" on a
system that is currently booted with the /sbin/init from
"sysvinit-core", a subsequent 'reboot' still works.  Does that mean that
/bin/systemctl knows how to talk to sysvinit /sbin/init?  Can it do the
same for upstart?  If so, perhaps the "systemd" package should just take
over those programs.

If those things are taken care of, then I see no reason why
sysvinit-core, systemd, and upstart could not all provide alternatives
for /sbin/init, and we'd be done here.

zw



signature.asc
Description: OpenPGP digital signature


Bug#747149: duck: detect domains that have expired

2014-05-05 Thread Paul Wise
Package: duck
Severity: wishlist

A common thing that happens when domains expire is that they become for
sale. It would be great if duck could detect this situation. A recent
example of this is the fontmatrix Homepage, which has the text below. I
expect you will be able to find more instances in the archive. Another
possible indicator of expired but still resolvable domains is the text
below text in the whois information for the fontmatrix Homepage.

http://www.fontmatrix.net/

This domain may be for sale. Backorder this Domain

Registrant Name: REACTIVATION PERIOD
Registrant Email: reactivation-pend...@enom.com
Admin Name: REACTIVATION PERIOD
Admin Email: reactivation-pend...@enom.com
Tech Name: REACTIVATION PERIOD
Tech Email: reactivation-pend...@enom.com

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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


Bug#747105: policykit-1: depends on systemd

2014-05-05 Thread Laurent Bigonville
Adam Borowski wrote:
> Michael Biebl wrote:
> > non-sense.
> 
> Per the policy, severity for "breaks unrelated software" is
> "critical". Thus, this bug is valid.

If you think that systemd is breaking anything on your system please
open a bug against systemd package not policykit.


> Please explain to me why a wrapper that executes, among others,
> "pm-suspend" or "halt", would be related to an init system?
> Especially if those commands (which in turn _could_ be related!) work
> just fine without it.

Because policykit needs to track user session, that ConsoleKit is dead
for years, that logind is coming for free with the new selected init
system and because it's time IMVHO to start moving away from ConsoleKit
on linux architectures.

> If you can't fathom a reason why systemd might not work for someone,
> please re-read some of massive flamewars we had, I'm not going to
> repeat the arguments here.  As for policykit, though, basic
> functionality like being able to shutdown from xfce, is something not
> related to systemd in any way.

If you are looking carefully at the dependencies, policykit is
depending against libpam-systemd (because you need to have a logind
session for the things to work) which in turn depends against
"systemd-sysv | systemd-shim". If you don't like the systemd as PID1
just install systemd-shim and your init of choice, everything should
work as before.


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



Bug#747146: pptpd: initd./pptpd status - always says not running

2014-05-05 Thread Christoph Biedl
tags 747146 pending
thanks

Marc Matters wrote...

> /etc/init.d/pptpd status always says not running.
> Fix:  Add "-p" to status_of_proc (in front of pid file)

Thanks for the catch. Will upload a new version once a few more things
are sorted out.

Christoph


signature.asc
Description: Digital signature


Bug#747142: kernel-package: fails, reporting a bogus version

2014-05-05 Thread Manoj Srivastava
Hi,

Your kernel tree is dirty, which means that a '_' character is
 inserted into the version number. That  causes all kinds of problems.
  Yours: 3.15.0-rc4-x32+-10.00.Custom
  Mine:  3.15.0-rc4-10.00.Custom

That -x32+ causes problems. Eithe get rid of the script that
 appends the + for a dirty tree, or create a branch and commit ht
 changes to it.

Here are the first few lines of my build from a non-dirty tree:
--8<---cut here---start->8---
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.003.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do 
 \
cp -f  /usr/share/kernel-package/$file ./debian/;   
\
done
cp: cannot stat ‘/usr/share/kernel-package/ChangeLog’: No such file or directory
for dir  in Config docs examples ruleset scripts pkg po;  do
  \
  cp -af /usr/share/kernel-package/$dir  ./debian/; 
\
done
test -f debian/control || sed -e 's/=V/3.15.0-rc4/g'  \
-e 's/=D/3.15.0-rc4-10.00.Custom/g' -e 's/=A/amd64/g'  \
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/3.15/g'   \
-e 's/=M/Unknown Kernel Package Maintainer 
/g' \
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
  /usr/share/kernel-package/Control > debian/control
test -f debian/changelog ||  sed -e 's/=V/3.15.0-rc4/g'   \
-e 's/=D/3.15.0-rc4-10.00.Custom/g'-e 's/=A/amd64/g'   \
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer 
/g'\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp 
make -f debian/rules debian/stamp/conf/kernel-conf
--8<---cut here---end--->8---

Here is your log:
--8<---cut here---start->8---
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.003.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do 
 \
cp -f  /usr/share/kernel-package/$file ./debian/;   
\
done
cp: cannot stat /usr/share/kernel-package/ChangeLog: No such file or directory
for dir  in Config docs examples ruleset scripts pkg po;  do
  \
  cp -af /usr/share/kernel-package/$dir  ./debian/; 
\
done
test -f debian/control || sed -e 's/=V/3.15.0-rc4/g'  \
-e 's/=D/3.15.0-rc4-x32+-10.00.Custom/g' -e 
's/=A/amd64/g'  \
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/3.15/g'\
-e 's/=M/Unknown Kernel Package Maintainer 
/g'\
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
  /usr/share/kernel-package/Control > debian/control
test -f debian/changelog ||  sed -e 's/=V/3.15.0-rc4/g'   \
-e 's/=D/3.15.0-rc4-x32+-10.00.Custom/g'-e 's/=A/amd64/g'   
\
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer 
/g'\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp 
make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory '/home/kilobyte/linux'
--8<---cut here---end--->8---

-- 
Have you seen the latest Japanese camera?  Apparently it is so fast it
can photograph an American with his mouth shut!
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature


Bug#705786: disagree...

2014-05-05 Thread Xavier Brochard
Hello

I disagree. There is no reason to add such very specific and advanced shortcut 
in a tool that is supposed to be used by normal users. 
I too add my own shortcuts to Konqueror because it is what advanced users are 
supposed to do.
Current Debian shortcuts are all related to packages (package and backport 
search, bug reports search), which looks reasonable for normal users. Even Kde 
shortcuts are all around normal and advanced users, not programmers or 
techcrunch sysadmins.

-- 
Xavier / zeroheure


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



Bug#717807: kernel-release contains -dirty although the tree is clean

2014-05-05 Thread Manoj Srivastava
fixed 717807  13.003
thanks

Hi,

I guess this got fixed:
--8<---cut here---start->8---
This is kernel package version 13.003.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do 
 \
cp -f  /usr/share/kernel-package/$file ./debian/;   
\
done
cp: cannot stat ‘/usr/share/kernel-package/ChangeLog’: No such file or directory
for dir  in Config docs examples ruleset scripts pkg po;  do
  \
  cp -af /usr/share/kernel-package/$dir  ./debian/; 
\
done
test -f debian/control || sed -e 's/=V/3.15.0-rc4/g'  \
-e 's/=D/3.15.0-rc4-10.00.Custom/g' -e 's/=A/amd64/g'  \
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/3.15/g'   \
-e 's/=M/Unknown Kernel Package Maintainer 
/g' \
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
  /usr/share/kernel-package/Control > debian/control
test -f debian/changelog ||  sed -e 's/=V/3.15.0-rc4/g'   \
-e 's/=D/3.15.0-rc4-10.00.Custom/g'-e 's/=A/amd64/g'   \
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer 
/g'\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp 
make -f debian/rules debian/stamp/conf/kernel-conf
--8<---cut here---end--->8---
--8<---cut here---start->8---
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do 
\
 cp -f  /usr/share/kernel-package/$file ./debian/;  \
done
cp: cannot stat ‘/usr/share/kernel-package/ChangeLog’: No such file or directory
for dir  in Config docs examples ruleset scripts pkg po;do  
\
   cp -af /usr/share/kernel-package/$dir  ./debian/;
\
done
install -p -m 755 /usr/share/kernel-package/rules debian/rules
sed -e 's/=V/3.15.0-rc4/g'  \
-e 's/=D/3.15.0-rc4-10.00.Custom/g' -e 's/=A/amd64/g'  \
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/3.15/g'   \
-e 's/=M/Unknown Kernel Package Maintainer 
/g' \
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
  /usr/share/kernel-package/Control > debian/control
sed -e 's/=V/3.15.0-rc4/g' -e 's/=D/3.15.0-rc4-10.00.Custom/g'\
-e 's/=A/amd64/g' -e 's/=M/Unknown Kernel Package Maintainer 
/g' \
-e 's/=ST/linux/g'   -e 's/=B/x86_64/g'   \
/usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
--8<---cut here---end--->8---


Oh, and we only use $(version) when initially creating the
 ./debian directory; from that point on it is all $(KERNELRELEASE),

manoj
-- 
panic: can't find /
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature


Bug#705392: kernel-package: fails to build RC-kernel 3.2 with clang

2014-05-05 Thread Manoj Srivastava
Hi,

kernel-package does nothing special with the C compiler. If you
 can use clang to build the kernel, you can use kernel-package to
 package it. There is othing that kernel-package can do to make kernel
 building with clang easier.

In any case, what are the errors you saw?

manoj
-- 
Have you seen the latest Japanese camera? Apparently it is so fast it
can photograph an American with his mouth shut!
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature


Bug#727171: mime-support: /etc/mime.types of pcf font

2014-05-05 Thread Kevin Ryde
Charles Plessy  writes:
>
> Ideally, to give a new media type to PCF fonts, one would submit this new 
> media
> type to the IANA.

Yes.

> Do you think that it has chances to happen ?

Not immediately I wouldn't think.  I imagine usually it would be whoever
defined the format who would submit it.  Is it from X11 somewhere?
Maybe it pre-dates the existence of MIME.


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



Bug#747105: breaks unrelated packages

2014-05-05 Thread Adam Borowski
reopen 747105
kthxbye

> non-sense.

Per the policy, severity for "breaks unrelated software" is "critical". 
Thus, this bug is valid.

Please explain to me why a wrapper that executes, among others, "pm-suspend"
or "halt", would be related to an init system?  Especially if those commands
(which in turn _could_ be related!) work just fine without it.

If you can't fathom a reason why systemd might not work for someone, please
re-read some of massive flamewars we had, I'm not going to repeat the
arguments here.  As for policykit, though, basic functionality like being
able to shutdown from xfce, is something not related to systemd in any way.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


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



Bug#747147: whatmaps: bad package description

2014-05-05 Thread Justin B Rye
Package: whatmaps
Version: 0.0.5
Severity: wishlist
Tags: patch

The package description has several minor flaws (but even adding them
together this is still only a wishlist bug).

# Description: Find processes mapping shared objects

I wouldn't bother mentioning this if it was the only problem, but that
synopsis is a capitalised verb phrase; the DevRef-compliant format is
a non-capitalised noun phrase, such as

  Description: tool to find processes mapping shared objects

(I'm also not keen on the way it focusses on the implementation
rather than the objective, but never mind.)

#  After package upgrades, processes using a ahared library need to be
#  restarted to make use of that updated library (e.g. if the library got a
#  security upgrade).

A typo: "ahared".

A quibble: you can't restart a process.  What you restart is the
service.

The "e.g." is presented as if it's a random example of a situation
where the service won't be using the new library until restarted.
That's not right; it's the one kind of package upgrade where that
matters most.

I would suggest phrasing it as:

   After package upgrades (especially security fixes), services using a
   shared library need to be restarted to make use of the updated version.

#  Whatmaps looks for shared objects in packages and finds running programs that
#  map them, list them and allows one to restart them.

A grammar error (missing third-person-singular-present agreement): it
"listS" them ("list" makes it sound as if it's the plural programs
that list something).  But why itemise the stages of *finding* and
*listing* the programs separately here anyway?

The sentence also has a rogue "and", plus some generally awkward
phrasing.  For instance, "allow" isn't quite right - whatmaps doesn't
grant me permission to restart services, it offers to do that for me.

#  It can be integrated with apt to automatically restart services automatically
#  on security upgrades.

Repeated "automatically".

This is somewhat repetitive, once you've said that it optionally
restarts services that need it; so I would suggest merging it into the
previous paragraph, giving something like:

   Whatmaps looks for shared objects provided by upgraded packages, lists any
   running processes that map them, and can integrate with APT to restart
   services as needed after security upgrades.

Since this package deals with the same problem as checkrestart and
needrestart but approaches it from an interestingly different angle,
it might be worth adding a couple of lines to compare and contrast...
but I'll leave that up to you.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru whatmaps-0.0.5.pristine/debian/control whatmaps-0.0.5/debian/control
--- whatmaps-0.0.5.pristine/debian/control	2014-04-18 14:13:30.0 +0100
+++ whatmaps-0.0.5/debian/control	2014-05-01 13:37:58.989629007 +0100
@@ -15,13 +15,10 @@
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}, lsb-release,
  python-apt
-Description: Find processes mapping shared objects
- After package upgrades processes using a ahared library need to be
- restarted to make use of that updated library (e.g. if the library got a
- security upgrade).
+Description: tool to find processes mapping shared objects
+ After package upgrades (especially security fixes), services using a
+ shared library need to be restarted to make use of the updated version.
  .
- Whatmaps looks for shared objects in packages and finds running programs that
- map them, list them and allows one to restart them.
- .
- It can be integrated with apt to automatically restart services automatically
- on security upgrades.
+ Whatmaps looks for shared objects provided by upgraded packages, lists any
+ running processes that map them, and can integrate with APT to restart
+ services as needed after security upgrades.


Bug#629245: the symlinks are there, pointing to a wrong place

2014-05-05 Thread Adam Borowski
On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote:
> On Sat, Mar 16 2013, Adam Borowski wrote:
> 
> > ls -al /lib/modules/3.8.2-x32
> > lrwxrwxrwx 1 root root 36 Sep 27 04:09 build -> 
> > /home/kilobyte/tmp/kernel/linux-source-3.8
> > lrwxrwxrwx 1 root root 37 Sep 27 04:09 source -> 
> > /home/kilobyte/tmp/kernel/linux-source-3.8
> 
> Actually, not so: The postinst should take care of all this.

The symlinks still point to the build dir as of a week ago, with
kernel-package 12.036+nmu3.  Can't test 13.00* as those versions fail
building the kernel for me due to an unrelated bug (just reported).

> > Please fix, this breaks dkms among others.
> 
> The dkms issue might be something else. Do you have full logs for that?

I don't have kernel build logs due to #747142, DKMS output is:

Loading new virtualbox-4.3.10 DKMS files...
Building only for 3.14.2-x32
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

If I restore the source to that directory, all works ok.

Should I downgrade kernel-package to produce a full log?

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


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



Bug#578820: works here

2014-05-05 Thread Xavier Brochard
tag 578820 +moreinfo unreproducible
thanks


Hello

I can't see this behavior with current version (konqueror 4.12.4)
Does it still apply? If yes, please provide url to reproduce.

-- 
Xavier / zeroheure


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



Bug#579870: this is a minor wish

2014-05-05 Thread Xavier Brochard
Control: severity -1 wishlist


-- 
Xavier / zeroheure


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



Bug#747146: pptpd: initd./pptpd status - always says not running

2014-05-05 Thread Marc Matters
Package: pptpd
Version: 1.4.0-2
Severity: normal

Dear Maintainer,


/etc/init.d/pptpd status always says not running.
Fix:  Add "-p" to status_of_proc (in front of pid file)


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

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

Versions of packages pptpd depends on:
ii  bcrelay   1.4.0-2
ii  libc6 2.18-5
ii  libwrap0  7.6.q-25
ii  netbase   5.2
ii  ppp   2.4.6-2

pptpd recommends no packages.

pptpd suggests no packages.

-- Configuration Files:
/etc/init.d/pptpd changed [not included]
/etc/ppp/pptpd-options [Errno 2] No such file or directory: 
u'/etc/ppp/pptpd-options'
/etc/pptpd.conf changed [not included]

-- 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#542482: patch proposal

2014-05-05 Thread Manoj Srivastava
On Mon, May 05 2014, Denis Excoffier wrote:


>>> However, i would prefer that you remove one of the blank lines
>>> *after* this #line directive. That way, the linenum variable
>>> is left unchanged.
>> 
>>Could you elaborate? Where is this blank line being emitted?
>
> Take a flex-2.5.39 with no patch, feed it with the following foo.lex:
> % cat foo.lex
> /* myline 1 */
> %%
>   /* myline 3 */
> %%
> /* myline 5 */ int main() {
>   yylex();
>   fprintf(stdout, "%s %u\n", __FILE__, __LINE__);
>   return(0);
> }
> /* myline 10 */
> %
>
> In the output, you get 2 empty lines just before ‘/* myline 5 */‘. If
> you remove one of these, you get the same effect as with --linenum.  I
> think this is preferable to ‘--linenum’ (because you don’t have any
> reason to have 2 empty lines at the first place). Currently, i was not
> able to understand how to make this line disappear.

Wll, with the latest versopn in unstable, I get only one blank
 line, which is still off by one lex.yy.c:
--8<---cut here---start->8---
#define YYTABLES_NAME "yytables"

#line 4 "foo.lex"

/* myline 5 */ int main() {
  yylex();
  fprintf(stdout, "%s %u\n", __FILE__, __LINE__);
  return(0);
}
/* myline 10 */
--8<---cut here---end--->8---

> By the way, you also get an unexpected extra empty line after ‘/* myline 10 
> */‘. To
> omit this one, the easiest way is to replace ‘OUT_END_CODE ()’ in gen.c with
> outc(‘]’); outc(‘]’); outc(‘)’)
> The drawback is that you don’t get an extra newline in case foo.lex does
> not end with a newline, but you don’t have any source files not ending
> with newline do you?

Well, no extra line here either.

Unfortunately, I do not know how to get rid of any extra lines
 either. I shall apply that patch, to see if I can get it to say

manoj

#line 3 "foo.lex"

/* myline 5 */ int main() {


-- 
Make love, not war.-Hell, do both, get married! Women's restroom, The
Filling Station.  Bozeman, Montana.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature


Bug#747145: [l10n] Swedish translation for cyphesis-cpp

2014-05-05 Thread Anders Jonsson
Package: cyphesis-cpp
Severity: wishlist
Tags: l10n, patch

Attached is an updated Swedish translation for the cyphesis-cpp package.

Regards,
Anders Jonsson
# Swedish translation for cyphesis-cpp.
# Copyright (C) 2005, 2014 the cyphesis-cpp copyright holder
# This file is distributed under the same license as the cyphesis-cpp package.
# Daniel Nylander , 2005.
# Anders Jonsson , 2014.
#
msgid ""
msgstr ""
"Project-Id-Version: cyphesis-cpp\n"
"Report-Msgid-Bugs-To: cyphesis-...@packages.debian.org\n"
"POT-Creation-Date: 2014-04-30 01:26-0500\n"
"PO-Revision-Date: 2014-05-06 00:33+0100\n"
"Last-Translator: Anders Jonsson \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.6.4\n"

#. Type: note
#. Description
#: ../cyphesis-cpp.templates:1001
msgid "Configuration note"
msgstr "Konfigurationsnotering"

#. Type: note
#. Description
#: ../cyphesis-cpp.templates:1001
msgid ""
"In order to use cyphesis-cpp you must have access to a postgresql server. "
"The server does not have to be installed on the same host as cyphesis-cpp "
"but it has to be reachable over a network and you have to have access to it."
msgstr ""
"För att använda cyphesis-cpp måste du ha tillgång till en PostgreSQL-server. "
"Servern måste inte vara installerad på samma värd som cyphesis-cpp men den "
"måste vara nåbar över ett nätverk och du måste ha tillgång till den."

#. Type: note
#. Description
#: ../cyphesis-cpp.templates:1001
msgid ""
"For further configuration information please read /usr/share/doc/cyphesis-"
"cpp/README.Debian."
msgstr ""
"För mer information om konfigurationen, vänligen läs /usr/share/doc/cyphesis-"
"cpp/README.Debian."

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:2001
msgid "Use a local postgresql server?"
msgstr "Använda en lokal PostgreSQL-server?"

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:2001
msgid ""
"Cyphesis-cpp can use a local postgresql server over unix sockets instead "
"over a network. The database server doesn't need to listen to the network "
"then. This is recommended for local usage as it's thought to be more secure."
msgstr ""
"Cyphesis-cpp kan använda en lokal PostgreSQL-server för Unix-sockets "
"istället för över ett nätverk. Databasservern behöver då inte lyssna på "
"nätverket. Det är rekommenderat för lokal användning eftersom det är tänkt "
"att vara säkrare."

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:3001
msgid "Database server:"
msgstr "Databasserver:"

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:3001
#| msgid ""
#| "On which host is the postgresql database server located, which will be "
#| "used by cyphesis-cpp to store its internal data?"
msgid ""
"The host on which the postgresql database server is located. This will be "
"used by cyphesis-cpp to store its internal data."
msgstr ""
"Värden på vilken PostgreSQL-databasen är placerad. Denna kommer att användas "
"av cyphesis-cpp för att lagra dess interna data."

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:4001
msgid "Database name:"
msgstr "Databasnamn:"

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:4001
#| msgid ""
#| "What is the database name cyphesis-cpp should use on the database server?"
msgid "The database name cyphesis-cpp should use on the database server."
msgstr "Databasnamnet som cyphesis-cpp ska använda på databasservern."

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:5001
msgid "Database user:"
msgstr "Databasanvändare:"

#. Type: string
#. Description
#: ../cyphesis-cpp.templates:5001
msgid "Please type in the username for the database server"
msgstr "Ange användarnamnet för databasservern"

#. Type: password
#. Description
#: ../cyphesis-cpp.templates:6001
msgid "Password:"
msgstr "Lösenord:"

#. Type: password
#. Description
#: ../cyphesis-cpp.templates:6001
msgid "Please type in the password to use to access the database server"
msgstr "Ange lösenordet att användas för tillgång till databasservern"

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:7001
msgid "Register with the WorldForge metaserver?"
msgstr "Registrera mot metaservern för WorldForge?"

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:7001
msgid ""
"Cyphesis-cpp can use the metaserver of the WorldForge project to announce "
"itself to the world. Players will detect your server automatically when "
"starting their client."
msgstr ""
"Cyphesis-cpp kan använda metaservern för WorldForge-projektet för att "
"informera om sig själv för världen. Spelare kommer att hitta din server "
"automatiskt när de startar sin klient."

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:8001
msgid "Automatically start the Cyphesis server on boot?"
msgstr "Starta Cyphesis-servern automatiskt vid uppstart?"

#. Type: boolean
#. Description
#: ../cyphesis-cpp.templates:8001
msgid ""
"Cyphesis-cpp can st

Bug#735765: closed by Tatsuya Kinoshita (Bug#735765: fixed in wl-beta 2.15.9+0.20140504-1)

2014-05-05 Thread Juliusz Chroboczek
> [1  ]
> This is an automatic notification regarding your Bug report
> which was filed against the wl-beta package:
>
> #735765: IMAP: WL calls STATUS on selected folder
>
> It has been closed by Tatsuya Kinoshita .

I can confirm that it's fixed in wl-beta 2.15.9+0.20140504-1.  Thanks
a lot to both of you.

-- Juliusz


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



Bug#746436: Re: evolution-data-server: Unable to read any messages

2014-05-05 Thread Emilio Pozuelo Monfort
severity 746436 important
tags 746436 moreinfo unreproducible
thanks

Hi,

On 02/05/14 17:07, Paul Menzel wrote:
> Dear Jordi,
> 
> 
> thank you for your reply!
> 
> 
> Am Donnerstag, den 01.05.2014, 15:32 +0200 schrieb Jordi Mallach:
> 
>> On Wed, Apr 30, 2014 at 01:16:44AM +0200, Paul Menzel wrote:
>>> Package: evolution-data-server
>>> Version: 3.12.0-1
>>> Severity: grave
>>> Tags: upstream
>>> Justification: renders package unusable
>>> Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=728976
>>> Control: found -1 3.12.1-1
> 
> […]
> 
>>> upgrading from Evolution Data Server 3.8.5 to 3.12.x it is impossible to
>>> read messages. They are not shown.
>>>
>>> Even building Evolution Data Server from the upstream branch
>>> `evolution-data-server-3-12` with the commit below does not help.
>>>
>>> commit 4615a98c7be1e3f8d23aa8a1c4f43b9d1fb62712
>>> Author: Milan Crha 
>>> Date:   Fri Apr 25 08:33:48 2014 +0200
>>>
>>> Remove unused imapx_unmark_folder_subscribed()
>>>
>>> There are more issues like this reported in the GNOME Bugzilla, so spare
>>> Jessie/testing users from the regular Evolution upgrade pain until
>>> upstream fixes these issues.
>>
>> Thanks for the report. I wonder if you've tried with both e-d-s _and_
>> evolution from unstable, ie 3.12.1. There's a ton of bugfixes in there.
> 
> Yes, I did try Evolution and E-D-S 3.12.0 and 3.12.1.
> 
>> It's interesting we've only got one bug report like this in Debian,
> 
> I suppose most “mail power users”, i. e. users with over 10 accounts
> (POP and IMAP) and several hundred thousands of messages and those users
> probably using Debian Sid/unstable, moved away from Evolution a long
> time ago and I am the only masochist still using it. You are using Mutt
> too, if I am not mistaken. :P
> 
> Point is, it is not surprising, that there are only a few reports as I
> believe most Evolution users do not know how to submit a bug report and
> just accept crashes and other flaws.
> 
>> so let's see if we can track it down fast and let eds migrate.
> 
> I’ll try to help upstream to get these issues fixed, but I strongly
> believe the migration should wait until at least Evolution Data Server
> 3.12.2 is released. As you can see in the branch
> evolution-data-server-3-12 there are several critical fixes in there
> already.

Given that we've got no other reports like this, and that nobody from our team
can reproduce this, I'm downgrading the severity.

You're still encouraged to provide the requested information and we'll then try
to get this fixed, but I don't think this should block testing migration any 
longer.

Regards,
Emilio


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



Bug#747144: pppoe-setup cannot run, pppoe.conf is missing

2014-05-05 Thread Marc Matters
Package: pppoe
Version: 3.8-3
Severity: normal

Dear Maintainer,


Did try to install pppoe as mentioned in various places (needs edit pppoe.conf).
I did not succeed as pppoe.conf is missing.
pppoe-setup refuses to run, too, because pppoe.conf is missing.
Please incorporate the missing files.


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

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

Versions of packages pppoe depends on:
ii  libc6  2.18-5
ii  ppp2.4.6-2

pppoe recommends no packages.

pppoe 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#746497: sbc: Fix FTBFS in new archs

2014-05-05 Thread Steve Langasek
Package: sbc
Version: 1.2-1
Followup-For: Bug #746497
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu utopic ubuntu-patch

Dear Nobuhiro,

Please find attached a more complete patch for this issue, which also adds
a build-dependency on pkg-config - without which, dh_autoreconf will fail
at build time due to missing macros.

As has recently been discussed on debian-devel, forcing a full regeneration
of all autotools-generated files at build time is the most future-proof way
of ensuring the portability of packages to new architectures.  Please
consider applying this patch to sbc, which is still needed to make sbc 1.2-1
build on the new ppc64el architecture.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
=== modified file 'debian/control'
--- debian/control	2014-04-19 17:00:02 +
+++ debian/control	2014-05-05 22:44:08 +
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian Bluetooth Maintainers 
 Uploaders: Nobuhiro Iwamatsu 
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config
 Standards-Version: 3.9.4
 Homepage: http://www.bluez.org/
 Vcs-Git: git://git.debian.org/pkg-bluetooth/sbc.git

=== modified file 'debian/rules'
--- debian/rules	2014-04-19 17:00:02 +
+++ debian/rules	2014-05-05 22:38:22 +
@@ -3,7 +3,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --disable-tester --disable-silent-rules



Bug#747120: Package build requires root permissions, fakeroot doesn't work

2014-05-05 Thread Manoj Srivastava
Hi,

Could youplease try 13.003 instead? I hace build a set of
 packages today with tht version (the latest rc from Linus)

manoj
-- 
O'Reilly's Law of the Kitchen: Cleanliness is next to impossible
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature


Bug#729081: [Pkg-xfce-devel] Bug#729081: Suspend not working when closing lid

2014-05-05 Thread Omen Nemo
> As far as I can tell, you're using systemd. Can you confirm/infirm
> systemd is your PID1?

Infirm:
  PID TTY  STAT   TIME COMMAND
1 ?Ss 0:08 init [2]
 2910 ?S  0:01 /lib/systemd/systemd-logind

and indeed I have packages sysvinit and sysvinit-core at version 2.88dsf-53.

Cordially,
Omen


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



Bug#745593: use the loader, Luke

2014-05-05 Thread g1pi
It seems very similar to #702605.

A work-around: tell the loader to resolve all symbols at
startup, via the LD_BIND_NOW environment variable.  e.g.:

env LD_BIND_NOW=1 icedove

Currently I'm using lightning (not iceowl) and icedove does not crash.

Regards,
g1


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



Bug#747143: thinkfan: Compile with SMART support

2014-05-05 Thread Natanael Arndt
Package: thinkfan
Version: 0.9.2-1
Severity: wishlist

Dear Maintainer,
you could compile thinkfan with -DUSE_ATASMART to enable it to read the
temperature directly from the SMART status of the HDD by adding to the
configfile:
atasmart /dev/sda

I think this requires libatasmart then.



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

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

Versions of packages thinkfan depends on:
ii  libc6  2.18-5

thinkfan recommends no packages.

thinkfan suggests no packages.

-- Configuration Files:
/etc/default/thinkfan changed [not included]
/etc/thinkfan.conf changed [not included]

-- 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#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

2014-05-05 Thread Zack Weinberg
On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen  wrote:
> ]] Zack Weinberg
>> Fundamentally what I want is a bulletproof procedure for reverting to
>> sysvinit in case something goes wrong.
>
> Sounds like you're arguing that sysvinit-core should no longer ship
> /sbin/init, then, so systemd-sysv doesn't have to conflict with it.

Wouldn't that make the sysvinit implementation of /sbin/init
completely unavailable?  This is an earnest question.  I do not have
access to package contents right now.

Note that coinstallability is not enough -- the bulletproof procedure
(e.g. "update-init-system") must also be implemented, shipped, and
documented.

zw


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



Bug#723086: [libxkbcommon-dev] dh_install --fail-missing may fail

2014-05-05 Thread Julien Cristau
On Fri, May  2, 2014 at 09:45:43 -0300, Fernando Seiti Furusato wrote:

> Index: libxkbcommon-0.4.0/debian/libxkbcommon-dev.install
> ===
> --- libxkbcommon-0.4.0.orig/debian/libxkbcommon-dev.install 2014-05-02 
> 12:28:49.0 +
> +++ libxkbcommon-0.4.0/debian/libxkbcommon-dev.install  2014-05-02 
> 12:30:10.280005991 +
> @@ -6,3 +6,4 @@
>  usr/lib/*/libxkbcommon.a
>  usr/lib/*/libxkbcommon.so
>  usr/lib/*/pkgconfig/xkbcommon.pc
> +usr/share/doc/libxkbcommon

The subdirectory of /usr/share/doc should be the name of the package, so
libxkbcommon-dev here.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#746198: unar fails to extract test rar on arm.

2014-05-05 Thread peter green

peter green wrote:
So I decided to test it in some test chroots (note: the i386 chroot 
was on an amd64 host, the arm chroots were all on an armv7 host)


debian wheezy i386: works
debian wheezy armel: fails
debian wheezy armhf: fails
debian jessie armel: fails
debian jessie armhf: fails
raspbian jessie: fails

So it looks like a general arm breakage, not something specific to 
raspbian.
Another data point, it worked on my Pi running debian derived 3.6 and 
3.10 kernels and a mixture of raspbian wheezy and raspbian jessie. Could 
be a kernel config issue I guess.


I tried diffing the straces but there was too much noise for me to 
really see what was going on. Without a real error message I'm not sure 
what if anything can be done.



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



Bug#725786: Revisiting this...

2014-05-05 Thread Leoš Bitto
On Mon, May 5, 2014 at 11:53 PM, Santiago Garcia Mantinan
 wrote:
> Yes, Lukas case is different, but the case I found that is not working on
> 3.2 is not Lukas'. This case is based on a bridge with a card but which
> forces a different MAC on the bridge, not the MAC of the card that is
> attached.

That sounds like a configuration error to me - I have always used MAC
of the real card for the bridge, just as a "rule of thumb". Later I
wanted this MAC to stay the same all the time - hence "ip link set br0
address ...".

> This case works on 3.11 and later but doesn't work on 3.2, the
> bridge is set up and everything seems ok but network doesn't work.

It's nice to know that recent kernels have changed this, but I see it
as that it's up to the users what MAC they configure, and it's their
responsibility how it will work with their kernel.

It might be nice to provide functionality like "bridge_hw clone from
eth0", maybe even implicitly use the MAC of the first interface in
bridge_ports, but these are just ideas for improving the current
state.

The only thing that I see as clearly broken currently is that if I
configure bridge_hw with some explicit MAC, it does not stay the same
after I add more interfaces to the bridge - fortunately there is a
workaround with explicitly running "ip link set br0 address ..."
(thanks to that kernel patch from 2008).


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



Bug#742412: USB Webcam Grabs ALSA Card Index 0

2014-05-05 Thread Elimar Riesebieter
* Rainer Dorsch  [2014-04-07 22:49 +0200]:

> On Sunday 06 April 2014 22:39:28 Elimar Riesebieter wrote:
> [...]
> > 
> > Please leave me a note whether you are happy now. So I can close
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742412
> 
> I will look into it next weekend again, and then update the bugreport.

Any suggestion?

Elimar
-- 
  Do you smell something burning or is it me?


signature.asc
Description: Digital signature


Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

2014-05-05 Thread Samuel Thibault
Gabriele Giacone, le Mon 05 May 2014 23:50:40 +0200, a écrit :
> On Mon, May 5, 2014 at 6:12 PM, Samuel Thibault  wrote:
> > Gabriele Giacone, le Mon 05 May 2014 18:02:34 +0200, a écrit :
> >> On Mon, May 05, 2014 at 04:57:53PM +0200, Samuel Thibault wrote:
> >> > > + pitch = ALIGN_TO(pitch, alignment);
> >> >
> >> > Err, this can not work: "pitch" becomes completely undefined...
> >>
> >> Only said it would have built, not also worked ;)
> >
> > Well, submitting a patch usually means one thinks that it will work, not
> > just build...
> >
> >> - libdrm-dev (>> 2.0),
> >> + libdrm-dev (>> 2.0) [!hurd-any],
> >
> >> +--- a/src/via_driver.c
> >>  b/src/via_driver.c
> >> +@@ -49,6 +49,8 @@
> >> +
> >> + #ifdef HAVE_DRI
> >> + #include "dri.h"
> >> ++#else
> >> ++#include "drm_fourcc.h"
> >> + #endif
> >> +
> >
> > I don't see how that can build: drm_fourcc.h is part of libdrm-dev...
> 
> Not this one:
> http://sources.debian.net/src/xserver-xorg-video-openchrome/1:0.3.3-1/src/drm_fourcc.h

Oh, sorry, I didn't notice that.

This indeed looks like something that would work.

Samuel


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



Bug#747077: [pkg-fso-maint] Bug#747077: nodm: please ack NMUs and apply various pending patches

2014-05-05 Thread Sebastian Reichel
Hi Simon,

On Mon, May 05, 2014 at 01:27:28PM +0100, Simon McVittie wrote:
> I'd rather not maintain nodm long-term, but I'd consider NMUing it if
> the maintainers would like that to happen. I attach a possible patch
> series, also available to pull from
> https://alioth.debian.org/anonscm/git/users/smcv/nodm.git
> (gitweb: ).

Neither Enrico nor Joachim are still working actively on this
package. I have spoken with Enrico at DebConf 13 if he would
be ok with opening a RFH bug for the package and he approved
it. Then I totally forgot to actually do it.

The pkg-fso is quite small (I think I'm the last DD :/) and
nobody is working on nodm. Feel free to do whatever.

> While preparing this patch series I noticed that nodm is maintained
> in git as a non-native package, but it appears to be treated more like
> a native package, with no real upstream and no use of debian/patches to
> split out Debian changes - would the maintainers be willing to consider
> making it a real native package? That would work better with git-buildpackage,
> for instance.

sounds reasonable to me.

> Alternatively, if the maintainers would prefer to go to 3.0 (quilt) with
> maintainer-approved changes made "upstream" but NMU changes in
> debian/patches, I could prepare a version that looked more like that
> and make it available for git pull instead.

To summarize what Enrico told me: Do whatever is needed to keep nodm
up to date and working.

Thanks for working on this :)

-- Sebastian


signature.asc
Description: Digital signature


Bug#710855: gdk-pixbuf: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache'

2014-05-05 Thread Alex Robbins

Another story, with some extra details...

Same problem while using Testing on May 5, upgrading
libgdk-pixbuf2.0-common:amd64 from version 2.30.6-1 to 2.30.7-1. 
Aptitude printed:

Processing triggers for hicolor-icon-theme (0.13-1) ...

(gtk-update-icon-cache-3.0:19424): GdkPixbuf-WARNING **: Cannot open 
pixbuf loader module file 
'/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No 
such file or directory


This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

to make things work again for the time being.
Processing triggers for menu (2.1.46) ...


In my case, however,
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache actually 
did not
exist, although it was still in my mlocate.db, which indicates that 
although it was

there recently, it no longer is, but should be.

It sounds to me like either the error message is spurious (which is 
bad), or a

file was somehow deleted but shouldn't have been (also bad).

Thanks,
Alex Robbins


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



Bug#746550: needrestart: handle uncompressed kernel images

2014-05-05 Thread Thomas Liske

severity 746550 minor
thanks

Hi Axel,

On 05/01/2014 12:13 PM, Axel Beckert wrote:

P.S.: Feel free to clone this report if you want to track the probably
at least two different issues in here separately.


ACK, kernel image stuff goes into #746550.


Ok, downgrading that one to wishlist (via Bcc to control@b.d.o) as it
is probably a seldom corner case and hence more a feature request than
a real bug. At least "important" is not the proper severity for that
issue. :-)


the request fixing a broken needrestrat due to unexpected user input 
(a.k.a. uncompressed kernel images) should be at least a minor issue IMHO.


I think the kernel analysis requires some more testing tricky stuff... 
I'm already having some ideas... please stay tuned.



HTH,
Thomas

--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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



Bug#725786: Revisiting this...

2014-05-05 Thread Santiago Garcia Mantinan
On May 04 2014, Leoš Bitto wrote:
> I think that the crucial difference is that I start the bridge with
> one interface added (eth0), but Lukas starts the bridge without any
> interface. These two cases are very different - my case has a simple
> solution (see my previous comment), the case for Lukas is more
> complicated (depends on kernel version).

Yes, Lukas case is different, but the case I found that is not working on
3.2 is not Lukas'. This case is based on a bridge with a card but which
forces a different MAC on the bridge, not the MAC of the card that is
attached. This case works on 3.11 and later but doesn't work on 3.2, the
bridge is set up and everything seems ok but network doesn't work.

I'd like to know what fixed this and on which version, but my first searches
have failed to identify that.

Regards.
-- 
Manty/BestiaTester -> http://manty.net


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



Bug#747110: systemd: non-booting post d-u with "systemd"

2014-05-05 Thread Michael Stapelberg
Hi Pela,

c d  writes:
> I have no nfs-mount in fstab and did not think my problem to be related.
> It may well be the same problem, with different causes, or not.
> I don't know if this is a contention between the old network system and
> "NetworkManager"?
Please keep the bug address in CC, otherwise your messages won’t show
up.

I don’t think NetworkManager is related to this problem.

-- 
Best regards,
Michael


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



Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

2014-05-05 Thread Gabriele Giacone
On Mon, May 5, 2014 at 6:12 PM, Samuel Thibault  wrote:
> Gabriele Giacone, le Mon 05 May 2014 18:02:34 +0200, a écrit :
>> On Mon, May 05, 2014 at 04:57:53PM +0200, Samuel Thibault wrote:
>> > > + pitch = ALIGN_TO(pitch, alignment);
>> >
>> > Err, this can not work: "pitch" becomes completely undefined...
>>
>> Only said it would have built, not also worked ;)
>
> Well, submitting a patch usually means one thinks that it will work, not
> just build...
>
>> - libdrm-dev (>> 2.0),
>> + libdrm-dev (>> 2.0) [!hurd-any],
>
>> +--- a/src/via_driver.c
>>  b/src/via_driver.c
>> +@@ -49,6 +49,8 @@
>> +
>> + #ifdef HAVE_DRI
>> + #include "dri.h"
>> ++#else
>> ++#include "drm_fourcc.h"
>> + #endif
>> +
>
> I don't see how that can build: drm_fourcc.h is part of libdrm-dev...

Not this one:
http://sources.debian.net/src/xserver-xorg-video-openchrome/1:0.3.3-1/src/drm_fourcc.h


-- 
G..e


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



Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

2014-05-05 Thread Tollef Fog Heen
]] Zack Weinberg 

> On 2014-05-03 12:18 PM, Tollef Fog Heen wrote:
> > Zack Weinberg wrote:
> >> 1) Switching from sysvinit to systemd (and vice versa, if necessary)
> >> should be accomplished via a command dedicated to the purpose; it
> >> should *not* occur as a side effect of installing, removing,
> >> upgrading, or downgrading any package.
> >
> > So you say.  I (with my systemd maintainer hat on) disagrees, and this
> > has already been in wheezy and works quite well.
> >
> >> 2) The procedure I described should be the official procedure for
> >> making the changeover.
> >
> > Again, you say so, but provide no rationale or reason why.
> 
> Fundamentally what I want is a bulletproof procedure for reverting to
> sysvinit in case something goes wrong.  I made an analogy earlier to
> how upgrading to a newer upstream kernel (with Debian's packaging)
> keeps the old kernel installed and trivially bootable, in case
> something goes wrong.  This is not because the kernel maintainers know
> of specific situations where something *will* go wrong; it is because
> there is a nontrivial chance that something *could* go wrong, and in
> the worst case that will render the system unbootable.

Sounds like you're arguing that sysvinit-core should no longer ship
/sbin/init, then, so systemd-sysv doesn't have to conflict with it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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



Bug#746151: systemd: daemon-reload+reload kills a daemon with a BusName

2014-05-05 Thread Michael Stapelberg
control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=78311
control: tags -1 + upstream

Hi Josselin,

Thanks for your report. I was able to reproduce it and filed a report
upstream with the details of my investigation. Hopefully someone will
step up and provide a fix :).

-- 
Best regards,
Michael


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



Bug#747141: debhelper: dh_installdocs --link-doc forces source-version dependencies

2014-05-05 Thread Stephen Kitt
Package: debhelper
Version: 9.20140228
Severity: important

Hi Joey,

The potential bug referred to in #676777, namely that the strictly
versioned dependency introduced by dh_installdocs --link-doc can cause
packages to no longer be installable, is occurring with my
gcc-mingw-w64 packages.

Admittedly the way I'm using versions is a bit unconventional, but I
don't think it goes against policy... I have a simple, native source
version (12 currently in unstable, 13 in the package I'm working on),
but all the binary packages are built using my package source along
with gcc-4.8-source (gcc-4.9-source in the version I'm working on),
and use binary version of the form ${gcc:Version}+${source:Version},
e.g. 4.9.0-2+13.

My package correctly handled the documentation link with a strictly
versioned dependency on the binary version. With the fix for #676777,
dh_installdocs also introduces a strict dependency on the source
version, which can't be satisfied...

I'm afraid my perl-fu isn't up to fixing this quickly. In any case I'm
not sure what the correct fix should be; I guess the right thing to do
would be to determine the binary version of the packages being linked
to and use that, but I don't know how to go about that within
debhelper.

Regards,

Stephen


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

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

Versions of packages debhelper depends on:
ii  binutils2.24.51.20140425-1
ii  dpkg1.17.9
ii  dpkg-dev1.17.9
ii  file1:5.17-1
ii  man-db  2.6.7.1-1
ii  perl5.18.2-2+b1
ii  po-debconf  1.0.16+nmu2

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  0.63

-- 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#746363: needrestart: "uninitialized value" by kernel threads

2014-05-05 Thread Axel Beckert
Hi Thomas,

Thomas Liske wrote:
> Does the system has any enhanced security mechanism established?

At least not on purpose. Default debian kernels.

> I've attached a small debug script (modified needrestart script)
> which analysis the processes and looks for non-readable
> /proc//exe symlinks. Could you please run it once and provide
> it's output?

Will send the whole output to you by private e-mail. Just so far in
advance:

_All_ processes output by the script in detail (i.e. those shown with
"| fgrep cmndline") seem running inside a GNU Screen session. And if
I'm not mistaken, _all_ processes which are running inside a GNU
Screen session are in the detailed output.

So there seems to be some relation between where you suspect the error
and processes running in GNU Screen sessions.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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



Bug#747129: grub-pc-bin (2.00-22) no one module in /boot/grub after installation

2014-05-05 Thread Colin Watson
On Mon, May 05, 2014 at 11:03:58PM +0300, Андрей Василишин wrote:
> Package: grub-pc-bin
> Version: 1.42.9-3

This version number doesn't make sense as a version of grub-pc-bin.

> Hello!
> After upgrading grub2 from wheezy to jessie i have no one module in
> /boot/grub

They're in /boot/grub/i386-pc/ now.

> After system reboot I receive grub_rescue message

That probably indicates that your system is misconfigured and isn't
installing the GRUB core image to the right place.  Please post the
output of "debconf-show grub-pc" and "ls -l /dev/disk/by-id/".

-- 
Colin Watson   [cjwat...@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#746819: mount: Add dummy mount options for systemd.

2014-05-05 Thread Jan Christoph Uhde
I guess this bug should be closed.

Cheers!


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



Bug#747140: docker.io: unable to query docker version without user tracking

2014-05-05 Thread Jonathan McCrohan
Package: docker.io
Version: 0.9.1~dfsg1-2
Severity: important

Hi Paul,

It appears that it is not possible to query the current docker version
without the client hitting https://get.docker.io/latest to find the
latest upstream version. This could (arguably) allow DotCloud to track
the usage habits of Debian users.

Given that this package is provided by Debian, this version check is not
appropriate. This has already been raised upstream as issue #4802 [1].

Perhaps the attached patch against current docker HEAD (afaab73) would
be appropriate?

Thanks,
Jon

[1] https://github.com/dotcloud/docker/issues/4802

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

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

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.18
ii  iptables 1.4.21-1
ii  libapparmor1 2.8.0-5+b1
ii  libc62.18-5
ii  libdevmapper1.02.1   2:1.02.83-2
ii  libsqlite3-0 3.8.4.3-1
ii  perl 5.18.2-2+b1

Versions of packages docker.io recommends:
ii  aufs-tools   1:3.2+20130722-1.1
ii  ca-certificates  20140325
ii  cgroupfs-mount   1.0
ii  git  1:2.0.0~rc0-2
ii  xz-utils 5.1.1alpha+20120614-2

Versions of packages docker.io suggests:
ii  btrfs-tools  3.14.1-1
ii  debootstrap  1.0.59
pn  lxc  
ii  rinse2.0.1-1

-- no debconf information
>From afaab73f03e0a1a91a5e8baafacbb7e096381c5c Mon Sep 17 00:00:00 2001
From: Jonathan McCrohan 
Date: Mon, 5 May 2014 22:20:27 +0100
Subject: [PATCH] utils.go: Make GetReleaseVersion() a noop

Signed-off-by: Jonathan McCrohan 
---
 utils/utils.go | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/utils/utils.go b/utils/utils.go
index 066cfba..c2e3a07 100644
--- a/utils/utils.go
+++ b/utils/utils.go
@@ -926,19 +926,7 @@ func ParseHost(defaultHost string, defaultUnix, addr string) (string, error) {
 }
 
 func GetReleaseVersion() string {
-	resp, err := http.Get("https://get.docker.io/latest";)
-	if err != nil {
-		return ""
-	}
-	defer resp.Body.Close()
-	if resp.ContentLength > 24 || resp.StatusCode != 200 {
-		return ""
-	}
-	body, err := ioutil.ReadAll(resp.Body)
-	if err != nil {
-		return ""
-	}
-	return strings.TrimSpace(string(body))
+	return ""
 }
 
 // Get a repos name and returns the right reposName + tag
-- 
2.0.0.rc0



Bug#747139: docker.io: fails to run on i386

2014-05-05 Thread W. Martin Borgert
Package: docker.io
Version: 0.9.1~dfsg1-2
Severity: important

Please either change the platform check from failure into warning
or, not so nice, make the package amd64-only. Thanks!

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

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

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.18
ii  iptables 1.4.21-1
ii  perl 5.18.2-2+b1

Versions of packages docker.io recommends:
ii  aufs-tools   1:3.2+20130722-1.1
ii  ca-certificates  20140325
ii  cgroupfs-mount   1.0
ii  git  1:2.0.0~rc0-2
ii  xz-utils 5.1.1alpha+20120614-2

Versions of packages docker.io suggests:
pn  btrfs-tools  
ii  debootstrap  1.0.59
pn  lxc  
pn  rinse

-- 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#747130: owncloud 'Depends' on php-irods-prods while it is noted 'Recommends'

2014-05-05 Thread David Prévot
Hi Jérémy,

On Mon, May 05, 2014 at 10:15:32PM +0200, Jérémy Viès wrote:
> Package: owncloud
> Version: 6.0.2+dfsg-1~bpo70+1

“Please report bugs that you found in the packages to the backports
mailinglist[1] and NOT to the Debian BTS!”[2]

   1: http://lists.debian.org/debian-backports/
   2: http://backports.debian.org/Instructions/#index6h2

> After the installation of owncloud on Debian Wheezy, it was configured
> correctly, but was never able to start.
> 
> lighttpd error logs show:
> 2014-05-05 09:10:41: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal
> error:  require_once(): Failed opening required 'ProdsConfig.inc.php'
> (include_path='/usr/share/owncloud/lib/private:/usr/share/owncloud/config:/usr/share/owncloud/3rdparty:/usr/share/owncloud/apps:/usr/share/owncloud/lib:.:/usr/share/php:/usr/share/pear:/usr/share/owncloud:/usr/share/owncloud/apps/search_lucene/3rdparty:/usr/share/php/irods/prods/src')
> in /usr/share/owncloud/apps/files_external/lib/irods.php on line 15
> 
> The installation of php-irods-prods fixed the problem.

AFAICT, only the files_external app needs php-irods-prods, but it’s not
enabled by default, so no strict dependency is necessary here
(administrators who decide not to follow the maintainer’s
recommendations are exposed to fix their own installation).

Can you please confirm that you activated the files_external app?

Regards

David


signature.asc
Description: Digital signature


Bug#747130: owncloud 'Depends' on php-irods-prods while it is noted 'Recommends'

2014-05-05 Thread David Prévot
Control: notfound -1 6.0.2+dfsg-1~bpo70+1
Control: retitle -1 Recommends rationale should be documented
Control: severity -1 wishlist

On Mon, May 05, 2014 at 10:51:04PM +0200, Jérémy Viès wrote:

> I suppose that to note the dependencies of each provided application in the
> README.Debian would take too much time...

That’s actually a fair suggestion, the documentation should help
administrators pick the needed packages for their installation.

Regards

David


signature.asc
Description: Digital signature


Bug#747120: Package build requires root permissions, fakeroot doesn't work

2014-05-05 Thread Jens Seidel
Hi Manoj,

Am 5. Mai 2014 22:25 schrieb Jens Seidel :
> 2014-05-05 20:57 GMT+02:00 Manoj Srivastava :
>> That's not the real bug. Were you to run it as root, it would
>>  still do the wrong thing. The real bug has been fixed in kernl-package
>>  version 13.001
>
> If I run it as root I get at least a deb package :-)
>
> Haven't found a similar problem in the change log of 13.001 ...
>
> Using 13.001:
>
> $ make-kpkg -j6 --rootcmd fakeroot --initrd --append-to-version
> allmodules kernel_image kernel_headers
> exec make kpkg_version=Aufruf: dpkg-parsechangelog [...]

That's because /usr/bin/make-kpkg contains:

$main::AuthorMail  = "srivasta\@debian.org";
$main::Version = 'Aufruf: ...

The reason is the non-fatal error at build of kernel-package:

 make[1]: Leaving directory
`/home/jens/Software/Linux/Kernel/kernel-package/kernel-package-13.002'
   dh_auto_test
dpkg-parsechangelog: unknown option `--show-field'

I have dpkg-dev 1.16.14 but need 1.17.0:
* Add new dpkg-parsechangelog --show-field option to print a field value.
Closes: #284664

Rebuilding kernel-package using dpkg-dev 1.17.9 (haven't tested
1.17.0) seems to result in a working version. Great!
Please add dpkg-dev >= 1.17.0 to Build-Depends-Indep:.

But the obtained kernel-package version has the same problem:

sh /home/jens/Software/Linux/Kernel/linux/arch/x86/boot/install.sh
3.15.0-rc3allmodules-00180-g94f3b71-dirty arch/x86/boot/bzImage \
System.map
"/home/jens/Software/Linux/Kernel/linux/debian/linux-image-3.15.0-rc3allmodules-00180-g94f3b71-dirty//boot"
run-parts: executing /etc/kernel/postinst.d/dkms
3.15.0-rc3allmodules-00180-g94f3b71-dirty
/home/jens/Software/Linux/Kernel/linux/debian/linux-image-3.15.0-rc3allmodules-00180-g94f3b71-dirty//boot/vmlinuz-3.15.0-rc3allmodules-00180-g94f3b71-dirty
/usr/lib/dkms/dkms_autoinstaller: 42:
/usr/lib/dkms/dkms_autoinstaller: dkms: not found
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
3.15.0-rc3allmodules-00180-g94f3b71-dirty
/home/jens/Software/Linux/Kernel/linux/debian/linux-image-3.15.0-rc3allmodules-00180-g94f3b71-dirty//boot/vmlinuz-3.15.0-rc3allmodules-00180-g94f3b71-dirty
/etc/kernel/postinst.d/initramfs-tools: 35:
/etc/kernel/postinst.d/initramfs-tools: update-initramfs: not found
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127

Thanks for your fast reply,
Jens


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



Bug#747138: ITP: node-source-map -- Generates and consumes source maps

2014-05-05 Thread Leo Iannacone
Subject: ITP: node-source-map -- generates and consumes source maps
Package: wnpp
Severity: wishlist
Owner: Leo Iannacone 

* Package name: node-source-map
  Version : 0.1.33
  Upstream Author : Nick Fitzgerald 
* URL : https://github.com/mozilla/source-map
* License : BSD
  Programming Lang: JavaScript
  Description : generates and consumes source maps - JavaScript library

 JavaScript library which generates and consumes source maps
 in the format version 3.
 .
 This library is written in the Asynchronous Module Definition format.
 .
 Node.js is an event-based server-side JavaScript engine.


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



Bug#739053: rpcbind LSB initscript runlevels are incorrect

2014-05-05 Thread Roger Leigh
On Mon, May 05, 2014 at 01:15:48PM -0700, Steve Langasek wrote:
> Control: reopen -1
> 
> Roger,
> 
> > Please could you apply the following patch.  We are planning to upgrade
> > the version of insserv, and testing shows that the new version breaks
> > on the dependencies declared by rpcbind (which doesn't match the
> > dependent nfs-common).  This change adjusts the start runlevels to
> > match nfs-common.
> 
> What do you mean, it doesn't match?  The nfs-common init script has:
> 
> # Default-Start: S
> # Default-Stop:  0 1 6

I'm not sure myself.  I can't recall the details offhand I'm afraid;
I've spent the intervening months dealing with RSI and haven't done any
work on this since then.

> Anibal has reverted my deliberate change to rpcbind's init script, in
> response to this bug report which makes no sense.  Why did you think it was
> appropriate to mark rpcbind for start in both runlevel S and runlevels 2 3 4
> 5?

I was asked to test insserv from experimental, sometime before opening
this bug.  I found that the rpcbind LSB headers caused insserv to fail,
and this fixed things.  IIRC I discussed this with the insserv
maintainer but I could be wrong.  The reasons for this I'm not sure.
It may be there needed a corresponding change to nfs-common, but I
don't think that was the case.  During this period I couldn't even hold
the pages of a book open, let alone type properly, so it's possible
I've missed something.

Sorry I can't help more here.  I really can't recall the specifics, and
I'm not able to do more investigation at present due to my hands.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


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



  1   2   3   4   >