shotwell: 2048px publishing for unlimited picasa/G+ storage
@G+ users: Ever wanted to use shotwell to mass-publish your pics taken with your high resolution camera to picasa? Ever found that you cannot publish using the max pic size that gives G+ users unlimited storage (2048px) easily?
If so: I made a tiny patch for shotwell that allows you to do exactly that and prepared a package for Ubuntu 12.04 LTS (precise). You can get it from my ppa: https://edge.launchpad.net/~asac/+archive/ppa with just a few clicks/commands away:
sudo add-apt-repository ppa:asac/ppa
sudo apt-get update
sudo apt-get install shotwell
sudo add-apt-repository -r ppa:asac/ppa
Here a screenshot of what it does:
Hope this is useful for some! Have fun!
Update: uploaded an untested backport for Ubuntu 11.10 (oneiric) to the same ppa. Report back how things go!
Update: trivial patch from my package forwarded to shotwell issue tracker http://redmine.yorba.org/issues/5210
Mission Hamburg @ gmaps - April 1st, 2012
I am sure I don’t get mercurial’s (hg) branches and heads concept…
I am sure I am moronic, but …
hg clone http://dev.mutt.org/hg/mutt
destination directory: mutt
requesting all changes
adding changesets
adding manifests
adding file changes
added 6202 changesets with 17611 changes to 532 files (+8 heads)
updating to branch default
369 files updated, 0 files merged, 0 files removed, 0 files unresolved
gives me a fresh copy claiming that it updated the ‘default’ branch.
Now…
asac@thinki:/tmp/test$ cd mutt/
asac@thinki:/tmp/test/mutt$ hg branch
default
confirms that somewhat, but…
asac@thinki:/tmp/test/mutt$ hg log -l1
changeset: 6201:c26dbc7021f4
branch: HEAD
tag: tip
user: TAKAHASHI Tamotsu <ttakah@lapis.plala.or.jp>
date: Tue Dec 20 22:24:35 2011 -0800
summary: Updated Japanese translation
already seems to think its the HEAD branch and…
asac@thinki:/tmp/test/mutt$ hg branches
HEAD 6201:c26dbc7021f4
mutt-1-4-stable 5160:9c9fbf98fbda
mutt-1-4-stable-NEW_NOICONV 2871:2946ce6c56c9
mutt-1-2-5-1 1839:1da8b126c870
mutt-1-0-stable 1203:982532ae8410
mutt-0-95-exp 682:90944f375844
mutt-0-94 411:a60586461eb8
mutt-0-93 146:6934de2f9f48
muttintl 2:5b142858393a
default 5034:f467353f5657 (inactive)
mutt-1-2-stable 1835:8b0b9f06f1ba (inactive)
tells me the default branch is a) inactive and b) a different revision.
I feel that ‘default’ is probably something like a magic label referring to a somehow configured default branch in the repository (e.g. HEAD in this case), but then I couldn’t figure a) how to set which branch ‘default’ should refer to and b) what the real ‘default’ branch above is about and why I cannot get that revision checked out with ‘hg checkout -r default’.
I tried searching the hg web documentation and found confusing things like concepts of branches, heads and dragons etc. in mercurial…
So now I wonder: is hg harder than git?
If anybody knows about a crisp and clear write up on how to use hg branches/heads properly, please drop a comment. At best such intro would be targeted at the use case of maintaining a longer term running downstream repository with a regularly rebased? branch…
Linaro invests in blueprint work items - Launchpad grows convenience
This must be a very exciting, christmas type day for many us that didn’t like the very rudimentary (or non-existing) work item support of launchpad’s blueprints and that hoped to get better and more convenient tooling for their daily work item maintenance for a long time.
Linaro heard you and is actively investing into adding convenience infrastructure that will hopefully make life of all of you work item poets much easier and more pleasant!
For some background, check out the launchpad blog post here: http://blog.launchpad.net/cool-new-stuff/work-items-in-blueprints.
Canadian Aiport Codes and the “why the Y”
don’t ask me why, but the question why all “big” canadian airport codes start with a Y came to my brain. Like:
- YVR - Vancouver
- YYZ - Toronto
Quick search gave me a forum thread with this explain:
Okay, so the final answer, and specifically the answer to the question above is found here below. I am going to be quoting from my Canadian IFR ground school course text written by Micheal Culhane.
“Although the naming of Canadian airports and weather stations can seem confusing, here is a brief explanation. Originally, in the 1930’s, Canada used two letters for identification of a weather reporting station. Additionally, preceding the 2-letter code, was placed a Y (meaning “yes”) where the reporting station was co-located with an airport, a W (meaning “without”) where the reporting station was not co-located with an airport, and a U where the reporting station was co-located with an NDB. An X was used if the last two letters of the code had already been taken by another Canadian ident, and a Z was used if the locator could be confused with a U.S. three letter ident. … The ICAO names are in a 4 letter format starting with a C for Canadian airports.” (section 2.18 pg 64)
Now the rest of the airport code scheme seems to be still a partly mystery, but it makes at least a lot of more sense now:
- YVR for Vancouver and YOW for Ottawa: makes sense to my brain
- YYC for Calgary: seems this is the result of a conflict induced backflip (YCY is Clyde River Aiport, Canada)
- YYZ for Toronto: There must be a combined bitshift with a backflip somewhere here :)
Not sure if this was worth the typing, but guess fun enough for a Sunday afternoon hotel room activity in California. This reminds me: let me go down and grab a beer or two…
Maybe a million people on ice these weekend by Cornelia Schroeder on Flickr.
Altereisvergnügen in Hamburg … too bad i am on a biz trip in California right now.
Thanks to Cornelia Schroeder for that pic! It helped me get past my depression of not being able to enjoy this once-in-a-decade happening.
Rock on Hamburg!
p.s. yes, Linaro connect here in the bay area was more than worth this sacrifice.
Developer Platform & Ubuntu sessions at Linaro Connect Q1.12
Linaro Android lead proposes new build naming scheme
For a while we knew that our currently used scheme for naming our android builds didn’t do a good job at conveying what was in there. Finally, Zach proposed a new naming scheme on the linaro android mailing list. I like the way it ensures that people understand the main ingredients of how our builds are cooked at a quick glance, but I only see this as a first step!
First step only, because the name can only give information about the main/biggest components integrated and obviously cannot give a complete list all components changed and used to cook our builds. This means: even after this, we have to continue our effort to improve the documentation shipped side-by-side with our build and release artifacts.
If you have feedback on top of what was discussed in that thread, talk to pfefferz on irc.freenode.net or reply here or to the mailing list post:
The screenshots in this post capture a preview of raw results coming out of LAVA for the basic WIFI and X11 smoke tests currently developed by Ricardo’s DevPlatform Team. I like what I see so far! For now, my only suggestion on that is that the names of the tests could be improved a bit :).
So, what’s left to finish things up in time for 12.01 release?
- Dave Pigott from the LAVA lab team to set up initial instrumentation for automated WIFI and bluetooth testing in the LAVA lab
- Ricardo and team to finish and cut a first release of our Ubuntu middleware smoke test suite and set it up to automatically tests the ubuntu LEB images.
- Release team to add reviewing and monitoring the middleware smoke test results to their continuous release process and the final build sign off.
Quite exciting stuff; stay tuned!
If you are interested in how to add automated tests like this to LAVA, check out the current code in bzr:
Couldn’t remember the URL for the open-source multimedia test repository maintained by Linaro’s Multimedia WG for a while now. Google didn’t come up with a good direct hit either, so here it is:
Here you can get open-source video and audio content encoded in various formats and codecs. Linaro engineering and community can and do use this to verify their enablement, codec and integration work.
