Originally posted to the ubuntu-devel mailing list (archive).
I thought it was about time that I shared my own merge workflow, as I think it is quite different from most other Ubuntu developers. I'm an advanced git user (even a fanatic, perhaps), and I make extensive use of git's interactive rebase feature. To me, an Ubuntu package merge is just a rebase in git's terminology, and in this case I use git as nothing more than an advanced patchset manager.
I find my workflow allows me to handle arbitrarily complex package merges - something I've not been able to do any other way. And once I've merged a particular package with this workflow once, future merges take me far less time because checking individual broken down diffs is even quicker still.
This workflow may be useful to others, but probably only if you are already very familiar with git's interactive rebase feature. I don't suggest that you try to use this workflow without first being extremely comfortable with this (for example, working with git while not attached to a branch).
On the other hand, if you are very familiar with rebasing in git, then like me you may find this workflow to be the logically obvious way of doing package merges in Ubuntu. I wonder if anybody else feels like this.
In my mind, this write-up may seem complex, but I think this complexity is just a reflection of the reality of what's really going on when one does an Ubuntu package merge. But by using git, the complexity gets moved to the complexity of doing git rebases, and this is something that only needs to be learnt once.
I'm also interested to know how this fits in with other recent work in using git with Debian packaging. My impression is that it doesn't fit so well, because in Ubuntu we need to deal with all Debian packages, including those not managed in git in Debian. Comments, feedback and criticism are all appreciated.Considering merges Merge essentials
Let's me first consider what an Ubuntu package merge really is. Existing Ubuntu developers probably want to skip this section.
First, some terminology. For a given package that needs merging, Ubuntu has applied some set of changes from the Debian version it is based on. So we have some Debian version from which Ubuntu diverged (the base version), the latest Debian version, and the current Ubuntu version. The old Ubuntu delta is the diff between the base version and the current Ubuntu version. The new Ubuntu delta will be the diff between the latest Debian version and the newest Ubuntu version that we will upload.
To do a package merge, we must re-apply all of the Ubuntu delta that is still required onto the latest Debian version. On the way, we might find that some changes are no longer required, some changes that have to be modified to work against the latest Debian version, and may perhaps need to introduce new changes.
We expect the result to contain a changelog entry summarising what remains in the Ubuntu delta, what was modified or dropped, and any new changes that were made.The logical delta
So when doing a package merge, it is essential to understand what exactly logically constituted the previous Ubuntu delta, so that we can identify what changes are no longer required, how we might need to modify some previous changes, and what new changes may be needed.
When the Ubuntu delta is relatively trivial, checking all of this by examining the diffs produced by merge-o-matic is normally fine. Even if the delta consists of a few changes, they are easy to identify and understand in a small diff.
But when the delta is larger, I find it far more difficult to follow it all in my head at once, particularly when multiple logical changes apply changes to similar overlapping areas across multiple files. This is, of course, yet another good reason why we should be sending our changes to Debian and keeping our delta small, but in some cases this maintaining a large delta is necessary, at least in the short term.
In following my workflow, I have come across a number of merge errors made by multiple Ubuntu developers, where the claimed delta in the changelog for a merge did not match the delta itself. This suggests to me that developers are not always checking and understanding the delta as they should.Applying git
git makes it easy to take a large "squashed" diff and split it into multiple constituent logical parts. This is what I've been doing here. Once split like this, I use git rebase to apply the logical parts back on to the latest Debian version. This allows me to examine each logical part of the delta separately, modifying or removing them as required. When I'm done, it is easy to review each part, and even compare against the previous version. And I can save the broken down parts for the next merge.
So broadly, my workflow for packages with complex deltas is:
Import the base, latest Debian and all Ubuntu revisions since the base version into a git repository.
Break down the Ubuntu revisions into constituent logical parts using git rebase. Or If I followed this workflow last time, then I just run git am against what I saved previously. One might consider this step to be the opposite of a "squash" operation. "Unsquash", if you like.
Rebase onto the latest Debian version, dropping any metadata changes (eg. debian/changelog changes and update-maintainer) and amending the delta on the way as required.
Update debian/changelog, apply update-maintainer, review, test and upload.
Run git format-patch to save my set of logical changes for next time.
To help with these tasks, I have written some tooling that I use. I've pushed these to git://github.com/basak/ubuntu-git-tools.git:
xgit is a wrapper around setting GIT_WORK_DIR and GIT_DIR, so that I can operate with a .git directory that is outside my working tree. This means that dpkg-buildpackage, dpkg-source etc. don't need to know or care that I'm using git, and I can run git commands without necessarily being in my working tree.
git-dsc-commit imports a source package by just committing and tagging a new commit (in the current branch, or detached HEAD) that is exactly the unpacked source package.
git-merge-changelogs is a wrapper around dpkg-mergechangelogs that takes its input changelogs from debian/changelog files found in specific git revisions.
git-reconstruct-changelog extracts commit log messages from a set of git commits and writes them to debian/changelog.
These tools are incomplete. I didn't know where I was going when I wrote them, and there is certainly scope for more automation. I addressed the biggest needs first, and what is remaining costs me little time so I have not spent time to automate any more yet.Importing revisions into a git repository
I generally start with:# Import relevant source packages. This could probably be automated # with the help of grab-merge. pull-debian-source -d <package> pull-debian-source -d <package> <base-revision> pull-lp-source -d <package> pull-lp-source -d <package> <version-since-base> # 0 or more times # Set up git repository for this merge . /path/to/xgit.bash xgit mkdir git gitwd # git = moved .git directory; gitwd = working directory # without .git git init
Next I import the sources package into git, modelling the Ubuntu divergence by having the new Debian package have a parent commit of the base Debian package, and the Ubuntu packages on a separate branch also rooted at the base package:git dsc-commit <base-revision .dsc> git dsc-commit <latest-debian-version .dsc> git checkout <base-revision tag> git dsc-commit <Ubuntu version since base .dsc> # 0 or more times git dsc-commit <current Ubuntu version .dsc>
git-dsc-commit automatically tags revisions, but since ~ and : are invalid in git tag names, _ is substituted. So right now, I have to correctly name the tag that git-dsc-commit used in the git checkout call above.
git-dsc-commit commits "3.0 (quilt)" source packages without patches applied. I prefer to work with quilt patches directly if they need refreshing or other changes made. Otherwise I just get noise in .pc/, and it is difficult to rationalise any changes made back into the separate quilt patches they belong to.
Note that git-dsc-commit commits the entire source package tree exactly as it is. It is not like a normal commit, where logically you're committing a change. Underneath, git commits are really snapshots, not changesets, so git-dsc-commit just commits a snapshot identical to the source package. For example, if you have made a change, then from your point of view git-dsc-commit will effectively commit the reverse of that change if necessary so that the result looks identical to the source package you're importing.
When this step is done, I have a git repository with imported source packages in commits that mirror the Ubuntu divergence.
I find this point very useful in itself, since I can now easily compare things. If I want to know if two files specific are different between specific Debian and Ubuntu source package versions, or how they are different, or want a list of files in a particular debian/ subdirectory that have changed, then I just ask and git will tell me. Querying for changes between arbitrary revisions and files is something that git does very well.Breaking down the delta into logical parts
If I already perfomed this for a previous upload, then a simple git am against my saved work allows me to skip this step. I can verify the result by diffing against the imported squashed equivalent.
I won't go into how to use git rebase here; I assume you know that. For every commit I edit, I generally git reset HEAD^ back to the previous version, so all changes made in this particular source package version become unstaged. Then I go through the changelog entries one by one, staging only those changes (often using git add -p) and committing them one by one.
The point in this step is to reflect what was logically present in an already-uploaded source package, errors and all. Some notes:
I generally aim to end up with commits that follow the same order as the entries in debian/changelog.
git log --decorate is useful here, since all the imported source packages are tagged.
I make the commit message for each logical change identical to its entry in debian/changelog where possible, including leading whitespace and the *, - or + bullet points.
I make the debian/changelog file change for the entire upload a separate commit at the end (most recent) for each source package version.
If update-maintainer was run and thus modified debian/control, or VCS-* entries changed to XS-Debian-VCS* entries, I put this in a separate logical commit with an "ubuntu-meta" commit message.
Quilt patches that exist only in Ubuntu involve logical commits that add the file in debian/patches/ and add a single line to debian/patches/series. Patches remain unapplied. Similarly, for other types of quilt patch modification, only changes to debian/patches/ end up in the commit.
This is the stage that I often find errors in the previously documented changelog. Where this happens, I just figure out what happened logically and try and commit something that matches. If debian/changelog specified a change that was actually not present, it doesn't get a logical commit, but the commit with the full debian/changelog change does include the erroneous text.
When done, it is trivial to run git log -p and check that all commits match their description. I also run git diff <tag> and verify that the result is still identical to the source package import we started from by checking that the reported diff is empty.Rebasing onto the newest Debian version
Again, this should be straightforward to follow for git rebasers, and I assume you know how to operate the details.
First, I drop any previous commits that changed debian/changelog only, as well as any "ubuntu-meta" commits. Then something like git rebase --onto <new_debian_version> <base_version> does the job. If there are conflicts, they can be handled during the rebase in the normal way.
While I'm doing this, I take notes of the changes I made so that I can write up the changelog later. Where possible, I directly squash these notes into the commit messages in the form of the future changelog entry. If the rebase step drops commits because they have been applied in Debian, then it's important to note these. git doesn't specifically point these out except as they scroll past.
Next, I check that all quilt patches apply and are still correct, and do any further editing required. This includes test builds, running dep8 tests, etc. As I do this, I use git rebase extensively again, squashing the commits down into their original places and updating commit messages (which will be the basis of the future changelog message).
When doing test builds at this stage, I don't want to overwrite the Debian source package in my parent directory, so I do have to insert a temporary changelog entry or something. I haven't worked out a strong pattern for this yet; sometimes I complete the remaining steps first to avoid this issue, and rebase and squash any changes I needed back in. git-buildpackage can probably help me here; I haven't looked into integrating it into my workflow at this step yet.
It is important to note that this stage really uses git as an advanced patchset editor. I am editing the patchset itself. I specifically do not add new commits to the end, except temporarily before I squash them down again.
When this step is complete, my commits start from the imported latest Debian source package version, and show the logical delta (one logical entry per commit) that will form the new Ubuntu upload. Changelog entries exist only as commit messages; debian/changelog is not modified at all yet.Updating the changelog
Since an Ubuntu merge is expected to include a merged changelog, adding to the Debian changelog will not do; we need to import all previous Ubuntu changelog entries too.
Most of this could probably be automated more.Merging old changelog entries
My tool git-merge-changelogs does this. Calling it as git merge-changelogs <base version tag> <latest Debian version tag> <current Ubuntu version tag> fetches the changelog entries out of the imported source packages, calls dpkg-mergechangelogs and writes out debian/changelog in the working tree. Then I usually just git commit -mmerge-changelogs debian/changelog to commit this step.Automatically creating new changelog entries
Next, I need to add the changelog entry for the merge itself. I do this with my tool git-reconstruct-changelog. Calling git reconstruct-changelog <latest Debian version tag> inserts the commit messages into debian/changelog. Then I usually run git commit -mreconstruct-changelogs debian/changelog to commit this step.Finishing the changelog
Reconstructing the changelog will miss out the merge introduction, and also will fail to mention any dropped changes since there are no commits that correspond to these. Consulting my notes from earlier, I edit up the changelog manually, fix any whitespace/wrapping issues, release it with dch -r '' and commit it with git commit -mchangelog debian/changelog.Other metadata
Next I run update-maintainer, and then git commit -mubuntu-meta debian/control to commit this step. Any VCS-* to XS-Debian-VCS-* type translation goes into this commit, too.Uploading
That's it. Since my working tree has no .git directory, I can just run debuild as usual to create my source package ready for upload.
If there's a problem and I need to go round again, it's quite easy to squash a change in where I need it, re-run git reconstruct-changelog and edit the changelog, and rebuild the source package.Saving the logical delta for future use
After upload, I make sure to save my logical delta by using git format-patch. This allows me to reconstruct it quickly the next time I merge the same package. There is no need for me to keep the git repository around.
The patchsets I've saved this way don't always follow what I've written here precisely, as I have taken a while to settle on it, and I still deviate on a whim. It doesn't really matter though; by separating out logical changes into separate commits, when I look at it the next time it's easy to mould a patchset into whatever form I will need.Example of use
This workflow allows me to handle any merge that is thrown at me, however complex it may be. When I merged mysql-5.5 last cycle, it had diverged considerably from Debian, but with much cherry-picking going both ways. The sheer complexity of it, and the time necessary to figure it all out, had put off developers before me from sorting it out. Instead, some changes kept getting cherry-picked and other changes were getting lost.
When I reconstructed the logical set of changes made in Ubuntu since we diverged, I ended up with a branch of around 120 commits (IIRC). With extensive rebasing, I ended up reducing this to 8 logical changes to send to Debian, and just 4 commits remaining in the Ubuntu delta. Importantly, I did this in a way that I could be confident about the results, since I could easily verify my work.
I'm now going to do the same for mysql-5.6, and I'm much happier doing it knowing that I can manage it this way.Future
I have a local store of these logical delta patchsets. Currently this is for apache2, facter, nginx, php5, subversion and vsftpd. If others want to follow the same workflow, we should work out some way to share them.
And if many people find a git repository that follows Debian and Ubuntu source packages useful, then perhaps we should set one of those up to share, too, to save doing the import step.
I did have some code that auto-imported into git from UDD bzr, and cached, so I could just git clone a UDD branch, but this is limited to UDD's package import reliability, so I stopped using it. My git-dsc-commit tool should always work. I have had to fix a number of edge cases, but I am not aware of any that are outstanding.The End
What I think I have here are the pieces needed to make merging Ubuntu packages with git work. The workflow itself doesn't matter so much - you can mix and match, and you should be fine.
Because it’s an awesome release in many fronts, and it’s now in Utopic and the PPAs. It’s been especially significant for me as it includes some patches of my own :) (thanks to Caolán who kindly reviewed them).
I loved this comment from an LWN reader:
I also just noticed that legend Michael Meeks has mentioned me in his epic blog post detailing the work that all the different LibreOffice teams have been doing during the last six months (definitely check it out if you haven’t yet). The mention was cool, but I only played a small part on making this release the best yet: everyone, from developers, bug triagers and translators to marketers and designers, has done an excellent job. The LibreOffice community is a delightful place to be, and we need your help.
This has been missing for a few weeks, but it's back!Why is CSP Failing?
Why is CSP Failing? Trends and Challenges in CSP Adoption. Despite being an "academic" paper, this actually has a lot to offer about why one of the most effective defenses against XSS isn't yet getting widely implemented, and what the implementation costs and strategies are.Safari Bites the Dust
Ian Beer of Google Project Zero recently popped Safari and then proceeded to pwn OS X. This post dives into exploiting a WebKit unbounded write bug, and makes it obvious just how many hoops an attacker needs to go through compared to the 'buffer overflow to overwrite EIP' bugs of the 'good old days'. It's a great read, especially if you're new to browser/client exploitation.Blackhat & DEF CON Tips
It's that time of year again -- the annual Las Vegas pilgrimage for hackers. As usual, Chief Monkey over at Toolbox.com has some protips for first time attendees. (Or reminders for seasoned vets!)
The first point release of 14.04 just came out a few days ago and many LTS users waited for this to upgrade from 12.04 – in fact do-release-upgrade only offers the LTS to LTS upgrade after the first point release for stability reasons. So we thought this would be the perfect time to do a quick writeup of a few things to do after upgrading your system. User configuration isn’t updated and installed applications aren’t removed when upgrading and that’s a good thing: Upgraders will not have to restore their customizations and their system will mostly look as before.
However, for those of you who want to get closer to the default setup of Xubuntu 14.04 Trusty Tahr, here go five easy steps you can quickly follow to that end.
- Light Locker has replaced XScreenSaver. Light Locker uses LightDM to lock the screen, merging the functionality of the login screen and the lock screen. Having both applications installed at the same time may produce bugs or regressions, so it is recommended to remove XScreenSaver. To remove it just run the following command in a terminal window: sudo apt-get remove xscreensaver
If you would rather see a screensaver instead of an improved screen locker, you can alternatively remove Light Locker and keep XScreenSaver.
- MenuLibre, an advanced menu editor that provides modern features in a clean, easy-to-use interface, with full Xfce support, replaces Alacarte for menu editing. To remove Alacarte open a terminal window and run the following command: sudo apt-get remove alacarte
- Due to a duplication of functionalities, the Xubuntu Team decided to favor Ristretto for photo viewing, and drop gThumb. To remove gThumb from your system run in a terminal window: sudo apt-get remove gthumb
- As Whiskermenu is now the default menu in Xubuntu, swap out the old application menu with it. Just right click the top panel and navigate to Panel > Add New Items, then select “Whisker Menu” and click “Add”.
After that, and to remove the old application menu, just right click on its icon and choose the “Remove” option.
- All PPAs are automatically disabled when you upgrade, so you’ll have to re-enable release-independent PPAs manually, taking in consideration that you’ll have to check if the old PPAs work with the new Xubuntu version.
This is my monthly summary of my free software related activities. If you’re among the people who made a donation to support my work (548.59 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.Distro Tracker
Now that tracker.debian.org is live, people reported bugs (on the new tracker.debian.org pseudo-package that I requested) faster than I could fix them. Still I spent many, many hours on this project, reviewing submitted patches (thanks to Christophe Siraut, Joseph Herlant, Dimitri John Ledkov, Vincent Bernat, James McCoy, Andrew Starr-Bochicchio who all submitted some patches!), fixing bugs, making sure the code works with Django 1.7, and started the same with Python 3.
I added a tox.ini so that I can easily run the test suite in all 4 supported environments (created by tox as virtualenv with the combinations of Django 1.6/1.7 and Python 2.7/3.4).
Over the month, the git repository has seen 73 commits, we fixed 16 bugs and other issues that were only reported over IRC in #debian-qa. With the help of Enrico Zini and Martin Zobel, we enabled the possibility to login via sso.debian.org (Debian’s official SSO) so that Debian developers don’t even have to explicitly create their account.
As usual more help is needed and I’ll gladly answer your questions and review your patches.Misc packaging work
Publican. I pushed a new upstream release of publican and dropped a useless build-dependency that was plagued by a difficult to fix RC bug (#749357 for the curious, I tried to investigate but it needs major work for make 4.x compatibility).
GNOME 3.12. With gnome-shell 3.12 hitting unstable, I had to update gnome-shell-timer (and filed an upstream ticket at the same time), a GNOME Shell extension to start some run-down counters.
Django 1.7. I packaged python-django 1.7 release candidate 1 in experimental (found a small bug, submitted a ticket with a patch that got quickly merged) and filed 85 bugs against all the reverse dependencies to ask their maintainers to test their package with Django 1.7 (that we want to upload before the freeze obviously). We identified a pain point in upgrade for packages using South and tried to discuss it with upstream, but after closer investigation, none of the packages are really affected. But the problem can hit administrators of non-packaged Django applications.
Misc stuff. I filed a few bugs (#754282 against git-import-orig –uscan, #756319 against wnpp to see if someone would be willing to package loomio), reviewed an updated package for django-ratelimit in #755611, made a non-maintainer upload of mairix (without prior notice) to update the package to a new upstream release and bring it to modern packaging norms (Mako failed to make an upload in 4 years so I just went ahead and did what I would have done if it were mine).Kali work resulting in Debian contributions
Kali wants to switch from being based on stable to being based on testing so I did try to setup britney to manage a new kali-rolling repository and encountered some problems that I reported to debian-release. Niels Thykier has been very helpful and even managed to improve britney thanks to the very specific problem that the kali setup triggered.
Since we use reprepro, I did write some Python wrapper to transform the HeidiResult file in a set of reprepro commands but at the same time I filed #756399 to request proper support of heidi files in reprepro. While analyzing britney’s excuses file, I also noticed that the Kali mirrors contains many source packages that are useless because they only concern architectures that we don’t host (and I filed #756523 filed against reprepro). While trying to build a live image of kali-rolling, I noticed that libdb5.1 and db5.1-util were still marked as priority standard when in fact Debian already switched to db5.3 and thus should only be optional (I filed #756623 against ftp.debian.org).
When doing some upgrade tests from kali (wheezy based) to kali-rolling (jessie based) I noticed some problems that were also affecting Debian Jessie. I filed #756629 against libfile-fcntllock-perl (with a patch), and also #756618 against texlive-base (missing Replaces header). I also pinged Colin Watson on #734946 because I got a spurious base-passwd prompt during upgrade (that was triggered because schroot copied my unstable’s /etc/passwd file in the kali chroot and the package noticed a difference on the shell of all system users).Thanks
See you next month for a new summary of my activities.
– The Unicorn looked dreamily at Alice, and said "Talk, child."
– Alice could not help her lips curling up into a smile as she began: "Do
you know, I always thought Unicorns were fabulous monsters, too? I
never saw one alive before!"
– "Well, now that we have seen each other," said the Unicorn, "If you’ll
believe in me, I’ll believe in you. Is that a bargain?"
Lewis Carroll, Through the Looking-Glass, and What Alice Found There.
The second alpha of the Utopic Unicorn (to become 14.10) has now been released!
This alpha features images for Kubuntu, Lubuntu, Ubuntu GNOME, UbuntuKylin and the Ubuntu Cloud images.
Pre-releases of the Utopic Unicorn are *not* encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu flavor developers and those who want to help in testing, reporting and fixing bugs as we work towards getting this release ready.
Alpha 2 includes a number of software updates that are ready for wider testing. This is quite an early set of images, so you should expect some bugs.
While these Alpha 2 images have been tested and work, except as noted in the release notes, Ubuntu developers are continuing to improve the Utopic Unicorn. In particular, once newer daily images are available, system installation bugs identified in the Alpha 2 installer should be verified against the current daily image before being reported in Launchpad. Using an obsolete image to re-report bugs that have already been fixed wastes your time and the time of developers who are busy trying to make 14.10 the best Ubuntu release yet. Always ensure your system is up to date before reporting bugs.Kubuntu
Kubuntu is the KDE based flavour of Ubuntu. It uses the Plasma desktop and includes a wide selection of tools from the KDE project.
Kubuntu development is now focussing on the next generation of KDE Software, Plasma 5. This is not yet stable enough for everyday use, so we are still shipping the Plasma 1 desktop on our image which has been updated to the latest version in the alpha.
The Alpha-2 images can be downloaded at: http://cdimage.ubuntu.com/kubuntu/releases/utopic/alpha-2/
More information on Kubuntu Alpha-2 can be found here: https://wiki.ubuntu.com/UtopicUnicorn/Alpha2/KubuntuLubuntu
Lubuntu is a flavor of Ubuntu based on LXDE and focused on providing a very lightweight distribution.
The Alpha 2 images can be downloaded at: http://cdimage.ubuntu.com/lubuntu/releases/utopic/alpha-2/Ubuntu GNOME
Ubuntu GNOME is a flavor of Ubuntu featuring the GNOME desktop environment.
The Alpha-2 images can be downloaded at: http://cdimage.ubuntu.com/ubuntu-gnome/releases/utopic/alpha-2/
More information on Ubuntu GNOME Alpha-2 can be found here: https://wiki.ubuntu.com/UtopicUnicorn/Alpha2/UbuntuGNOMEUbuntuKylin
UbuntuKylin is a flavor of Ubuntu that is more suitable for Chinese users.
The Alpha-2 images can be downloaded at: http://cdimage.ubuntu.com/ubuntukylin/releases/utopic/alpha-2/
More information on UbuntuKylin Alpha-2 can be found here: https://wiki.ubuntu.com/Ubuntu%20Kylin/1410-alpha-2-ReleaseNoteUbuntu Cloud
Ubuntu Cloud images will shortly be available. These images can be run on Amazon EC2, Openstack, SmartOS and many other clouds.
Regular daily images for Ubuntu can be found at: http://cdimage.ubuntu.com
If you’re interested in following the changes as we further develop Utopic, we suggest that you subscribe to the ubuntu-devel-announce list. This is a low-traffic list (a few posts a week) carrying announcements of approved specifications, policy changes, alpha releases and other interesting events.
A big thank you to the developers and testers for their efforts to pull together this Alpha release!
From the steps outside GUADEC in Strasbourg, and on behalf of the Ubuntu release team,
Originally posted to the ubuntu-devel-announce mailing list on Fri Aug 1 08:50:23 UTC 2014 by Iain Lane
As part of this we are introducing basic test cases that every user can run to ensure that core functionality such as instant messaging and playing MP3 files is working as expected. All tests are meant to take no more than 10 minutes and should be doable by just about everyone. They are the perfect way to get some basic testing done without all the hassle testing usually involves.
Feel free to run any test case, at any time.
If you have any questions, drop me a mail at email@example.com, or stop by in #kubuntu-devel on irc.freenode.net.
kitten by David Flores
Ubuntu GNOME Team is happy to announce the first point release for Ubuntu GNOME 14.04 LTS.
- Q: What are point releases for LTS versions of Ubuntu family?
- A: Please, see the answer.
Get Ubuntu GNOME 14.04.1
To contact Ubuntu GNOME:
Please see our full list of contact channels.
Thank you for choosing and using Ubuntu GNOME!
Ubuntu GNOME Team is pleased to announce the release of Ubuntu GNOME Utopic Unicorn Alpha 2.
Please do read the release notes.
This is Alpha 2 Release. Ubuntu GNOME Alpha Releases are NOT recommended for:
- Regular users who are not aware of pre-release issues
- Anyone who needs a stable system
- Anyone uncomfortable running a possibly frequently broken system
- Anyone in a production environment with data or workflows that need to be reliable
Ubuntu GNOME Alpha Releases are recommended for:
- Regular users who want to help us test by finding, reporting, and/or fixing bugs
- Ubuntu GNOME developers
To help with testing Ubuntu GNOME:
Please see Testing Ubuntu GNOME Wiki Page.
To contact Ubuntu GNOME:
Please see our full list of contact channels.
Thank you for choosing and testing Ubuntu GNOME!
In our next release of the Openstack Installer we concentrated on some visual improvements. Here are a few screenshots of some of those changes:
We’ve enhanced feedback of what’s happening during the installation phase:
Services are now being displayed as deployment occurs rather than waiting until completion:
An added help screen to provide more insight into the installer:
We decided to keep it more Openstack focused when listing the running services, this is the final view with all components deployed:
And if you don’t care about the UI (why wouldn’t you?!?) there is an added option to run the entire deployment in your console:
We’ve still got some more polishing to do and a few more enhancements to add, so keep your eye out for a future announcement!
If you are interested in helping us out head over to the installer github page and have a look, the experimental branch is the code used when generating these screenshots. Some of our immediate needs are end to end testing of the single and multi installer, extending the guides, and feedback on the UI itself.
Next November I'll be speaking at JMaghreb conference, i'll be giving a talk about the Ubuntu Touch platform and the Ubuntu development story, together with a live coding session and a Q&A round at the end.
In this session i'll be covering :
- System architecture
- Security model
- QML/HTML5 SDK
- Platform APIs(udm, push notifications, webview, etc...)
- Writing & testing apps on the device & the emulator
- Publishing apps to the store
The exact time & date of the session will be announced soon, so if you're going to be in or near Morocco this November, make sure to attend!
We’re back with Season Seven, Episode Eighteen of the Ubuntu Podcast! Alan Pope is sill MIA, Mark Johnson is still in quarantine but talking to us using Skype, and Tony Whitmore and Laura Cowen are drinking cold squash (it’s really quite hot out there!) and eating Jamaican Ginger cake in Studio L.Download OGG Download MP3 Play in Popup
In this week’s show:
- We interview Graham Binns about the MAAS project at Canonical…
We also discuss:
- We share some Command Line Lurve: rlwrap
And we read your feedback.
Thanks for sending it in!
We’ll be back next week, so please send your comments and suggestions to: firstname.lastname@example.org
Join us on IRC in #uupc on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: email@example.com and skype: ubuntuukpodcast
Follow us on Twitter
Find our Facebook Fan Page
Follow us on Google+
After years fueled by hobbyist passion, I’ve been really excited to see how work that many of my peers and I have been doing in open source has grown into us having serious technical careers these past few years. Whether you’re a programmer, community manager, systems administrator like me or other type of technologist, familiarity with Open Source technology, culture and projects can be a serious boon to your career.
Last year when I attended Fosscon in Philadelphia, I did a talk about my work as an “Open Source Sysadmin” – meaning all my work for the OpenStack Infrastructure team is done in public code repositories. Following my talk I got a lot of questions about how I’m funded to do this, and a lot of interest in the fact that a company like HP is making such an investment.
So this year I’m returning to Fosscon to talk about these things! In addition to my own experiences with volunteer and paid work in Open Source, I’ll be drawing experience from my colleague at HP, Mark Atwood, who recently wrote 7 skills to land your open source dream job and those of others folks I work with who are also “living the dream” with a job in open source.
I’m delighted to be joined at this conference by keynote speaker and friend Corey Quinn and Charlie Reisinger of Penn Manor School District who I’ve chatted with via email and social media many times about the amazing Ubuntu deployment at his district and whom am looking forward to finally meeting.
In Philadelphia or near by? The conference is coming up on Saturday, August 9th and is being held at the the world-renowned Franklin Institute science museum.
Registration to the conference is free, but you get a t-shirt if you pay the small stipend of $25 to support the conference (I did!): http://fosscon.us/Attend
News from Ghislain Vaillant:
The recently released Spyder version 2.3 introduced the much awaited Python 3 support. Debian already has a working package in testing/unstable for both Python 2 (spyder) and Python 3 (spyder3). I have proposed a backport of this version of Spyder to the current LTS in the following bug report: https://bugs.launchpad.net/ubuntu/+source/spyder/+bug/1347487 For those who are interested, please back this proposal up by adding any additional comments up in the bug report or simply marking yourself as affected.
Filed under: News Tagged: spyder
Dustin Kirkland: Ubuntu OpenStack on an Orange Box, Live Demo at the Cloud Austin Meetup, August 19th
I hope you'll join me at Rackspace on Tuesday, August 19, 2014, at the Cloud Austin Meetup, at 6pm, where I'll use our spectacular Orange Box to deploy Hadoop, scale it up, run a terasort, destroy it, deploy OpenStack, launch instances, and destroy it too. I'll talk about the hardware (the Orange Box, Intel NUCs, Managed VLAN switch), as well as the software (Ubuntu, OpenStack, MAAS, Juju, Hadoop) that makes all of this work in 30 minutes or less!
Be sure to RSVP, as space is limited.
I'm a few days away from hitting 6 years at Canonical and I've ended up doing a lot more management than anything else in that time. Before that I did a solid 8 years at my own company, doing anything from developing, project managing, product managing, engineering managing, sales and accounting.
This time of the year is performance review time at Canonical, so it's gotten me thinking a lot about my role and how my view on engineering management has evolved over the years.
A key insights I've had from a former boss, Elliot Murphy, was viewing it as a support role for others to do their job rather than a follow-the-leader approach. I had heard the phrase "As a manager, I work for you" a few times over the years, but it rarely seemed true and felt mostly like a good concept to make people happy but not really applied in practice in any meaningful way.
Of all the approaches I've taken or seen, a role where you're there to unblock developers more than anything else, I believe is the best one. And unless you're a bit power-hungry on some level, it's probably the most enjoyable way of being a manager.
It's not to be applied blindly, though, I think a few conditions have to be met:
1) The team has to be fairly experienced/senior/smart, I think if it isn't it breaks down to often
2) You need to understand very clearly what needs doing and why, and need to invest heavily and frequently in communicated it to the team, both the global context as well as how it applies to them individually
3) You need to build a relationship of trust with each person and need to trust them, because trust is always a 2-way street
4) You need to be enough of an engineer to understand problems in depth when explained, know when to defer to other's judgments (which should be the common case when the team generally smart and experienced) and be capable of tie-breaking in a technical-savvy way
5) Have anyone who's ego doesn't fit in a small, 100ml container, leave it at home
There are many more things to do, but I think if you don't have those five, everything else is hard to hold together. In general, if the team is smart and experienced, understands what needs doing and why, and like their job, almost everything else self-organizes.
If it isn't self-organizing well enough, walk over those 5 points, one or several must be mis-aligned. More often than not, it's 2). Communication is hard, expensive and more of an art than a science. Most of the times things have seemed to stumble a bit, it's been a failure of how I understood what we should be doing as a team, or a failure on how I communicated it to everyone else as it evolved over time.
Second most frequent I think is 1), but that may vary more depending on your team, company and project.
Oh, and actually caring about people and what you do helps a lot, but that helps a lot in life in general, so do that anyway regardless of you role