Re: [gentoo-user] insane backends

[Philip Webb]

Further to the thread re mysterious behaviour of 'sane-backends',
I remembered what happened when I set my new scanner up earlier in 2017.

There is no driver in 'sane-backends', because it contains a binary blob.
You have to download an appropriate pkg for the V550 from Epson,
which provides installers for Debian or RPM.
Presumably one of those worked with Gentoo
& that's where the 'epkowa' driver came from in  /usr/lib64/sane/ .

So relieved that I'd got it working, I failed to update my notes,
which I've now done.  Thanks for Neil's suggestions.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 4:40 PM, Ian Zimmerman  wrote:
> On 2017-11-05 14:22, Rich Freeman wrote:
>
>> Second, my actual objection is more to sticking wrappers around an
>> upstream program just to extend its capabilities, when other software
>> is maintained upstream that already does what you're re-inventing.
>> When you already have 47 different cron implementations out there, I'm
>> not sure it adds a lot to have a distro-specific solution.  The distro
>> should certainly be providing stuff like /etc/cron.*/ and the scripts
>> inside when upstream isn't providing them.  By all means include a
>> stock wrapper /etc/crontab that runs that stuff at set times for those
>> running 24x7 with vixie cron.  If run-scripts was implemented in
>> python instead of shell this objection wouldn't go away.
>
> I really want to stop prologing the agony of this thread, but I just
> have to point out that when you install cronie with the anacron flag (as
> I just did, if only to know what I'm talking about), you _still_ get a
> wrapper: it's called /etc/cron.hourly/0anacron.  Simpler than run-crons
> for sure, but the principle is the same.

Sure, but that is upstream-maintained, and that is my point.  It comes
out of the upstream contrib directory:
https://github.com/cronie-crond/cronie/blob/master/contrib/0anacron

> After all distros exist for a reason (over and above building packages).
> If upstreams always did the glue job right, a bot could handle all the
> package builds and you gentoo devs could go home ;-)

In your example upstream DID do the glue job right.  Even so, the glue
isn't the part I object to.  Running cron jobs after a system comes
back online isn't glue - that is core functionality, even if not every
implementation has it.

Distros will always have to do integration work, and that is fine.
That is the role of a distro.  And sometimes distros have to roll
their own tools when they just aren't available.  Once upon a time
service managers fell into that category.  Now this is less the case.

There is of course nothing wrong if people want to implement things.
I just tend to prefer to stick with stuff that has an upstream that is
bigger than one distro.

-- 
Rich

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 21:40, Alan McKinnon wrote:

> Agreed again. My desktop cronjobs are all empty and when I had some
> they were of the "do this once a week or once a day" variety. I didn't
> care when they ran, just that they did every so often

What about the synchronization and predictability aspect, which I
mentioned in my 1st entry in this thread?

I want _all_ my machines to do a full fsck when I turn them on the 1st
of a month.  (if a month seems too long, substitute "Sunday").  Anything
else is madness.

And yeah, desktops matter to me.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 14:22, Rich Freeman wrote:

> Second, my actual objection is more to sticking wrappers around an
> upstream program just to extend its capabilities, when other software
> is maintained upstream that already does what you're re-inventing.
> When you already have 47 different cron implementations out there, I'm
> not sure it adds a lot to have a distro-specific solution.  The distro
> should certainly be providing stuff like /etc/cron.*/ and the scripts
> inside when upstream isn't providing them.  By all means include a
> stock wrapper /etc/crontab that runs that stuff at set times for those
> running 24x7 with vixie cron.  If run-scripts was implemented in
> python instead of shell this objection wouldn't go away.

I really want to stop prologing the agony of this thread, but I just
have to point out that when you install cronie with the anacron flag (as
I just did, if only to know what I'm talking about), you _still_ get a
wrapper: it's called /etc/cron.hourly/0anacron.  Simpler than run-crons
for sure, but the principle is the same.

After all distros exist for a reason (over and above building packages).
If upstreams always did the glue job right, a bot could handle all the
package builds and you gentoo devs could go home ;-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Alan McKinnon]

