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 need
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 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 cro
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 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 (parti
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 wi
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 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
infrastruc
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 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 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 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 co
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 pac
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 absolutely agree here.
>
&g
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 3
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 t
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 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
>
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)
> [2
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
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 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 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
Adrian
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 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 buildd
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 wor
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
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 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 pack
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 co
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 actual
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 consid
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, b
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 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 not
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 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 e2fsp
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 says
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 t
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 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 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(?) p
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 fi
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 report
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.
> > It cr
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 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 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 keeping
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 refere
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 publ
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
> f
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 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 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 mai
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.
>
> Question
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 b
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 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:26 CET Adrian Bunk w
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 Fri, Feb 14, 2020 at 10:56:47AM -0600, John Goerzen wrote:
>
> The thing that we have to remember is that an operating system is a
> platform for running software. This problem is rather thorny, because:
>
> 1) Some software is provided in only binary form and cannot be
> recompiled
>
> 2) S
On Thu, May 21, 2020 at 10:44:01PM +0200, Daniel Lange wrote:
>...
> We do suggest that attendees begin making travel arrangements as soon as
> possible, of course. Please bear in mind that most air carriers allow
> free cancellations and changes.
>...
Please bear in mind that this is not true.
F
On Mon, Jun 01, 2020 at 10:28:48PM +0400, Jerome BENOIT wrote:
> Hello,
Hi Jerome,
> the package e-antic that I maintain is currently blocked in Sid because
> it failed to build on the mips64el according to Build status [1].
> However, I could not reproduce the failure on the Debian porter.
> How
On Mon, Jun 22, 2020 at 06:45:50PM +0100, Simon McVittie wrote:
> > On Mon, 2020-06-22 at 17:50 +0200, Michael Biebl wrote:
> > > there has been a lot of talk recently about how master is a loaded term
> > > that should be avoided.
> > > If I read the news correctly, github and others are going to
On Fri, Jul 03, 2020 at 07:50:55PM +0200, Jérémy Lal wrote:
>...
> One can install nodejs 10 along with libnode64, and build node-iconv
> using libnode-dev 12 which links to libnode72.
>
> However, running node-iconv tests in the autopkgtests environment requires
> the nodejs version that is linke
On Mon, Jul 20, 2020 at 03:05:26AM +, Paul Wise wrote:
> On Mon, Jul 20, 2020 at 1:40 AM Yao Wei wrote:
>
> > There's a serious bug when I am uploading afdko package, that one of the
> > binaries in this package "tx" has name conflicting with
> > transifex-client.
>
> As transifex-client is c
On Mon, Jul 20, 2020 at 09:35:35AM +0800, Yao Wei wrote:
>...
> I am currently considering doing it by moving all binaries of afdko from
> /usr/bin to /usr/bin/afdko, and then creating another package
> afdko-legacy, that, similar to node-legacy before node changed the name
> to ax25-node, symlinks
On Mon, Jul 20, 2020 at 11:52:15PM +, Paul Wise wrote:
> On Mon, Jul 20, 2020 at 6:48 PM Adrian Bunk wrote:
>...
> > If we start allowing conflicts between completely unrelated packages
> > it might not end well in the long run.
>
> We already have had situation
On Tue, Jul 28, 2020 at 12:41:42PM +0200, Matthias Klose wrote:
>...
> Suggested ways to solve these issues:
>
> - Use plain shlibs files, without using symbols files, although
>debhelper wrongly warns about missing symbols files.
Usually this is the better option for C++ libraries,
for more
On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote:
> I'm maintaining mlpack. It is able to generate julia bindings, so on
> architectures in which julia is available I'd like to generate julia
> bindings, and this requires julia to be installed at build time. I've
> set up debian
On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote:
>...
> "Build-Depends-If-Available: foo" as "Build-Depends: foo | something"
> is a bad idea from the get-go. After all, foo can have three states on
> an architecture: installable, unavailable, or
> available-but-uninstallable-f
On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
>...
> Historically, versions of these packages were shipped by the third-party
> deb-multimedia.org apt repository. That would have been fine, except that
> the maintainer(s) of deb-multimedia.org added an epoch to their versions.
> I
On Mon, Aug 17, 2020 at 10:01:53AM +, Holger Levsen wrote:
> hi,
>
> debian-security-support | 2019.12.12~deb8u2 | jessie-security |
> source, all
> debian-security-support | 2020.06.21~deb9u1 | stretch |
> source, all
> debian-security-support | 2020.06.21~deb
On Sat, Aug 22, 2020 at 05:05:36PM +0300, Andrei POPESCU wrote:
> On Lu, 17 aug 20, 10:21:37, Simon McVittie wrote:
> >
> > Jeremy Bicha contacted deb-multimedia.org and arranged for babl and gegl
> > to be dropped from the third-party repository, which fixes this problem
> > for new installations
On Wed, Sep 07, 2016 at 09:26:37AM -0700, Russ Allbery wrote:
>...
> Full disclosure: several of my packages in the archive have similar tests.
> Those tests are part of the upstream test suite for the getaddrinfo and
> getnameinfo replacement functions for OSes that are too old to have them.
> The
On Wed, Sep 21, 2016 at 10:56:10AM -0700, Russ Allbery wrote:
>...
> If no one is ever going to look at the bug again, just close it. It feels
> more confrontational, but it's far more honest, and it doesn't create
> unrealistic expectations.
>...
"no one is ever going to look at the bug again" i
On Wed, Sep 21, 2016 at 12:50:41PM -0700, Russ Allbery wrote:
>...
> But still, despite all of those caveats, I do think there are a few things
> that are fairly clear-cut. If the package has 3,000 open bugs, just close
> out the unactionable reports in some polite and constructive way. At that
>
(Cc-ing ftpmaster, debian-devel)
On Tue, Oct 04, 2016 at 07:05:09PM +0200, Emilio Pozuelo Monfort wrote:
> (Cc-ing debian-a11y)
>
> Hi,
Hi Emilio,
> On 30/09/16 13:03, Andreas Henriksson wrote:
> > While the patch would solve the RC bug and get dasher back into
> > testing, I'm hesitant to assi
On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote:
>...
> As frustrating as occasional removal/reintroduction cycles are, they are rare
> enough that despite the frustration when they occur it's really not worth the
> effort it would take to avoid them completely.
This assumes that
On Thu, Oct 06, 2016 at 02:46:46PM -0400, Scott Kitterman wrote:
>
>
> On October 6, 2016 8:51:59 AM EDT, Adrian Bunk wrote:
> >On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote:
> >>...
> >> As frustrating as occasional removal/reintroduction cy
[ adding debian-powerpc ]
On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working. Pe
On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> >
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier schrieb:
> >
On Sat, Oct 15, 2016 at 02:03:36PM -0400, Paul Tagliamonte wrote:
>...
> So, the real question:
>
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
>...
This is actually only the server-side part of the problem,
On Sun, Oct 16, 2016 at 02:14:47PM +, lumin wrote:
> Hi there,
>
> I encountered an unexpected FTBFS on amd64 that I can't repro.[1]
> And I'd like to ask the list before fixing it by e.g. an binary
> only upload.
>
> My package lua-torch-torch7/experimental fails[2] to build from
> source be
On Mon, Oct 17, 2016 at 03:10:57AM +0100, Ben Hutchings wrote:
> On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote:
> [...]
> > You should fix your package so that it works on the lowest supported
> > hardware of each port.
>
> Right.
>
> > Autobuilding is
On Mon, Oct 17, 2016 at 10:28:53PM +0200, Eduard Bloch wrote:
> Hallo,
> * Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]:
> > Hi,
> >
> > On 17 October 2016 at 18:57, Sruthi Chandran wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Sruthi Chandran
> > > X-Debbugs-CC: debian-devel
On Tue, Oct 18, 2016 at 04:15:50PM +0100, Steve McIntyre wrote:
>...
> Life's too short to go and fix all the crap in the world personally,
> but we can keep certain minimum standards for what we as a group allow
> into Debian. :-(
What policies and processes should ensure these minimum standards?
On Wed, Oct 19, 2016 at 09:33:14AM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, Oct 19, 2016, at 06:56, Jan Mojzis wrote:
> > >I read manpage on github, but did not understood, what exactly this
> > > program provides. Can it replace creation system users for dropping
> > > privileges?
> >
On Fri, Oct 21, 2016 at 08:55:26AM +0200, Jan Mojzis wrote:
> > "extremely outdated"?
> >
> > This sounds like a hack from ~ 20 years ago when people realized that
> > running several programs at the same time as nobody does not isolate
> > them from each other.
> >
> > Much better solutions for
On Sun, Oct 23, 2016 at 06:04:50AM -0700, Kristian Erik Hermansen wrote:
>...
> The main issue is that a well positioned attacker, such as the NSA or
> Chinese router admins, have the ability to collect and analyze in
> real-time what systems have installed what patches installed by
> monitoring th
On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>...
> The value of HTTPS lies in its protection against passive snooping. Given
> the sad state of the public CA infrastructure, you cannot really protect
> against active MITM with HTTPS without certificate pinning.
You are implicite
On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote:
> but also I should point out that your email is being routed
> insecurely via welho.com and lacks TLS in transit, so I also probably
> shouldn't
On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: When should we https our mirrors?"):
>...
> Adrian:
> > Noone is arguing that switching to https would be a bad thing,
> > but whether or not it will happen depends solely on whe
On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>
> >>...
> >> The value of HTTPS lies in its protection against passive snooping. Given
> >> the sad sta
On Mon, Oct 24, 2016 at 04:33:57PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > I would assume this can be pretty automated, and that by NSA standards
> > this is not a hard problem.
>
> Since the entire exchange is encrypted, it's not completely
On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote:
> On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote:
> > The current policy says:
> > "As to the static libraries, the common case is not to have relocatable
> > code"
> >
> > As of gcc-6 version 6.2.0-7 this is factua
On Thu, Oct 27, 2016 at 08:41:12AM -0200, Henrique de Moraes Holschuh wrote:
>...
> That said, Thaddeus, if you do go ahead with the upload please check if
> you can minimize that size somehow, even just a 10% drop in size would
> already be worth the work it took for something big like this.
>...
On Sun, Oct 30, 2016 at 04:02:48PM +, Ian Jackson wrote:
>...
> Most of our packages use `make' or something like it. make relies on
> timestamps to decide what to rebuild. It seems that sometimes our
> source packages contain combinations of timestamps (and perhaps stamp
> files) which, in p
On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote:
>...
> * Source for generated files in the tarball: should be in both git and
> tarball, but sometimes mistakenly omitted from tarballs (e.g. configure.ac,
> m4/foo.m4, build-aux/git-version-gen). Leaving these out of the tarball i
On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"):
> > Be prepared to see a lot of such issues when you touch random files.
>
> I'm certainly expecting to see lots of issues.
>
On Mon, Oct 31, 2016 at 03:58:12PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more
> messages]"):
> > On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote:
> ...
> > > If it does "sufficiently diff
401 - 500 of 674 matches
Mail list logo
