On Sat, Apr 06, 2024 at 03:54:51PM +0200, kpcyrd wrote:
>...
> autotools pre-processed source code is clearly not "the preferred form of
> the work for making modifications", which is specifically what I'm saying
> Debian shouldn't consider a "source code input" either, to eliminate this
> vector
On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
> Hello,
>
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> >
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
>
On Fri, Apr 05, 2024 at 01:30:51AM +0200, kpcyrd wrote:
> On 4/5/24 12:31 AM, Adrian Bunk wrote:
> > Hashes of "git archive" tarballs are anyway not stable,
> > so whatever a maintainer generates is not worse than what is on Github.
> >
> > An
On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
>...
> I've checked both, upstreams github release page and their website[1], but
> couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> the compression is fair.
>
> [1]: https://www.vim.org/download.php
>...
Perhaps
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
>...
> I figured out a somewhat straight-forward way to check if a given `git
> archive` output is cryptographically claimed to be the source input of a
> given binary package in either Arch Linux or Debian (or both).
For Debian the proper
On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > >
On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
>...
> On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
>...
> > This seems like a serious bug in autoreconf, but I've not checked if
> > this has been brought up upstream, and whether they consider it's
> > working as
On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote:
> On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote:
>...
> > Yes, perhaps it's time to switch to a different build system, although one
> > of the reasons I've personally been putting this off is that I do a lot of
> >
On Mon, Apr 01, 2024 at 12:02:09PM +0200, Bastian Blank wrote:
> Hi
>
> On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > > What we can do unilaterally is to disallow vendoring those files.
> > These files are supposed to be vendored in release tarball
On Sat, Mar 30, 2024 at 11:55:04AM +, Luca Boccassi wrote:
>...
> In the end, massaged tarballs were needed to avoid rerunning
> autoconfery on twelve thousands different proprietary and
> non-proprietary Unix variants, back in the day. In 2024, we do
> dh_autoreconf by default so it's all
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote:
> On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > > tooling to CMake or Meson
On Sun, Mar 31, 2024 at 03:07:53AM +0100, Colin Watson wrote:
> On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote:
> > The timing of the 5.6.0 release might have been to make it into the
> > upcoming Ubuntu LTS, it didn't miss it by much.
>
> It didn't miss it at a
On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
>...
> On 2024/03/29 23:38, Russ Allbery wrote:
> > I think the big open question we need to ask now is what exactly the
> > backdoor (or, rather, backdoors; we know there were at least two versions
> > over time) did.
>
> Another
On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>...
> I'd be happy to have Debian France care about buying and having yubikeys
> delivered to any DD over the world.
Including Russia?
cu
Adrian
On Fri, Mar 29, 2024 at 11:29:01PM -0700, Russ Allbery wrote:
>...
> In other words, we should make sure that breaking the specific tactics
> *this* attacker used truly make the attacker's life harder, as opposed to
> making life harder for Debian packagers while only forcing a one-time,
> minor
On Fri, Mar 29, 2024 at 06:21:27PM -0600, Antonio Russo wrote:
>...
> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>...
git commit IDs, not tags.
Upstream moving git tags does sometimes happen.
Usually for bad-but-not-malicious reasons like "add one more
On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more
On Wed, Aug 09, 2023 at 02:26:17PM +0800, Paul Wise wrote:
> On Tue, 2023-08-08 at 18:32 +0300, Adrian Bunk wrote:
>
> > Manual opt-in for our > 11k -dev packages is a significant cost
> > that would have to be justified by the people who oppose opt-out.
>
> You
On Tue, Aug 08, 2023 at 09:19:16AM -0300, Antonio Terceiro wrote:
> On Tue, Aug 08, 2023 at 11:35:01AM +0300, Adrian Bunk wrote:
> > On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote:
> > > On 2023-08-07, Benjamin Drung wrote:
> > > > while working a wh
On Mon, Aug 07, 2023 at 06:43:36PM +, Benjamin Drung wrote:
>...
> I propose to add an autodep8 test for C/C++ header files that tries to
> compile the header file. This will catch issues like missing
> dependencies and other issues.
>...
An additional check with some overlap would be whether
On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote:
> On 2023-08-07, Benjamin Drung wrote:
> > while working a whole week on fixing failing C/C++ header compilations
> > for armhf time_t [1], I noticed a common pattern: The library -dev
> > packages was missing one or more dependencies
On Mon, Aug 07, 2023 at 09:17:18PM +, Benjamin Drung wrote:
> On Mon, 2023-08-07 at 22:52 +0300, Peter Pentchev wrote:
>...
> > 1) The library has a "main" header file that must be included before
> >any of the others, and it does not come first in lexicographical
> >order. It may
On Mon, Aug 07, 2023 at 10:09:40AM +0800, Paul Wise wrote:
> On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote:
>
> > I am late to the party but as i mentioned a couple times on debian-mips
> > already i'd like to keep mipsel as a debian-port - and i'd like to
> > revert away from mips32r2
On Sat, Aug 05, 2023 at 07:40:36PM +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote:
> > Debian maintainers with proper git workflows are already exporting all
> > their changes from git to debian/patches/ as one file - currently the
On Sat, Aug 05, 2023 at 08:55:03PM +0200, Lucas Nussbaum wrote:
> On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> > On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> > >...
> > > Packages tested: 29883 (I filtered out those that take a ver
On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote:
>...
> One way to streamline dealing with these generated files would be
> to normalize repacking of upstream source releases to exclude them,
> and make it easier to have source packages that genuinely only contain
> what we consider
On Wed, Jul 26, 2023 at 06:24:49PM +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-07-24 23:07, Adrian Bunk wrote:
> > On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> > > On Sun, 23, Jul, 2023 at 08:36:15PM +0200, Paul Gevers spoke thus..
> > > >
On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
>...
> Packages tested: 29883 (I filtered out those that take a very long time to
> build)
> .. building OK all times: 24835 (83%)
> .. failing somehow: 5048 (17%)
>...
> I wonder what we should do, because 5000+ failing packages is
On Thu, Jul 27, 2023 at 01:49:33PM +0200, Timo Röhling wrote:
>...
> However, a few Debian
> packages have also relied on the old, broken behavior, which is
> why about 30 packages have been hit by FTBFS bugs from Lucas' latest
> archive rebuild ("dh_install: error: missing files, aborting")
>...
On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> On Sun, 23, Jul, 2023 at 08:36:15PM +0200, Paul Gevers spoke thus..
> > Speaking as a member of the Release Team, but without having consulted with
> > the others, I think we're OK with the removal.
> >
> > I have not been involved in
On Sat, Mar 04, 2023 at 07:43:37PM +, Scott Kitterman wrote:
> On March 4, 2023 5:25:35 PM UTC, Adrian Bunk wrote:
> >On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
> >>
> >> This is a matter of perspective. The fact that dak doesn't store git
>
On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
> Hello,
Hi Sean,
> On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
>
> > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> >> On Sunday, 26 February 2023 20:06:
On Sun, Feb 26, 2023 at 08:25:25PM +0100, Helmut Grohne wrote:
> On Sun, Feb 26, 2023 at 07:15:45PM +0200, Adrian Bunk wrote:
> > What you describe is an RC bug as soon as the more recent toolchain
> > becomes default, and the correct solution is to not bui
On Sun, Feb 26, 2023 at 11:42:25PM +0100, Diederik de Haas wrote:
>...
> The reason that I'm such a proponent of that is that 3 weeks or 3 months from
> now, there's a reasonable chance that you (the author/committer) does no
> longer remember the details of that commit.
> In 3+ years that will
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
>...
> > For anything in Debian, the package sources in Debian would not
> > disappear when a repository (or salsa) disappears.
>
>
On Sun, Feb 26, 2023 at 07:09:59PM +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
> >
> [..]
> > Debian Policy §4.9 says that *attempting* to access the internet
> > is forbidden:
> >
> > For packages in the
On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
>...
> Apart from me not liking proprietary systems in general and M$ GitHub in
> particular, you also run the risk of things disappearing entirely without any
> notice and without any recourse.
Perhaps tomorrow some company like
On Sun, Feb 26, 2023 at 04:32:59PM +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 16:57 +0200 schrieb Adrian Bunk:
> > On Sun, Feb 26, 2023 at 03:47:49PM +0100, Daniel Leidert wrote:
> > > Am Samstag, dem 25.02.2023 um 16:15 +0200 schrieb Adrian Bunk:
> > &
On Fri, Feb 24, 2023 at 07:19:41AM +0100, Helmut Grohne wrote:
>...
> * A package adds -Werror to the build. When a new toolchain version is
>uploaded, it triggers a new warning and that makes the package FTBFS.
>...
> When building affected packages with more recent toolchains, such build
>
On Wed, Feb 22, 2023 at 07:39:09AM -0700, Sam Hartman wrote:
>
> As Jonas mentions, including the years allows people to know when works
> enter the public domain and the license becomes more liberal.
> I think our users are better served by knowing when the Debian packaging
> would enter the
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs
On Tue, Feb 14, 2023 at 04:16:33PM -0800, Steve Langasek wrote:
>...
> working out which of those reverse-dependencies are
> *not* scientific applications that should drop the build-dependency rather
> than being removed, and so forth.
>
> So it's a tradeoff between the maintenance work of
On Mon, Feb 13, 2023 at 08:05:50AM -0800, Russ Allbery wrote:
>...
> So in short I agree with Holger: it really depends. It's rude to ask
> someone to do a bunch of work when you have no intention of following
> through on that work, which happens a lot when new volunteers do bug
> triage without
On Mon, Feb 13, 2023 at 10:59:18AM +, Alastair McKinstry wrote:
>...
> > The case we should make is that "no one cares about 32-bit builds" from
> > the starting post in the GitHub issue is not true for Debian.
> > We do care that it *builds*, even if it might not be actually used.
> I've been
On Mon, Feb 13, 2023 at 10:33:51AM +, Holger Levsen wrote:
> On Sat, Feb 11, 2023 at 10:45:16PM +0200, Adrian Bunk wrote:
> > On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote:
> > > Most of us do not prefer to close bugs simply because they are old.
> >
On Thu, Feb 09, 2023 at 09:53:37AM +, Alastair McKinstry wrote:
> Hi,
>
> The push-back from upstream is that they're unconvinced anyone is actually
> using i386 for MPI.
>
> For example, MPI is configured to use PMIx but its thought that doesn't work
> on 32-bit, but no bugs have been
On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote:
>...
> Most of us do not prefer to close bugs simply because they are old.
It creates angry users and no real benefits.
> But closing bugs with a moreinfo tag when information has not been
> provided in six months to a year is likely
On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote:
> On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote:
> > I don't think such arguments are bringing us forward,
> > we should rather resolve the problem that these differ.
> >
> > All/Most(?) pa
On Sun, Jan 29, 2023 at 01:33:56AM +0100, Jonas Smedegaard wrote:
> Hi,
>
> Can someone help me understand what is going wrong in Bug#1029911?
>
> The source package build-depends on libstring-shellquote-perl but it
> seems like that build-dependency is not getting installed on the buildd.
>...
On Sat, Jan 28, 2023 at 10:23:19PM +0100, Santiago Vila wrote:
> El 28/1/23 a las 22:18, Adrian Bunk escribió:
> > On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
> > > ...
> > > The other one: There are a bunch of packages whose unit tests rely o
On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
>...
> The other one: There are a bunch of packages whose unit tests rely on tzdata.
> The tzdata
> package changes often during the lifetime of stable, and as a result, some
> package might
> stop building from source. If we wanted
On Sat, Jan 28, 2023 at 07:34:48PM +0100, Guillem Jover wrote:
> On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote:
> > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote:
> > > Unsupported by whom? What is supported or unsupported is explained in
> > > policy.
> > > Policy
On Sat, Jan 28, 2023 at 03:28:58PM +0100, Johannes Schauer Marin Rodrigues
wrote:
>...
> My proposal is to fix debootstrap #837060 (patch is in the bug report) so that
> it only installs Essential:yes, build-essential and apt and discuss if it
> makes
> sense to have packages like tzdata or
On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues
wrote:
>...
> Why do people call just accepting that Priority:required packages have to be
> part of the buildd chroot the easier solution? We just need to fix debootstrap
> bug #837060 and we are done, no?
This is mostly
On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
>...
> * Those bugs are RC by definition and have been for a long time.
>...
Please provide a pointer where a release team member has said so
explicitly in recent years.
In my experience they are usually saying that FTBFS that do
On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote:
> El 27/1/23 a las 22:37, Adrian Bunk escribió:
> > On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
...
> > I am right now looking at #1027382, and the first question is how I can
> > make apt remov
On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
> Greetings.
>
> I'm doing archive-wide rebuilds again.
>
> I've just filed 21 bugs with subject "Missing build-depends on tzdata"
> in bookworm (as tzdata is not build-essential).
>
> This is of course not fun for the maintainers,
On Wed, Sep 14, 2022 at 01:38:01PM +0200, Guillem Jover wrote:
>...
> [ Mostly to summarize the status re dpkg. ]
>...
> * Lack of bits/endianness arch "aliases" (#962848). The main problem
> with this one is that we cannot simply add such aliases, as then
> those would silently be
On Mon, Sep 12, 2022 at 04:08:08PM +0200, Tobias Frost wrote:
>...
> The problem is that if you want to exclude an arch explicitly, you have to
> list all archs you want to build it on. IOW, I'm missing an easy way to say
> "not on THIS architecture", somthing like "[!armel]"
>...
> I don't
On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote:
>...
> The issue we see is that some DDs end up setting a hardcoded list in
> the "Architecture" field, rather than just letting builds keep failing
> on these archs (and then possibly succeeding after some time whenever
> somebody
On Sun, Sep 11, 2022 at 09:25:40PM +0200, Samuel Thibault wrote:
> Paul Gevers, le dim. 11 sept. 2022 21:16:08 +0200, a ecrit:
> >
> > - color packages that "never" had a successful built on an architecture
> > different. That information is already available because that's what marks
> > the
Package: debhelper
Version: 13.8
Severity: serious
X-Debbugs-Cc: debian-devel@lists.debian.org
[ debian-devel is in Cc for getting further input. ]
dh_dwz is part of the standard sequence in dh since debhelper compat 12.
dwz offers small optimizations of debug info, the typical benefit
seems to
On Fri, Jul 15, 2022 at 07:10:55PM +, Andrew M.A. Cater wrote:
> On Fri, Jul 15, 2022 at 07:05:09PM +0300, Adrian Bunk wrote:
>...
> > Debian is not a project that fights for trans people or fights for
> > denazification or fights for whatever other non-technical top
On Thu, Jul 14, 2022 at 04:05:35PM +0200, Jeremy Bicha wrote:
>...
> Debian has a Diversity Statement [1] which says that Debian welcomes
> people regardless of how they identify themselves. Trans people and
> non-binary people face a lot of discrimination, harrassment and
> bullying around the
On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote:
>...
> The proposal is to turn on LTO by default on most 64bit release
> architectures.
>...
By what factor does -ffat-lto-objects increase disk space usage during
package builds?
Please coordinate with DSA to ensure that the
On Fri, Apr 22, 2022 at 01:41:50PM -0700, Steve Langasek wrote:
>...
> On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote:
> > I'm using NIS since 20+ years in a small network with about 60 computers.
> > Since I manage all computers and the physical network can be seen as secure
> >
On Mon, Apr 25, 2022 at 02:41:50PM -0700, Ross Vandegrift wrote:
> Hello,
Hi Ross,
> The autoremoval below has me stumped. I couldn't find any
> (build-)dependency on freeradius packages.
e17 -> connman -> openconnect -> ocserv -> freeradius
> Thanks in advance for any hints,
> Ross
cu
On Wed, Apr 06, 2022 at 01:38:09PM +0200, Adam Borowski wrote:
> On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> > On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > > * while a hard Depends: works for leafy packages, on a library it
> &
On Sun, Apr 03, 2022 at 02:42:18PM +0200, Bastian Blank wrote:
> On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> > SIMDe (or similar approaches) could be used to build variant(s) of the
> > library that have compile-time emulation of SIMD instructions in the
>
On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> Hi!
Hi Adam!
>...
> * while a hard Depends: works for leafy packages, on a library it
> disallows having alternate implementations that don't need the
> library in question. Eg, libvectorscan5 blocks a program that
> uses it
The package
> was not uploaded by its maintainer for >10 years. It received an NMU by
> Adrian Bunk (in CC as well):
>
> [2022-01-02] imgvtopgm 2.0-9.1 MIGRATED to testing (Debian testing watch)
> [2021-12-27] Accepted imgvtopgm 2.0-9.1 (source) into unstable (Adrian Bunk)
> [201
On Thu, Mar 10, 2022 at 09:49:50PM +0100, Lucas Nussbaum wrote:
>...
> For packages in (1.1) and (1.2), I propose to file Severity: wishlist
> bugs using the following template:
>
> -->8
> Subject: please consider upgrading to 3.0 source format
On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote:
>...
> (2)
> #774046 #520037
> Which special characters should we allow for account names?
>
> People demand being able to use a dot (which might break scripts using
> chown) and non-ASCII national characters in account names. The regex
On Tue, Mar 08, 2022 at 04:45:48PM +0100, Lucas Nussbaum wrote:
>...
> 1/ the arguments about using patches to track changes to upstream code.
> Among the ~600 packages in that potential MBF, there are still many that
> make changes to upstream code, which are not properly documented. I
> believe
On Tue, Mar 08, 2022 at 05:10:44PM +0100, Johannes Schauer Marin Rodrigues
wrote:
>...
> So now we have 364 source packages for which we have a patch and for which we
> can show that this patch does not change the build output. Do you agree that
> with those two properties, the advantages of the
On Tue, Mar 08, 2022 at 11:39:04AM +0100, Andreas Tille wrote:
> Hi Adrian,
Hi Andreas,
> Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk:
>...
> > lintian already warns or has info tags that should be upgraded to warning,
>
> I
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
>...
> I think that we should reduce the number of packages using the 1.0 format, as
> (1) format 3.0 has many advantages, as documented in
> https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to
> standardization of
On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote:
>...
> For the Debian package you could drop use_debian_packaged_libpcre.patch and
> use the embedded copy to not block the prce3 removal in Debian.
As a general comment, this would be a lot worse than keeping pcre3.
If any
On Tue, Nov 16, 2021 at 02:23:36PM +0100, Matthias Klose wrote:
> I'm planning to upload python3-defaults later tonight, adding 3.10 as a
> supported Python version. Packages are able to migrate on their own, there
> are
> no blockages introduced on other transitions.
>
> We have most packages
On Mon, Sep 13, 2021 at 04:05:57PM -0700, Don Armstrong wrote:
> On Fri, 10 Sep 2021, Adrian Bunk wrote:
> > On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:
> > >...
> > > I think dnspython's previous approach was correct: just like glibc, musl,
>
On Mon, Sep 13, 2021 at 08:38:52PM +, Bastien ROUCARIES wrote:
> Le lun. 13 sept. 2021 à 20:24, Adrian Bunk a écrit :
> > On Mon, Sep 13, 2021 at 08:19:31PM +0200, Stephen Kitt wrote:
>...
> > > The regressions are significant though: if packages can’t stay
> > >
On Mon, Sep 13, 2021 at 08:19:31PM +0200, Stephen Kitt wrote:
>...
> For Wine (and even a wider MinGW-w64
> ecosystem) we don’t need all that many source packages to be
> cross-satisfiable for the whole endeavour to be useful...
But you would still need to create and maintain the whole
On Sun, Sep 12, 2021 at 07:03:54PM +0200, Stephen Kitt wrote:
> On Sun, 12 Sep 2021 19:20:16 +0300, Adrian Bunk wrote:
> > On Sun, Sep 12, 2021 at 05:31:41PM +0200, Stephen Kitt wrote:
> > >...
> > > While one could imagine adding support to all the appropriate
>
On Thu, Sep 02, 2021 at 11:38:35PM +0100, Phil Morrell wrote:
>...
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>convenience copy but MUST document why in README.source and SHOULD be
>included in the [security-tracker].
>...
The package MUST be listed as being
On Sun, Sep 12, 2021 at 05:31:41PM +0200, Stephen Kitt wrote:
>...
> While one could imagine adding support to all the appropriate
> source packages to build similar “Architecture: all” packages, that would
> require convincing all the relevant maintainers,
Adding a new release architecture
On Sun, Sep 12, 2021 at 02:57:20PM +, Bastien ROUCARIES wrote:
> Le dim. 12 sept. 2021 à 14:16, Adrian Bunk a écrit :
> >
> > On Sun, Sep 12, 2021 at 01:57:44PM +, Bastien ROUCARIES wrote:
> > >
> > > I think you misunderstand:
> > &g
On Sun, Sep 12, 2021 at 01:57:44PM +, Bastien ROUCARIES wrote:
>
> I think you misunderstand:
> https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches
>
> They are a full color gradiant between:
> - freestanding arches pure cross compile without any depends except arch:all
> - partial
On Sun, Sep 12, 2021 at 01:18:11PM +, Bastien ROUCARIES wrote:
> Le dim. 12 sept. 2021 à 07:38, Adrian Bunk a écrit :
> >
> > On Sun, Sep 05, 2021 at 08:53:49AM +0200, Bastien ROUCARIES wrote:
> > >...
> > > Improve dpkg to support partial arch. I volonteer t
On Sun, Sep 05, 2021 at 08:53:49AM +0200, Bastien ROUCARIES wrote:
>...
> Improve dpkg to support partial arch. I volonteer to implement none arch
> but i am waiting from guillem here.
>...
There is also plenty of infrastructure on the buildd, archive and
release team sides that would likely
On Sat, Sep 04, 2021 at 08:17:53PM -0500, Zebediah Figura wrote:
> Hello all,
>
> I'm a contributor to the Wine project. To summarize the following mail, Wine
> needs special versions of some of its normal dependencies, such as
> libfreetype and libgnutls, built using the MinGW cross-compiler,
On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:
>...
> I think dnspython's previous approach was correct: just like glibc, musl, and
> other libraries, if /etc/resolv.conf is missing they should treat that as
> though it specified a nameserver on localhost.
How libraries implement
On Thu, Sep 09, 2021 at 04:45:35AM +, Paul Wise wrote:
>...
> That seems like a bug in the test cases, they shouldn't be testing the
> build time environment like that, since it could differ from the
> runtime environment.
These are usually not the tests of dnspython.
dnspython even has some
On Wed, Sep 08, 2021 at 05:44:34PM +0200, Helmut Grohne wrote:
> On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote:
> > Do anybody on the list have any opinion on where is the bug, on
> > dnspython, or on the build environment?
>
> I concur that the absence of /etc/resolv.conf is a
On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:
> On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand
> wrote:
> > Therefore, I am in the opinion that we should let the package run its
> > test as much as possible, especially considering that it's not doing
> >
On Tue, Sep 07, 2021 at 04:41:49PM -0700, Don Armstrong wrote:
> On Mon, 06 Sep 2021, Mattia Rizzolo wrote:
> > It must be noted that no actual network operation happen, so this
> > doesn't fall into the "no network activity" bucket.
> >
> > This is the bug that was filed against dnspython:
> >
On Fri, Jul 09, 2021 at 10:28:57AM +0200, Helmut Grohne wrote:
>...
> I also disagree with the need to go through NEW more than once. The new
> package could quite simply be named libsystemd-private and lack a
> .symbols and .shlibs file. Internal users would always use (=
> ${binary:Version})
On Tue, Apr 20, 2021 at 11:59:31AM +0200, Philipp Kern wrote:
> On 2021-04-20 10:59, Adrian Bunk wrote:
> > I would suggest to replace the option of shortening the discussion
> > period with the possibility of early calling for a vote after a week
> > that can be vetoed by an
On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
>...
> * The length of the discussion period is ill-defined in multiple ways,
> which has repeatedly caused conflicts. It only resets on accepted
> amendments but not new ballot options, which makes little logical sense
> and
On Mon, Apr 19, 2021 at 12:31:51PM -0700, Steve Langasek wrote:
>...
> IMHO, it's better to have a vote quickly on a limited set of GR options,
> with the possibility of a second GR if there is sufficient dissatisfaction
> with the first GR outcome, than to have community energy spent endlessly on
On Mon, Apr 19, 2021 at 06:37:01PM +0200, Simon Richter wrote:
> Hi,
Hi Simon,
> On Sun, Apr 18, 2021 at 04:56:34PM +0300, Adrian Bunk wrote:
>
> > Is it really still an open question whether Debian is a political
> > project that has opinions on non-technical
1 - 100 of 1145 matches
Mail list logo