On 05/11/2017 17:11, Rich Freeman wrote:
> On Sun, Nov 5, 2017 at 6:43 AM, Alan McKinnon  wrote:
>>
>> There are other schedulers out there that succeed where cron fails (eg
>> Control-M, chronos, quartz), but those are all large, bulky, designed
>> for big complex installs/requirements and probably not suited for simple
>> things you'd deploy out of a base in portage
>>
> 
> Amusing that you classify 99.999% of all desktop installs as "big
> complex installs."

Heh :-)

Well, to a first approximation all Linux installs are servers or phones
so whatever is going on in desktop space can be disregarded

>
> But, I agree that it makes far more sense to just have desktop users
> use an appropriate cron implementation designed to handle the machine
> being off most of the time vs trying to use shell scripting to make
> vixie cron into such an implementation.

Vixie cron and it's clones needs to die, really. The number of places
where it makes sense is falling by the day; showing no sign of slowing
down. I think I have 3 cronjobs left across my fleet that actually make
sense and all of them are just-in-case-I-screwed-up-elsewhere safety
nets. The very idea of cron itself comes from the '80s and to be honest,
we don't work anymore like we did in the 80s
> 
> FWIW this is probably the reasoning behind including cron-like
> functionality in systemd, and having it support optionally running
> jobs if the system was down during a calendar-based event.  It was
> considered bare-bones functionality that any desktop or generic server
> would need.  It is, of course, optional, and just about any kind of
> rule is supported.  I personally use systemd-cron which basically is a
> wrapper+generator around /etc/crontab and the various /etc/cron.*/
> scripts.

Agreed again. My desktop cronjobs are all empty and when I had some they
were of the "do this once a week or once a day" variety. I didn't care
when they ran, just that they did every so often


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 8:10 AM, Ian Zimmerman  wrote:
> On 2017-11-05 07:11, Rich Freeman wrote:
>
>> But, I agree that it makes far more sense to just have desktop users
>> use an appropriate cron implementation designed to handle the machine
>> being off most of the time vs trying to use shell scripting to make
>> vixie cron into such an implementation.
>>
>> FWIW this is probably the reasoning behind including cron-like
>> functionality in systemd, and having it support optionally running
>> jobs if the system was down during a calendar-based event.  It was
>> considered bare-bones functionality that any desktop or generic server
>> would need.
>
> If Kai is right that fcron handles it, the reason is probably systemd
> people thought that had to match the functionality to be considered a
> full replacement.  Especially since fcron is the normal system cron on
> Fedora/RH, right?

Honestly, I think it is more because it is almost impossible to cover
both desktops and servers without these features, so there is little
point in adding timers if you don't support both.  The reason they're
there at all is because it falls into "core functionality" which is a
goal of systemd - it is a bit like busybox in that regard (and, indeed
busybox also implements a crond).

However, while systemd aims to go further than busybox it doesn't
actually aim to replace all the other tools that it overlaps with.
For example, resolved isn't a full substitute for bind, and timesyncd
isn't a full substitute for ntp (the latter of which is relatively
popular on random systems and not just dedicated servers).  In general
they try to focus on the client-side stuff only, with a moderate but
not minimal scope.

>
>> I personally use systemd-cron which basically is a wrapper+generator
>> around /etc/crontab and the various /etc/cron.*/ scripts.
>
> If your dislike for having this in cron itself comes down to shell
> script vs. C code, and it appears so from the above, I'm not at all sure
> I agree.  This to me seems one of the few tasks where shell script is in
> fact a good fit: mainly looking at files, timestamps, and running other
> programs.

So, two things here:

First, I'm honestly not sure I buy that shell scripts are the best
tool here.  Yes, they can look at files and timestamps, but I tend to
be of the school that shell scripts are poor environments to write
actual software in.  At best they work reasonably well for glue.  I'm
not advocating for C, but if I were implementing a cron I wouldn't be
doing it in bash.

Second, my actual objection is more to sticking wrappers around an
upstream program just to extend its capabilities, when other software
is maintained upstream that already does what you're re-inventing.
When you already have 47 different cron implementations out there, I'm
not sure it adds a lot to have a distro-specific solution.  The distro
should certainly be providing stuff like /etc/cron.*/ and the scripts
inside when upstream isn't providing them.  By all means include a
stock wrapper /etc/crontab that runs that stuff at set times for those
running 24x7 with vixie cron.  If run-scripts was implemented in
python instead of shell this objection wouldn't go away.

