neering. If that went
through, I'd expect results to be publicly available in the next days.
Cheers,
Moritz
and s390x. I'm adding the respective porter lists, if there's
consensus among porters of a given arch other than amd64 to also add
the flag, please post a followup to #918914.
Cheers,
Moritz
Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> Hey Moritz,
>
> On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > I think this should rather be applied early after the Bookworm
> > release (and ideally we can also finish off the necessary testing
>
t; If this is correct, then we probably should not include singularity-container
> in bookworm, better than possibly need to remove it after bookworm release in
> a
> point release.
Agreed.
Cheers,
Moritz
eady for it (#918914)).
Cheers,
Moritz
e-gost-openssl package.
Cheers,
Moritz
abaSSL to the many archs
we have in Debian, then keep it in unstable only by filing a bug to block
it from testing.
Cheers,
Moritz
g for that new section (as opposed
to non-free where this is limited).
Cheers,
Moritz
Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: libapache2-mod-oauth2
Version : 3.2.2
Upstream Author : Hans Zandbelt
* URL : https://github.com/zmartzone/mod_oauth2
* License : AGPL-3
roject.org/wiki/Changes/NtpReplacement
Cheers,
Moritz
There are only 24 packages left using dpatch and the vast majority of remaining
uses are packages which haven't seen a maintainer upload for a decade or longer.
Some of these have existing "please migrate to source format 3(quilt)" bugs
already
and in the interest of more streamlined packaging wo
modified
to includen buster-proposed-updates temporarily):
I'd say if it works out without additional overhead, let's also update
buster-security,
but it's also important not to overstretch the time/resources, so focusing on
bullseye and
EOLing buster is also an option for sure.
Cheers,
Moritz
to March 2019...
Cheers,
Moritz
On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > Exactly that.
> >
> > I'd suggest anyone who's interested in seeing Chromiu
gets actively maintained again there's no real blocker to have it in
bookworm, but it's a lot of work.
Cheers,
Moritz
perfect task for a Debian Janitor fixer
script, have you considered filing a task for this? After all those transitional
deps are reliably detectable and fixable.
Cheers,
Moritz
une reverse deps. The same process which also happens/
happened for many other outdated and security relavant libs, think OpenSSL 1.0.
Talk is cheap if you're not the one who has to deal with the consequences
(like backporting security fixes to an unsupported release)
Cheers,
Moritz
Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: seadrive-gui
Version : 2.0.7
Upstream Author : Seafile Ltd.
* URL : https://github.com/haiwen/seadrive-gui
* License : Apache-2.0
Programming
Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: seadrive-fuse
Version : 2.0.6
Upstream Author : Seafile Ltd.
* URL : https://github.com/haiwen/seadrive-fuse
* License : GPL-3.0
Programming
On Wed, Sep 02, 2020 at 05:25:28AM +0900, Mike Hommey wrote:
> Note Firefox doesn't need wasi-libc at the moment. Neither does
> thunderbird AFAICT.
Not Firefox/Thunderbird itself, but rustc in the versions needed by ESR 78
build depends on it.
Cheers,
Moritz
LLVM 11 or so, but happy to
be proven wrong :-) So maybe let's directly move to 10 directly.
Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against
LLVM, then.
Cheers,
Moritz
[Adding debian-devel to the list]
On Sun, Aug 02, 2020 at 06:21:30PM +0200, Moritz Mühlenhoff wrote:
> > We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3
> > comes out. We have some time still, but if we want FF and TB to keep being
> > supported, we&
t to be stuck on it's current
> version, so any objection if I look into making an NMU upload for this
> package?
It doesn't need a one time NMU, but an additional 1-3 active maintainers.
Failing that, we should rather drop it for bullseye.
Cheers,
Moritz
astructure-announce, January has seen the
12.6/12.7 updates, February 12.8, March 12.9 and the 12.10 update happened
last Thursday.
Cheers,
Moritz
uot;once for the initial upload" and "randomly
when new new binary packages" appear. Plus everyone keen on reviewing
copyright files is always able to report bugs in the BTS.
Cheers,
Moritz
Debian's release cycles, but I think Janos' tradeoffs
seems fair for packaging kubernetes.
Cheers,
Moritz
Thomas Goirand wrote:
> Gosh, these are all mine... Don't worry, no need to bother filling bugs,
> I'll take care of it. However, what package should it depends on now?
On "puppet".
Cheers,
Moritz
n-specific kernel patch
by default, so I'd say that src:linux should be patched as well, this changes
the default at the deepest level and the /etc/sysctl.conf kicks in for
anyone running custom built kernels.
Cheers,
Moritz
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 fro
t; of phasing out obsolete software (qt4, openssl 1.0,
etc.) are currently too manual and too time-consuming.
Cheers,
Moritz
ives,
forcing the least common denominator of init system features.
Cheers,
Moritz
ually wants (and what policy should spell out).
Cheers,
Moritz
binary
package and they tend to get stale with changes to binary names anyway
(soname changes to libs etc.)
Cheers,
Moritz
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 buil
but disk/network constraints
changed a lot since then. Maybe ditching them entirely would actually
reduce a lot of toil in d-i and make d-i development more flexible?
(Honest question, not trying to insinuate anything)
Cheers,
Moritz
lease before October 22nd (or in case of poor timing, we can also release
build
dependency updates via stretch-security).
Cheers,
Moritz
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 availab
(hsa-ext-rocr-dev) is optional and was axed out
in the tests).
Cheers,
Moritz
e're just the only ones transparent about it instead of wiping it
under the carpet.
Cheers,
Moritz
g based on traditional debhelper and or even not using
debhelper at all.
Cheers,
Moritz
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
;s a lot of work.
Why doesn't Ubuntu ship the ESR releases in their stable releases, then?
Cheers,
Moritz
ith strange measures to overcome at least the first
obstacles (mouse movements, strace-call) I somehow suspect it.
Sincerely yours,
Moritz
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (750, 'testing'), (50, 'stable
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
&
Emilio Pozuelo Monfort 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.
>>
>> However carg
recent libgit than we have in stretch).
Cheers,
Moritz
.
in some meta data on ftp-master or in whatever tooling involved) and
then have a mechanism to yank all those packages out of testing once
we've entered a freeze.
Cheers,
Moritz
W. Martin Borgert 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 scale at all. If you want you
W. Martin Borgert schrieb:
> Quoting Moritz Mühlenhoff :
>> Julien Cristau schrieb:
>>> I expect nothing much different from previous ESR cycles: stretch will
>>> move to 60 after 52 goes EOL in September.
>>
>> Exactly.
>
> How will we deal wi
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
ian release (for
the demands of a specific group of users).
Cheers,
Moritz
contracting
work to extend the life time of some packages for some customers.
I don't see a compelling reason for it to run on Debian infrastructure.
Cheers,
Moritz
vide packages for say Nextcloud,
the Elastic stack or Grafana (or even gitlab, while packaged
in stretch, salsa also follows upstream and even backporting
the first set of security fixes isn't done after a month (#888508).
Cheers,
Moritz
ve been merged there.
He also maintains a 4.9 branch of his patches on Github, but those
are still in flux. When they are finalised they'll provide the basis
for a jessie update.
Cheers,
Moritz
e_function
Two additional patches have been added to HJ's 4.9 branch since then.
Cheers,
Moritz
. This fork adds
>new features, making it a one-way transition. With all due respect,
>as far as I can tell it's a one-person fork with very limited uptake
>compared to OpenSSH, and I don't think it would be wise to switch
>Debian over to it. (If somebody wants to package it separately for
>the extra features, that's their affair, but it wouldn't solve the
>problem at hand.)
Certainly not :-)
Cheers,
Moritz
blame old Android releases.
Cheers,
Moritz
d: intrigeri mention that new features are
now added to Linux mainline. Was there ever an attempt to upstream
those existing patches (e.g. for network socket mediation); was it
NACKed by upstream for conceptual problems or was it simply never
attempted due to time/resource constraints?
Cheers,
Moritz
a lot of the AppArmor profiles currently in use are
coming from Ubuntu or OpenSUSE. If one of those profiles relies
on features which are not upstreamed on the kernel end, how's
that handled?
Cheers,
Moritz
w
people to testdrive via s-p-u. But that's up for the SRMs to
decide (and I doubt they want to deal with that kind of API
"stability" either).
Cheers,
Moritz
s (sans a few addons breaking), but unless webkit
provides a long term branch with API stability guarantees, that's
not a workable. "Rebase to a new 2.x branch every six months and let's
hope that it doesn't break any rdeps" is not a workable solution.
Cheers,
Moritz
t to them on behalf
of the project should probably be initiated by the DPL. Fortunately
there's a DPL election happening, so a perfect time to raise that question
to the candidates :-)
Cheers,
Moritz
on, it's also questionable whether it will receive any support
from its author(s). I very much doubt cloudflare will use it much
longer.
Cheers,
Moritz
Stefan Fritsch schrieb:
> On Friday, 18 November 2016 22:22:59 CET 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
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
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 yes, I would step back and switch libssl
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
ng with this, please?
If you're going that route, you need to make sure to clearly indicate
that people still need subscribe to debian-security-announce. We will
inevitably have cases where additionally information is needed to
set an update into effect.
Cheers,
Moritz
her small subset of overall policy
changes).
Cheers,
Moritz
t all the copyright holders and license holders
at upload time. That would even provide up-to-date copyright files since
effectively 95% of all debian/copyright files are written once for the
initial upload and then never touched again.
Cheers,
Moritz
#x27;s there a wide range of 1.1 features which will b
e important during the lifetime of stretch (e.g. chacha20/poly1305 support).
Cheers,
Moritz
at h
ttps://release.debian.org/transitions/html/jasper-rm.html
I'll start filing bugs in a week or so (initially with non-RC severity, but
they will be upgraded after a few weeks).
Cheers,
Moritz
lugin-nonfree could speed this up by proposing patches in
the BTS.
Cheers,
Moritz
.
Indeed. If there's any worthwhile wrt security enhancements, please submit
patches to Mozilla so that it ends up in Firefox.
Cheers,
Moritz
secary
> to me.
They're certainly necessary. W/o the icons there would be no indication
which search engine is currently selected in the Iceweasel search box.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe&qu
towards outright giving up.
Agreed, spending further time on LSB compliance seems like a waste
of time/resources at this point.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@list
ned, you should rather
adopt it and update it to the most recent upstream release.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnm7hj5n.3ms@inutil.org
Thank you very much, that worked instantly! I don't know why kexec-tools
was installed, but now, it isn't any longer and the reboot-cycle is
broken.
On Fri, 17 Oct 2014, Konstantin Khomoutov wrote:
On Fri, 17 Oct 2014 15:28:18 +0200
Moritz wrote:
* What led up to the situat
Package: general
Severity: normal
Dear Maintainer,
* What led up to the situation?
After the last upgrade, the system would not halt any more. Instead, it runs
into a restart cycle. The restart bypasses GRUB, i.e. one a computer with
multiple OS, it restarts linux directly.
The machine in us
On Thu, Sep 18, 2014 at 11:12:28AM +0800, Paul Wise wrote:
> On Thu, Sep 18, 2014 at 4:15 AM, Moritz Muehlenhoff wrote:
>
> > Does anyone have a better suggestion?
>
> What about just bumping the Priority?
This wouldn't ensure that updated systems would get it ins
lso, which package should
recommend debian-security-support?
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140917201506.GA9244@pisco.westfalen.local
ona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
e a different ballpark. Please contact
us at t...@security.debian.org so that we sort that out.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnluhrq3.61t@inutil.org
ity issues; when
I contacted Michael Niedermeyer in private we has always quick to reply,
while libav-security@ seems understaffed: Several queries in the past needed
additional poking, some were left unaddressed until today. Also, the Google
fuzzer guys stated that more samples are unfixed
ribution for scientific works.
You already can by adding this to your rules file:
export DEB_CFLAGS_MAINT_APPEND = -O3
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
On Mon, Mar 17, 2014 at 10:33:32AM +0100, Holger Levsen wrote:
> Hi,
>
> On Mittwoch, 5. März 2014, Moritz Muehlenhoff wrote:
> > Security release workflow
> > -
> > * We're currently using Subversion. We discussed changing to git, but
>
m filtering debian-devel-changes and looking for words like
> security, overflow, attack etc? This might turn up some things that
> don't have CVEs but should.
Yes, at least two people are reading d-d-changes on a daily basis.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-de
hint* *hint*
needs actual commitment:)
Skipping releases will not be possible/supported, if anyone wants to
upgrade from squeeze-lts to jessie both updates can to be done subsequently
in one maintenance windows.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debi
this didn't
make
the cut yet:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html
As for the GSoC project; GCC partiticates, if anyone wants to push this, I
suggest
to talk to GCC developers and see whether there's a mentor available.
Cheers,
Moritz
--
To UNSUBSCRIBE, ema
Jonathan Dowland 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 f
we've found uses for both implementations.
But we still try to minimise such cases as much as possible. And for
libav/ffmpeg this simply isn't managable at all due to the huge stream
of security issues trickling in. We need definitely need to pick one
solution only.
Cheers,
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 wrote:
> > Hi,
> > lcms needs to go for jessie in favour of lcms2 (#717928). (liblcms1-dev ->
> > liblcms2-dev)
> > The maintainer seems MIA,
example somebody discovers a
> serious security issue. Which is very possible, as I don't think anyone is
> really interested in the source code any more.
I agree with the removal. http://www.debian.org/security/2011/dsa-2375 was
already a sufficiently unpleasant christmas present (ex
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
w
builds/conversions (lcms.h -> lcms2.h), which all
went fine (ghostscript, inkscape). I also noted that poppler is fixed
in experimental.
Cheers,
Moritz
Andreas Metzler
enblend-enfuse (U)
Andreas Tille
entangle (U)
Ari Pollak
gimp
Arthur Loiret
wine (U)
wine-
) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
s since 9 months (708140).
It is simply unmaintained. If there were interest it could easily be fixed.
to support current libav.
But there's simply no point in doing that work, since mpv is so much
cleaner and better.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@
On Sun, Dec 15, 2013 at 10:38:58PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/15/2013 10:11 PM, Moritz Mühlenhoff wrote:
> > Bálint Réczey schrieb:
> >> How about introducing the ffmpeg shared libraries with libffmpeg
> >> prefix instead of libav prefix?
>
Bálint Réczey 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 to debian
o 5.1.71
- Several fixes need to be backported to gimp
- Several Drupal 6 fixes need to be backported
- Several fixed need to be backport to Ruby 1.8
If you want to help out, mail t...@security.debian.org so that we can
ensure that no work in duplicated.
Cheers,
Moritz
--
To UNSUBSCRIBE,
1 - 100 of 259 matches
Mail list logo
