[DONE] pepperflash-plugin-adobe-nonfree

Head_on_a_Stick · 2016-09-05 06:31:58

"Type=oneshot" is the default if none is specified so that may indeed be the right option.

johnraff wrote:

What do you think of Nice=5 BTW?

I don't know enough about nice(1p) to comment, sorry.

barnabyh · 2016-09-12 21:22:22

Nice idea. If it was still using cron instead of systemd timers it would also work on systems with other init sequences. However, I understand this is written for Bunsen and Bunsen is using systemd, staying close to Debian for the base.

Fair enough.

I have to admit, the journalctl feature is pretty neat to check whether the package updated, if it works as intended.

Last edited by barnabyh (2016-09-12 21:25:43)

Head_on_a_Stick · 2016-09-12 21:28:55

barnabyh wrote:

If it was still using cron instead of systemd timers it would also work on systems with other init sequences.

This is a consideration, adoption of this scheme would appear to drop the init-agnosticism of the upstream Debian release.

Related: Adobe have officially announced the resumption of NPAPI updates for GNU/Linux systems so PPAPI is no longer needed for full Flash support.

https://blogs.adobe.com/flashplayer/201 … 51yFW.dpbs

EDIT: PPAPI is still needed for 3D rendering with the GPU and playback of DRM-restricted content.

Last edited by Head_on_a_Stick (2016-09-12 21:43:42)

Bearded_Blunder · 2016-09-12 23:50:38

barnabyh wrote:

Nice idea. If it was still using cron instead of systemd timers it would also work on systems with other init sequences. However, I understand this is written for Bunsen and Bunsen is using systemd, staying close to Debian for the base.

Debian work hard to make switching to sysv init doable and supported, I have in the past done so with bunsen, with no significant detrimental consequences. I'm hoping that the bunsen devs don't cause such switches to break bunsen in the future :-)
Though to be fair, I'm trying to learn to deal with systemd, in spite of my distaste for what I considered a needless switch upstream presenting me with a whole new thing to learn from scratch, just as I was starting to get a handle on the old init system.

johnraff · 2016-09-14 08:58:34

1) This isn't a core part of BL, it's a utility to download the Adobe PPAPI flash player for i386 systems only. (i686 systems have pepperflashplugin-nonfree.)

2) The systemd timer for automatic upgrade checks will not be a core part of the package. (pepperflashplugin-nonfree has no such function - upgrades have to be run by hand or triggered by a package version upgrade.) The basic script will be coded so as not to exit with error even if the systemctl executable is unavailable, so it will work like pepperflashplugin-nonfree on init.d systems. I don't think providing some function enhancement that only works with systemd can fairly be considered "breaking BL's init-agnosticism". (The BL system out of the box already contains other systemd services and timers of course.)

3) Dropping a systemd timer here and switching to a cron job is not absolutely out of the question, if the advantages of doing so were considered to outweigh the disadvantages...

barnabyh · 2016-09-14 21:32:39

^Thanks johnraff. That makes it all a lot clearer. Sounds good. I particularly like the bit about exiting without error. The able can then set up a cron job themselves should they wish automatic update.

Bearded_Blunder · 2016-09-14 22:26:31

It's of passing interest to me, given i386 is what I mostly use, and perforce have to on my laptop, that said, I'm fairly indifferent about auto update checking on that, it gets used infrequently enough that updating is pretty routinely my first post-login task. The other installs (again often i386) tend to run server type roles mostly (so far) and as such flash is pretty much irrelevant, the big bloated browsers tend to be "apt-ungot"(tm) and replaced with netsurf for the rare occasions a browser is needed on them, typically the browser and entire system gets updated more often than the browser gets used. Flash plugins just don't get/remain installed in any event except on the laptop.

johnraff · 2016-09-15 03:43:48

Head_on_a_Stick wrote:

May I ask why "Type=oneshot" was deemed preferable?

I've been searching all over for a way to make persistent OnCalendar timer events, that are doing a "catchup" elapse because the computer was down at the set time, fire off at a certain time after bootup, but it looks increasingly likely to be impossible(*), at least until we get a version of systemd that supports RandomizedDelaySec($). Persistent "catchup" elapses are always run immediately after boot at the moment. (In this case it's not such a big deal, fortunately.)

Today, searching to see if AccuracySec might help, I ran into this post in the Debian Forums, July 25th, by a certain Head_on_a_Stick, which uses, along with "AccuracySec=1h", "Type=oneshot"...

(*) While AccuracySec doesn't seem to help at all with "catchup" elapses, a different approach is to make a monotonic timer with eg "OnBootSec=20min" and "OnUnitActiveSec=1d". That gets the event 20m away from bootup, then runs it every day thereafter. The disadvantage is that the event will be run again 20min after every bootup, even if there are several in the same day.

($) RandomizedDelaySec doesn't seem to help either: https://bugzilla.redhat.com/show_bug.cgi?id=1282232#c31
I'm going to try adding a sleep command with ExecStartPre in the service file.

Last edited by johnraff (2016-09-15 03:55:54)

Head_on_a_Stick · 2016-09-15 06:29:05

this post in the Debian Forums

I forgot about that...

johnraff · 2016-09-20 07:29:34

This small side-project (PepperFlash for 32bit systems of all things!) has been taking too much time lately, but I think it's nearing a conclusion...

