Bug#776701: ssd-test 1g file size too small

2015-02-16 Thread Martin Steigerwald
Am Montag, 16. Februar 2015, 15:04:03 schrieb Jens Axboe:
> On 02/04/2015 02:10 AM, Martin Steigerwald wrote:
> > Hello Daniel, hi Jens,
> > 
> > Am Samstag, 31. Januar 2015, 14:23:34 schrieb Daniel Pocock:
> >> Package: fio
> >> Version: 2.1.11-2
> >> Severity: important
> >> 
> >> 
> >> In the ssd-test sample config:
> >> 
> >> https://sources.debian.net/src/fio/2.1.11-2/examples/ssd-test.fio/
> >> 
> >> 
> >> The test size is 1GB, this line:
> >> 
> >> size=1g
> >> 
> >> 
> >> There are SSDs that have 1g caches and this leads to unhelpful
> >> results.
> >> 
> >> One user I discussed this with had to use a 10g test file to get
> >> consistent and meaningful results.
> >> 
> >> Maybe bump the example to 10g or add a comment in front of that line.
> > 
> > As the examples are taken from the upstream tarball, I suggest taking
> > this upstream. I put upstream in Cc, Jens, what do you think about
> > this?
> Sure, that sounds fine to me. 1G is tiny by todays standards, 10G would
> be a lot more reasonable. I'll commit that change.

Great. I think I will look into packaging latest fio upstream one of the 
next weeks.

(sorry for long sig, can´t disable it)

-- 
Martin Steigerwald  | Consultant / Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerw...@teamix.de | web:  http://www.teamix.de | blog: 
http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller


***Nicht verpassen: TechDemo Hochverfügbare Storage-Infrastruktur***
Nürnberg 25.02.15 | München 26.02.15 | Jetzt anmelden unter: 
www.teamix.de/techdemo


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



Bug#772963: release-notes: cellphone friendly CSS

2015-02-16 Thread Niels Thykier
On 2015-02-17 01:04, Stéphane Blondon wrote:
> I didn't find the arrows icons in the repository in Niels's master
> branch. Do you have directly updated
> /usr/share/xml/docbook/stylesheet/nwalsh?

Hi,

I do not quite have the capacity for tracking this thread right now.
Feel free to continue this one without me and I will catch up when I can.

By all means, please do make a clone/branch on git.debian.org or github
if that will facilitate your work, so you do not stall on me.

Thanks,
~Niels


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



Bug#778597: [PATCH] bootcd: Update "LiveUsbBootStick" Section in FAQ

2015-02-16 Thread Kai Harries
Source: bootcd
Source-Version: 4.05
Tags: patch

Dear Maintainer,

I believe the LiveUsbBootStick section in the FAQ contains an error.
At least I was not able to make it work without a few modifications.
Therefore I have updated the FAQ.bootcd.

Kind regards,

Kai Harries

---
Index: bootcd-4.05/FAQ.bootcd
===
--- bootcd-4.05/FAQ.bootcd
+++ bootcd-4.05/FAQ.bootcd
@@ -195,9 +195,9 @@
sgdisk -n 2:0:+100M -c 2:"partition for iso"   -t 2:8300 /dev/sdx
sgdisk -N 3 -c 3:"unused partition"-t 3:8300 /dev/sdx

# Format partition for iso and mount it
-   mkfs.ext3 /dev/sdx2
+   mkfs.ext2 /dev/sdx2
mkdir -p /mnt/stick
mount /dev/sdx2 /mnt/stick

# install Grub
@@ -211,10 +211,12 @@
 set default=0
 set timeout=5

 menuentry 'bootcd 1' {
+insmod part_gpt
+insmod ext2
 search --file --set root --no-floppy /cdimage_1.iso
-loopback loop /cdimage.iso
+loopback loop /cdimage_1.iso
 linux (loop)/isolinux/vmlinuz root=iso:auto:/cdimage_1.iso
bootcd=standard
 initrd (loop)/isolinux/initrd
 }
 END


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



Bug#778596: php5-gd: imageantialias is still missing

2015-02-16 Thread Vincas Dargis
Package: php5-gd
Version: 5.6.5+dfsg-1
Severity: normal

Dear Maintainer,

Quite some time ago bug #321237 was posted, noting that php5-gd used by Debian
has missing some funtions.

