http://permalink.gmane.org/gmane.comp.video.lumiera.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.lumiera.general/1625 <pre> Lorenzo schrieb: ...as said, we /have/ these screenshots. They aren't even a mockup. http://git.lumiera.org/gitweb?p=lumiera-propaganda;a=blob;f=lumiera_screenshot.png What we really need is volunteers working on the website, re-arranging the existing already asciidoced pages, writing summary pages, etc. Of course, in addition it would also be helpful if the "workflow" related things could be picked up. There is a started minimal workflow by Nikola, there is the proposed TOC of a user manual (which is helpful as an outline), there are some detail discussions etc. No one is currently blocked by these things missing, but it would be certainly of benefit for the project (i.e. to do this discussions and planning work) and also for the visibility (because it could lead to more detailed mockups). While I'd like to work on this, I'll refrain from doing so personally, because my contribution is much more needed some levels below ;-) Cheers, Hermann _______________________________________________ Lumier</pre> Ichthyostega 2010-02-10T00:43:53 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1624 <pre>_______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html</pre> Lorenzo 2010-02-07T18:59:54 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1623 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, according to our usual habits, the next Lumiera developer meeting will happen in the second week of February. Currently, it seems that Saturday is good for everyone, right? Thus, the schedule would be: Saturday February 13, 2010 20:00 UTC The meeting will be held on IRC: freenode.net in #lumiera Please speak up if this schedule doesn't work for you. Not much official topics on the agenda this time, but still some details to discuss. Please feel free to propose topics or just join the meeting. Hermann Vosseler (aka "Ichthyo") -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktu7DAACgkQZbZrB6HelLIaLQCfdM8QjpdfzgJAMqEDdjqZDa/r BDQAn1XcH59Tshj8zL2RwN4aqaVpHKug =L/Vp -----END PGP SIGNATURE----- _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cg</pre> Ichthyostega 2010-02-07T16:37:05 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1622 <pre>Lorenzo schrieb: the only problem is: you won't see a visible difference to the last screenshot published, as all work done meanwhile is happening rather well below the surface :-) Cheers Hermann _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Ichthyostega 2010-02-06T23:17:47 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1621 <pre> Thanks for trying, looks like the autoconf is missing somthing there, maybe just an older version? Anyways you may try from the tarball version: http://www.pipapo.org/nobug-releases/nobug-201002.1.tar.gz.gpg This comes with 'configure' and you dont need to bootstrap it see: http://lumiera.org/nobug_manual.html#_release_tarballs I've added some maintainer targets to the toplevel Makefile, you possibly need gnu make (gmake) but if you dont have it installed you may first try without. Trying with suns C compiler instead gcc would be also worth a try (is it C99 conforming?) otherwise gcc should work. Thanks Christian _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Christian Thaeter 2010-02-05T05:56:46 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1620 <pre>Well, after getting no response from any solaris folks I tried this myself. Granted I have never tried to compile anything on Solaris. After making seemingly unnecessay symbolic links for aclocal and automake I get the following after running autoreconf -f -i ... autoreconf -f -i /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.ac:32: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:35: error: possibly undefined macro: AC_DEFINE configure.ac:52: error: possibly undefined macro: AC_MSG_NOTICE autoreconf: /usr/bin/autoconf failed with exit status: 1 I am sure that I am missing some bit of information that you would normally know if you compiled on </pre> Aaron Newcomb 2010-02-04T16:36:43 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1619 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Thaeter schrieb: Agreed. Following this argument, I've now re-issued the deb package thereby brushing the commits from this morning under the carpet :-P Hermann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktq6lUACgkQZbZrB6HelLKEDQCg2k30nU4XCsW4ZwSGzOVbbpQJ jZgAniURIgro/7AXB8y1RhA9qPKabOnk =lHAf -----END PGP SIGNATURE----- _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Ichthyostega 2010-02-04T15:40:06 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1618 <pre> i didnt bumped it because there was no change in a working abi, as in the broken functions from the release before will not enter production because they just dont work :P. Strictly speaking one should always bump versions when somethings changes but since the nobug user community is small and no end-users are affected i'd rather aim to keep the library version numbers small. Of course this breaks apps which using the defective 201001.3, but in this way it's rather a deliberate nudge not to use some defective lib. Christian _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Christian Thaeter 2010-02-04T12:00:43 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1617 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Thaeter schrieb: Just pushed out the Debian package nobug_201002.1-1 at git://git.lumiera.org/nobug Note: Lumiera master still uses 201001.1-2 Christian: due to the ABI change, I bumped the library version. Please pull also the "upstream" branch into your master in the nobug repository. Maybe we should even move up the tag "201002.1" to include this bumped lib version. Strictly speaking, the changes seemed to be downward compatible (only added symbols in the lib). But, I think actually we don't want anyone to link against the old library version anymore, right? Cheers, Hermann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktqsX0ACgkQZbZrB6HelLJv7gCfYmaQNz5VoyzoYXkI4mHrZaId OSoAn2+dJJlZFAE0Q0k3vcYg+jP5V2Wv =7Csk -----END PGP SIGNATURE----- _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy</pre> Ichthyostega 2010-02-04T11:37:33 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1616 <pre>I just made a new NoBug release, there leaped a nasty race condition in. Ichthyo, please pull from my 'backend_devel' there are some things pending for you. For anyone else: the current development stuff is little bumpy, don't update we'll push a fixed master soon. Christian _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Christian Thaeter 2010-02-03T09:50:19 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1615 <pre>Hi ichthyo, the lumiera thread handle returned by lumiera_thread_run() was initially meant to be an opaque pointer only notifying the caller about success or failure of the call. By now we added join() and sync() which gives it little more purpose. For a joinable thread the handle is guranteed to be valid until you join it. But for a non joinable thread this handle is only considerd to be valid until the last sync() call by the thread. Notably sync/sync_other() must be properly paired and synchronized. This was only meant for startup synchronization anything beyond this and perhaps loosing syncronization pairing leads to undefined states. If such is need then we need some more heavyweight syncronization using a custom mutex or condition var outside of the scope if the thread management itself. Whats left is the 'isValid()' call you added to the thread wrapper which is impossible to implement for non-joinable threads (by purpose). Argueable this is a bit sloppy, but adding more handshakes and states there de</pre> Christian Thaeter 2010-01-30T05:18:07 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1614 <pre>Ichthyostega schrieb: oops... just to clarify: current Lumiera master works with 201001.1-2 which corresponds to GIT [8ec97d12ad3] We're in the process of adopting the newer releases... Hermann _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Ichthyostega 2010-01-30T01:33:49 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1613 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Thaeter schrieb: Just created the debian package for this release Ichthyostega schrieb: NOTE: use this one for current Lumiera master. * debian/201001.3-1 : the newest release from Christian. Using library versioning starting with this one Cheers, Hermann V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktjiCMACgkQZbZrB6HelLIdigCfVrUieS47kjQHMOtCJwiXxUri qHMAn1beOCLj4LJs3aZ8eK6GI2IbZAqe =KCcF -----END PGP SIGNATURE----- _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Ichthyostega 2010-01-30T01:15:15 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1612 <pre>New NoBug, no much new things and not required for Lumiera but adds some nice things under the hood: Refactored the logging core, it now supports multiline logging, log statements can contain newline characters which will emit to multiple loglines atomically, resource dumping uses this feature. The nobug libraries are now properly versioned. Added internal ringbuffer documentation. The ringbuffer guard pages can now be dynamically configured. Resource logging stays active in BETA builds in preparation for offline resource tracking. Improved release targets for make, that means more frequent releases in future. The library versioning should make packaging live easier, only the manpage is missing now. Christian _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Christian Thaeter 2010-01-29T07:35:20 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1611 <pre>_____________________________________________ Christian, I will meet you to work with uWiki. Since then nothing much happend :/. my answer to that lackyness is that from mid december to early january I was with family and vacationed. from early january to current I was composing my verse 3 of the website map and other personal work. I had to balance two related commitments in this project, uwiki and site design. since our previous attempts to start uWiki at my system were failures mostly, I choose respond to the website map verse 2 that was authored. I am not the quickest author, that explains the delay of my website map verse 3. the reason for my slow publication was that I like to analyze, research, and appreciate in thought before I write. during the design process I concurrently thought of my work as a programmer and the details of uWiki that are needed to realize our designs. however late that verse 3 was published, I think that I chose correctly to author verse 3, that was a conce</pre> andrew james 2010-01-28T07:19:16 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1610 <pre> I'd just mention that closed tickets dont mean that this things are final until the end of the world. But at some point we just have to get things done (as decided) and maybe improve them later, possibly even in many incremental steps. Talking and refining things before the implementation even started won't bring us elsewhere. On mid December I send an announcement that uWiki is (almost) ready from the backend coding side and now needs some web developers *urgendly* to make it useable. Since then nothing much happend :/. Of course we want a new web site and a nice structure and design. But with our current manpower and resources we make no progress if we don't do that in very little steps. I'd rather like to if someone takes initiative in starts implementing the things which are decided and necessary to go further than talking about future glorious web pages. We can and will improve that later (with uwiki this might even become quite simple). Christian _______________________________________________ Lum</pre> Christian Thaeter 2010-01-27T22:08:52 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1609 <pre> I am concerned that this job was closed prematurely. Early january I told Christian Thaeter that I would later draft my response to your proposal. report at trac ticket 229 truely states that the ticket is closed - was closed three weeks ago but all the most recent work for the website is also three weeks old. http://issues.lumiera.org/report/6 'Press page', 'About page' are also in the website map verse 3 that is an addition to your version 2, in no way a 'move backwards' if you really are grateful for my time and energy then you may want to read verse 3 that is a result of my 4 years experience in government site design and recent cumulation of my thoughts for how to form an open source project, community. per my experience as, website map version 2 is not even easily translatable for a web developer to a website. verse 3 was authored from my web programmer perspective that saw structural redundancies and superfluousness in verse 2. for example, it is not clear what PUBLIC SECTION is</pre> andrew james 2010-01-27T21:42:19 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1608 <pre>Andrew, thanks for your collaboration on Lumiera. Please, note that this ticked is closed. http://issues.lumiera.org/ticket/229 Website map was already discussed and accepted. While I agree it might not be perfect, I state that we can't keep opening every decision back to discussion or we risk to move backwards instead of forwards. We are very grateful you give your time and energy for Lumiera and we need your work. Please, prefer collaboration on open tickets. As usual, communicate what you want to do before starting so that we can coordinate things. Ciao Raffaella _______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html </pre> Raffaella Traniello 2010-01-27T09:16:12 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1607 <pre> nothing too fancy. but if you go to sites like microsoft or adobe creative suite they have community for their users, developers, designers. actually adobe's site is lame and exclusive, administrator controls exposure. that perfectly describes this part of the design. I think we (video editors, open source community) can create better integration of users art, guides, tutorials - specific to lumiera. That might be taking off more than we can chew not only The type of wiki (uwiki) that is intend for the site is dynamic enough to control the data. I personally accept the job as manager of community...or coordinator, call me whatever you want -- ;) kinky wink. Otherwise it just I think that in this context you more refer to the four types of persons in COMMUNITY than 'profiles'; user, developer, merchant, donor. be careful to not exaggerates the number of types of persons. those four were chosen to represent the current dichotomies of open source projects. work and money. each person </pre> andrew james 2010-01-27T09:04:02 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1606 <pre>_______________________________________________ Lumiera mailing list Lumiera-aLEFhgZF4x639dL7tAm8iNi2O/JbrIOy&lt; at &gt;public.gmane.org http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera http://lumiera.org/donations.html</pre> yanikn-v1ITN679K0Syum0STUha2w< at >public.gmane.org 2010-01-26T15:22:29 http://permalink.gmane.org/gmane.comp.video.lumiera.general/1605 <pre>redesign website map verse 3 Raffaello was the author of verse 2 with some explicit help from Itchthyo in the “Dev's vault”. verse 3 is the result of research, analysis, reversion. in part one, the map is described. in part two the changes from verse 2 are explained in verse 2, our community was defined as developers and users. verse 3 is an attempt to join the two groups. verse 3 defines developers to include programmers, documenters, educators, marketers, promoters, even critics and feature requesters. users are anyone. to define, for example, documenters, educators, marketers, and promoters as developers in addition to programmers is respectful and a result is increased communication. the theory is that more developers is always better. if users and developers are exposed to the variety of development then they can easily transition from user to developer and developer to developer. part one map specifics * the purpose of the map is to define all sections once in the</pre> andrew james 2010-01-26T06:34:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.lumiera.general