On August 1-2, 2014, Open Source Conference 2014 Kansai@Kyoto was held in Kyoto.
This event is the largest OSS community gathers for in Japan. We participate as exhibitor and speaker every year. Yes, Of course as for this year.
Hiroshi Chonan was in charge of the seminar. He talked about trusty and Utopic.
The highlight of the event is as follows:
The NetBSD team displayed Luna work station of OMRON. Luna(= opposed to Sun) is very old UNIX workstation in Japan. However, the newest Twitter client "Mikutter" works in this workstation on NetBSD!
Mikutter is simple, powerful and moeful twitter client. This is very popular among young geek. (We call them "Teokure" in Japan)
This is Takayoshi Okano. He is one of greatest FLOSS translators in Japan. And it is Open Street Map mapper too.
In this way, the Japanese FLOSS community is very active and happy!
This is just a kind reminder of the UbuConLa happening next week (August 14th-16th) in Cartagena Colombia. With only two previous attempts, the UbuConLa is quickly heading to integrate most of the Ubuntu Latinoamerican teams. This year there will be presence from at least the following countries; Colombia, Brazil, Peru, Venezuela, Uruguay, Argentina, Paraguay, Mexico, España, India, Panama and Ecuador, pretty awesome =)!
With so many attendees I’m sure the UbuConLa will not only increase the awareness of Ubuntu and libre software in the region but will be an ideal forum to exchange experience between local teams and its correlation with local governments and other institutions.
I look forward to talking with you!
Este es un recordatorio del UbuConLa a celebrarse la siguiente semana (14-16 de Agosto) en Cartagena Colombia. Con solo dos versiones anteriores, la UbuConLa ha integrado a la mayoría de los equipos latinoamericanos de Ubuntu. Este año se contara con personas provenientes de por lo menos; Colombia, Brazil, Peru, Venezuela, Uruguay, Argentina, Paraguay, Mexico, España, India, Panama y Ecuador =)!
Con tantos asistentes estoy seguro que la UbuConLa no solo incrementara la popularidad de Ubuntu y del software libre en la region tambien permitira compartir experiencias entre los equipos locaes y sus correlaciones con los gobiernos locales y otras instituciones.
¡Espero verlos por ahí!
Just about two weeks ago, I got a Flame and have decided to use it as my primary phone and put away my Nexus 5. I’m running Firefox OS Nightly on it and so far have not run into any bugs so critical that I have needed to go back to Android.
I have however found some bugs and have some thoughts on things that need improvement to make the Firefox OS experience even better.
One thing that has really irked me while using Firefox OS 2.1 is the keyboard always shows capital letters even if you don’t have caps lock on and are typing lower case letters. This experience is not what I have grown used to while using Android for years and iOS before that. When typing my password into web apps it is confusing to not see a visual cue on the keyboard to let me know what casing I am inputting.
For whatever reason this was an intended feature and I honestly think this UX decision needs to be rethought because it just doesn’t feel natural.
On Firefox OS 2.1, at least in my experience, the max volume is totally inadequate because indoors, it sounds like the person on the other end of a call is whispering or talking quietly. Making or receiving a call outdoors or in a noisy environment is impossible. I filed a bug on this so hopefully it will be sorted.
I like that the mail app is fast and nimble but the lack of having threaded e-mail conversations just leaves me wanting more. It would also be nice to be able to have a smart inbox like the GMail app on Android has since that is also my mail provider.
Social Media Apps
The Facebook and Twitter app both work better and luckily the Facebook web app has avoided many of the UI and feature changes Facebook has landed to its Android and iOS app so the experience is still good. One thing I do miss though is that I got notices on Android where currently the Facebook and Twitter apps on Firefox OS do not check for new messages on either platform and send notifications to your phone.
Additionally, it would really be nice to have a standalone Google+ packaged app in the marketplace since the current one I can add to the home screen seems a bit hit or miss and has some weird grey bar above the app which limits the app using the full screen resolution.
I’m still using my Flame so none of the issues I have pointed out are making my phone unusable and I know that I am running a nightly unreleased version of Firefox OS so stability and issues are expected on Nightly. That being said, I’m really impressed by how polished the UI is compared to previous versions. Each time I get an OTA, I see more and more polish and improvements coming to certified apps.
I am really happy with the fact the Flame had dual SIM since I am traveling to Europe in a few weeks and can buy a SIM for a few euros if my T-Mobile International Roaming for some reason fails me.
I also know others who are not involved in the Mozilla community that are also using the Flame as their daily driver in North America, so that’s very optimistic to see people buying the Flame and dogfooding it on their own simply because they want a platform that puts the Open Web while also being Open Source.
- coreycb to take bug 1347567
- DebianImportFreeze on the 7th and FeatureFreeze on the 21st
- coreycb agreed to take on bug 1347567
- Everyone reminded to keep BP up to date
- no updates
- psivaa reported that utopic installation jobs are broken at the moment due to a parted bug and that the Foundations team is working on a fix.
- smb reported that several bugs were reported by EC2 users.
- Linuxcon on the 20th and TL sprint going on during this week.
- lutostag reminded everyone that voting for ODS sessions are about to close, so people should vote ASAP. Ubuntu related sessions: http://insights.ubuntu.com/2014/07/31/voting-begins-for-openstack-summit-sessions-in-paris/
- Next meeting will be on Tuesday, Aug 12th at 16:00 UTC in #ubuntu-meeting. Chaired by gaughen
Here is a recent article on Randa and what goes on here: https://dot.kde.org/2014/08/02/randa-meetings-interview-four-myriam-schweingruber. Most of the attendees are traveling on funds contributed by the community. Thanks so much! I hope our work will be worth your generosity.
Today, the Akademy session schedule was announced: https://dot.kde.org/2014/08/04/akademy-2014-program-schedule-fast-fun-inspiring. This will be my third Akademy, and they are always fascinating, friendly, educational, and just plain awesome! At this point, we're still open for more sponsorship of Akademy, and registration seems a bit slow. If you are interested, please register and make your way to Brno for Akademy. If you know a company who is not yet a sponsor and should be, please urge them to register as a sponsor now.
The talks will be great, as will the "hall track." Following the formal meeting, we have a few days of informal talks, mini-sprints, and workshops. This is when Kubuntu will be meeting, which is why Ubuntu sponsored me to attend! \o/ Thanks so much for that, generous Ubuntu users. To sum up, I'll quote Myriam from the above article:
While a lot of the work in Free Software is done over the internet, nothing replaces the real life meetings, as it provides an extra drive in terms of motivation. Modern software development is mostly agile, something even corporate software development is using more and more. Due to the global distribution of our contributors; Free Software development has always been agile to start with, even if we didn't put a label on it in the early days.And in agile development; sprints are a very important element to push the project forward. While sprints can be done over the web, they are hindered by time-zones, external distractions, availability of contributors, etc. Having real life sprints, even if those are few, are more productive as all the hindrances of the web meetings are eliminated and the productivity is greatly enhanced. [emphasis added]
Welcome to the Ubuntu Weekly Newsletter. This is issue #377 for the week July 28 – August 3, 2014, and the full version is available here.
In this issue we cover:
- Ubuntu 14.10 (Utopic Unicorn) alpha-2 released!
- Ubuntu Stats
- FOSSCON 2014 Sat August 9th Philadelphia
- Ubuntu Touch session in Morocco
- Ubuntu Cloud News
- Svetlana Belkin: Ubuntu Leadership Team:Team Leaders Wanted
- Ubuntu App Developer Blog: A faster Ubuntu positioning system with Nokia HERE
- Ubuntu Scientists: Backport spyder 2.3 to Ubuntu 14.04 LTS
- Harald Sitter: Kubuntu Testing and You
- 5 Things to Do After Upgrading from 12.04 to 14.04
- Ubuntu Server Guide – Calling all contributors
- Permission to break the system? – GRANTED!
- Canonical News
- A year without Windows and a new love of Linux
- In The Blogosphere
- Other Articles of Interest
- Featured Audio and Video
- Weekly Ubuntu Development Team Meetings
- Monthly Team Reports: June 2014
- Upcoming Meetings and Events
- Updates and Security for 10.04, 12.04 and 14.04
- And much more!
The issue of The Ubuntu Weekly Newsletter is brought to you by:
- Elizabeth K. Joseph
- Tiago Carrondo
- David Morfin
- Jose Antonio Rey
- And many others
Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License
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!