Sure, back in the early days of Gentoo maybe it made a little more
sense to have our own tools just like everybody else did, and I'm not
sure I'd advocate to go removing them either.  However, I can
certainly sympathize with WONTFIX when people want to continue to add
features to them.  They're just a minimal starting point that is
implementation-agnostic - use the right tool if your requirements
exceed these.


-- 
Rich

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-05 18:12, Neil Bothwick wrote:


On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:







OT: Seems that since the last update of my MUA the formatting of my







mails is broken - at least at reply's. There are extra line breaks.







G - if you not do everything by yourself ...   ;-)







... at least you have someone else to blame.




Nobody to blame, it's more to excuse me.

--

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Neil Bothwick]

On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:

> OT: Seems that since the last update of my MUA the formatting of my 
> 
> mails is broken - at least at reply's. There are extra line breaks. 
> 
> G - if you not do everything by yourself ...   ;-)

... at least you have someone else to blame.


-- 
Neil Bothwick

WinErr 678: This will end your Windows session. Do you want to play
another game?


pgplUCij_CE3p.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

There are other schedulers out there that succeed where cron fails (eg



Control-M, chronos, quartz), but those are all large, bulky, designed


for big complex installs/requirements and probably not suited for 



simple



things you'd deploy out of a base in portage






Long time ago I decided to use fcron only. The reasons doesn't matter, 

but thus I can talk about fcron only. But you are right, there are a lot 

of others. At least I tried to answer Ian's question as exact as 

possible. I realized the inaccuracy in it too. Wasn't it to me? Than 


sorry for the noise.



cron is stupid and deliberately so. We really ought to let it remain 



stupid







The decision what have to be done MUST be made by the user/sysadmin



first. Than you can do the config to reach your goal. But that does go



to far now.







+1 agreed.







I've always maintained that cron cannot possibly know what the scripts



it launches deem to be correct. It's a countdown time and launcher, not


an orchestrator. It can figure out what to do if 2am happens twice 



(just



don't do it the second time), but not what should happen if 2am was



missed for any reason, including DST or poweroff or overeager ntpdate






The simplest approach to fixing missed jobs is to have the script 



itself


track what is correct. If it's lock and records files indicate 



something



didn't happen when it should, the script can do it's own repair or do



it's work twice. Or whatever else is appropriate.




@Alan, I like your writings. Unfortunately I'm not able to do so, thus 


my (very seldom) answers are sometimes to short. ;-)



OT: Seems that since the last update of my MUA the formatting of my 

mails is broken - at least at reply's. There are extra line breaks. 


G - if you not do everything by yourself ...   ;-)



--

Sent with eQmail-1.10

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 07:11, Rich Freeman wrote:

> But, I agree that it makes far more sense to just have desktop users
> use an appropriate cron implementation designed to handle the machine
> being off most of the time vs trying to use shell scripting to make
> vixie cron into such an implementation.
> 
> FWIW this is probably the reasoning behind including cron-like
> functionality in systemd, and having it support optionally running
> jobs if the system was down during a calendar-based event.  It was
> considered bare-bones functionality that any desktop or generic server
> would need.

If Kai is right that fcron handles it, the reason is probably systemd
people thought that had to match the functionality to be considered a
full replacement.  Especially since fcron is the normal system cron on
Fedora/RH, right?

> I personally use systemd-cron which basically is a wrapper+generator
> around /etc/crontab and the various /etc/cron.*/ scripts.

If your dislike for having this in cron itself comes down to shell
script vs. C code, and it appears so from the above, I'm not at all sure
I agree.  This to me seems one of the few tasks where shell script is in
fact a good fit: mainly looking at files, timestamps, and running other
programs. 

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] [OT] AppImage? What's that?

[Peter Humphrey]

On Sun, 5 Nov 2017 16:46:07 +0200

> Reading only this thread, it looks like an upstream used a horribly
> incomplete scheme for distribution that isn't even ready for launch.

What, like KDE-4, KDE-plasma, ... ?

-- 
Regards,
Peter.

[gentoo-user] How to crack open an *.AppImage Was: [OT] AppImage? What's that?

