> "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
ld of endeavor. In other words, such a license
would not be DFSG free.
--Sam
signature.asc
Description: PGP signature
> "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
which the extra space of libpam-doc would be a problem?
Unless there's a compelling need, my answer is that I don't understand
why manpages should be separated from other documentation in this instance.
--Sam
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
e that makes
it easier for Debian to grow?
* Should we have some way to remove packages (from releases if not
unstable) if they are not getting changes sponsored? How would we do
something like that without creating underground sponsorship requests?
--Sam
> "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
lly like this, both for Debian work and for downstream work on
Debian derived systems.
--Sam
> "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
ing it would be great.
I would appreciate compassion for our differences and for how that's
just not true.
There will be trade offs.
--Sam
> "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
of Fedora
have been moving to logind to handle utmp functionality.
You will start to see the first impacts of that in pam unstable.
--Sam
> "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> be worth a go?
Steve and I are unaware of usage in Debian either.
--Sam
signature.asc
Description: PGP signature
> "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
that we're limited only to libkdb5-10 and
libgssrpc4.
I would prefer not to change the abi of the other libraries, especially
libkrb5, libk5crypto3 and libgssapi-krb5-2.
What can I do to help facilitate that?
--Sam
signature.asc
Description: PGP signature
> "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
if running without CAP_SYS_ADMIN, so for it
to be effective you'd have to set it explicitly.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
> "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
.
If you have not accepted that value proposition, I think you may be
closing off design space by going that route.
Like Steve, I do not want to drive the discussion, but like Steve, I do
think the discussion needs to happen.
I strongly encourage those who value empty /etc to drive such a
discussion and to explain to the project why we want that.
--Sam
>>>>> "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
this direction, then I'll revisit how we handle this for PAM.
If Debian develops another approach for resetting local state, I'll be
eager to look at that for PAM.
--Sam
signature.asc
Description: PGP signature
> "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.
NetworkManager config is going to
have better user experience if the user later edits the config.
--Sam
>>>>> "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.
put bootstrapping behind us at
least for now and help get to a concrete proposal for canonicalizing
files, let me know.
I think that proposal will require as much review as we can get.
--Sam
signature.asc
Description: PGP signature
>>>>> "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> archite
> "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
took (and
are still using) with compiler wrapping and diffing old/new config.log
which Florian was referring to.
>
> - Oskari
>
best,
sam
signature.asc
Description: PGP signature
> "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
ed by knowing when the Debian packaging
would enter the public domain.
--Sam
owever, adding a question to the mix, why does arch all work for go
packages?
Do they not care about cross compilation, or are concerns somehow
different there?
--Sam
> "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
ing binaries in wherever we decide to move these netboot
images.
Also, I guess there's a question of whether we move the images to
non-free or non-free-firmware.
Presumably non-free-firmware would make them more available.
--Sam
signature.asc
Description: PGP signature
> "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
s with those extensions.
Such a rebuild would introduce incompatibility,
but that's okay in a local context if someone wants to do that.
Actually, it's more than okay; it's an important freedom.
--Sam
> "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
1 - 100 of 747 matches
Mail list logo
