Re: limits for package name and version (MBF alert: ... .deb filenames)

[Followup-To: nach gmane.linux.debian.devel.general gesetzt.] Philipp Kern tr...@philkern.de schrieb: [Followup-To: header set to gmane.linux.debian.devel.general.] On 2011-04-23, Dominic Hargreaves d...@earth.li wrote: On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: I would

Re: A few observations about systemd

Jon Dowland j...@debian.org schrieb: On Mon, Jul 18, 2011 at 08:12:04AM +0200, Josselin Mouette wrote: Developing for Linux-only is fine, but Lennart has explicitly said that he wouldn’t remotely consider accepting portability patches, which goes further than any other piece of free software I

Providing official virtualisation images of Debian

Hi, I believe it's high time we start to providing Debian in form of official virtualisation images. In contrast to the ISOs currently provided it allows a quicker evaluation/testing of Debian (and can also be very useful for testing (e.g. someone wrote on debian-release that he doesn't have

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

Paul Wise p...@debian.org schrieb: So, I was wondering if anyone has any ideas on this topic? I would suggest a package such as debian-oem-prep, which contains an init script, which tests a file such a /etc/wipe-all-traces-on-next-boot. If that files exists, all sensitive host data like

Re: Bug#635516: ITP: dvdstyler -- DVD authoring and burning tool

Reinhard Tartler siret...@debian.org schrieb: On Tue, Jul 26, 2011 at 16:02:42 (CEST), Moritz Muehlenhoff wrote: Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff j...@debian.org * Package name: dvdstyler Version : 1.8.4.2 Upstream Author : Alex Thuering * URL

Re: Providing official virtualisation images of Debian

Karl Goetz k...@kgoetz.id.au schrieb: I think it's sufficient for starters to provide images for stable (they can be updated for every few point updates if needed). =20 What virtualisation solutions should be supported? - Vmware has a significant installed base and is relevant, although

Re: Providing official virtualisation images of Debian

Vincent Bernat ber...@debian.org schrieb: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OoO En cette matin=C3=A9e ensoleill=C3=A9e du mardi 26 juillet 2011, vers= 09:28, Lucas Nussbaum lu...@lucas-nussbaum.net disait=C2=A0: What

Re: Providing official virtualisation images of Debian

Michael Tokarev m...@tls.msk.ru schrieb: What virtualisation solutions should be supported? - Virtual Box seems like a natural candidate since it's free and included since Squeeze. - Vmware has a significant installed base and is relevant, although proprietary - Microsoft Virtual PC is

Re: Providing official virtualisation images of Debian

debian deb...@fpsoft.net schrieb: For now I would recommend against pre-configured Citrix XenServer releases. I am a Citrix CCNA and I would not recommend that for this very reason. Debian is best set up in Citrix Xenserver from scratch. Is there a technical reason or is this personal

Re: Providing official virtualisation images of Debian

Lars Wirzenius l...@liw.fi schrieb: On Tue, Jul 26, 2011 at 12:27:09AM +0200, Moritz Mühlenhoff wrote: What virtualisation solutions should be supported? - Virtual Box seems like a natural candidate since it's free and included since Squeeze. - Vmware has a significant installed base

Re: Providing official virtualisation images of Debian

Stefano Zacchiroli lea...@debian.org schrieb: Additionally, I think we should also consider getting contacts with cloud providers (e.g. Amazon, as mentioned in this thread) and have them offer Debian images provided by us. Some of those provider already offer, possibly via third parties,

Re: Providing official virtualisation images of Debian

Ian Campbell i...@hellion.org.uk schrieb: On Tue, 2011-07-26 at 00:27 +0200, Moritz Mühlenhoff wrote: Hi, I believe it's high time we start to providing Debian in form of official virtualisation images. [...] Do people think this is relevant and are willing to work on providing one

Re: Providing official virtualisation images of Debian

