On 15/09/23 20:44, Luca Boccassi wrote:
In fact, Marco yesterday told me the only blocker to boot a minimal
Debian image with only /usr is PAM
Related: For compat >= 14 dh_installpam will install PAM modules in
/usr, not /etc:
https://salsa.debian.org/debian/debhelper/-/merge_requests/63
--
Package: wnpp
Severity: wishlist
Owner: Afeedh Shaji
* Package name: golang-github-gookit-color
Version : 1.5.4-1
Upstream Author : Gookit
* URL : https://github.com/gookit/color
* License : Expat
Programming Lang: Go
Description : A command-line color
Hi,
Today I want to propose you to change default compression format in .deb,
{data,control}.tar."xz" to ."zst".
I want to hear your thought about this.
# Compared to past change to xz proposal (in DebConf12)
There are reasons why I propose this
* More bandwidth
* More CPUs
* More
On Fri, Sep 15, 2023 at 03:17:42PM -0600, Sam Hartman wrote:
> Luca> And we can have a
> Luca> working, bootable Debian container with only /usr.
> I'm not actually convinced this is a good thing.
> (I don't think it's a bad thing--I just am not convinced it's something
> we should be work
On Sep 15, Sam Hartman wrote:
> But for the most part PAM appears to just override on a file-by-file
> basis.
Just like udev, kmod, dbus, etc...
PAM is not different.
> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the we
On Fri, Sep 15, 2023 at 07:44:45PM +0100, Luca Boccassi wrote:
> In fact, Marco yesterday told me the only blocker to boot a minimal
> Debian image with only /usr is PAM, and that's exclusively because of
> downstream-specific changes - upstream not only has supported the
> hermetic-usr config mode
On Sep 16, Josh Triplett wrote:
> If we're talking about developing a solution that doesn't already exist,
> why not have that solution *be* the
> notification-and-diff/show-the-defaults mechanism you're describing? For
> instance, provide a declarative mechanism to say "this file/directory in
>
On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with
On Fri, Sep 15, 2023 at 10:15:53PM +0200, Paul Gevers wrote:
> Hi Steve,
> On 15-09-2023 21:54, Steve Langasek wrote:
> > armel != armhf
> Of course
> > and nobody should be running armel on a NEON-capable CPU...
> Not sure why you say it like that, I guess you don't meen CI purposes here.
I m
On Fri, Sep 15 2023 at 03:00:05 PM -04:00:00, Andres Salomon
wrote:
On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers
wrote:
Hi,
On 15-09-2023 17:52, Andres Salomon wrote:
Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is
empty on
armel ci.
Sam Hartman wrote:
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that. You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
>
> I thought about doing that for Debian PAM, and have decided against.
> M
On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote:
> What's the status of throwing away the binaries when doing a non-source-only
> upload?
it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess
that nowish would be a good time to enable it.
--
cheers,
Sam Hartman writes:
>> "Peter" == Peter Pentchev writes:
> Peter> Hm, what happens if a sysadmin deliberately removed a file
> Peter> that the distribution ships in /etc, trying to make sure that
> Peter> some specific service could never possibly succeed if it
> Peter> shoul
On 2023-09-15 21:04, Sebastian Ramacher wrote:
Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
https://qa.debian.org/excuses.php?package=libcbor
Issues preventing migration:
Not built on buildd: arch amd64 binaries uploaded by bernat
Not built o
> "Peter" == Peter Pentchev writes:
Peter> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
>> On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote:
Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships in /etc, trying
> "Luca" == Luca Boccassi writes:
Luca> With the provision that I know next to nothing about pam - if
Luca> I understood correctly how it works, why not simply do both?
Luca> Ship the default file in the package under both /usr and
Luca> /etc. Then, you get the semantics you w
On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote:
> >
> >
> >
> > Apropos of the discussion about removing default configuration from
> > /etc.
> > Upstream PAM now supports doing that. You can set up a vendor directory
> > such as
On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote:
>
>
>
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that. You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
>
> I thought about doing that for Debi
Hi Steve,
On 15-09-2023 21:54, Steve Langasek wrote:
armel != armhf
Of course
and nobody should be running armel on a NEON-capable CPU...
Not sure why you say it like that, I guess you don't meen CI purposes
here. But anyways, it seems that also the arm64 host that runs our armel
and arm
Apropos of the discussion about removing default configuration from
/etc.
Upstream PAM now supports doing that. You can set up a vendor directory
such as /usr/lib where pam.d and security live.
I thought about doing that for Debian PAM, and have decided against.
My rationale is that I actually
On Fri, Sep 15, 2023 at 08:30:20PM +0200, Paul Gevers wrote:
> Hi,
> On 15-09-2023 17:52, Andres Salomon wrote:
> > Any thoughts on this?
> Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on
> armel ci.debian.net workers. (I'm failing to spot neon in the list of
> features of
On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers
wrote:
Hi,
On 15-09-2023 17:52, Andres Salomon wrote:
Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty
on
armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of
On Mon, 11 Sept 2023 at 15:09, Simon McVittie wrote:
>
> On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote:
> > An even bigger prerequisite is that many upstream projects does not yet
> > support working without /etc or (orthogonally) reading their default
> > configuration from /usr.
Hi,
On 15-09-2023 17:52, Andres Salomon wrote:
Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on
armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)
Paul
[1] https://bugs.debian.org/cgi-bin/bugreport.c
- Original Message -
> From: "Paul Tagliamonte"
> To: "Andres Salomon"
> Cc: debian-devel@lists.debian.org, "Timothy Pearson"
> , debian...@lists.debian.org
> Sent: Friday, September 15, 2023 11:29:56 AM
> Subject: Re: armhf NEON exception for chromium
> On Fri, Sep 15, 2023 at 12:18
On Fri, Sep 15, 2023 at 12:18 PM Andres Salomon wrote:
> So my proposal for chromium is this:
> a) Enable NEON for chromium's armhf build.
> b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: line,
> and fail to build if NEON is not present. This should ensure that any buildds
> "Andres" == Andres Salomon writes:
Andres> Any thoughts on this? Please explicitly Cc me on replies, as
Andres> I'm not subscribed to any of the lists.
Makes sense to me.
Hi,
The latest chromium is failing to build on armhf because upstream broke
non-NEON builds. While that is technically an upstream bug, I'm not
sure upstream is going to care enough to even accept a patch to fix it.
I understand that the baseline for the armhf architecture is to not
support N
Package: wnpp
Severity: wishlist
Owner: Yadd
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: node-sixel
Version : 0.16.0
Upstream Contact: Joerg Breitbart
* URL : https://github.com/jerch/node-sixel/
* License : Expat
Programming Lang: JavaScript
On 2023-09-15 05:03, Paul Wise wrote:
On Wed, 2023-09-13 at 21:09 +0200, Gunnar Hjalmarsson wrote:
So we have a conflict of goals here. The good news is that a user
who speaks some latin language, and who thinks it's important to be
able to easily select font directly in various applications, ca
Package: wnpp
Severity: wishlist
Owner: Tom Parkin
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: golang-github-katalix-go-l2tp
Version : 0.1.1
Upstream Contact: Tom Parkin
* URL : https://github.com/katalix/go-l2tp
* License : BSD
Programming L
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-yamlfix
Version : 1.13.0
Upstream Contact: Lyz
* URL : https://github.com/lyz-code/yamlfix
* License : GPL-3
Programming Lang: Python
32 matches
Mail list logo
