[jitsi-dev] Jitsi into Debian wheezy backports?


#1

I'm just wondering if you are thinking about making a version of Jitsi
available in wheezy-backports?

This will be useful for all the people who like to keep their systems on
a stable Debian release

The version you have in testing has been there since 2013-11-29 - that
is more than the 10 day threshold required for something to be
considered for backports but it is ultimately up to you if that is a
version you want to support in backports


#2

Hey Daniel,

···

On 16.01.14, 16:55, Daniel Pocock wrote:

I'm just wondering if you are thinking about making a version of Jitsi
available in wheezy-backports?

This will be useful for all the people who like to keep their systems on
a stable Debian release

The version you have in testing has been there since 2013-11-29 - that
is more than the 10 day threshold required for something to be
considered for backports but it is ultimately up to you if that is a
version you want to support in backports

We (BlueJimp) can't currently dedicate any resources to this but if someone else is interested in doing it, then sure.

Emil

--
https://jitsi.org


#3

It may not actually require very much effort at all, as Jitsi already
runs on a wheezy system anyway.

The first thing is, you have to avoid making an upload for a period of
10 days. You need to let the package in unstable sit there for 10 days
so that it propagates to testing. That is why the version in testing is
so old, it appears you keep uploading new versions to unstable and that
always resets the 10 day counter.

So, no explicit work required, just avoid uploading to unstable.

After that 10 day wait, the period in unstable will be copied to
testing. You can then make more uploads to unstable.

After the version you are happy with has propagated to testing, you then
make a request for it to join backports. This is very trivial, you just

a) make a branch in git
b) on that branch, add a backports entry to the debian/changelog file
(this is just cut and pasting 3 lines of text)
c) run the command to build the package
d) wait, backports maintainers do the rest

The only catch is that this process may need to be repeated for any
build dependencies or runtime dependencies. The main thing to remember,
though, is that you are only uploading versions that you already
produced for testing, they should not really need to be changed in any
other way - if there is significant change required, the packages are
probably not suitable for backports anyway.

···

On 20/01/14 09:06, Emil Ivov wrote:

Hey Daniel,

On 16.01.14, 16:55, Daniel Pocock wrote:

I'm just wondering if you are thinking about making a version of Jitsi
available in wheezy-backports?

This will be useful for all the people who like to keep their systems on
a stable Debian release

The version you have in testing has been there since 2013-11-29 - that
is more than the 10 day threshold required for something to be
considered for backports but it is ultimately up to you if that is a
version you want to support in backports

We (BlueJimp) can't currently dedicate any resources to this but if
someone else is interested in doing it, then sure.


#4

Hey Daniel,

I'm just wondering if you are thinking about making a version of Jitsi
available in wheezy-backports?

This will be useful for all the people who like to keep their systems on
a stable Debian release

The version you have in testing has been there since 2013-11-29 - that
is more than the 10 day threshold required for something to be
considered for backports but it is ultimately up to you if that is a
version you want to support in backports

We (BlueJimp) can't currently dedicate any resources to this but if
someone else is interested in doing it, then sure.

It may not actually require very much effort at all, as Jitsi already
runs on a wheezy system anyway.

The first thing is, you have to avoid making an upload for a period of
10 days. You need to let the package in unstable sit there for 10 days
so that it propagates to testing. That is why the version in testing is
so old, it appears you keep uploading new versions to unstable and that
always resets the 10 day counter.

Oops, not quite correct: the version in testing is old (November) simply
because you did not make any other uploads and then made an upload to
unstable just a few days ago. Can you just clarify,

a) is that version (2.4.4997-1) a release you consider suitable for
backports?

b) is the previous version (2.3.4909-1) a release you consider suitable
for backports?

So, no explicit work required, just avoid uploading to unstable.

After that 10 day wait, the period in unstable will be copied to
testing. You can then make more uploads to unstable.

After the version you are happy with has propagated to testing, you then
make a request for it to join backports. This is very trivial, you just

a) make a branch in git
b) on that branch, add a backports entry to the debian/changelog file
(this is just cut and pasting 3 lines of text)
c) run the command to build the package
d) wait, backports maintainers do the rest

The only catch is that this process may need to be repeated for any
build dependencies or runtime dependencies. The main thing to remember,
though, is that you are only uploading versions that you already
produced for testing, they should not really need to be changed in any
other way - if there is significant change required, the packages are
probably not suitable for backports anyway.

