search for: 20200811

...019 system drwxr-xr-x 2 root root 4096 Sep 13 2019 tmp drwxr-xr-x 2 root root 4096 Sep 13 2019 voicemail Any suggestions on what I am doing wrong? Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200811/90eb6691/attachment.html>

On Mon, 10 Aug 2020, Todd Benivegna wrote: > synoups: https://hastebin.com/xexafofiha.bash Wow! What a mess. It looks as if Synology wanted to write their own "NUT", but decided it would be easier to put their ideas in a script when they saw they could use upssched.conf to call it. NUT intends such a script for timer management. Synology use it for general system management.

...__ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200811/7f9a2b51/attachment.html>

...__ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200811/d5728801/attachment.html>

Hi, everyone, A quick reminder: This call will start in approximately four hours. See below for how to join. On our current agenda: Agenda * Full restrict patch * Observation and clarification * Issues encountered * Speed up in intersection code - O(nlog(n)) * Calling Verifier after LoopVectorize pass? -Hal Hal Finkel Lead, Compiler Technology and Programming

...etwork). --Larry -- Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com Minneapolis, Minnesota www.FahnoeTech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200811/f8bec641/attachment.html>

...__ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200811/301106eb/attachment.html>

...ed in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Markus-Elfring/drm-nouveau-gem-Use-vmemdup_user-rather-than-duplicating-its-implementation/20200812-150757 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-c002-20200811 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp at intel.com> coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/nouveau/nouveau_gem.c:589:9-16: WARNI...

...#39;~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/rsync/attachments/20200811/5396fccf/signature.sig>

Hi, I see some warnings like the following. Could anybody explains what they mean? Thanks. 19/31274477.pdf 257,169,119 0% 1.26MB/s 0:03:15 (xfr#121, to-chk=848309/1043298)WARNING: 18/32281577.pdf failed verification -- update retained (will try again). WARNING: 19/28879866.pdf failed verification -- update retained (will try again). -- Regards, Peng

...nihan at fsu.edu> 850-645-6067 850-645-7200 WFSU Public Media 1600 Red Barber Plaza Tallahassee, FL 32310 wfsu.org<http://wfsu.org> [WFSU Public Media] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200811/f439dd51/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1386 Bug ID: 1386 Summary: nftables.py cmd doesn't read updated counter values after first read Product: nftables Version: unspecified Hardware: x86_64 OS: Gentoo Status: NEW Severity: major Priority: P5 Component:

From: Markus Elfring <elfring at users.sourceforge.net> Date: Tue, 11 Aug 2020 19:25:22 +0200 Reuse existing functionality from vmemdup_user() instead of keeping duplicate source code. Generated by: scripts/coccinelle/api/memdup_user.cocci Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 12 +++--------- 1 file changed, 3

This morning I did a build with Ninja, which mysteriously decided to rebuild the entire system (something about a deps stamp being corrupted). When it was done, I had a new llvm-tblgen.exe, but all the target .inc files were old. Hmm. So I touched one of the TableGen source files and did another build. Again, a new llvm-tblgen.exe but no new .inc files. I do, however, have a new .inc.d file

...LLD code. Are there any existing examples of adding custom ELF sections at link time in LLVM framework? Is it possible? Any pointers? Thanks in advance!Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200811/457afa52/attachment.html>

On 8/12/20 3:42 AM, Manuel Wolfshant wrote: > On 8/12/20 3:20 AM, Todd Benivegna wrote: >> Hi everyone, >> >> Well, we lost power here again.  I was not at home, but I guess a >> dump truck smashed into some power poles and took out half the city; >> actually tripped most of the breakers in the panel.  Anyways, the >> power was out for just a few seconds

I have submitted a patch to Phabricator that includes the TableGen file TGparser.cpp. Now I want to fix a bug in that file. What is the proper procedure so that the two patches don't get screwed up, either in my repository or in the master repository? Please answer as if I'm a git/Phabricator idiot, because, well, I am. I should note that all I did in my repository for the first patch was

Hello, I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the

...__ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200811/f88dfe24/attachment.html>