date:20141027

Bug#766757: Generated services should start After=systemd-user-sessions.service

2014-10-27 Thread Alexandre Detiste

control: tags -1 + fixed-upstream

Ok, I've added After=systemd-user-sessions.service 
 RequiresMountsFor=/home/folder 
for user crontabs + /var/spool/cron/crontabs/root .

https://github.com/systemd-cron/systemd-cron/commit/98ae11e0341f5c955c9de08778de9de3bafd459b
 


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

Bug#766949: sks: init script doesn't fail when sks can't bind to address

2014-10-27 Thread Christoph Anton Mitterer

Package: sks
Version: 1.1.5-2
Severity: normal



Hi.

This is basically a follow up to #766943.

Apparently sks' initscript doesn't fail, even when sks couldn't
bind to an address, e.g.:

# systemctl -l status sks.service 
● sks.service - (null)
   Loaded: loaded (/etc/init.d/sks)
   Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
  Process: 1991 ExecStart=/etc/init.d/sks start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/sks.service
   ├─2043 /usr/sbin/sks db
   └─2046 /usr/sbin/sks recon

Oct 27 06:52:22 kronecker systemd[1]: sks.service changed dead - start
Oct 27 06:52:22 kronecker systemd[1991]: Executing: /etc/init.d/sks start
Oct 27 06:52:22 kronecker sks[1991]: Starting sks daemons: sksdb.. sksrecon.. 
done.
Oct 27 06:52:22 kronecker systemd[1]: Child 1991 belongs to sks.service
Oct 27 06:52:22 kronecker systemd[1]: sks.service: control process exited, 
code=exited status=0
Oct 27 06:52:22 kronecker systemd[1]: sks.service got final SIGCHLD for state 
start
Oct 27 06:52:22 kronecker systemd[1]: sks.service changed start - running
Oct 27 06:52:22 kronecker systemd[1]: Job sks.service/start finished, 
result=done
Oct 27 06:52:22 kronecker systemd[1]: Started (null).
Oct 27 06:52:23 kronecker sks[1991]: 2014-10-27 06:52:23 Failed to listen on 
2a01:4f8:a0:4024::2:2:11370: Failure(Failure while binding socket.  Probably 
another socket bound to this address)



