Elsewhere

Body: 

DrupalCon Sydney 2013 is now over! We had a fantastic time, and we'll be talking about that really soon, but first there's an important matter we'd like your help with.

The Drupal Association is looking for feedback on the sessions presented at DrupalCon Sydney 2013, and are encouraging you to submit it via the web. We understand that there are some issues with the submission form on the DrupalCon site, so we decided to help out by reminding people about a different approach for your feedback.

We've got a rating system already in place on the DrupalCon Sydney 2013 Mobile App. The data goes to the Drupal Association and the feedback is critical for the DA so that they have a better idea of what sessions people want to see, and what feedback to give to presenters. We really appreciate the many of you have already have already used the mobile app and ecourage you to rate all the sessions. 

For those that haven't, please do the following::

1. Download the app for your phone or device from the Apple App Store or Google Play.
2. Run the app, open the Sessions list and navigate down to the session you want to rate.
3. Click the Rate this session button.
4. A form will be shown, prompting you to select a star rating from 1 to 5, as well as enter a short comment.
5. Click Save, and your results will be saved and sent to us.

If you have any problems submitting, please let us know. The future of DrupalCon depends on your feedback!

Geoffrey

One the third day of DrupalCon Sydney, all the Drupal 8 initiative owners conducted a Q&A with attendees in Sydney. Some of us were there in person, and some connected via Google Hangout. In a moment of weakness, I sent a message on Twitter to request questions via the cheeky hashtag of #IOHeckle. There were so many questions from (and discussion with) the audience that we didn't get to most of the Twitter questions, but they were generally really interesting so I decided to answer them anyway.

Thanks to everyone who submitted questions!

What are all of your plans for maintaining your new code/subsystems after 8.0 release? Any new features mid-cycle before D9? - Dave Reid
I don't really know how involved I will be. After my funding runs out I am planning on getting a full time job again, and to some extent it will depend on how that works and what kind of time I have available. I do plan to take a break from day to day core work after release but we'll see what happens going forward at that point. As far as mid-cycle features for Drupal 9, I'd like to see some enhancements to the import UI and site building tools. I think there's more we could have done there but we ran out of time.

What is 1 thing that you didn't get to in 8 that you want to change 9+? - Dave Hall, Dave Reid
At DrupalCon Munich several people got a presentation from Bernhard Schussek, maintainer of the Symfony forms system. He talked about how Symfony forms work and how their approach compares and contrasts to Drupal's Form API. I left the presentation really impressed with Symfony forms and wishing we had the time to investigate whether they would be a good replacement for Form API. Anyone interested in that presentation can download the PDF from http://drupal.org/node/1447712#comment-6497818. Ultimately this just happened too late for anyone to have time to do anything about it, but I'm pretty sure we'll get to it in Drupal 9.

Are you worried about how fast major version releases affect the Enterprise community, since they're almost always slow to adopt? - Domenic Santangelo
I answered this to some extent in the presentation but there are a couple things I didn't get to bring up that are really important to consider. I'm a huge advocate for a faster release cycle for a variety of reasons. Obviously technology is changing at a brisk pace and it is important to keep up as much as possible. However our release cycle also places enormous burdens on us that are not always plainly obvious. For instance, it makes fundraising for core development much more difficult than it would be if we released more often. The most common refrain I heard from people I approached for funding was "We can't invest in something we aren't going to be able to use for two years." Another problem we have is that our long development cycle puts a lot of pressure on people to get things 'exactly right' because they know they'll have to live with it for six more years. This is actually a huge cause of many issues that become embroiled in architectural purity or arguments over differing approaches. If we knew we could adapt and improve iteratively, a lot of this pressure would disappear. This of course opens up backwards compatibility questions (which are discussed in the video) but I think the gains we would get are well worth it. I'd love to see us on six month release cycles for Drupal 9.

What is the one most important thing you would tell a D9 initiative owner that you wish you had known? - Dave Reid
Build a multi-functional team from the start. This is the thing the Views team got right, and its a huge reason why they were successful. They got four people together with differing but also overlapping skill sets, all of whom agreed to work together and stay on top of the things for the long haul. This is so important, and its something I never really had. I have had contributors who have been active for most of the project (most notably Daniel Kudwein and Alex Pott) but it was never a 'team', we never really coordinated much amongst each other, we never sat down and made a roadmap or raised funds as a group. Two years ago I wish I had gotten a core group together and just fundraised for the lot of us to work for the next two years. It would have been phenomenal.

"If you could send a message to yourself-one-year-ago, what would it say? - Cathy Theys
Build a team right now and start fundraising for all of you.

If you were to receive a message today from yourself-one-year-in-the-future, what do you hope it would say? - Cathy Theys
It was all worth it.

