Re: [gentoo-user] Snort compiling problems
On Sunday, August 23, 2015 3:26:24 PM Rod wrote: On 08/23/2015 08:59 AM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 8:27:17 AM Rod wrote: Snipped out the previous, takes a while to scroll... On 08/23/2015 07:40 AM, Fernando Rodriguez wrote: Post the output of: emerge -vap snort and then: USE=normalizer emerge -vap snort The only way NormFlags is left out (as far as I can see) is if you disable that flag (which is enabled by default). # emerge -pqv '=net-analyzer/snort-2.9.7.5::gentoo' [ebuild U ] net-analyzer/snort-2.9.7.5 [2.9.1] USE=threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -normalizer -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) Ahhh, ok, I see it, -normalizer Maybe on newer install systems its enabled by default, but I have been running this system with Snort on it for 10 years or so... and I don't think normalizer would be that old in theUSE flags, opening `ufed` it doesn't show it as included or enabled, I have enabled it. # USE=normalizer emerge -vap snort [ebuild U ~] net-analyzer/snort-2.9.7.5::gentoo [2.9.1::gentoo] USE=normalizer* threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) 0 KiB No luck I'm afraid grep your package.* in /etc/portage for snort entries. I didn't investigate which one is breaking this time but it must be something you got there somewhere. I just built it with the default use flags and it works. If it was profile changes you would've got them when you sync'd. And don't forget to file a bug. net-analyzer/snort ~amd64 # required by net-analyzer/snort-2.9.6.1 # required by @selected # required by @world (argument) =net-libs/daq-2.0.2 ~amd64 When was the last time you sync'd? And did a world update? Your portage is two versions behind mine... This *should* work: USE=active-response flexresp3 gre mpls non-ether-decoders normalizer perfprofiling ppm react targetbased threads emerge snort Hopefully somebody else can help figure out why those use flags are disabled, they're enabled in my ebuild. For now add those flags to your package.use. -- Fernando Rodriguez
[gentoo-user] Re: 69.99 != 69.99
On 2015-08-22, Alan McKinnon alan.mckin...@gmail.com wrote: [regarding floating point comparison.] A good way to demonstrate just how problematic floats can be is to point out that floats are banned in the linux kernel for exactly this reason. Integers only. Really? The reason that I was given when I wanted to use FP in a kernel module is that handing context switching for FP hardware is much simpler/faster if you assume no FP operations in the kernel. Nobody ever mentioned the comparison problem or other typical FP computation stumbles -- the decision was supposedly based on the complications of handing FP hardware context switches. -- Grant
[gentoo-user] python problem trying to emerge systemd-cron
Trying to emerge systemd-cron results in the following error !!! Problem resolving dependencies for sys-process/systemd-cron ... done! !!! The ebuild selected to satisfy systemd-cron has unmet requirements. - sys-process/systemd-cron-1.5.3::gentoo USE=-cron-boot -etc-crontab-systemd -minutely -setgid -yearly ABI_X86=64 PYTHON_SINGLE_TARGET=-pypy3 -python3_3 -python3_4 PYTHON_TARGETS=python3_4 -pypy3 -python3_3 The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_pypy3 python_single_target_python3_3 python_single_target_python3_4 ) The above constraints are a subset of the following complete expression: exactly-one-of ( python_single_target_pypy3 python_single_target_python3_3 python_single_target_python3_4 ) python_single_target_pypy3? ( python_targets_pypy3 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 ) - I do not have python_targets set explicitly, but have used eselect right now eselect python list gives Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * and eselect python list --python3 naturally gives Available Python 3 interpreters: [1] python3.3 [2] python3.4 * I have sync'ed and emerge -uDv --changed-use @world shows nothing What should I do? thanks, allan
Re: [gentoo-user] python problem trying to emerge systemd-cron
Am Sun, 23 Aug 2015 15:50:28 -0400 schrieb allan gottlieb gottl...@nyu.edu: Trying to emerge systemd-cron results in the following error !!! Problem resolving dependencies for sys-process/systemd-cron ... done! !!! The ebuild selected to satisfy systemd-cron has unmet requirements. - sys-process/systemd-cron-1.5.3::gentoo USE=-cron-boot -etc-crontab-systemd -minutely -setgid -yearly ABI_X86=64 PYTHON_SINGLE_TARGET=-pypy3 -python3_3 -python3_4 PYTHON_TARGETS=python3_4 -pypy3 -python3_3 The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_pypy3 python_single_target_python3_3 python_single_target_python3_4 ) The above constraints are a subset of the following complete expression: exactly-one-of ( python_single_target_pypy3 python_single_target_python3_3 python_single_target_python3_4 ) python_single_target_pypy3? ( python_targets_pypy3 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 ) - I do not have python_targets set explicitly, but have used eselect right now eselect python list gives Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * and eselect python list --python3 naturally gives Available Python 3 interpreters: [1] python3.3 [2] python3.4 * I have sync'ed and emerge -uDv --changed-use @world shows nothing What should I do? thanks, allan The default value of PYTHON_SINGLE_TARGET is python2_7 (it's set in /usr/portage/profiles/base/make.defaults), so you must change it for this package. I use the following package.use entry: sys-process/systemd-cron python_single_target_python3_4 HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgprLzWT8Ecof.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Snort compiling problems
On 08/23/2015 03:59 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 3:26:24 PM Rod wrote: On 08/23/2015 08:59 AM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 8:27:17 AM Rod wrote: Snipped out the previous, takes a while to scroll... On 08/23/2015 07:40 AM, Fernando Rodriguez wrote: Post the output of: emerge -vap snort and then: USE=normalizer emerge -vap snort The only way NormFlags is left out (as far as I can see) is if you disable that flag (which is enabled by default). # emerge -pqv '=net-analyzer/snort-2.9.7.5::gentoo' [ebuild U ] net-analyzer/snort-2.9.7.5 [2.9.1] USE=threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -normalizer -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) Ahhh, ok, I see it, -normalizer Maybe on newer install systems its enabled by default, but I have been running this system with Snort on it for 10 years or so... and I don't think normalizer would be that old in theUSE flags, opening `ufed` it doesn't show it as included or enabled, I have enabled it. # USE=normalizer emerge -vap snort [ebuild U ~] net-analyzer/snort-2.9.7.5::gentoo [2.9.1::gentoo] USE=normalizer* threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) 0 KiB No luck I'm afraid grep your package.* in /etc/portage for snort entries. I didn't investigate which one is breaking this time but it must be something you got there somewhere. I just built it with the default use flags and it works. If it was profile changes you would've got them when you sync'd. And don't forget to file a bug. net-analyzer/snort ~amd64 # required by net-analyzer/snort-2.9.6.1 # required by @selected # required by @world (argument) =net-libs/daq-2.0.2 ~amd64 When was the last time you sync'd? And did a world update? Your portage is two versions behind mine... This *should* work: USE=active-response flexresp3 gre mpls non-ether-decoders normalizer perfprofiling ppm react targetbased threads emerge snort Hopefully somebody else can help figure out why those use flags are disabled, they're enabled in my ebuild. For now add those flags to your package.use. emerge sync is every night (once every 24Hrs) and the portage directory is NFS shared to all other computers on this home network, Bug has been filed to here - https://bugs.gentoo.org/show_bug.cgi?id=558454 Ok, thats a bugger. Grrr (now) I have added your USE (above) to package.use, recompiled, nothing changed, still bombed at Stream 6 then tried without changing anything, your USE=active...threads emerge snort and it happily compiled, and installed :( now I don't know why... I submitted the bug report (previous Email request) then typed this Email as I was trying what you requested, and now G... -- --- Regards, Rod Smart 0417 513 286
Re: [gentoo-user] Snort compiling problems
On Sunday, August 23, 2015 4:35:12 PM Rod wrote: On 08/23/2015 03:59 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 3:26:24 PM Rod wrote: On 08/23/2015 08:59 AM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 8:27:17 AM Rod wrote: Snipped out the previous, takes a while to scroll... On 08/23/2015 07:40 AM, Fernando Rodriguez wrote: Post the output of: emerge -vap snort and then: USE=normalizer emerge -vap snort The only way NormFlags is left out (as far as I can see) is if you disable that flag (which is enabled by default). # emerge -pqv '=net-analyzer/snort-2.9.7.5::gentoo' [ebuild U ] net-analyzer/snort-2.9.7.5 [2.9.1] USE=threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -normalizer -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) Ahhh, ok, I see it, -normalizer Maybe on newer install systems its enabled by default, but I have been running this system with Snort on it for 10 years or so... and I don't think normalizer would be that old in theUSE flags, opening `ufed` it doesn't show it as included or enabled, I have enabled it. # USE=normalizer emerge -vap snort [ebuild U ~] net-analyzer/snort-2.9.7.5::gentoo [2.9.1::gentoo] USE=normalizer* threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) 0 KiB No luck I'm afraid grep your package.* in /etc/portage for snort entries. I didn't investigate which one is breaking this time but it must be something you got there somewhere. I just built it with the default use flags and it works. If it was profile changes you would've got them when you sync'd. And don't forget to file a bug. net-analyzer/snort ~amd64 # required by net-analyzer/snort-2.9.6.1 # required by @selected # required by @world (argument) =net-libs/daq-2.0.2 ~amd64 When was the last time you sync'd? And did a world update? Your portage is two versions behind mine... This *should* work: USE=active-response flexresp3 gre mpls non-ether-decoders normalizer perfprofiling ppm react targetbased threads emerge snort Hopefully somebody else can help figure out why those use flags are disabled, they're enabled in my ebuild. For now add those flags to your package.use. emerge sync is every night (once every 24Hrs) and the portage directory is NFS shared to all other computers on this home network, Bug has been filed to here - https://bugs.gentoo.org/show_bug.cgi?id=558454 Ok, thats a bugger. Grrr (now) I have added your USE (above) to package.use, recompiled, nothing changed, still bombed at Stream 6 then tried without changing anything, your USE=active...threads emerge snort and it happily compiled, and installed :( now I don't know why... I submitted the bug report (previous Email request) then typed this Email as I was trying what you requested, and now G... That is strange. All I can say is upgrade portage try again to see if it picks up the use flags correctly. And don't do a world update until you sort it out cause if it's not picking your use flags it may make it worst. -- Fernando Rodriguez
Re: [gentoo-user] Snort compiling problems
On Sunday, August 23, 2015 5:17:53 PM Rod wrote: On 08/23/2015 05:02 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 4:35:12 PM Rod wrote: On 08/23/2015 03:59 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 3:26:24 PM Rod wrote: On 08/23/2015 08:59 AM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 8:27:17 AM Rod wrote: Snipped out the previous, takes a while to scroll... On 08/23/2015 07:40 AM, Fernando Rodriguez wrote: Post the output of: emerge -vap snort and then: USE=normalizer emerge -vap snort The only way NormFlags is left out (as far as I can see) is if you disable that flag (which is enabled by default). # emerge -pqv '=net-analyzer/snort-2.9.7.5::gentoo' [ebuild U ] net-analyzer/snort-2.9.7.5 [2.9.1] USE=threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -normalizer -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (- odbc%*) (-paf%) (-postgres%*) (-zlib%*) Ahhh, ok, I see it, -normalizer Maybe on newer install systems its enabled by default, but I have been running this system with Snort on it for 10 years or so... and I don't think normalizer would be that old in theUSE flags, opening `ufed` it doesn't show it as included or enabled, I have enabled it. # USE=normalizer emerge -vap snort [ebuild U ~] net-analyzer/snort-2.9.7.5::gentoo [2.9.1::gentoo] USE=normalizer* threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init- failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (- aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (- odbc%*) (-paf%) (-postgres%*) (-zlib%*) 0 KiB No luck I'm afraid grep your package.* in /etc/portage for snort entries. I didn't investigate which one is breaking this time but it must be something you got there somewhere. I just built it with the default use flags and it works. If it was profile changes you would've got them when you sync'd. And don't forget to file a bug. net-analyzer/snort ~amd64 # required by net-analyzer/snort-2.9.6.1 # required by @selected # required by @world (argument) =net-libs/daq-2.0.2 ~amd64 When was the last time you sync'd? And did a world update? Your portage is two versions behind mine... This *should* work: USE=active-response flexresp3 gre mpls non-ether-decoders normalizer perfprofiling ppm react targetbased threads emerge snort Hopefully somebody else can help figure out why those use flags are disabled, they're enabled in my ebuild. For now add those flags to your package.use. emerge sync is every night (once every 24Hrs) and the portage directory is NFS shared to all other computers on this home network, Bug has been filed to here - https://bugs.gentoo.org/show_bug.cgi?id=558454 Ok, thats a bugger. Grrr (now) I have added your USE (above) to package.use, recompiled, nothing changed, still bombed at Stream 6 then tried without changing anything, your USE=active...threads emerge snort and it happily compiled, and installed :( now I don't know why... I submitted the bug report (previous Email request) then typed this Email as I was trying what you requested, and now G... That is strange. All I can say is upgrade portage try again to see if it picks up the use flags correctly. And don't do a world update until you sort it out cause if it's not picking your use flags it may make it worst. I added the USE flags to package.use, upgraded portage, then tried emerge snort, nothing, then tried it your way USE=. emerge snort, and it worked, sorry I didn't add previous Email that I updated portage By any change you do have USE=-* ... on your make.conf? If so you must have made a typo or something wrong when you added the flags to package.use -- Fernando Rodriguez
Re: [gentoo-user] Snort compiling problems
On 08/23/2015 05:02 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 4:35:12 PM Rod wrote: On 08/23/2015 03:59 PM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 3:26:24 PM Rod wrote: On 08/23/2015 08:59 AM, Fernando Rodriguez wrote: On Sunday, August 23, 2015 8:27:17 AM Rod wrote: Snipped out the previous, takes a while to scroll... On 08/23/2015 07:40 AM, Fernando Rodriguez wrote: Post the output of: emerge -vap snort and then: USE=normalizer emerge -vap snort The only way NormFlags is left out (as far as I can see) is if you disable that flag (which is enabled by default). # emerge -pqv '=net-analyzer/snort-2.9.7.5::gentoo' [ebuild U ] net-analyzer/snort-2.9.7.5 [2.9.1] USE=threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -normalizer -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) Ahhh, ok, I see it, -normalizer Maybe on newer install systems its enabled by default, but I have been running this system with Snort on it for 10 years or so... and I don't think normalizer would be that old in theUSE flags, opening `ufed` it doesn't show it as included or enabled, I have enabled it. # USE=normalizer emerge -vap snort [ebuild U ~] net-analyzer/snort-2.9.7.5::gentoo [2.9.1::gentoo] USE=normalizer* threads -active-response -control-socket% -debug -file-inspect% -flexresp3 -gre -high-availability% -inline-init-failopen -large-pcap-64bit -linux-smp-stats -mpls -non-ether-decoders% -perfprofiling -ppm -react -reload-error-restart (-selinux*) -shared-rep% -side-channel% -sourcefire% -static -targetbased (-aruba%) (-decoder-preprocessor-rules%) (-dynamicplugin%*) (-mysql%*) (-odbc%*) (-paf%) (-postgres%*) (-zlib%*) 0 KiB No luck I'm afraid grep your package.* in /etc/portage for snort entries. I didn't investigate which one is breaking this time but it must be something you got there somewhere. I just built it with the default use flags and it works. If it was profile changes you would've got them when you sync'd. And don't forget to file a bug. net-analyzer/snort ~amd64 # required by net-analyzer/snort-2.9.6.1 # required by @selected # required by @world (argument) =net-libs/daq-2.0.2 ~amd64 When was the last time you sync'd? And did a world update? Your portage is two versions behind mine... This *should* work: USE=active-response flexresp3 gre mpls non-ether-decoders normalizer perfprofiling ppm react targetbased threads emerge snort Hopefully somebody else can help figure out why those use flags are disabled, they're enabled in my ebuild. For now add those flags to your package.use. emerge sync is every night (once every 24Hrs) and the portage directory is NFS shared to all other computers on this home network, Bug has been filed to here - https://bugs.gentoo.org/show_bug.cgi?id=558454 Ok, thats a bugger. Grrr (now) I have added your USE (above) to package.use, recompiled, nothing changed, still bombed at Stream 6 then tried without changing anything, your USE=active...threads emerge snort and it happily compiled, and installed :( now I don't know why... I submitted the bug report (previous Email request) then typed this Email as I was trying what you requested, and now G... That is strange. All I can say is upgrade portage try again to see if it picks up the use flags correctly. And don't do a world update until you sort it out cause if it's not picking your use flags it may make it worst. I added the USE flags to package.use, upgraded portage, then tried emerge snort, nothing, then tried it your way USE=. emerge snort, and it worked, sorry I didn't add previous Email that I updated portage -- --- Regards, Rod Smart 0417 513 286
Re: [gentoo-user] using systemd timers as a cron replacement
Am Sat, 22 Aug 2015 22:56:47 -0400 schrieb Fernando Rodriguez frodriguez.develo...@outlook.com: On Saturday, August 22, 2015 10:17:04 PM allan gottlieb wrote: On Sat, Aug 22 2015, Marc Joliet wrote: Am Sat, 22 Aug 2015 17:15:38 -0400 schrieb Fernando Rodriguez frodriguez.develo...@outlook.com: On Saturday, August 22, 2015 4:52:47 PM allan gottlieb wrote: I use systemd and wish to employ timers an analogue of cron.daily. The system is a laptop that is normally turned off each evening. As I read the manuals one can have either a monotone or a realtime timer. But I seem to need features of each. Specifically, I would like the daily timer to trigger 10 minutes (say) after boot (OnBootSec=600) but not more than once a day (OnCalendar=daily). The manual and several wiki pages suggest that you can't mix monotone and realtime options. Am I misreading the manual (and mixing is permitted) or is there a way to achieve my goals with just monotone or just realtime options. I think so, this is what systemd.timer(5) says: Multiple directives may be combined of the same and of different types. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible to define a timer that elapses in regular intervals and activates a specific service each time. There's also sys-process/systemd-cron that works like a regular cron and seems to work fine for me but I haven't tested it depth. Right, I have one timer that, for example, uses: [Timer] OnBootSec=10m OnUnitInactiveSec=1h Those are both monotone options so definitely can be combined. I want daily so would have [Timer] OnBootSec=10 minutes OnUnitInactiveSec=1d However If I boot the machine at 9am, turn it off at 10am, and boot again at 11am, won't the timer fire twice? I thought for monotone timers the time starts anew a the next boot? thanks, allan Sorry I'm not sure, it says the semantics are the same so I assume that means they can be mixed but I'm unclear if they run twice in that case. I guess you can just set it to a short interval, wait for it to run, then reboot and see what happens (and let us know the result :). I'm curious about it, too. If you use OnCalendar with Persistent=true it should run no more than once a day though, but it'll run right away on boot if you miss it one day. The persistent daily timers I have *will* run twice on one day if you missed one or more deadlines. They will run once for all the missed deadlines, then continue on the next deadline as usual. I don't use the daily keyword, but that is equivalent to *-*-* 00:00:00, whereas my timers are *-*-* 23:00, so I expect daily to behave the same. If you just want to replace cron my advice is install systemd-cron, it has the advantage that it'll satisfy any dependencies on cron. If you don't want to install it you can still download it and see how they did it. I agree, I switched to it pretty much the instant it was in the portage tree. However, I don't have any self-defined cron jobs, only those installed by packages into /etc/cron.daily/. I use timer units directly for my own repeating jobs. -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpiNr6OX5fEb.pgp Description: Digitale Signatur von OpenPGP
[gentoo-user] kde-frameworks 5
KDE 5 is in the tree, it's called KDE Frameworks 5. A quick heads-up to anyone who runs into what I just had. It all started with this incompatible USE error: emerge: there are no ebuilds built with USE flags to satisfy sys-auth/polkit-qt[qt5]. !!! One of the following packages is required to complete your request: - sys-auth/polkit-qt-0.112.0-r1::gentoo (Change USE: +qt5) (dependency required by kde-frameworks/kauth-5.13.0::gentoo[policykit] [ebuild]) (dependency required by kde-frameworks/kdelibs4support-5.13.0::gentoo [ebuild]) (dependency required by kde-apps/kmix-15.08.0::gentoo [ebuild]) (dependency required by kde-apps/kdemultimedia-meta-15.08.0::gentoo [ebuild]) And that led into a long change of adding USE=qt5 to several packages, followed by portage's decision to upgrade to KDE 5, which I've decided to postpone for a bit. Most KDE5 packages are in a new category or renamed, but some -meta package names are re-used like this one: $ eix kdemultimedia-meta [U] kde-apps/kdemultimedia-meta Available versions: (4)4.14.3 (5)(~)15.08.0 which portage obviously wants to upgrade, and cascades into a full KDE5 upgrade. To prevent this and stick with KDE 4 meanwhile, just specify the :4 slot for your kde packages in set files or in world, like so: kde-apps/kdemultimedia-meta:4 In my case I only had to do it for the -meta packages and all was good. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] using systemd timers as a cron replacement
Thank you marc and fernando (fernando, I think your replies go only to marc and not to the group). So it seems the conclusion is timers can't achieve both 1. Run only once a day even if you boot often. 2. Not starting for at least 10 minutes after boot I realize that you can achieve 2 outside the timer by having services fired by the timer begin with a 10 minute delay. However, I thought timers were supposed to achieve 1 2, since that is what I believe you get with vixie-cron + anacron. Also, since systemd.cron is based on timers, I would think it would have the same problem we are discussing. allan
Re: [gentoo-user] Filthy oscilloscope picture! =P
Mick wrote: PS. Noisy PSUs are nothing new. The noise is can be caused by the capacitors, or the coils. Although annoying it does not necessarily mean that there is an electrical problem with the components. If the fan is rattling, then a drop of oil on its bearing should soon put a stop to this. As Dale mentioned, a stalled fan will not help the longevity of the remaining components. :-) This is true, they do sometimes make noise. What got my attention is that it stopped. Usually if one makes noise, it will make it for the remainder of its life cycle unless something changes, such has adding additional load which may change a frequency. If nothing changes and it stops making that noise, then it likely stopped working as well. I've seen capacitors go bad and it not blow anything else out or stop the rest of the circuit from working. It all depends on how it is used in the circuit. Most likely in a case like this, if the capacitor just went open circuit, the rest of the circuit will continue to work but the capacitor is no longer doing its job of filtering out the noise and ripple. Still, the mention that it stopped is what got my attention. That doesn't sound good, pardon the pun. ;-) Dale :-) :-)
[gentoo-user] Problems booting vanilla kernel 4.1.x
Dear all, after successfully using kernel 4.0.5 (vanilla-sources) for a while, I upgraded to 4.1.5 last week and 4.1.6 today. I cannot boot either of them. On the screen I see Decompressing Linux... Parsing ELF... done. Booting the kernel. as the last thing, then it just sits there. To upgrade I copy the previously used .config to the new kernel directory and run genkernel with --no-clean and --menuconfig so that I get the same config as before -- unless I change something, which in this case I didn't. (This has worked very nicely since 3.1.x or so). Does that ring a bell with someone? Peter.
Re: [gentoo-user] Filthy oscilloscope picture! =P
On Sunday 23 Aug 2015 01:11:03 Fernando Rodriguez wrote: On Saturday, August 22, 2015 3:19:50 PM Alan Grimes wrote: Isn't this the filthiest oscilloscope u've seen recently? The only bare metal contact that I could safely use to get a reading off was a +12v line on a spare PCI-E gpu plug. The ground reference is the chassis. You can see the machine's settings in the photo clearly enough. The waveform is fairly constant, it stays in this mode most of the time but sometimes goes into a low ripple mode where the ripple falls to +/- 20mv and holds tight. The scaling indicates the upward spikes are around 0.120 volts and the downward spikes are about 0.22 volts. This __SHOULD__ be within the input tolerances of the motherboard's regulators. Regulators don't filter noise, they introduce it. Capacitors do that as somebody pointed on the other thread. So if you're on a tight budget and you have an electronics surplus store nearby you can replace all the capacitors on your mobo and PSU (except the big bulky ones on the PSU) for about $3. It is quite likely that only the secondary circuit on the PSU needs to have its electrolytic capacitors replaced. We're talking of anything between one to half a dozen of capacitors. In all likelihood less than a $1 to $3. If any are even slightly domed I'd start with those and spend no more than a few cents. Primary circuit ceramic capacitors (transient protection) could have been affected if the PSU was submitted to high surges in the mains supply. I had one go bad on me after sheet lightning hit the area once. Its replacement along with a resistor fixed the PSU without any further problems and to much of my surprise - I thought it was a gonner! Domed capacitors on the MoBo is a different story. Quite likely other components would have been affected and many of them are surface mounted. You'll need a magnifying glass and steady hands for those. It is not something I would attempt in haste, as it is easy to damage more components than what you fix on a MoBo. YMMV. PS. Noisy PSUs are nothing new. The noise is can be caused by the capacitors, or the coils. Although annoying it does not necessarily mean that there is an electrical problem with the components. If the fan is rattling, then a drop of oil on its bearing should soon put a stop to this. As Dale mentioned, a stalled fan will not help the longevity of the remaining components. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problems booting vanilla kernel 4.1.x
On Sun, Aug 23, 2015 at 4:08 PM, Peter Weilbacher newss...@weilbacher.org wrote: Dear all, after successfully using kernel 4.0.5 (vanilla-sources) for a while, I upgraded to 4.1.5 last week and 4.1.6 today. I cannot boot either of them. On the screen I see Decompressing Linux... Parsing ELF... done. Booting the kernel. as the last thing, then it just sits there. To upgrade I copy the previously used .config to the new kernel directory and run genkernel with --no-clean and --menuconfig so that I get the same config as before -- unless I change something, which in this case I didn't. (This has worked very nicely since 3.1.x or so). Does that ring a bell with someone? Peter. I am running vanilla-sources 4.1.6, and so far I have not had any trouble booting it. Are you able to boot some of your previous kernels? If so, what does your '/boot/grub/grub.cfg' look like? What is the output of 'cat /etc/fstab' and 'ls -1 /boot'? If you are not able to boot any of your kernels, if you could get a hold of a Rescue CD or something like that and run the command lines above, that would be helpful.
Re: [gentoo-user] Filthy oscilloscope picture! =P
On 23/08/2015 22:24, Fernando Rodriguez wrote: On Sunday, August 23, 2015 12:14:58 PM Mick wrote: On Sunday 23 Aug 2015 01:11:03 Fernando Rodriguez wrote: On Saturday, August 22, 2015 3:19:50 PM Alan Grimes wrote: Isn't this the filthiest oscilloscope u've seen recently? The only bare metal contact that I could safely use to get a reading off was a +12v line on a spare PCI-E gpu plug. The ground reference is the chassis. You can see the machine's settings in the photo clearly enough. The waveform is fairly constant, it stays in this mode most of the time but sometimes goes into a low ripple mode where the ripple falls to +/- 20mv and holds tight. The scaling indicates the upward spikes are around 0.120 volts and the downward spikes are about 0.22 volts. This __SHOULD__ be within the input tolerances of the motherboard's regulators. Regulators don't filter noise, they introduce it. Capacitors do that as somebody pointed on the other thread. So if you're on a tight budget and you have an electronics surplus store nearby you can replace all the capacitors on your mobo and PSU (except the big bulky ones on the PSU) for about $3. It is quite likely that only the secondary circuit on the PSU needs to have its electrolytic capacitors replaced. We're talking of anything between one to half a dozen of capacitors. In all likelihood less than a $1 to $3. If any are even slightly domed I'd start with those and spend no more than a few cents. Primary circuit ceramic capacitors (transient protection) could have been affected if the PSU was submitted to high surges in the mains supply. I had one go bad on me after sheet lightning hit the area once. Its replacement along with a resistor fixed the PSU without any further problems and to much of my surprise - I thought it was a gonner! Domed capacitors on the MoBo is a different story. Quite likely other components would have been affected and many of them are surface mounted. You'll need a magnifying glass and steady hands for those. It is not something I would attempt in haste, as it is easy to damage more components than what you fix on a MoBo. YMMV. I don't think it's very likely to have damanged something else if it's just noise, but then again I'm not an electronics engineer, this is just a hobby of mine so you may be right. Though I can tell you that I have gotten a few damaged boards to work like new by just replacing the electrolitic caps. That's quite normal - electrolytic caps are the only electronic components that can be considered to wear out. Apart from batteries of course :-) Getting the caps off modern motherboards is a real PITA though - surface mount caps need semi-specialized equipment: a proper soldering iron or hot air pencil with a very fine tip, desolder braid, a magnifier and a very steady hand PS. Noisy PSUs are nothing new. The noise is can be caused by the capacitors, or the coils. Although annoying it does not necessarily mean that there is an electrical problem with the components. If the fan is rattling, then a drop of oil on its bearing should soon put a stop to this. As Dale mentioned, a stalled fan will not help the longevity of the remaining components. :-) I recall an ancient TV from the mid '70s (Blaupunkt) that would sometimes develop a rattle in one of the drive circuit coils. Damn thing would sound like a hive of bees inside the cabinet! Agreed. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] using systemd timers as a cron replacement
Am Sun, 23 Aug 2015 10:38:23 -0400 schrieb allan gottlieb gottl...@nyu.edu: Thank you marc and fernando (fernando, I think your replies go only to marc and not to the group). So it seems the conclusion is timers can't achieve both 1. Run only once a day even if you boot often. 2. Not starting for at least 10 minutes after boot I realize that you can achieve 2 outside the timer by having services fired by the timer begin with a 10 minute delay. However, I thought timers were supposed to achieve 1 2, since that is what I believe you get with vixie-cron + anacron. Also, since systemd.cron is based on timers, I would think it would have the same problem we are discussing. allan FWIW, this is also mentioned in the anacrontab(5) man page that comes with systemd-cron: There are subtle differences on how anacron systemd handle persistente timers: anacron will run a weekly job at most once a week, with allways a minimum delay of 6 days between runs; where systemd will try to run it every monday at 00:00; or as soon the system boot. In the most extreme case, if a system was only started on sunday; a weekly job will run this day and the again the next (mon)day. With carefull manual settings, it would be possible to run the real anacron binary (not your distro's package) with systemd-cron; if you need an identical behaviour. There is no difference for the daily job. I have no idea about the last sentence, since I observe the exact same behaviour with persistent daily timers. HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpMyE0HdEzJq.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Filthy oscilloscope picture! =P
On Sunday, August 23, 2015 12:14:58 PM Mick wrote: On Sunday 23 Aug 2015 01:11:03 Fernando Rodriguez wrote: On Saturday, August 22, 2015 3:19:50 PM Alan Grimes wrote: Isn't this the filthiest oscilloscope u've seen recently? The only bare metal contact that I could safely use to get a reading off was a +12v line on a spare PCI-E gpu plug. The ground reference is the chassis. You can see the machine's settings in the photo clearly enough. The waveform is fairly constant, it stays in this mode most of the time but sometimes goes into a low ripple mode where the ripple falls to +/- 20mv and holds tight. The scaling indicates the upward spikes are around 0.120 volts and the downward spikes are about 0.22 volts. This __SHOULD__ be within the input tolerances of the motherboard's regulators. Regulators don't filter noise, they introduce it. Capacitors do that as somebody pointed on the other thread. So if you're on a tight budget and you have an electronics surplus store nearby you can replace all the capacitors on your mobo and PSU (except the big bulky ones on the PSU) for about $3. It is quite likely that only the secondary circuit on the PSU needs to have its electrolytic capacitors replaced. We're talking of anything between one to half a dozen of capacitors. In all likelihood less than a $1 to $3. If any are even slightly domed I'd start with those and spend no more than a few cents. Primary circuit ceramic capacitors (transient protection) could have been affected if the PSU was submitted to high surges in the mains supply. I had one go bad on me after sheet lightning hit the area once. Its replacement along with a resistor fixed the PSU without any further problems and to much of my surprise - I thought it was a gonner! Domed capacitors on the MoBo is a different story. Quite likely other components would have been affected and many of them are surface mounted. You'll need a magnifying glass and steady hands for those. It is not something I would attempt in haste, as it is easy to damage more components than what you fix on a MoBo. YMMV. I don't think it's very likely to have damanged something else if it's just noise, but then again I'm not an electronics engineer, this is just a hobby of mine so you may be right. Though I can tell you that I have gotten a few damaged boards to work like new by just replacing the electrolitic caps. PS. Noisy PSUs are nothing new. The noise is can be caused by the capacitors, or the coils. Although annoying it does not necessarily mean that there is an electrical problem with the components. If the fan is rattling, then a drop of oil on its bearing should soon put a stop to this. As Dale mentioned, a stalled fan will not help the longevity of the remaining components. :-) Agreed. -- Fernando Rodriguez
Re: [gentoo-user] Filthy oscilloscope picture! =P
On Sunday, August 23, 2015 10:34:20 PM Alan McKinnon wrote: On 23/08/2015 22:24, Fernando Rodriguez wrote: On Sunday, August 23, 2015 12:14:58 PM Mick wrote: On Sunday 23 Aug 2015 01:11:03 Fernando Rodriguez wrote: On Saturday, August 22, 2015 3:19:50 PM Alan Grimes wrote: Isn't this the filthiest oscilloscope u've seen recently? The only bare metal contact that I could safely use to get a reading off was a +12v line on a spare PCI-E gpu plug. The ground reference is the chassis. You can see the machine's settings in the photo clearly enough. The waveform is fairly constant, it stays in this mode most of the time but sometimes goes into a low ripple mode where the ripple falls to +/- 20mv and holds tight. The scaling indicates the upward spikes are around 0.120 volts and the downward spikes are about 0.22 volts. This __SHOULD__ be within the input tolerances of the motherboard's regulators. Regulators don't filter noise, they introduce it. Capacitors do that as somebody pointed on the other thread. So if you're on a tight budget and you have an electronics surplus store nearby you can replace all the capacitors on your mobo and PSU (except the big bulky ones on the PSU) for about $3. It is quite likely that only the secondary circuit on the PSU needs to have its electrolytic capacitors replaced. We're talking of anything between one to half a dozen of capacitors. In all likelihood less than a $1 to $3. If any are even slightly domed I'd start with those and spend no more than a few cents. Primary circuit ceramic capacitors (transient protection) could have been affected if the PSU was submitted to high surges in the mains supply. I had one go bad on me after sheet lightning hit the area once. Its replacement along with a resistor fixed the PSU without any further problems and to much of my surprise - I thought it was a gonner! Domed capacitors on the MoBo is a different story. Quite likely other components would have been affected and many of them are surface mounted. You'll need a magnifying glass and steady hands for those. It is not something I would attempt in haste, as it is easy to damage more components than what you fix on a MoBo. YMMV. I don't think it's very likely to have damanged something else if it's just noise, but then again I'm not an electronics engineer, this is just a hobby of mine so you may be right. Though I can tell you that I have gotten a few damaged boards to work like new by just replacing the electrolitic caps. That's quite normal - electrolytic caps are the only electronic components that can be considered to wear out. Apart from batteries of course :-) Getting the caps off modern motherboards is a real PITA though - surface mount caps need semi-specialized equipment: a proper soldering iron or hot air pencil with a very fine tip, desolder braid, a magnifier and a very steady hand For the tiny SMT ones I usually use an worn out iron tip (cause it may get plastic on it), heat the whole thing up and push it aside if there's room, then pull them off with twizzers and a little bit for force, clean up the contacts with braid. If they're many I use solder paste and an oven the get new ones on. But usually there's still a few through hole electrolytics (at least on boards old enough to be failing) and those are the ones that fail. When they're SMT it's usually a relatively big one or an SMT can and I only seen those fail on homemade or dev boards when I do something stupid. For the canned ones I heat the can up until it comes off. The real PITA with those is that you usually don't find those at a local store. PS. Noisy PSUs are nothing new. The noise is can be caused by the capacitors, or the coils. Although annoying it does not necessarily mean that there is an electrical problem with the components. If the fan is rattling, then a drop of oil on its bearing should soon put a stop to this. As Dale mentioned, a stalled fan will not help the longevity of the remaining components. :-) I recall an ancient TV from the mid '70s (Blaupunkt) that would sometimes develop a rattle in one of the drive circuit coils. Damn thing would sound like a hive of bees inside the cabinet! -- Fernando Rodriguez
Re: [gentoo-user] Re: Anyone using xfce4 with compositing turned off?
On Sunday, August 23, 2015 2:25:47 PM walt wrote: On Sun, 23 Aug 2015 05:53:37 +0200 bitlord bitlord0...@gmail.com wrote: On Sat, 2015-08-22 at 19:08 -0700, walt wrote: I forgot about xf86-video-ati until you mentioned it, so I just emerged it and (I think) made all the changes needed to reconfigure Xorg to use it instead of fglrx. Maybe I'm just too tired right now to think straight, but the error messages I see in Xorg.log tell me that my video chip is not supported. For radeon (free driver) you need to configure more than Xorg, check wiki article about radeon driver [1], It needs in kernel support, also most cards especially newer (=r600) need proprietary firmware. [1] https://wiki.gentoo.org/wiki/Radeon An excellent wiki page, thanks. It tells me that my video chip should be supported so I'll go back and follow all the steps this time. I'd like to avoid the proprietary ati driver if I can. I had nothing but trouble with the free driver with a kabini APU. Hibernate would give a black screen on resume. The Dim screen after an inactive period (whatever it's called) would dim it further until the backlight turns off everytime the period elapses. And a lot of programs like the adobe flash plugin and other players, and games would show video that I may have watched even days before but it's still on video memory when started. The only problem I've had with the proprietary driver (which may be realted to your problem) is that if you use a premptive kernel it causes a LOT of errors to be written to the syslog which makes the desktop very unresponsive. That's because it calls functions that should not be called with preemption enabled. If that's your problem you'll see errors on the syslog and I posted a patch that disables preemption before calling those functions. It's on a VLC bug (cause at first I tought it was a VLC related) and I recently noticed that I still get the errors if I switch between X sessions with CTRL-ALT-Fx so it's incomplete but it makes things much better. I will update it and post it on the right bug when I get around it. -- Fernando Rodriguez
Re: [gentoo-user] using systemd timers as a cron replacement
On Sun, Aug 23 2015, Marc Joliet wrote: Am Sun, 23 Aug 2015 10:38:23 -0400 schrieb allan gottlieb gottl...@nyu.edu: Thank you marc and fernando (fernando, I think your replies go only to marc and not to the group). So it seems the conclusion is timers can't achieve both 1. Run only once a day even if you boot often. 2. Not starting for at least 10 minutes after boot I realize that you can achieve 2 outside the timer by having services fired by the timer begin with a 10 minute delay. However, I thought timers were supposed to achieve 1 2, since that is what I believe you get with vixie-cron + anacron. Also, since systemd.cron is based on timers, I would think it would have the same problem we are discussing. allan FWIW, this is also mentioned in the anacrontab(5) man page that comes with systemd-cron: There are subtle differences on how anacron systemd handle persistente timers: anacron will run a weekly job at most once a week, with allways a minimum delay of 6 days between runs; where systemd will try to run it every monday at 00:00; or as soon the system boot. In the most extreme case, if a system was only started on sunday; a weekly job will run this day and the again the next (mon)day. With carefull manual settings, it would be possible to run the real anacron binary (not your distro's package) with systemd-cron; if you need an identical behaviour. There is no difference for the daily job. I have no idea about the last sentence, since I observe the exact same behaviour with persistent daily timers. HTH Thank you for this. allan
[gentoo-user] Re: Anyone using xfce4 with compositing turned off?
On Sun, 23 Aug 2015 05:53:37 +0200 bitlord bitlord0...@gmail.com wrote: On Sat, 2015-08-22 at 19:08 -0700, walt wrote: I forgot about xf86-video-ati until you mentioned it, so I just emerged it and (I think) made all the changes needed to reconfigure Xorg to use it instead of fglrx. Maybe I'm just too tired right now to think straight, but the error messages I see in Xorg.log tell me that my video chip is not supported. For radeon (free driver) you need to configure more than Xorg, check wiki article about radeon driver [1], It needs in kernel support, also most cards especially newer (=r600) need proprietary firmware. [1] https://wiki.gentoo.org/wiki/Radeon An excellent wiki page, thanks. It tells me that my video chip should be supported so I'll go back and follow all the steps this time. I'd like to avoid the proprietary ati driver if I can.
[gentoo-user] emerge world looking grim
My gentoo OS is running on Openindiana (solaris) inside oracle's vbox. It's been left setting for at least 4-5 months maybe a couple more. After eix-sync, attempting an `emerge vuND world' comes up with so many blocks, use flag changes and a variety of other bad news in such proliferation... I'm thinking better to install from scratch with latest ISO. , | NOTE: The full mess can be viewed here: | | zeus.jtan.com/~reader/vutxt/images/emerge_MassiveFailure-150823.txt ` I've been quite a long time gentoo user but last 2+ yrs only very lightly. I'm awful dumb for someone who has problably more than 15 yrs running gentoo. I wondered if there are some very new ISO's that would contain all major changes in last year or so once I got the core installed and key useflags/make.conf setup? Can anyone advise me which iso to use? And which profile to set for general use in a vbox, hopefully to allow a `no sweat' emerge to a full OS.
Re: [gentoo-user] emerge world looking grim
2015-08-23 20:19 GMT-06:00 Harry Putnam rea...@newsguy.com: My gentoo OS is running on Openindiana (solaris) inside oracle's vbox. Why so much overhead for compiling, and not doing it bare-metal? It's been left setting for at least 4-5 months maybe a couple more. After eix-sync, attempting an `emerge vuND world' comes up with so many blocks, use flag changes and a variety of other bad news in such proliferation... I'm thinking better to install from scratch with latest ISO. Did you really took your time to read that error message, You are seeing problems, except where they are. , | NOTE: The full mess can be viewed here: | | zeus.jtan.com/~reader/vutxt/images/emerge_MassiveFailure-150823.txt ` I've been quite a long time gentoo user but last 2+ yrs only very lightly. I'm awful dumb for someone who has problably more than 15 yrs running gentoo. Considering gentoo doesn't even have 15 years, I guess you are talking to us from the future. I wondered if there are some very new ISO's that would contain all major changes in last year or so once I got the core installed and key useflags/make.conf setup? Can anyone advise me which iso to use? And which profile to set for general use in a vbox, hopefully to allow a `no sweat' emerge to a full OS. You should really step first at the documentation and then ask about it, gentoo doesn't have 'new isos to install', it has stage3 tarballs. you are trying to see gentoo as a binary distro. Did you even tried to read the message before asking? Didn't this told you anything? (From your log): --- * LLVM-3.6.2 requires C++11-capable C++ compiler. Your current compiler * does not seem to support -std=c++11 option. Please upgrade your compiler * to gcc-4.7 or an equivalent version supporting C++11. * ERROR: sys-devel/llvm-3.6.2::gentoo failed (pretend phase): * Currently active compiler does not support -std=c++11 --- gcc-config: error: could not run/locate 'i686-pc-linux-gnu-cpp' * ERROR: x11-base/xorg-server-1.17.2-r1::gentoo failed (pretend phase): * Sorry, but gcc earlier than 4.0 will not work for xorg-server. Upgrade your compiler and try again. But I should say from reading your email you don't seem to have the attitude to be a gentoo user and enjoy it, if this made think about reinstalling without even giving a good read to that error message, I've using gentoo for ~2 years, and even then 4.7 or 4.6, I remember was already a stable compiler, are you sure you haven't upgraded in a significant more time than you say?
