[opensource-dev] jira patch name convention
Hi all, the jira makes no difference between Snowglobe 1.4 and Snowglobe 2.1, the two most active development branches at the moment. While many jira entries are specifically about one or the other, some things apply to both. There are two ways to deal with this: either create a new jira for the same thing, so we have two jira entries about the same thing, one for patches related to 1.x and one for patches related to 2.x. However, that is not always feasible. The second option is to use one jira for both and just attach patches (if they differ) for both branches to the same jira. For that latter case I propose to use the following convention: Patches that are for 1.x should start with SNOW1-123_description.diff Patches that are for 2.x should start with SNOW2-123_description.diff Leaving out the version would mean it applies in general. Ie, SNOW-123_description.diff should apply to 1.x and/or 2.x (depending on what the jira is about). If there is a patch that is specifically for SG 2.0, and the patch for 2.1 has to look different, you can call it SNOW20-123_description.diff, etc. Aleric ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] http://jira.secondlife.com/browse/VWR-8999
I would be curious if a few devs would try out the patch in http://jira.secondlife.com/browse/VWR-8999 and make comments. Thanks to Latif for coming up with it; it is a little thing, but has been an annoyance to me for quite some time. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] GStream disabled on linux 32bit with a 64bit kernel
I've a 32-bit linux distro (debian sid), with kernel compiled with 32bytecode but amd64 instruction set, uname report "x86_64" so GStream is disable by lunching script (wrongly) i've patched the script http://jira.secondlife.com/browse/VWR-20340 hoping may be usefull to other else Regards Altair ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SL on ARM platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 here is an excerpt from https://secure.wikimedia.org/wikipedia/en/wiki/Nokia_N900 : "The Nokia N900 is powered by a high-end OMAP 3430 ARM Cortex A8 which is a System-on-a-chip made by Texas Instruments based on a 65-nanometer CMOS process. The OMAP 3430 is composed of three microprocessors; the Cortex A8 running at 600 MHz used to run the OS and applications, the PowerVR SGX 530 GPU made by Imagination Technologies which supports OpenGL ES 2.0 and is capable of up to 14 MPolys/s and a TMS320C64x, the digital signal processors, running at 430 MHz used to run the image processing (camera), audio processing (telephony) and data transmission." I've read people managed to overclock the processor up to about 1 GHz, some people even made it so the clock would change depending on how much is being demanded from the processor, not only getting better performance but also increased battery time. On 20/7/2010 14:52, Altair Sythos Memo wrote: > On Wed, 14 Jul 2010 12:35:01 + (GMT) > DEEPAK JAIN wrote: > > compile on ARM is possible, depending on which operating system you > want to do. ARM since V4 is basically a 32bit little endian processor > (latest version big endian 64bit too), a GCC since V2.95 can compile > ELF binaries. > > Using ARM linux you can follow a generic "standalone build" how-to > (preconf libraries aren't compiled for ARM), but the problem is only > shifted on performance side. I've worked on Familiar Project to > 5years ago (ex-compaq linux project on ARM devices) and about all > application written in a good ANSI C/C++ can be compiled without too > much pain, the step after is who do all the rendering job. A lot of > nowadays portable devices (handhelds, smartphone, pdaphone, tablet pc) > have a "sort of" GPU or graphic co-processor, but very few of them have > full OpenGL support (I think OpenGL2.1 is the minimum for latest > viewers), some have only software OpenGL API (ridicolous performance). > > some detail more can be usefulkl to answer to your wuestion ;) > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkxHikAACgkQ8ZFfSrFHsmXY5QCeOx7nK9fi7kDXOx2GcSItiFAv GVMAniN++5PN7mgnGDTLZxfbF6o+jrOg =RN/k -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] TeamCity build production
Hi, I went through the whole export and build system again on TeamCity and fixed everything that was strictly build script and TeamCity config related. Summary: - viewer-public export: the export script was faulty, pointing to libs ad artwork bundles that were empty since the swtich to TeamCity (7/12). This has been fixed and exports since yesterday starting with build 207152 are producing correct bundles. One note: the name of the bundle is a bit confusing since it has "viewer-2-0" in it while the version is "2.1.0.x". This is because the internal hg branch I'm using is named that way. This will become "viewer-public" once we merge the export script there. - Binary posting: the 1.x trunk (1.4) and 2.x trunk (2.1) were both dropped in "viewer-source-downloads/2010/trunk" and could end up overwriting each other. I fixed that by forcing the 1.x trunk in "2009" since it's what its svn branch says. - 1.4 Build posting: those were dropped in lala S3 land and unreachable because of some svn client issue on TeamCity. Fixed. - Email notification subject: I fixed the "Build ()" blank notification subject to mention the branch and revision and added the "year" (2009/2010) so we can easily spot the 1.x (2009) from the 2.x (2010) notifications We still have issues with the Mac executable produced, both for 1.x and 2.x (different issues) but those are code (2.x) or build option (1.x) issues, not TeamCity issues. I hope we'll seen a full "green" production cycle with downloadable and usable binaries tomorrow. Thanks for your patience. - Merov ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] TeamCity build production
Am Donnerstag 22 Juli 2010 schrieb Philippe (Merov) Bossut: > Hi, > > I went through the whole export and build system again on TeamCity > and fixed everything that was strictly build script and TeamCity > config related. > Thanks for your patience. > > - Merov You are awesome. bye, LC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
