On Mon, Mar 14, 2022 at 09:43:15PM +0100, Jérémy Lal wrote:
> > We are currently considering the following dates as our freeze
> > dates. If you are aware of major clashes of these dates with anything
> > we depend on please let us know. We also like to stress again that we
> > really would like to
Hi,
On Mon, Mar 14, 2022 at 6:23 PM Jameson Graef Rollins
wrote:
>
> On Mon, Mar 14 2022, Paul Gevers wrote:
> > We are currently considering the following dates as our freeze
> > dates. If you are aware of major clashes of these dates with anything
> > we depend on please let us know. We also l
On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote:
> Yes, this is true. These are the unit and script that I use, and I think
> that Debian would benefit from having something like this available in
> some common package.
...
> $(systemctl status "$FAILED_UNIT" --full --lines=100)
Unfortuna
On 2022-03-13 01:07, Simon McVittie wrote:
> - reserving an environment variable like SKIP_CRON_JOB_UNDER_SYSTEMD=1
> to act as a request to skip parsing this cron job on systemd systems
> (it would also be set like any other environment variable when the cron
> job is executed on a non-syste
On Mon, Mar 14 2022, Paul Gevers wrote:
> We are currently considering the following dates as our freeze
> dates. If you are aware of major clashes of these dates with anything
> we depend on please let us know. We also like to stress again that we
> really would like to have a short Hard and Full
Hi Paul,
These dates are in the past, was it intended for the dates to be in
Janruay, February, and March of 2023 instead of 2022?
Jesse
On 2022-03-14 5:36 p.m., Paul Gevers wrote:
> Dear all,
>
> We are currently considering the following dates as our freeze
> dates. If you are aware of major
On Mon, Mar 14, 2022 at 9:36 PM Paul Gevers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear all,
>
> We are currently considering the following dates as our freeze
> dates. If you are aware of major clashes of these dates with anything
> we depend on please let us know. We als
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
[Message resent because the year was wrong]
Dear all,
We are currently considering the following dates as our freeze
dates. If you are aware of major clashes of these dates with anything
we depend on please let us know. We also like to stress agai
Am 14.03.22 um 20:43 schrieb Josh Triplett:
Michael Biebl wrote:
I'd agree here. user crontabs are such a niche case where systemd's
own facilities don't provide a direct replacement.
That said, my main point was about packages shipping cron files.
As a distro we'd benefit if those shipped na
Michael Biebl wrote:
> I'd agree here. user crontabs are such a niche case where systemd's
> own facilities don't provide a direct replacement.
>
> That said, my main point was about packages shipping cron files.
>
> As a distro we'd benefit if those shipped native systemd timers
> (instead or in a
Hi,
> I think we can all agree upon bumping the lintian severity to
> warning.
I am not sure there is unanimous support. Instead, I would like to
propose the following compromise (as I have before).
> 1.0 native is sometimes better than 3.0 (native) because dpkg-source
> refuses to build a 3.0 n
Am 14.03.22 um 16:28 schrieb Colin Watson:
On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote:
On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote:
I don't think that's a very constructive line of argument. As a former
maintainer, it was evident that user crontabs (crontab -e) are
On Mon, 2022-03-14 at 15:28 +, Colin Watson wrote:
> I'm not particularly anti-systemd - there are lots of things about it
> that I like and use. However, I'm not sure the ergonomics of it
> weighed up against user crontabs are particularly favourable.
I think we are only talking about possib
Hi Peter,
Am Mon, Feb 21, 2022 at 07:40:26PM +0200 schrieb Peter Pentchev:
> > there was a (private) request to upgrade libzstd to latest 1.5.2.
> >
> > I'd like to repeat that I'm really convinced that libzstd should *not*
> > be maintained in the Debian Med team but rather some core team in
> >
On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote:
> On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote:
> > I don't think that's a very constructive line of argument. As a former
> > maintainer, it was evident that user crontabs (crontab -e) are still
> > very popular, as are some
On 2022-03-14 08:48, Marc Haber wrote:
> On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner
>> I don't think that's a very constructive line of argument. As a former
>> maintainer, it was evident that user crontabs (crontab -e) are still
>> very popular, as are some other perhaps niche features
On Mon, Mar 14, 2022 at 01:10:19PM +, Wookey wrote:
> > You're trying to produce packages from CI builds or other automation
> > where you sometimes have native Debian revisions.
> >
> > * you are producing a package where you have distinct upstream and
> > debian branches, and you cannot co
On 2022-03-10 12:09 -0700, Sam Hartman wrote:
> > "Steve" == Steve McIntyre writes:
>
> Steve> Why on earth *would* you mess around using Debian revisions
> Steve> on a native-format package, though?
>
> You're trying to produce packages from CI builds or other automation
> where you
On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote:
> On Mar 14, Paul Wise wrote:
>
> > AFAICT OnSuccess/OnFailure services don't recieve the output of the
> > succeeding/failing service. So the mail sending service needs to dig
> > around in the systemd journal. Or make the service output go
On Mon, 14 Mar 2022 at 11:47:33 +0100, Marco d'Itri wrote:
> On Mar 14, Paul Wise wrote:
> > AFAICT OnSuccess/OnFailure services don't recieve the output of the
> > succeeding/failing service. So the mail sending service needs to dig
> > around in the systemd journal.
>
> Yes, this is true. These
On Sun, Mar 13, 2022 at 09:47:01PM +0100, Philip Rinn wrote:
> On 13.03.22 at 18:47, Domenico Andreoli wrote:
> > Now, wouldn't be nice to have the latest version uploaded to main and
> > the renamed alternative to NEW?
>
> Absolutely, that's what I just did - at least the first part. Uploading it
On Mar 14, Paul Wise wrote:
> AFAICT OnSuccess/OnFailure services don't recieve the output of the
> succeeding/failing service. So the mail sending service needs to dig
> around in the systemd journal. Or make the service output go to a file,
> FIFO or socket and then send that to a mail.
Yes, th
On Mon, 14 Mar 2022 09:29:56 +0800, Paul Wise wrote:
>The cron feature of sending the output via email by default isn't
>possible to get easily with systemd timers or systemd-cron, unless you
>modify every single timer to manually send email or use systemd-cron
>and have every single timer fail.
On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner
wrote:
>On 2022-03-13 11:06, Marc Haber wrote:
>> The anti-systemd faction in Debian is cordially invited to step in,
>> bring cron and cronie up to shape, before asking the rest of the
>> Distribution to stick with essential system software th
On Sun, 13 Mar 2022 20:52:47 -0600, Sam Hartman
wrote:
>Let me try asking something more reasonable.
>If you end up tightening down world readableness, let me know so I can
>reject the umask patch, because I suspect if your decision to tighten
>down being world readable sticks, the 15 year old use
On Mon, 2022-03-14 at 07:11 +0100, Michael Biebl wrote:
> See https://lists.debian.org/debian-devel/2020/01/msg00205.html
AFAICT OnSuccess/OnFailure services don't recieve the output of the
succeeding/failing service. So the mail sending service needs to dig
around in the systemd journal. Or make
26 matches
Mail list logo