[tuxic]

On 11/05 04:04, tu...@posteo.de wrote:
> On 11/05 04:46, Alan McKinnon wrote:
> > On 05/11/2017 15:48, tu...@posteo.de wrote:
> > > On 11/05 07:21, Tom H wrote:
> > >> On Sun, Nov 5, 2017 at 7:11 AM,  wrote:
> > >>> On 11/05 06:29, Tom H wrote:
> >  On Sun, Nov 5, 2017 at 6:20 AM,  wrote:
> > >
> > > I got an archive (???) of an Linux application, which
> > > has the extension "*.AppImage".
> > >
> > > What is that?
> > >
> > > Is it possible to "unpack" that into something more common?
> > > How to handle that?
> > 
> >  Does it use this spec?
> > 
> >  https://appimage.org/
> > >>>
> > >>> Dont know...
> > >>> How can I unpack that to look into it?
> > >>
> > >> From
> > >> https://github.com/AppImage/AppImageKit
> > >>
> > >> wget 
> > >> "https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage;
> > >> etc...
> > >>
> > > 
> > > 
> > > ./appimagetool-x86_64.AppImage appimagetool-x86_64.AppImage TestApp/.
> > > WARNING: appstreamcli is missing, please install it if you want to use 
> > > AppStream metadata
> > > appimagetool-x86_64.AppImage is a file, assuming it is an AppImage and 
> > > should be unpacked
> > > To be implemented
> > > 
> > > unpacking is not implemented yet.
> > 
> > 
> > Reading only this thread, it looks like an upstream used a horribly
> > incomplete scheme for distribution that isn't even ready for launch.
> > 
> > And yet they distribute using it.
> > 
> > I would be questioning why I'm using that upstream's project at all, and
> > find something better by an author with more clue.
> > 
> > Am I missing something?
> > 
> > 
> > -- 
> > Alan McKinnon
> > alan.mckin...@gmail.com
> > 
> > 
> 
> As so often, the persons 'up' in the hierarch decide things the people
> 'down' the hierarchy would keep their fingers off - but they will not
> be asked.
> 
> I am 'down' the hierarchy and want to unpack that
> archive/image/whatever.
> 
> Currently I am recompiling my kernel to support squashfs as it seems
> that this image is one of that images.
> If so, mounting it as an image and copying the files out of the
> mountpoints directory may work.
> 
> Fingers crossed...
> 
> Cheers
> Meino
> 
> 

OK, I have found a way -- for all hesitating with this
closed-opensource AppImage-blobs:

chmod file.AppImage
./file.AppImage # wait ...
mount # find mount point of this sealed bag,,,mine was /tmp/.mount-someting
cp -a /tmp/.mount-something ~/somesaveplace


That's it.
Happy tinkering!

Cheers
Meino

Re: [gentoo-user] [OT] AppImage? What's that?

[Rich Freeman]

On Sun, Nov 5, 2017 at 6:46 AM, Alan McKinnon  wrote:
> On 05/11/2017 15:48, tu...@posteo.de wrote:
>>
>> unpacking is not implemented yet.
>
>
> Reading only this thread, it looks like an upstream used a horribly
> incomplete scheme for distribution that isn't even ready for launch.
>
> And yet they distribute using it.
>

