John Paul Adrian Glaubitz wrote:
> >> Why would I need to communicate that?
> > Because coordination needs involvement from all
>
> If the maintainer of a package doesn't understand which reverse
> dependencies his package has, he shouldn't be the maintainer of
> his package.
This is not a situ
>> Why would I need to communicate that?
> Because coordination needs involvement from all
If the maintainer of a package doesn't understand which reverse
dependencies his package has, he shouldn't be the maintainer of
his package.
I don't understand why you are defending his behavior. It's si
On Tue, Nov 6, 2018 at 6:53 AM Adam Borowski wrote:
> Another question: do we want it? It's beneficial only if you can not only
> add your own keys but also _remove_ built-in ones, and typical "consumer"
> machines don't allow that.
AFAICT the Debian Secure Boot packages are not designed for the
Hi,
As far as I remember there are some netbooks (from Lenovo) which cannot turn
Secure Boot off even if it is x86 based.
We can tell user to buy laptop with Coreboot + HEADS preinstalled, or laptops
that can turn Secure Boot off, but what if they are installing their existing
machine?
(I hop
Hi!
Hideki Yamane wrote:
>
> I'm curious that what is the blocker for introducing secure boot feature
> into Debian now? Already kernel, grub2 and shim are signed, then what should
> we do to achieve it?
We're just working out the last steps on the debian-efi list at the
moment.
--
Steve McInty
On Tue, 6 Nov 2018 01:09:50 +0100
Adam Borowski wrote:
> But only the stock kernel, which turns it non-free software.
Sorry, I'm not sure what you're saying.
> There's no benefits for us, too
As I said, our users can install Debian easily. It's huge benefit.
> -- a thief or attacker can bo
On Mon, 05 Nov 2018 at 13:32:40 +, Ian Jackson wrote:
> When a package does not want, specifically, this sharing, the
> dependency should be on
>default-dbus-session-bus | dbus-session-bus
This is right for packages that don't particularly care whether the
session bus is per-uid or per-log
On Tue, Nov 06, 2018 at 09:01:23AM +0900, Hideki Yamane wrote:
> On Mon, 5 Nov 2018 23:52:35 +0100
> Adam Borowski wrote:
> > Another question: do we want it? It's beneficial only if you can not only
> > add your own keys but also _remove_ built-in ones, and typical "consumer"
> > machines don't
On Mon, Nov 05, 2018 at 11:52:35PM +0100, Adam Borowski wrote:
> On Tue, Nov 06, 2018 at 04:15:31AM +0900, Hideki Yamane wrote:
> > Hi,
> > I'm curious that what is the blocker for introducing secure boot feature
> > into Debian now? Already kernel, grub2 and shim are signed, then what
> > shou
On Mon, 5 Nov 2018 23:52:35 +0100
Adam Borowski wrote:
> Another question: do we want it? It's beneficial only if you can not only
> add your own keys but also _remove_ built-in ones, and typical "consumer"
> machines don't allow that.
I disagree it. With my understand, secure boot support in D
On Tue, Nov 06, 2018 at 04:15:31AM +0900, Hideki Yamane wrote:
> Hi,
>
> I'm curious that what is the blocker for introducing secure boot feature
> into Debian now? Already kernel, grub2 and shim are signed, then what should
> we do to achieve it?
Another question: do we want it? It's benefic
Hi,
I'm curious that what is the blocker for introducing secure boot feature
into Debian now? Already kernel, grub2 and shim are signed, then what should
we do to achieve it?
--
Hideki Yamane
> > Instead of putting all the blame on
>
> Why would I need to communicate that?
Because coordination needs involvement from all
> Instead of putting all the blame on the GNOME team, maybe you could
> have expressed your concerns during the months that librsvg was still
> in experimental? Or maybe you could have said "Rust is now available
> on all release architectures, but please talk to us before uploading a
> rustified l
So I promised that I would summarise. I found that trying to write a
summary involved me doing a bit of research, and that not everyone in
the thread seemed to agree about everything. To make a coherent
picture I had to make some suppositions, which may well be wrong.
So I'd appreciate a review
Package: wnpp
Severity: wishlist
Owner: Ilias Tsitsimpis
* Package name: haskell-mustache
Version : 2.3.0
Upstream Author : Justus Adam
* URL : https://hackage.haskell.org/package/mustache
* License : BSD-3-clause
Programming Lang: Haskell
Description
On Mon, 05 Nov 2018 at 08:44:45 +0100, Philipp Kern wrote:
> Do you know if any idea was
> already floated somewhere on how to make this work? I.e. have multiple
> systemd user instances per user?
This is specifically not supported. `systemd --user` always has the
same semantics as the $XDG_RUNTIM
Hi all
This email is a followup to this earlier issue:
https://lists.debian.org/debian-devel/2018/10/msg00044.html
The TL/DR is that unfortunately I could not organize any sort of
meeting of interested parties for th meeting (which is this week).
Fortunately based on the discussion other people
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: puppet-module-antonlindstrom-powerdns
Version : 0.0.5
Upstream Author : Anton Lindström
* URL : https://github.com/antonlindstrom/puppet-powerdns
* License : GPL-2
Programming Lang: Puppe
On Mon, Nov 5, 2018 at 4:00 PM Philipp Kern wrote:
> I.e. have multiple systemd user instances per user?
That sounds strange, something like systemd session instances and
services seems more logical to me. systemd already has session scopes
so it isn't too much of a stretch to add session instanc
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: egl-wayland
Version : 1.1.0
Upstream Author : NVIDIA
* URL : https://github.com/NVIDIA/egl-wayland
* License : MIT
Programming Lang: C
Description : Wayland EGL External Platform libr
Hi Simon,
On 03.11.2018 12:11, Simon McVittie wrote:
> However, note that if you want multiple parallel dbus-daemons per uid,
> in particular one per X11 display, then dbus-user-session is not for you,
> and you should continue to use dbus-x11 or some third party implementation
> of the dbus-sessi
22 matches
Mail list logo
