search for: _mac

...n which is very self explanatory and should work with bash / dash / etc. This can be accomplished with python using only a few lines of code, but bash seems more widely used when creating back end helpers. Hope someone finds it of use. Best, -Tim # creates a random mac address and sets a global _MAC variable # to contain it. makemac() { # edit prefix to suit, ideally matches the manufacturer # prefix of the type of nic your using. local prefix="00:00:6d" local hextet[3]="" local hextet[4]="" local hextet[5]="" l...

Hi, I like Xen''s feature of autogenerating those values if they are not supplied in a config file, but for sake of persistency I want to inherit the once-generated values and reuse them after the first creation of a domU. I found it possible to query the values at runtime using xm list --long but I''m not sure I''m going the most elegant route with that, it would mean

...t; > > apps41.8-5-2TH1-9.sbn > > cnu41.8-5-2TH1-9.sbn > > cvm41sip.8-5-2TH1-9.sbn > > dsp41.8-5-2TH1-9.sbn > > jar41sip.8-5-2TH1-9.sbn > > SIP41.8-5-2S.loads > > term41.default.loads > > term61.default.loads > > XMLDefault.cnf.xml > > SEP[_MAC-ADDR_].cnf.xml > > > > I provide samples of the last two files on the blog > post mentioned earlier.? The last file, that starts > with SEP, should contain the actual mac address of the phone > you are trying to provision.? So, for example, it would > be SEP0003C9DD5624.cnf...

Hi all, I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if this is the right place to submit patches, but someone suggested this on the apparently dead SourceForge patch tracker. The first two are quite straight forward: - The ICL patch fixes a typo in bitmath.h and adds FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c. - The Ogg patch replaces

...is is how things work. That source also includes an fseeki64()/ftelli64(), but they are not defined in stdio.h. I wonder if just declaring it yourself is good enough? If not, they get called by fsetpos()/fgetpos() (which _do_ interact correctly with the buffering in stdio streams), except when _MAC is defined (which I presume is not common). I don't actually have XP to test against.

...gt; That source also includes an fseeki64()/ftelli64(), but they are not > defined in stdio.h. I wonder if just declaring it yourself is good > enough? If not, they get called by fsetpos()/fgetpos() (which _do_ > interact correctly with the buffering in stdio streams), except when > _MAC is defined (which I presume is not common). I don't actually have > XP to test against. Bad, do no declare manually, I had to cleanup some bad code recently that make assumptions about your header declarations. You can try using GetModuleHandle/GetProcAddress instead, but msvcr* versions a...

I decided, since nobody else seems to be doing it, to do a new build of the Mac library. Unfortunately, things now rely on os_types.h. No problem, I'll just create an os_types.h in mac/compat. Except os.h #includes "../include/vorbis/os_types.h" -- in other words, it explicitly wants the os_types.h that was generated from os_types.h.in by configure. The simple solution is to