On Mon, Jul 16, 2018 at 05:59:28PM +0200, Matthias Klose wrote:
>...
> - armel: The armv4t default isn't used very much anymore,
The baseline is armv5te since last year.
> and we had issues in the past.
Could you elaborate on that?
The latest major issue I am aware of was about #727621 and the
On Tue, Aug 21, 2018 at 01:39:29PM +0800, Paul Wise wrote:
> On Tue, Aug 21, 2018 at 1:21 PM, Kentaro Hayashi wrote:
>...
> > So, I plan to make one more 3rd party keryring into Debian.
>
> That seems like a reasonable way to provide a secure mechanism to install it.
This would actually compromis
On Tue, Aug 21, 2018 at 03:41:20PM +0200, Wouter Verhelst wrote:
>...
> I agree that having a key fingerprint on a valid TLS website is less
> good than having a trust anchor in Debian,
>...
The problem is that this is a trust anchor provided by Debian.
If a user installs the Emdebian or leap.se
On Thu, Aug 23, 2018 at 05:59:45AM -0700, Sean Whitton wrote:
> Hello,
>
> On Tue 21 Aug 2018 at 10:25AM GMT, Peter Palfrader wrote:
>
> > I'm not convinced that 3rd party keyring packages belong in the Debian
> > archive.
> >
> > If the software itself is good and free, then it belongs into Debi
On Tue, Aug 21, 2018 at 04:20:14PM +0200, Adam Borowski wrote:
> On Tue, Aug 21, 2018 at 05:07:21PM +0300, Adrian Bunk wrote:
> > This also opens the general question whether 3rd party repositories
> > should become strongly discouraged in general, and flatpak/snap/...
> >
On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
>...
> For example, in the Rust team, we have been discussing about packaging fd (a
> find alternative developed using rust [1]).
> We are planning to install it in /usr/bin/fd .. but this conflicts with
> something completely diffe
On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> Dear Adrian,
Dear Chris,
> > This is fake news.
>
> Please try and avoid casual use of this term on Debian lists.
>
> Whilst I understand your meaning and intentions, the term has now been
> so overused and overapplied and has been e
On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
>...
> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare
On Wed, Mar 08, 2017 at 11:33:21PM +, Ian Jackson wrote:
> Adam Borowski writes ("Depends/Recommends from libraries"):
> > I'd like to discuss (and then propose to -policy) the following rule:
> >
> > # Libraries which don't provide a convenient means of conditionally loading
> > # at runtime
On Sun, Mar 12, 2017 at 05:36:30PM +, Simon McVittie wrote:
> Most packages in Debian that run autoreconf currently build-depend
> directly or indirectly on automake (version 1.14.1 in jessie, released
> 2013; version 1.15 in stretch/sid, released in 2015). However, 58
> packages in sid still b
On Mon, May 15, 2017 at 12:39:25PM +, Medical Wei wrote:
> As for concerns of not informative, i think the informative part should be
> placed in the wiki and/or have few recent articles in display. The home
> page should be able to attract people to use Debian rather than scaring
> people away
Both the jessie release notes [1] and the draft stretch release notes [2]
contain the following text:
5.2.1. Security status of web browsers
Debian 9 includes several browser engines which are affected by a steady
stream of security vulnerabilities. The high rate of vulnerabilities and
On Fri, May 19, 2017 at 06:43:13PM +0200, Matthias Klumpp wrote:
> 2017-05-18 19:52 GMT+02:00 Sean Whitton :
> > Hello Matthias,
> >
> > On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote:
> >> Looking at what other languages with the same problem have done, there
> >> are basically tw
On Tue, Jun 06, 2017 at 06:43:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Jun 2017, Adam Borowski wrote:
> > No one installs i386 new -- machines that are non-amd64-capable are:
> > * mainstream machines from 2004 and earlier
>
> That date is incorrect. I can't give you a precise
On Wed, Jun 07, 2017 at 03:26:35PM +0200, Christian Seiler wrote:
>...
> - You install package A, which Recommends: B, but you don't
>want B, notice that at the time, and either remove B
>afterwards, or install A with --no-install-recommends. But
>then you install package C at a later
On Thu, Jun 15, 2017 at 08:30:33PM -0700, Russ Allbery wrote:
> writes:
>
> > First of all, thank you for your kind and sympathetic message. I'm
> > referring to the second option you mentioned. We are using gcc, and it
> > seems that a reason to not use lzip in gcc is that Debian doesn't
> > sup
On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
>...
> We pretty much need Debian packages to be 100% correct in the first
> place, they are not going to be subject to lossy recovery from
> corruption (which is where lzip is supposed to be much better than xz):
> we nee
On Sun, Jul 23, 2017 at 01:54:32PM +0200, Mattia Rizzolo wrote:
>...
> Buildinfo files
> ===
>
> We have been playing with .buildinfo files [9] for more than two years,
> and dpkg finally started producing them with version 1.18.11 (Nov 2016).
>
> Some weeks later dak started to store
On Mon, Jul 24, 2017 at 09:46:27PM +0100, Chris Lamb wrote:
>...
> Related to this is how we show/expose reproducibility to end users, if it
> all. Some discussion of sorts is happening on #863622 (src:apt).
>...
How is this supposed to work for DSAs?
Do you want to claim a security update is repr
On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>...
> I've also included a purely informative change which emphasises that
> packages that are team maintained in name only should be orphaned
> properly, with their maintainer field set to the QA team. This is
> already current best p
On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > Bill Allombert writes:
> > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> >
> > >> I've also included a purely informative change which emphasises
On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert writes:
> > > > On Wed, Aug 02, 2017 at 05:48:
On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> >
> > This would not be "a purely informative change".
>
On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emai
On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost writes:
>
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recogn
On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
>
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploade
On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
>
> I agree, but that's not directly relevant here, since we'
On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
>...
> One approach as Holger points out: look for
> packages where all the recent uploads have been by the MIA member, which
> doesn't require the Uploaders field at all.
As I already tried to explain, this is an easy part that could b
On Fri, Aug 04, 2017 at 06:20:31PM -0700, Sean Whitton wrote:
> Hello,
>
> On Fri, Aug 04 2017, Adrian Bunk wrote:
>
> > Autogenerating Uploaders like GNOME does [1] would be an alternative
> > approach.
> >
> > [1]
> > https://sources.debian.net/src/g
On Sat, Aug 05, 2017 at 03:19:29PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 04:35:35PM +0200, Bill Allombert wrote:
> > > > Note that a prerequisite for such debian/changelog parsing would be
> > > > that policy sets strict syntax and semantics requirements.
> > >
> > > No, we do not
On Sat, Aug 05, 2017 at 03:28:57PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > > I don't understand this suggestion. If it can be automatically
> > > generated, just generate it when you need it -- why store it i
One thing that is worth discussing here:
For how many teams would it bring real benefits if they no longer
have to maintain team membership information in every source packages?
My guesstimate is that these might perhaps be 5 teams.
Why is my guestimate so low?
It only brings real benefits for
On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be
> done
> to deprecate Python2 usage within the distribution. It might not be possible
> to
> drop Python2 for the next release, but there are still too ma
On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be
> done
> to deprecate Python2 usage within the distribution. It might not be possible
> to
> drop Python2 for the next release, but there are still too ma
On Sat, Aug 05, 2017 at 07:53:02PM +0200, Adam Borowski wrote:
>...
> Dropping baseline support is giving up, but let's at least surrender nicely.
>
> Thus, here's a proposed solution: in unstable, there's now a bunch of
> packages that do such checking in preinst, and thus refuse (overridably) to
On Sat, Aug 05, 2017 at 04:29:34PM -0700, Russ Allbery wrote:
>...
> since teams are less likely to only have a single leaf package.
Approximate data based on grep'ing Packages[1]:
- 466 teams maintaining packages in unstable
- 8 is the median number of packages maintained by a team
- 73 teams mai
On Tue, Aug 08, 2017 at 04:47:26AM +0200, Adam Borowski wrote:
> On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote:
> > It's easy to quite reliably detect the presence of such instructions
> > (probably no one JITs such code). There's no real way to check if it's
> > executed unconditi
On Sun, Jul 30, 2017 at 02:36:03PM +0200, Steffen Möller wrote:
>
> Users will not care if it is flatpak, singularity, conda or prefix -
> they want
> all the packages and the packages shall work. What I like about all of these
> efforts is that from what I grasped we will stop caring too much abo
On Wed, Aug 09, 2017 at 11:56:32PM +0200, Adam Borowski wrote:
>...
> Thus, it'd be nice to have a way to automatically detect such cases, but I
> don't know of a anything better than testing manually. Which is extra unfun
> as any pre-sse2 (or pre-sse3) machine is crummy to the extreme, making
>
7, 2017 at 04:48:54PM +0300, Adrian Bunk wrote:
>
> Approximate data based on grep'ing Packages[1]:
> - 466 teams maintaining packages in unstable
> - 8 is the median number of packages maintained by a team
> - 73 teams maintaining a single package
>
> A package with 500
On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
>...
> I think delta debs are generally a thing we should aim to have,
>...
It sounds like something that would have been a cool feature 20 years
ago when I was downloading Debian updates over an analog modem.
Today the required
On Mon, Aug 07, 2017 at 03:42:39AM +0200, Kurt Roeckx wrote:
>...
> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.
>...
Has prior to this change any effort been made t
On Tue, Aug 15, 2017 at 05:04:50PM +0200, Kurt Roeckx wrote:
> On Tue, Aug 15, 2017 at 10:49:05PM +0900, Norbert Preining wrote:
>...
> > Do you really think that big companies like cable provides give a
> > about what Debian deprecates? I was personally fighting with similar
> > problems i
On Fri, Aug 11, 2017 at 02:52:56PM +0200, Marco d'Itri wrote:
> On Aug 11, Marco d'Itri wrote:
>
> > but I see on your link that Android pre-5.x still has a ~25% market
> > share, so unless it will drop a lot in the next year I do not think that
> > we can cut them off from Debian-based web ser
On Fri, Aug 11, 2017 at 04:11:16PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
> > Marco d'Itri wrote:
> > > On Aug 09, Sven Hartge wrote:
> >
> > >> Looking at https://developer.android.com/about/dashboards/index.html
> > >> there is still a marketsh
On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> The PCI consortium extended the deadline until June
> 2018. Assuming that deadline holds, people with older machines will not
> be able to access services such as online banking or pay onli
On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk
>...
> > Think of the "TLS 1.2 not working with WPA" discussed earlier here that
> > might still affect half a billion active Android devices at the buster
> > release date.[
On Mon, Aug 24, 2015 at 11:41:21PM +0200, Vincent Bernat wrote:
> ❦ 24 août 2015 22:30 +0100, Colin Tuckley :
>
> >> We have pushed other archive-wide goals that were not shared by
> >> all upstreams. For example, we have enabled hardening build flags
> >> on almost all packages and for packages
On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
>...
> However, based on an informal survey at DebConf (and to reflect the
> feeling towards software reproducibility in the free software community
> in general) unless there are strong objections I intend to raise the
> severity of these
On Fri, Sep 01, 2017 at 09:43:54AM +, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 09:34:53AM +0300, Adrian Bunk wrote:
> > On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> > >...
> > > However, based on an informal survey at DebConf (and to reflec
On Thu, Oct 05, 2017 at 03:52:56AM +0200, Adam Borowski wrote:
>...
> But, Adrian Bunk warned that this makes violating the baseline too easy.
> And indeed, I just noticed an attempt to use an extension in a way I don't
> consider to be valid: #864012. I understand the maint
On Sun, Oct 22, 2017 at 06:53:49PM +0800, Aron Xu wrote:
>...
> With packages like sse2-support maintainers have the option of
> creating different flavors of their packages with modern instructions
> enabled/disabled,
The opposite is true.
The result are not different flavors (which would be OK)
Hi,
for the armel port in buster the question of raising the baseline came up.
20 years ago you could go into a shop and buy a mobile phone
with a CPU supported by the armel port in stretch.
Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug
reports from users on ARMv5 hardw
On Tue, Nov 07, 2017 at 01:43:50PM +0100, Héctor Orón Martínez wrote:
>...
> 2017-11-05 22:32 GMT+01:00 Adrian Bunk :
>
> > for the armel port in buster the question of raising the baseline came up.
>
> That has been a recurring question over the time, the reason to
> mai
On Tue, Nov 07, 2017 at 11:08:39AM +0100, Julien Cristau wrote:
>
> That's not clear to me at all. Keeping armel on life support for 2 more
> years is a significant drain on DSA and our hosters,
>...
What kind of significant drain exactly?
AFAIK so far noone has stated that it would be safe to
On Tue, Nov 07, 2017 at 07:45:35PM +, Wookey wrote:
>...
> I'm very happy if people mark problematic packages that no longer
> build for armv5 as 'notforus' if no-one steps up to fix them in a
> timely fashion, but killing the architecture because some upstreams
> no-longer care about v5 seems
On Sun, Nov 05, 2017 at 08:03:00AM +, Niels Thykier wrote:
>...
> * Even if we could use a debhelper compat level to introduce R³, it
>would have neutered the adoption rate. We got plenty of packages,
>where maintainers want to have their package backportable to stable,
>oldstable
On Sat, Nov 11, 2017 at 09:03:04PM +0100, Andreas Henriksson wrote:
> Hello,
>
> On Tue, Nov 07, 2017 at 11:10:27PM +0200, Adrian Bunk wrote:
> [...]
> > This whole "so many packages are broken on armel" narrative
> > is actually mostly FUD, and you ar
On Sun, Nov 12, 2017 at 10:25:00AM +, Niels Thykier wrote:
>...
> Full list of changes in compat 11
> =
>...
> > - The cmake buildsystem now passes
> > -DCMAKE_INSTALL_RUNSTATEDIR=/run to cmake(1).
> >
> > Caveat: Th
Package: libqt5opengl5-dev
Version: 5.9.2+dfsg-4
Severity: normal
Tags: patch
Different from other architectures, on armel and armhf
Qt in Debian is configured to use OpenGL ES instead
of full OpenGL.
Some OpenGL-related functionality in Qt is not available
with OpenGL ES, and Qt also offers dire
On Wed, Nov 15, 2017 at 04:43:17PM +0100, Steffen Möller wrote:
> Hello,
>
> my QA page or our blend's task page (like
> https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
> updates that should be performed to packages I alone maintain or (more
> likely) with the help of my bl
On Mon, Nov 20, 2017 at 09:37:10AM +, Lars Brinkhoff wrote:
> Adrian Bunk wrote:
> > If anyone is running stretch, buster or sid on ARMv4t hardware, then
> > please let us know what device and kernel you are using and whether
> > you intend to use buster.
>
> M
On Mon, Nov 20, 2017 at 01:20:06PM +, Ian Jackson wrote:
>...
> I would much rather have a minimally maintained package, from Debian,
> in my stable release, than have to roll my own. This is particularly
> true if I don't know yet whether the thing is what I want. Trying
> something out from
On Thu, Nov 30, 2017 at 06:36:59PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Auto-update for sid? Auto-backport?"):
> > Sometimes I see bug reports in the BTS where it is evident that a user
> > has spent hours or days on debugging an issue and writing a mar
601 - 664 of 664 matches
Mail list logo