Now I think it's quite clear, that having failed to bind to an iface
should be considered a critical errror (since the service
won't be usable) and thus the init-script should fail as well
and not let e.g. systemd believe that everything got right.


Cheers,
Chris.


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

Bug#765406: [Pkg-gnupg-maint] Bug#765406: please add dependency on pinentry-gtk2

2014-10-27 Thread Eric Dorland

* Michael Biebl (bi...@debian.org) wrote:
 Am 26.10.2014 um 01:04 schrieb Eric Dorland:
  * Michael Biebl (bi...@debian.org) wrote:
  Am 24.10.2014 um 06:39 schrieb Eric Dorland:
  Hmmm, are you talking about gnome-keyring? It actually hijacks the
  gpg-agent protocol and breaks some things (see http://b/760102). You
  still need the pinentry program if you disable gnome-keyright AFAIK.
 
  Couldn't that warning message also include hints to install pinentry-gtk2?
  
  It could but just installing it won't fix anything by itself, you need
  to disable the agent functionality in gnome-keyring. Which some people
  will do to work around the bug, and if they do it would be nice if
  they had a graphical pinentry.
 
 Sure. The message could say: If you disable the gnome-keyring
 integration, make sure to install an alternative pinentry program like
 pinentry-gtk2
 
 Problem solved.

I mean not really problem solved, perhaps a slightly better
explanation. I still think it makes sense to install it pinentry-gtk2
with the gnome desktop task but I can live without if you object.

-- 
Eric Dorland e...@kuroneko.ca
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: Digital signature

Bug#766939: wanna-build: Wanna-build considers alternatives, but buildds don't, causing futile builds

2014-10-27 Thread Johannes Schauer

Hi,

On Mon, 27 Oct 2014 02:27:01 + Wookey woo...@wookware.org wrote:
 Is this a wanna-build bug?

you could also see this as a dose3 bug.

dose-builddebcheck does not eliminate all but the first build dependency as
sbuild does it. Maybe even worse, for it the order of a disjunction does not
matter at all. I see two solutions.  Either wanna-build modifies the build
dependencies before passing them to dose-builddebcheck or I add an option to
dose-builddebcheck to remove build dependencies in disjunctions just as sbuild
does. Doing the latter is probably the right way to do it in the long term but
this will come too late for Jessie.  Thus, you probably have to do the former
anyways until Jessie+1.

In fact, botch already has a utility solving this (because I also stumbled over
this problem a while ago) called botch-remove-virtual-disjunctions. It's a
short Python script which, in case of source packages, modifies
build-dependencies just as sbuild would so that they can then be handled by
dose3.

If you nevertheless think that adding such a feature to dose-builddebcheck
would be a good idea, please file a wishlist bug against dose-builddebcheck so
that the issue does not get lost. I'll see if I can take care of the problem
after the Jessie release.

cheers, josch


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

Bug#766943: systemd: server no longer gets networking after switching to systemd

2014-10-27 Thread Christoph Anton Mitterer

On Mon, 2014-10-27 at 06:56 +0100, Christoph Anton Mitterer wrote: 
 # systemctl -l status sks.service 
 ● sks.service - (null)
Loaded: loaded (/etc/init.d/sks)
Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
   Process: 1991 ExecStart=/etc/init.d/sks start (code=exited, 
 status=0/SUCCESS)
...
 Oct 27 06:52:23 kronecker sks[1991]: 2014-10-27 06:52:23 Failed to listen on 
 2a01:4f8:a0:4024::2:2:11370: Failure(Failure while binding socket.  Probably 
 another socket bound to this address)

FYI: I've reported the problem, that sks returns success, even though it
couldn't start up successfully as: #766949.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#766950: Start up fails if any root cert is a dangling symlink

2014-10-27 Thread Daniel Pocock

Package: repro

Start up fails if any root cert is a dangling symlink


-- 
http://danielpocock.com


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

Bug#682006: Gnus ignores marks from imap server

2014-10-27 Thread Arto Jantunen

Rob Browning r...@defaultvalue.org writes:

 Arto Jantunen vi...@debian.org writes:

 The Gnus version included in Emacs 24 ignores any marks set on an imap
 server, including is the message read or not. This makes the imap
 support of Gnus unusable for the main thing imap is used for (sharing
 one mailbox between multiple client applications). This works normally
 in Emacs 23, so this is a regression.

 Is this still a problem?

 If so, can you elaborate a bit on your situation?  (I'm assuming that
 Gnus normally handles this better, or we'd have heard more
 complaints.)

As I thought, this does happen on upgrade from Emacs 23 to 24, and can
be cleared by removing .newsrc.eld. Some incompatibility with the file
format, perhaps?

-- 
Arto Jantunen


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

Bug#766815: installation-reports: please omit quiet option

2014-10-27 Thread lee

Ben Hutchings b...@decadent.org.uk writes:

 On Sun, 2014-10-26 at 02:44 +0100, lee wrote:
 [...]
 I strongly recommend to change the installer to *not* use the quiet
 option.  Especially with the installer, there is much point in being
 able to see all messages, and not everyone installs Debian on up-to-date
 and/or fully known hardware.

 No, it is important to see the *error* messages.  The bug is that this
 error message is suppressed when 'quiet' is used.

This message is probably not the only error message you don't see when
quiet is used.  IIRC, you don't see it when the killing of modprobe is
being delayed.  I'll have to verify.

 Besides, the quiet option shouldn't be used by default after the
 installation has completed, either.
 [...]

 It is the correct default.  Those *expert* users who feel able to
 interpret the extra information that may be logged to the console are
 exactly the users that are most likely to know how to override this
 default.

You don't have to be that expert user to be able to figure out that
something isn't right when you see the messages, and you cannot expect
everyone to know about this option and how it may hide problems.  I've
been using Debian for over 20 years and didn't know it would hide so
much.  I only found out about it by chance and tried it in desperation.

So I don't understand what should be correct about hiding potentially
important and valuable information from users by default.  It seems far
more logical to display such information until the user has verified
that everything works, in which case they can add this option if they
want.

Users who want as much as possible hidden from them can use other OSs.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.


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

Bug#766920: initramfs-tools: update-initramfs makes system unbootable due to missing rootfs

2014-10-27 Thread Richard Lucassen

On Mon, 27 Oct 2014 00:54:54 +
Ben Hutchings b...@decadent.org.uk wrote:

  After a reboot, the system is unbootable due to a missing rootfs.
 [...]
 
 We support hexadecimal device numbers in the 'root=' kernel parameter
 when booting, but do not expect to see them at build time in the mount
 table.
 
 Please provide the output of 'mount' on one such system.

Sorry, I forgot to mention that:

# mount | grep 803
803 on / type ext4
(rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)

(this is another system that had the same problem btw)
 
 You are recommended to specify the root device on the kernel command
 line using the syntax 'root=UUID=...'

I use lilo:

boot=/dev/sda
root=/dev/sda3
map=/boot/map
delay=20
compact
prompt
timeout=20
default=Linux

image=/vmlinuz
label=Linux
read-only
initrd=/initrd.img

[..]

I tried both, UUID= and /dev/sda3 in /etc/fstab, but the result was the
same. I haven't tried lilo.conf yet. I'll let you know.

BTW, UUID is great for mounting removable devices, but for fixed
devices it may be problem: you cannot simply copy images to a disk
without adapting the UUID. E.g.: I run a big number of devices and the
disks are copies of a central image. Using UUID would make things more
complex than using /dev/sdX in that case.

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+


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

Bug#766939: wanna-build: Wanna-build considers alternatives, but buildds don't, causing futile builds

2014-10-27 Thread Kurt Roeckx

On Mon, Oct 27, 2014 at 02:27:01AM +, Wookey wrote:
 Package: wanna-build
 Severity: normal
 
 Sometimes packages go round and round on the builds, trying to be
 built repeatedly, because wanna-build thinks that the build-deps are
 availbale, but when sbuild tries the build it finds them
 unsatisfiable.
 
 This appears to happen when Build-Depends has alternatives. It seems
 that wanna-build considers it OK if any of the alternatives are
 available, even though buildds only take the first option.
 
 My current example is openmeeg. This build-deps on 
 libtiff4-dev | libtiff-dev

We pass this to edos to check it.  But as far as I know we strip
the | libtiff-dev part both in wanna-build for edos and in
sbuild for apt.  So I really have no idea why edos thinks it's
installable and apt thinks it's not installable and edos thinks
it is.


Kurt


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

Bug#494156: please support Fujitsu fi-6xxx series

2014-10-27 Thread Jörg Frings-Fürst

Hello,

on[1] a lot of Fujitsu fi-6xxx supported with complete and good.

So I close this bug.

CU
Jörg


[1] 
http://www.sane-project.org/cgi-bin/driver.pl?manu=fujitsumodel=bus=anyv=p=
-- 
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8  EBCB 422B 44B0 BE58 1B6E
pgp Key: BE581B6E
CAcert Key S/N: 0E:D4:56

Jörg Frings-Fürst
D-54526 Niederkail

Threema-ID: SYR8SJXB

IRC: j_...@freenode.net, j_...@oftc.net

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

Bug#766929: SSL handshake failed (fail to connect to sites that only support TLS1.0)

2014-10-27 Thread Laurent Bigonville

Le Sun, 26 Oct 2014 16:52:18 -0700,
Troy Sankey sankey...@gmail.com a écrit :

Hello,

I've added the maintainers of openssl and gnutls in the loop, sorry for
the noise.

When I use any web browser (that uses libsoup) to access the URL
https://be.my.ucla.edu/ I get the following error:

Unable to load page
Problem occurred while loading the URL https://be.my.ucla.edu/
SSL handshake failed

Affected web browsers include midori, dwb, uzbl, surf, and luakit.
Browsers that work for me are firefox and rekonq, both of which don't
use libsoup. I haven't tried Chromium.

The openssl command line program successfully connects to the server:

$ printf GET / HTTP/1.1\n\n | \
openssl s_client -ign_eof -connect be.my.ucla.edu:443
[...]
HTTP/1.1 302 Please Wait
[...]

See full output in the attachment openssl.txt

Thanks for the bug report.

libsoup seems to use GnuTLS instead of openssl. I just tried with wget
which is also using GnuTLS and I also get an error:

$ wget -O - https://be.my.ucla.edu/
--2014-10-27 08:11:49-- https://be.my.ucla.edu/
Resolving be.my.ucla.edu (be.my.ucla.edu)... 128.97.52.156
Connecting to be.my.ucla.edu (be.my.ucla.edu)|128.97.52.156|:443... connected.
HTTP request sent, awaiting response... 302 Please Wait
Location:
https://shb.ais.ucla.edu/shibboleth-idp/profile/Shibboleth/SSO?shire=https%3A%2F%2Fbe.my.ucla.edu%2FShibboleth.sso%2FSAML%2FPOSTtime=1414393910target=cookie%3A1414393910_8276providerId=https%3A%2F%2Fbe.my.ucla.edu%2Fshibboleth-sp%2F
[following]
--2014-10-27 08:11:50--
https://shb.ais.ucla.edu/shibboleth-idp/profile/Shibboleth/SSO?shire=https%3A%2F%2Fbe.my.ucla.edu%2FShibboleth.sso%2FSAML%2FPOSTtime=1414393910target=cookie%3A1414393910_8276providerId=https%3A%2F%2Fbe.my.ucla.edu%2Fshibboleth-sp%2F
Resolving shb.ais.ucla.edu (shb.ais.ucla.edu)... 164.67.228.230
Connecting to shb.ais.ucla.edu (shb.ais.ucla.edu)|164.67.228.230|:443...
connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.

As you can see there is a redirection, to shb.ais.ucla.edu.

Running both openssl s_client and gnutls-cli on this URL gives me an
error. Forcing openssl to use TLS1.0 works. (Not sure how to do the
same with gnutls-cli though).

Also Running the following external test tool on this url gives a
warning:
This site is intolerant to newer protocol versions, which might cause
connection failures.
See: https://www.ssllabs.com/ssltest/analyze.html?d=shb.ais.ucla.edu

So it seems that both openssl and gnutls have issues with this (and
probably all the) sites that are only supporting tls1.0.

I also had issues in the past (with both debian and ubuntu) when trying
to connect some old linksys AP. Other users running Arch where able to
connect to it. This might be related.

1 2 3 4 5 >

1 - 100 of 420 matches

Mail list logo