Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition
On Monday, 6 November 2017 23:11:44 GMT Rich Freeman wrote: > On Mon, Nov 6, 2017 at 10:45 AM, Ian Zimmerman wrote: > > On 2017-11-05 17:17, Rich Freeman wrote: > >> 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. > > > > What's a service manager? > > Easiest way to explain it is to give examples. Openrc, systemd, > runit, and upstart are all service managers. I'd argue that sysvinit > is also a service manager but nobody really uses it as one unless you > count getty as a service. > > A service manager is a program used to manage the daemons running on a > system. > > Is making cron care about missed jobs service > > management, but running daily/weekly/monthly jobs isn't? > > Cron is generally not considered a service manager though there is > some overlap since it does manage jobs. I wouldn't make any > distinction in this regard to how it handles missed jobs. Those are > just features that a cron implementation can have or lack. > > It is like arguing about whether sh, dash, or bash are shells on the > basis of the features they provide. They're all shells, but at the > same time we can acknowledge that they have different feature sets. Apologies for prolonging this exhaustive and exhausting thread, but what is the Gentoo suggested cron application for a non-24-7 desktop these days? I'm still using sys-process/vixie-cron because I guess that's what was de rigueur at the time I installed this system, although on other desktop PCs I run sys- process/cronie. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition
On Tue, 07 Nov 2017 08:48:22 +, Mick wrote: > Apologies for prolonging this exhaustive and exhausting thread, but > what is the Gentoo suggested cron application for a non-24-7 desktop > these days? I'm still using sys-process/vixie-cron because I guess > that's what was de rigueur at the time I installed this system, > although on other desktop PCs I run sys- process/cronie. According to virtual/cron, cronie RDEPEND="|| ( sys-process/cronie sys-process/vixie-cron sys-process/bcron sys-process/dcron sys-process/fcron sys-process/systemd-cron )" -- Neil Bothwick EASY TO INSTALL = Difficult to install, but instruction manual has pictures. pgp5PRBHlNCKu.pgp Description: OpenPGP digital signature
[gentoo-user] Compilation error mpv / libav
Hi, I got a couple of depending compilation errors... Top of the stack seems to a problem with mpv / libav. From the build.lg: Setting top to : /var/tmp/portage/media-video/mpv-/work/mpv- Setting out to : /var/tmp/portage/media-video/mpv-/work/mpv-/build Checking for waf version in 1.8.4-2.0.0 : ok Checking for program 'cc': x86_64-pc-linux-gnu-gcc Checking for program 'pkg-config': x86_64-pc-linux-gnu-pkg-config Checking for program 'ar': x86_64-pc-linux-gnu-ar Checking for program 'rst2html' : /usr/bin/rst2html.py Checking for program 'rst2man' : /usr/bin/rst2man.py Checking for program 'rst2pdf' : /usr/bin/rst2pdf Checking for program 'windres' : not found Checking for program 'perl' : /usr/bin/perl Checking for 'gcc' (C compiler) : x86_64-pc-linux-gnu-gcc Detected target OS: : os-linux Checking for compiler flags -Werror=implicit-function-declaration : yes Checking for compiler flags -Wno-error=deprecated-declarations: yes Checking for compiler flags -Wno-error=unused-function: yes Checking for compiler flags -Wempty-body : yes Checking for compiler flags -Wdisabled-optimization : yes Checking for compiler flags -Wstrict-prototypes : yes Checking for compiler flags -Wno-format-zero-length : yes Checking for compiler flags -Werror=format-security : yes Checking for compiler flags -Wno-redundant-decls : yes Checking for compiler flags -Wvla : yes Checking for LGPL (version 2.1 or later) build: disabled Checking for GPL (version 2 or later) build : yes Checking for internal audio filter chain : yes Checking for mpv CLI player : yes Checking for shared library : disabled Checking for static library : disabled Checking for static build : disabled Checking for whether to include binary compile time : yes Checking for whether to optimize : disabled Checking for whether to compile-in debugging information : disabled Checking for manpage generation : yes Checking for html manual generation : yes Checking for pdf manual generation: yes Checking for dynamic loader : yes Checking for C plugins: yes Checking for zsh completion : yes Checking for inline assembly (currently without effect) : yes Checking for test suite (using cmocka): disabled Checking for generate a clang compilation database: disabled Checking for compiler support for noexecstack : yes Checking for linker support for --nxcompat --no-seh --dynamicbase : no Checking for -lm : yes Checking for MinGW: os-win32 not found Checking for POSIX environment: yes Checking for Android environment : disabled Checking for development environment : yes Checking for Universal Windows Platform : disabled Checking for win32 desktop APIs : os-win32 not found Checking for internal pthread wrapper for win32 (Vista+) : posix found Checking for POSIX threads: yes Checking for GNU C extensions : yes Checking for stdatomic.h : yes Checking for stdatomic.h support or slow emulation: yes Checking for linking with -lrt: yes Checking for iconv: yes Checking for w32/dos paths: os-win32 not found Checking for termios : yes Checking for shm : yes Checking for nanosleep: yes Checking for spawnp()/kill() POSIX support: yes Checking for spawnp()/kill() Android replacement : posix-spawn-native found Checking for any spawnp()/kill() support : yes Checking for Windows pipe support
Re: [gentoo-user] Compilation error mpv / libav
On Tue, Nov 7, 2017 at 7:01 PM, wrote: > Hi, > > I got a couple of depending compilation errors... > > Top of the stack seems to a problem with mpv / libav. > > From the build.lg: > > Setting top to : > /var/tmp/portage/media-video/mpv-/work/mpv- > Setting out to : > /var/tmp/portage/media-video/mpv-/work/mpv-/build > Checking for waf version in 1.8.4-2.0.0 : ok > Checking for program 'cc': x86_64-pc-linux-gnu-gcc > Checking for program 'pkg-config': x86_64-pc-linux-gnu-pkg-config > Checking for program 'ar': x86_64-pc-linux-gnu-ar > Checking for program 'rst2html' : /usr/bin/rst2html.py > Checking for program 'rst2man' : /usr/bin/rst2man.py > Checking for program 'rst2pdf' : /usr/bin/rst2pdf > Checking for program 'windres' : not found > Checking for program 'perl' : /usr/bin/perl > Checking for 'gcc' (C compiler) : x86_64-pc-linux-gnu-gcc > Detected target OS: : os-linux > Checking for compiler flags -Werror=implicit-function-declaration : yes > Checking for compiler flags -Wno-error=deprecated-declarations: yes > Checking for compiler flags -Wno-error=unused-function: yes > Checking for compiler flags -Wempty-body : yes > Checking for compiler flags -Wdisabled-optimization : yes > Checking for compiler flags -Wstrict-prototypes : yes > Checking for compiler flags -Wno-format-zero-length : yes > Checking for compiler flags -Werror=format-security : yes > Checking for compiler flags -Wno-redundant-decls : yes > Checking for compiler flags -Wvla : yes > Checking for LGPL (version 2.1 or later) build: disabled > Checking for GPL (version 2 or later) build : yes > Checking for internal audio filter chain : yes > Checking for mpv CLI player : yes > Checking for shared library : disabled > Checking for static library : disabled > Checking for static build : disabled > Checking for whether to include binary compile time : yes > Checking for whether to optimize : disabled > Checking for whether to compile-in debugging information : disabled > Checking for manpage generation : yes > Checking for html manual generation : yes > Checking for pdf manual generation: yes > Checking for dynamic loader : yes > Checking for C plugins: yes > Checking for zsh completion : yes > Checking for inline assembly (currently without effect) : yes > Checking for test suite (using cmocka): disabled > Checking for generate a clang compilation database: disabled > Checking for compiler support for noexecstack : yes > Checking for linker support for --nxcompat --no-seh --dynamicbase : no > Checking for -lm : yes > Checking for MinGW: os-win32 > not found > Checking for POSIX environment: yes > Checking for Android environment : disabled > Checking for development environment : yes > Checking for Universal Windows Platform : disabled > Checking for win32 desktop APIs : os-win32 > not found > Checking for internal pthread wrapper for win32 (Vista+) : posix > found > Checking for POSIX threads: yes > Checking for GNU C extensions : yes > Checking for stdatomic.h : yes > Checking for stdatomic.h support or slow emulation: yes > Checking for linking with -lrt: yes > Checking for iconv: yes > Checking for w32/dos paths: os-win32 > not found > Checking for termios : yes > Checking for shm : yes > Checking for nanosleep: yes > Checking for spawnp()/kill() POSIX support: yes > Checking for spawnp()/kill() Android replacement : > posix-spawn-native found > Chec
Re: [gentoo-user] Compilation error mpv / libav
On 11/07 07:38, R0b0t1 wrote: > On Tue, Nov 7, 2017 at 7:01 PM, wrote: > > Hi, > > > > I got a couple of depending compilation errors... > > > > Top of the stack seems to a problem with mpv / libav. > > > > From the build.lg: > > > > Setting top to : > > /var/tmp/portage/media-video/mpv-/work/mpv- > > Setting out to : > > /var/tmp/portage/media-video/mpv-/work/mpv-/build > > Checking for waf version in 1.8.4-2.0.0 : ok > > Checking for program 'cc': x86_64-pc-linux-gnu-gcc > > Checking for program 'pkg-config': x86_64-pc-linux-gnu-pkg-config > > Checking for program 'ar': x86_64-pc-linux-gnu-ar > > Checking for program 'rst2html' : /usr/bin/rst2html.py > > Checking for program 'rst2man' : /usr/bin/rst2man.py > > Checking for program 'rst2pdf' : /usr/bin/rst2pdf > > Checking for program 'windres' : not found > > Checking for program 'perl' : /usr/bin/perl > > Checking for 'gcc' (C compiler) : x86_64-pc-linux-gnu-gcc > > Detected target OS: : os-linux > > Checking for compiler flags -Werror=implicit-function-declaration : yes > > Checking for compiler flags -Wno-error=deprecated-declarations: yes > > Checking for compiler flags -Wno-error=unused-function: yes > > Checking for compiler flags -Wempty-body : yes > > Checking for compiler flags -Wdisabled-optimization : yes > > Checking for compiler flags -Wstrict-prototypes : yes > > Checking for compiler flags -Wno-format-zero-length : yes > > Checking for compiler flags -Werror=format-security : yes > > Checking for compiler flags -Wno-redundant-decls : yes > > Checking for compiler flags -Wvla : yes > > Checking for LGPL (version 2.1 or later) build: disabled > > Checking for GPL (version 2 or later) build : yes > > Checking for internal audio filter chain : yes > > Checking for mpv CLI player : yes > > Checking for shared library : disabled > > Checking for static library : disabled > > Checking for static build : disabled > > Checking for whether to include binary compile time : yes > > Checking for whether to optimize : disabled > > Checking for whether to compile-in debugging information : disabled > > Checking for manpage generation : yes > > Checking for html manual generation : yes > > Checking for pdf manual generation: yes > > Checking for dynamic loader : yes > > Checking for C plugins: yes > > Checking for zsh completion : yes > > Checking for inline assembly (currently without effect) : yes > > Checking for test suite (using cmocka): disabled > > Checking for generate a clang compilation database: disabled > > Checking for compiler support for noexecstack : yes > > Checking for linker support for --nxcompat --no-seh --dynamicbase : no > > Checking for -lm : yes > > Checking for MinGW: > > os-win32 not found > > Checking for POSIX environment: yes > > Checking for Android environment : disabled > > Checking for development environment : yes > > Checking for Universal Windows Platform : disabled > > Checking for win32 desktop APIs : > > os-win32 not found > > Checking for internal pthread wrapper for win32 (Vista+) : posix > > found > > Checking for POSIX threads: yes > > Checking for GNU C extensions : yes > > Checking for stdatomic.h : yes > > Checking for stdatomic.h support or slow emulation: yes > > Checking for linking with -lrt: yes > > Checking for iconv: yes > > Checking for w32/dos paths: > > os-win32 not found > > Checking for termios : yes > > Checking for shm : yes > > Checking for nanosleep
Re: [gentoo-user] Compilation error mpv / libav
On 11/07/2017 05:01 PM, tu...@posteo.de wrote: > Hi, > > I got a couple of depending compilation errors... > > Top of the stack seems to a problem with mpv / libav. > > Is there any known fix for that? > > Thanks a lot for any help in advance! :) I've got mpv- installed. I'm pretty sure you need to move to ffmpeg- as well. Also, libav and ffmpeg are mutually exclusive. You can have one, but not the other.
Re: [gentoo-user] Compilation error mpv / libav
On 11/07 07:21, John Campbell wrote: > On 11/07/2017 05:01 PM, tu...@posteo.de wrote: > > Hi, > > > > I got a couple of depending compilation errors... > > > > Top of the stack seems to a problem with mpv / libav. > > > > Is there any known fix for that? > > > > Thanks a lot for any help in advance! :) > > I've got mpv- installed. I'm pretty sure you need to move to > ffmpeg- as well. > > Also, libav and ffmpeg are mutually exclusive. You can have one, but > not the other. > I installed ffmpeg- and it compiles fines. Everything else failed again (for example mpv-). Why does an update of already ok installed applications break something in parts because the installation has components, which are mutually exclusive? They weren't before (whichout the update everythong was fine...) Cheers Meino
Re: [gentoo-user] Compilation error mpv / libav
> I installed ffmpeg- and it compiles fines. > > Everything else failed again (for example mpv-). > > Why does an update of already ok installed applications > break something in parts because the installation > has components, which are mutually exclusive? > They weren't before (whichout the update everythong was fine...) I've been periodically fighting with mpv and ffmpeg for various reasons for quite some time. Which is why I've been pushed into running live versions of both. Version bumps on ebuilds that fail version checks (like this one) is my first line of defence. The reason live rebuilds keep breaking even though they're installed it the upstream developers change to library requirements and flags without telling anyone. There's a bug report about this at https://bugs.gentoo.org/635650 which seems to offer several solutions and satisfies none... It looks like the decision at present is "wait and hope it gets fixed upstream"
[gentoo-user] Linux USB security holes.
Howdy, I ran up on this link. Is there any truth to it and should any of us Gentooers be worried about it? http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ Isn't Linux supposed to be more secure than this?? Dale :-) :-)
Re: [gentoo-user] Linux USB security holes.
On Wed, Nov 8, 2017 at 4:08 PM, Dale wrote: > Howdy, > > I ran up on this link. Is there any truth to it and should any of us > Gentooers be worried about it? > Its sensible to think of anything that's been assigned a CVE number as real. > > http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ > > Isn't Linux supposed to be more secure than this?? It is what it is.
Re: [gentoo-user] Linux USB security holes.
On Tue, Nov 7, 2017 at 11:08 PM, Dale wrote: > Howdy, > > I ran up on this link. Is there any truth to it and should any of us > Gentooers be worried about it? > > http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ > > Isn't Linux supposed to be more secure than this?? > In theory. There was no comment on the existence of such bugs in the Windows driver stack, but they likely exist. However, note: "The impact is quite limited, all the bugs require physical access to trigger," said Konovalov. "Most of them are denial-of-service, except for a few that might be potentially exploitable to execute code in the kernel." Which is typically what one should expect from bugs discovered by fuzzing. These are issues which should be fixed, but keep in mind that there has been (and still is) lots of kernel development that focuses on isolating the kernel from itself. The reporting of these bugs will likely be used to make those mechanisms even better. To compare, here is an "exploit" discovered in a monitor: https://github.com/RedBalloonShenanigans/MonitorDarkly. The prerequisites include having debug access to the monitor's controller. Personally I am surprised this was presented at DefCon as it does not really seem appropriate. At least the articles covering the code should be reworded - it's exploiting the monitor almost the same way you can exploit a car by driving it. More and more security releases are starting to look like the above, as the researchers and authors clamor for notability, which is increasingly hard to find. I think the article you found strikes a middle ground - the exploits are relevant in practice, but take a lot of work to use. Cheers, R0b0t1
Re: [gentoo-user] Compilation error mpv / libav
On Tue, Nov 7, 2017 at 11:04 PM, John Campbell wrote: > >> I installed ffmpeg- and it compiles fines. >> >> Everything else failed again (for example mpv-). >> >> Why does an update of already ok installed applications >> break something in parts because the installation >> has components, which are mutually exclusive? >> They weren't before (whichout the update everythong was fine...) > > I've been periodically fighting with mpv and ffmpeg for various reasons > for quite some time. Which is why I've been pushed into running live > versions of both. Version bumps on ebuilds that fail version checks > (like this one) is my first line of defence. > > The reason live rebuilds keep breaking even though they're installed it > the upstream developers change to library requirements and flags without > telling anyone. > > There's a bug report about this at https://bugs.gentoo.org/635650 which > seems to offer several solutions and satisfies none... It looks like > the decision at present is "wait and hope it gets fixed upstream" > With Gentoo that is usually the most expedient solution, cost of time considering.
Re: [gentoo-user] Linux USB security holes.
On 8 November 2017 06:08:21 GMT+01:00, Dale wrote: >Howdy, > >I ran up on this link. Is there any truth to it and should any of us >Gentooers be worried about it? > >http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ > >Isn't Linux supposed to be more secure than this?? > >Dale > >:-) :-) From what I read, you need physical access. And I am not certain what you need to do to the firmware on the USB device to trigger this. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Linux USB security holes.
Dale wrote: > Howdy, > > I ran up on this link. Is there any truth to it and should any of us > Gentooers be worried about it? > > http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ > > Isn't Linux supposed to be more secure than this?? > > Dale > > :-) :-) > To reply to all that posted so far. I did see that it requires physical access, like a lot of other things. Once a person has physical access, there are a number of things that can go wrong. It does seem to be one of those things that while possible, has anyone been able to do it in the real world and even without physical access? Odds are, no. Still, all things considered, Linux is pretty secure. BSD is more secure from what I've read but Linux is better than windoze. Dale :-) :-)
Re: [gentoo-user] Linux USB security holes.
On Wed, Nov 8, 2017 at 12:02 AM, Dale wrote: > Dale wrote: >> Howdy, >> >> I ran up on this link. Is there any truth to it and should any of us >> Gentooers be worried about it? >> >> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ >> >> Isn't Linux supposed to be more secure than this?? >> >> Dale >> >> :-) :-) >> > > > To reply to all that posted so far. I did see that it requires physical > access, like a lot of other things. Once a person has physical access, > there are a number of things that can go wrong. > > It does seem to be one of those things that while possible, has anyone > been able to do it in the real world and even without physical access? > Odds are, no. > The most widely publicized example is STUXNET. There are also reports that malicious USB keys with driver-level exploits are sometimes used for industrial espionage. The key point being that in either case, someone is spending a lot of money to research and set up a plausible attack. > Still, all things considered, Linux is pretty secure. BSD is more > secure from what I've read but Linux is better than windoze. > > Dale > > :-) :-) >
Re: [gentoo-user] Linux USB security holes.
On Wed, Nov 8, 2017 at 12:10 AM, R0b0t1 wrote: > On Wed, Nov 8, 2017 at 12:02 AM, Dale wrote: >> Dale wrote: >>> Howdy, >>> >>> I ran up on this link. Is there any truth to it and should any of us >>> Gentooers be worried about it? >>> >>> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ >>> >>> Isn't Linux supposed to be more secure than this?? >>> >>> Dale >>> >>> :-) :-) >>> >> >> >> To reply to all that posted so far. I did see that it requires physical >> access, like a lot of other things. Once a person has physical access, >> there are a number of things that can go wrong. >> >> It does seem to be one of those things that while possible, has anyone >> been able to do it in the real world and even without physical access? >> Odds are, no. >> > > The most widely publicized example is STUXNET. There are also reports > that malicious USB keys with driver-level exploits are sometimes used > for industrial espionage. > > The key point being that in either case, someone is spending a lot of > money to research and set up a plausible attack. > >> Still, all things considered, Linux is pretty secure. BSD is more >> secure from what I've read but Linux is better than windoze. >> >> Dale >> >> :-) :-) >> I suppose I should add that once the basic work has been done for an exploit like this it will have great reproducibility. But at that level you are (usually) talking about very well funded actors, and one should also be worried about controller-level exploits that would be much harder to discover from an operating system. If you can't surround your computer with trustworthy armed guards, assume you suffer from a serious vulnerability based on the preliminary work the article is talking about. Rainbows and Sunshine, R0b0t1
Re: [gentoo-user] Linux USB security holes.
R0b0t1 wrote: > On Wed, Nov 8, 2017 at 12:10 AM, R0b0t1 wrote: >> On Wed, Nov 8, 2017 at 12:02 AM, Dale wrote: >>> Dale wrote: Howdy, I ran up on this link. Is there any truth to it and should any of us Gentooers be worried about it? http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/ Isn't Linux supposed to be more secure than this?? Dale :-) :-) >>> >>> To reply to all that posted so far. I did see that it requires physical >>> access, like a lot of other things. Once a person has physical access, >>> there are a number of things that can go wrong. >>> >>> It does seem to be one of those things that while possible, has anyone >>> been able to do it in the real world and even without physical access? >>> Odds are, no. >>> >> The most widely publicized example is STUXNET. There are also reports >> that malicious USB keys with driver-level exploits are sometimes used >> for industrial espionage. >> >> The key point being that in either case, someone is spending a lot of >> money to research and set up a plausible attack. >> >>> Still, all things considered, Linux is pretty secure. BSD is more >>> secure from what I've read but Linux is better than windoze. >>> >>> Dale >>> >>> :-) :-) >>> > I suppose I should add that once the basic work has been done for an > exploit like this it will have great reproducibility. But at that > level you are (usually) talking about very well funded actors, and one > should also be worried about controller-level exploits that would be > much harder to discover from an operating system. > > If you can't surround your computer with trustworthy armed guards, > assume you suffer from a serious vulnerability based on the > preliminary work the article is talking about. > > Rainbows and Sunshine, > R0b0t1 > > I've considered encrypting my stuff. I'm talking locked down from power up all the way through. Those who have been on this list a while and know me, they know that would be a disaster. If anything could go wrong with it, it would. While I try to be secure, I'm not going nuts over it. I do lock my screen if I leave and sometimes even logout but I don't put hand grenades and other booby traps around it. Heck, if I did, I'd likely trip up and hurt myself. Ooops!! I guess I'll just kept my top secret stuff in my head. ;-) Dale :-) :-)
[gentoo-user] Re: Compilation error mpv / libav
On 08/11/17 05:51, tu...@posteo.de wrote: I installed ffmpeg- and it compiles fines. Everything else failed again (for example mpv-). Why does an update of already ok installed applications break something in parts because the installation has components, which are mutually exclusive? They weren't before (whichout the update everythong was fine...) With mpv, I'd recommend using their own build system if you want the current git version of mpv. It compiles ffmpeg too and uses it privately, which frees you from the burden of having to emerge ffmpeg- and break other packages that rely on ffmpeg. If the mpv ebuild has a "bundled-ffmpeg' USE flag, we would be fine. But since it doesn't, it's recommended to not use Gentoo's mpv ebuild and instead build it manually. Fortunately, mpv's build script is easy to use. You just run it from time to time and it will get you a build from latest git using latest ffmpeg.