I had a quick look over the dependencies, they all appear to be in
wheezy or wheezy-backports

The only unusual thing I notice is the versioned libx264-133 - is it OK
to run Jitsi with the libx264-123 package in wheezy or you really need
the 133 version?

Which repository do you use to track the debian/* files, e.g. these files:

http://sources.debian.net/src/jitsi/2.4.4997-1/debian

for making the Debian package? Do you want to have those hosted in a
Debian git repository? Do you have any document listing the steps to go
from the Github version of your code, to build a release tarball and to
convert it to a package?

If you can let me know about all these things I can look a little bit
more closely at getting it into backports

···

On 20/01/14 09:37, Daniel Pocock wrote:

On 20/01/14 09:06, Emil Ivov wrote:

On 16.01.14, 16:55, Daniel Pocock wrote:


#5

Hi,

Hey Daniel,

I'm just wondering if you are thinking about making a version of Jitsi
available in wheezy-backports?

This will be useful for all the people who like to keep their systems on
a stable Debian release

The version you have in testing has been there since 2013-11-29 - that
is more than the 10 day threshold required for something to be
considered for backports but it is ultimately up to you if that is a
version you want to support in backports

We (BlueJimp) can't currently dedicate any resources to this but if
someone else is interested in doing it, then sure.

It may not actually require very much effort at all, as Jitsi already
runs on a wheezy system anyway.

The first thing is, you have to avoid making an upload for a period of
10 days. You need to let the package in unstable sit there for 10 days
so that it propagates to testing. That is why the version in testing is
so old, it appears you keep uploading new versions to unstable and that
always resets the 10 day counter.

Oops, not quite correct: the version in testing is old (November) simply
because you did not make any other uploads and then made an upload to
unstable just a few days ago. Can you just clarify,

a) is that version (2.4.4997-1) a release you consider suitable for
backports?

Yes we do, this is our latest stable release.

b) is the previous version (2.3.4909-1) a release you consider suitable
for backports?

So, no explicit work required, just avoid uploading to unstable.

After that 10 day wait, the period in unstable will be copied to
testing. You can then make more uploads to unstable.

After the version you are happy with has propagated to testing, you then
make a request for it to join backports. This is very trivial, you just

a) make a branch in git
b) on that branch, add a backports entry to the debian/changelog file
(this is just cut and pasting 3 lines of text)
c) run the command to build the package
d) wait, backports maintainers do the rest

The only catch is that this process may need to be repeated for any
build dependencies or runtime dependencies. The main thing to remember,
though, is that you are only uploading versions that you already
produced for testing, they should not really need to be changed in any
other way - if there is significant change required, the packages are
probably not suitable for backports anyway.

I had a quick look over the dependencies, they all appear to be in
wheezy or wheezy-backports

The only unusual thing I notice is the versioned libx264-133 - is it OK
to run Jitsi with the libx264-123 package in wheezy or you really need
the 133 version?

If it compiles successfully it is ok.

Which repository do you use to track the debian/* files, e.g. these files:

http://sources.debian.net/src/jitsi/2.4.4997-1/debian

On every build we generate source package:
https://download.jitsi.org/jitsi/nightly/debian-src/

for making the Debian package? Do you want to have those hosted in a
Debian git repository? Do you have any document listing the steps to go
from the Github version of your code, to build a release tarball and to
convert it to a package?

In order to build it you need to clone several repositories in one
folder, so here is a simple 6 step guide I use:
(suppose current build is 4997, if I need older build: checkout
corresponding commit)
git clone https://github.com/jitsi/jitsi.git
git clone https://github.com/jitsi/libjitsi.git
git clone https://github.com/jitsi/libsrc.git
git clone https://github.com/jitsi/otr4j.git
cd jitsi
ant deb-src -Dlabel=4997
then the source package will be in release/debian folder of jitsi.

Regards
damencho

···

On Mon, Jan 20, 2014 at 1:34 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

On 20/01/14 09:37, Daniel Pocock wrote:

On 20/01/14 09:06, Emil Ivov wrote:

On 16.01.14, 16:55, Daniel Pocock wrote:

If you can let me know about all these things I can look a little bit
more closely at getting it into backports

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev