roject.org/wiki/Changes/NtpReplacement
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
g for that new section (as opposed
to non-free where this is limited).
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
e-gost-openssl package.
Cheers,
Moritz
eady for it (#918914)).
Cheers,
Moritz
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
binary
package and they tend to get stale with changes to binary names anyway
(soname changes to libs etc.)
Cheers,
Moritz
ually wants (and what policy should spell out).
Cheers,
Moritz
ives,
forcing the least common denominator of init system features.
Cheers,
Moritz
t; of phasing out obsolete software (qt4, openssl 1.0,
etc.) are currently too manual and too time-consuming.
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
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
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
Debian's release cycles, but I think Janos' tradeoffs
seems fair for packaging kubernetes.
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
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
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
[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&
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
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
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
her small subset of overall policy
changes).
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
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
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
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
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
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
e_function
Two additional patches have been added to HJ's 4.9 branch since then.
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
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
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
ian release (for
the demands of a specific group of users).
Cheers,
Moritz
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
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
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
.
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
recent libgit than we have in stretch).
Cheers,
Moritz
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
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
&
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
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
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
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
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
blame old Android releases.
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
lugin-nonfree could speed this up by proposing patches in
the BTS.
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
#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
to that are not supporting,
>> adopting, or intending to adopt the .desktop standard?
>
> Have you any evidence that (or any idea whether) fvwm, icewm, wmaker,
> lwm, ...[1] plan to support .desktop?
It is trivial to support desktop in icewm. Check out icewm.py, one of my few
prog
pretty simple to implement - just more
> text fields.
Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and
uncustomizable the Debian menu system at the moment.
> That way we support the upstream menu entries in
> everything, not just kde and gnome.
--
Moritz Moe
Andrew Suffield wrote:
> On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote:
>> You do realize that the desktop standard has more features than the
>> debian menu system? Like i18n, icon theming, dynamic construction of a
>> menu hierarchy based on
Bruce Sass wrote:
> On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote:
>> Freedesktop standard supporting
>> systems are probably used by 90% of all Debian desktop users.
>
> Unsubstantial, and probably bullshit.
Maybe you are just incapable of finding arguments and
E and Gnome.
This is not true. Almost all features are being used in current KDE and to
some degree by current GNOME. Could you please give examples?
--
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme
Cameron Patrick wrote:
> On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote:
> | This is not true. Almost all features are being used in current KDE and
> | to some degree by current GNOME. Could you please give examples?
> The Categories= field (to place .d
SuSE, you already have the same menue in both
DEs.
--
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain.
(ANATOLE FRANCE)
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-
201 - 259 of 259 matches
Mail list logo
