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
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
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: 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
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
> "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.
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
- 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
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
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.
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 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
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
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
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
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
> "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
> "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
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
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 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 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 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.
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 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 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 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 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 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
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
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
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
--
32 matches
Mail list logo
