-free to be autobuildable today. This
change also does not introduce this, except for everything that is to be
built on official builders to not require network access.
There are even two stages of allowlisting today (file-based and the dsc
field).
Kind regards
Philipp Kern
; > the affected packages?
>
> Fair enough. I can work on that, but help would be welcome as my
> resources are limited.
I did a test rebuild of contrib, non-free and non-free-firmware packages
in sid with both stable sbuild schroot and unshare backends and could
not find a difference in build success (i.e. what failed failed in both,
what succeeded succeeded in both).
Kind regards
Philipp Kern
On 1/21/2020 4:50 PM, Sam Hartman wrote:
>>>>>> "Philipp" == Philipp Kern writes:
>
> Philipp> I'm told it was broken by the upgrade of Apache - apparently it
> can no
> Philipp> longer do per path client certificate authentication. There
authentication. There is a pending RT
ticket from DSA to fix that but I don't think there is anything I can do at
the moment - except turn on SSO for the whole vhost. Maybe that could even
be a workaround for now and we could check if someone is annoyed by that. :)
Kind regards
Philipp Kern
On 2020-01-05 23:33, Philipp Kern wrote:
And then the following (in spirit) to base-passwd to make the systemd
allocation explicit:
--- a/README
+++ b/README
@@ -32,6 +32,9 @@ registry of allocations.
Reserved uids:
uid | name | description
llowing (in spirit) to base-passwd to make the systemd
allocation explicit:
> --- a/README
> +++ b/README
> @@ -32,6 +32,9 @@ registry of allocations.
> Reserved uids:
> uid | name | description
> --+---+-------
> +61184 | | reserved for systemd dynamic users
> + - | |
> +63433 | |
> 63434 | netplan | netplan
> 64000 | ftn | fidogate
> 64001 | mysql | mysql-server
I'd still like to hear from the systemd maintainers about their opinion
about the UID space shift and slight reduction, of course.
Kind regards and thanks
Philipp Kern
Hey,
thanks, Sam, Simon and Russ! That was all very helpful! Much appreciated!
[Adding the systemd maintainers to the Cc for Simon's question below.]
On 1/4/2020 5:08 PM, Simon McVittie wrote:
> On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote:
>> now that we are talking ag
(And then my broken keyboard driver caused this to be sent prematurely.
But alas, it's out now.)
On 1/4/2020 1:52 PM, Philipp Kern wrote:
> [Please cc me on replies as I am not currently subscribed to the list.]
>
> now that we are talking again about standardizing user creation using
&
y the system administrator, usernames created by packages
should start with an underscore." (assuming we could get a rough
consensus for something like that) in 9.2.1 for now? Or is this
effectively infeasible until we come up with a good migration story?
Kind regards
Philipp Kern
[1] https://
padding is required according to
the example but not according to the text.
Kind regards and thanks
Philipp Kern
Philipp Kern
signature.asc
Description: Digital signature
for
other suites e.g. backports. This will disable the stripping.
I find this acceptable[0]. Thanks for driving this.
Kind regards
Philipp Kern
[0] I didn't agree with the earlier suggestion of telling people to stop
the use of alternatives instead of using predictable behaviour
as a consequence of it?
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
block 611501 by 299007
severity 611501 wishlist
# It's not really security-related, as it's currently the defined and
# expected behaviour, albeit some people want to change this.
tag 611501 - security
thanks
Russ,
On Sun, Jan 30, 2011 at 11:46:23AM -0800, Russ Allbery wrote:
Philipp Kern pk
On Thu, Nov 25, 2010 at 07:45:16PM +0100, Luk Claes wrote:
On 11/25/2010 07:18 PM, Guillem Jover wrote:
On Thu, 2010-11-25 at 16:25:35 +0200, Peter Pentchev wrote:
In #509702, Philipp Kern says that a particular package's list of
architectures should be specified in the source stanza
to the global debug store.
Someone should've pointed a summary of how Ubuntu does it, it seems.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
/section.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
as they're defined in debian/control.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
you're right, we do not
impose debhelper upon everyone.
I already consider debhelper coverage as a worthy goal. :-P
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
be required to implement such functionality?
IMHO you can build single binaries that live e.g. in contrib from a package
in main so this should be a non-issue.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
20 matches
Mail list logo