Nah, they just don't consider extracting the stuff without running it
important.  Nor apparently do they consider it important to support
the 0.1% of Linux users on a distro that doesn't support appimage
(just a rough estimate based by all the logos on their webpage - I
can't vouch for how well it works on the distros they list).

The concept behind it isn't terrible, but if you want to use it your
first step is to get it packaged/working on Gentoo.  I don't see any
reason that this couldn't be done - it just probably doesn't scratch
many Gentoo user's itches.

-- 
Rich

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 6:43 AM, Alan McKinnon  wrote:
>
> There are other schedulers out there that succeed where cron fails (eg
> Control-M, chronos, quartz), but those are all large, bulky, designed
> for big complex installs/requirements and probably not suited for simple
> things you'd deploy out of a base in portage
>

Amusing that you classify 99.999% of all desktop installs as "big
complex installs."

But, I agree that it makes far more sense to just have desktop users
use an appropriate cron implementation designed to handle the machine
being off most of the time vs trying to use shell scripting to make
vixie cron into such an implementation.

FWIW this is probably the reasoning behind including cron-like
functionality in systemd, and having it support optionally running
jobs if the system was down during a calendar-based event.  It was
considered bare-bones functionality that any desktop or generic server
would need.  It is, of course, optional, and just about any kind of
rule is supported.  I personally use systemd-cron which basically is a
wrapper+generator around /etc/crontab and the various /etc/cron.*/
scripts.


-- 
Rich

Re: [gentoo-user] [OT] AppImage? What's that?

[tuxic]

On 11/05 04:46, Alan McKinnon wrote:
> On 05/11/2017 15:48, tu...@posteo.de wrote:
> > On 11/05 07:21, Tom H wrote:
> >> On Sun, Nov 5, 2017 at 7:11 AM,  wrote:
> >>> On 11/05 06:29, Tom H wrote:
>  On Sun, Nov 5, 2017 at 6:20 AM,  wrote:
> >
> > I got an archive (???) of an Linux application, which
> > has the extension "*.AppImage".
> >
> > What is that?
> >
> > Is it possible to "unpack" that into something more common?
> > How to handle that?
> 
>  Does it use this spec?
> 
>  https://appimage.org/
> >>>
> >>> Dont know...
> >>> How can I unpack that to look into it?
> >>
> >> From
> >> https://github.com/AppImage/AppImageKit
> >>
> >> wget 
> >> "https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage;
> >> etc...
> >>
> > 
> > 
> > ./appimagetool-x86_64.AppImage appimagetool-x86_64.AppImage TestApp/.
> > WARNING: appstreamcli is missing, please install it if you want to use 
> > AppStream metadata
> > appimagetool-x86_64.AppImage is a file, assuming it is an AppImage and 
> > should be unpacked
> > To be implemented
> > 
> > unpacking is not implemented yet.
> 
> 
> Reading only this thread, it looks like an upstream used a horribly
> incomplete scheme for distribution that isn't even ready for launch.
> 
> And yet they distribute using it.
> 
> I would be questioning why I'm using that upstream's project at all, and
> find something better by an author with more clue.
> 
> Am I missing something?
> 
> 
> -- 
> Alan McKinnon
> alan.mckin...@gmail.com
> 
> 

As so often, the persons 'up' in the hierarch decide things the people
'down' the hierarchy would keep their fingers off - but they will not
be asked.

I am 'down' the hierarchy and want to unpack that
archive/image/whatever.

Currently I am recompiling my kernel to support squashfs as it seems
that this image is one of that images.
If so, mounting it as an image and copying the files out of the
mountpoints directory may work.

Fingers crossed...

Cheers
Meino

Re: [gentoo-user] [OT] AppImage? What's that?

[Alan McKinnon]

On 05/11/2017 15:48, tu...@posteo.de wrote:
> On 11/05 07:21, Tom H wrote:
>> On Sun, Nov 5, 2017 at 7:11 AM,  wrote:
>>> On 11/05 06:29, Tom H wrote:
 On Sun, Nov 5, 2017 at 6:20 AM,  wrote:
>
> I got an archive (???) of an Linux application, which
> has the extension "*.AppImage".
>
> What is that?
>
> Is it possible to "unpack" that into something more common?
> How to handle that?

 Does it use this spec?

 https://appimage.org/
>>>
>>> Dont know...
>>> How can I unpack that to look into it?
>>
>> From
>> https://github.com/AppImage/AppImageKit
>>
>> wget 
>> "https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage;
>> etc...
>>
> 
> 
> ./appimagetool-x86_64.AppImage appimagetool-x86_64.AppImage TestApp/.
> WARNING: appstreamcli is missing, please install it if you want to use 
> AppStream metadata
> appimagetool-x86_64.AppImage is a file, assuming it is an AppImage and should 
> be unpacked
> To be implemented
> 
> unpacking is not implemented yet.


Reading only this thread, it looks like an upstream used a horribly
incomplete scheme for distribution that isn't even ready for launch.

And yet they distribute using it.

I would be questioning why I'm using that upstream's project at all, and
find something better by an author with more clue.

Am I missing something?


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Alan McKinnon]