What was the best (got results) method of communicating the top priorities and asking people to help with what you most needed? - Cathy Theys
I feel like I never got a handle on this. Gábor did an amazing job with his D8MI website (http://www.drupal8multilingual.org/), and I know it has served him well. In my case, I feel like every time I tried to communicate my own priorities I didn't get a lot of results, and I also feel like my priorities didn't mesh well with the priorities of others working on CMI issues. Around the end of the original feature freeze I thought it was enormously important to get our admin functionality done so that people could test the system as it was intended to be used, but I feel like other people thought that perfecting the underlying architecture was more important, even if it meant we shipped with no user-facing functions at all. I have also been hampered by a lack of issues that novices could get involved in, which has been a problem from day one. Most of our issues are just thorny and hard.

Who mentored you in how to be an initiative lead? What did they do? - Cathy Theys

• Angie Byron has always been my ideal of what a community leader should be. She has inspired me immensely over the years.
• David Strauss was really great to work with. While he has been too busy to be involved in the project extensively, he always made time for technical discussions when I needed a sounding board, and has an uncanny way of clearing a path through really thorny problems by looking at them from fresh angles.

Beyond that, I think all the initiative leads have acted as sort of one bug support group, inspiring each other in different ways.

• Gábor Hojtsy is incredible at organizing and getting the word out about his initiative, making it as easy as possible for people to get involved.
• Larry Garfield never gives up on his technical vision and has fought incredibly hard on things I would have long since given up on, including the integration with Symfony which I view as the single most important and revolutionary change in Drupal's history.
• Kris Vanderwater has an incredible breadth of understanding around his subject area, which has allowed him to work fast and identify pitfalls others would have missed and thus cost weeks or months of work.
• The Views team ... I don't even have words. Incredible people accomplishing an impossible task in record time. An amazing demonstration of the power of teamwork.
• John Albin is just one of my favorite people, funny and passionate and driven even while being 18 hours around the world from everyone else.
• Throughout the dev cycle Shannon Vettes has attempted to organize and manage us to work more efficiently, a thankless task if ever there was one.

During initiative efforts, what was the saddest day? What got you through it? The most fun day? - Cathy Theys
I don't know if there was one specific saddest day, but the worst days were the ones where people are actively being jerks to you. When people say your work sucks, that you're ruining Drupal, that the whole system should be torn out of core, or that you're an elitist core dev unconcerned with the needs of users ... I don't know about anyone else but my initial reaction is to give everyone the finger and go live on a farm with 15 cats. One thing Angie has said which I try to always remember is that these reactions are borne out of passion for the project and people who want things to be as good as they possibly can be. This helps conceptually, but it doesn't do much about the raw feeling in your gut.

The most fun days were the code sprints, when you are surrounded by your favorite people in the world hammering away on the big problems to solve. In particular I remember when Alex Pott brought me my custom made CMI shirt at DrupalCon Munich. That was really special.

What are you most proud of? - Cathy Theys
I'm actually really proud that I figured out a way to raise funds for core development which I hope can serve as a model for future initiatives. As I've said many times before, Drupal is in a place where it has all of the business and economic pressures of a large commercial software project, but none of the resources. If we can't figure out a way to scale core development, then the future prospects for the project are grim. There is a lot of interesting work being done to look into this problem and I don't think there is any one answer. Acquia's Large Scale Drupal program is attempting to fund development through subscriptions from large Drupal users. I took a more grass roots fundraising model. I would love to see a world where companies that rely on Drupal are funding people to work on core full time, as a business investment. Hopefully all these and more will lead to a future where developers can focus more on Drupal and less on paying the rent so they can work on Drupal with what is left.

topics: drupalplanet drupal

As my time in the US is rapidly drawing to a close, I thought I should capture the final count of US states that I've visited in the 7 years I've been here. I didn't realise it's been so long since I last did this.

21 states. Not too bad. I'd have liked to have visited Hawaii and Florida. Maybe in my next life.

until a few hours ago I thought there wouldn't be anything for my weekly RC bug report. then I at least found one bug to work on:

• #698582 – isc-dhcp-client: "isc-dhcp-client: prompting due to modified conffiles which were not modified by the user: /etc/dhcp/dhclient.conf"
  some triaging, prepare preliminary patch

let's take the declining number of (easy to fix) RC bugs as a sign that the release is getting closer …

In April of 2012 I bought a ColorHug colorimeter. I got a bit discouraged when the first thing I realized was that one of my monitors needed replacing, and put the the colorhug in a drawer until today.

With quite a lot of help and encouragment from Pascal de Bruijn, I finally got it going. Pascal has written an informative blog post on color management. That's a good place to look for background. This is more of a "write down the commands so I don't forget" sort of blog post, but it might help somebody else trying to calibrate their monitor using argyll on the command line. I'm not running gnome, so using gnome color manager turns out to be a bit of a hassle.

I run Debian Wheezy on this machine, and I'll mention the packages I used, even though I didn't install most of them today.

1. Find the masking tape, and tear off a long enough strip to hold the ColorHug on the monitor. This is probably the real reason I gave up last time; it takes about 45minutes to run the calibration, and I lack the attention span/upper-arm-strength to hold the sensor up for that long. Apparently new ColorHugs are shipping with some elastic.

2. Update the firmware on the colorhug. This is a gui-wizard kindof thing.

   % apt-get install colorhug-client % colorhug-flash

3. Set the monitor to factory defaults. On this ASUS PA238QR, that is brightness 100, contrast 80, R=G=B=100. I adjusted the brightness down to about 70; 100 is kindof eye-burning IMHO.

4. Figure out which display is which; I have two monitors.

   % dispwin -\?

   Look under "-d n"

5. Do the calibration. This is really verbatim from Pascal, except I added the ENABLE_COLORHUG=true and -d 2 bits.

   % apt-get install argyll % ENABLE_COLORHUG=true dispcal -v -d 2 -m -q m -y l -t 6500 -g 2.2 test % targen -v -d 3 -G -f 128 test % ENABLE_COLORHUG=true dispread -v -d 2 -y l -k test.cal test % colprof -v -A "make" -M "model" -D "make model desc" -C "copyright" -q m -a G test

6. Load the profile

   % dispwin -d 2 -I test.icc

   It seems this only loads the x property _ICC_PROFILE_1 instead of _ICC_PROFILE; whether this works for a particular application seems to be not 100% guaranteed. It seems ok for darktable and gimp.

(insert here: I've been to FOSDEM, I got a nasty flu, and other $lame_excuses for the delay in sending out this report)

Dear Project Members, here's the monthly DPL activity report, this time for January 2013.

About the next DPL

This is the last DPL report before the start of the election process for the next term: around early March, about 20 days from now, the Secretary will send out the call for nominations. I'd like to respond (also) here to inquiries I'm receiving these days: I will not run again as DPL. So you have about 20 days to mobWconvince other DDs to run, or decide to run yourself. Do not to wait for the vary last minute, as that makes for lousy campaigns. I'm available to give feedback about my DPL experience to prospective candidates, ... and also to join mobbingWconvincing actions toward potential candidates. Just contact me.

Call for helps

• Last year delegation for Google Summer of Code Admins 1 has expired and the program for 2013 will likely start soon. I'm looking for volunteer admins for this year, to organize Debian activities in the program. If you're interested, please contact me.

• In January we had a couple of related discussions on -project about DFSG §10 and maintaining an authoritative list of DFSG-free licenses. The latter would be an important contribution to the Free Software "political" ecosystem. An ikiwiki-based infrastructure to maintain such a list has been created by ftp-masters but needs to be populated. At this point we need volunteers willing to review licenses already present in main and fill them in. If you're interested, please review the discussion and manifest yourself on debian-dak@lists.d.o, where coordination about this work will happen.

Assets

• The long standing issue of writing a proper (outbound) trademark policy for Debian marks has been completed. I've reviewed on -project outstanding items from the last discussion, and documented how they've been implemented in a new policy draft. Later on, I've published the updated policy draft on our website.

• Complementary to the above, Ian Jackson has summarized the state of the discussion about our (inbound) trademark policy, i.e. what to do when accepting in the Debian archive software subject to trademark. It looks like we are close to conclusion on that front too.

• I've worked with representatives of Debian France, on the shared interest in having the association become a Debian Trusted Organization (per Constitution §9.3). We're not yet ready to start the 2 weeks discussion period to accept the orga as such (see Constitution §5.1.11), but I'd like to do that soon. So I encourage all of you to find out about the association, which is run by well-known project members.

Cloud Images

Work has gone on also on the front of supporting Debian installation in public "clouds". Thanks to Arnaud Patard, Jose Miguel Parrella Romero, Pierre Couzy, and Gianugo Rabellino, we now have Debian testing images for Microsoft Azure. Together with Amazon EC2, this is the second large provider supporting Debian via images maintained by Debian Developers. More providers are welcome, exactly as more hardware/CD vendors shipping Debian are always welcome. If you want to contribute support for other providers just show up on the -cloud mailing list and say so. Some documentation effort in view of Wheezy are in need of help too, in order to let our users know about "cloud" options, see #695681.

DPL helpers

The DPL helpers experiment goes on. We have had 2 more IRC meetings in January (see the minutes). Documentation of the "team" communication channels (mailing list, IRC, Git, etc.) is now available from the DPL wiki page.

Talks

I've given an invited Debian talk at Polytech'Grenoble, as part of a free software event organized for students of local universities. Slides of the talk are available. I'd like to thank Vincent Danjean for the event organization.

Let's release Wheezy now!
Cheers.

PS the day-to-day activity log for December 2012 is available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.201212

The UEFI bootloader that the Linux Foundation have been working on has just been released. That means we now have two signed bootloaders available - this one and shim.
Does this mean Linux distributions can now support Secure Boot?They've actually been able to for a while. Ubuntu shipped with Secure Boot support last October, and Fedora shipped with Secure Boot support in January. Both used Shim rather than the Linux Foundation loader, and Shim's also being used by a variety of smaller distributions. The LF loader is a different solution to the same problem.
Is the Linux Foundation the preferred loader for distributions?Probably not in most cases. One of the primary functional differences between Shim and the LF loader is that the LF loader is based around cryptographic hashes rather than signing keys. This means that the user has to explicitly add a hash to the list of permitted binaries whenever a distribution updates their bootloader or kernel. Doing that involves being physically present at the machine, so it's kind of a pain.
Why use it at all, then?Being hash based means that you don't need to maintain any signing infrastructure. This means that distributions can support Secure Boot without having to change their build process at all. Shim already supports this use case (and some distributions are using it), but the LF loader has nicer UI for managing it.
Any other reasons?Actually, yes. Shim implements Secure Boot loading in a less than entirely ideal way - it duplicates the firmware's entire binary loading, validation, relocation and execution code. This is necessary because the UEFI specification doesn't provide any mechanism for adding additional authentication mechanisms. The main downside of this is that the standard UEFI LoadImage() and StartImage() calls don't work under Shim. The LF loader hooks into the low-level security architecture and installs its own handlers, which means the standard UEFI interfaces work. The upshot is that you can use bootloaders like Gummiboot or efilinux without having to modify them to call out to Shim.
Why doesn't Shim do the same?The UEFI architecture is slightly complicated. The UEFI specification itself defines the upper layers of the firmware, basically covering everything that UEFI applications and operating systems need. It doesn't define the lower layers of a UEFI implementation. Those are contained in the UEFI Platform Initialization spec, and that's what defines the security architecture interfaces that the LF loader hooks into. The problem is that it's completely valid to implement the UEFI specification without implementing the Platform Initialization specification, and if anyone does that then the LF loader will fail.
Can't you try both approaches?Yes, and that's actually pretty much the plan now. I'm working on integrating the LF loader's UI and security code into Shim with the aim of producing one loader that'll satisfy the full set of use cases, and James is happy with this.
Which should I use?Depends. If you want to support gummiboot (and aren't willing to patch it to call out to Shim), you'll need to use the LF loader. If you want to use key-based signing setups to avoid forcing re-enrolment on updates, you'll need to use Shim. If you're somewhere in the middle, you can probably use either. Once we've got the code merged, you won't have to make a choice.

comments

Unfortunately, most of MIBs doesn't meet DFSG since RFC is non-free. However, RFC5378 was released and it says "code components in RFCs are licensed under Simplified BSD license (BSD-3-clause)", See Trust Legal Provisions (TLP) Documents page.

Code components are

ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and classical programming source codeSo, recent MIBs can be included to Debian package :)

But it isn't enough because those RFCs are almost 30/260, 90% are not DFSG-free. And 190/260 RFCs are owned by ISOC and IETF trustee, I hope thay will release old MIBs code in RFCs under DFSG-free license as same as after RFC5378.

As I did not find a nice explanation of Debian version numbers, here some random collection of information about:

All our packages have a version. For the package managers to know which to replace with which, those versions needs an ordering. As version orderings are like opinions (everyone has one), none of them would match any single one chosen for our tools to implement. So maintainers of Debian packages sometimes have to translate those versions into something the Debian tools understand.

But first let's start with some basics:

A Debian version string is of the form: [Epoch:]Upstream-Version[-Debian-Revision]

To make this form unique, the Upstream-Version may not contain an colon if there is no epoch and not contain a minus, if there is no Debian-Revision. The Epoch must be an integer (so no colons allowed). And the Debian-Revision may not contain a minus sign (so the Debian-Revision is everything right of the right-most minus sign, or empty if there is no such sign).

Two versions are compared by comparing all three parts. If the epochs differ, the biggest epoch wins. With same epochs, the biggest upstream version wins. With same epochs and same upstream versions, the biggest revision wins.

Comparing first the upstream version and then the revision is the only sensible thing to do, but it can have counter-intuitive effects if you try to compare versions with minus signs as Debian versions:

$ dpkg --compare-versions '1-2' '<<' '1-1-1' && echo true || echo false true $ dpkg --compare-versions '1-2-1' '<<' '1-1-1-1' && echo true || echo false false

To compare two version parts (Upstream-Version or Debian-Revision), the string is split into pairs of digits and non digits. Consecutive digits are treated as a number and compared numerrically. Non-digit parts are compared just like ASCII strings with the exception that letters are sorted before non-letters and the tilde is treated specially (see below).

So 3pl12 and 3pl3s are slit into (3, 'pl', 12, '') and (3, 'pl', 3, 's') and the first is the larger version.

Comparing digits as characters makes not sense at least at the beginning of the string (otherweise version 10.1 would be smaller than 9.3). For digits later in the string there are two different version schemes competing here: There is GNU style 0.9.0 followed by 0.10.0 and decimal fractions like 0.11 < 0.9. Here a version comparison algorithm has to choose one and the one chosen by dpkg is both the one supporting the GNU numbering and also the one easier supporting the other scheme:

Imagine one software going 0.8 0.9 0.10 and one going 1.1 1.15 1.2. With out versioning scheme the first just works, while the second has to be translated into 1.1 1.15 1.20 to still be monotonic. The other way around, we would have to translate the first form to 0.08 0.09 0.10, or better 0.008 0.009 0.010 as we do not know how big those numbers will be, i.e. one would have to know beforehand where the numbers will end up, while adding zeros as needed for our scheme can be done with only knowing the previous numbers.

Another decision to be taken is how to treat non-numbers. The way dpkg did this was assuming adding stuff to the end increases numbers. This has the advantage to not needing to special case dots, as say 0.9.6.9 will be bigger than 0.9.6 naturally. I think back then this decision was also easier as usually anything attached was making the version bigger and one often saw versions like 3.3.bl.3 to denote some patches done atop of 3.3 in the 3th revision.

But this scheme has the disadvantage that version schemes like 1.0rc1 1.0rc2 1.0 do not map naturally. The classic way to work arround this is to translate that into 1.0rc1 1.0rc2 1.0.0 which works because the dot is a non-letter (it also works with 1.0-rc1 and 1.0+rc1 as the dot has a bigger ASCII number than minus or plus).

The new way is the specially treated tilde character. This character was added some years ago to sort before anything else, including an empty string. This means that 1.0~rc1 is less than 1.0:

dpkg --compare-versions '1.0~rc1-1' '<<' '1.0-1' && echo true || echo false

This scheme is especially useful if you want to create a package sorting before a package already there, as you for example do want with backports (as a user having a backport installed upgrading to the next distribution should get the backport replaced with the actual package). That's why backport usually having versions like 1.0-2~bpo60+1. Here 1.0-2 is the version of the un-backported version; bpo60 is a note that this is backported to Debian 6 (AKA squeeze) and the +1 is the number of the backport in case there are multiple tries necessary. (Note the use of the plus sign as the minus sign is not allowed in revisions and would make the part before a part of the upstream version).

Now, when to use which technique?

• Usually try to stick to the upstream version if it is sane. (With the exception of data based versions, as experience shows upstreams later change their mind, so a version of 20130210 is best translated to 0.20130210 in order to have a future 1.0 sort higher).
• If there are some suffixes in the version that denote a "before", prefix them with a tilde.
• Compare a version to your last version and put zeros or .0 at the end (or the ends of parts) where necessary to increase them.

Some common examples:

• You want to package 2.0 but you need to repack the .orig.tar because it contains a file with some non-free license (for example no license at all). Then you can call it 2.0~dfsg-1. If the file is later relicensed, you can do a 2.0-2 with the original file which sorts higher.
• You need to repack 2.0 but it was already in the archive. then you can do 2.0+dfsg-1 as this is higher. (using the plus has the advantage that you can later use the 2.0.0 trick if the file is relicensed, while the older 2.0.dfsg-1 made this impossible). (One can also use -dfsg-1 here, but + might be easier to parse for humans).
• You package a git snaphost of a version 2.0 not yet released, then you can use 2.0~gitXYZ-1
• You package a git snapshot of upstream doing some works on top of 1.9, then you can use 1.9+gitXYZ-1

Yesterday, I launched the contest for prediction of the day Debian bugs #800000 and #1000000 will be reported.

For bug #1000000, this is the second set of bets after those we placed back in 2008 when bug #500000 was reported. I then proposed that we have different bets, refined each time. That gives an interesting light on how people estimate the bug report rate (and, to some extent, the project's life).

Have you bet already?

You don't need to be a DD or a DM in order to bet. Just someone wanting to have some fun with Debian contributors. Easy and costless.

With kids in the house, one challenge is getting them to sleep during the night and wake up when it is morning. I mean, when I believe it is morning, and not two hours earlier. In our household we have decided that 07:00 is the turning point, but getting the kids to sleep until 07:00 is a small challenge every day. They have adapted quite well, and rarely wake up at 05:00 any more, but some times wake up at times like 05:50, 06:15, 06:30 or 06:45, and it is hard to put the awake one to bed again without disturbing and waking the rest. And I understand perfectly well that they fail to sleep until 07:00 some times, as there is no way for them to know if it is before or after the magic moment without coming and asking us parents.

But yesterday I came up with a method to solve this problem. It involve home automation. A few years ago I bought a Tellstick and RF switches at the local Clas Ohlson shop, allowing me to control lights and other electrical gadgets using my Linux server. When I moved from the old flat to a small house, I put away all this equipment as most of the lighting in the house was not using wall sockets and thus not easy to connect to the gadgets I had. But recently I bought a Tellstick Net to be able to read sensor input as well as control power sockets. I want to control ovens in the basement to avoid the pipes to freeze, and monitor the humidity to detect flooding. The default setup for Tellstick Net is to be controlled by the vendor web service, which to me is a security problem, but it is also possible to build ones own firmware with local access instead of being controlled by a Swedish company, thanks to the release of the GPL licensed firmware source code. I plan to get that running before I let it control anything important. But while working on this, one idea to make it easier for the kids came to me yesterday. We can set up a night light controlled by the computer, and turn it automatically on at 07:00. The kids can then check the light in the morning to know if they are supposed to get up or not. They joined me in setting everything up, and I repeated the concept several times before bed times to make sure they remembered to check the light before getting up in the morning.

We tested it this morning, and all the kids stayed in bed until after 07:00, and every one of them commented on the fact that the "morning light" was turned on and signalled that the morning had arrived. So this look like a success, and I am excited to see how this develops the next few days. :) I really hope this can allow us all to sleep a bit longer in the morning.

A nice advantage of this setup is that we can remote control when to tell the kids to get up. We do not have to wait until 07:00, and can also delay it if we want to.

Leaving for Finland in less than 5 hours and my GPS keeps acting up, external disks refuse to be mounted, and copying data off of SD cards results in I/O errors...

The SD card I/O errors are apparently caused by my still-half-broken ThinkPad X201 which never got fixed properly. To be specific, the internal card reader is acting up.

But to get back to the GPS and my external drives... I had feared my ThinkPad was in its death throes when I decided to try another cable. Lo and behold, everything (other than my built-in SD card reader) started to work all of a sudden.

This is the third time I've had issues with random USB cables. For Micro USB I decided to only use ones that came packaged with a phone or similar as those tend to be high quality.

If anyone has a suggestion about where to source high-quality Mini USB cables after returning from Finland, please let me know.

In this blog I will drive you through setting up Drupal project instance on Ec2 micro instance of AWS and setting up ftp on your Drupal instance. Before this, of course you have to register with AWS which is straightforward.

So, what we will understand from this blog:-

1       Choosing OS and assigning some security rules on our instance.

2       How to access our instance and play around it?

3       Setting up LAMP on our AWS micro instance

4       Setting up ftp on AWS micro instance

5       Managing your Drupal project using ftp connection using filezilla

Once you are registered with AWS you have to login into your account. Among the AWS services just click on EC2 link which is nothing but a virtual server in the cloud. It will redirect you to EC2 dashboard where you can manage your entire instance. Now for creating new instance follow below steps:-

1       Just click on Launch instance select Classical wizard and click continue.

2       Now you have to select Amazon Machine Image (AMI) from one of the tabbed lists below by clicking its Select button.

3       Let’s say we select Ubuntu 12.04 LTS.

4       Next leave default settings except just select micro instance from the instance type because it’s free to use and click continue.

5       Next again leave default setting and click continue.

6       Next again leave default setting and click continue.

7       Now you have to give name of your key and value. I recommend give key value name more sensible with your project and click continue.

8       Now select creating a new key pair as we are new we don't have existed key pair. Give name to your key pair file it should make sense with regards to your project. Download your keypair.pem file and save at a safe place because we need this file later.

9       Next select create a new security group. Here we will assign some security rule and enable http, SSH and ftp connection to our instance. Http port range is 80 SSH port range is 22, for ftp select custom TCP rule and give port range 21-22. About source you can give any IP range as you need or just leave default for now.

10    Just click continue and launch instance. Your instance will be running in some time as AWS will take some time to run your instance.

Now our EC2 micro instance is running. You can check out from your dashboard.

Now we setup LAMP in our Ubuntu 12.04 LTS instance. For this we access our Ubuntu instance from terminal and setup LAMP in that. Below are the steps to access and setup your LAMP in Ubuntu 12.04 LTS instance.

1       Open your terminal and go to the directory where you stored your key pair file .pem file then run this command into your terminal sudo SSH -i file_name.pem Ubuntu@ec2-40-90-193.compute-1.amazonAWS.com .

2       It will give you Ubuntu prompt in your terminal. You can understand like this that now you are logged in into your Ubuntu machine and you can do anything over there. The main thing here is you have to run all commands with "sudo" or as a root user which works on file system directory.

3       In order to setup LAMP we will install three packages in it . Run these command from terminal :-

●       sudo apt-get install apache2

●       sudo apt-get install mysql-server

●       sudo apt-get php5 php-pear php5-mysql php5-suhosin

That's it your LAMP environment is ready. You can check it by navigating your instance url that is for example look like this ec2-43-23-32.compunte.AWS.com in browser. It will give you message Localhost is working something like that.

Till here we got our LAMP environment running into our EC2 instance. Now we install our Drupal 7 instance in it. Here in Ubuntu instance we don't have any ftp connection with ftp client or server. So we can use SCP for taking Drupal tarball from our local instance or we can use wget utility of linux to download Drupal from its url. Below are steps to install Drupal 7

1       cd /var/www/

2       wget  http://ftp.Drupal.org/files/projects/Drupal-7.12.tar.gz

3       tar xvf Drupal-7.12.tar.gz

4       mv Drupal-7.12 Drupal

Below is a link which can tell you how to install Drupal in linux . Just follow all those steps.

http://Drupal.org/documentation/install/developers

When you setup with your mysql database and Drupal configuration then just browser link like for example:

http://ec2-43-23-32.compute-1.amazonAWS.com/Drupal/

It will take you to your Drupal site.

Now we will see how to setup ftp on Drupal instance .Why we need ftp for Drupal instance. In order to work on Drupal we have to use many modules, themes and libraries. So we have to upload those things on site. We can achieve this with SCP but that will be more difficult because you have to do via command line.  Here we will see how to setup Filezilla ftp on Drupal site which is on AWS EC2. Below are the steps to setup filezilla as a ftp client.

1       Install filezilla  into your local system :- sudo apt-get install filezilla

2       Now open filezilla click on file > site manager

3       Enter the details of your site here like :-

●       HOST - ec2-43-23-32.compute-1.amazonAWS.com

●       Port- 22

●       Protocol - SFTP(SSH file transfer protocol )

●       Logon Type - Normal

●       User - Ubuntu

●       Password - Ubuntu . Then click on ok don't click on connect this time.

1       Now click on Edit> Settings > SFTP and addkeyfile. Navigate your .pem file here. It will ask you to convert .pem file just select ok. Now filezilla have your instance credentials to connect and everything is good to connect to your Drupal instance.

2       Now click on file > site manager > connect

Now you can transfer all files from your local to Drupal instance.

 

I hope you enjoyed this blog. Please feel free to comment and send queries to me.

 

Reference:-

https://AWS.amazon.com/documentation/

http://library.linode.com/lamp-guides/Ubuntu-12.04-precise-pangolin

 

Thanks for reading draft of this. Appreciate your help and contribution.

I bricked a Samsung laptop today. Unlike most of the reported cases of Samsung laptops refusing to boot, I never booted Linux on it - all experimentation was performed under Windows. It seems that the bug we've been seeing is simultaneously simpler in some ways and more complicated in others than we'd previously realised.

So, some background. The original belief was that the samsung-laptop driver was doing something that caused the system to stop working. This driver was coded to a Samsung specification in order to support certain laptop features that weren't accessible via any standardised mechanism. It works by searching a specific area of memory for a Samsung-specific signature. If it finds it, it follows a pointer to a table that contains various magic values that need to be written in order to trigger some system management code that actually performs the requested change. This is unusual in this day and age, but not unique. The problem is that the magic signature is still present on UEFI systems, but attempting to use the data contained in the table causes problems.

We're not quite sure what those problems are yet. Originally we assumed that the magic values we wrote were causing the problem, so the samsung-laptop driver was patched to disable it on UEFI systems. Unfortunately, this doesn't actually fix the problem - it just avoids the easiest way of triggering it. It turns out that it wasn't the writes that caused the problem, it was what happened next. Performing the writes triggered a hardware error of some description. The Linux kernel caught and logged this. In the old days, people would often never see these logs - the system would then be frozen and it would be impossible to access the hard drive, so they never got written to disk. There's code in the kernel to make this easier on UEFI systems. Whenever a severe error is encountered, the kernel copies recent messages to the UEFI variable storage space. They're then available to userspace after a reboot, allowing more accurate diagnostics of what caused the crash.

That crash dump takes about 10K of UEFI storage space. Microsoft require that Windows 8 systems have at least 64K of storage space available. We only keep one crash dump - if the system crashes again it'll simply overwrite the existing one rather than creating another. This is all completely compatible with the UEFI specification, and Apple actually do something very similar on their hardware. Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here - it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.

This is pretty obviously a firmware bug. Writing UEFI variables is expressly permitted by the specification, and there should never be a situation in which an OS can fill the variable store in such a way that the firmware refuses to boot the system. We've seen similar bugs in Intel's reference code in the past, but they were all fixed early last year. For now the safest thing to do is not to use UEFI on any Samsung laptops. Unfortunately, if you're using Windows, that'll require you to reinstall it from scratch.

comments

I can't begin to tell you what a joy these last two days in Sydney have been. My first DrupalCon was a whirlwind of acronyms and goodwill and I couldn't have had a better time, or packed my head with more Drupal knowledge. One of the most impressive parts of the conference has been how welcoming each and evey indidivual is.

I can't begin to tell you what a joy these last two days in Sydney have been. My first DrupalCon was a whirlwind of acronyms and goodwill and I couldn't have had a better time, or packed myhead with more Drupal knowledge. One of the most impressive parts of the conference has been how welcoming each and evey indidivual is. To a person, community members have welcomed new initiates into the fold, creating ana amzing spirit of "can-do" and collaboration.

I can't begin to tell you what a joy these last two days in Sydney have been. My first DrupalCon was a whirlwind of acronyms and goodwill and I couldn't have had a better time, or packed myhead with more Drupal knowledge. One of the most impressive parts of the conference has been how welcoming each and evey indidivual is. To a person, community members have welcomed new initiates into the fold, creating ana amzing spirit of "can-do" and collaboration.

Yesterday I made a very bad assumption that's wasted a day of my time. Today, while I wait to hear back on where I went wrong, I thought I'd write up a little warning to my future self.

First, a bit of background: It's very unusual for me to start a project at the beginning. Most of the time when I'm working on a project it's doing little fix-its for a client as part of a larger training contract. Sometimes it's simplifying things to eliminate the need to train users on complex tasks; sometimes it's tweaking a theme to accommodate the way content is being placed into the site now that it's a Real Live Web Site. Regardless of what I'm doing, I seem to spend a lot of time fitting into someone else's work flow. I'm used to it, and usually I enjoy the discovery process.

Yesterday when I hopped onto a project, I was thinking about checklist of jobs (images in the sidebar needed to float: left, lightbox module needed to be installed for a gallery, verify backups are working properly)...but I wasn't thinking about the fact that this project had already had multiple rounds of developers working on it...potentially each set having their own preferred workflow. In retrospect, this is what I *should* have done right from the beginning (and all at once) instead of only doing little bits and pieces over the course of the day while pausing to bang my head against a wall.

Conditions:

• The project has had more than one developer/development team working on the project before you start.
• You only have FTP access to the server (yes, seriously).
• The only way for you to pick up the files you need to be working on is by downloading them via FTP from the live server to your work station.

How I *should have* started this project:

1. Look in the theme folder for documentation about how the theme was built. If there is none but there are preprocessor files (LESS or SASS), stop immediately, and ask to speak with the previous developers. (I assumed I could just muscle through it without docs...because I'm psychic and code is self-documenting. HINT: turns out this actually just means that I'm psychotic, because CSS preprocessors are totally NOT self-documenting....so you can probably tell that I skipped this step?)
2. Download as many relevant files as necessary to run the site locally (in this case it was the entire site + a B&M snapshot of the database).
3. Put everything into version control. Do not pass go. Do not make changes until everything is in version control. (Did this. /me pats self on the back.)
4. (This is where I went wrong.) Create a new branch and recompile the CSS files from the source preprocessor files (e.g. SASS or LESS).
5. Assuming you're using Git for your version control, run the command:
   $ git difftool mynewbranch..master
   Look for differences between the two branches.
6. If there are any differences in Step 5, stop immediately. There is a problem. Either you are missing the source files (i.e. .scss or .less), OR someone has been editing the CSS files directly. Stop and find out which problem you're dealing with.

Possible scenario #1: If you're missing source files: easy! Once you've got the right files you can continue to take advantage of all the awesomeness you get with a CSS preprocessor. Of course once you get the source files, you should repeat steps 4-6 until you can get your output to match what's on the server.

Possible scenario #2: If one of the developers along the way has been editing the CSS files directly: easy! Delete all of the source files from the preprocessor and do your work like it was 1999. Well. Except with more awesome version control than what was possible back then. Of course if you love to punish yourself, you can carefully inspect the live CSS files and pull out the hand-edits and put them back into the preprocessor files where they belong. Chances are very good that your client won't want to pay for this step. Only you can decide if it's worth eating the time costs.

So there we have it: a note to my future self about making assumptions and jumping into the middle of a problem. Do you have your own process for dealing with inherited projects? I'd love to hear any tips you'd like to share.

PS @rupl over at Four Kitchens helps to solve this problem by including a WARNING file in his SASS source files. You can read it here. I think it's brilliant. and so does fubhy.

Only a few minutes too late; this blog post is sponsored by the word "meh"...

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 791
  • Affecting wheezy: 212 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 129 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 33 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 4 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 93 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 83 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 53 bugs are in packages that are unblocked by the release team.
      • 30 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83)

