Hi,
I get the following error while trying to rebuild
'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a
pbuilder environment:
...
g++ -c -pipe -O2 -Wall -W -fPIC -I. -I../../../mkspecs/linux-g++ -o db2.o
db2.cpp
db2.cpp:40:20: fatal error: sqlcli.h: No such file or direct
On വ്യാ, Jan 2, 2020 at 21:43, debacle
wrote:
On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote:
El jue., 2 ene. 2020 08:28, Julien Cristau
escribió:
> No, it'll eventually get retried and (assuming it passes) the
migration
> block will lift.
And "eventually" is normall
Hi Carsten!
On Wed, 8 Jan 2020 at 06:51, Carsten Behling
wrote:
>
> Hi,
>
> I get the following error while trying to rebuild
> 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a
> pbuilder environment:
qtbase can't be cross built "as is" in Stretch, and possibly not in
Am Dienstag, den 07.01.2020, 20:19 -0800 schrieb Russ Allbery:
> Noah Meyerhans writes:
> > On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote:
> > > I disagree here. I don't want you to overrule my decision for a
> > > cron-script. If a user has enabled a cron-job you shouldn't change
Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:
> Daniel Leidert writes:
> ...
> > Please ask during installation and give the question an appropriate
> > priority.
> > By choosing the priority you can even achieve a "silent" transition for
> > "normal" users and let more advanced u
On 2020-01-08 14:27, Daniel Leidert wrote:
And what s the benefit of this change: Getting rid of cron?
The very simple thing is: CRON=1 enables a cron job. It does *not* say:
"Please
enable something different as long as it achieves the same." There is
nothing
wrong with the cron job and it wo
On Wed, 08 Jan 2020, Daniel Leidert wrote:
> > This strikes me as clutter that will never be removed from debconf, so
> > let's not decide to do that for every package that might need a timer.
>
> Why should this question ever been removed? What is your goal? Getting rid of
> cron-jobs?
The quest
Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
> On 2020-01-08 14:27, Daniel Leidert wrote:
> > And what s the benefit of this change: Getting rid of cron?
> >
> > The very simple thing is: CRON=1 enables a cron job. It does *not* say:
> > "Please
> > enable something different as
Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:
[..]
> How about modifying the shipped /etc/default/spamassassin to include a
> comment explaining what's going on, and how to enable the timer instead?
It seems I misread this part at first. Is it your suggestion to keep the
default
On Wed, Jan 08, 2020 at 05:15:36PM +0100, Daniel Leidert wrote:
It seems I misread this part at first.
So maybe you should slow down on the emails?
在 2020-01-08三的 16:36 +0530，Pirate Praveen写道：
>
> On വ്യാ, Jan 2, 2020 at 21:43, debacle
> wrote:
> > On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > El jue., 2 ene. 2020 08:28, Julien Cristau
> > > escribió:
> > > > No, it'll eventually get retried and (assuming it pass
On Wed, Jan 08, 2020 at 02:18:34PM +0100, Daniel Leidert wrote:
> > Yeah, that's my reaction as well. The point is to run the job
> > periodically.
>
> No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Your
> behavior here is pretty similar to Microsofts: Let the user decide if
Daniel Leidert writes:
> Am Dienstag, den 07.01.2020, 20:19 -0800 schrieb Russ Allbery:
>> Yeah, that's my reaction as well. The point is to run the job
>> periodically.
> No. The configuration says CRON=1. It doesn't say
> PERIODIC_CHECKS=1. Your behavior here is pretty similar to Microsofts:
Am Mittwoch, den 08.01.2020, 12:56 -0500 schrieb Noah Meyerhans:
> On Wed, Jan 08, 2020 at 02:18:34PM +0100, Daniel Leidert wrote:
> > > Yeah, that's my reaction as well. The point is to run the job
> > > periodically.
> >
> > No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Y
On Wed, Jan 08, 2020 at 10:36:02AM -0800, Russ Allbery wrote:
Could you be specific about what you prefer about a cron job over a
systemd timer unit? If it's just that you are familiar with cron jobs and
not systemd timer units, I'm sympathetic but I don't think that's a very
strong argument for
Hi,
I have been working with the coin3 [1] package and I have found some
curious situation today. I have build the package in my pbuilder without
any problem. Then I have tested the ci so:
- at Jan 8, 2020 3:08 PM I have pushed to salsa and the ci was activated
building the sources but failing _
Package: wnpp
Severity: wishlist
Owner: JAIR REIS
* Package name: python-cliapp
Version : 1.20140719-1
Upstream Author : Lars Wirzenius
* URL : https://liw.fi/cliapp/
* License : GPL
Programming Lang: Python
Description : cliapp is a Python framework
Michael Stone writes:
> On Wed, Jan 08, 2020 at 10:36:02AM -0800, Russ Allbery wrote:
>> Could you be specific about what you prefer about a cron job over a
>> systemd timer unit? If it's just that you are familiar with cron jobs
>> and not systemd timer units, I'm sympathetic but I don't think
On 08/01/2020 19.09, Boyuan Yang wrote:
> 在 2020-01-08三的 16:36 +0530，Pirate Praveen写道：
>>
>> On വ്യാ, Jan 2, 2020 at 21:43, debacle
>> wrote:
>>> On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote:
El jue., 2 ene. 2020 08:28, Julien Cristau
escribió:
> No, it'll eve
On Wed, Jan 08, 2020 at 11:25:56AM -0800, Russ Allbery wrote:
> > As a third party with no particular ax to grind on this, I do wonder
> > what the advantage is to adding another mechanism for this particular
> > use case, given the need to somehow handle upgrades involving an
> > existing (presuma
Russ Allbery wrote:
The one exception I can think of is if someone really wants to
customize the [spamassassin daily] job. That can be a little more
tedious to do with timer units. Right now, I think there's a bunch of
logic in the /etc/cron.daily script that someone could in theory
change. But I
Le mercredi, 8 janvier 2020, 16.33:28 h CET Daniel Leidert a écrit :
> Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
> > I think there needs to be a sensible choice for *periodic jobs* that we
> > should document as the default unless there is a reason to use something
> > else. It
Daniel Leidert writes:
> Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
>> On 2020-01-08 14:27, Daniel Leidert wrote:
>> > And what s the benefit of this change: Getting rid of cron?
>> >
>> > The very simple thing is: CRON=1 enables a cron job. It does *not* say:
>> > "Please
>>
On Mi, Jan 08, 2020 at 02:57:51 -0500, Noah Meyerhans wrote:
visible to administrators. IMO the migration to systemd timers can be
done more smoothly, so it's still preferable.
Well, since you need to support non-systemd systems as well (like mine)
the cron script is still needed (I don’t thi
Daniel Leidert writes:
> Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:
>
> [..]
>> How about modifying the shipped /etc/default/spamassassin to include a
>> comment explaining what's going on, and how to enable the timer instead?
>
> It seems I misread this part at first. Is it y
Stephan Seitz writes:
> On Mi, Jan 08, 2020 at 02:57:51 -0500, Noah Meyerhans wrote:
>> visible to administrators. IMO the migration to systemd timers can be
>> done more smoothly, so it's still preferable.
> Well, since you need to support non-systemd systems as well (like mine)
> the cron scr
On Wed, Jan 08, 2020 at 10:09:58PM +0100, Stephan Seitz wrote:
> > visible to administrators. IMO the migration to systemd timers can be
> > done more smoothly, so it's still preferable.
>
> Well, since you need to support non-systemd systems as well (like mine) the
> cron script is still needed
On Wed, Jan 08, 2020 at 10:32:07PM +0100, Philip Hands wrote:
> I don't really care what that comment says, as that's up to the
> maintainer of the package, and how they intend to deal with this in the
> future, but I'm really not a fan adding unnecessary questions to debconf.
Here's my proposal f
Noah Meyerhans wrote:
> Spamassassin has traditionally supplied a cron.daily script. I'd like
> to provide the same functionality via a systemd timer, while still
> providing cron as a fallback. For the most part, this is
> straightforward, but there are a few details on which I'd like feedback.
On 1/8/20 4:25 PM, Josh Triplett wrote:
> (I would suggest doing the same for the cron job, for new installations:
> put the script itself in /usr/lib/spamassassin or similar, and document
> that people can enable it by either enabling the systemd timer, linking
> the script from cron.daily, or cop
On 1/8/20 1:02 PM, Michael Stone wrote:
> As a third party with no particular ax to grind on this, I do wonder
> what the advantage is to adding another mechanism for this particular
> use case, given the need to somehow handle upgrades involving an
> existing (presumably working?) solution.
At my
On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote:
> >
> > I get the following error while trying to rebuild
> > 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a
> > pbuilder environment:
>
> q
On Wed, Jan 8, 2020 at 11:45 PM Richard Laager wrote:
> We do lose the automatic cron emails
This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:
This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
tool to monitor a tool and send a
Michael Stone writes:
> On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:
>> This is the main reason I haven't switched to systemd timers for my
>> personal crontab, I have some jobs that generate output (diffs of
>> various things mostly) but don't fail. There doesn't appear to be any
>
Hi,
On Wed, Jan 08, 2020 at 11:53:28PM +, Paul Wise wrote:
> On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote:
> > >
> > > I get the following error while trying to rebuild
> > > 'qtbase-opensource-src_5.7.1+dfs
36 matches
Mail list logo
