Re: Rebuilds with unexpected timestamps

On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote: >... > Personally I think a Linux kernel tarball, without accompanying git > history, is a GPL violation. >... Why would the git *history* matter for GPL compliance? You can push from a shallow clone. > Ian. cu Adrian -- "Is

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

On Mon, Oct 31, 2016 at 03:23:51PM +0100, Bálint Réczey wrote: > Hi Ian, > > 2016-10-31 14:19 GMT+01:00 Ian Campbell : > > On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote: > >> 2016-10-31 10:38 GMT+01:00 Ian Campbell : > >> > If possible I'd also prefer a solution which fixed qcontrol-stati

Re: NRSS has been deprecated [#696302]

On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote: >... > An user interested in future releases is usually a contributor of sorts, > thus often has "devscripts" installed. The typical user of Debian stable is running Debian on servers, and will become interested in a future release aft

Re: unattended-upgrades by default?

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote: >... > * it will be a different experience compared to what people will get >when installing Debian normally, using d-i / debootstrap. Most >(all?) of our desktop environments already have some automatic >notification of a

Re: Intended MBF: maintainer scripts not starting on #!

On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote: > Hi, Hi Ralf, > in the Colis project (which aims at analyzing maintainer scripts) we > found 39 maintainer scripts in stable which do not start on #!. The > list is attached. Policy 6.1 says about maintainer scripts: > > if they ar

Re: Intended MBF: maintainer scripts not starting on #!

On Fri, Nov 04, 2016 at 05:05:33PM -0400, Scott Kitterman wrote: > > > On November 4, 2016 5:01:31 PM EDT, Adrian Bunk wrote: > >On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote: > >> Hi, > > > >Hi Ralf, > > > >> in the Colis proj

Re: Intended MBF: maintainer scripts not starting on #!

On Fri, Nov 04, 2016 at 10:21:13PM +0100, Ralf Treinen wrote: > On Fri, Nov 04, 2016 at 11:01:31PM +0200, Adrian Bunk wrote: > > On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote: > > > Hi, > > > > Hi Ralf, > > > > > in the Colis project (w

Re: OpenSSL 1.1.0

On Thu, Nov 03, 2016 at 10:49:30AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote: > > On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer > > wrote: > > > > [...] > > > > > Today we the Qt/KDE t

Re: unattended-upgrades by default?

On Fri, Nov 04, 2016 at 10:27:00PM +, Holger Levsen wrote: > On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote: > > Should Debian also default to automatically reboot? > > > > If the answer is "no", then nothing is a solution that does not also > &

Re: Road to Stretch: let's stop increasing major version number in critical libraries at this point

On Sat, Nov 05, 2016 at 11:14:02AM +0100, Thomas Goirand wrote: > Hi, Hi Thomas, >... > Finally, with the above examples as illustration (and please, these > aren't attacks in any way...), I guess what I'm trying to say here is: > > While disruptive changes are necessary evils so we upgrade ever

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

On Tue, Oct 25, 2016 at 11:06:23AM -0700, Russ Allbery wrote: > Adrian Bunk writes: >... > So, I'm not quite sure how to put this, since I don't know how much work > you've done professionally in computer security, and I don't want to > belittle that.

Re: libc recently more aggressive about pthread locks in stable ?

On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > It's worth noting that TSX is broken in 'Haswell' processors and is > > supposed to be disabled via a microcode update. I don't know whether > > glibc avoids using it on the

Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?

On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > And what should we do about Debian stretch, then? > > I believe a good start would be to add an assert() in a test version of > glibc and then run all the autopkgtest scripts on the packages in

Re: What to do when a maintainer is blocking maintenance for stretch?

On Wed, Nov 09, 2016 at 06:45:43PM +, Mattia Rizzolo wrote: >... > Also, a personal pledge to everybody who's reading this: please don't > attach yourself to your packages like mussels on a rock. If you realize > (or somebody else is making you realize) that you're doing a bad job on > a packa

Re: More 5 november in the release schedule

On Wed, Nov 09, 2016 at 11:16:36AM +0800, Paul Wise wrote: > On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote: > > > Right. We want auto-removals to be useful for the release process, so that > > we > > don't end up with a thousand of RC bugs in testing when we freeze, most of > > th

Re: unattended-upgrades by default?

On Tue, Nov 08, 2016 at 11:16:53AM +0800, Paul Wise wrote: > On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote: > > > Forced reboot on upgrade is damage. Let's learn from errors of others. > > needrestart has a mechanism (needrestart-session) to hook into user > sessions, perhaps that could be

Re: NRSS has been deprecated [#696302]

On Mon, Nov 07, 2016 at 08:58:53PM +0100, Adam Borowski wrote: > On Sun, Oct 30, 2016 at 06:55:33PM +, Clint Adams wrote: > > On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote: > > > A maintainer would then file "ITR: dasher" and wait for responses before > > > requesting RM. > > >

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

On Sun, Nov 06, 2016 at 12:03:03AM +0100, Philipp Kern wrote: > On 2016-11-05 22:23, Adrian Bunk wrote: > > The solution you are trying to sell is apt-transport-https as default. > [...] > > Your solution would be a lot of work with relatively little improvement. > > Well

Re: OpenSSL 1.1.0

On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote: > Marco d'Itri: > > On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: > > > >> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev > >> and > >> have libssl1.1-dev around for anyone who can really do the sw

Re: OpenSSL 1.1.0

On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: > > On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: > > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev > > >

Re: OpenSSL 1.1.0

On Tue, Nov 15, 2016 at 07:03:28PM +1100, Scott Leggett wrote: > On 2016-11-15.00:16, Adrian Bunk wrote: > > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid > > free." > > or #843988 will be a common sight on the list of RC bugs fo

Re: libc recently more aggressive about pthread locks in stable ?

On Mon, Nov 14, 2016 at 10:31:18AM +0100, Gert Wollny wrote: > Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes > Holschuh: > >  > >  > >  > > Unfortunately, when hardware lock elision support was added to glibc > > upstream, libpthreads was *not* changed to properly assert() this

Re: OpenSSL 1.1.0

On Wed, Nov 16, 2016 at 12:15:39AM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-15 00:16:14 [+0200], Adrian Bunk wrote: > > And since 80% of all OpenSSL-using packages in unstable are still > > using libssl1.0.2 (binNMUs have not yet happened), all runtime > > issue

Re: OpenSSL 1.1.0

On Thu, Nov 17, 2016 at 12:27:43AM -0500, Scott Kitterman wrote: > On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez > Meyer wrote: > > On jueves, 17 de noviembre de 2016 00:40:42 ART Kurt Roeckx wrote: > > > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote: >

Re: OpenSSL 1.1.0

On Wed, Nov 16, 2016 at 10:53:18PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-16 19:49:44 [+0200], Adrian Bunk wrote: > > The problem are not specific bugs, the problem is the whole size of the > > problem: > > > > 1. Sorting out what packages have to stay a

Re: libc recently more aggressive about pthread locks in stable ?

On Thu, Nov 17, 2016 at 09:28:34AM -0200, Henrique de Moraes Holschuh wrote: > On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote: > > On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote: > > > The deal with *current* Debian stable is that, if the breakage is too > > > widespread, we si

Re: libc recently more aggressive about pthread locks in stable ?

On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh wrote: > On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote: > > But we do already have > 1 year of widespread testing by users > > running unstable/testing on machines with TSX enabled. > > > > So

Re: OpenSSL 1.1.0

On Thu, Nov 17, 2016 at 10:43:53PM +0100, Moritz Mühlenhoff wrote: > Adrian Bunk schrieb: > > On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez > > Meyer wrote: > >> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: > >>

Re: OpenSSL 1.1.0

On Fri, Nov 18, 2016 at 10:22:59PM +0100, Moritz Mühlenhoff wrote: > Adrian Bunk schrieb: > > And/or get sponsorship from companies for supporting ChaCha20-patched > > 1.0.2 > > It's not a matter of whipping up some patch; anything less than an > official backp

Re: Multi-Arch: allowed

On Sat, Nov 19, 2016 at 05:53:04PM +0100, Julien Cristau wrote: > On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > > > The -dbg package is Multi-Arch same. It Depends on the packages for > > which it provides debugging symbols, some of which are Multi-Arch: > > allowed. > > That D

Re: OpenSSL 1.1.0

On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 24 Nov 2016, Kurt Roeckx wrote: >... > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it > > > might not be safe. If it doesn't (i.e. at most you have a qt flag that > > > says "use SSL",

Re: OpenSSL 1.1.0

On Thu, Nov 24, 2016 at 03:20:06PM +0100, Jan Niehusmann wrote: > On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote: > > If inspection is not easily possible, then adding a dependency on > > libssl1.0-dev to qtbase5-private-dev should be sufficient to > > ensure th

Re: [Letsencrypt-devel] Certbot in Debian Stretch

On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote: > On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote: > > So if you, as an upstream maintainer, have a change that is needed for > > compatibility with changes in network APIs and the change is reviewable > > by humans, a stable update co

Re: [Letsencrypt-devel] Certbot in Debian Stretch

On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote: >... > For networked services, it is different. > > Debian has already been carrying updated versions of Firefox and > Chromium in stable including bundled dependencies too. Maybe we need to > have an objective way of deciding which o

Re: OpenSSL 1.1.0

On Thu, Nov 24, 2016 at 02:50:23PM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 24 Nov 2016, Adrian Bunk wrote: > > On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote: > > > On Thu, 24 Nov 2016, Kurt Roeckx wrote: > > >... > > >

Re: [Letsencrypt-devel] Certbot in Debian Stretch

On Thu, Nov 24, 2016 at 07:08:33PM +0100, Daniel Pocock wrote: > > > On 24/11/16 17:39, Adrian Bunk wrote: > > On Thu, Nov 24, 2016 at 05:22:29PM +0100, Daniel Pocock wrote: > >> ... > >> For networked services, it is different. > >> > >> D

Re: MIA maintainers and RC-buggy packages

On Sun, Dec 04, 2016 at 01:14:42PM +0100, Christoph Biedl wrote: >... > To add a few criteria, I'd remove a package from sid only if it >... > * has been orphaned for a longer time, say: a year > So again users of that package had a grace period to ask for work on > that package. >... Two ques

Re: contacting all bug reporters for a package?

On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote: > > Is there any easy way to contact everybody who made a bug report against > a package and ask them to check if the latest upload fixes it? Or is > there any script for maintainers to do this? I would expect the majority of your us

Re: contacting all bug reporters for a package?

On Mon, Dec 19, 2016 at 10:15:33PM +0100, Daniel Pocock wrote: > > > On 19/12/16 21:57, Adrian Bunk wrote: > > On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote: > >> > >> Is there any easy way to contact everybody who made a bug report against > &

no-strong-digests-in-dsc MBF

Hi, I want to do a MBF for all packages without a SHA256 checksum field in the .dsc [1] - only SHA1 as hash would not be good in stretch. This is quite easy to fix in a package - all that is required is a sourceful upload (but a binNMU would not be sufficient). The steps will be: 1. QA uploads

Re: [RFC] The PIE unholy mess

On Wed, Jan 18, 2017 at 04:34:24AM +0100, Guillem Jover wrote: >... > At about the same time this was being considered, I realized that dpkg > could enable this "safely" by using gcc specs files. But this is in > any case also required to be able to disable PIE when it is implicitly > enabled by de

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

On Tue, Jan 09, 2018 at 01:22:33PM -0500, Michael Stone wrote: > On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote: > > At times, Ubuntu needs to avoid certain build-dependencies because > > they would add an unwanted "universe" binary dependency to a "main" > > package. In some cases, t

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote: >... > Given the background of build-profiles, I'm very much in favor of > introducing the equivalent usage as Gentoo USE flags, which was its > main intention! :) It could make Debian a viable source-based > distribution to use or base

Re: Why do we list individual copyright holders?

On Fri, Dec 22, 2017 at 08:51:37AM -0500, Scott Kitterman wrote: >... > I intend to work within the FTP Team to get some clarification on the team's > position on this, but I don't expect it to be quick. I agree we could do > with > better documentation of what the policy is and why. >... Than

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

On Tue, Jan 09, 2018 at 07:29:51PM -0500, Sam Hartman wrote: > >>>>> "Adrian" == Adrian Bunk writes: > > Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote: > >> ... Given the background of build-profiles, I'm very m

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote: > On 10/01/18 01:29, Sam Hartman wrote: > > A build profile seems like a great way to express the flag, and like > > many things in Debian, the work would fall on those who would benefit > > from it. > > I think it'd be better

Re: Reducing the attack surface caused by Berkeley DB...

On Fri, Jan 26, 2018 at 11:49:41PM +0100, Lionel Debroux wrote: >... > On 1/26/18 11:39 AM, David Kalnischkies wrote: >... > > Finding someone performing the daunting task of actually switching > > code, documentation and existing databases over on the other hand… I > > at least don't see me enthus

Re: Reducing the attack surface caused by Berkeley DB...

On Sat, Jan 27, 2018 at 12:25:20PM +0100, Lionel Debroux wrote: > Hi Adrian, Hi Lionel, > On 1/27/18 6:27 AM, Adrian Bunk wrote: >... > > There doesn't seem to be any disagreement on the general idea, > > the only thing missing is a person doing the work on getting >

Re: Reducing the attack surface caused by Berkeley DB...

On Sat, Jan 27, 2018 at 12:22:59PM +0100, Lionel Debroux wrote: >... > On 1/27/18 1:42 AM, Guillem Jover wrote: > > On Thu, 2018-01-25 at 23:59:06 +0100, Lionel Debroux wrote: > > > Several days ago, jmm from the security team suggested that I start > > > a discussion on debian-devel about Berkeley

Re: Reducing the attack surface caused by Berkeley DB...

On Sat, Jan 27, 2018 at 01:53:54PM +0100, David Kalnischkies wrote: >... > I guess you can kill both birds with one stone if you go for a "write > libdb-api-compatibility layer for your favorite other db", but that > wouldn't really be a Debian task anymore. Without even thinking a split- > second

Re: Removing packages perhaps too aggressively?

On Wed, Jan 31, 2018 at 11:18:28PM -0500, Scott Kitterman wrote: > On Thursday, February 01, 2018 11:56:21 AM Paul Wise wrote: > > On Thu, Feb 1, 2018 at 3:14 AM, Andrej Shadura wrote: > > > For example > > > > Here is another example of a low-quality RM bug; removal at request of > > the maintain

Re: Removing packages perhaps too aggressively?

On Wed, Jan 31, 2018 at 10:40:19PM +0100, Michael Biebl wrote: > > I think we should remove cruft more aggressively then we currently do. I think it would be bad to move even more to a revolving door situation where we are adding packages to a stable release only to remove them in the next stabl

Re: Removing packages perhaps too aggressively?

On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote: > On Fri, Feb 02, 2018 at 12:00:58AM +0100, Wouter Verhelst wrote: > > Currently, RM bugs are filed against ftp.debian.org. > > > > It might make sense to have them filed against ftp.debian.org *and* the > > package to be removed, inste

Re: Removing packages perhaps too aggressively?

On Fri, Feb 02, 2018 at 01:48:52PM -0500, Michael Stone wrote: >... > And we've all learned a lot more about secure coding in the past 20 years. >... Who is "we all"? I'd guess the majority of new packages in Debian were not written by people who have learned anything about secure coding. It is

Re: Removing packages perhaps too aggressively?

On Fri, Feb 02, 2018 at 12:17:14PM -0500, Scott Kitterman wrote: > On Friday, February 02, 2018 06:30:28 PM Adrian Bunk wrote: > > On Wed, Jan 31, 2018 at 11:18:28PM -0500, Scott Kitterman wrote: > > > On Thursday, February 01, 2018 11:56:21 AM Paul Wise wrote: > > > &g

Re: Removing packages perhaps too aggressively?

On Sat, Feb 03, 2018 at 05:57:26PM +, Colin Watson wrote: > On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote: > > On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote: > > > It'd probably make sense to use > > > https://www.debian.org/Bugs

Re: Removing packages perhaps too aggressively?

On Sat, Feb 03, 2018 at 02:01:38AM -0500, Scott Kitterman wrote: > On Saturday, February 03, 2018 08:20:02 AM Adrian Bunk wrote: >... > > Do you have any suggestion better than "ITP immediately followed by > > orphaning" for packages I consider useful but don't

Re: What can Debian do to provide complex applications to its users?

On Fri, Feb 16, 2018 at 06:12:04PM +0100, Michael Meskes wrote: > On Fri, Feb 16, 2018 at 11:12:51AM -0500, Michael Stone wrote: > > On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote: > > > I know that this does create some problems for us, e.g. on the security > > > side, but the alte

Re: What can Debian do to provide complex applications to its users?

On Fri, Feb 16, 2018 at 08:18:13PM +0100, Samuel Thibault wrote: > W. Martin Borgert, on ven. 16 févr. 2018 18:59:21 +0100, wrote: >... > > This is very much a web application problem. Other software is > > less affected in my experience. > > Sure. But the current world is more and more focused on

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 07:03:04PM +0100, Michael Meskes wrote: > > Because eventually a future version will come out that doesn't work > > with > > the stable base, at which point we suddenly stop supporting the > > package. > > That's much worse than just admitting up front that we can't suppor

Re: What can Debian do to provide complex applications to its users?

On Sun, Feb 18, 2018 at 11:47:52PM +0100, Vincent Bernat wrote: > ❦ 18 février 2018 23:53 +0200, Adrian Bunk  : > > >> Who said we cannot properly maintain this stuff? And where do you > >> think our expected level of quality (whatever that is) will not be > >>

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 09:18:13AM +0100, Philipp Kern wrote: > On 2018-02-18 22:53, Adrian Bunk wrote: > > In the year 2018, any kind of "properly maintain" includes security > > support. > > > > Please elaborate how Debian can provide security support for p

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 08:35:29PM +0100, Michael Meskes wrote: > > What is the user supposed to do when Debian announces that some > > software essential for that user is no longer supported in the > > stable release the user is using? > > Again, where does this differ from the user realizing th

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: >... > > An example what "no security support" means in practice: > > I don't think anyone suggest "no security", but something like > "security by upstream releases". How can you guarantee that to our users for buster until mid-2022

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 08:44:58PM +0100, Vincent Bernat wrote: >... > Or we could put those software in a special repository (called "unsupported") >... What about calling it "nsa-enablement"? Cause that's what it is. But to be fair, no longer installing packages without security support in the

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 09:42:28PM +0100, Michael Meskes wrote: > > > And why wouldn't we offer said upstream version instead of the > > > unsupported older one? > > > > In some cases this might require changing literally thousands of > > packages in stable. > > > > Imagine said upstream version

Re: What can Debian do to provide complex applications to its users?

On Mon, Feb 19, 2018 at 03:52:30PM -0500, Roberto C. Sánchez wrote: > On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: > > On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: > > >... > > > > An example what "no security support"

Re: What can Debian do to provide complex applications to its users?

On Tue, Feb 20, 2018 at 11:56:04AM +0100, Michael Meskes wrote: > > > Right, and that's why we were talking about stuff like flatpak that > > > bring the application with its dependencies, more or less like a > > > container. > > > > That's a better solution for such cases than shipping the softwa

Re: What can Debian do to provide complex applications to its users?

On Tue, Feb 27, 2018 at 02:14:02PM +, Simon McVittie wrote: >... > Also, the security team specifically don't provide security > support for libv8, which apparently extends to node-* packages like > , so it's > hard to see how toleratin

Re: What can Debian do to provide complex applications to its users?

On Tue, Feb 27, 2018 at 02:13:41PM +0100, Didier 'OdyX' Raboud wrote: >... > In other words, vendorization is the tool that allows developers to get rid > of > distribution constraints and get on with their development through installing > the dependencies from their ecosystem as they see fit (n

Re: What can Debian do to provide complex applications to its users?

On Fri, Mar 09, 2018 at 02:07:19AM +0100, gregor herrmann wrote: > On Thu, 08 Mar 2018 23:03:17 +0200, Adrian Bunk wrote: > > > The first question should always be if/how we can provide something that > > is better than what is already available elsewhere. > > An answe

Re: Usage of real m68k hardware

On Wed, Mar 28, 2018 at 10:26:28AM -0700, Russ Allbery wrote: >... > The chances of anyone really wanting to run some of this scientific > software on m68k seem remote, so it feels like it would be an overall > reduction of friction if the maintainer could just say "I don't support > this arch" and

Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 04:21:58PM +0200, Wouter Verhelst wrote: > On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote: > > On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote: > > > Don Armstrong writes ("Re: interpretation of wontfix"): > > > > 2) wontfix+help: this bug requires too muc

Re: interpretation of wontfix

On Thu, Mar 29, 2018 at 01:59:29PM +0100, Ian Jackson wrote: >... > Perhaps > >soon > >The maintainers intend to fix this bug quickly, probably in the >next upload to Debian unstable. > > [ I find myself using a browser tab on my laptop for this, which >is distin

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

On Wed, Mar 28, 2018 at 08:08:07PM -0700, Russ Allbery wrote: > Boyuan Yang <073p...@gmail.com> writes: > > > * Upstream released new version and bumped SONAME to 2 > > * -dev package didn't change its name > > * My mentor suggests that the new library package (libdframeworkdbus2) > > should > >

Re: Debian part of a version number when epoch is bumped

On Wed, Mar 28, 2018 at 11:39:58PM +0200, Christian T. Steigies wrote: >... > You still have not convinced me that I did anything wrong with the version > number and you keep ignoring my request for propper official documentation > how to use and not use an epoch. Maybe you all can read between th

Re: Debian part of a version number when epoch is bumped

On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote: > Moin, Hi, > On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote: > > > > There are two problems here. > > > > The first is the use of an epoch in a situation where it shouldn't

Re: Planning the removal of c_rehash | mass bug filling

On Fri, Apr 06, 2018 at 12:22:12AM +0200, Sebastian Andrzej Siewior wrote: > Hi, > > the openssl package provides the c_rehash script which creates the links > from .Y to the actual certificate in /etc/ssl/certs/. During the > transition from 0.9.8 to 1.0.0 the hash (for the X part) change

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 11:40:52PM +, Holger Levsen wrote: > On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote: > > With my one of most active sponsors hat on: the current policy is that a > > version that has never hit the archive must not have a separate changelog > > entry, unles

Re: Updated proposal for improving the FTP NEW process

On Mon, Apr 09, 2018 at 02:24:23PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW > process"): > > A version is published to our users when it gets accepted into > > the archive. > > > > Readable inf

Re: Updated proposal for improving the FTP NEW process

On Wed, Apr 11, 2018 at 02:05:03PM -0700, Russ Allbery wrote: > Adrian Bunk writes: > > > Imagine tomorrow a random person from the internet noone has ever heard > > of uploads a package dgit 5.0 to mentors.d.n. > > > It is clear that this would not be sponsored.

Re: Bug#895246: gconf: Intent to Adopt

On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote: > (I don't speak for the GNOME team, or for Josselin, who is officially > this package's maintainer; please don't assume I do.) > > On Sun, 08 Apr 2018 at 22:19:43 +0300, Adrian Bunk wrote: > > I

Re: Updated proposal for improving the FTP NEW process

On Fri, Apr 13, 2018 at 03:54:29PM +0100, Ian Jackson wrote: >... > Now you seem to be saying > > 1 having the same version version number referring to >multiple different source versions is completely fine > because > 2 reusing version version numbers should not be forbidden >... > I

Re: my package was fixed by someone else and i dont like that

On Mon, Apr 16, 2018 at 12:43:57PM +, Holger Levsen wrote: > Rolf, > > first of all, you immediatly lost your argument by putting peoples name > in the subject of a mail to debian-devel. This is really bad style > (called fingerpointing) and I wish you hadn't done this. Based on this > behavio

Re: Updated proposal for improving the FTP NEW process

On Sat, Apr 14, 2018 at 01:00:08PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW > process"): >... > > What happens outside of our archive (e.g. in Ubuntu or .debian.net) > > is nothing we officially provide to our

Re: Bits from the release team: full steam ahead towards buster

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote: > On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote: > > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote: > > > On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote: > > > > Please define "sorted orde

Please do not drop Python 2 modules

Hi, first two facts: 1. Upstream EOL for Python 2 is 2020 2. Debian will fully (security) support Python 2 in buster until the EOL of buster (ETA: mid-2022) Python 2 is obsolete, no doubt about that. But in many cases a Linux distribution is just a platform for running own applications, an

Re: Please do not drop Python 2 modules

On Mon, Apr 23, 2018 at 05:49:32PM +0200, Helmut Grohne wrote: > On Sat, Apr 21, 2018 at 08:57:55PM +0300, Adrian Bunk wrote: > > The tip of the iceberg are some recent cases where Python 2 modules > > were dropped that still had reverse dependencies in unstable, but > > a

Re: Please do not drop Python 2 modules

On Tue, Apr 24, 2018 at 12:10:12AM +0200, Thomas Goirand wrote: >... > This cannot go on, and on, and on, and on... We have to send a clear > message on the right direction, which is Python 2 removal. Yes, removal! > Why are we even discussing this? Isn't it obvious? It is not for us to decide wha

Re: Please do not drop Python 2 modules

On Mon, Apr 23, 2018 at 11:54:51PM +0200, Thomas Goirand wrote: >... > Right now, the only reason I'm keeping Python 2 support within a number > of packages in OpenStack, is because one of our team member wrote he's > using Python 2 in his company, and that we never finished the > conversation as t

Re: Please do not drop Python 2 modules

On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote: > On 04/25/2018 06:14 PM, Adrian Bunk wrote: > > On Tue, Apr 24, 2018 at 12:10:12AM +0200, Thomas Goirand wrote: > >> ... > >> This cannot go on, and on, and on, and on... We have to send a clear > >

Re: Please do not drop Python 2 modules

On Thu, Apr 26, 2018 at 10:35:10AM -0700, Don Armstrong wrote: > On Thu, 26 Apr 2018, Adrian Bunk wrote: > > We (Debian) have decided to support Python 2.7 in buster, like it or > > not. > > > > At that point it is not up to individual maintainers to sabotage > >

Re: Please do not drop Python 2 modules

On Thu, Apr 26, 2018 at 06:19:24PM +0100, Ian Jackson wrote: >... > Adrian: are you volunteering to write patches to solve Helmut's cross > building problem ? I am willing to stop for several weeks/months to monitor RC bugs and report FTBFS if you can make the case that it is more beneficial for

Re: Please do not drop Python 2 modules

On Fri, Apr 27, 2018 at 01:06:03PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Please do not drop Python 2 modules"): > > On Thu, Apr 26, 2018 at 06:19:24PM +0100, Ian Jackson wrote: > > > Adrian: are you volunteering to write patches to solve Helmut&#x

Re: RFC: Support for zstd in .deb packages?

On Fri, Apr 27, 2018 at 07:02:12AM +0200, Guillem Jover wrote: >... > * Eternity contract: This would add yet another format that would need > to be supported pretty much forever, to be able to at least unpack > .deb's that might be available in the wild. This also increases the > (Build-)Ess

Re: Please do not drop Python 2 modules

On Fri, Apr 27, 2018 at 03:08:24PM +0200, Thomas Goirand wrote: > On 04/26/2018 07:14 PM, Adrian Bunk wrote: > > On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote: > >> On 04/25/2018 06:14 PM, Adrian Bunk wrote: > >>> On Tue, Apr 24, 2018 at 12:10:12

Re: Bug#895246: gconf: Intent to Adopt

On Mon, Apr 30, 2018 at 06:47:41PM -0400, Jeremy Bicha wrote: > On Sun, Apr 8, 2018 at 3:19 PM, Adrian Bunk wrote: > > Sorry for not replying more promptly. > > > I hereby declare my intent to adopt gconf. > > Why? Basically there are only two things left in Buste

Re: Versioned dependencies and maintainer scripts

On Mon, Jun 25, 2018 at 11:10:51AM -0600, Daniele Nicolodi wrote: >... > On 6/25/18 1:04 AM, Simon McVittie wrote: >... > > For the postinst, you can rely on the updated init-system-helpers being > > at least unpacked (which should be enough, because i-s-h is Essential, > > so it's required to prov

Re: SALSA migration of XML/SGML packages (sgml-data for me)

On Sun, Jul 08, 2018 at 11:20:57PM +0900, Osamu Aoki wrote: > Hi, > > I am wondering what is happening with XML/SGML packages. > > I am doing SALSA migration and I realized I need to RFA or Orphan some > of my packages. Specifically: > > sgml-data > debiandoc-sgml > debiandoc-sgml-doc > deb

Re: Mass filing on Python 3.7 async module import?

On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote: > On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote: > > List of affected packages: > > > > openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py > > pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.

<    1   2   3   4   5   6   7   >