As far as I can tell, there's no way to get a systemd timer to delay it's execution when it's being triggered by a boot-up later than its configured elapse time, due to the persistence flag. There seem to be some tweaks available on the official time, but all overdue timers with persistence seem to be executed together, just after boot.

But, a reasonable workaround seems to be to add some sleep to the service file, not the timer, in the form of an ExecStartPre entry calling /bin/sleep. The actual ExecStart command won't be run till that has completed. In this case, if we set a sleep of 600 then the flash update script won't be run for 10 min after the timer goes off. That seems like a reasonable compromise, no?

Putting the sleep in the service file instead of in the script itself means that the upgrade can still still be done manually from a terminal with no delay.

I'm still thinking about exactly how the .deb package maintainer scripts should be organized so that a script upgrade is triggered by a package upgrade. I think it'll be OK though.

johnraff · 2016-09-21 06:14:46

Forgot to post the code that seems to be working OK.
pepperflash-adobe.timer (unchanged from HoaS's post):

[Unit]
Description=Run pepperflash upgrade check daily.

[Timer]
OnCalendar=daily
Persistent=true 

[Install]
WantedBy=timers.target

pepperflash-adobe.service:

[Unit]
Description=Check Adobe for pepperflash upgrade.
OnFailure=notify-failure@The\x20Adobe\x20Flash\x20update\x20script\x20returned\x20an\x20error.\x0aRun\x20\x27sudo\x20journalctl\x20\x2du\x20pepperflash\x2dadobe\x27\x20for\x20details..service

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 600
ExecStart=/usr/bin/update-pepperflashplugin-adobe-nonfree --upgrade
Nice=5

notify-failure@.service

[Unit]
Description=Send failure notification

[Service]
Type=oneshot
ExecStart=/usr/bin/notify-broadcast "Service Failed" "%I" --icon=dialog-error --expire-time=30000

(notify-broadcast described elsewhere.)

Head_on_a_Stick · 2016-09-21 06:39:53

Good work John, I have "stolen" your ExecStartPre line and added it to my fdn guide

johnraff · 2016-09-26 07:06:24

The latest .deb package has been pushed to GitHub: https://github.com/johnraff/pepperflash … be-nonfree
(same url as before)

EDIT: sorry, I forgot, that's the source code, which would have to be built.
Here's a compiled .deb for i386 people:
https://www.dropbox.com/s/6y8oc3ev0dacz … 1_i386.deb

If any i386 users fell like trying it out, bug reports are welcome!

@HoaS (or other systemd users) I ran into a tricky point doing the systemd packaging there. When installing, the process just hung (gdebi or dpkg). Fruitless hours of Googling later I finally realized that it was the 10 min sleep in pepperflash-adobe.service!
If you use dh_systemd for the package build (as recommended) then all service files are started on install by default - even Type=oneshot, and even those with no WantedBy or any [Install] section at all.

If you ever end up trying to package a service file with an ExecStartPre sleep you'll want to stop it from being started at install, or else dpkg will hang until the sleep is over and the ExecStart command has run. More (and more) Googling later, this was found to work in debian/rules:

# main packaging script based on dh7 syntax
%:
	dh $@ --with systemd

# debmake generated override targets
override_dh_systemd_start:
	dh_systemd_start pepperflash-adobe.timer

The override causes the unwanted pepperflash-adobe.service to be left out of the auto-generated start command in DEBIAN/postinst.

@all The dh_systemd build causes the systemd setup commands to be run in a way that does not break non-systemd systems. The systemd timer will simply not work, but the packaged script will run on install, can be run manually, and will also be triggered by a package upgrade.

Last edited by johnraff (2016-09-26 08:04:50)

johnraff · 2016-10-24 06:04:16

This package has now been uploaded to the BunsenLabs repositories as bunsen-pepperflash

#21 2016-09-05 06:31:58

Re: [DONE] pepperflash-plugin-adobe-nonfree

#22 2016-09-12 21:22:22

Re: [DONE] pepperflash-plugin-adobe-nonfree

#23 2016-09-12 21:28:55

Re: [DONE] pepperflash-plugin-adobe-nonfree

#24 2016-09-12 23:50:38

Re: [DONE] pepperflash-plugin-adobe-nonfree

#25 2016-09-14 08:58:34

Re: [DONE] pepperflash-plugin-adobe-nonfree

#26 2016-09-14 21:32:39

Re: [DONE] pepperflash-plugin-adobe-nonfree

#27 2016-09-14 22:26:31

Re: [DONE] pepperflash-plugin-adobe-nonfree

#28 2016-09-15 03:43:48

Re: [DONE] pepperflash-plugin-adobe-nonfree

#29 2016-09-15 06:29:05

Re: [DONE] pepperflash-plugin-adobe-nonfree

#30 2016-09-20 07:29:34

Re: [DONE] pepperflash-plugin-adobe-nonfree

#31 2016-09-21 06:14:46

Re: [DONE] pepperflash-plugin-adobe-nonfree

#32 2016-09-21 06:39:53

Re: [DONE] pepperflash-plugin-adobe-nonfree

#33 2016-09-26 07:06:24

Re: [DONE] pepperflash-plugin-adobe-nonfree

#34 2016-10-24 06:04:16

Re: [DONE] pepperflash-plugin-adobe-nonfree

Board footer