Jon Dowland j...@debian.org schrieb: Perhaps a Debian web service could spit out custom VM definitions alongside the image file in a chosen disk format for users on-demand? For starters, compressed RAW disk format is perhaps the most useful disk image format (can be imported into virtually

Re: Providing official virtualisation images of Debian

Daniel Baumann daniel.baum...@progress-technologies.net schrieb: On 07/26/2011 12:27 AM, Moritz Mühlenhoff wrote: I believe it's high time we start to providing Debian in form of official virtualisation images. we have worked on that with debian-live (both producing live and 'non-live

Re: Hardening build flags release goal

Raphael Hertzog hert...@debian.org schrieb: Hello, we're not very far from having hardening build flags set by default by dpkg-buildflags (waiting on some documentation update that Kees should take care of). Thanks! I would like to find one or two persons to lead a new release goal

Re: release goal proposal: enable hardening build flags

Andreas Metzler ametz...@downhill.at.eu.org schrieb: In gmane.linux.debian.devel.general Kees Cook k...@debian.org wrote: I would like to propose a release goal of enabling hardening build flags[1] for all C/C++ packages in the archive[2]. For Wheezy, specific sub-goals are being chosen.

Re: Enabling hardened build flags for Wheezy

Nikolaus Rath nikol...@rath.org schrieb: Moritz Muehlenhoff j...@debian.org writes: Hi, dpkg-buildflags allows a uniform setting of default build flags for code written in C and C++. Using dpkg-build-flags in your rules files has a number of benefits: [...] Should packages of Python

Re: Enabling hardened build flags for Wheezy

Russ Allbery r...@debian.org schrieb: Paul Wise p...@debian.org writes: Personally I think this is completely the wrong approach to take for compiler hardening flags. The flags should be enabled by default in upstream GCC and disabled by upstream software where they result in problems. If

Re: Enabling hardened build flags for Wheezy

Kees Cook k...@debian.org schrieb: In the mean time, I'll continue to work on the crappy heuristic checks. ;) Shall we move hardening-check to devscripts, now that dpkg-buildflags slowly trickles into standard Debian development practice? Cheers, Moritz -- To UNSUBSCRIBE, email to

Re: Enabling hardened build flags for Wheezy

Charles Plessy ple...@debian.org schrieb: Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit : -BEGIN PGP SIGNED MESSAGE- Since it will be almost impossible to convert all packages before Wheezy freezes, a specific sub-group of packages receives targeted

Re: Please make yourself maintainer

retitle 548366 O: irdc-hybrid -- high-performance secure IRC server reassign 548366 wpp thanks On Fri, Sep 25, 2009 at 01:11:32PM -0700, Joshua Kwan wrote: Package: ircd-hybrid Hi Aurelien, Please feel free to remove me as Maintainer and take it on as your own package. I haven't worked on

Re: Bug#672695: wordpress: no sane way for security updates in stable releases

On Sun, May 13, 2012 at 02:54:40PM +0200, Yves-Alexis Perez wrote: On sam., 2012-05-12 at 23:45 +0200, Bernd Zeimetz wrote: Being forced to upgrade to a new major version by a stable security support is nothing we should force our users to. Debian stable is known for (usually) painfree

Re: jessie release goals

Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Another thing: Hardening already has been a release goal but there still are packages around without. Agreed. I made a concentrated effort for Wheezy by submitting lots of patches for crucial packages and the general adoption among

Re: Bug#666490: O: svgalib -- console SVGA display libraries

On Mon, May 13, 2013 at 07:30:20PM +0200, Stephen Kitt wrote: Hi, On Sun, Apr 01, 2012 at 02:59:24AM +0100, Ben Hutchings wrote: Thanks for your work, but isn't it time we quietly got rid of this library? Video memory and mode setting should be managed by the kernel, not by

Re: Switching to mozilla ESR in stable-security

Arno Töll a...@debian.org schrieb: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enigD8B4E48BF27B74A11F1ECB8F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29.05.2013 15:15, Ansgar Burchardt wrote: I would expect some

Re: Switching to mozilla ESR in stable-security

Willi Mann foss...@wm1.at schrieb: Hello Moritz, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more

Re: Switching to mozilla ESR in stable-security

Christoph Anton Mitterer cales...@scientia.net schrieb: --=-dGSWlplfgLb+HUgDia6J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Moritz. Moritz Muehlenhoff wrote: In the future the majority of packages should thus rather be installed through

Re: Switching to mozilla ESR in stable-security

Didier 'OdyX' Raboud o...@debian.org schrieb: FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up

Re: Switching to mozilla ESR in stable-security

Ansgar Burchardt ans...@debian.org schrieb: Hi, On 05/28/2013 22:33, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Reverse-deps of the older xulrunner libs have negligable security impact and we won't update them

Re: Switching to mozilla ESR in stable-security

Andrei POPESCU andreimpope...@gmail.com schrieb: --Yvzb+MHGXtbPBi5F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: =20 As such, we'll switch to releasing the ESR

Re: Reporting 1.2K crashes

Alexandre Rebert alexandre.reb...@gmail.com schrieb: Hi, I am a security researcher at Carnegie Mellon University, and my team has found thousands of crashes in binaries downloaded from debian wheeze packages. After contacting ow...@bugs.debian.org, Don Armstrong advised us to contact you

Re: Survey answers part 3: systemd is not portable and what this means for our ports

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de schrieb: On 07/13/2013 11:46 PM, Michael Stapelberg wrote: since some people might not read planet debian, here is a link to my third blog post in a series of posts dealing with the results of the Debian systemd survey:

Re: Dreamhost dumps Debian

Russ Allbery r...@debian.org schrieb: Pau Garcia i Quiles pgqui...@elpauer.org writes: On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery r...@debian.org wrote: My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in

Re: Dreamhost dumps Debian

Steve Langasek vor...@debian.org schrieb: I understand the motivation (like everyone else they have more to do than they have time to do it in), but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

Michael Meskes mes...@debian.org schrieb: Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? No hard numbers, but I'd suppose half and half (i.e. cases, where the maintainer prepared

Re: to those who want to support Debian longer...

Holger Levsen hol...@layer-acht.org schrieb: please start with helping supporting the current stable release better: Indeed, actions speak louder than words. Here's four specific packages, where the security team could need some help for an oldstable-security update: - mysql-5.1 needs to be

Re: Bug#732159: Should this package be removed?

Bálint Réczey bal...@balintreczey.hu schrieb: How about introducing the ffmpeg shared libraries with libffmpeg prefix instead of libav prefix? No way. Keeping up with security fixes for libav is tedious enough, we cannot reasonably have both. Cheers, Moritz -- To UNSUBSCRIBE, email

Re: Bug#732159: Should this package be removed?

Ian Jackson ijack...@chiark.greenend.org.uk schrieb: Jonas: Is your view that the packages which aren't working properly with libav (including mplayer) should be removed from Debian ? mplayer doesn't need to be removed because of any compatibility issues with libav. It FTBFSes for entirely

Re: GnuTLS in Debian

Andreas Metzler ametz...@debian.org schrieb: #5 Declare GMP to be a system library. (..) #5 was how Fedora looked at the OpenSSL library issue. Since Debian has another viewpoint on OpenSSL I somehow doubt we would use it for GMP. We should do that (and also reevaluate the position wrt

Upcoming switch to ESR24 for iceweasel in stable-security

Hi, quick heads up for everyone maintaining xul-ext-* packages: We'll soon update iceweasel in stable-security to the ESR24 branch, test packages can be fetched from http://mozilla.debian.net/24/ Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

Brian May br...@microcomaustralia.com.au schrieb: --001a11c1fd62df72e504f0aac077 Content-Type: text/plain; charset=UTF-8 On 24 January 2014 04:14, Jelmer Vernooij jel...@samba.org wrote: My proposal is to drop the package from the archive, but I wanted to give others a chance to shout out

Re: lcms - lcms2 migration

On Sun, Dec 29, 2013 at 11:25:48AM +0100, Bastien ROUCARIES wrote: On Sun, Dec 29, 2013 at 10:33 AM, Moritz Mühlenhoff j...@inutil.org wrote: Hi, lcms needs to go for jessie in favour of lcms2 (#717928). (liblcms1-dev - liblcms2-dev) The maintainer seems MIA, so I'm going ahead. Below

Re: FFmpeg vs. libav packaging

Russ Allbery r...@debian.org schrieb: Paul Wise p...@debian.org writes: On Fri, Feb 14, 2014 at 5:40 AM, Adrian Bunk wrote: Having both sets of libraries in the archive at the same time is what I called insane in the RFP and where I expect additional probems due to: Also, I expect the

Re: FFmpeg vs. libav packaging

Jonathan Dowland j...@debian.org schrieb: Moritz, what's the security team's opinion on ffmpeg being reintroduced as a binary package (providing /usr/bin/ffmpeg) only? Doesn't make much of a difference, since it still exposes all the same decoders and demuxers through the ffmpeg binary.

Re: Bits from the Security Team

Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Matthias Urlichs wrote... IMHO the decision to designate release N to be a LTS release has too be made at release time of N+1 _at_the_latest_, so maintainers know that they may not remove their old upgrade script snippets. Agreed, but

Re: Bits from the Security Team

On Thu, Mar 06, 2014 at 09:00:13AM +0800, Paul Wise wrote: * There are quite some vulnerabilities which are addressed in Debian, but for which no CVE identifier has been assigned. Perhaps we could encourage those submitting security bugs to X-Debbugs-CC the oss-sec list? That would

Re: Why not 03 ?

Charles Plessy ple...@debian.org schrieb: Perhaps we can stop overriding this option ? For a lot of scientific packages, -O3 is chosen by the upstream author, and I always feel bad that if we make the programs slower by overriding it to -O2, it will reflect poorly on Debian as a distribution

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Josselin Mouette j...@debian.org schrieb: Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look more secure. When in

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Wookey woo...@wookware.org schrieb: Unless we were to decide to make an exception re internal libraries (which seems unlikely in this case given the general discussion on security load), this package is not going to make it into Debian anytime soon, which from my POV is very sad - I had

Re: Reintroducing FFmpeg to Debian

Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb: Hi Thomas, On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with

Re: Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)

Maxime Chatelle x...@rxsoft.eu schrieb: Package: wnpp Severity: wishlist Owner: Maxime Chatelle x...@rxsoft.eu * Package name: cakephp2 Version : 2.5.6 Upstream Author : http://cakefoundation.org/ * URL : http://cakephp.org/ * License : MIT

Accepted poppler 0.12.4-1.2 (source amd64)

: source amd64 Version: 0.12.4-1.2 Distribution: unstable Urgency: medium Maintainer: Loic Minier l...@dooz.org Changed-By: Moritz Mühlenhoff j...@debian.org Description: libpoppler-dev - PDF rendering library -- development files libpoppler-glib-dev - PDF rendering library -- development files (GLib

Accepted iceape 1.1.14-1.1 (source all amd64)

-mozilla-maintain...@lists.alioth.debian.org Changed-By: Moritz Mühlenhoff j...@debian.org Description: iceape-dev - Development files for the Iceape Internet Suite iceape-dev-bin - Development files for the Iceape Internet Suite Closes: 511477 Changes: iceape (1.1.14-1.1) unstable; urgency=medium

Accepted wvstreams 4.4.1-1.1 (source all amd64)

Version: 4.4.1-1.1 Distribution: unstable Urgency: high Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Moritz Mühlenhoff j...@debian.org Description: libuniconf4.4 - C++ network libraries for rapid application development libwvstreams-dev - Development libraries and header files

Accepted elinks 0.12~pre5-9 (source amd64 all)

...@debian.org Changed-By: Moritz Mühlenhoff j...@debian.org Description: elinks - advanced text-mode WWW browser elinks-data - advanced text-mode WWW browser - data files elinks-doc - advanced text-mode WWW browser - documentation elinks-lite - advanced text-mode WWW browser - lightweight version

Accepted open-vm-tools 2:9.2.3-1031360-7 (source amd64 all)

-1031360-7 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Moritz Mühlenhoff muehlenh...@univention.de Description: open-vm-dkms - Open VMware Tools for virtual machines hosted on VMware (transiti open-vm-toolbox - Open VMware Tools for virtual

Re: The Spirit of Free Software, or The Reality

Paul Wise p...@debian.org schrieb: On Thu, Jul 16, 2015 at 6:17 AM, Mike Hommey wrote: I, myself, find our DFSG-freeness pickiness going too far, and I'm sick of this icon thing. So, here's what I'm going to do: unless I hear non-IANAL objection until the next upstream release due on august

Re: Question about flashplugin-nonfree

Marcio Souza wrote: > The problem is that most Debian users to update the system using apt-get > update && apt-get upgrade or the like. > Thus the flash plugin is not updated and the security problem will persist. > > I believe that the flash update should be automatic

Re: Debian LSB compliance

Didier 'OdyX' Raboud o...@debian.org wrote: Given a) the work that certifying Debian would take; b) the interest in having Debian be certified (I am yet to see any of that interest); c) the marginal interest by application vendors for the LSB; I'm leaning towards outright giving up.