On 05/11/2017 16:28, Kai Peter wrote:
> 
> 
> On 2017-11-04 18:42, Ian Zimmerman wrote:
> 
>> On 2017-11-04 01:39, Kai Peter wrote:
> 
>>
> 
>>> > If you want to run a monthly job on a host that is not always on, do
> 
>>> > you have to pretend it's an hourly job and check in the script
> 
>>> > itself?
> 
>>>
> 
>>> This is a special case to me. IMHO special cases have to be handled
> 
>>> special or much better: avoid it.
> 
>>
> 
>> Sorry, I don't get this.  How do you avoid this situation?  By not
> 
>> having any monthly jobs?
> 
> No, monthly jobs are fine, but you mentioned a special case as the host
> is may be off at that time. Perhaps you can do: run all jobs which
> didn't run because the host was off at next startup once. fcron has such
> an option. Depending on the exact situation it could require additional
> configuration/checks.


It is not really cron's job to figure out what it thinks the user might
want if the machine was off when the job should have run. That is
expecting far too much intelligence from cron.

Cron is wall-clock time and time based:

When the time is *this*, then do *that*

anacron has some logic for this case of jobs not run but to do it, it
had to give up it's strictly wall-clock time based approach

There are other schedulers out there that succeed where cron fails (eg
Control-M, chronos, quartz), but those are all large, bulky, designed
for big complex installs/requirements and probably not suited for simple
things you'd deploy out of a base in portage

cron is stupid and deliberately so. We really ought to let it remain stupid

> The decision what have to be done MUST be made by the user/sysadmin
> first. Than you can do the config to reach your goal. But that does go
> to far now.

+1 agreed.