Graphical overview of bug stats thanks to azhag:

Am I the only one who's disappointed with the route Mozilla's taking and left wondering what the direction is? First they killed off the development of Thunderbird because, as we all know, people mainly use webmail these days. Then they presented us their view that the big Certificate Authorities are too big to fail, as CAs gravely violated our trust (c.f. Trustwave and their MitM authority). And "now" they're also blocking the introduction of new formats into their browser because they cannot be the one who innovates. Instead Microsoft and Apple obviously need to take the lead in introducing a format into their browsers because otherwise it wouldn't be useful. Even though it's safe to say that Chrome and Firefox make up for more than half of the desktop browser market share. It might be that Chrome's nibbling from Firefox's, still IE seems to be in decline and Safari is rather a further mention than something many people would care strongly about.

There were of course some valid reasons for not supporting WebP yet. But most of them got fixed in the meantime and all we hear is the referal to proprietary vendors who need to move first. If I'd want to depend on such vendors I'd go with proprietary operating systems. (Having to deal with hardware products of proprietary vendors at $dayjob is enough.) So what's up Mozilla? The solution is to ignore your users and tag bugs with patches wontfix?

The only real advantage of Firefox over Chromium these days is the vast amount of plugins and extensions (e.g. Pentadactyl, for which there is no real equivalent available). Another sad fact is that you need to pull Firefox from a 3rd party repository (even though packages are coming from the 2nd party) to get a current version onto your Debian system to work with the web. But then it's not Mozilla who's to blame here. Maybe we should've introduced one Iceweasel version that's allowed to have reverse-dependencies and one that cannot.

(This post might contain hyberboles, which should be considered as such.)