There is a comment (#71) stating that "There is also an ongoing work",
and since Jessie is comming, I have checked if previosly missing
imageantialias() is maybe already implemented, but sadly:

$ php -r "var_dump(function_exists('imageantialias'));" 

  
bool(false)

I have asked about imageantialias() progress in libgd bug tracker:
https://bitbucket.org/libgd/gd-libgd/issue/115/backports-php-internal-functions-to-libgd#comment-13551981
but with no response.

Is there any hope, any possibility to encourage, motivate libgd developers to
have it fixed since Jessie is out? Or it is already too late (because of freeze)
and we will have to recompile php with bundeled libgd for another 2-3 years..?



-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
apache2
cli

 PHP 5 Extensions (php5query -M -v): 
readline (Enabled for apache2 by maintainer script)
readline (Enabled for cli by maintainer script)
json (Enabled for apache2 by maintainer script)
json (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
opcache (Enabled for cli by maintainer script)
gd (Enabled for apache2 by maintainer script)
gd (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pdo (Enabled for cli by maintainer script)

 Configuration files: 
 /etc/php5/mods-available/gd.ini 
extension=gd.so


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

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

Versions of packages php5-gd depends on:
ii  libc6  2.19-13
ii  libfreetype6   2.5.2-2
ii  libgd3 2.1.0-5
ii  libjpeg62-turbo1:1.3.1-11
ii  libpng12-0 1.2.50-2+b2
ii  libvpx11.3.0-3
ii  libx11-6   2:1.6.2-3
ii  libxpm41:3.5.11-1+b1
ii  php5-common [phpapi-20131226]  5.6.5+dfsg-1
ii  ucf3.0030
ii  zlib1g 1:1.2.8.dfsg-2+b1

php5-gd recommends no packages.

php5-gd suggests no packages.

Versions of packages php5-common depends on:
ii  libc6   2.19-13
ii  lsof4.86+dfsg-1
ii  psmisc  22.21-2
ii  sed 4.2.2-4+b1
ii  ucf 3.0030

Versions of packages php5-common suggests:
pn  php5-user-cache  

Versions of packages php5-cli depends on:
ii  libbz2-1.01.0.6-7+b2
ii  libc6 2.19-13
ii  libcomerr21.42.12-1
ii  libdb5.3  5.3.28-7~deb8u1
ii  libedit2  3.1-20140620-2
ii  libgssapi-krb5-2  1.12.1+dfsg-17
ii  libk5crypto3  1.12.1+dfsg-17
ii  libkrb5-3 1.12.1+dfsg-17
ii  libmagic1 1:5.20-2
ii  libonig2  5.9.5-3.2
ii  libpcre3  2:8.35-3.3
ii  libqdbm14 1.8.78-5+b1
ii  libssl1.0.0   1.0.1k-1
ii  libxml2   2.9.1+dfsg1-4
ii  mime-support  3.58
ii  php5-common   5.6.5+dfsg-1
ii  php5-json 1.3.6-1
ii  tzdata2015a-1
ii  ucf   3.0030
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages php5-cli recommends:
ii  php5-readline  5.6.5+dfsg-1

Versions of packages php5-cli suggests:
pn  php-pear  

Versions of packages libapache2-mod-php5 depends on:
ii  apache2 2.4.10-9
ii  apache2-bin [apache2-api-20120211]  2.4.10-9
ii  libbz2-1.0  1.0.6-7+b2
ii  libc6   2.19-13
ii  libcomerr2  1.42.12-1
ii  libdb5.35.3.28-7~deb8u1
ii  libgssapi-krb5-21.12.1+dfsg-17
ii  libk5crypto31.12.1+dfsg-17
ii  libkrb5-3   1.12.1+dfsg-17
ii  libmagic1   1:5.20-2
ii  libonig25.9.5-3.2
ii  libpcre32:8.35-3.3
ii  libqdbm14   1.8.78-5+b1
ii  libssl1.0.0 1.0.1k-1
ii  libstdc++6  4.9.1-19
ii  libxml2 2.9.1+dfsg1-4
ii  mime-support3.58
ii  php5-cli5.6.5+dfsg-1
ii  php5-common 5.6.5+dfsg-1
ii  php5-json   1.3.6-1
ii  tzdata  2015a-1
ii  ucf 3.0030
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages

Bug#777166: Please consider not hard coding the name "Debian" into error messages

2015-02-16 Thread Steve McIntyre
On Fri, Feb 06, 2015 at 06:53:30AM +0100, Christian PERRIER wrote:
>Quoting Phillip Susi (ps...@ubuntu.com):
>> 
>> Recently a new message was added to d-i:
>> 
>>  This machine's firmware has started the installer in UEFI mode but
>>  it looks like there may be existing operating systems already
>>  installed using "BIOS compatibility mode". If you
>>  continue to install Debian in UEFI mode, it might be difficult to
>>  reboot the machine into any BIOS-mode operating systems later.
>> 
>> Please consider replacing "Debian" with `lsb_release -si` or similar
>> so that people installing other distros based on debian don't get a
>> message about a different operating system than the one they are
>> installing.
>
>Doh. That one escaped my attention when this message was added.
>
>We usually avoid hardcoding "Debian" and this is probably one of the
>very rare cases where we failed. The message was added in a bit of a
>hurry recently and that failed to be catched by the review:-(

ACK. Sorry, my fault guys. :-(

>Sadly, I'd prefer us not to change  this now.as it will require
>Yet Another Round of translation updateswhich takes weeks to
>achieve.
>
>I'd prefer something like "If you continue to install in UEFI
>mode, it might be difficult to reboot the machine into any BIOS-mode
>operating systems later" and avoid "the distro" or anything like
>that. The output of "lsb_release -si" is likely to not work.

Works for me, yeah.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra


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



Bug#777647: partman-efi always complains when installing from usb

2015-02-16 Thread Steve McIntyre
On Wed, Feb 11, 2015 at 01:10:02PM -0500, Phillip Susi wrote:
>On 02/11/2015 11:47 AM, Steve McIntyre wrote:
>> Quite, that's exactly how it's meant to work and it's what I've seen
>> in my development and testing. Silly question - is ubiquity trying to
>> run some of the d-i bits in parallel, or something?
>
>That's what I was wondering.  I'm looking at /var/log/partman now and it
>appears that visual.d/35name runs and then I see /bin/perform_recipie
>issue a NEW_PARTITION command to make the ext2 partition ( which will
>later be formatted as fat32 for the esp ), and then the ext4 partition
>for the root and then swap.  Later init.d/50efi runs and "sees" the
>partition that the earlier script "created" even though it has not
>actually been committed to disk yet ( i.e. blkid still sees a blank disk ).
>
>Did we change the ordering in ubuntu or something so that the problem is
>that visual.d has priority 35 but init.d/efi has priority 50 when they
>should run the other order?  I would think that all of the init.d
>scripts would be run before any visual.d scripts though, and the
>priorities just order them within their group.  If that's not the case
>then I guess they simply have the wrong priority.

Hi Phillip!

[ technically I'm on VAC, but my wife's not watching... *grin* ]

Any futher clues on this at all? I have next to no knowledge about how
the Ubuntu installer code uses the d-i packages, which makes it
difficult for me to comment much more.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth


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



Bug#772691: Disc icon not displayed

2015-02-16 Thread Steve McIntyre
Control: tag -1 +pending

On Thu, Feb 05, 2015 at 07:16:22PM +, jnqnfe wrote:
>Control: retitle -1 autorun.inf improvements
>thanks
>
>Updated patch, rebased on latest changes in git

Thanks! I've tweaked things slightly (changing the "install Debian
Gnu/Linux" text appropriately for kfreebsd and hurd!) and pushed this,
so daily and weekly builds will get these changes from now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


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



Bug#778594: git-import-orig fails to merge into packaging branch

2015-02-16 Thread Martin Pitt
Package: git-buildpackage
Version: 0.6.22

Hello,

We use git-buildpackage to maintain the systemd Debian package. I was
just trying to import a new upstream version into the experimental
branch, which fails:

$ git-import-orig  --uscan
gbp:info: Launching uscan...
gbp:info: using ../systemd_219.orig.tar.xz
What is the upstream version? [219] 
gbp:info: Importing '../systemd_219.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is systemd
gbp:info: Upstream version is 219
pristine-tar: committed systemd_219.orig.tar.xz.delta to branch pristine-tar
gbp:info: Merging to 'experimental'
gbp:error: Merge failed, please resolve.

(debian/gbp.conf has "debian-branch = experimental", so that's corrrect).

Now "git status" shows a huge unresolved mess.
http://paste.debian.net/150285/ has the full output, but it looks
like this:

| Changes to be committed:
| 
|   modified:   README
|   modified:   catalog/systemd.catalog
|   modified:   catalog/systemd.fr.catalog
|   new file:   catalog/systemd.pt_BR.catalog
| [...]

These are alright.

| Unmerged paths:
|   (use "git add/rm ..." as appropriate to mark resolution)
| 
|   both modified:   Makefile-man.am
|   both modified:   Makefile.am
|   both modified:   Makefile.in
|   both modified:   NEWS
|   both modified:   TODO
|   both added:  catalog/systemd.pl.catalog
|   both modified:   config.h.in

(lots more)

| Untracked files:
|   (use "git add ..." to include in what will be committed)
| 
|   src/analyze/analyze-verify.h~HEAD
|   src/analyze/analyze-verify.h~upstream_219
|   src/resolve/dns-type.c~HEAD

(lots more)

Before the import-orig, experimental and upstream branches were
identical (except for debian/ of course).

I'll resolve these manually (i. e. rm everything, unpack the
tarball, then git add everything), so the branch on alioth will
probably be ahead when you look at this, so I tar'ed up the local
checkout and put it on

  https://people.debian.org/~mpitt/tmp/systemd-gbp.tar.xz

The original tarball is

 http://www.freedesktop.org/software/systemd/systemd-219.tar.xz

(same error with git-import-orig systemd-219.tar.xz)

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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#778593: [PATCH] bootcd: Update "Burning the image" Section in FAQ

2015-02-16 Thread Kai Harries
Source: bootcd
Source-Version: 4.05
Tags: patch

Dear Maintainer,

it looks like the "Burning the image" section in FAQ.bootcd is
outdated. In the example I have replaced the tool cdrecord by wodim.

Kind regards,

Kai Harries


---
Index: bootcd-4.05/FAQ.bootcd
===
--- bootcd-4.05/FAQ.bootcd
+++ bootcd-4.05/FAQ.bootcd
@@ -164,15 +164,10 @@
 3. Burning the image or creating a liveusbstick

 3.1
 Q: How can I burn the image ?
-A: For cdrom install cdrecord and see man cdrecord(1). Example
- cdrecord -scanbus
- cdrecord dev=0,2,0 -v -eject blank=fast
- cdrecord dev=0,2,0 -v -eject /var/spool/bootcd/cdimage.iso
-   For dvd install package dvd+rw-tools and see man growisofs(1m). Example:
- dvd+rw-format /dev/dvd
- growisofs -dvd-compat -Z /dev/dvd=/var/spool/bootcd/cdimage.iso
+A: Install wodim and see man wodim(1). Example
+ wodim -v -eject /var/spool/bootcd/cdimage.iso

 3.2
 Q: How can I create a floppy ?
 A: If you need to boot from floppy and to save changes made in ram you can


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



Bug#743303: Can help

2015-02-16 Thread Richard Winters
Hello,

I thought I had already replied to this bug - I apologize if I emailed
someone directly on accident.

II use pulseaudio and infact use the bluetooth module all the time.

I'm interested to help out and gain a foot-hold into Debian development -
I'm a c++ developer of over 10 years (I'll admit I'm replying as I'm
heading to the source to see if its even my language) - but can generally
write anything.  Ah, as its C I shouldn't have any problem.

Are you still seeking help?  I have registered on Alioth previou/sly and
will request to join the team

If you need the help, and add me:  Where should I begin (aside from reading
all documentation in the vcs as well as upstream)?

Best,



*Richard B. Winters*


Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Josh Triplett
On Tue, Feb 17, 2015 at 06:59:15AM +0100, Martin Pitt wrote:
> Josh Triplett [2015-02-16 21:49 -0800]:
> > > It does, it's called "Alias=" (man systemd.unit).
> > 
> > Can Alias work together with Conflicts on that alias, such that each of
> > several services all Alias a given virtual service and Conflicts with
> > other providers of that service?  If so, what about using that for
> > systemd-timesyncd and all of the other time services, at least once they
> > all have native service files?
> 
> That's certainly the idea, yes. The Alias= mechanism works a bit
> differently than Provides: on a packaging level; e. g. it must be
> possible to have several of them installed in parallel. So AFAIK
> packages which use this schema need to either systemctl disable
>  first (if they want to set itself as the "selected
> alternative") or not enable itself at all (if they are not the
> "selected alternative").

With a bit of machinery tied into the alternatives mechanism, perhaps
"which of several concurrently installed units are enabled" could be
more easily admin-controllable?

> > > We use it for display-manager already (kind of, as we also have to
> > > support the old /etc/X11/default-display-manager config file).
> > 
> > Also, post-jessie, do you have any plans to do a one-time migration away
> > from that display manager configuration file, similar to the various
> > one-time migrations away from sysvinit-specific config files like
> > /etc/default/rcS?
> 
> I wish we could. But don't forget that we still have to support at
> least SysVinit and perpaps even more (openrc? upstart?). As long as we
> have those, we probably have to keep these uber-complex mechanisms
> like systemd-default-display-manager-generator which sync these
> config files with the systemd unit enablement.

Just because we support other init systems, and migrate user
configuration from those init systems, doesn't necessarily mean the
configuration files have to remain the *same*.  It'd be easy enough to
do a one-time migration of the current value in
/etc/X11/default-display-manager to the set of enabled .service files
for display managers, and let the user know that future changes to that
file will not have any further effect.

Similarly, the current setting in /etc/default/tmpfs for whether to
mount a tmpfs on /tmp gets migrated to
/etc/systemd/system/local-fs.target.wants/tmp.mount , but future changes
to /etc/default/tmpfs have no effect, and that file will one day go away
when systemd no longer depends on initscripts.

(I also have hopes that one day, the sysvinit unit generator can live in
a separate package that systemd just Suggests but does not Depends on.)

- Josh Triplett


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



Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Martin Pitt
Josh Triplett [2015-02-16 21:49 -0800]:
> > Note that openntpd and chrony both have a Provides: time-daemon, but
> > ntp doesn't.
> 
> Interesting.  Any idea why?

No, I don't; probably just an omission. openntpd and chrony both have
an explicit Conflicts: ntp, though.

> > It does, it's called "Alias=" (man systemd.unit).
> 
> Can Alias work together with Conflicts on that alias, such that each of
> several services all Alias a given virtual service and Conflicts with
> other providers of that service?  If so, what about using that for
> systemd-timesyncd and all of the other time services, at least once they
> all have native service files?

That's certainly the idea, yes. The Alias= mechanism works a bit
differently than Provides: on a packaging level; e. g. it must be
possible to have several of them installed in parallel. So AFAIK
packages which use this schema need to either systemctl disable
 first (if they want to set itself as the "selected
alternative") or not enable itself at all (if they are not the
"selected alternative").

> > We use it for display-manager already (kind of, as we also have to
> > support the old /etc/X11/default-display-manager config file).
> 
> Also, post-jessie, do you have any plans to do a one-time migration away
> from that display manager configuration file, similar to the various
> one-time migrations away from sysvinit-specific config files like
> /etc/default/rcS?

I wish we could. But don't forget that we still have to support at
least SysVinit and perpaps even more (openrc? upstart?). As long as we
have those, we probably have to keep these uber-complex mechanisms
like systemd-default-display-manager-generator which sync these
config files with the systemd unit enablement.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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#80123: Interested

2015-02-16 Thread Richard Winters
Hello,

I'm a newbie to debian development, looking to find a spot to settle and
start contributing.

The requested feature I believe I can do with some investigation of the
code and time to get familiar - so not sure if I should go ahead and try or
if I might want to stay away from this particular request?

However, I'm also very interested in the plugin API you have stated would
be a good idea.  I'd be interested to help with that - especially if you
guys would consider a more modern and universal approach (such as JS rather
than LUA).

Please let me know -> I have experience with v8 more specifically ...also
with LUA and with building LUA plug-in systems (though mostly for games).

Please keep in mind all of my extravagant ranting above is
pre-looking-at-any-code.  I'm just  basing my input on the *.cc reference
above.


Best,



*Richard B. Winters*


Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Josh Triplett
On Tue, Feb 17, 2015 at 06:44:28AM +0100, Martin Pitt wrote:
> Josh Triplett [2015-02-16 17:37 -0800]:
> > Seems like systemd could take a lesson from Debian packaging metadata
> > here.  Every mail transport agent, rather than conflicting with every
> > other, has a "Provides: mail-transport-agent" and "Conflicts:
> > mail-transport-agent", specifically because they all want to provide
> > /usr/sbin/sendmail and (usually) listen on port 25.
> 
> Note that openntpd and chrony both have a Provides: time-daemon, but
> ntp doesn't.

Interesting.  Any idea why?

> > Unit files could do something similar, if systemd had an appropriate
> > "virtual service" mechanism.
> 
> It does, it's called "Alias=" (man systemd.unit).

Can Alias work together with Conflicts on that alias, such that each of
several services all Alias a given virtual service and Conflicts with
other providers of that service?  If so, what about using that for
systemd-timesyncd and all of the other time services, at least once they
all have native service files?

> We use it for display-manager already (kind of, as we also have to
> support the old /etc/X11/default-display-manager config file).

Also, post-jessie, do you have any plans to do a one-time migration away
from that display manager configuration file, similar to the various
one-time migrations away from sysvinit-specific config files like
/etc/default/rcS?

- Josh Triplett


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



Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Martin Pitt
Hey Josh,

Josh Triplett [2015-02-16 17:37 -0800]:
> Seems like systemd could take a lesson from Debian packaging metadata
> here.  Every mail transport agent, rather than conflicting with every
> other, has a "Provides: mail-transport-agent" and "Conflicts:
> mail-transport-agent", specifically because they all want to provide
> /usr/sbin/sendmail and (usually) listen on port 25.

Note that openntpd and chrony both have a Provides: time-daemon, but
ntp doesn't.

> Unit files could do something similar, if systemd had an appropriate
> "virtual service" mechanism.

It does, it's called "Alias=" (man systemd.unit). We use it for
display-manager already (kind of, as we also have to support the old
/etc/X11/default-display-manager config file).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Martin Pitt
Hello Eric,

Eric L. [2015-02-17  1:24 +0100]:
> Perhaps just a bit too late for me, but how would package vdr be
> handled, which does _optionally_ set the system clock from the TV
> signal.

Note that not starting timesyncd if ntp etc. are installed is mostly
an optimization, to avoid multiple unnecessary time syncs and wakeups.
But we don't need to be exact here: timesyncd automatically adjusts
the period after which it wakes up and sets the clock based on the
previous inaccuracy. Thus if the clock keeps being correct because
something else sets it regularly, it will hardly ever wake up.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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#778577: CVE-2015-1606 CVE-2015-1607 -- multiple issues found in GnuPG

2015-02-16 Thread Salvatore Bonaccorso
Control: fixed -1 2.1.2-1

Hi Daniel,

On Mon, Feb 16, 2015 at 06:09:18PM -0500, Daniel Kahn Gillmor wrote:
> Several coding errors were discovered in GnuPG 2.0 lately by Hanno Böck
> as part of the Fuzzing Project:

Have you checked if gnupg 1.4.x is also affected by both of these
CVEs? We have marked gnupg as "undetermined" so far in the
security-tracker.

Regards,
Salvatore


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



Bug#778592: libabiword-3.0 : Depends: libical1 (>= 1.0) but it is not installable.

2015-02-16 Thread 積丹尼 Dan Jacobson
Package: libabiword-3.0
Version: 3.0.1-1

The following packages have unmet dependencies:
 libabiword-3.0 : Depends: libical1 (>= 1.0) but it is not installable.


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



Bug#778546: RFS: miceamaze/4.2-1 -- video game with mice in a maze

2015-02-16 Thread Paul Wise
Control: tags -1 + moreinfo

On Mon, Feb 16, 2015 at 10:38 PM, Raphaël Champeimont wrote:

>   miceamaze - video game with mice in a maze

There is one issue that need to be fixed before I will upload the package:

The debian/copyright file needs to be updated for the new copyright
year. It also needs updating for the new files that are under
different licenses or have different copyright holders (data/music/
and data/mazes/maze13.txt). Please note that a full copy of the CC-BY
3.0 license needs to be added to debian/copyright, so offline users
can read the license.

Other thoughts:

On a system with two screens (laptop + external screen), full-screen
mode crosses the two screens which makes the menu hard to read and
cuts part of it off.

In chromium-bsu I was able to get nice anti-aliased text by passing
GLC_TEXTURE to glcRenderStyle, but for some reason that only produces
white squares in miceamaze.

You might want to mention the Standards-Version in debian/changelog.
If you have gone through the upgrading checklist and there aren't any
changes that apply to miceamaze, you can say just "Bump
Standards-Version, no changes needed".

http://www.debian.org/doc/debian-policy/upgrading-checklist

You might want to mention the reason for the Priority change in
debian/changelog.

I would have indented the second debian/changelog item like this:

  * New upstram release 4.2 (Closes: #766820)
- Removed creation timestamp in PNG generation (Closes: #778491)

ttf-dejavu-core is a transitional dummy package, you could depend on
fonts-dejavu-core | ttf-dejavu-core instead.

You may want to work on porting the code to SDL2. chromium-bsu is an
example of a game that supports SDL and SDL2 (in upstream git only).

The debian/patches directory is empty and could be removed.

There are two spelling errors:

$ codespell --quiet-level=3
./src/Functions.h:149: occured  ==> occurred
./src/AIVertex.h:33: colum  ==> column

The include-what-you-use tool (from the iwyu Debian package) suggests
a lot of files that are missing headers for the variables and
functions that they use. I ran this command:

$ find -type f \( -iname '*.c' -o -iname '*.cc' -o -iname '*.cxx' -o
-iname '*.cpp' -o -iname '*.h' -o -iname '*.hh' -o -iname '*.hxx' -o
-iname '*.hpp' \) -exec include-what-you-use {} \;

I would suggest renaming the upstream README.txt file to INSTALL.txt.

The upstream LICENSE.txt still contains details about the
Bitstream/DejaVu license even though that was removed from the source
tarball.

The upstream LICENSE.txt is missing copyright/license info for
maze13.txt, which appears to have been contributed by someone else?

This is a better URL for the Ogg file from ccmixter, I found it in the
metadata of the Ogg file:

http://ccmixter.org/files/George_Ellinas/14073-

The upstream ChangeLog.txt is missing information about versions from
2.1 to 4.2.

You've changed the mouse image and introduced 2 modified copies of it.
This could be problematic if you want to tweak the mouse image or use
different modifications in the future. Personally I would have done it
like this: mouse.png containing the normal mouse image, helmet.png
containing the mouse helmet and sickness.png containing the sickness
pattern. Then at build time you would use imagemagick to overlay the
helmet on the mouse image to create drill_mouse.png and similarly to
create sick_mouse.png. Using SVG for the mouse image would give you
more options for modifying the mouse too.

The Ogg files aren't very modifiable, for example you could not easily
change the drums to different drum or to a sample of someone hitting
two rocks together.

lintian complaints:

P: miceamaze source: debian-watch-may-check-gpg-signature
I: miceamaze: arch-dep-package-has-big-usr-share 12285kB 98%

For the first one, refer to these URLs:

https://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html
https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
https://help.riseup.net/security/message-security/openpgp/best-practices

For the second one, refer to these URLs:

https://lintian.debian.org/tags/arch-dep-package-has-big-usr-share.html

As you are upstream for a game, you may want to look at these:

https://wiki.debian.org/UpstreamGuide
http://www.freedesktop.org/wiki/Games/Upstream/

-- 
bye,
pabs

https://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#765104:

2015-02-16 Thread Adam Baxter
Any updates on this bug? What modifications are needed from upstream?

What impact will using an old version have on compatibility with OS X
systems?


Bug#778591: unblock: pastebinit/1.4-4

2015-02-16 Thread Rolf Leggewie
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pastebinit to allow the fix for
RC-bug 778336 to propagate to testing. Thank you

unblock pastebinit/1.4-3
diff --git a/debian/changelog b/debian/changelog
index 7de6407..b3370f0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+pastebinit (1.4-4) unstable; urgency=medium
+
+  [ Andrew Starr-Bochicchio ]
+  * detect_distro_with_python3.patch: Use platform instead of
+lsb_release to detect the distro as lsb_release is not
+available under Python 3 (Closes: #760341). pastebinit
+will now default again to using paste.debian.net on Debian
+(Closes: #778336).
+
+ -- Rolf Leggewie   Tue, 17 Feb 2015 11:35:07 +0800
+
 pastebinit (1.4-3) unstable; urgency=low
 
   * bump debhelper to version 9
diff --git a/debian/patches/detect_distro_with_python3.patch b/debian/patches/detect_distro_with_python3.patch
new file mode 100644
index 000..e0737c3
--- /dev/null
+++ b/debian/patches/detect_distro_with_python3.patch
@@ -0,0 +1,15 @@
+Index: pastebinit/pastebinit
+===
+--- pastebinit.orig/pastebinit	2015-02-16 12:37:04.434846203 -0500
 pastebinit/pastebinit	2015-02-16 12:39:22.709104460 -0500
+@@ -37,8 +37,8 @@
+ 
+ # Now try to override it with a distributor pastebin
+ try:
+-import lsb_release
+-release = lsb_release.get_distro_information()['ID'].lower()
++import platform
++release = platform.linux_distribution()[0].lower()
+ if release == 'debian':
+ defaultPB = "http://paste.debian.net";
+ elif release == 'fedora':
diff --git a/debian/patches/series b/debian/patches/series
index 986704d..b17e68f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 upstream-r205_r201.patch
 increase_timeout.patch
+detect_distro_with_python3.patch


Bug#751860: Your mail

2015-02-16 Thread Michel Dänzer
On Mon, 10 Nov 2014 11:30:11 -0500 Marc Deslauriers
 wrote:
> I've attached a patch to the upstream bug I've filed about this issue:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=739895

I can confirm your patch fixes the problem, thanks!


Can we get a fixed package uploaded? I think the severity of this bug
should be important at least.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


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



Bug#760341: Bug#778336: pastebinit: fails in the default configuration

2015-02-16 Thread Rolf Leggewie
On 17.02.2015 01:49, Andrew Starr-Bochicchio wrote:
> This could be fixed by fixing #760341 so that pastebinit defaults to
> paste.debian.net The root cause of that is lsb-release doesn't support
> Python 3, breaking the distro detection.
> 
> The attached patch works around that by using platform to detect the
> distribution instead.

Thanks, everyone, especially Andrew.  I'm preparing an upload as we speak.


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



Bug#778567: qt5-default: wrongly in section libs

2015-02-16 Thread Lisandro Damián Nicanor Pérez Meyer
Actually the Qt4 version is on the wrong section. This is really not for
developing.

Anyway I think qtx-default packages will disappear in Strech.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


Bug#778590: ITP: python-curtsies -- terminal wrapper with colored strings

2015-02-16 Thread Sebastian Ramacher
Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 

* Package name: python-curtsies
  Version : 0.1.18
  Upstream Author : Thomas Ballinger
* URL : https://github.com/thomasballinger/curtsies
* License : Expat
  Programming Lang: Python
  Description : library for interacting with the terminal

 Curtsies is a library for interacting with the terminal. It features
 string-like objects which carry formatting information, per-line fullscreen
 terminal rendering, and keyboard input event reporting.

bpython 0.13 introduced a new frontend based on curtsies and bpython
0.14 switched the default frontend to it.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature


Bug#778589: ITP: express -- Streaming quantification for high-throughput sequencing

2015-02-16 Thread Michael Crusoe
Package: wnpp
Severity: wishlist
Owner: Debian Med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: express
  Version : 1.5.1
  Upstream Author : Adam Roberts & Lior Pachter 
* URL : http://bio.math.berkeley.edu/eXpress/index.html
* License : Artistic-2.0
  Programming Lang: C++
  Description : Streaming quantification for high-throughput sequencing

eXpress is a streaming tool for quantifying the abundances of a set of
 target sequences from sampled subsequences. Example applications include
 transcript-level RNA-Seq quantification, allele-specific/haplotype
 expression analysis (from RNA-Seq), transcription factor binding
 quantification in ChIP-Seq, and analysis of metagenomic data. It is
 based on an online-EM algorithm that results in space (memory)
 requirements proportional to the total size of the target sequences and
 time requirements that are proportional to the number of sampled
 fragments. Thus, in applications such as RNA-Seq, eXpress can accurately
 quantify much larger samples than other currently available tools
 greatly reducing computing infrastructure requirements. eXpress can be
 used to build lightweight high-throughput sequencing processing
 pipelines when coupled with a streaming aligner (such as Bowtie), as
 output can be piped directly into eXpress, effectively eliminating the
 need to store read alignments in memory or on disk.
 .
 In an analysis of
 the performance of eXpress for RNA-Seq data, we have observed that this
 efficiency does not come at a cost of accuracy. eXpress is more accurate
 than other available tools, even when limited to smaller datasets that
 do not require such efficiency. Moreover, like the Cufflinks program,
 eXpress can be used to estimate transcript abundances in multi-isoform
 genes. eXpress is also able to resolve multi-mappings of reads across
 gene families, and does not require a reference genome so that it can be
 used in conjunction with de novo assemblers such as Trinity, Oases, or
 Trans-ABySS. The underlying model is based on previously described
 probabilistic models developed for RNA-Seq but is applicable to other
 settings where target sequences are sampled, and includes parameters for
 fragment length distributions, errors in reads, and sequence-specific
 fragment bias.
 .
 eXpress can be used to resolve ambiguous mappings in other
 high-throughput sequencing based applications. The only required inputs
 to eXpress are a set of target sequences and a set of sequenced
 fragments multiply-aligned to them.  While these target sequences will
 often be gene isoforms, they need not be. Haplotypes can be used as the
 reference for allele-specific expression analysis, binding regions for
 ChIP-Seq, or target genomes in metagenomics experiments. eXpress is
 useful in any analysis where reads multi-map to sequences that differ in
 abundance.

Express is a dependency of trinityrnaseq. The Debian Med team will be group
maintaining it.


Bug#778573: xorg: Xorg shows blank black screen at startup instead of a Display Manager.

2015-02-16 Thread Kevin McKinley
I see you have the nouveau driver loaded, indicating you have nvidia
hardware.

This is the same symptom I reported using the nvidia driver in bug
#775012.

I can disable the display manager and boot to a console, then use
startx to get a KDE session.

Kevin

On Mon, 16 Feb 2015 16:27:22 -0500
Matthew Trescott  wrote:

> Package: xorg
> Version: 1:7.7+3~deb7u1
> 
> 
> 
> Dear Maintainer,
> 
>* What led up to the situation? A system update which included an
> update for xorg
>* What exactly did you do (or not do) that was effective (or
> ineffective)? I attempted to switch to a different Display Manager.
>* What was the outcome of this action? Nothing changed.
>* What outcome did you expect instead? I hoped that the problem
> was with gdm3.
> 
> 
> 
> -- System Information:
> Debian Release: 7.8
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages xorg depends on:
> ii  gnome-terminal [x-terminal-emulator]  3.4.1.1-2
> ii  konsole [x-terminal-emulator] 4:4.8.4-2
> ii  libgl1-mesa-dri   8.0.5-4+deb7u2
> ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u2
> ii  libglu1-mesa  8.0.5-4+deb7u2
> ii  lxterminal [x-terminal-emulator]  0.1.11-4
> pn  x11-apps  
> pn  x11-session-utils 
> ii  x11-utils 7.7~1
> pn  x11-xfs-utils 
> ii  x11-xkb-utils 7.7~1
> ii  x11-xserver-utils 7.7~3
> ii  xauth 1:1.0.7-1
> ii  xfonts-100dpi 1:1.0.3
> ii  xfonts-75dpi  1:1.0.3
> ii  xfonts-base   1:1.0.3
> ii  xfonts-scalable   1:1.0.3-1
> ii  xfonts-utils  1:7.7~1
> pn  xinit 
> ii  xkb-data  2.5.1-3
> ii  xorg-docs-core1:1.6-1
> ii  xserver-xorg  1:7.7+3~deb7u1
> ii  xterm [x-terminal-emulator]   278-4
> 
> xorg recommends no packages.
> 
> Versions of packages xorg suggests:
> pn  xorg-docs  
> 
> Versions of packages xserver-xorg depends on:
> ii  libc6
> 2.13-38+deb7u7 ii
> x11-xkb-utils 7.7~1 ii
> xkb-data  2.5.1-3 ii
> xserver-xorg-core
> 2:1.12.4-6+deb7u6 ii
> xserver-xorg-input-all1:7.7+3~deb7u1
> ii  xserver-xorg-input-evdev [xorg-driver-input]
> 1:2.7.0-1+b1 ii  xserver-xorg-input-mouse
> [xorg-driver-input]  1:1.7.2-3 ii
> xserver-xorg-input-synaptics [xorg-driver-input]  1.6.2-2 ii
> xserver-xorg-input-vmmouse [xorg-driver-input]1:12.9.0-1 ii
> xserver-xorg-input-wacom [xorg-driver-input]
> 0.15.0+20120515-2 ii
> xserver-xorg-video-all1:7.7+3~deb7u1
> ii  xserver-xorg-video-apm [xorg-driver-video]1:1.2.3-3
> ii  xserver-xorg-video-ark [xorg-driver-video]
> 1:0.7.4-1+b1 ii  xserver-xorg-video-ati
> [xorg-driver-video]1:6.14.4-8 ii
> xserver-xorg-video-chips [xorg-driver-video]  1:1.2.4-2 ii
> xserver-xorg-video-cirrus [xorg-driver-video] 1:1.4.0-2 ii
> xserver-xorg-video-fbdev [xorg-driver-video]  1:0.4.2-4+b3
> ii  xserver-xorg-video-i128 [xorg-driver-video]
> 1:1.3.5-1+b1 ii  xserver-xorg-video-intel
> [xorg-driver-video]  2:2.19.0-6 ii  xserver-xorg-video-mach64
> [xorg-driver-video] 6.9.1-2 ii  xserver-xorg-video-mga
> [xorg-driver-video]1:1.5.0-3 ii
> xserver-xorg-video-neomagic [xorg-driver-video]   1:1.2.6-1 ii
> xserver-xorg-video-nouveau [xorg-driver-video]1:1.0.1-5 ii
> xserver-xorg-video-openchrome [xorg-driver-video]
> 1:0.2.906-2+deb7u1 ii  xserver-xorg-video-r128
> [xorg-driver-video]   6.8.2-1 ii  xserver-xorg-video-radeon
> [xorg-driver-video] 1:6.14.4-8 ii
> xserver-xorg-video-rendition [xorg-driver-video]  1:4.2.4-3 ii
> xserver-xorg-video-s3 [xorg-driver-video] 1:0.6.3-5 ii
> xserver-xorg-video-s3virge [xorg-driver-video]1:1.10.4-5 ii
> xserver-xorg-video-savage [xorg-driver-video] 1:2.3.4-1 ii
> xserver-xorg-video-siliconmotion [xorg-driver-video]  1:1.7.6-1 ii
> xserver-xorg-video-sis [xorg-driver-video]1:0.10.4-1 ii
> xserver-xorg-video-sisusb [xorg-driver-video] 1:0.9.4-3 ii
> xserver-xorg-video-tdfx [xorg-driver-video]   1:1.4.4-1 ii
> xserver-xorg-video-trident [xorg-driver-video]1:1.3.5-1 ii
> xserver-xorg-video-tseng [xorg-driver-video]  1:1.2.4-3 ii
> xserver-xorg-video-vesa [xorg-driver-video]   1

Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Vincent Lefevre
On 2015-02-17 03:21:16 +0100, Sebastian Ramacher wrote:
> On 2015-02-17 03:18:01, Vincent Lefevre wrote:
> > > Not on my machine:
> > > 
> > > xvii:~> ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so 
> > > /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> > > libgcrypt.so.11 => not found
> > > libgcrypt.so.11 => not found
> > 
> > The cause may be that I have the libmtp library installed in
> > /usr/local/lib.

Since this built was done against an old libgcrypt (no longer
installed), I suppose that the installation was obsolete, and
I've removed the files that were installed at that time. But
VLC still crashes.

> Do you have any other libraries there that are used by vlc / libav?

No, now /usr/local/lib no longer contains any file.

I've patched and rebuilt some Debian packages, but libpaps0 is
the only library, and I don't think it affects VLC.

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


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



Bug#778588: linux-tools: build fails with linux-3.19 sources

2015-02-16 Thread Luca Boccassi
Package: src:linux-tools
Version: 3.18.5-1~exp1
Severity: important
Tags: patch

Dear Maintainer,

As linux-image-3.19.0-* packages are available in experimental but
linux-kbuild-3.19 is not yet in the repositories, I tried to build it manually
following the guide at 
https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage
but I encountered a couple of problems that break the build.

Hoping that it can be useful, I am attaching the patch I diff'ed against the
latest version of the repo: svn://svn.debian.org/kernel/dists/trunk/linux-tools

The problems encountered are:

- The patch tools-perf-version.patch does not apply cleanly due to upstream
changes
- lib/hweight.c must be copied by debian/bin/genorig.py as it is needed to build
- x86_64 specific: perf does not build, fix taken from lkml (has not been
committed as of now) and used to create a new Quilt patch, link to the upstream
mail: https://lkml.org/lkml/2015/2/13/55

Kind regards,
Luca Boccassi

Index: debian/bin/genorig.py
===
--- debian/bin/genorig.py   (revision 22391)
+++ debian/bin/genorig.py   (working copy)
@@ -146,6 +146,7 @@
 'arch/x86/lib/memset_64.S',
 'include/',
 'lib/rbtree.c',
+'lib/hweight.c',
 'scripts/',
 'tools/',
 )
Index: debian/patches/perf-fix-building-error-in-x86_64.patch
===
--- debian/patches/perf-fix-building-error-in-x86_64.patch  (revision 0)
+++ debian/patches/perf-fix-building-error-in-x86_64.patch  (working copy)
@@ -0,0 +1,27 @@
+From: He Kuang 
+Date: Fri, 13 Feb 2015 15:11:14 +0800
+Subject: [PATCH v2] perf: fix building error in x86_64
+
+When build with ARCH=x86_64, perf failed to compile with following error:
+
+tests/builtin-test.o:(.data+0x158): undefined reference to 
`test__perf_time_to_tsc'
+collect2: error: ld returned 1 exit status
+Makefile.perf:632: recipe for target 'perf' failed
+...
+
+Which is caused commit c6e5e9fbc3ea1 ("perf tools: Fix building error
+in x86_64 when dwarf unwind is on"), ARCH test in Makefile.perf
+conflicts with tests/builtin-test.c's __x86_64__.
+To x86/x86_64 platform, ARCH should always override to x86 while
+IS_64_BIT stands for the actual architecture.
+
+--- a/tools/perf/config/Makefile.arch
 b/tools/perf/config/Makefile.arch
+@@ -29,3 +29,7 @@
+ else
+   IS_64_BIT := 0
+ endif
++
++ifeq ($(ARCH), x86_64)
++  override ARCH := x86
++endif
Index: debian/patches/series
===
--- debian/patches/series   (revision 22391)
+++ debian/patches/series   (working copy)
@@ -4,3 +4,4 @@
 usbip-document-tcp-wrappers.patch
 kbuild-fix-recordmcount-dependency.patch
 usbip-include-uninstalled-linux-usbip-h.patch
+perf-fix-building-error-in-x86_64.patch
Index: debian/patches/tools-perf-version.patch
===
--- debian/patches/tools-perf-version.patch (revision 22391)
+++ debian/patches/tools-perf-version.patch (working copy)
@@ -9,7 +9,7 @@
 
 --- a/tools/perf/Makefile.perf
 +++ b/tools/perf/Makefile.perf
-@@ -833,8 +833,8 @@ install-gtk:
+@@ -923,8 +923,8 @@ install-gtk:
  install-bin: all install-gtk
$(call QUIET_INSTALL, binaries) \
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'; \
@@ -17,10 +17,10 @@
 -  $(LN) '$(DESTDIR_SQ)$(bindir_SQ)/perf' 
'$(DESTDIR_SQ)$(bindir_SQ)/trace'
 +  $(INSTALL) $(OUTPUT)perf 
'$(DESTDIR_SQ)$(bindir_SQ)/perf_$(VERSION)'; \
 +  $(LN) '$(DESTDIR_SQ)$(bindir_SQ)/perf_$(VERSION)' 
'$(DESTDIR_SQ)$(bindir_SQ)/trace_$(VERSION)'
-   $(call QUIET_INSTALL, libexec) \
-   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)'
-   $(call QUIET_INSTALL, perf-archive) \
-@@ -857,7 +857,7 @@ ifndef NO_LIBPYTHON
+ ifndef NO_PERF_READ_VDSO32
+   $(call QUIET_INSTALL, perf-read-vdso32) \
+   $(INSTALL) $(OUTPUT)perf-read-vdso32 
'$(DESTDIR_SQ)$(bindir_SQ)';
+@@ -957,7 +957,7 @@ ifndef NO_LIBPYTHON
  endif
$(call QUIET_INSTALL, perf_completion-script) \
$(INSTALL) -d -m 755 
'$(DESTDIR_SQ)$(sysconfdir_SQ)/bash_completion.d'; \
@@ -29,7 +29,7 @@
$(call QUIET_INSTALL, tests) \
$(INSTALL) -d -m 755 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests'; \
$(INSTALL) tests/attr.py 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests'; \
-@@ -871,7 +871,7 @@ install-python_ext:
+@@ -971,7 +971,7 @@ install-python_ext:
  
  # 'make install-doc' should call 'make -C Documentation install'
  $(INSTALL_DOC_TARGETS):


signature.asc
Description: Digital signature


Bug#778487: s3ql: Needs python-dugong >= 3.4

2015-02-16 Thread Nikolaus Rath
On Feb 16 2015, Mika Pflüger  wrote:
> Hi Nikolaus,
>
> Am Mon, 16 Feb 2015 09:42:57 -0800
> schrieb Nikolaus Rath :
>
>> > So please tighten the dependencies of s3ql 2.13 to require
>> > python3-dugong >= 3.4
>> 
>> At least according to
>> https://packages.debian.org/source/unstable/s3ql, this is exactly
>> what the dependency is.
>
> That shows the dependencies of the s3ql source package (I guess that's
> build dependencies, but I'm not sure about that). The dependencies of
> the s3ql binary packages are found at
> https://packages.debian.org/sid/s3ql
> and as you can see, there is no version specified for python3-dugong. I
> think the ${python3:Depends} does not  expand to versioned dependencies
> by default. The dh_python3 man page says:
> "If the pydist file contains PEP386 flag or set of (uscan like) rules,
> dh_python3 will make the depedency versioned (version requirements are
> ignored by default)."
> So I guess dh_python3 needs a pydist file or a py3dist-overrides file.
> Adding debian/s3ql.pydist with the contents
> dugong python3-dugong; PEP386
> did not do the trick for me, maybe I'm reading the manpage wrong.
> However; I couldn't test building in a clean environment because
> building s3ql failed for me (with and without the pydist file) in an
> unstable pbuilder. I still think a proper pydist file should work.

The above didn't work in a clean chroot for me either (but the
build succeeds). But I agree that it should work that way. I'll look
into it.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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


signature.asc
Description: PGP signature


Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Sebastian Ramacher
On 2015-02-17 03:18:01, Vincent Lefevre wrote:
> On 2015-02-17 03:05:34 +0100, Vincent Lefevre wrote:
> > On 2015-02-17 02:33:37 +0100, Sebastian Ramacher wrote:
> > > That looks weird. The Debian package is linked against libgcrypt.so.20:
> > > 
> > > $ ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so \
> > > /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> > > libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> > > (0x7f58c7e7e000)
> > > libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> > > (0x7fc14dfd3000)
> > 
> > Not on my machine:
> > 
> > xvii:~> ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so 
> > /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> > libgcrypt.so.11 => not found
> > libgcrypt.so.11 => not found
> 
> The cause may be that I have the libmtp library installed in
> /usr/local/lib.

Do you have any other libraries there that are used by vlc / libav?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature


Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Vincent Lefevre
On 2015-02-17 03:05:34 +0100, Vincent Lefevre wrote:
> On 2015-02-17 02:33:37 +0100, Sebastian Ramacher wrote:
> > That looks weird. The Debian package is linked against libgcrypt.so.20:
> > 
> > $ ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so \
> > /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> > libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> > (0x7f58c7e7e000)
> > libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> > (0x7fc14dfd3000)
> 
> Not on my machine:
> 
> xvii:~> ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so 
> /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> libgcrypt.so.11 => not found
> libgcrypt.so.11 => not found

The cause may be that I have the libmtp library installed in
/usr/local/lib. The reason is that Debian's MTP support has
been broken for years:

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

(though that's a long time I have not tried).

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


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



Bug#778587: ITP: r-cran-blockmodeling -- Generalized and classical blockmodeling of valued networks

2015-02-16 Thread Michael Crusoe
Package: wnpp
Severity: wishlist
Owner: Debian Med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: r-cran-blockmodeling
  Version : 0.1.8
  Upstream Author : Ales Ziberna 
* URL :
http://cran.fhcrc.org/web/packages/blockmodeling/index.html
* License : GPL-2+
  Programming Lang: R, Fortran
  Description : Generalized and classical blockmodeling of valued
networks

This R package is primarly meant as an implementation of Generalized
 blockmodeling for valued networks. In addition, measurese of similarity or
 dissimilarity based on structural equivalence and regular equivalence (REGE
 algorithem) can be computed and partitioned matrices can be ploted.

r-cran-blockmodeling is a dependency of r-bioc-ebseq. It is group maintained
by the Debian Med team.


Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Vincent Lefevre
On 2015-02-17 02:33:37 +0100, Sebastian Ramacher wrote:
> That looks weird. The Debian package is linked against libgcrypt.so.20:
> 
> $ ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so \
> /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
> libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> (0x7f58c7e7e000)
> libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
> (0x7fc14dfd3000)

Not on my machine:

xvii:~> ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so 
/usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
libgcrypt.so.11 => not found
libgcrypt.so.11 => not found

> Do you really have the Debian packages installed or are they taken from
> somwhere else?

They come from the Debian packages:

xvii:~> dlocate /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so
vlc-nox: /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so
xvii:~> dlocate /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so
vlc-nox: /usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so
xvii:~> apt-show-versions -a vlc-nox
vlc-nox:amd64 2.2.0~rc2-2 install ok installed
vlc-nox:amd64 2.0.3-5+deb7u1wheezy   ftp.fr.debian.org
vlc-nox:amd64 2.0.3-5+deb7u2+b1 wheezy   security.debian.org
vlc-nox:amd64 2.2.0~rc2-2   testing  ftp.fr.debian.org
vlc-nox:amd64 2.2.0~rc2-2   unstable ftp.fr.debian.org
No experimental version
vlc-nox:amd64/testing 2.2.0~rc2-2 uptodate
vlc-nox:i386 2.0.3-5+deb7u1wheezy   ftp.fr.debian.org
vlc-nox:i386 2.0.3-5+deb7u2+b1 wheezy   security.debian.org
vlc-nox:i386 2.2.0~rc2-2   testing  ftp.fr.debian.org
vlc-nox:i386 2.2.0~rc2-2   unstable ftp.fr.debian.org
No experimental version
vlc-nox:i386 not installed

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


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



Bug#738286: Fix autologin to use getty

2015-02-16 Thread Daniel Dickinson (SysAdmin)
Ok,

I had a system crash but I was able to find the configs I used for this.
 It only applies to sysvinit in the form I did it.

I modifed the file lib/live/config/0170-sysvinit so that it has the
following:


In function Configure_sysvinit:

# Configure autologin
sed -i -e "s|^\([^:]*:[^:]*[^:]*\):\(.*getty\) \(.*getty\) \(.*\)$|\1:\2
${LIVE_USERNAME:+-a $LIVE_USERNAME }\3|" /etc/inittab

Sorry, for taking so long, in part I thought I had at least already
posted this part of the details, but apparently not.

I'm unlikely to actually have the chance to make a patch anytime soon
though.

Regards,

Daniel


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



Bug#778586: ITP: r-bioc-ebseq -- R package for RNA-Seq Differential Expression Analysis

2015-02-16 Thread Michael Crusoe
Package: wnpp
Severity: wishlist
Owner: Debian Med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: r-bioc-ebseq
  Version : 1.6.0
  Upstream Author : Ning Leng 
* URL : https://www.biostat.wisc.edu/~kendzior/EBSEQ/
* License : Artistic-2.0
  Programming Lang: R
  Description : R package for RNA-Seq Differential Expression Analysis

r-bioc-ebseq is an R package for identifying genes and isoforms
differentially
 expressed (DE) across two or more biological conditions in an RNA-seq
 experiment.

EBSeq is an important program used in many bioinformatics pipelines. It is a
dependency of the Trinity RNASeq assembler (trinityrnaseq). This package
will
be group maintained by the Debian Med team.
~


Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Josh Triplett
On Tue, Feb 17, 2015 at 12:52:20AM +0100, Michael Biebl wrote:
> Am 17.02.2015 um 00:27 schrieb Josh Triplett:
> > On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt  wrote:
> >> For jessie+1/experimental onward, we'll fix this properly by enabling
> >> timesyncd by default. It won't start if ntp or similar are installed.
> >> This will make sure that the hw clock will be updated often enough,
> >> and we won't poke false data into it:
> >>
> >>   
> >> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326
> > 
> > Using ConditionFileIsExecutable on specific NTP daemons seems odd here.
> > Doesn't systemd already have a mechanism for choosing from multiple
> > alternative implementations of a given feature, automatically running
> > only one of them?  If not, perhaps it should; that same mechanism would
> > then work for display managers, web servers, etc.
> 
> Sort of. The plan here is, that the individual ntp implementations ship
> a native systemd unit file, which has
> Conflicts=systemd-timesyncd.service [1]
> 
> This will make sure, that if e.g. ntp is installed and enabled, ntp will
> be used instead of systemd-timesyncd.
> 
> None of the ntp implementations currently ship such a native unit file
> though, that's why we decided to add such a Condition to the
> systemd-timesyncd.service unit file for the time being.
> 
> There were concerns that adding this Conflicts to every time
> synchronization service is a questionable approach [2].

Seems like systemd could take a lesson from Debian packaging metadata
here.  Every mail transport agent, rather than conflicting with every
other, has a "Provides: mail-transport-agent" and "Conflicts:
mail-transport-agent", specifically because they all want to provide
/usr/sbin/sendmail and (usually) listen on port 25.

Unit files could do something similar, if systemd had an appropriate
"virtual service" mechanism.  That would then allow the simultaneous
installation of several services that need a conflicting set of
resources (for instance, several services that all need to listen on the
same port), leaving it to the sysadmin to determine which one to enable,
and automatically disabling all the rest.  Some integration with
Debian's alternative mechanism could ensure that the currently enabled
listener on port 25 always matches the provider of /usr/sbin/sendmail.

Time synchronization services need to conflict as well, not necessarily
because they all listen on the same port, but because they all want to
control the system clock, and only one should do so.  A simple "named
resource" mechanism, and some collaboration to agree on common names for
such resources (similar to names for virtual packages) would solve that.

Likewise, display managers could all coexist and install appropriate
unit files, but provide and conflict with a virtual service representing
their control of the display, forcing at most one to run at once.

Does that sound plausible?

- Josh Triplett


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



Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Sebastian Ramacher
Hi Vincent

On 2015-02-17 02:18:54, Vincent Lefevre wrote:
> [00cfeea8] core libvlc debug: loading plugins cache file 
> /usr/lib/vlc/plugins/plugins.dat
> [00cfeea8] core libvlc debug: recursively browsing 
> `/usr/lib/vlc/plugins'
> [00cfeea8] core libvlc warning: cannot load module 
> `/usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so' (libgcrypt.so.11: 
> cannot open shared object file: No such file or directory)
> [00cfeea8] core libvlc warning: cannot load module 
> `/usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so' (libgcrypt.so.11: 
> cannot open shared object file: No such file or directory)

That looks weird. The Debian package is linked against libgcrypt.so.20:

$ ldd -r /usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so \
/usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so | grep gcrypt
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f58c7e7e000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fc14dfd3000)


Do you really have the Debian packages installed or are they taken from
somwhere else?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature


Bug#776172: vlc: crash (segmentation fault) on a webm file

2015-02-16 Thread Vincent Lefevre
On 2015-02-16 19:03:32 +0100, Sebastian Ramacher wrote:
> On 2015-02-15 00:46:46, Vincent Lefevre wrote:
> > Another test: I start "vlc Nosferatu*.webm", then select the 3x speed
> > via a click on the speed area at the bottom, then do a sequence of
> > stop/play until a crash. The first 3 times, VLC crashed immediately
> > after a "play" in the first 5 iterations. The 4th time, I did a
> > sequence of several dozens of stop/play, but couldn't make it crash.
> > The 5th time, VLC crashed at the 7th iteration. The 6th time, VLC
> > crashed at the 6th iteration.
> 
> Nope, cannot get it to crash.

This may depend on some context. For the first time on my machine,
"vlc Nosferatu_a_Venezia_-_Pelicula_Completa_audio_espa_ol.webm"
crashed almost immediately, i.e. at normal speed!

> Please also include the output of vlc -vvv.

Attached.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[00cfeea8] core libvlc debug: VLC media player - 2.2.0-rc2 Weatherwax
[00cfeea8] core libvlc debug: Copyright © 1996-2014 the VideoLAN team
[00cfeea8] core libvlc debug: revision 2.2.0-rc1-118-g22fda39
[00cfeea8] core libvlc debug: configured with ./configure  
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' '--localstatedir=/var' 
'--libdir=${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-dependency-tracking' 
'--build=x86_64-linux-gnu' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 
'LDFLAGS=-Wl,-z,relro' '--config-cache' '--disable-maintainer-mode' 
'--disable-silent-rules' '--disable-update-check' '--enable-fast-install' 
'--prefix=/usr' '--docdir=/usr/share/doc/vlc-nox' '--libdir=/usr/lib' 
'--sysconfdir=/etc' '--with-binary-version=2' '--enable-a52' '--enable-aa' 
'--enable-bluray' '--enable-bonjour' '--enable-caca' '--enable-chromaprint' 
'--enable-dbus' '--enable-dca' '--enable-directfb' '--enable-dvbpsi' 
'--enable-dvdnav' '--enable-faad' '--enable-flac' '--enable-fluidsynth' 
'--enable-freerdp' '--enable-freetype' '--enable-fribidi' '--enable-gles1' 
'--enable-gles2' '--enable-glx' '--enable-gnutls' '--enable-jack' 
'--enable-kate' '--enable-libass' '--enable-libmpeg2' '--enable-libxml2' 
'--enable-lirc' '--enable-live555' '--enable-mad' '--enable-mkv' '--enable-mod' 
'--enable-mpc' '--enable-mtp' '--enable-mux_ogg' '--enable-ncurses' 
'--enable-notify' '--enable-ogg' '--enable-opus' '--enable-pulse' '--enable-qt' 
'--enable-realrtsp' '--enable-samplerate' '--enable-schroedinger' 
'--enable-sdl' '--enable-sftp' '--enable-shine' '--enable-shout' 
'--enable-skins2' '--enable-smbclient' '--enable-speex' '--enable-svg' 
'--enable-taglib' '--enable-theora' '--enable-twolame' '--enable-upnp' 
'--enable-vcdx' '--enable-vdpau' '--enable-vnc' '--enable-vorbis' 
'--enable-x264' '--enable-zvbi' 
'--with-kde-solid=/usr/share/kde4/apps/solid/actions/' '--disable-decklink' 
'--disable-dxva2' '--disable-fdkaac' '--disable-gnomevfs' '--disable-goom' 
'--disable-libtar' '--disable-mfx' '--disable-opencv' '--disable-projectm' 
'--disable-sndio' '--disable-svgdec' '--disable-telx' '--disable-vpx' 
'--disable-vsxu' '--disable-wasapi' '--enable-alsa' '--enable-atmo' 
'--enable-dc1394' '--enable-dv1394' '--enable-linsys' '--enable-omxil' 
'--enable-udev' '--enable-v4l2' '--enable-libva' '--enable-vcd' '--disable-oss' 
'--enable-crystalhd' '--enable-mmx' '--enable-sse' '--disable-neon' 
'--disable-altivec' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security' 'CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security' 'build_alias=x86_64-linux-gnu' 'OBJCFLAGS=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security'
[00cfeea8] core libvlc debug: searching plug-in modules
[00cfeea8] core libvlc debug: loading plugins cache file 
/usr/lib/vlc/plugins/plugins.dat
[00cfeea8] core libvlc debug: recursively browsing 
`/usr/lib/vlc/plugins'
[00cfeea8] core libvlc warning: cannot load module 
`/usr/lib/vlc/plugins/access/libaccess_mtp_plugin.so' (libgcrypt.so.11: cannot 
open shared object file: No such file or directory)
[00cfeea8] core libvlc warning: cannot load module 
`/usr/lib/vlc/plugins/services_discovery/libmtp_plugin.so' (libgcrypt.so.11: 
cannot open shared object file: No such file or directory)
[00cfeea8] core libvlc debug: saving plugins cache 
/usr/lib/vlc/plugins/plugins.dat
[00cfeea8] core libvlc debug: plug-ins loaded: 452 modules
[00cfeea8] core libvlc debug: opening config file 
(/home/vinc17/.config/vlc/vlcrc)
[00cfeea8] core libvlc debug: translation test: code is "C"
[00cfeea8] core libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2 
SSE3 SSSE3 SSE4.1 FPU 
[00d2b078] core input debug: Creating an input for 'Media Library'
[00d2b078] cor

Bug#778583: embedded jquery.scrollTo.js available as package

2015-02-16 Thread W. Martin Borgert
Package: dispcalgui
Version: 2.5.0.0-1
Severity: normal

Please consider removing jquery.scrollTo.js from your package
and depending on libjs-jquery-scrollto instead. Thanks!


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



Bug#778584: embedded jquery.scrollTo.js available as package

2015-02-16 Thread W. Martin Borgert
Package: python-weberror
Version: 0.10.3+dfsg-1
Severity: normal

Please consider removing jquery.scrollTo.js from your package
and depending on libjs-jquery-scrollto instead. Thanks!


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



Bug#778582: embedded jquery.scrollTo.js available as package

2015-02-16 Thread W. Martin Borgert
Package: chef-server-webui
Version: 10.12.0+dfsg-1
Severity: normal

Please consider removing jquery.scrollTo.js from your package
and depending on libjs-jquery-scrollto instead. Thanks!


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



Bug#778510: dnsutils: Please include edns-client-subnet patch to dig

2015-02-16 Thread Wilmer van der Gaast

Hello,

I had never really considered submitting this patch to Debian though I 
like the idea.


Note that recent versions of BIND (IIRC including BIND9) have this patch 
on board already by the way, though with the flag renamed to something 
else. I forgot what. 
http://www.zytrax.com/books/dns/ch7/bind9-features.html suggests +subnet=


So maybe for compatibility you want to use that. I should maybe update 
the patches.



Wilmer van der Gaast.

--
+ .''`. - -- ---+  +- -- ---  - --+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---+  +-- -  --- -- -+


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



Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Eric L.
Hi,

On 17 February 2015 00:52:20 CET, Michael Biebl  wrote:
>Sort of. The plan here is, that the individual ntp implementations ship
>a native systemd unit file, which has
>Conflicts=systemd-timesyncd.service [1]
>
>This will make sure, that if e.g. ntp is installed and enabled, ntp
>will
>be used instead of systemd-timesyncd.
>
>None of the ntp implementations currently ship such a native unit file
>though, that's why we decided to add such a Condition to the
>systemd-timesyncd.service unit file for the time being.
>
>There were concerns that adding this Conflicts to every time
>synchronization service is a questionable approach [2].
>
>Arguably, for ntp, chrony and openntpd, we can solve this on a
>packaging
>level, by making those packages conflict.
>
>If we want to enable timesyncd by default and keep it as a part of the
>systemd package, this approach doesn't work, and we need the Conflicts=
>on the systemd unit level.
Perhaps just a bit too late for me, but how would package vdr be handled, which 
does _optionally_ set the system clock from the TV signal.
Eric

-- 
I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no 
need to CC me on these lists. Thanks!


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



Bug#778348: [release-notes] release-notes:document security status for libv8/nodejs in jessie - added missing tag

2015-02-16 Thread Stephan Beck
Package: release-notes


Hi,

I added a missing tag twice and revised punctuation.
What I don't know is if the occurrence of "jessie" requires another tag to be
inserted.

Please find attached the diff of the patch as
0002-en-issues-Document-lack-of-security-support-for-Node.patch

Good night

Stephan Beck




Index: /home/knoppix/project3/0001-en-issues-Document-lack-of-security-support-for-Node.patch
===
--- /home/knoppix/project3/0001-en-issues-Document-lack-of-security-support-for-Node.patch	(Revision 1)
+++ /home/knoppix/project3/0001-en-issues-Document-lack-of-security-support-for-Node.patch	(Arbeitskopie)
@@ -1,4 +1,4 @@
->From b4a2d1c275bf871705d53b4861c1dd26f568f2c8 Mon Sep 17 00:00:00 2001
+>From b4a2d1c275bf871705d53b4861c1dd26f568f2c8 Mon Sep 17 00:00:00 2001
 From: nthykier 
 Date: Mon, 16 Feb 2015 08:07:01 +
 Subject: [PATCH 1/2] en/issues: Document lack of security support for Node.js
@@ -24,10 +24,10 @@
  
  
 +
-+Lack of security support for the ecosystem around libv8 and Node.js
++Lack of security support for the ecosystem around libv8 and Node.js
 +
-+   The Node.js platform is built on top of libv8, which receives a
-+   high volume of security issues but there are currently no
++   The Node.js platform is built on top of libv8, which receives a
++   high volume of security issues, but there are currently no
 +   volunteers within the project or the security team sufficiently
 +   interested and willing to spend the large amount of time required
 +   to stem those incoming issues.
@@ -35,7 +35,7 @@
 +
 +   Unfortunately, this means that libv8, nodejs, and the associated node-*
++   role="package">nodejs and the associated node-*
 +   package ecosystem should not currently be used with untrusted
 +   content, for example unsanitized data from the internet.
 +



signature.asc
Description: OpenPGP digital signature


Bug#778581: systemd install breaks chroot jail and compromises guest system

2015-02-16 Thread Wolfgang Rosner
Package: systemd
Version: 215-8
Severity: normal

Dear Maintainer,


I'm trying to configure nfsroot installation for diskless clients.
-  debootstrap  /path/to/client-root
-  chroot /path/to/client-root /bin/bash
- CHR#>  apt-get install 
- CHR#>  apt-get install systemd

The last command leads to some error message (I can't remember)
Then, after googling, I run something like dpkg -a (still in the chrooted shell)
This made my server completely frozen.

After forceful reboot, It seems that I got parts of systemd installed on the 
server, too, not only on the chrooted client-root.


root@cruncher:/cluster/tftp/active/pxelinux.cfg# dpkg --list | grep systemd
ii  libpam-systemd:amd64  215-8 
 amd64system and service manager - PAM module
ii  libsystemd-login0:amd64   44-11+deb7u4  
 amd64systemd login utility library
ii  libsystemd0:amd64 215-8 
 amd64systemd utility library
ii  systemd   215-8 
 amd64system and service manager
ii  systemd-shim  9-1   
 amd64shim for systemd

root@cruncher:/cluster/tftp/active/pxelinux.cfg# grep systemd 
/var/log/apt/history.log

. is EMPTY 

So I think systemd got installed accidentially by breaking the chroot.

I also think that my mount list is weird and contains both systemd and 
sysv-init mounts:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=2036655,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1637124k,mode=755)
/dev/sda2 on / type ext4 
(rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=9524120k)
/dev/sda4 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb2 on /ssd type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
(rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k)
configfs on /sys/kernel/config type configfs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
systemd on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/x86_64-linux-gnu/systemd-shim-cgroup-release-agent,name=systemd)
tmpfs on /run/user/0 type tmpfs 
(rw,nosuid,nodev,relatime,size=1637124k,mode=700)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=1637124k,mode=700,uid=1000,gid=1000)


However, the system behaviour seems OK as far as I can tell.

How can I get rid of the situation?

I think such things should not happen.
May be it is difficult / impossible to install such fundamental stuff like 
systemd into a chrooted debootstrap.
Nevertheless, then I'd expect a graceful fail with some decent error message, 
and not a poke into the host system.


Wolfgang Rosner


-- Package-specific info:

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 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 systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap2 1:2.22-1.2
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20 1.6.2-4+b1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2
ii  libpam0g1.1.3-7.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-8
ii  mount   2.25.2-4
ii  sysv-rc 2.88dsf-41+deb7u1
ii  udev215-8
ii  util-linux  2.25.2-4

Versions of packages systemd recommends:
ii  dbus1.6.8-1+deb7u5
ii  libpam-systemd  215-8

Versions of packages systemd suggests:
pn  systemd-ui  

-- 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#759001: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d

2015-02-16 Thread Christian Seiler

Control: tags -1 + patch

(remove CC systemd-devel, add CC corresponding Debian bug)

Am 16.02.2015 um 19:12 schrieb Michael Biebl:

That said, as one of the Debian systemd maintainers, I could probably
be convinced to add the insserv override support as a downstream patch
for jessie.


I've attached a minimal patch for Debian Jessie for this. I tested it
briefly, i.e. if no /etc/insserv/overrides/$NAME exists, nothing
changes, but if it exists, it properly overrides the current LSB
script. Please review.

Only minor issue is that SourcePath= is a single-valued entry in
systemd, so I can't just add the override if it exists, and
FragmentPath= is only ever dynamically filled by systemd when parsing,
so I can't set that either. It's mostly cosmetic, but systemctl status
for example won't show that the file was overwritten.

(Alternatively, one could ONLY use /etc/insserv/overrides/$NAME as
SourcePath=, of course, I don't have a strong opinion on either one of
these solutions.)


We are pretty late into the freeze though, so this would
require an ack from our release managers.


Do you want me to ask for pre-approval?

Christian

From: Christian Seiler 
Date: Tue, 17 Feb 2015 00:27:21 +0100
Subject: sysv-generator: add support for /etc/insserv/overrides

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759001
---
 src/sysv-generator/sysv-generator.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index 628d579..c4888e2 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -41,6 +41,8 @@
 #include "fileio.h"
 #include "hashmap.h"
 
+#define SYSV_OVERRIDE_PATH"/etc/insserv/overrides/"
+
 typedef enum RunlevelType {
 RUNLEVEL_SYSINIT,
 RUNLEVEL_UP,
@@ -76,6 +78,7 @@ static const struct {
 typedef struct SysvStub {
 char *name;
 char *path;
+char *override_path;
 char *description;
 bool sysinit;
 int sysv_start_priority;
@@ -351,7 +354,7 @@ finish:
 return 1;
 }
 
-static int load_sysv(SysvStub *s) {
+static int load_sysv(SysvStub *s, const char *lsb_header_path) {
 _cleanup_fclose_ FILE *f;
 unsigned line = 0;
 int r;
@@ -368,7 +371,7 @@ static int load_sysv(SysvStub *s) {
 
 assert(s);
 
-f = fopen(s->path, "re");
+f = fopen(lsb_header_path, "re");
 if (!f)
 return errno == ENOENT ? 0 : -errno;
 
@@ -381,7 +384,7 @@ static int load_sysv(SysvStub *s) {
 
 log_error_unit(s->name,
"Failed to read configuration file '%s': %m",
-   s->path);
+   lsb_header_path);
 return -errno;
 }
 
@@ -456,7 +459,7 @@ static int load_sysv(SysvStub *s) {
 if (!path_is_absolute(fn)) {
 log_error_unit(s->name,
"[%s:%u] PID file not absolute. Ignoring.",
-   s->path, line);
+   lsb_header_path, line);
 continue;
 }
 
@@ -547,7 +550,7 @@ static int load_sysv(SysvStub *s) {
 if (r < 0)
 log_error_unit(s->name,
"[%s:%u] Failed to add LSB Provides name %s, ignoring: %s",
-   s->path, line, m, strerror(-r));
+   lsb_header_path, line, m, strerror(-r));
 }
 
 } else if (startswith_no_case(t, "Required-Start:") ||
@@ -571,7 +574,7 @@ static int load_sysv(SysvStub *s) {
 if (r < 0) {
 log_error_unit(s->name,
"[%s:%u] Failed to translate LSB dependency %s, ignoring: %s",
-   s->path, line, n, strerror(-r));
+   lsb_header_path, line, n, strerror(-r));
 continue;
 }
 
@@ -605,7 +608,7 @@ static int load_sysv(SysvStub *s) {
 if (r < 0)
 log_error_unit(s->name,
"[%s:%u] Failed to add dependency on %s, ignoring: %s",
-

Bug#772963: release-notes: cellphone friendly CSS

2015-02-16 Thread Stéphane Blondon
I have added the 'important' and 'note' icons from Tango desktop
project. There is no 'caution' icon in Tango so I changed the colors
of the 'important' icon to add it.
You can find the 3 icons attached to this message. The source for the
'caution' icon is added too in case of someone wants to modifiy it.

You can find a temporary demo at:
http://stephane.yaal.fr/tmp/release-notes.amd64.html.icons/ch-about.en.html

I didn't find the arrows icons in the repository in Niels's master
branch. Do you have directly updated
/usr/share/xml/docbook/stylesheet/nwalsh?


2015-02-14 21:30 GMT+01:00 Stephan Beck :
> And, Stéphane, this time you may integrate it into the html file(s) and 
> publish
> it, if you like.

I uploaded them at:
http://stephane.yaal.fr/tmp/release-notes.amd64.html.sbeck/index.en.html

I think they are not well integrated with the others icons and the
rest of the CSS. (However if people think they are better, commit them
instead of the current ones.)

The 'home' icon is confusing: it's an 'up' arrow so it means more 'go
to the top of the page' than 'go to home page'.



> I have a website, too, but the provider does not support the
> scp command, and I am not willing to use simple ftp transfer anymore

If your concerns with the FTP protocol is security, perhaps your
provider accepts FTPS or SFTP?



-- 
Stéphane


Bug#778424: trying to overwrite '/usr/share/xsessions/icewm-session.desktop' bug still there?

2015-02-16 Thread 積丹尼 Dan Jacobson
Here's what I see today

Preparing to unpack .../icewm_1.3.8+githubmod+20150214+d373d98-1_i386.deb ...
Unpacking icewm (1.3.8+githubmod+20150214+d373d98-1) over (1.3.8-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/icewm_1.3.8+githubmod+20150214+d373d98-1_i386.deb 
(--unpack):
 trying to overwrite '/usr/share/xsessions/icewm-session.desktop', which is 
also in package icewm-common 1.3.8-2
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Preparing to unpack 
.../icewm-common_1.3.8+githubmod+20150214+d373d98-1_i386.deb ...
Unpacking icewm-common (1.3.8+githubmod+20150214+d373d98-1) over (1.3.8-2) ...


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



Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Michael Biebl
Am 17.02.2015 um 00:27 schrieb Josh Triplett:
> On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt  wrote:
>> For jessie+1/experimental onward, we'll fix this properly by enabling
>> timesyncd by default. It won't start if ntp or similar are installed.
>> This will make sure that the hw clock will be updated often enough,
>> and we won't poke false data into it:
>>
>>   
>> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326
> 
> Using ConditionFileIsExecutable on specific NTP daemons seems odd here.
> Doesn't systemd already have a mechanism for choosing from multiple
> alternative implementations of a given feature, automatically running
> only one of them?  If not, perhaps it should; that same mechanism would
> then work for display managers, web servers, etc.

Sort of. The plan here is, that the individual ntp implementations ship
a native systemd unit file, which has
Conflicts=systemd-timesyncd.service [1]

This will make sure, that if e.g. ntp is installed and enabled, ntp will
be used instead of systemd-timesyncd.

None of the ntp implementations currently ship such a native unit file
though, that's why we decided to add such a Condition to the
systemd-timesyncd.service unit file for the time being.

There were concerns that adding this Conflicts to every time
synchronization service is a questionable approach [2].

Arguably, for ntp, chrony and openntpd, we can solve this on a packaging
level, by making those packages conflict.

If we want to enable timesyncd by default and keep it as a part of the
systemd package, this approach doesn't work, and we need the Conflicts=
on the systemd unit level.

Michael


[1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/22172
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1116369

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



signature.asc
Description: OpenPGP digital signature


Bug#778580: dracut-network: dracut fails to start up rpc.idmapd required for nfsroot over nfsv4

2015-02-16 Thread Wolfgang Rosner
Package: dracut-network
Version: 040+1-1 
Severity: important

Dear Maintainer,

I try to set up a beowulf style cluster with diskless nodes on following assets
- debian wheezy both on client and server
- dnsmasq for DHCP, /etc/host-based DNS and TFTP
- pxelinux
- nfsv4 for nfsroot (goal was rw)
- aufs layered file system on the server
- bonded ethernet network - requires dracut

When I log into the client, I get squeezed file ownership like this:

total 50980
drwx--  7 4294967294 4294967294 4096 Feb 15  2015 .
drwxr-xr-x 22 4294967294 4294967294 4096 Feb 16  2015 ..
drwx--  2 4294967294 4294967294 4096 Jan 25  2015 .aptitude
-rw---  1 4294967294 4294967294 6944 Feb 15  2015 .bash_history

This indicates that rpc.idmapd is not properly working.
When I switch to nfs v3 via pxelinux kernel command line, the ownership is ok

I alread filed a reques on debian-user - without response:
https://lists.debian.org/debian-user/2015/02/msg00628.html
(some details are covered there)

I switched to dracut from "testing", since there are many bugs reported to be 
corrected somwhere in dracut 03x
(missing libraries, )

Anything else should be from wheezy stable (I think...), at least at the 
clients.

I tried both sysvinit and systemd based installations, and starting from 
HD-installations and from debootstrap.
Some details may vary, but in no case rpc.idmapd  fires up during boot as it 
should.

Following these hints
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/927908
---8<--
The following lines in /etc/fstab are missing:
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs defaults 0 0
nfsd /proc/fs/nfsd nfsd defaults 0 0
---8<--

I mounted those manually (partially I had to create mountpoints by 
mount-binding tempfs),
after that I can manually fire up rpc.statd and rpc.idmapd
and then manually mount my nfsroot.

On sysvinit system, this solves the problem and UIDs are correct.
On systemd system, UIDs are still wrong.

I can produce lots of logs and wiresharks upon request, but myself get lost in 
the details.


Wolfgang Rosner

(FYI: reportbug runs on server, but apt is configured identical on the client 
nodes:)
-- System Information: 
Debian Release: 7.7
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#674875: Still orphaned?

2015-02-16 Thread Richard Winters
Is this package still orphaned?  It seems to have a maintainer different
than specified in this post now -> with updates as recent as july of last
year.

Just thought I'd ping it, I'm interested in maintaining through a sponsor
if its in need of a maintainer - sorry if I'm jumping the gun, this package
is listed in orphaned packages.



*Ri​k*


Bug#778579: Output not explained

2015-02-16 Thread Joachim Breitner
Package: zerofree
Version: 1.0.3-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I just ran zerofree and it returned with

$ zerofree -v /dev/vg-raid1/fry-disk 
2368428/2661728/4826112

Now I wonder what these numbers mean, but neither the homepage nor the
manpage would enlighten me.

If you know what they mean, please add that to the manpage.

Thanks,
Joachim


- -- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages zerofree depends on:
ii  e2fslibs  1.42.12-1
ii  libc6 2.19-15

zerofree recommends no packages.

zerofree suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlTifz0ACgkQ9ijrk0dDIGw9IgCdG7FTReQllWOkFrKwKF8R7POo
6zUAoL8ucPqd7rbJH/+sHkHi9eNhjJNj
=6h+3
-END PGP SIGNATURE-


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



Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Josh Triplett
On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt  wrote:
> For jessie+1/experimental onward, we'll fix this properly by enabling
> timesyncd by default. It won't start if ntp or similar are installed.
> This will make sure that the hw clock will be updated often enough,
> and we won't poke false data into it:
> 
>   
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326

Using ConditionFileIsExecutable on specific NTP daemons seems odd here.
Doesn't systemd already have a mechanism for choosing from multiple
alternative implementations of a given feature, automatically running
only one of them?  If not, perhaps it should; that same mechanism would
then work for display managers, web servers, etc.

- Josh Triplett


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



Bug#776611: [Pkg-gnupg-maint] Bug#776611: [dirmngr] segfaults

2015-02-16 Thread Daniel Kahn Gillmor
Control: tags 776611 - moreinfo unreproducible

Hi Florian--

Sorry for taking a little while to get to this...

On Thu 2015-02-05 02:59:28 -0500, Florian Reitmeir wrote:
>  cat /var/log/dirmngr/dirmngr.log
> 2015-02-02 06:36:34 dirmngr[3324.0] permanently loaded certificates: 0
> 2015-02-02 06:36:34 dirmngr[3324.0] runtime cached certificates: 0
> 2015-02-02 16:02:48 dirmngr[2517.0] permanently loaded certificates: 0
> 2015-02-02 16:02:48 dirmngr[2517.0] runtime cached certificates: 0
> 2015-02-03 22:48:20 dirmngr[2384.0] permanently loaded certificates: 0
> 2015-02-03 22:48:20 dirmngr[2384.0] runtime cached certificates: 0
 [...]
> attached is a stack trace, ..

Thanks for this information!  It looks to me like the errors are related
to loading the CRL cache. (in particular, in open_dir() in
src/crlcache.c).  I think i'm now able to reproduce this.

I suspect you have a zero-length file in
/var/cache/dirmngr/crls.d/DIR.txt, is that correct?  can you show me the
output of:

   stat /var/cache/dirmngr/crls.d/DIR.txt

If you move that file out of the way, can you start dirmngr without
it crashing?

   mv /var/cache/dirmngr/crls.d/DIR.txt  /var/cache/dirmngr/crls.d/DIR.txt.bak

If this works, do you have any idea how dirmngr's crlcache got into this
state?  I'm working on a patch now.

--dkg


signature.asc
Description: PGP signature


Bug#778578: ITP: rsem -- RNA-Seq by Expectation-Maximization

2015-02-16 Thread Michael Crusoe
Package: wnpp
Severity: wishlist
Owner: Debian Med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: rsem
  Version : 1.2.19
  Upstream Author : Bo Li 
* URL : http://deweylab.biostat.wisc.edu/rsem/
* License : GPL-3
  Programming Lang: C++, Perl
  Description : RNA-Seq by Expectation-Maximization

RSEM is a software package for estimating gene and isoform expression
 levels from RNA-Seq data. The RSEM package provides an user-friendly
 interface, supports threads for parallel computation of the EM
 algorithm, single-end and paired-end read data, quality scores,
 variable-length reads and RSPD estimation. In addition, it provides
 posterior mean and 95% credibility interval estimates for expression
 levels. For visualization, It can generate BAM and Wiggle files in both
 transcript-coordinate and genomic-coordinate. Genomic-coordinate files
 can be visualized by both UCSC Genome browser and Broad Institute’s
 Integrative Genomics Viewer (IGV). Transcript-coordinate files can be
 visualized by IGV. RSEM also has its own scripts to generate transcript
 read depth plots in pdf format. The unique feature of RSEM is, the read
 depth plots can be stacked, with read depth contributed to unique reads
 shown in black and contributed to multi-reads shown in red. In addition,
 models learned from data can also be visualized. Last but not least,
 RSEM contains a simulator.

RSEM is a popular bioinformatics program and a dependency of trinityrnaseq.
It will be maintained by the Debian Med team.


Bug#778566: unblock: node-serve-static/1.6.4-2

2015-02-16 Thread Andrew Kelley
On Mon, 16 Feb 2015 23:45:17 +0100 Mehdi Dogguy  wrote:
> Assuming you will replace "UNRELEASED" with a more sensible string,
> please go
> ahead and upload it to Unstable.

It is now uploaded to unstable. Thank you.


Bug#778568: unblock: node-findit2/2.2.3-2

2015-02-16 Thread Andrew Kelley
On Mon, 16 Feb 2015 23:39:29 +0100 Mehdi Dogguy  wrote:
> Can you please elaborate on the "node-tap is a buggy package" part?
>
> I see that there is an RC-bug reported against it and its maintainer
> seems
> to think that it should be easy to fix. Are there any other issues? Did
> you
> try to contact node-tap's maintainer to see if/when he is willing to
> fix that
> RC-bug?

Good call. I have now worked with Jérémy and we have filed #778576 to
unblock node-tap.

If for some reason, however, that unblock request is rejected then I would
propose this one in its place.


Bug#778577: CVE-2015-1606 CVE-2015-1607 -- multiple issues found in GnuPG

2015-02-16 Thread Daniel Kahn Gillmor
Package: gnupg2
Version: 2.0.14-2
Tags: security
Control: notfound -1 2.1.2-1

Several coding errors were discovered in GnuPG 2.0 lately by Hanno Böck
as part of the Fuzzing Project:

  
https://blog.fuzzing-project.org/5-Multiple-issues-in-GnuPG-found-through-keyring-fuzzing-TFPA-0012015.html

These changes are in upstream git, but have not been rolled into an
official release yet, except for 2.1.2 on the upstream "modern" branch.

I believe they go back as far as the version in squeeze, possibly
farther.

 --dkg


signature.asc
Description: PGP signature


Bug#778576: unblock: node-tap/0.4.13-2

2015-02-16 Thread Andrew Kelley
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-tap

The bug that caused this package to be scheduled for autoremoval is
fixed with this small patch which disables a single test.

This does not affect the behavior of the package itself in any way.

diff -Nru node-tap-0.4.13/debian/changelog node-tap-0.4.13/debian/changelog
--- node-tap-0.4.13/debian/changelog2014-10-20 00:01:44.0 +
+++ node-tap-0.4.13/debian/changelog2015-02-16 22:53:56.0 +
@@ -1,3 +1,9 @@
+node-tap (0.4.13-2) unstable; urgency=medium
+
+  * Patch fixing failing test FTBFS (Closes: #775627)
+
+ -- Jérémy Lal   Mon, 16 Feb 2015 23:52:37 +0100
+
 node-tap (0.4.13-1) unstable; urgency=low
 
   * Initial release (Closes: #765988)
diff -Nru node-tap-0.4.13/debian/patches/mitigate_test_segv.patch 
node-tap-0.4.13/debian/patches/mitigate_test_segv.patch
--- node-tap-0.4.13/debian/patches/mitigate_test_segv.patch 1970-01-01 
00:00:00.0 +
+++ node-tap-0.4.13/debian/patches/mitigate_test_segv.patch 2015-02-16 
22:53:00.0 +
@@ -0,0 +1,30 @@
+Description: exit code of segv test depend on platform - do not check it
+ For reasons yet to be discovered, the assumption in segv test is wrong on
+ the platform used for https://bugs.debian.org/775627.
+Last-Update: 2015-02-16
+Author: Jérémy Lal 
+Forwarded: no, need more info
+--- a/test/segv.js
 b/test/segv.js
+@@ -37,9 +37,7 @@
+   , { 'id': 1,
+   'ok': false,
+   'name': ' ././segv',
+-  'exit': null,
+   'timedOut': true,
+-  'signal': process.platform === 'linux' ? 'SIGSEGV' : 'SIGTERM',
+   'command': '"./segv"' }
+   , 'tests 1'
+   , 'fail  1' ]
+@@ -47,11 +45,6 @@
+   tc.on('data', function (d) {
+ var e = expect.shift()
+ 
+-// specific signal can be either term or bus
+-if (d.signal && e.signal)
+-  e.signal = d.signal === "SIGTERM" || d.signal === "SIGBUS" ?
+-d.signal : e.signal
+-
+ t.same(d, e)
+   })
+   tc.on('end', function () {
diff -Nru node-tap-0.4.13/debian/patches/series 
node-tap-0.4.13/debian/patches/series
--- node-tap-0.4.13/debian/patches/series   2014-10-20 00:01:40.0 
+
+++ node-tap-0.4.13/debian/patches/series   2015-02-16 22:53:00.0 
+
@@ -1,3 +1,4 @@
 nodejs_rename.patch
 use_available_modules.patch
 sbuild_disable_tests.patch
+mitigate_test_segv.patch

unblock node-tap/0.4.13-2

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

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


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



Bug#778190: fixed-upstream

2015-02-16 Thread Anton Gladky
tags 778190 +pending
thanks


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



Bug#777714: Acknowledgement (man-db crashes during post-install)

2015-02-16 Thread Lukasz Szotek
This bug can be closed, because it does not directly concern the man-db.
Hangs during packages installation are caused by another problem, possibly 
related to VirtualBox.

[720.119857] ca-certificates D c1657c44 0  5246   5244 0x
[720.119862]  f4903d94 0082 f5054ab0 c1657c44 0001 c170e280 c170e280 

[720.119866]  007b f75de280 f5054ab0 c16571c0   c1254011 
c1657540
[720.119871]  f5fa1620 0001 bfede000 8000 bfedf000 f6980cf0 f4903d7c 
c10524ec
[720.119876] Call Trace:
[720.119882]  [] ? radix_tree_lookup_slot+0x11/0x30
[720.119885]  [] ? __kunmap_atomic+0x5c/0x80
[720.119889]  [] ? unmap_single_vma+0x44b/0x760
[720.119892]  [] ? rwsem_down_write_failed+0x165/0x260
[720.119895]  [] ? call_rwsem_down_write_failed+0x6/0x8
[720.119898]  [] ? down_write+0x25/0x40
[720.119901]  [] ? unlink_anon_vmas+0x5b/0x160
[720.119904]  [] ? free_pgtables+0x81/0xf0
[720.119906]  [] ? exit_mmap+0x82/0x120
[720.119910]  [] ? mmput+0x57/0xf0
[720.119913]  [] ? flush_old_exec+0x364/0x6d0
[720.119916]  [] ? load_elf_binary+0x23a/0x11c0
[720.119919]  [] ? kmap_high+0x21/0x1f0
[720.119922]  [] ? page_address+0xba/0xd0
[720.119925]  [] ? kunmap_high+0x1f/0xb0
[720.119928]  [] ? copy_strings+0x1fd/0x250
[720.119931]  [] ? search_binary_handler+0x7d/0x1a0
[720.119934]  [] ? do_execve_common+0x3fe/0x540
[720.119937]  [] ? SyS_execve+0x21/0x30
[720.119940]  [] ? sysenter_do_call+0x12/0x12

-- 
Best regards
 Lukasz


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



Bug#778190: fixed-upstream

2015-02-16 Thread Anton Gladky
tags 778190 +fixed-upstream
thanks

https://github.com/yade/trunk/commit/459085df5e3bdab39aae879d65a6e8198249ebf4


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



Bug#778575: libparse-recdescent-perl: please enable reproducible builds

2015-02-16 Thread Reiner Herrmann
Source: libparse-recdescent-perl
Version: 1.967009+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102160

Hi!

While working on Debian's “reproducible builds” effort [1], we have
noticed that libparse-recdescent-perl produces grammar files with
elements in random order, which results in other packages being
unreproducible.

The attached patch, which I have already forwarded upstream,
fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_grammar.patch b/debian/patches/reproducible_grammar.patch
new file mode 100644
index 000..3404321
--- /dev/null
+++ b/debian/patches/reproducible_grammar.patch
@@ -0,0 +1,25 @@
+Author: Reiner Herrmann 
+Description: produce reproducible grammar files
+Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102160
+
+Index: libparse-recdescent-perl-1.967009+dfsg/lib/Parse/RecDescent.pm
+===
+--- libparse-recdescent-perl-1.967009+dfsg.orig/lib/Parse/RecDescent.pm
 libparse-recdescent-perl-1.967009+dfsg/lib/Parse/RecDescent.pm
+@@ -144,6 +144,7 @@ sub Precompile
+ print OUT "my ";
+ 
+ require Data::Dumper;
++$Data::Dumper::Sortkeys = 1;
+ $code = Data::Dumper->Dump([$self], [qw(self)]);
+ if ($opt{-standalone}) {
+ $code =~ s/Parse::RecDescent/$runtime_package/gs;
+@@ -3082,7 +3083,7 @@ local \$SIG{__WARN__} = sub {0};
+ $self->{"startcode"} = '';
+ 
+ my $rule;
+-foreach $rule ( values %{$self->{"rules"}} )
++foreach $rule ( sort { $a->{name} cmp $b->{name} } values %{$self->{"rules"}} )
+ {
+ if ($rule->{"changed"})
+ {
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..d2c4421
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible_grammar.patch


signature.asc
Description: OpenPGP digital signature


Bug#777042: unblock: suricata/2.0.6-1

2015-02-16 Thread Julien Cristau
On Wed, Feb  4, 2015 at 12:16:59 +0100, Arturo Borrero Gonzalez wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release team, please unblock package suricata
> 
> We were contacted privately regarding this release of libhtp/suricata
> which include important security updates (no CVE asigned though).
> 
> We considered backporting just the important patches, but the changelog is
> rather small and we decided to package the new version directly.
> 
> Before we upload 2.0.6-1 to unstable we would like to make sure that this is 
> OK for you.
> 
> Similar unblock exists for libhtp (#777040).
> 
> The the debdiff, generated with this cmdline:
> debdiff suricata_2.0.4-1.dsc suricata_2.0.6-1.dsc | filterdiff -i '*.[ch]
> 
> Note that the resulting debdiff was hand-modified to delete the libhtp code, 
> which is
> included in upstream tarball but it has his own source package.
> 
It's large enough that I got bored midway through, but meh, if it breaks
you keep both pieces; feel free to upload.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#778566: unblock: node-serve-static/1.6.4-2

2015-02-16 Thread Mehdi Dogguy

Tags: + confirmed

Le 2015-02-16 20:14, Andrew Kelley a écrit :


The package had a security vulnerability which was the bug that caused
node-serve-static and its reverse dependencies to be marked as
autoremove. This debdiff fixes that vulnerability without touching any
other code.

diff -Nru node-serve-static-1.6.4/debian/changelog
node-serve-static-1.6.4/debian/changelog
--- node-serve-static-1.6.4/debian/changelog	2014-10-15 
15:52:21.0 +
+++ node-serve-static-1.6.4/debian/changelog	2015-02-16 
19:05:08.0 +

@@ -1,3 +1,9 @@
+node-serve-static (1.6.4-2) UNRELEASED; urgency=medium

   ^^
Assuming you will replace "UNRELEASED" with a more sensible string, 
please go

ahead and upload it to Unstable.

Regards,

--
Mehdi


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



Bug#776847: gsasl 1.8.0-6 does not support GSSAPI

2015-02-16 Thread Simon Josefsson
Den Mon, 16 Feb 2015 22:51:26 +0100
skrev Re: Bug#776847: gsasl 1.8.0-6 does not support GSSAPI:

> 
> On 16/02/15 22:13, Simon Josefsson wrote:
> > It seems clear that the #745332 fix was incorrect.  You can see in
> > the build logs GSSAPI is not enabled since krb5-config isn't found:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gsasl&arch=amd64&ver=1.8.0-6&stamp=1412611018
> >
> > On considering solutions, I don't like the unpredictability in
> > depending on libkrb5-dev|libheimdal-dev.  The GSSAPI library used by
> > the binary libgsasl package in Debian will depend on whether the
> > buildds have Heimdal or MIT installed when you built the package.
> > Coping with different GSS libraries on different architecture
> > sounds like a recipe for disaster.  For Jessie, gsasl should be
> > built against the same Kerberos library on all architectures,
> > unless there is a reason not to -- and I don't know of a reason.
> > MIT is picked arbitrarily here.
> >
> > Cc'ing Jelmer (who reported 745332) and Andreas (who uploaded it) --
> > any comments?  Jelmer, what prompted your initial report?  The way I
> > see it, it is important (for us) that you buildds don't have
> > multiple Kerberos development packages installed when they build
> > gsasl.  So the old way was the preferred way, causing heimdal-dev
> > to be removed and libkrb5-dev to be pulled in.  People with other
> > preferences who build their own packages can surely modify the
> > gsasl package to their liking.
> >
> > I've pushed a fix in git and attmpted to upload to experimental, so
> > you can test the new packages.
> The main reason for proposing this change was just to make it easier
> to have heimdal-dev installed while working on other parts of the
> system. At the moment, building gsasl requires uninstalling a number
> of packages for me, that indirectly depend on heimdal-dev.
> 
> With the patch, the intent was to gsasl still build against MIT
> kerberos
> - e.g. no change in the binary packages. It merely changed the
> dependency from libkrb5-dev to libkrb5-multidev, the latter of which
> doesn't prevent heimdal-dev from being installed.

Right -- but the patch also had the consequence of completely disabling
GSSAPI in gsasl.  Reverting the patch makes GSSAPI work again.

> Anyway, as you say, I can manually patch gsasl if I need to, and at
> the moment I don't work on any packages that depend on libgsasl-dev.
> I still think it would be nice to not have gsasl conflict with
> heimdal-dev, but it's not the end of the world if it doesn't.

Maybe libkrb5-dev|heimdal-dev is a better build-dep -- but I don't know
what holds for Debian buildds: are they allowed to have some packages
pre-installed?  If they can never have heimdal-dev installed (or for
some other reason prefer heimdal-dev over libkrb5-dev), I don't see a
problem using libkrb5-dev|heimdal-dev instead of libkrb5-dev.  But if
there are no guarantees, I prefer hard-coding libkrb5-dev to avoid
linking with different Kerberos libraries depending on Debian
architecture.  Does anyone know?

Btw, packages have hit experimental, if someone wants to test them.  We
can look at build logs to see if it enables GSSAPI or not.

/Simon

> 
> Cheers,
> 
> Jelmer
> 



pgpSbqZz2UQGk.pgp
Description: OpenPGP digital signatur


Bug#778568: unblock: node-findit2/2.2.3-2

2015-02-16 Thread Mehdi Dogguy

Control: retitle -1 pre-approval: node-findit2/2.2.3-2

Le 2015-02-16 20:33, Andrew Kelley a écrit :

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

Please unblock package node-findit2

The package build-depends on node-tap, a buggy package. However, this
dependency is strictly optional and is only used to run upstream 
tests.

Further, there are many examples of Debian JavaScript packages which
have tests disabled.



Can you please elaborate on the "node-tap is a buggy package" part?

I see that there is an RC-bug reported against it and its maintainer 
seems
to think that it should be easy to fix. Are there any other issues? Did 
you
try to contact node-tap's maintainer to see if/when he is willing to 
fix that

RC-bug?

Regards,

--
Mehdi


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



Bug#778565: 215-12 does not set correct rights for hidraw devices (and others) anymore

2015-02-16 Thread Michael Biebl
Am 16.02.2015 um 23:02 schrieb Klaus Ethgen:
> Am Mo den 16. Feb 2015 um 21:46 schrieb Michael Biebl:
>> Am 16.02.2015 um 19:50 schrieb Klaus Ethgen:
>>> Package: udev
>>> Version: 215-12
>>> Severity: important
>>>
>>> After updating from 215-11 to 215-12, usb hidraw devices stopped to be
>>> accessable by plugdev group after reboot. I only checked that rights as
>>> this ist the most important for me but had also some other error
>>> messages after the reboot.
>>>
>>> So the system is only partial working after that update.
> 
>> The udev rules shipped by the udev package do not use the plugdev group
>> *at all*. I fail to see why an update of udev should have changed
>> anything in that regard.
> 
> Well, it is in fact. Installing version 215-11 fixes the bug.
> 
>> And aside from that, the only udev related change in 215-12 was [1],
>> which isn't relevant regarding hidraw devices.
> 
> Well, then I suspect that there got something else into that package
> under the radar.
> 

Please run git bisect to find the commit then.


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



signature.asc
Description: OpenPGP digital signature


Bug#776847: gsasl 1.8.0-6 does not support GSSAPI

2015-02-16 Thread Max Kosmach

Hi, Jelmer

17.02.2015 0:51, Jelmer Vernooij пишет:


On 16/02/15 22:13, Simon Josefsson wrote:

It seems clear that the #745332 fix was incorrect.  You can see in the
build logs GSSAPI is not enabled since krb5-config isn't found:

https://buildd.debian.org/status/fetch.php?pkg=gsasl&arch=amd64&ver=1.8.0-6&stamp=1412611018


[skip]


With the patch, the intent was to gsasl still build against MIT kerberos
- e.g. no change in the binary packages. It merely changed the
dependency from libkrb5-dev to libkrb5-multidev, the latter of which
doesn't prevent heimdal-dev from being installed.


With Your patch gsasl configure can't find krb5-config.
From buildd logs above:
configure: checking for GSS implementation (mit)
configure: WARNING: MIT Kerberos krb5-config not found, disabling GSSAPI

Without patch (1.8.0-4):
configure: checking for GSS implementation (mit)
configure: trying MIT
checking for krb5-config... /usr/bin/krb5-config

So binary files are differ: 1.8.0-4 support GSSAPI and 1.6.0-6 - does 
not support.



--
With best wishes
Max


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



Bug#778445: My mistake on MilterSocketMode

2015-02-16 Thread Branko Majic
Great, thanks a lot for the quick work! :)

My bad on MilterSocketMode, I must have been going back and forth for
testing, so the error slipped in on my side.

Best regards


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



Bug#776839: unblock: libgit2/0.21.3-1.1

2015-02-16 Thread Mehdi Dogguy
Tags: + confirmed

On Thu, Feb 12, 2015 at 09:49:34PM +1100, Russell Sim  
wrote:
> On 11 February 2015 at 23:24, Russell Sim  wrote:
> 
> > On 9 February 2015 at 09:36, Mehdi Dogguy  wrote:
> >
> >> I'm afraid we cannot accept 0.21.3-1.1 in Jessie because the changes are
> >> quite large. Can you please prepare an upload targetting jessie based on
> >> 0.21.1-2.1?
> >>
> >
> >
> > Thanks for looking at this.  I have created a patch that backport the
> > relevant changes to the 0.21.1-2.1
> 
> 
> I have reduced the patch removing any Win32 parts.
> 

Thanks for your work and sorry for not getting back to you sooner. The patch
looks okay. Please go ahead and upload 0.21.1-3 to Jessie and notify us as
soon as it gets accepted.

Cheers.

-- 
Mehdi Dogguy


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



Bug#778574: planetfilter: Log output to /var/log/planetfilter.log

2015-02-16 Thread Francois Marier
Package: planetfilter
Version: 0.2.0-1
Severity: wishlist

Because we swallow all non-error cron output using "chronic", there should
be a (log-rotated) logfile that admins can take a look at if they want to
see more info about what the package is doing.

We could modify the cronjob to make use of the "ts" command (part of
moreutils) to timestamp each message coming out of the main binary.

The tricky part here is that we want:

- the cronjob to hide all output when planetfilter zero exit code
- the cronjob to show all output in case of a non-zero exit code
- the log file to have all output, regardless of the exit code

We may not be able to use chronic anymore.

If anybody has ideas on how to do the above, please chime in.

Francois


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



Bug#777540: The libhtp SONAME mismatch *is* a policy violation.

2015-02-16 Thread Hilko Bengen
* Julien Cristau:

>> 1. Override upstream's decision to change the SONAME with every release.
>>I am not entirelysure how stable libhtp's API/ABI should be
>>considered -- looking at changes and deciding on compatibility issues
>>making those decisions would certainly put a burden on the maintainer
>>in the future (although the .symbols mechanism helps for obvious
>>cases such as removed APIs.)
>> 
>>I am attaching a patch to drop the -release parameter from the
>>libtool call, libhtp.so.1.0.0 (instead of libhtp-0.5.15.so.1.0.0) is
>>generated. The .symbols file would need to be updated to reflect that
>>change, too, of course.
>> 
>> 2. Since suricata is the only reverse dependency of libhtp and contains
>>a copy of libhtp within its source tarball, so we could drop the
>>libhtp package altogether and use that embedded copy instead, at
>>least for the jessie release.
>> 
>> 3. Change the binary package name to reflect the SONAME -- for instance
>>libhtp-0.5.15. I believe that we are too late in the freeze to be
>>adding new binary package names.
>> 
> For jessie, 2 sounds like the best way to go IMO.

Thank you. Could somebody please decide about #777042 ("unblock:
suricata/2.0.6-1")?

A positive answer, together with the decision to use the copy of the
libhtp sources shipped as part of suricata for jessie, would also take
care of #777040 ("unblock: libhtp/0.5.16-1"), as well as security issues
#774897, #777522, and #777523.

Cheers,
-Hilko


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



Bug#769155: kde-workspace-bin: laptop does not go to sleep when critical battery level is reached

2015-02-16 Thread Felipe Sologuren Gutiérrez
Package: kde-workspace-bin
Version: 4:4.11.13-2
Followup-For: Bug #769155

Dear Maintainer,

Confirming this bug with version 4.11.13-2.

I tested booting with linux-image-3.2.0-4-amd64 (3.2.65-1+deb7u1) and the 
laptop has gone to hibernate when passing the critical level, so I think is 
related with kernel behaviour.

Thank you.
Felipe Sologuren

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (100, 'unstable'), (40, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kde-workspace-bin depends on:
ii  iso-codes 3.57-1
ii  kde-runtime   4:4.14.2-2
ii  kde-style-oxygen  4:4.11.13-2
ii  kde-workspace-data4:4.11.13-2
ii  kde-workspace-kgreet-plugins  4:4.11.13-2
ii  kscreen   1.0.2.1-1
ii  libc6 2.19-13
ii  libcln6   1.3.4-1
ii  libdbusmenu-qt2   0.9.2-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-2
ii  libgcc1   1:4.9.1-19
ii  libgl1-mesa-glx [libgl1]  10.3.2-1
ii  libice6   2:1.0.9-1+b1
ii  libjpeg62-turbo   1:1.3.1-11
ii  libkactivities6   4:4.13.3-1
ii  libkcmutils4  4:4.14.2-5
ii  libkdeclarative5  4:4.14.2-5
ii  libkdecore5   4:4.14.2-5
ii  libkdesu5 4:4.14.2-5
ii  libkdeui5 4:4.14.2-5
ii  libkfile4 4:4.14.2-5
ii  libkidletime4 4:4.14.2-5
ii  libkio5   4:4.14.2-5
ii  libknewstuff3-4   4:4.14.2-5
ii  libknotifyconfig4 4:4.14.2-5
ii  libkparts44:4.14.2-5
ii  libkpty4  4:4.14.2-5
ii  libkscreensaver5  4:4.11.13-2
ii  libkworkspace4abi24:4.11.13-2
ii  libnepomukcore4   4:4.14.0-1+b2
ii  libpam0g  1.1.8-3.1
ii  libphonon44:4.8.0-4
ii  libplasma34:4.14.2-5
ii  libplasmagenericshell44:4.11.13-2
ii  libpng12-01.2.50-2+b2
ii  libprocesscore4abi1   4:4.11.13-2
ii  libprocessui4a4:4.11.13-2
ii  libqalculate5 0.9.7-9
ii  libqimageblitz4   1:0.0.6-4
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-declarative4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-sql4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libsm62:1.2.2-1+b1
ii  libsolid4 4:4.14.2-5
ii  libsoprano4   2.9.4+dfsg-1.1
ii  libstdc++64.9.1-19
ii  libstreamanalyzer00.7.8-1.2+b2
ii  libudev1  215-11
ii  libusb-0.1-4  2:0.1.12-25
ii  libx11-6  2:1.6.2-3
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxft2   2.3.2-1
ii  libxi62:1.7.4-1+b2
ii  libxinerama1  2:1.1.3-1+b1
ii  libxkbfile1   1:1.0.8-1
ii  libxrandr22:1.4.2-1+b1
ii  libxrender1   1:0.9.8-1+b1
ii  libxtst6  2:1.2.2-1+b1
ii  phonon4:4.8.0-4
ii  plasma-desktop4:4.11.13-2
ii  qdbus 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  x11-utils 7.7+2
ii  x11-xserver-utils 7.7+3+b1

Versions of packages kde-workspace-bin recommends:
ii  plasma-scriptengines  4:4.11.13-2
ii  policykit-1-gnome 0.105-2
ii  polkit-kde-1  0.99.1-1
ii  upower0.99.1-3.1

Versions of packages kde-workspace-bin suggests:
ii  x11-xkb-utils  7.7+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#776701: ssd-test 1g file size too small

2015-02-16 Thread Jens Axboe

On 02/04/2015 02:10 AM, Martin Steigerwald wrote:

Hello Daniel, hi Jens,

Am Samstag, 31. Januar 2015, 14:23:34 schrieb Daniel Pocock:

Package: fio
Version: 2.1.11-2
Severity: important


In the ssd-test sample config:

https://sources.debian.net/src/fio/2.1.11-2/examples/ssd-test.fio/


The test size is 1GB, this line:

size=1g


There are SSDs that have 1g caches and this leads to unhelpful results.

One user I discussed this with had to use a 10g test file to get
consistent and meaningful results.

Maybe bump the example to 10g or add a comment in front of that line.


As the examples are taken from the upstream tarball, I suggest taking this
upstream. I put upstream in Cc, Jens, what do you think about this?


Sure, that sounds fine to me. 1G is tiny by todays standards, 10G would 
be a lot more reasonable. I'll commit that change.


--
Jens Axboe


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



Bug#778565: 215-12 does not set correct rights for hidraw devices (and others) anymore

2015-02-16 Thread Klaus Ethgen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mo den 16. Feb 2015 um 21:46 schrieb Michael Biebl:
> Am 16.02.2015 um 19:50 schrieb Klaus Ethgen:
> > Package: udev
> > Version: 215-12
> > Severity: important
> > 
> > After updating from 215-11 to 215-12, usb hidraw devices stopped to be
> > accessable by plugdev group after reboot. I only checked that rights as
> > this ist the most important for me but had also some other error
> > messages after the reboot.
> > 
> > So the system is only partial working after that update.
> 
> The udev rules shipped by the udev package do not use the plugdev group
> *at all*. I fail to see why an update of udev should have changed
> anything in that regard.

Well, it is in fact. Installing version 215-11 fixes the bug.

> And aside from that, the only udev related change in 215-12 was [1],
> which isn't relevant regarding hidraw devices.

Well, then I suspect that there got something else into that package
under the radar.

> I suspect that the problem you have lies elsewhere, but with the given
> information it's hard to tell.

Then please tell me why the problem is gone when I go back to 215-11
without changing anything else?

I believe that it is not that easy to find. But it is clearly udev
update that triggered the issue.

The point where I seen that directly is using solaar to look/configure
my logitech mouse. There is a special rule that comes with it,
/lib/udev/rules.d/60-solaar.rules, that is not working after the update.

And even more. There was many desktop notifications about late detected
devices. It was too many to see all of them. I believe that there is
something really strange happen with this update.

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJU4mkJAAoJEKZ8CrGAGfasSKEL/1ZFBd/IEWyVHWN6D+KHvByU
BG3sQwe32gwzFSiynN5kLg31gL8CcWh6+T4La9xOOIGb7xl1cn9P7mJsjxaaMVS0
YG5KRZw8rT1314pSaf2c3UkQti0ezLHXS9+3Rq2VFaZIfC51xgTVd94v7wEYziqf
nHKjdQ/f+P/7u3NvOsKFdpj49NNOxy1slxLDwCg7FY9Xby7jxSHSrAO4+gzHq4En
fOnLQnfhAGSILUrSNU9rKWBYypi/TMpQjKJ4DhAS2dlnS5IvGMwZ6w7Ib8hNU/zl
1jcdfHTpFWsJpldZfMCrtTMeMbL9PqLbAg3rBXq8+x84oQAHPuOh3ttvWrcsVpd0
o142LLDekAGSpjQSG3fP4ya2okEY/lTnLgKWRHX7t0jujreQpzpD8Hg260fg55dd
siWETB3qi1LF6LYLklx6PjZtqm4KjE6tHR4awv5ir8yUbodpP/fAUx2iLHIBMKew
WAuWSdQc9+FTR/7gDEeHDwWSwYwVCs/0wilsnrkavA==
=v3EC
-END PGP SIGNATURE-


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



Bug#776847: gsasl 1.8.0-6 does not support GSSAPI

2015-02-16 Thread Jelmer Vernooij

On 16/02/15 22:13, Simon Josefsson wrote:
> It seems clear that the #745332 fix was incorrect.  You can see in the
> build logs GSSAPI is not enabled since krb5-config isn't found:
>
> https://buildd.debian.org/status/fetch.php?pkg=gsasl&arch=amd64&ver=1.8.0-6&stamp=1412611018
>
> On considering solutions, I don't like the unpredictability in
> depending on libkrb5-dev|libheimdal-dev.  The GSSAPI library used by
> the binary libgsasl package in Debian will depend on whether the buildds
> have Heimdal or MIT installed when you built the package.  Coping with
> different GSS libraries on different architecture sounds like a recipe
> for disaster.  For Jessie, gsasl should be built against the same
> Kerberos library on all architectures, unless there is a reason not to
> -- and I don't know of a reason.  MIT is picked arbitrarily here.
>
> Cc'ing Jelmer (who reported 745332) and Andreas (who uploaded it) --
> any comments?  Jelmer, what prompted your initial report?  The way I
> see it, it is important (for us) that you buildds don't have multiple
> Kerberos development packages installed when they build gsasl.  So the
> old way was the preferred way, causing heimdal-dev to be removed and
> libkrb5-dev to be pulled in.  People with other preferences who build
> their own packages can surely modify the gsasl package to their liking.
>
> I've pushed a fix in git and attmpted to upload to experimental, so you
> can test the new packages.
The main reason for proposing this change was just to make it easier to
have heimdal-dev installed while working on other parts of the system.
At the moment, building gsasl requires uninstalling a number of packages
for me, that indirectly depend on heimdal-dev.

With the patch, the intent was to gsasl still build against MIT kerberos
- e.g. no change in the binary packages. It merely changed the
dependency from libkrb5-dev to libkrb5-multidev, the latter of which
doesn't prevent heimdal-dev from being installed.

Anyway, as you say, I can manually patch gsasl if I need to, and at the
moment I don't work on any packages that depend on libgsasl-dev. I still
think it would be nice to not have gsasl conflict with heimdal-dev, but
it's not the end of the world if it doesn't.

Cheers,

Jelmer



signature.asc
Description: OpenPGP digital signature


Bug#607543: Interested

2015-02-16 Thread Richard Winters
Is this package still in need of  a maintainer?

I believe I have a sponsor and I am looking for a way to get my foot in the
door to progress in Debian development/contribution.

RapidSVN interests me and I have other interests with Node.js with regards
to creating a web front end alternative to apache webdav.

I would explore the RapidSVN API but it doesn't necessarily mean I will use
it for said idea. My purpose for inquiry is that I'm interested in getting
started in contributing to Debian.

Please advise -


*Ri​k*


Bug#549551:

2015-02-16 Thread Matus UHLAR - fantomas

Hello,

looks like the xscreensaver violates UNIX philosophy : do one thing and do
it well.

There is dozen of other applicasions taking care of powermanagement, not
just DPMS: display brightness, HDD spindown...

"It seems that perfection is attained not when there is nothing more to add,
but when there is nothing more to remove."

please kill the DPMS handling, or at least allow us to disable it.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)


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



Bug#614394: init.d script and config file for openipmi

2015-02-16 Thread Azeem Esmail


Is the reason why I cannot get Hardware Watchdog setup properly related 
to this bug?


openipmi (2.0.16-1.4)
ipmitool (1.8.14-4)
watchdog (5.14-3)

***

The server keeps rebooting after 5 minutes. What am I doing wrong, and 
what do I need to do to get hardware watchdog working in Debian Jessie. 
Please help.



Motherboard: Supermicro X9DRH-7TF


***

List of IPMI BMC Info:

# dmidecode --type 38

# dmidecode 2.12
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.

Handle 0x003f, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x00
NV Storage Device: Not Present
Base Address: 0x0CA2 (I/O)
Register Spacing: Successive Byte Boundaries


***

Install procedure:

# apt-get install openipmi
# apt-get install ipmitool

While installing ipmitools there was an error message "Job for 
ipmievd.service failed" because /dev/ipmi0 was not created yet. I 
rebooted and reinstalled ipmitool.



# apt-get install --reinstall ipmitool


# lsmod | grep ipmi

ipmi_wathdog
ipmi_si
ipmi_poweroff
ipmi_devintf
ipmi_msghandler


# dmesg | grep ipmi

ipmi message handler version 39.2
ipmi device interface
ipmi_si: probing via ACPI
ipmi_si: 00:07: [io 0x0ca2] regsize 1 spacing 1 irq 0
ipmi_si: Adding ACPI-specified kcs state machine
ipmi_si: probing via SMBIOS
ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
ipmi_si: Adding SMBIOS-specified kcs state machine duplicate interface
ipmi_si: probing via SPMI
ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0
ipmi_si: Adding SPMI-specified kcs state machine duplicate interface

ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, 
slave address 0x0, irq0 ipmi_si: 00:07: Found new BMC (man_id: 0x002a7c, 
prod_id: 0x0664, dev_id: 0x20)


ipmi_si: 00:07: IPMI kcs interface initialized

Is there a conflict with there being duplicate interfaces, and should 
one be used in place of the other and if so how?



***

The boot time startup screen listed

watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16).
watchdog: iTCO_wdt: a legacy watchdog module is probably present.


To solve this issue I blacklisted the following modules so they would 
not load into the kernel.



iTCO-wdt
iTCO_vendor_support

Also setting the following option in '/etc/default/grub' before running 
'update-grub'



GRUB_CMDLINE_LINUX_DEFAULT="quiet nmi_watchdog=0"


While I was trouble shooting, I also blacklisted

mei
mei_me

And I used 'lsmod' to verified that none of the blacklisted modules were 
loaded into the kernel.




***

Then I install the watchdog service:

# apt-get install watchdog


I edited the watchdog daemon config file:

# nano /etc/watchdog.conf

watchdog-device=/dev/watchdog
watchdog-timeout=240
interval=20
logtick=30
realtime=yes
priority=1
admin=root
file=/var/log/messages
log-dir=/var/log/watchdog


# ipmitool mc watchdog get

Watchdog Time Use: SMS/OS (0x44)
Watchdog Time is: Started/Running
Watchdog Timer Action: Hard Reset (0x01)
Pre-timeout interval: 0 seconds
Timer Expiration Flags: 0x00
Initial Countdown: 240 sec
Present Countdown: 233 sec


# cat /var/log/syslog | grep watchdog

... watchdog[1087] :  starting daemon (5.14):
... watchdog[1087] :  int=20s realtime=yes sync=no soft=no mla=0 mem=0
... watchdog[1087] :  ping: no machine to check
... watchdog[1087] :  file: /var/log/messages:0
... watchdog[1087] :  pidfile: no server process to check
... watchdog[1087] :  interface: no interface to check
... watchdog[1087] :  temperature: no sensors to check

... watchdog[1087] : test=none(0) repair=none(0) alive=/dev/watchdog 
heartbeat=none to=root no_act=no force=no


... watchdog[1087] :  watchdog now set to 240 seconds
... watchdog[1087] :  hardware watchdog identity: IPMI


# nano /etc/default/watchdog

# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Start wd_keepalive after stopping watchdog? 0 or 1
run_wd_keepalive=1
# Load module before starting watchdog
watchdog_module="none"


# nano /etc/default/ipmievd

# This is a shell script fraction
#
# To enable ipmievd set ENABLED="true" for sysvinit (ignored by systemd)
ENABLED="false"
#
#
# Options to the daemon ipmievd(8).
#
IPMIEVD_OPTIONS=open daemon"
ENABLE=true


In addition:

While I can manually start the 'watchdog.service' and 'ipmievd.service', 
these serviced do not start automatically at boot time.



'systemctl enable ' does not enable either service with 
the following output listed:



Synchronizing state for watchdog.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d watchdog defaults
Executing /usr/sbin/update-rc.d watchdog enable

The unit files have no [Install] section. they are not ment to be 
enabled using systemctl.


...

How should I start the services automatically at boot time?


***

The motherboard has a jumper (JI2C1) for the 'I2C Bus to PCI-Exp. 
Slots'. The jumper is currenly disabled. Does this jumper need to be 
en

Bug#778388: ccache: scanner confused by comment signs in strings

2015-02-16 Thread Joel Rosdahl
Thanks. After seeing more of the code, I have been able to reproduce the
problem. It's not only related to the code you added but also to the usage
of '"' further up in the code. See attachment for a reproduction script.

The bug is not present in ccache 3.2 due to a rewrite of the relevant code.

-- Joel


On 16 February 2015 at 21:41, Oswald Buddenhagen 
wrote:

> On Mon, Feb 16, 2015 at 09:26:02PM +0100, Joel Rosdahl wrote:
> > Yes, a reduced testcase would be much appreciated. I don't have access to
> > https://codereview.qt-project.org/105039 and I wouldn't know what to do
> > anyway. :-)
> >
> oh, right, it was a draft, invite only. fixed now.
> i think you'll figure it out easily.
> anyway, cloning the whole thing seems like overkill, indeed.
> you can just get the patched version of the file from the diff view.
> from there it is extracting the code into a minimal qt/qmake project.
> i expect this to be a somewhat time-consuming iterative process, so i'm
> not exactly in a hurry ...
>
> > (BTW: You did clear the cache before you compiled the changed source
> code,
> > right? Otherwise a cache hit is expected from the previous experiments,
> of
> > course. Just checking.)
> >
> i retried with multiple string and number variants i didn't use before,
> so this is of no concern.
>
>


debian-bug-778388.sh
Description: Bourne shell script


Bug#778573: xorg: Xorg shows blank black screen at startup instead of a Display Manager.

2015-02-16 Thread Matthew Trescott
Package: xorg
Version: 1:7.7+3~deb7u1



Dear Maintainer,

   * What led up to the situation? A system update which included an update
for xorg
   * What exactly did you do (or not do) that was effective (or ineffective)?
I attempted to switch to a different Display Manager.
   * What was the outcome of this action? Nothing changed.
   * What outcome did you expect instead? I hoped that the problem was with
gdm3.



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

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

Versions of packages xorg depends on:
ii  gnome-terminal [x-terminal-emulator]  3.4.1.1-2
ii  konsole [x-terminal-emulator] 4:4.8.4-2
ii  libgl1-mesa-dri   8.0.5-4+deb7u2
ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u2
ii  libglu1-mesa  8.0.5-4+deb7u2
ii  lxterminal [x-terminal-emulator]  0.1.11-4
pn  x11-apps  
pn  x11-session-utils 
ii  x11-utils 7.7~1
pn  x11-xfs-utils 
ii  x11-xkb-utils 7.7~1
ii  x11-xserver-utils 7.7~3
ii  xauth 1:1.0.7-1
ii  xfonts-100dpi 1:1.0.3
ii  xfonts-75dpi  1:1.0.3
ii  xfonts-base   1:1.0.3
ii  xfonts-scalable   1:1.0.3-1
ii  xfonts-utils  1:7.7~1
pn  xinit 
ii  xkb-data  2.5.1-3
ii  xorg-docs-core1:1.6-1
ii  xserver-xorg  1:7.7+3~deb7u1
ii  xterm [x-terminal-emulator]   278-4

xorg recommends no packages.

Versions of packages xorg suggests:
pn  xorg-docs  

Versions of packages xserver-xorg depends on:
ii  libc6 2.13-38+deb7u7
ii  x11-xkb-utils 7.7~1
ii  xkb-data  2.5.1-3
ii  xserver-xorg-core 2:1.12.4-6+deb7u6
ii  xserver-xorg-input-all1:7.7+3~deb7u1
ii  xserver-xorg-input-evdev [xorg-driver-input]  1:2.7.0-1+b1
ii  xserver-xorg-input-mouse [xorg-driver-input]  1:1.7.2-3
ii  xserver-xorg-input-synaptics [xorg-driver-input]  1.6.2-2
ii  xserver-xorg-input-vmmouse [xorg-driver-input]1:12.9.0-1
ii  xserver-xorg-input-wacom [xorg-driver-input]  0.15.0+20120515-2
ii  xserver-xorg-video-all1:7.7+3~deb7u1
ii  xserver-xorg-video-apm [xorg-driver-video]1:1.2.3-3
ii  xserver-xorg-video-ark [xorg-driver-video]1:0.7.4-1+b1
ii  xserver-xorg-video-ati [xorg-driver-video]1:6.14.4-8
ii  xserver-xorg-video-chips [xorg-driver-video]  1:1.2.4-2
ii  xserver-xorg-video-cirrus [xorg-driver-video] 1:1.4.0-2
ii  xserver-xorg-video-fbdev [xorg-driver-video]  1:0.4.2-4+b3
ii  xserver-xorg-video-i128 [xorg-driver-video]   1:1.3.5-1+b1
ii  xserver-xorg-video-intel [xorg-driver-video]  2:2.19.0-6
ii  xserver-xorg-video-mach64 [xorg-driver-video] 6.9.1-2
ii  xserver-xorg-video-mga [xorg-driver-video]1:1.5.0-3
ii  xserver-xorg-video-neomagic [xorg-driver-video]   1:1.2.6-1
ii  xserver-xorg-video-nouveau [xorg-driver-video]1:1.0.1-5
ii  xserver-xorg-video-openchrome [xorg-driver-video] 1:0.2.906-2+deb7u1
ii  xserver-xorg-video-r128 [xorg-driver-video]   6.8.2-1
ii  xserver-xorg-video-radeon [xorg-driver-video] 1:6.14.4-8
ii  xserver-xorg-video-rendition [xorg-driver-video]  1:4.2.4-3
ii  xserver-xorg-video-s3 [xorg-driver-video] 1:0.6.3-5
ii  xserver-xorg-video-s3virge [xorg-driver-video]1:1.10.4-5
ii  xserver-xorg-video-savage [xorg-driver-video] 1:2.3.4-1
ii  xserver-xorg-video-siliconmotion [xorg-driver-video]  1:1.7.6-1
ii  xserver-xorg-video-sis [xorg-driver-video]1:0.10.4-1
ii  xserver-xorg-video-sisusb [xorg-driver-video] 1:0.9.4-3
ii  xserver-xorg-video-tdfx [xorg-driver-video]   1:1.4.4-1
ii  xserver-xorg-video-trident [xorg-driver-video]1:1.3.5-1
ii  xserver-xorg-video-tseng [xorg-driver-video]  1:1.2.4-3
ii  xserver-xorg-video-vesa [xorg-driver-video]   1:2.3.1-1+b1
ii  xserver-xorg-video-vmware [xorg-driver-video] 1:12.0.2-1+b1
ii  xserver-xorg-video-voodoo [xorg-driver-video] 1:1.2.4-2+b3

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  8.0.5-4+deb7u2


Bug#738897: Update

2015-02-16 Thread Richard Winters
After looking through I see that 2.0 is released and actively maintained.
Unless there is some reason to keep this package maintained I suppose I
should retract my claim of interest.  Sorry, looking for a package to adopt
- or somewhere I can be helpful is quite an involved process it seems -

so I've been jumping on things that seem promising - I apologize if I was
too  hasty.




*Ri​k*


Bug#778487: s3ql: Needs python-dugong >= 3.4

2015-02-16 Thread Nikolaus Rath
On Feb 16 2015, Mika Pflüger  wrote:
> Hi Nikolaus,
>
> Am Mon, 16 Feb 2015 09:42:57 -0800
> schrieb Nikolaus Rath :
>
>> > So please tighten the dependencies of s3ql 2.13 to require
>> > python3-dugong >= 3.4
>> 
>> At least according to
>> https://packages.debian.org/source/unstable/s3ql, this is exactly
>> what the dependency is.
>
> That shows the dependencies of the s3ql source package (I guess that's
[...]
> So I guess dh_python3 needs a pydist file or a py3dist-overrides file.
> Adding debian/s3ql.pydist with the contents
> dugong python3-dugong; PEP386

Gotcha. Thanks for doing all the debugging for me. It'll be fixed in the
next release (I'd upload a fixed version right away if I could, but I
don't want to bother my sponsor with too many minor uploads).

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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


signature.asc
Description: PGP signature


Bug#768352: gsasl: Does not support GSSAPI.

2015-02-16 Thread Simon Josefsson
Hi.  Thanks for the report.  It seems related to this report:

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

/Simon


pgp4mL89Z9DCa.pgp
Description: OpenPGP digital signatur


Bug#776847: gsasl 1.8.0-6 does not support GSSAPI

2015-02-16 Thread Simon Josefsson
It seems clear that the #745332 fix was incorrect.  You can see in the
build logs GSSAPI is not enabled since krb5-config isn't found:

https://buildd.debian.org/status/fetch.php?pkg=gsasl&arch=amd64&ver=1.8.0-6&stamp=1412611018

On considering solutions, I don't like the unpredictability in
depending on libkrb5-dev|libheimdal-dev.  The GSSAPI library used by
the binary libgsasl package in Debian will depend on whether the buildds
have Heimdal or MIT installed when you built the package.  Coping with
different GSS libraries on different architecture sounds like a recipe
for disaster.  For Jessie, gsasl should be built against the same
Kerberos library on all architectures, unless there is a reason not to
-- and I don't know of a reason.  MIT is picked arbitrarily here.

Cc'ing Jelmer (who reported 745332) and Andreas (who uploaded it) --
any comments?  Jelmer, what prompted your initial report?  The way I
see it, it is important (for us) that you buildds don't have multiple
Kerberos development packages installed when they build gsasl.  So the
old way was the preferred way, causing heimdal-dev to be removed and
libkrb5-dev to be pulled in.  People with other preferences who build
their own packages can surely modify the gsasl package to their liking.

I've pushed a fix in git and attmpted to upload to experimental, so you
can test the new packages.

/Simon


pgpTXn8nmJV3r.pgp
Description: OpenPGP digital signatur


Bug#778446: python-argh: Please provide Python 3 package

2015-02-16 Thread Marco Nenciarini
Il 16/02/15 10:36, Marco Nenciarini ha scritto:
> Hi Brian,
> 
> Il 15/02/15 23:26, Brian May ha scritto:
>> Attached is a patch to fix this.
>>
>> I have not attempted to update the standards version.
>>
>> I also have not attempted to update the git repository, if you want I can 
>> redo the change using git as a reference, and commit the changes to git also.
>>
>> I plan to upload this tomorrow as a NMU. It will get stuck in new for a 
>> while, so you can raise any objections if I have done anything wrong.
>>
> 
> thanks for the patch.
> I will upload this today unless I found issues.
> 

I've found two issues with unit tests included in version 0.26.1 which I was 
pushing at the same time.

Python 2.7 tests fail with

-

prompt = '\u043f\u0440\u0438\u0432\u0435\u0442? (y/n)'

def safe_input(prompt):
"""
Prompts user for input. Correctly handles prompt message encoding.
"""

if sys.version_info < (3,0):
if isinstance(prompt, compat.text_type):
# Python 2.x: unicode →  bytes
encoding = locale.getpreferredencoding() or 'utf-8'
>   prompt = prompt.encode(encoding)
E   UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 0-5: ordinal not in range(128)

-

and python 3.4 tests fail because they depends from py.test filename (which is 
py.test-3.4 in this case)

I'll try to fix them this evening, but if I fail doing that I'll upload a 
0.25.0-2 tomorrow.

Regards,
Marco

-- 
-
|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member |
| mnen...@prato.linux.it | http://www.prato.linux.it/~mnencia   |
-
Key fingerprint = 7C23 B804 3E65 D298 0A21  B6E2 589F 03F0 1BA5 5038




signature.asc
Description: OpenPGP digital signature


Bug#778388: ccache: scanner confused by comment signs in strings

2015-02-16 Thread Oswald Buddenhagen
On Mon, Feb 16, 2015 at 09:26:02PM +0100, Joel Rosdahl wrote:
> Yes, a reduced testcase would be much appreciated. I don't have access to
> https://codereview.qt-project.org/105039 and I wouldn't know what to do
> anyway. :-)
> 
oh, right, it was a draft, invite only. fixed now.
i think you'll figure it out easily.
anyway, cloning the whole thing seems like overkill, indeed.
you can just get the patched version of the file from the diff view.
from there it is extracting the code into a minimal qt/qmake project.
i expect this to be a somewhat time-consuming iterative process, so i'm
not exactly in a hurry ...

> (BTW: You did clear the cache before you compiled the changed source code,
> right? Otherwise a cache hit is expected from the previous experiments, of
> course. Just checking.)
> 
i retried with multiple string and number variants i didn't use before,
so this is of no concern.


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



Bug#778571: sbuild: predictible build location for reproducible builds

2015-02-16 Thread Vagrant Cascadian
Package: sbuild
Version: 0.65.0-1
Severity: wishlist
Tags: patch

Thanks for maintaining sbuild!

In order to use sbuild for reproducible builds, the build dir needs to
be consistent across rebuilds, but sbuild currenty generates a
randomly named build dir.


The following proof-of-concept patch does this by setting the build
dir to /build/PACKAGE-VERSION rather than /build/PACKAGE-XX:

>From 15b77405a67faaea7bc3974a4e7a3862620d0b42 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 13 Feb 2015 23:18:23 -0800
Subject: [PATCH 1/2] Make predictible build dir location based on the package
 version.

---
 lib/Sbuild/Build.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 155e4fc..5149a8a 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -396,8 +396,8 @@ sub run_chroot_session {
# TODO: Don't hack the build location in; add a means to customise
# the chroot directly.  i.e. allow changing of /build location.
$self->set('Chroot Build Dir',
-  tempdir($self->get('Package') . '-XX',
-  DIR =>  $session->get('Location') . "/build"));
+  $session->get('Location') . "/build/" . 
$self->get('Package') . "-" . $self->get('Version'));
+   mkdir $self->get('Chroot Build Dir');
 
$self->set('Build Dir', $session->strip_chroot_path($self->get('Chroot 
Build Dir')));
 
-- 
2.1.4


This patch is really only a small step forward, making the build dir
consistent only when building with sbuild. Ideally, the build dir
should be set to /usr/src/debian/PACKAGE-VERSION (or some other widely
agreed upon dir) so that builds would be reproducible if built with
other tools such as pbuilder using the same build dir.

Making the build dir configurable might also help...


live well,
  vagrant

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

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

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.0.9.6
ii  libsbuild-perl  0.65.0-1
ii  perl5.20.1-5
ii  perl-modules5.20.1-5

Versions of packages sbuild recommends:
ii  debootstrap  1.0.66
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.16-1

-- no debconf information


signature.asc
Description: PGP signature


Bug#778388: ccache: scanner confused by comment signs in strings

2015-02-16 Thread Joel Rosdahl
Yes, a reduced testcase would be much appreciated. I don't have access to
https://codereview.qt-project.org/105039 and I wouldn't know what to do
anyway. :-)

(BTW: You did clear the cache before you compiled the changed source code,
right? Otherwise a cache hit is expected from the previous experiments, of
course. Just checking.)

-- Joel

On 16 February 2015 at 20:37, Oswald Buddenhagen 
wrote:

> this is pretty incredible ...
> i can't reproduce it with your testcase, either.
> but when i run the actual build with CCACHE_LOGFILE=/dev/stdout, it
> totally confirms that the issue is real:
>
> [2015-02-16T20:25:26.035076 20314] === CCACHE STARTED
> =
> [2015-02-16T20:25:26.035222 20314] Command line: /usr/bin/ccache
> /usr/bin/g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_NO_MTDEV
> -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DPROPARSER_DEBUG
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_TESTLIB_LIB -DQT_CORE_LIB
> -DQT_NAMESPACE=TestSpace
> -DQT_TESTCASE_BUILDDIR=/home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
> -I/home/obuddenh/depot/qt5/qtbase/tests/auto/tools/qmakelib -I.
> -I/home/obuddenh/depot/qt5/qtbase/qmake/library -I../../../../include
> -I../../../../include/QtTest -I../../../../include/QtCore -I.moc
> -I/home/obuddenh/depot/qt5/qtbase/mkspecs/linux-g++ -o .obj/qmakeparser.o
> /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
> [2015-02-16T20:25:26.035255 20314] Hostname: troll08
> [2015-02-16T20:25:26.035295 20314] Working directory:
> /home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
> [2015-02-16T20:25:26.035379 20314] Source file:
> /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
> [2015-02-16T20:25:26.035393 20314] Object file: .obj/qmakeparser.o
> [2015-02-16T20:25:26.035412 20314] Trying direct lookup
> [2015-02-16T20:25:26.035865 20314] Looking for object file hash in
> /home/obuddenh/.ccache/1/8/3571b3286295ea842e4d0e4b5d8614-51629.manifest
> [2015-02-16T20:25:26.055382 20314] Got object file hash from manifest
> [2015-02-16T20:25:26.055444 20314] Unlink .obj/qmakeparser.o via
> .obj/qmakeparser.o.tmp.rm.troll08.20314
> [2015-02-16T20:25:26.055697 20314] Copying
> /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o to
> .obj/qmakeparser.o via .obj/qmakeparser.o.troll08.20314.XX
> (uncompressed)
> [2015-02-16T20:25:26.056724 20314] Created .obj/qmakeparser.o from
> /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o
> [2015-02-16T20:25:26.056755 20314] Succeeded getting cached result
> [2015-02-16T20:25:26.056793 20314] Acquired lock
> /home/obuddenh/.ccache/6/stats.lock
> [2015-02-16T20:25:26.056988 20314] Releasing lock
> /home/obuddenh/.ccache/6/stats.lock
> [2015-02-16T20:25:26.057008 20314] Unlink
> /home/obuddenh/.ccache/6/stats.lock (as-tmp)
> [2015-02-16T20:25:26.057033 20314] Result: cache hit (direct)
>
> to reproduce it, you "only" need:
>
> qtbase/dev (@1d2efe1f27bedcbaa157ef4e82b8eda33dda46ad).
> this pending change: https://codereview.qt-project.org/105039 (PS3)
> including dependencies.
> this hunk on top:
>
> --- a/qmake/library/qmakeparser.cpp
> +++ b/qmake/library/qmakeparser.cpp
> @@ -1340,6 +1374,7 @@ static bool getBlock(const ushort *tokens, int
> limit, int &offset, QString *outS
>  return false;
>  }
>  *outStr += fL1S(" << H(") + fL1S(tokNames[maskedTok]);
> +*outStr += fL1S(" /* \\u") + QString::number(maskedTok, 16) +
> fL1S(" */");
>  if (tok & TokNewStr)
>  *outStr += fL1S(" | TokNewStr");
>  if (tok & TokQuoted)
>
> ... and a lot of time, heh.
>
> i thought i might have some env variables set (CCACHE_UNIFY), but this
> doesn't appear to be the case, either.
>
> i can try to extract a smaller testcase if you don't beat me to it.
>
>


Bug#778570: sbuild: ignore .buildinfo files in .changes

2015-02-16 Thread Vagrant Cascadian
Package: sbuild
Version: 0.65.0-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Thanks for maintaining sbuild!

When using dpkg from the reproducible builds toolchain, it generates a
.buildinfo file in the .changes file:

  https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#dpkg


When .buildinfo files are present in the .changes, sbuild treats it as
an "attempted" build, rather than a successful build; it appears to be
treating the .buildinfo file as a .deb and tries to unpack it:

  ltsp_5.5.4-4~20150213~1_amd64.buildinfo
  ───

  dpkg-deb: error: 
`/«CHROOT»/«BUILDDIR»/ltsp_5.5.4-4~20150213~1_amd64.buildinfo' is not a debian 
format archive

  dpkg-deb: error: 
`/«CHROOT»/«BUILDDIR»/ltsp_5.5.4-4~20150213~1_amd64.buildinfo' is not a debian 
format archive


The following patch should fix/workaround this:

>From 8468411099b8ec28641df015742784b63b98b573 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 13 Feb 2015 23:51:11 -0800
Subject: [PATCH 2/2] Ignore .buildinfo files produced by reproducible builds.

---
 lib/Sbuild/Build.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 5149a8a..f15e94a 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1768,6 +1768,8 @@ sub build {
foreach (@debcfiles) {
my $deb = "$build_dir/$_";
next if $deb !~ /(\Q$host_arch\E|all)\.[\w\d.-]*$/;
+   # ignore .buildinfo files produced by reproducible builds.
+   next if $deb =~ /\.*buildinfo$/;
 
$self->log_subsubsection("$_");
if (!open( PIPE, "dpkg --info $deb 2>&1 |" )) {
-- 
2.1.4


live well,
  vagrant


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

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

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.0.9.6
ii  libsbuild-perl  0.65.0-1
ii  perl5.20.1-5
ii  perl-modules5.20.1-5

Versions of packages sbuild recommends:
ii  debootstrap  1.0.66
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.16-1

-- no debconf information


signature.asc
Description: PGP signature


Bug#778388: ccache: scanner confused by comment signs in strings

2015-02-16 Thread Oswald Buddenhagen
this is pretty incredible ...
i can't reproduce it with your testcase, either.
but when i run the actual build with CCACHE_LOGFILE=/dev/stdout, it
totally confirms that the issue is real:

[2015-02-16T20:25:26.035076 20314] === CCACHE STARTED 
=
[2015-02-16T20:25:26.035222 20314] Command line: /usr/bin/ccache /usr/bin/g++ 
-c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_NO_MTDEV -DQT_NO_TSLIB 
-DQT_NO_LIBINPUT -DQT_NO_XKB -DPROPARSER_DEBUG -D_LARGEFILE64_SOURCE 
-D_LARGEFILE_SOURCE -DQT_TESTLIB_LIB -DQT_CORE_LIB -DQT_NAMESPACE=TestSpace 
-DQT_TESTCASE_BUILDDIR=/home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
 -I/home/obuddenh/depot/qt5/qtbase/tests/auto/tools/qmakelib -I. 
-I/home/obuddenh/depot/qt5/qtbase/qmake/library -I../../../../include 
-I../../../../include/QtTest -I../../../../include/QtCore -I.moc 
-I/home/obuddenh/depot/qt5/qtbase/mkspecs/linux-g++ -o .obj/qmakeparser.o 
/home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
[2015-02-16T20:25:26.035255 20314] Hostname: troll08
[2015-02-16T20:25:26.035295 20314] Working directory: 
/home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
[2015-02-16T20:25:26.035379 20314] Source file: 
/home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
[2015-02-16T20:25:26.035393 20314] Object file: .obj/qmakeparser.o
[2015-02-16T20:25:26.035412 20314] Trying direct lookup
[2015-02-16T20:25:26.035865 20314] Looking for object file hash in 
/home/obuddenh/.ccache/1/8/3571b3286295ea842e4d0e4b5d8614-51629.manifest
[2015-02-16T20:25:26.055382 20314] Got object file hash from manifest
[2015-02-16T20:25:26.055444 20314] Unlink .obj/qmakeparser.o via 
.obj/qmakeparser.o.tmp.rm.troll08.20314
[2015-02-16T20:25:26.055697 20314] Copying 
/home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o to 
.obj/qmakeparser.o via .obj/qmakeparser.o.troll08.20314.XX (uncompressed)
[2015-02-16T20:25:26.056724 20314] Created .obj/qmakeparser.o from 
/home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o
[2015-02-16T20:25:26.056755 20314] Succeeded getting cached result
[2015-02-16T20:25:26.056793 20314] Acquired lock 
/home/obuddenh/.ccache/6/stats.lock
[2015-02-16T20:25:26.056988 20314] Releasing lock 
/home/obuddenh/.ccache/6/stats.lock
[2015-02-16T20:25:26.057008 20314] Unlink /home/obuddenh/.ccache/6/stats.lock 
(as-tmp)
[2015-02-16T20:25:26.057033 20314] Result: cache hit (direct) 

to reproduce it, you "only" need:

qtbase/dev (@1d2efe1f27bedcbaa157ef4e82b8eda33dda46ad).
this pending change: https://codereview.qt-project.org/105039 (PS3)
including dependencies.
this hunk on top:

--- a/qmake/library/qmakeparser.cpp
+++ b/qmake/library/qmakeparser.cpp
@@ -1340,6 +1374,7 @@ static bool getBlock(const ushort *tokens, int limit, int 
&offset, QString *outS
 return false;
 }
 *outStr += fL1S(" << H(") + fL1S(tokNames[maskedTok]);
+*outStr += fL1S(" /* \\u") + QString::number(maskedTok, 16) + fL1S(" 
*/");
 if (tok & TokNewStr)
 *outStr += fL1S(" | TokNewStr");
 if (tok & TokQuoted)

... and a lot of time, heh.

i thought i might have some env variables set (CCACHE_UNIFY), but this
doesn't appear to be the case, either.

i can try to extract a smaller testcase if you don't beat me to it.


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



Bug#778569: gnome-session-flashback: switching between different keyboard layouts does not work

2015-02-16 Thread Andrey Skvortsov
Package: gnome-session-flashback
Version: 3.8.1-7
Severity: important

Dear Maintainer,

On clean Jessie installation in GNOME flashback session I setup two keyboard
layouts (ru and us).
But layout switching does not work neither with default shortcut (Alt-Shift,
Super-Space) nor with others (Menu, Ctrl-Shift). I've not checked all possible
keyboard shortcuts settings. Layout switching is broken only in flashback
session in normal gnome session layout can be switched as expected.

As a temporary solution I installed gxneur and created script, that is started
automatically as user logs in.

#!/bin/sh
setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll us,ru
gxneur &






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

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

Versions of packages gnome-session-flashback depends on:
ii  gnome-flashback 3.10.0-3
ii  gnome-panel 3.8.1-7+b1
ii  gnome-screensaver   3.6.1-4
ii  gnome-session-bin   3.14.0-2
ii  gnome-session-common3.14.0-2
ii  gnome-settings-daemon   3.14.2-2
ii  mate-notification-daemon [notification-daemon]  1.8.1-2
ii  mate-polkit [policykit-1-gnome] 1.8.0+dfsg1-4
ii  metacity1:3.14.3-1
ii  nautilus3.14.1-2
ii  notification-daemon 0.7.6-2
ii  policykit-1-gnome   0.105-2

Versions of packages gnome-session-flashback recommends:
ii  gnome-power-manager  3.14.1-1

Versions of packages gnome-session-flashback suggests:
ii  desktop-base  8.0.2
ii  gnome-keyring 3.14.0-1+b1
ii  gnome-user-guide  3.14.1-1

-- debconf-show failed


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



Bug#775834: closed by Michael Gilbert (Bug#775834: fixed in isc-dhcp 4.3.1-6)

2015-02-16 Thread Toby Speight
reopen 775834
thanks

I'm not convinced that a change to isc-dhcp fixes this issue - did you
perhaps make a typo?


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



Bug#778437: palo: please make the build reproducible

2015-02-16 Thread Helge Deller

Hello Chris,

On 16.02.2015 00:08, Chris Lamb wrote:

With that in mind we can not use debian-specific tools like
"dpkg-parsechangelog"...


Of course. The patch was 50% to highlight/demonstrate the issue in a
concise way and 50% assuming that it would be a Debian-specific
modification.


I've pushed two changes upstream which will make the build reproducible:
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/commit/?id=db563d9c49054409959f9befbcb05d28a6d68c20
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/commit/

Thanks,
Helge


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



Bug#770492: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks

2015-02-16 Thread Josh Boyer
On Sat, Jan 17, 2015 at 6:26 PM, Ben Hutchings  wrote:
> chown() and write() should clear all privilege attributes on
> a file - setuid, setgid, setcap and any other extended
> privilege attributes.
>
> However, any attributes beyond setuid and setgid are managed by the
> LSM and not directly by the filesystem, so they cannot be set along
> with the other attributes.
>
> Currently we call security_inode_killpriv() in notify_change(),
> but in case of a chown() this is too early - we have not called
> inode_change_ok() or made any filesystem-specific permission/sanity
> checks.
>
> Add a new function setattr_killpriv() which calls
> security_inode_killpriv() if necessary, and change the setattr()
> implementation to call this in each filesystem that supports xattrs.
> This assumes that extended privilege attributes are always stored in
> xattrs.
>
> Compile-tested only.
>
> XXX This is a silent change to the VFS API, but we should probably
> change something so OOT filesystems fail to compile if they aren't
> updated to call setattr_killpriv().
>
> Reported-by: Ben Harris 
> References: https://bugs.debian.org/770492

This seems to have stalled.  I don't see it in linux-next or anywhere
else I can find.  The issue has a shiny CVE now, so it makes people
that follow those nervous.  Is there any further feedback or follow-up
here?

josh

> ---
>  drivers/staging/lustre/lustre/llite/llite_lib.c |  4 
>  fs/9p/vfs_inode.c   |  4 
>  fs/9p/vfs_inode_dotl.c  |  4 
>  fs/attr.c   | 32 
> +
>  fs/btrfs/inode.c|  4 
>  fs/ceph/inode.c |  4 
>  fs/cifs/inode.c | 11 -
>  fs/ext2/inode.c |  4 
>  fs/ext3/inode.c |  4 
>  fs/ext4/inode.c |  4 
>  fs/f2fs/file.c  |  4 
>  fs/fuse/dir.c   | 15 +++-
>  fs/fuse/file.c  |  3 ++-
>  fs/fuse/fuse_i.h|  2 +-
>  fs/gfs2/inode.c |  3 +++
>  fs/hfs/inode.c  |  4 
>  fs/hfsplus/inode.c  |  4 
>  fs/jffs2/fs.c   |  4 
>  fs/jfs/file.c   |  4 
>  fs/kernfs/inode.c   | 17 +
>  fs/libfs.c  |  3 +++
>  fs/nfs/inode.c  | 11 +++--
>  fs/ocfs2/file.c |  6 -
>  fs/reiserfs/inode.c |  4 
>  fs/ubifs/file.c |  4 
>  fs/xfs/xfs_acl.c|  3 ++-
>  fs/xfs/xfs_file.c   |  2 +-
>  fs/xfs/xfs_ioctl.c  |  2 +-
>  fs/xfs/xfs_iops.c   | 16 ++---
>  fs/xfs/xfs_iops.h   | 10 ++--
>  include/linux/fs.h  |  1 +
>  mm/shmem.c  |  4 
>  32 files changed, 176 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
> b/drivers/staging/lustre/lustre/llite/llite_lib.c
> index a8bcc51..2a714b2 100644
> --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
> +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
> @@ -1434,6 +1434,10 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr 
> *attr, bool hsm_import)
> spin_unlock(&lli->lli_lock);
> }
>
> +   rc = setattr_killpriv(dentry, attr);
> +   if (rc)
> +   return rc;
> +
> /* We always do an MDS RPC, even if we're only changing the size;
>  * only the MDS knows whether truncate() should fail with -ETXTBUSY */
>
> diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
> index 296482f..735cbf84 100644
> --- a/fs/9p/vfs_inode.c
> +++ b/fs/9p/vfs_inode.c
> @@ -1130,6 +1130,10 @@ static int v9fs_vfs_setattr(struct dentry *dentry, 
> struct iattr *iattr)
> if (S_ISREG(dentry->d_inode->i_mode))
> filemap_write_and_wait(dentry->d_inode->i_mapping);
>
> +   retval = setattr_killpriv(dentry, iattr);
> +   if (retval)
> +   return retval;
> +
> retval = p9_client_wstat(fid, &wstat);
> if (retval < 0)
> return retval;
> diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
> index 02b64f4..f3ca76d 100644
> --- a/fs/9p/vfs_inode_dotl.c
> +++ b/fs/9p/vfs_inode_dotl.c
> @@ -583,6 +583,10 @@ int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct 
> iattr *iattr)
> if (S_ISREG(inode->i_mode))
> fil

Bug#212814: Kiemelt akció

2015-02-16 Thread Wellness7
2 felnőtt + 4 év alatti gyermek részére 2
éjszakára félpanzióval, római ízvilággal,
sok finomsággal vár benneteket a Kék Duna
Wellness Hotel!


Kék Duna Wellness Hotel - Ráckeve





Eredeti ár: 61.700 Ft
Akciós ár: 41.500 Ft


Foglaláshoz fizetendő:
5.600 Ft


33% kedvezmény



Kupon Tartalma:

3 nap/2 éjszaka szállás 2 felnőtt és egy 4
év alatti gyermek részére Kis-Dunára néző
standard kétágyas szobában a Kék Duna Wellness
Hotelben
antik Római wellness részlegünk használata
szauna programok  – képzett szauna
mesterünkkel, mely a test és a lélek
harmonizálására szolgál
aerobic és vízi torna azoknak, akik fittebbnek
és egészségesebbnek szeretnék magukat érezni
Római ízvilág bemutató és kóstoló az ókori
római konyha ízvilágában




  






Dráva Hotel - Harkány (3 nap / 2 éjszaka - 2
fő)




Eredeti ár: 66.360 Ft Akciós ár: 49.900 Ft
Foglaláskor fizetendő:  7.485 Ft
25%
  




NAIH-79431/2014.
Ha nem Te adtad meg az emailcímedet, vagy nem
szeretnél a jövőben értesülni a legjobb
ajánlatokról, ide kattinva leiratkozhatsz, vagy
írj levelet az i...@wellness7.eu címre



Bug#777540: The libhtp SONAME mismatch *is* a policy violation.

2015-02-16 Thread Julien Cristau
On Fri, Feb 13, 2015 at 22:13:21 +0100, Hilko Bengen wrote:

> control: severity -1 grave
> control: block 772551 by -1
> control: tag -1 patch
> 
> In the current state of the libhtp source package, every new upstream
> release of changes the SONAME and thus requires that reverse
> dependencies (currently only suricata) are rebuilt. As long as the name
> of the binary package stays the same, eventual breakage is guaranteed,
> see #772551.
> 
> The current state defeats the purpose of shared libraries and violates
> section 8.1 ("Run-time shared libraries") of the Debian Policy Manual.
> 
> I see three possible solutions:
> 
> 1. Override upstream's decision to change the SONAME with every release.
>I am not entirelysure how stable libhtp's API/ABI should be
>considered -- looking at changes and deciding on compatibility issues
>making those decisions would certainly put a burden on the maintainer
>in the future (although the .symbols mechanism helps for obvious
>cases such as removed APIs.)
> 
>I am attaching a patch to drop the -release parameter from the
>libtool call, libhtp.so.1.0.0 (instead of libhtp-0.5.15.so.1.0.0) is
>generated. The .symbols file would need to be updated to reflect that
>change, too, of course.
> 
> 2. Since suricata is the only reverse dependency of libhtp and contains
>a copy of libhtp within its source tarball, so we could drop the
>libhtp package altogether and use that embedded copy instead, at
>least for the jessie release.
> 
> 3. Change the binary package name to reflect the SONAME -- for instance
>libhtp-0.5.15. I believe that we are too late in the freeze to be
>adding new binary package names.
> 
For jessie, 2 sounds like the best way to go IMO.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#755722: systemd must sync systemclock to RTC on shutdown

2015-02-16 Thread Stefan Fritsch
On Monday 16 February 2015 16:00:36, Michael Biebl wrote:
> > There is also natural drift between the system clock and the RTC.
> > Who  is supposed to account for that? On a system with an uptime
> > of several months, the drift may be large enough to cause the
> > time to go backwards at a reboot.
> 
> Running hwclock --systohc on shutdown does not solve the time skew
> problem.

It does not magically make the RTC run accurately. But it solves the 
problem of spurious fscks at reboot, doesn't it?

> You could use hwclocks drift calculation and call hwclock
> --adjust e.g. via a cron job. That is ugly though and it get's
> easily confused in multi-boot environments.
> A better alternative is NTP.
> Incidentally, systemd ships systemd-timesyncd, a SNTP client, which
> can easily be enabled via "systemctl enable
> systemd-timesyncd.service" and we are discussing about shipping it
> enabled by default.

I am not opposed to enabling timesyncd by default post-jessie. For 
jessie, I agree with the simpler fix posted by Martin.

I don't know what timesyncd does if no NTP server is reachable. It's 
possible that this case will need to be discussed again, but probably 
that discussion should happen in upstream's bug tracker.


-- 
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   >