Re: [Shotwell] Picasa Upload Fail
Ühel kenal päeval, T, 2010-09-07 kell 23:32, kirjutas Kenneth Jernigan: > I owe a correction and more information. The database file ended up on the > root drive (a ReiserFS partition...). Anyhow, I found the method to call > the Shotwell with the debug commands. And here is what I receive: > > L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ... > L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema > version 8 created by app version 0.7.0 > L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to > Gtk.main() > > ** ERROR **: AppDirs.vala:106: Unable to create temporary directory > /home/kjernigan/.shotwell/tmp/13887 > aborting... > Aborted > > > > The folder /home/kjernigan/.shotwell links to the folder > /usr/share/shotwell/.shotwell > > Both users are members of a group that has full read/write access to the > /usr/share/shotwell/.shotwell directory. Any ideas? You probably have already checked this, but do the users have rw access to /usr/share/shotwell/.shotwell/tmp/ too? Btw, using /usr for personal data (or even links for that) is very uncommon, /var is usually used for that, and /usr only for program files. Mattias ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] Picasa Upload Fail
I owe a correction and more information. The database file ended up on the root drive (a ReiserFS partition...). Anyhow, I found the method to call the Shotwell with the debug commands. And here is what I receive: L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ... L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema version 8 created by app version 0.7.0 L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to Gtk.main() ** ERROR **: AppDirs.vala:106: Unable to create temporary directory /home/kjernigan/.shotwell/tmp/13887 aborting... Aborted The folder /home/kjernigan/.shotwell links to the folder /usr/share/shotwell/.shotwell Both users are members of a group that has full read/write access to the /usr/share/shotwell/.shotwell directory. Any ideas? Thanks, Ken On Tue, Sep 7, 2010 at 11:09 PM, Kenneth Jernigan wrote: > I see someone created a new ticket 2530 for a similar problem. I've > connected via Shotwell to my Picasa account and can see existing albums and > create new albums. But when Shotwell tries to upload a picture, Shotwell > crashes without any error message. I have been able to publish to Facebook > and export images as well as edit photos without any problems. I am running > Ubuntu Lucid and Shotwell 0.7.1. > > Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised). > However, I am running with the Shotwell database on a permanent NTFS > partition. The Shotwell database folder is hard-linked to the NTFS > partition folder. As for my photos, they are stored in ~/Pictures, which is > a hard link to a different permanent NTFS partition. The NTFS partitions > are from legacy dual-boot installs which I've not entirely purged. I do > share the database and pictures directory between two users, but I always > ensure that only one of us is running Shotwell. I doubt this setup > attributes to the problem, but wanted to share it. > > Let me know if there is anything I can do to provide debug information. > > Ken > ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
[Shotwell] Picasa Upload Fail
I see someone created a new ticket 2530 for a similar problem. I've connected via Shotwell to my Picasa account and can see existing albums and create new albums. But when Shotwell tries to upload a picture, Shotwell crashes without any error message. I have been able to publish to Facebook and export images as well as edit photos without any problems. I am running Ubuntu Lucid and Shotwell 0.7.1. Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised). However, I am running with the Shotwell database on a permanent NTFS partition. The Shotwell database folder is hard-linked to the NTFS partition folder. As for my photos, they are stored in ~/Pictures, which is a hard link to a different permanent NTFS partition. The NTFS partitions are from legacy dual-boot installs which I've not entirely purged. I do share the database and pictures directory between two users, but I always ensure that only one of us is running Shotwell. I doubt this setup attributes to the problem, but wanted to share it. Let me know if there is anything I can do to provide debug information. Ken ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] support to publish to blogspot (blogger)
Hi Ben, Sorry. The link I sent you was actually instructions for integrating the Picasa desktop application with Blogger; instructions for integrating Picasa Web Albums with blogger can be found here: http://picasa.google.com/support/bin/answer.py?hl=en&answer=150419. Cheers, Lucas ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] support to publish to blogspot (blogger)
Hi Ben, Since Blogger and Picasa Web Albums are both horses in the Google stable, they're exceptionally well integrated. If you upload a photo to Picasa Web Albums, it's trivial to publish it to a Blogger blog; see http://picasa.google.com/support/bin/answer.py?hl=en&answer=31292 for more information. Since version 0.5, Shotwell has supported uploading photos to Picasa Web Albums. Regards, Lucas ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] Using GNU Autotools
Valentin, obviously you've put a lot of work into this patch, and we appreciate that. The fact that Shotwell doesn't use autotools, isn't a bug, though - it's a feature. :) The Shotwell team explicitly decided not to use autotools for our project because we find autotools to be hackish, bloated, and slow. We really like the fact that you can check out Shotwell and build immediately, which would not be possible with autotools. We've tried hard to write our Makefile to conform to the GNU Makefile conventions (http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html) so that it is as compatible as possible with those generated by autotools. So it's not obvious to me what problem we would solve in Shotwell by switching to autotools - if our Makefile is currently limiting packagers in some way, please let me know and we can try to fix it. Some other people would also like to see GNOME move away from Autotools. You can read one such proposal here: http://aruiz.synaptia.net/siliconisland/2010/03/buildj-build-configuration-for-the-mases.html Finally, I'll say that we're not opposed to build systems in general - we just don't like Autotools. If you wanted to submit a patch to make Shotwell build with waf, for example, I think that might be fine. cheers adam On 09/07/2010 05:42 AM, Valentin David wrote: > I take the freedom to send you a patch to make use of the GNU > Autotools (i.e. Automake, Autoconf and Libtool) for the project > Shotwell. > > http://www.valentindavid.com/files/shotwell-autotools.patch > > The integration of Vala into Automake is still fishy, and would not > work properly for your project. Actually your project was an > interesting example on the limitations of Vala integration into > Automake. So in the patch here, the support is made by hand. However I > will try to file bugs to the Automake project so that you will be able > to use easily Vala with the future versions of Automake. > > The integration of gettext is also weird in Automake. But at least it > works. However seeing their mailing list it will probably easier to > use it in the future. I noticed that some languages had errors that > gettext would report. I fixed jp.po. I also disabled bad entries in > pl.po. This last one should be carefully checked. I am not really used > with using gettext, and I had no ideas how to fix those entries. > > Automake proposes a nice way add a test-suite. Specially since 1.11 > (with colors and in parallel). I recommend you start to use it. (I > think it answers your #1068). If you have an example of test case you > want to add, I can show you how. > > The patch would certainly work with Autoconf 2.65. But I set the > requirement to 2.67. I advise you to use recent versions of the > Autotools. After all it distributes all it needs in the tarball, so > anybody who wants to compile from the source tarball does not need to > have the autotools. Except if they desire to change the makefiles or > the configuration script. So no point to lower the requirements on > them for portability. > > To make a distribution tarball, it is advised to use "make -j > distcheck" and fix any problem until you get a nice message like that: > > == > shotwell-0.7.1+trunk archives ready for distribution: > shotwell-0.7.1+trunk.tar.gz > shotwell-0.7.1+trunk.tar.bz2 > == > > Then you know that the package is sane. For example someone might want > to compile in a separate directory from the source directory. And this > works smoothly with Automake. Also you are sure that all your clean > rules are right. And all your tests succeeded. > > To test the patch: > > $ svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell > $ cd shotwell > $ wget -O - http://www.valentindavid.com/files/shotwell-autotools.patch > | patch -p0 > $ chmod +x bootstrap # the patch does not do it, but a svn commit would save > it > $ ./bootstrap > $ ./configure > $ make -j > $ make -j distcheck > > > By default it uses silent rules (I think it is nice like that), so > that you do not see very complex command lines. If you wish to see > what is called use: > make V=1 > > I did not try it on mingw, but I tried to make the rules and > configuration so that it works as the old Makefile. The debian scripts > should probably be updated. Feel free to ask me to help fixing the > rest if you desire to apply the patch. > > I can do the same for gexiv2 if you wish. > > Best regards, > ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] Shotwell over NFS + shared access
Hello, Just a quick note. > Having the tags within the image files would probably be the best fit for > me, even though retagging a photo would cause unison to copy the whole file > across. Each side would have to notice when a file had changed, and update > its database accordingly. I used to manage my photos using a program called JBrout that does write tags to the actual JPEG files directly. I also use unison to synchronize my photos to a central location. My observation is that synchronizing changed tags was always quite quick. I assume that changing the tags only alter a very small portion of the file. So, since unison uses the rsync algorithm, it will only transfer these changes and not the entire file. Cheers /Robert ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
[Shotwell] Using GNU Autotools
I take the freedom to send you a patch to make use of the GNU Autotools (i.e. Automake, Autoconf and Libtool) for the project Shotwell. The integration of Vala into Automake is still fishy, and would not work properly for your project. Actually your project was an interesting example on the limitations of Vala integration into Automake. So in the patch here, the support is made by hand. However I will try to file bugs to the Automake project so that you will be able to use easily Vala with the future versions of Automake. The integration of gettext is also weird in Automake. But at least it works. However seeing their mailing list it will probably easier to use it in the future. I noticed that some languages had errors that gettext would report. I fixed jp.po. I also disabled bad entries in pl.po. This last one should be carefully checked. I am not really used with using gettext, and I had no ideas how to fix those entries. Automake proposes a nice way add a test-suite. Specially since 1.11 (with colors and in parallel). I recommend you start to use it. (I think it answers your #1068). If you have an example of test case you want to add, I can show you how. The patch would certainly work with Autoconf 2.65. But I set the requirement to 2.67. I advise you to use recent versions of the Autotools. After all it distributes all it needs in the tarball, so anybody who wants to compile from the source tarball does not need to have the autotools. Except if they desire to change the makefiles or the configuration script. So no point to lower the requirements on them for portability. To make a distribution tarball, it is advised to use "make -j distcheck" and fix any problem until you get a nice message like that: == shotwell-0.7.1+trunk archives ready for distribution: shotwell-0.7.1+trunk.tar.gz shotwell-0.7.1+trunk.tar.bz2 == Then you know that the package is sane. For example someone might want to compile in a separate directory from the source directory. And this works smoothly with Automake. Also you are sure that all your clean rules are right. And all your tests succeeded. To test the patch: svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell cd shotwell patch -p0 <../shotwell-autotools.patch chmod +x bootstrap # the patch does not do it, but a svn commit would save it ./bootstrap ./configure make -j make -j distcheck By default it uses silent rules (I think it is nice like that), so that you do not see very complex command lines. If you wish to see what is called use: make V=1 I did not try it on mingw, but I tried to make the rules and configuration so that it works as the old Makefile. The debian scripts should probably be updated. Feel free to ask me to help fixing the rest if you desire to apply the patch. I can do the same for gexiv2 if you wish. Best regards, -- Valentin David valentin.da...@gmail.com ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] Sharpening tool
Florian, sharpening (http://trac.yorba.org/ticket/690) is currently at priority 'high' in our ticket database, which means we think there's some chance it will make 0.8, though it's not on our top list of features for 0.8 (which are listed on our Wiki page at http://trac.yorba.org/wiki/Shotwell). If it doesn't make 0.8 then I think it will be a strong candidate for 0.9. Patches gladly accepted. :) adam On 09/06/2010 07:17 AM, Florian Manach wrote: > Hi everyone. > > I just wanted to know if advanced retouching and editing tools like > "Sharpenning" are planned for the next versions. > > Thx in advance. > > Florian > > ___ > Shotwell mailing list > Shotwell@lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
Re: [Shotwell] support to publish to blogspot (blogger)
Ben, that's a reasonable idea, so I've created a ticket for this at http://trac.yorba.org/ticket/2522 . I hope that within the next few releases Shotwell will support plugins which can implement exporting to various hosting sites (http://trac.yorba.org/ticket/182), which may make this easier. adam On 09/06/2010 08:09 PM, Ben Podoll wrote: > Is there a way (or is it in the roadmap) to publish to > blogspot.com(blogger)? We've been using Picasa for the last few years > since we never > really liked F-Spot, and we wanted easy support to publish to our blogs. I > really like how Shotwell is coming along, and support for publishing to > blogspot would be ideal. Thoughts/Comments? > ___ > Shotwell mailing list > Shotwell@lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
[Shotwell] Using GNU Autotools
I take the freedom to send you a patch to make use of the GNU Autotools (i.e. Automake, Autoconf and Libtool) for the project Shotwell. http://www.valentindavid.com/files/shotwell-autotools.patch The integration of Vala into Automake is still fishy, and would not work properly for your project. Actually your project was an interesting example on the limitations of Vala integration into Automake. So in the patch here, the support is made by hand. However I will try to file bugs to the Automake project so that you will be able to use easily Vala with the future versions of Automake. The integration of gettext is also weird in Automake. But at least it works. However seeing their mailing list it will probably easier to use it in the future. I noticed that some languages had errors that gettext would report. I fixed jp.po. I also disabled bad entries in pl.po. This last one should be carefully checked. I am not really used with using gettext, and I had no ideas how to fix those entries. Automake proposes a nice way add a test-suite. Specially since 1.11 (with colors and in parallel). I recommend you start to use it. (I think it answers your #1068). If you have an example of test case you want to add, I can show you how. The patch would certainly work with Autoconf 2.65. But I set the requirement to 2.67. I advise you to use recent versions of the Autotools. After all it distributes all it needs in the tarball, so anybody who wants to compile from the source tarball does not need to have the autotools. Except if they desire to change the makefiles or the configuration script. So no point to lower the requirements on them for portability. To make a distribution tarball, it is advised to use "make -j distcheck" and fix any problem until you get a nice message like that: == shotwell-0.7.1+trunk archives ready for distribution: shotwell-0.7.1+trunk.tar.gz shotwell-0.7.1+trunk.tar.bz2 == Then you know that the package is sane. For example someone might want to compile in a separate directory from the source directory. And this works smoothly with Automake. Also you are sure that all your clean rules are right. And all your tests succeeded. To test the patch: $ svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell $ cd shotwell $ wget -O - http://www.valentindavid.com/files/shotwell-autotools.patch | patch -p0 $ chmod +x bootstrap # the patch does not do it, but a svn commit would save it $ ./bootstrap $ ./configure $ make -j $ make -j distcheck By default it uses silent rules (I think it is nice like that), so that you do not see very complex command lines. If you wish to see what is called use: make V=1 I did not try it on mingw, but I tried to make the rules and configuration so that it works as the old Makefile. The debian scripts should probably be updated. Feel free to ask me to help fixing the rest if you desire to apply the patch. I can do the same for gexiv2 if you wish. Best regards, -- Valentin David valentin.da...@gmail.com ___ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
