Recently, Fedora's Copr service was launched which lets individuals create personal repos and build packages on Fedora's servers for a number of Fedora and EL versions (similar to OBS and PPAs).
I've set up a couple of repos under it, and one which contains builds of various gems as dependencies for librarian-puppet. Setting up and tracking RPM builds is made quite easy with git and tito, which lets you set up a simple directory structure in your RPM repo, track specs and source binaries (.gem files), tag and release changes to Copr:$ tree . |-- README.md |-- rel-eng | |-- packages | | |-- rubygem-highline | | |-- rubygem-librarian | | |-- rubygem-librarian-puppet | | `-- rubygem-thor | |-- releasers.conf | `-- tito.props |-- rubygem-highline | |-- highline-1.6.20.gem | `-- rubygem-highline.spec |-- rubygem-librarian | |-- librarian-0.1.2.gem | `-- rubygem-librarian.spec |-- rubygem-librarian-puppet | |-- librarian-puppet-0.9.17.gem | `-- rubygem-librarian-puppet.spec |-- rubygem-thor | |-- rubygem-thor.spec | `-- thor-0.15.4.gem `-- setup_sources.sh 6 directories, 16 files
(my librarian-puppet-copr repo)
However storing binary files in git has lots of problems, including the resulting size of the repo. To solve this, I use git-annex so the repo only stores metadata and a local cache of the binaries. The binaries can then be fetched from the web on a clean checkout using the setup_sources.sh script and git-annex on the fly.
Setting this up is easy:
Adding new packages is now a matter of doing:
git-annex will store the file in its local storage under .git/annex, replacing the file in git with a symlink based on the checksum of the contents. When you push the repo to a remote without git-annex support (like GitHub), then the binaries won't be transferred, keeping the size small. Other users can fetch binaries by adding a shared remote (e.g. a WebDAV or rsync share or web remotes using setup_sources.sh).
When tito is building SRPMs, it will "unlock" the files, fetching them from available remotes, build the RPM and then re-lock the checkout.
So the combination of git (for tracking sources and specs), git-annex (for keeping sources outside git), tito (for tagging builds) and Copr (for building and publishing) makes it easy to build and release your own RPMs, while allowing you to make the source code and build process accessible and transparent.
I have long been a keen user of pdftk, the PDF Toolkit, but am frequently surprised when people have not heard of it. True, it is a command line tool, but it is easy to incorporate into service menus, scripts etc and doubtless there is a GUI front-end for it somewhere (in fact there is one linked to from the above page).
Clearly a blog post is called for, but, whilst you wait for a post that will never arrive, here is a link to some examples that should open your eyes to what is possible with pdftk.
To get started on a Debian-based system:$ sudo apt-get install pdftk $ man pdftk
One of the (many) challenges with creating a new mobile platform is that of bootstrapping app developers. The Ubuntu SDK – based on well known tools like Qt & QtCreator and supporting HTML5, C++ & GL – we can run our applications both on mobile devices and standard Ubuntu desktops.
With our convergence plans being a core component of Ubuntu over the coming releases, we can take advantage of this when testing mobile apps.
Developers can create & users can test applications without having to commit funds to a dedicated Ubuntu mobile device. Of course in the future Ubuntu mobile devices will be ubiquitous but for now we can support those users, testers and developers right now to use Ubuntu mobile apps on the desktop.
So with the Core Apps Hack Days just around the corner, now is a great time to install the core apps on your desktop and help test them, file bugs and contribute patches!
For users of Ubuntu 13.10 and Trusty (14.04) we have a Core Apps Daily PPA which has builds of all the core apps. Installing them is a cinch on 13.10 and 14.04 via the PPA & touch-coreapps metapackage:-
sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily
sudo apt-get update
sudo apt-get install touch-coreapps
Note: This has been tested on 13.10 and 14.04 but not on previous releases.
If you later wish to remove them simply use sudo ppa-purge ppa:ubuntu-touch-coreapps-drivers/daily or just sudo apt-get autoremove touch-coreapps.
Once installed you should see icons for all the core apps in your dash
We welcome constructive feedback and bug reports about all aspects of the Core Apps. You can find us in #ubuntu-app-devel on freenode and details of where to file bugs can be found on the Core Apps wiki pages.
You can get started with developing apps on Ubuntu via the SDK, the documentation for which is at developer.ubuntu.com.Tweet
Hack Days are back!
On March 25th – 27th 2014 from 09:00 – 21:00U UTC we’re having another round of Core Apps Hack Days as we Sprint towards the final Ubuntu 14.04 release in April.
This time we’re concentrating our focus on 6 main apps, but we welcome new contributions to all the core apps. We’re identifying all the bite-size bugs which would be ideal for new developers, and we have some more chunky work for more experienced developers looking for more of a challenge. Getting involved is really easy and it’s fun and friendly.
Music & Reminders will be the focus on Tuesday 25th.
Clock & Calendar on Wednesday 26th.
Weather & Calculator on Thursday 27th.
That said, we don’t want to limit contributions to just those days, and of course welcome community developers getting involved at any time of day or night!
We’ve detailed on the HackDays wiki page how you can get involved and all the other details. Head over there for more information.
David, Michael & myself will be around on IRC in #ubuntu-app-devel as always to co-ordinate and run the Hack Days. We’ll also be able to test on multiple mobile devices as well as desktops and laptops. We can review code and get completed work landed into trunk and on devices promptly. We’ll also have and other Core Apps community & Canonical platform developers around to consult and mentor where required.
If you’ve ever considered developing on Ubuntu, but not got around to it, now is a great time to join. There’s plenty to do for people of all levels, developing Free Software for a very wide audience. Join us and lets make the Core Apps rock!Tweet
Anyone who has enjoyed the dubious benefits of working with IPSEC will find OpenVPN a delight, but what do you do with your client.ovpn file once you have it?
If you spend most of your time in a terminal anyway, then I would suggest just putting all your client.ovpn files into ~/.openvpn, renaming them in some appropriate way, and then using them simply by typing:$ sudo openvpn client.ovpn
If, on the other hand, you live in a more graphically orientated world, then you might like to integrate them into Network Manager. Sadly, the Import feature in Ubuntu does not work, at least in the versions of Ubuntu that I have used, and you have to make a few changes first.
Firstly, I would always create a hidden directory into which to store your client files:$ mkdir ~/.openvpn $ cd ~/.openvpn $ mv ~/Downloads/client.ovpn ./
Secondly, you need to ensure that you have installed openvpn for network-manager:$ sudo apt-get install network-manager-openvpn-gnome
Thirdly, we need to extract some data out of the client.ovpn, and for this I followed these instructions, which I include below in case of link breakage:
Finally, save and close all the files and check that you now have all the above files sitting happily in your ~/.openvpn directory.
Go to Network Manager -> Edit Connections ->VPN and click Import, browse to the modified client.ovpn import that file.
Enter vpn username and password if prompted.
On the VPN page, select Advanced and on the General Tab, uncheck the first option, “Use custom gateway.
Very early on in my Linux life, I came across this suggested header for crontab and I’ve used it ever since. So much so that I am always slightly thrown when I come across a crontab without it! No, you don’t need it, yes the standard commented header works just fine, but, if like me you prefer things neatly lined up, then this might suit you:MAILTO= # _________________________ 2. Minute - Minutes after the hour (0-59) # | # | ______________________ 2. Hour - 24-hour format (0-23). # | | # | | ___________________ 3. Day - Day of the month (1-31) # | | | # | | | ________________ 4. Month - Month of the year (1-12) # | | | | # | | | | ______________5. Weekday - Day of the week. (0-6, 0 indicates Sunday) # | | | | | #__|_____|_____|_____|____|___Command_____________________________________________________________
And if you recognise this as your’s, then thank you!
Occasionally users are unable to connect to our FreeNX server, they report an error “Startup Session Failed”. Clicking on “Detail” shows that it is unable to find the server session file.
Searching for solutions suggested a number of options, including removing the server /tmp/.X1***-lock files, or simply removing FreeNX and installing NoMachine’s NXServer instead.
In the end the solution proved remarkably simple:
On the server run:# nxserver --list NX> 100 NXSERVER - Version 1.5.0-60 OS (GPL) NX> 127 Sessions list: Display Username Remote IP Session ID ------- --------------- --------------- -------------------------------- 1001 chris 192.168.1.52 1BC6B4B9C3CF4C2B6BD7137AC7FDE5DA 1000 helen - 87443D16622EC0751551685A93DD023B 1002 michelle 192.168.1.102 DBAC430C8AA8B414A5E2228970E2BBDC NX> 999 Bye
The session with no remote IP is for a session that has not ended properly. Terminate this session and users should be able to log in once again:# nxserver --terminate helen
Update: This problem was little more complex than I at first thought, all I had really done is allow one more user to login before the issue re-occurred. You also need to check is that there are no old lock files in /tmp/.X11-unix:# cd /tmp/.X11-unix #ls -al /tmp/.X11-unix# ls -al total 316 drwxrwxrwt 2 root root 4096 2014-01-02 12:48 . drwxrwxrwt 375 root root 315392 2014-01-02 12:48 .. srwxrwxrwx 1 root root 0 2013-07-24 17:04 X0 srwxrwxrwx 1 helen helen 0 2014-01-02 10:32 X1000 srwxrwxrwx 1 chris chris 0 2014-01-02 11:42 X1001 srwxrwxrwx 1 michelle michelle 0 2014-01-02 08:52 X1002 srwxrwxrwx 1 terry terry 0 2013-09-05 15:05 X1003
Notice that there is a .X11-unix file for terry X1003, but no corresponding user shown in nxserver –list above. Remove this spurious file and it should now work.
It would also make sense to ensure that the correct /tmp/.X1***-lock files are present:# cd /tmp # ls -al | grep -i X.*-lock -rw------- 1 nx nx 0 2014-01-02 10:32 .nX1000-lock -rw------- 1 nx nx 0 2014-01-02 11:42 .nX1001-lock -rw------- 1 nx nx 0 2014-01-02 08:52 .nX1002-lock -r--r--r-- 1 helen helen 11 2014-01-02 10:32 .X1000-lock -r--r--r-- 1 chris chris 11 2014-01-02 11:42 .X1001-lock -r--r--r-- 1 michelle michelle 11 2014-01-02 08:52 .X1002-lock
You should expect to see the correct number of lock files for your user sessions, in my case these required no changes, but if there had been spurious files, removing them would seem sensible.
If this has been helpful to you, please do consider rating this post or adding a comment!