I am quoting the appImage project page here:
AppImages can be downloaded and run without installation or the need
for root rights.
Making it executable
You can make the appImage executable as follows:
chmod a+x exampleName.AppImage
You can execute an appImage as follows:
You're confusing built binary packages with the underlying source code/package that the packages were built from.
The packages you're referring to are all built from the same source code/package, mutter. You can find that easily by going to packages.ubuntu.com, searching the package you're looking at, and then refer to the "Source package" it refers to. ...
Before you can run an AppImage, you need to make it executable. This is a Linux security feature. There are two main ways to make an AppImage executable:
Using the GUI
Using command line
chmod a+x Some.Appimage
Now double-click your file to run it OR Right-click > Run
For this example I'll use icedtea-6-jre-jamvm as the package you want to rebuild.
First install all the dependencies and build essential:
sudo apt-get build-dep icedtea-6-jre-jamvm
sudo apt-get install build-essential
Then grab the source:
apt-get source icedtea-6-jre-jamvm
Then cd in the openjdk directory directory and build the deb, the -us and -uc ...
From man deb-version:
deb-version - Debian package version number format
Version numbers as used for Debian binary and source packages
consist of three components. These are:
epoch This is a single (generally small) unsigned integer.
The basic idea might look similar between the two systems, but there are some design differences between snaps and Appimages.
Some "big" ones that come to my mind are:
Security, in terms of confinement: Snap packages run in a sandbox, and they are not allowed to escape from it and reach other parts of the system that they should not touch. This is a ...
Why did Canonical chose snaps?
To quote the Ubuntu website:
We originally created the snappy technology and application
confinement system to ensure a carrier-grade update experience for
Ubuntu mobile users and set a new standard for application security in
the mobile era.
Essential idea was to fix issues that are present in both .deb packages and ...
If you have version 1.17.0 or later, you can use
dpkg-parsechangelog --show-field Version
No need to process the output further then. This version is currently (February 2014) available in Debian Testing.
It's always dangerous to disagree with Emmet, so let me start off by acknowledging that his answer is probably more correct. However, I personally find pbuilder more user-friendly and more performant out of the box.
If you are on Ubuntu 12.10 or later, be sure to install the excellent pbuilder-scripts, which are a set of extremely friendly wrappers around ...
There is a detailed explanation here and here. If you are really interested you can read the Debian Policy Manual also.
To answer your questions:
X = this is the debian version of the package
ubuntuY = this is the Yth ubuntu version of the debian package
To quote Verbatim from the first link, package-XubuntuY****” means:
package = this is the name of ...
Yes, there is a real need.
There has been a real need for something like this since the first time one software depended on another.
Let's make this clear:
Managing dependencies is hard.
There's a reason why it's called dependency hell. Packaging systems like RPM and Debian were created with the intent of avoiding dependency hell. However, somebody must ...
It has to be enabled in debian/rules. If the package uses dh, there is a line like this in debian/rules:
Change that to
dh $@ --parallel
Then your commands will work, at least DEB_BUILD_OPTIONS="parallel=4"
Take a look inside of /usr/share/applications/gimp.desktop file. You will see that the value of Image field is set to gimp. So, there is not given an absolute path for the GIMP icon. This means that the system will look for the icon most probably in /usr/share/icons. But there are more icons for GIMP, and the right icon will be chosen depending on the theme ...
While snap focuses on Ubuntu only, AppImage is cross-distribution and also runs on Fedora, debian, openSUSE, CentOS etc.
AppImage needs no runtime or infrastructure support from the Linux distribution and therefore runs next to everywhere. It enables application authors to ship their software directly to Linux users like the do for Windows and OS X; without ...
This is the epoch. It overrides the version in determining which of two packages is newer:
From the deb-version man page:
epoch This is a single (generally small) unsigned integer. It may be
omitted, in which case zero is assumed. If it is omitted then
the upstream-version may not contain any colons.
It is provided ...
From Debian bug 245554 already mentioned:
this can already be easily solved if you use dh >= 9
and dh-exec. Just make your .install file executable,
to the top, and you can use "source => dest", like
debian/default.conf => /etc/my-package/start.conf
Your postinst script should included a #DEBHELPER# token if you are using any debhelper commands that might modify it. It will get replaced in the resulting script by the auto-generated content. See manpage for the dh_installdeb command
# postinst script for webpy-example
# see: dh_installdeb(1)
# summary of how this ...
I'm using pbuilder with an enhanced config and not pbuilder-dist but the steps should be basically the same:
Add your extra sources to the OTHERMIRROR variable in your ~/.pbuilderrc:
OTHERMIRROR="deb http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu raring main|deb http://ppa.launchpad.net/tkluck/gnome3/ubuntu raring main"
Chroot into your pbuilder ...
You do need to rebuild the source package locally before uploading in order to adjust the change log and regenerate the changes file. Though since backporting a package is a pretty common task, this has been scripted. Check out the backportpackage command ubuntu-dev-tools package.
To backport a package from Debian, simply provide the target distro series, ...
Source packages and binary packages exist separately. Each source package may have multiple binary packages associated with it. This is to say that more than one binary package may be built from the same source package.
One of the common ways this happens is that you have a program, a library that the program uses to do much of its work, and the header ...
If copying the binaries for the package you're building does not work, you'll need to upload a source package for each distro version by editing the debian/changelog file.
How to Re-Package for Another Distro Version
Edit the debian/changelog file in your source package directory
Change both the version and target distribution to reflect which distro you ...
Found the problem,
It appears that dch will open an editor if it doesn't get all the information that it considers mandatory. So in order to create a debian/changelog without opening an editor I've found that the following combination of options is sufficient:
dch --create --distribution unstable --package "pkgpkg" --newversion 0.0.0.0-0.test "some nice ...
In order to make one package depend on another, you need to specify the relationship in the debian/control file. You can read about the syntax of this file in the Ubuntu Packaging Guide. The rest of that guide will probably be helpful in giving you an overview of packaging programs for Ubuntu.
Briefly though, your debian/control file might look something ...
As an overview, as far as I understand snaps:
Snaps are more secure. Running in own "containers".
It's much more easy to handle with snaps than with deb packages.
In the future, snaps will be the package format for mobile devices, internet of things and desktop.
is or will be .deb abandoned? Canonical said, there will be support deb packages also in the ...
Short answer: to get it all, you have to download the source packages individually; there is no single public browsing service for Ubuntu generally available today. But we're working on it!
The canonical source code for all of Ubuntu is available as source packages. You can go to https://launchpad.net/ubuntu/+source/hello, for example, click ...