similar to: Bug#691805: Just a little correction..

The path of 'pidof' binary is also incorrect. Needed to change it from /sbin/pidof to /bin/pidof I believe it is not necessary to open a new bug report... Leonardo Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20121029/14c3ad4a/attachment.html>

Package: xcp-storage-managers Version: 0.1.1-2 Severity: important Dear Maintainer, I can not create an iSCSI storage resource using the following command: xe sr-create host-uuid=<my-host-uuid> content-type=user name-label="LVM over iSCSI SR"> shared=true device-config:target=192.168.10.100 device-config:targetIQN=<here-target-iqn>

Dean Andrew and List, I posted here >>https://lists.samba.org/archive/samba/2017-April/207671.html<< that my problem was solved, but I have the following question: What is the possible security issues that may come from removing the 'supplementalCredentials' attribute? Thanks, Leonardo Citando Andrew Bartlett <abartlet at samba.org>: > On Sun, 2017-04-09

Thank you so much, Rowland. I disabled the complexity using the command you sugested (just added 'set', I mean, 'samba-tool domain passwordsettings set --complexity=off'). 'smbclient' still works, no surprise here. However I can't test the Windows login right now. For some weird reason I can't open Windows VMs throught VPN. As soon as I have some aditional

Citando Andrew Bartlett <abartlet at samba.org>: > On Fri, 2017-04-07 at 20:32 +0000, Leonardo Bruno Lopes via samba > wrote: >> Hi everyone! >> >> I have a LDAP with all my users' accounts, each one with the >> sambaNTPassaword correctly defined. I also have a freshly installed >> Samba >> 4.2 running on a Debian 8.7 box. >> >> I

On Sun, 2017-04-09 at 16:12 +0100, Rowland Penny via samba wrote: > On Sun, 09 Apr 2017 14:47:59 +0000 > Leonardo Bruno Lopes via samba <samba at lists.samba.org> wrote: > > > > > Is there any chance that this could mean I only need to wipe   > > 'supplementalCredentials' attribute -- I saw that it is possible > > --   > > after set the

On Fri, 07 Apr 2017 20:32:37 +0000 Leonardo Bruno Lopes via samba <samba at lists.samba.org> wrote: > Hi everyone! > > I have a LDAP with all my users' accounts, each one with the > sambaNTPassaword correctly defined. I also have a freshly installed > Samba 4.2 running on a Debian 8.7 box. > > I followed the instructions described by Steve ThompsSmabon here >

On Wed, 2017-04-12 at 20:31 +0000, Leonardo Bruno Lopes wrote: > Dean Andrew and List, > > I posted here   >  >>https://lists.samba.org/archive/samba/2017-April/207671.html<<; > that   > my problem was solved, but I have the following question: > > What is the possible security issues that may come from removing > the   >

Hi Bruno, actually vicidial is working on top of asterisk, vicidial doesn't know what asterisk using in layer 2. SS7, ISDN stack, Unicall/mfcr2 is working with asterisk. vicidial uses asterisk application to deliver call center functionalities. Regards, Vidura. ================ Dear Bruno, I had the experience of using the Vcidial with the boards of Digivoice. It worked very well!

Package: xcp-storage-managers Version: 0.1.1-2 Severity: important The xcp-storage-managers seems to depends on sg3-utils package which contains the 'sginfo' (/usr/bin/sginfo) binary called by /usr/lib/xcp/sm/scsiutil.py script twice (lines 105 and 107). A simple 'apt-get install sg3-utils' solved this issue so I believe that xcp-storage-managers dependency list needs to

Hello, We believe we have found a bug in Icecast in version 2.3.2 (not the the released code but a version that was taken from a tag icecast2-svn-20090324.tar.gz) and it looks that it also affects the last version in the trunk. We studied a core dump generated by icecast. We found that the crash occurred in the following icecast code: static void auth_remove_listener (auth_t *auth,

On Fri, 2017-04-07 at 20:32 +0000, Leonardo Bruno Lopes via samba wrote: > Hi everyone! > > I have a LDAP with all my users' accounts, each one with the > sambaNTPassaword correctly defined. I also have a freshly installed > Samba > 4.2 running on a Debian 8.7 box. > > I followed the instructions described by Steve ThompsSmabon here >

On Sun, 2017-04-09 at 14:47 +0000, Leonardo Bruno Lopes via samba wrote: > > Dear Andrew, > > I confirmed that 'supplementalCredentials' has different values   > depending on whether I use 'samba-tool' or 'ldbmodify' to set the   > password. That seems to confirm your initial guess. > > > The code in pdb_samba_dsdb that owns the OID you use

I think the explanation of the NAMED field in the R Internals document is incorrect. In Section 1.1.2, it says: The named field is set and accessed by the SET_NAMED and NAMED macros, and take values 0, 1 and 2. R has a `call by value' illusion, so an assignment like b <- a appears to make a copy of a and refer to it as b. However, if neither a nor b are subsequently

https://bugs.freedesktop.org/show_bug.cgi?id=56546 Priority: medium Bug ID: 56546 Assignee: nouveau at lists.freedesktop.org Summary: crash at the second render when applying gamma correction Severity: critical Classification: Unclassified OS: Linux (All) Reporter: yves at 3delight.com

Sorry for taking this long to answer here, I would love to push my changes upstream (the ones for xxHash64) but what I did was use the standard xxHash64 c code as that allows a iterative hash computation, the one on LLVM only has the simple interface to pass a stringref to it, so I really don't know how to move this along, would it require me to rewrite the current internal xxHash64

Ok I went for kind of middle ground solution, I patch in the obj files, but as adding a new section didn't seem to work, I add a "shadow" section, by editing the pointer to line number and the virtual size on the .debug$T section. Although technically broken, both link.exe and lld-link.exe don't seem to mind the alterations and as the shadow .debug$H is not really a section

This part is only for objects with /Z7 debug information in them right? I think most of the third parties are either: .lib/obj without debug information, the same with information on pdb files. Rewriting all .lib/.obj with /Z7 information seems doable with a small python script, the pdb one is going to be more work, but I always wanted to know how a pdb file is structured so "fun" times

I cleaned up my tests and figured that the obj file generated with problems was only with msvc 2015, so trying again with msvc 2017 I get: lld-link: 4s lld-link /debug: 1m30s and ~20gb of ram lld-link /debug:ghash: 59s and ~20gb of ram link: 13s link /debug:fastlink: 43s and 1gb of ram link specialpdb: 1m10s and 4gb of ram link /debug: 9m16s min and >14gb of ram link incremental: 8s when it

Yeah true, is there any switches to profile the linker? On 29 Jan 2018 18:43, "Zachary Turner" <zturner at google.com> wrote: > Part of the reason why lld is so fast is because we map every input file > into memory up front and rely on the virtual memory manager in the kernel > to make this fast. Generally speaking, this is a lot faster than opening a > file, reading