Re: GNU IceCat?

Russ Allbery schrieb: > Simon Josefsson writes: > >> Is there any reason (other than lack of manpower) that GNU IceCat is not >> packaged in Debian? > > I suspect it's mostly just resources, but it's an immense amount of work, > and not just for the

Re: copyright precision

Simon McVittie schrieb: > In particular, if this thread comes to the conclusion that more needs to > be done than what maintainers currently do, then it should be something > actionable; Or we could rather automate the generation of debian/copyright entirely by letting fossology

Re: OpenSSL 1.1.0

Jérémy Lal wrote > The openssl release strategy page [1] states: > Version 1.1.0 will be supported until 2018-04-30. > Version 1.0.2 will be supported until 2019-12-31 (LTS). > > Considering the dates, upstream authors using openssl 1.0.2 might not > migrate to the new api

Re: Standards-Version field should be deprecated

Josh Triplett schrieb: > I do see value in documenting the version of Policy a package complies > with. However, I can also imagine some approaches to eliminate the > busywork. We could reduce the policy checklist to issues not covered/coverable by Lintian tests (which

Re: unattended-upgrades by default?

Steve McIntyre schrieb: > Definitely. I think we've got general consenus here, and we should do > the following: > > * work on fixing some of the highlighted bugs in unattended-upgrades > > * enable it for installation via d-i by default. At installation >time, it should

Re: OpenSSL 1.1.0

Stephan Seitz wrote: > And there is still the problem that 1.1.0 is not supported as long as the > available LTS version. That's not a decisive factor, Debian security support has been extended over the upstream support time frame many times before. Cheers, Moritz

Re: OpenSSL 1.1.0

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 backport of chacha20 into a 1.0.2x release is not going to be supportable. Cheers, Moritz

Re: OpenSSL 1.1.0

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: >> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer >> > wrote: >> > > And

Re: OpenSSL 1.1.0

Stefan Fritsch <s...@sfritsch.de> schrieb: > On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote: >> Adrian Bunk <b...@stusta.de> schrieb: >> > And/or get sponsorship from companies for supporting ChaCha20-patched >> > 1.0.2 >> >> It

Re: OpenSSL 1.1.0

Adrian Bunk schrieb: > Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not > obvious to me why this would be that much worse in comparison that > it would not be an option under any circumstances. That patch has never been upstreamed and is not something we can

Re: System libraries and the GPLv2 (was: Re: GnuTLS in Debian)

Florian Weimer schrieb: > Would it be possible to get real legal advice on this matter, with the > concrete goal to find a usable process to leverage the system library > exception in the GPLv2? We should have done that a decade ago... The SFLC can probably help, but an

Re: Let's enable AppArmor by default (why not?)

intrigeri schrieb: > Still, even with the set of features available in mainline Linux > *today*, IMO enabling AppArmor already has a good cost/benefit ratio > for Debian and our users. I'm not proposing we apply out-of-tree > AppArmor kernel patches. I'd expect that a lot

Re: Let's enable AppArmor by default (why not?)

Christian Seiler schrieb: > Another thing to consider: if a profile is too restrictive, but the > part that is too restrictive isn't in the upstream kernel yet, then > things could break if you upgrade the kernel to a newer version from > e.g. backports later on. How would you

Re: OpenSSL disables TLS 1.0 and 1.1

Marco d'Itri schrieb: >> The only thing you would achieve would be to force people to move >> away from Debian to distributions that are still able to interact >> with devices running ancient and highly insecure Android firmwares. > +1 I agree it's not something that should end up

Re: Mitigating the problem of limited security support

Jeremy Bicha schrieb: > understanding is that the Debian Security team has absolutely refused > to extend the "browser exception" (to allow major new versions) to > webkit2gtk, The "browser exception" applies to Chromium and Firefox, which are standalone packages (sans a few

Re: Mitigating the problem of limited security support

Alberto Garcia wrote: > The problem is that point releases with fixes for CVEs can also > introduce regressions (#855103, introduced in 2.14.4). That one was > fixed quickly, though, but that's why I was asking. The security archive doesn't scale to play catchup with all those rdeps. There's too

Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Colin Watson schrieb: > While there does exist a skeletal compatibility layer linked from the > upstream wiki [1], the OpenSSL developers explicitly don't want to > maintain this properly [2], and the OpenSSH developers say that it is > "unversioned, incomplete, barely

Re: Firefox 60esr on Stretch ?

Julien Cristau schrieb: > I expect nothing much different from previous ESR cycles: stretch will > move to 60 after 52 goes EOL in September. Exactly. Cheers, Moritz

Re: Firefox 60esr on Stretch ?

W. Martin Borgert <deba...@debian.org> schrieb: > On 2018-05-04 21:12, Moritz Mühlenhoff wrote: >> Same as all previous extension breakages incurred by ESR transitions; >> not at all. Apart from enigmail those are all not updated along >> in stable, this doesn't sca

Re: Firefox 60esr on Stretch ?

W. Martin Borgert <deba...@debian.org> schrieb: > Quoting Moritz Mühlenhoff <j...@inutil.org>: >> Julien Cristau <jcris...@debian.org> schrieb: >>> I expect nothing much different from previous ESR cycles: stretch will >>> move to 60 after 52 goes EOL

Re: Firefox 60esr on Stretch ?

Emilio Pozuelo Monfort <po...@debian.org> schrieb: > On 16/05/18 19:12, Moritz Mühlenhoff wrote: >> I've started to look into this; I have created a llvm-4.0 build >> for stretch and build a bootstrap build of rustc 1.24 against it. >> Those two went fine. >&

Re: Firefox 60esr on Stretch ?

Hideki Yamane schrieb: > Firefox60 needs rustc (>= 1.24) to be built but rustc in stretch is 1.14. > rustc (>= 1.24) needs llvm-4.0 and cargo but it is not in stretch... > > - add llvm-4.0 and cargo to stretch > - backport rustc > - rebuild build-depends: rustc

Re: Compiler with Spectre mitigation retpoline/-mindirect-branch=thunk

Robin Geuze schrieb: > I was wondering, are the debian maintainers planning on backporting the > -mindirect-branch=thunk support introduced in GCC 7.3 and 8.1 to the > compilers available on Jessie and Stretch? While this is not necessarily > a security fix for the compiler

Re: Compiler with Spectre mitigation retpoline/-mindirect-branch=thunk

Philipp Hahn wrote: > PS: Here are the 7 relevant GIT commpits for gcc-4.9 from H.J. Lu's GIT > repository for reference: >> 1fb3a1828fa x86: Disallow -mindirect-branch=/-mfunction-return= with >> -mcmodel=large >> 7ab5b649f72 x86: Add 'V' register operand modifier >> 5550079949a x86: Add

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

Raphael Hertzog schrieb: > What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? There's clearly a set of software which is of high quality, but where upstream's development practices are not usefully aligned with our

Re: Extended Long Term Support for Wheezy

Raphael Hertzog wrote: > some of the LTS sponsors are looking to extend the support period of > Debian 7 Wheezy (from a few months up to a full year). > > Our question is whether this can be done on debian.org infrastructure. LTS has a clearly defined scope, while this is essentially contracting

Re: Firefox 60esr on Stretch ?

Hideki Yamane schrieb: > Hi, > > On Fri, 18 May 2018 10:29:03 +0200 > Moritz Mühlenhoff wrote: >> > Does it fail like in bug #858153 (which has a patch) or in a different way? >> >> That bug is a year old and for 0.19, not sure if it's still any relevant >

Re: Extended Long Term Support for Wheezy

On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote: > But assuming that we keep updates hosted on some debian.org host, do you > think it's OK to continue to use the security tracker to track > vulnerabilities in wheezy? Need to be discussed with the rest of the team, I'm not really

Re: Uncoordinated upload of the rustified librsvg

Seth Arnold schrieb: > It doesn't help that the distributions in general want to support Firefox > on more platforms than the Rust team supports as tier-1 platforms. A > constant cadence of updates every six weeks is faster than anything else > excepting the Linux kernel. It's a lot of work. Why

Re: Proposal: Repository for fast-paced package backports

Thomas Goirand schrieb: > And for a start, I don't think you really need a buildd network, just amd64 > is ok-ish. Agreed. If there's actual demand for further architecture support, it will appear naturally by people offering to do the necessary setup. Cheers, Moritz

Re: AMDGPU+OpenCL with Debian?

Mo Zhou schrieb: > On 2019-06-18 03:15, PICCA Frederic-Emmanuel wrote: >> Same here... with WXX100 cards. >> what about rocm packaging ? > > Not easy. Involves a toolchain. > Is ROCm promising enough to challenge CUDA? > (Although ROCm has already beaten CUDA in > terms of license). You may find

Re: AMDGPU+OpenCL with Debian?

Michael Kesper schrieb: > On 18.06.19 22:55, Moritz M=C3=BChlenhoff wrote: >> You may find https://phabricator.wikimedia.org/T148843/#5078403 >> (and later) interesting,=20 > > This seems to require wikimedia authentication. > Is there some information publicly available about it? Ah, that's

Re: Do we want to Require or Recommend DH

Simon McVittie schrieb: > Packages using dh also make it a lot more straightforward to do > archive-wide changes - similar to the benefit of using debhelper, but > for changes that affect the "shape" of the build system rather than the > details of individual steps. As a concrete example, Or

Re: binutils security support (Re: fixing debian-security-support upgrades from stretch (for good))

Holger Levsen schrieb: > (and yes, I also agree this is quite a desaster, just like > kde4libs/khtml only is suitable for trusted content, which IOW means, > one should not use konqueror or kmail on the interweb.) That is the upstream status quo and not in any way specific to Debian, we're just

Backports needed for Firefox/Thunderbird ESR 68 in Stretch

Hi, Firefox 68 will be the next ESR release series. With the release of Firefox 68.2 on October 22nd, support for ESR 60 will cease. ESR 68 will require an updated Rust/Cargo toolchain and build dependencies not present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). Stretch was

Re: The noudeb build profile and dh-only rules files

Theodore Ts'o schrieb: > Back in the days of boot/root installation floppies, saving every last > byte was clearly important. It's probably worth discussing/investigating whether udebs in general still make sense for d-i in 2019? It was a design choice made 15 years ago, but disk/network

Re: Backports needed for Firefox/Thunderbird ESR 68 in Stretch

On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: > Hi, > Firefox 68 will be the next ESR release series. With the release of Firefox > 68.2 > on October 22nd, support for ESR 60 will cease. > > ESR 68 will require an updated Rust/Cargo toolchain and

Re: BITS from the DPL For September/October 2019

Thomas Goirand schrieb: > My understanding is that the current guidance is that doing init script > isn't mandatory. With policy not updated, people claim it's mandatory, see e.g. #925473 on Tomcat. The discussed GRs would provide clarification on what the project at large actually wants (and

Re: BITS from the DPL For September/October 2019

Thomas Goirand schrieb: > "I’d very happily maintain the init script." > > I haven't read all the bug entry, but if someone is claiming that > accepting such contribution is mandatory, then that's very much right, > at least that the consensus we're in right now, indeed. This isn't limited to

Re: Automated removal of RC buggy packages

On Mon, Nov 11, 2019 at 06:00:18PM -0500, Sam Hartman wrote: > Moritz> We should even work towards automating this further; if a > Moritz> package is RC-buggy for longer than say a year (with some > Moritz> select exceptions) it should just get auto-removed from the > Moritz>

Re: Python 2 removal in sid/bullseye: Progress and next steps

Scott Kitterman schrieb: > One maintainer doesn't get to block the removal of an entire stack like Qt4. > I think there's a reasonable point of discussion about when RoQA is > appropriate, but there comes a time when stuff just has to go. > That doesn't make it a free for all, but for old,

  1   2   >