I've always maintained that cron cannot possibly know what the scripts
it launches deem to be correct. It's a countdown time and launcher, not
an orchestrator. It can figure out what to do if 2am happens twice (just
don't do it the second time), but not what should happen if 2am was
missed for any reason, including DST or poweroff or overeager ntpdate

The simplest approach to fixing missed jobs is to have the script itself
track what is correct. If it's lock and records files indicate something
didn't happen when it should, the script can do it's own repair or do
it's work twice. Or whatever else is appropriate.


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-04 18:42, Ian Zimmerman wrote:


On 2017-11-04 01:39, Kai Peter wrote:







> If you want to run a monthly job on a host that is not always on, do



> you have to pretend it's an hourly job and check in the script



> itself?







This is a special case to me. IMHO special cases have to be handled



special or much better: avoid it.







Sorry, I don't get this.  How do you avoid this situation?  By not



having any monthly jobs?


No, monthly jobs are fine, but you mentioned a special case as the host 

is may be off at that time. Perhaps you can do: run all jobs which 

didn't run because the host was off at next startup once. fcron has such 

an option. Depending on the exact situation it could require additional 


configuration/checks.



The decision what have to be done MUST be made by the user/sysadmin 

first. Than you can do the config to reach your goal. But that does go 


to far now.



--

Sent with eQmail-1.10

Re: [gentoo-user] [OT] AppImage? What's that?

[tuxic]

On 11/05 07:21, Tom H wrote:
> On Sun, Nov 5, 2017 at 7:11 AM,  wrote:
> > On 11/05 06:29, Tom H wrote:
> >> On Sun, Nov 5, 2017 at 6:20 AM,  wrote:
> >>>
> >>> I got an archive (???) of an Linux application, which
> >>> has the extension "*.AppImage".
> >>>
> >>> What is that?
> >>>
> >>> Is it possible to "unpack" that into something more common?
> >>> How to handle that?
> >>
> >> Does it use this spec?
> >>
> >> https://appimage.org/
> >
> > Dont know...
> > How can I unpack that to look into it?
> 
> From
> https://github.com/AppImage/AppImageKit
> 
> wget 
> "https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage;
> etc...
> 


./appimagetool-x86_64.AppImage appimagetool-x86_64.AppImage TestApp/.
WARNING: appstreamcli is missing, please install it if you want to use 
AppStream metadata
appimagetool-x86_64.AppImage is a file, assuming it is an AppImage and should 
be unpacked
To be implemented

unpacking is not implemented yet.

Re: [gentoo-user] Re: Systemd

[Mick]

On Saturday, 4 November 2017 19:23:40 GMT Rich Freeman wrote:
> On Sat, Nov 4, 2017 at 2:17 PM, Nikos Chantziaras  wrote:
> > On 04/11/17 18:15, siefke_lis...@web.de wrote:
> >> I have a short question to systemd. I would like to ask your experience
> >> in the changeover. Was it easy? Were there problems?
> >> Change or reinstall? What mean the profis here?
> > 
> > I did both. Changed one system to systemd, re-installed one from scratch
> > with systemd.
> > 
> > Both worked. The only problem I have with systemd is that it's unable to
> > reliably restore the ALSA mixer volumes/settings on startup. It fails 50%
> > of the time. Which is very annoying, but not the end of the world.
> 
> Out of curiosity - are you using alsa-state or alsa-restore?
> Apparently alsa provides two different ways of preserving state.  You
> might consider switching them (which is triggered by the existence of
> /etc/alsa/state-daemon.conf - but it might have some other
> requirements which I didn't bother to check on).

I am using alsasound as a boot service, but in openrc - see below.


> I've seen similar issues with iptables-restore.  To be fair those are
> rare and I've also seen issues with that under openrc.

I have the same issue on one of my Gentoo systems, but I use openrc.  It seems 
to me this is occurring some times only, because the system is trying to read 
/usr when it has not yet been fully mounted, but I'm not sure.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] [OT] AppImage? What's that?

[Tom H]

On Sun, Nov 5, 2017 at 7:11 AM,  wrote:
> On 11/05 06:29, Tom H wrote:
>> On Sun, Nov 5, 2017 at 6:20 AM,  wrote:
>>>
>>> I got an archive (???) of an Linux application, which
>>> has the extension "*.AppImage".
>>>
>>> What is that?
>>>
>>> Is it possible to "unpack" that into something more common?
>>> How to handle that?
>>
>> Does it use this spec?
>>
>> https://appimage.org/
>
> Dont know...
> How can I unpack that to look into it?

From
https://github.com/AppImage/AppImageKit

wget 
"https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage;
etc...

Re: [gentoo-user] [OT] AppImage? What's that?

[tuxic]

On 11/05 06:29, Tom H wrote:
> On Sun, Nov 5, 2017 at 6:20 AM,   wrote:
> >
> > I got an archive (???) of an Linux application, which
> > has the extension "*.AppImage".
> >
> > What is that?
> >
> > Is it possible to "unpack" that into something more common?
> > How to handle that?
> 
> Does it use this spec?
> 
> https://appimage.org/
> 

Dont know...
How can I unpack that to look into it?

Cheers
Meino

[gentoo-user] CURA font renderer

[tuxic]

Hi,

Since cura/curaengine (portage) does not compile on my system and is
relatively old I downloaded cura for Linux from www.ultimaker.com.

This runs on my system without the installation of addtional
applications/libraries.

Unfortunately the font rendering screwed up and makes menu entries,
text boxes etc. hard to read.

This is an issue with cure, since the cura blog lists postings of 
cura users, which have these kinds of problems on MacOSX (and nvida
cards).

I also run a nvidia card.

In the cura code the devs have already fixed that by switching the
font renderer (qs vs. native)...but this fix will be published
in cura 3.1 (current version is 3.04).

Something echoed in my brain to have similiar problems which an
application on Linux a long time ago and I fixed that by doing
"something" with the font renderer/font cache or such.

Any idea how to fix this font issue or trying to are very appreciated!
Cheers
Meino

Re: [gentoo-user] [OT] AppImage? What's that?

[Tom H]

On Sun, Nov 5, 2017 at 6:20 AM,   wrote:
>
> I got an archive (???) of an Linux application, which
> has the extension "*.AppImage".
>
> What is that?
>
> Is it possible to "unpack" that into something more common?
> How to handle that?

Does it use this spec?

https://appimage.org/

[gentoo-user] [OT] AppImage? What's that?

[tuxic]

Hi,

I got an archive (???) of an Linux application, which
has the extension "*.AppImage".

What is that?
Is it possible to "unpack" that into something more common?
How to handle that?

Thanks a lot for any help in advance!

Cheers
Meino