> "Chris" == Chris Hofstaedtler writes:
Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.
T
> "Chris" == Chris Hofstaedtler writes:
Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.
[T
> "Andreas" == Andreas Tille writes:
>> The move to the debian namespace cannot be easily undone, as
>> those repos are protected and require an salsa admin to act on
>> e.g for (re)moving it.
Andreas> Another upload, with the removal of the Vcs fields, would
Andreas> ef
> "Santiago" == Santiago Ruano Rincón writes:
Santiago> Dear Debian fellows, I am writing this email under the
Santiago> hypothesis that having the latest (or longest supported)
Santiago> upstream version in the next release will: 1. make it
Santiago> easier to provide securit
> "Charles" == Charles Plessy writes:
Charles> Hi all, we are so diverse, that when the possibility of a
Charles> conflict of interest arises in a situation, it is too late,
Charles> because we are not even going to agree on what a conflict
Charles> of interest is, and how to
> "Russ" == Russ Allbery writes:
Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper symbol
Russ> versioning and could cause the symbols to be resolved weirdly
Russ> in a way that could cause serious bu
> "Gioele" == Gioele Barabucci writes:
Gioele> On 24/01/25 13:18, Colin Watson wrote:
>> I agree with this. From Otto in another thread:
>>
>> "It is sad to see that in Debian usage of git is stifled by
>> simple things like people not agreeing to use a common branch
> "Otto" == Otto Kekäläinen writes:
Otto> Hi,
Otto> On Thu, 23 Jan 2025 at 17:52, Wookey wrote:
Otto> ..
>> Right. I look at bug reports for my packages (eventually). I have
>> never looked at a Salsa merge request in my life. That's just
>> /dev/null for my packages.
Otto> Hi,
>> Are discussions at Salsa preserved years down the line?
Otto> confident that contents can be migrated. We already
Otto> successfully migrated git.debian.org to salsa.debian.org.
Actually, I think this is a lot of the problem.
We did not migrate all the alioth conte
> "Otto" == Otto Kekäläinen writes:
Otto> I would be curious to hear why people are *not* adopting
Otto> 'debian/latest'?
Because debian/latest is more to type and because until we adopt
something I think has a chance of getting real conformity, I am far more
interested in my own co
> "Jonas" == Jonas Smedegaard writes:
Jonas> Quoting Matthew Vernon (2025-01-23 15:28:00)
>> Otto Kekäläinen writes:
>>
>> > Numerous people are posting Merge Requests on Salsa. Please
>> help review them!
>>
>> I'd much much rather MRs were associated with bug
> "Samuel" == Samuel Thibault writes:
Samuel> And unfortunately, code that just uses PATH_MAX as
Samuel> allocation size most often do not really take care about
Samuel> this case, and then get possibly vulnerable.
Right, I'm just not sure the HURD approach is better.
The pam 1.
>>>>> "Samuel" == Samuel Thibault writes:
Samuel> Hello, Sam Hartman, le lun. 20 janv. 2025 13:21:32 -0700, a
Samuel> ecrit:
>> I will admit I was kind of disappointed that rather than working
>> to make my package handle arbitrary hostn
Please test pam from experimental.
Upstream made some significant changes including completely rewriting
the build system from autotools to meson.
I've also made some significant changes around pam_limits and when we
override limits set by systemd (now, we normally do not).
I'd love testing of
TL;DR: Is it time for the rest of Debian to stop conforming to HURD's
lack of maximums for path and hostname? By thispoint I think we
recognize those lack of maximums as an anti-pattern for DOS prevention
and other security reasons.
back in the day when I got my first HURD compatibility patch, I
>>>>> "Simon" == Simon McVittie writes:
Simon> On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
>> (We'd also need to do something about libpam0g-dev man pages).
Simon> Moving user-facing documentation from libpam0g into either
>>>>> "Simon" == Simon Richter writes:
Simon> Hi,
Simon> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook
>> tools changed between one arch build and another, we'd end up
>>>>> "Simon" == Simon McVittie writes:
Simon> On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote:
>> But the meson setup call is in override_dh_auto_configure. I
>> don't know at that point how to figure out of I am building arch
package: pam
version: 1.5.3-1
severity: wishlist
tags: help
> "Helmut" == Helmut Grohne writes:
[talking about pam manpages]
Helmut> From a package building pov, I'd appreciate if you could
Helmut> also move the tools for building the manual pages to
Helmut> Build-Depends-Indep
>>>>> "Guillem" == Guillem Jover writes:
Guillem> Hi!
Guillem> On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
>> My proposal is to move the man pages into libpam-doc. I'm not
>> actually convinced that normal Debian use
>>>>> "G" == G Branden Robinson writes:
G> At 2025-01-15T12:45:22-0700, Sam Hartman wrote:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather hav
> "Marvin" == Marvin Renich writes:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the additional
Marvin> documentation in libpam-doc. Why n
TL;DR: I propose move man pages out of a multi-arch: same package into a
arch all package. Asking for any downsides and usrmerge review.
I'm in the process of packaging pam 1.7.0. Upstream has moved from
autotools to meson and in the process has streamlined their release
tarballs to remove all or
> "Xiyue" == Xiyue Deng writes:
Xiyue> Thanks for your input! For sure if what-you-suggest happens
Xiyue> on a regular basis it would be great. I am just hoping to
Xiyue> let perspective DD sponsors have less concerns that we as
Xiyue> sponsees don't necessarily want to take
> "Andrey" == Andrey Rakhmatullin writes:
Andrey> On Wed, Dec 04, 2024 at 03:30:23PM -0800, Xiyue Deng wrote:
>> It would be great to have a group of DDs that are willing to
>> regularly check for RFS bugs / mentors.d.n and offer sponsorship
Andrey> Sure. This is true since t
> "Josh" == Josh Triplett writes:
Josh> In the future, I hope we have a more fine-grained mechanism
Josh> that allows saying "X recommends Y if Z is installed" (or even
Josh> "X depends on Y if Z is installed").
I'd really like this, both for Debian work and for downstream work o
> "Andreas" == Andreas Tille writes:
Andreas> Are there any blockers to accept this DEP which I might
Andreas> have missed?
Honestly, the git-buildpackage default layout is good enough, and dep-14
involves change that doesn't feel like it brings enough value to me.
I.E. I think t
> "Daniel" == Daniel Markstedt writes:
Daniel> Hi all, I have drafted a release of the netatalk package
Daniel> that addresses 5 critical deb bugs. However, I myself am
Daniel> only an uploader in name and don't yet have actual upload
Daniel> privileges. And my co-maintainer
> "Richard" == Richard Lewis writes:
Richard> Otto Kekäläinen writes:
>> Could you point me to some Debian Bug # or otherwise share
>> examples of cases when a build succeeded locally but failed on
>> official Debian builders due to something that is specific for
>> sbuil
> "Helmut" == Helmut Grohne writes:
Helmut> In this work, limitations with --chroot-mode=unshare became
Helmut> apparent and that lead to Johannes, Jochen and me sitting
Helmut> down in Berlin pondering ideas on how to improve the
Helmut> situation. That is a longer story, but
> "Otto" == Otto Kekäläinen writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?
Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?
I have n
> "Luca" == Luca Boccassi writes:
Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
Luca> wrote:
>>
>> Luca Boccassi writes:
>>
>> > Hence, I am not really looking for philosophical discussions or
>> lists > of personal preferences or hypotheticals, but for fact
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
>> > > If [files can be deleted automatically while mmdebstrap is using
them],
>> > > how should applications guard against that from
>> > > happening?
>> >
>> > As documented in tmpfiles.d(5), if mmdebstrap takes ou
> "Chris" == Chris Hofstaedtler writes:
Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog fi
> "Niels" == Niels Thykier writes:
Niels> # The proposal
Niels> I think our package helper tooling should just automatically
Niels> aggregate all provided substvars of the format ${*:Depends}
Niels> and append it the Depends field. Rinse and repeat for other
Niels> relati
> "Helmut" == Helmut Grohne writes:
Helmut> pam seems difficult: | extern time_t
Helmut> pam_misc_conv_warn_time; /* time that we should warn user */
Helmut> | extern time_t pam_misc_conv_die_time; /* cut-off time for
Helmut> input */
Helmut> We cannot symbol-version thes
> "Stan" == Stan Johnson writes:
Stan> sysvinit-core. But if wdm really does require systemd now,
Stan> that might explain this issue, with other X packages being
Stan> dependent on either wdm or systemd. As I recall, wdm is the
It does not look like wdm requires systemd.
I set up
There are a number of changes, and I'd just like a bit more confidence
that it works as expected before uploading to unstable in about a week.
Changes include:
* Running pam_umask with usergroups support by default.
* libpam-modules now depends on libsystemd0 because utmp is not
y2038-clean a
> "Simon" == Simon Josefsson writes:
Simon> Right, these are slightly different technical problems, but
Simon> as far as the brief discussion in the release notes --
Simon>
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking
> "Steve" == Steve Langasek writes:
>> At one level, krb5-multidev only has an rdep of 5, but I suspect
>> the rdep count for libkrb5-dev is somewhat larger:-) I don't know
>> how many packages would be removed from the transition if we
>> decide most of the krb5 libraries do
> "Steve" == Steve Langasek writes:
Steve> - In multi-library packages, there is no reliable way to map
Steve> from a set of headers in a dev package to specific shared
Steve> libraries in a runtime library package that's not
Steve> additionally computationally prohibitive; we
> "Mo" == Mo Zhou writes:
Mo> On 1/5/24 11:45, Ansgar wrote:
>> Then the package should be in main.
>>
>> We do not require external software to be free as well, be that
>> Web APIs provided by Github, Twitter, or the NVidia firmware
>> required for Nouveau, microcode
> "Paul" == Paul Wise writes:
Paul> Hi all, I have noticed that almost all Rust packages in Debian
Paul> have boilerplate long descriptions that aren't very useful to
Paul> Debian users. The only useful info is the crate name, but that
Paul> is also in the package name.
Pa
> "Christoph" == Christoph Biedl writes:
Christoph> "cups-bsd | lpr". For lpr, that might be xpaint. For
Christoph> lprng, I have no idea. And there's little chance to know.
For a long time (possibly still) MIT's printing infrastructure required
lprng and I don't think made it easy
> "Josh" == Josh Triplett writes:
Josh> If we're talking about developing a solution that doesn't
Josh> already exist, why not have that solution *be* the
Josh> notification-and-diff/show-the-defaults mechanism you're
Josh> describing? For instance, provide a declarative mecha
>>>>> "Russ" == Russ Allbery writes:
Russ> Sam Hartman writes:
>>>>>>> "Peter" == Peter Pentchev writes:
Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships i
>>>>> "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
> "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
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
> "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.
> "Roberto" == Roberto C Sánchez writes:
Roberto> sources." I mean, if you're going to wave the code of
Roberto> conduct around (or Andy in the case of the initial report),
Roberto> then perhaps we ought to distinguish between what the code
Roberto> of conduct was very clearly
> "Lucas" == Lucas Nussbaum writes:
Lucas> But unless we go further than that and decide that we don't
Lucas> care at all about 'source builds after successful builds',
Lucas> the bugs (which where filed severity:minor) remain valid.
FWIW in terms of building toward a consensus.
> "Lukas" == Lukas Märdian writes:
Lukas> That would lead to a situation where users would need to
Lukas> differentiate what system they are on when doing their
Lukas> network configuration: Debian Cloud (Netplan)
No, I think if the user is feeding configuration into a cloud image
> "nick" == nick black writes:
I consider anything that requires me to write wpa_supplicant config to
be a bad idea (unless I'm running an AP) and NetworkManager driving
wpa_supplicant is a better idea.
--Sam
> "Lukas" == Lukas Märdian writes:
Lukas> Therefore, I'd love to see Netplan to be used in combination
Lukas> with this! It's a clean, declarative configuration language
Lukas> not specifically tied to systemd-networkd as an
Lukas> implementation. So it could also be used on
> "Timo" == Timo Röhling writes:
Nod, I was wrong. Wanted to ex plicitly acknowledge that, although I
think it is also obvious from other mails.
Hi.
I have read both of your messages over the weekend multiple times.
I don't think replying point-by-point is going to be all that helpful,
although if there are any cases where you'd like me to do that, I will.
* I am really impressed with the work you are putting in on all this.
You have do
>>>>> "Helmut" == Helmut Grohne writes:
Helmut> Hi Sam,
Helmut> On Fri, Jul 07, 2023 at 08:50:49AM -0600, Sam Hartman wrote:
>>
>> TL;DR: It looks like if we do not want to encode merged /usr into
>> the bootstrap pr
> "Bastian" == Bastian Blank writes:
Bastian> On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón
wrote:
>> For the moment, ifupdown is still installed by the
>> debian-installer as default network interfaces manager. And after
>> sleeping over it, and discussing
>>>>> "Sam" == Sam Hartman writes:
Sam> TL;DR: It looks like if we do not want to encode merged /usr
Sam> into the bootstrap protocol, we must keep some aliases and
Sam> cannot move all files in data.tar. I think removing all
Sam> aliasing i
TL;DR:
It looks like if we do not want to encode merged /usr into the bootstrap
protocol, we must keep some aliases and cannot move all files in
data.tar.
I think removing all aliasing is important and so I am firmly in the
camp of doing usrmerge in the bootstrap protocol.
> "Helmut" == Helm
> "Helmut" == Helmut Grohne writes:
Helmut> I concur. Given Simon's analysis and the replies even when
Helmut> combined with earlier messages, I now see significantly more
Helmut> voices for the opinion:
Helmut> i386 primarily exists for running legacy binaries and
He
> "Russ" == Russ Allbery writes:
Russ> Helmut Grohne writes:
Russ> What Sam is trying to
Russ> say, I think, is that a different phrasing offers a way to
Russ> avoid that discussion and agree to disagree on the best
Russ> architecture in the abstract by pointing out an a
> "Helmut" == Helmut Grohne writes:
I believe I'm up on this discussion to at least comment on the consensus
calls you discuss in the mail.
Except where noted below, I support your reading of consensus.
Helmut> Consensus proposal #1:
Helmut> This updated DEP17 is a complete rep
> "Simon" == Simon Richter writes:
>> It also seems a bit strange to require more from the maintainer
>> when they are dropping an init script than we would if a
>> maintainer started depending on a feature like socket activation
>> such that their packkage simply would not wo
> "Russ" == Russ Allbery writes:
Russ> I think the open question is whether we're happy to just break
Russ> init scripts in unstable, since that migration path means
Russ> there will always be a window where a fully-upgraded unstable
Russ> system has no init script for a packa
> "Helmut" == Helmut Grohne writes:
Helmut> Moving on to category 4 feels rather obvious, especially
Helmut> because work has been done there in debootstrap. The
Helmut> approach in debootstrap however is one that I see as a dead
Helmut> end, because it causes us to maintain t
> "Helmut" == Helmut Grohne writes:
Helmut> I think at this point, we have quite universal consensus
Helmut> about the goal of moving files to their canonical location
Helmut> (i.e. from / to /usr) as a solution to the aliasing problems
Helmut> while we do not have consensus o
We've all been talking about the x86_64 ABI, and I'm realizing I'm never
read it.
Are we talking about
https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
--Sam
> "Helmut" == Helmut Grohne writes:
Helmut> Hi Luca,
Helmut> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
>> The local/external aspect is already covered in Ansgar's reply
>> and subthread.
Helmut> I hope that we can at least agree that we don't have
> "Helmut" == Helmut Grohne writes:
Helmut> Luca Boccassi kindly pointed me at config-package-dev
Helmut> though. This is a tool for generating local packages and it
Helmut> also employs dpkg-divert. There is a significant risk of
Helmut> breaking this use case. If we were to
> "Simon" == Simon McVittie writes:
Simon> You might reasonably say that "the maintainer of bar didn't
Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
Simon> and it is! - but judging by the number of "missing
Simon> Breaks/Replaces" bug reports that have to
> "Ivan" == Ivan Shmakov writes:
>> Having a bunch of problem reports that no one is interested in
>> cluttering up package pages has a cost. Just for the same
>> reasons you don't want these reports cluttering up your bugs from
>> page, I perhaps don't want them cluttering
> "Gioele" == Gioele Barabucci writes:
Gioele> For example I have opened bugs years ago against packages
Gioele> that I do not use anymore. These reports are still valid and
Gioele> sometime others comment on them, but I would no longer be
Gioele> able to, for example, respond
> "Steve" == Steve Langasek writes:
Steve> If this is for people doing out-of-archive builds who don't
Steve> want to deal with failures from -Werror, I can see how having
Steve> a single environment toggle is useful to them; but it doesn't
Steve> seem useful to *Debian* when s
Helmut> The problem here specifically arises, because we do not have
Helmut> consensus on -Werror being a bad idea in release builds.
I agree with your reading of consensus and for that reason support
registering an option to say do not use -Werror.
> "Antonio" == Antonio Terceiro writes:
Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
>>
>> On 2/21/23 15:03, Ryan Kavanagh wrote:
>> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>> > > Description : A tool for glamourous sh
> "Peter" == Peter Pentchev writes:
Peter> 3. Now, what about the `Files: debian/*` section of the
Peter> debian/copyright file? The common wisdom seems to be that, if
Peter> only to make it easier to submit patches to the upstream
Peter> project, the debian/* files ought to b
> "Peter" == Peter Pentchev writes:
Peter> Hi, So I've seen this idea floating around in the past couple
Peter> of years (and in some places even earlier), but I started
Peter> doing it for the couple of pieces of software that I am
Peter> upstream for after reading Daniel Ste
> "Fabian" == Fabian Grünbichler writes:
Fabian> All in all it seems to me like the problem currently is more
Fabian> a theoretical one - it doesn't seem to cause (much, if at
Fabian> all) additional breakage on top of stuff that is already not
Fabian> cross compilable at the m
> "Fabian" == Fabian Grünbichler writes:
Fabian> On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote:
>> Hi,
>>
>> I'm writing this mail in order to get further input from
>> knowledgeable, but not directly involved DDs - mostly those
>> involved with cross-bui
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
Johannes> This will of course just paper over the issue without
Johannes> fixing the underlying cause. It's what I called "not a
Johannes> good idea" in my last mail.
I like the explicit chgrp style because it explicitly do
> "Tomas" == Tomas Pospisek writes:
Tomas> All that said, I have never received negative feedback to
Tomas> these bug triages that I am occassionaly doing and am under
Tomas> the impression that the maintainers *do* appreciate someone
Tomas> going over their packages bugs from
> "Santiago" == Santiago Vila writes:
Santiago> El 28/1/23 a las 20:44, Sebastian Ramacher escribió:
>> On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
>>> On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
... * Those bugs are RC by definition and have been
> "Nilesh" == Nilesh Patra writes:
Nilesh> Since I had done quite a bit of work on this, I'm a sad to
Nilesh> see this happen, as fasttrack still has much less visibility
Nilesh> / availability than an official stable release, or even
Nilesh> backports.
Well, if you and a gro
> "nick" == nick black writes:
nick> it's 2023 and imho time to stop supporting unshadowed
nick> passwords from the installer.
Yes, absolutely.
I am familiar with nis/PAM/shadow/LDAP, have deployed NIS (although not
nisplus), and have been around long enough to understand the issues.
> "Andreas" == Andreas Metzler writes:
Andreas> Afaiui Graham's *question* was in response to Bastian's
Andreas> "However, please describe an actionable plan." Obviously it
Andreas> would be a lot easier if we could require to have all NEW
Andreas> uploads go to experimental in
> "Graham" == Graham Inggs writes:
Graham> Hi All
Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote:
Graham> Would it be a bad thing to require all uploads that need to
Graham> go through NEW (source and binary) to target experimental?
Graham> I have been doing t
>I wrote too early sry. A desktop app is also possible. I will use qt.
>Thanks for your time.
QT accessibility has improved a lot, but I suspect that a single page
web app with vuejs and a good widget set on top of that is going to be
more accessible than a QT app even today.
I find I stumble
> "Huỳnh" == Huỳnh Thành Hưng writes:
Huỳnh> Hi all, Special thanks to all of you, your replies really
Huỳnh> help me to know what I need to do. Weekly build image will
Huỳnh> help me reach to the target sooner than "Bookworm version".
Let us clarify a bit.
Our hope is that you
> "Reuben" == Reuben Thomas writes:
Reuben> I am a bit torn here: with my DM hat on, stripping out
Reuben> gnulib sources where possible and using Debian's gnulib
Reuben> package seems the right thing to do. With my upstream hat
Reuben> on it leads potentially to bug reports
> "Otto" == Otto Kekäläinen writes:
Otto> Instead of manually trying to manage TMPDIR env variable in
Otto> various places, we should have a standardized way to run
Otto> maintainer scripts in clean shell sessions that have all env
Otto> variables set automatically correctly.
> "Stephan" == Stephan Lachnit writes:
Stephan> On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank
wrote:
>>
>> Everyone coming up with solutions, please review the old thread
>> about that
>>
https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org
> "Steve" == Steve McIntyre writes:
Steve> Hi all! [ I've also blogged about this - see
Steve> https://blog.einval.com/2022/10/02#firmware-vote-result ]
Steve> I'm assuming that there will be no surprises and Kurt will
Steve> shortly confirm the result that devotee reported
> "Dylan" == Dylan Aïssi writes:
Dylan> We cannot talk about PipeWire without mentioning its session
Dylan> manager. Thus, this change should go along the switch of the
Dylan> default session manager, i.e. from the deprecated
Dylan> pipewire-media-session to WirePlumber. We
> "Simon" == Simon McVittie writes:
Simon> I don't think building from the least-derived form is always
Simon> the right thing to do. For instance, take rust-glib-sys, a
Simon> package of Rust bindings for the GLib library, which is one
Simon> of the libraries whose handling p
> "Andrey" == Andrey Rahmatullin writes:
Andrey> More sensible than not filing it? This defeats both
Andrey> purposes of an ITP: getting it discussed and working as a
Andrey> mutex for people who are thinking about packaging the same
Andrey> software. Are there other purposes?
> "Guillem" == Guillem Jover writes:
Guillem> Hi! There's been talk about switching away from
Guillem> netkit-telnet and netkit-telnetd as the default
Guillem> implementations for some time now, and replacing them with
Guillem> the ones from inetutils, which is a maintained p
> "Stephan" == Stephan Verbücheln writes:
Stephan> As far as I understand it, the main point of BabaSSL is to
Stephan> add support for Chinese developed ciphers and algorithms.
It looked like there were two main points.
The first was in fact these ciphers.
I don't think that's a good
>>>>> "Vincent" == Vincent Bernat writes:
Vincent> ❦ 10 May 2022 14:30 -06, Sam Hartman:
>> 2) We value being able to build from source when we can. We value
>> being able to have reproducible builds when we can. We don't want
>>
1 - 100 of 458 matches
Mail list logo
