[jitsi-dev] jitsi and libjitsi packages on mentors.debian.net


#1

Hi,

both, the jitsi and the libjitsi packages on mentors.debian.net do not
build in a clean chroot (see attached buildlogs). You should always
check, if your packages build in a clean chroot without network access.
One way to do this, would e.g. building them with pbuilder [1].

With best regards,
Julian Wollrath

[1] https://packages.debian.org/unstable/pbuilder

libjitsi_593-1.build.log (83.1 KB)

jitsi_2.8.5426-1.build.log (722 KB)


#2

Hi,

thanks for the report. To build jitsi you need the latest dns-java
version installed. We have submitted NMU on mentors for that lib.

The problem with libjitsi is caused by sdes4j which uses maven.

Do you know how to build a maven project offline?

Regards
damencho

···

On Wed, Apr 1, 2015 at 3:50 PM, Julian Wollrath <jwollrath@web.de> wrote:

Hi,

both, the jitsi and the libjitsi packages on mentors.debian.net do not
build in a clean chroot (see attached buildlogs). You should always
check, if your packages build in a clean chroot without network access.
One way to do this, would e.g. building them with pbuilder [1].

With best regards,
Julian Wollrath

[1] https://packages.debian.org/unstable/pbuilder


#3

Hi,

Do you know how to build a maven project offline?

no, I do not. But I guess, that it would be possible, do include the
downloaded file in the tarball and patch the respective build.xml not
to download the file. Any way, I do not have any experience with ant,
so I will not be any help in fixing that.

Cheers,
Julian


#4

Hi,

thanks for the report. To build jitsi you need the latest dns-java
version installed. We have submitted NMU on mentors for that lib.

than you should update debian/control to reflect that. This would mean,
replacing the line containing the build-dep libdnsjava-java by e.g.
libdnsjava-java (>= 2.1.7~).

Cheers,
Julian


#5

Hi,

so I tried out jitsi_2.8.5426 with libjitsi_598 and the new dnsjava
version and the SIP account, which worked and was shown with
jitsi_2.4.4997-1.2, was not shown anymore and therefore did not work.
Furthermore, I was not able to add the account again.

Cheers,
Julian


#6

Hi,

so I tried out jitsi_2.8.5426 with libjitsi_598 and the new dnsjava
version and the SIP account, which worked and was shown with
jitsi_2.4.4997-1.2, was not shown anymore and therefore did not work.
Furthermore, I was not able to add the account again.

Btw.: With jitsi 2.6.5390 and libjitsi 598 it worked.

···

Am Wed, 1 Apr 2015 16:35:37 +0200 schrieb Julian Wollrath <jwollrath@web.de>:

Cheers,
Julian


#7

Hi,

ok, we are fixing now the building stuff you reported. And will check
later what can be the problem with sip account, cause without logs its
hard to tell.
Hum on mentors libjitsi is 593. I'm not sure where you get 598, but
version mismatch can lead to unpredictable results.
You need to update everything, or stick to some versions. We currently
push to mentors the latest stable release.

Regards
damencho

···

On Wed, Apr 1, 2015 at 5:40 PM, Julian Wollrath <jwollrath@web.de> wrote:

Am Wed, 1 Apr 2015 16:35:37 +0200 > schrieb Julian Wollrath <jwollrath@web.de>:

Hi,

so I tried out jitsi_2.8.5426 with libjitsi_598 and the new dnsjava
version and the SIP account, which worked and was shown with
jitsi_2.4.4997-1.2, was not shown anymore and therefore did not work.
Furthermore, I was not able to add the account again.

Btw.: With jitsi 2.6.5390 and libjitsi 598 it worked.

Cheers,
Julian


#8

Hi,

ok, we are fixing now the building stuff you reported. And will check
later what can be the problem with sip account, cause without logs its
hard to tell.

This should be, what your asking for:
16:07:42.680 SCHWERWIEGEND: [28]
service.protocol.AccountManager.doLoadStoredAccounts().208 Failed to
load account {Encodings.speex/16000=14,
OPT_CLIST_USE_SIP_CREDETIALS=false, AUTHORIZATION_NAME=xxx,
OVERRIDE_ENCODINGS=false, speex/8000=13, Encodings.GSM/8000=6,
Encodings.SILK/24000=11, SILK/12000=2, ACCOUNT_UID=SIP:xxx@xxx,
POLLING_PERIOD=30, PROTOCOL_NAME=SIP, DTMF_METHOD=AUTO_DTMF,
H263-1998/90000=0, Encodings.SILK/8000=1, SAVP_OPTION=0,
Encodings.SILK/16000=10, Encodings.H263-1998/90000=0, H264/90000=1100,
Encodings.PCMA/8000=8, USER_ID=xxx@xxx, KEEP_ALIVE_INTERVAL=25,
XCAP_ENABLE=false, ENCRYPTION_PROTOCOL_STATUS.SDES=false,
telephone-event/8000=3, SILK/8000=1, ENCRYPTION_PROTOCOL.ZRTP=0,
XIVO_ENABLE=false, PCMA/8000=8, PROXY_AUTO_CONFIG=false,
opus/48000=750, Encodings.VP8/90000=0, DISPLAY_NAME=xxx,
Encodings.speex/8000=13, Encodings.SILK/12000=2,
IS_PRESENCE_ENABLED=true, DEFAULT_SIPZRTP_ATTRIBUTE=true,
Encodings.PCMU/8000=9, Encodings.iLBC/8000=7, SILK/24000=11,
VP8/90000=0, DEFAULT_ENCRYPTION=true, Encodings.H264/90000=1100,
SERVER_ADDRESS=xxx, Encodings.G722/8000=12,
ENCRYPTION_PROTOCOL_STATUS.ZRTP=true, PROXY_ADDRESS=xxx,
KEEP_ALIVE_METHOD=OPTIONS, SILK/16000=10, PREFERRED_TRANSPORT=UDP,
SERVER_PORT=5060, Encodings.telephone-event/8000=3, PCMU/8000=9,
speex/32000=15, iLBC/8000=7, Encodings.speex/32000=15,
ENCRYPTED_PASSWORD=xxx, G722/8000=12, GSM/8000=6, FORCE_P2P_MODE=false,
PROXY_PORT=5060, Encodings.opus/48000=750, ENCRYPTION_PROTOCOL.SDES=1,
SUBSCRIPTION_EXPIRATION=3600,
SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32,
speex/16000=14} java.lang.IllegalArgumentException: Failed to
initialize accountFailed to get SIP Factory at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:313)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)

Hum on mentors libjitsi is 593. I'm not sure where you get 598, but
version mismatch can lead to unpredictable results.

When I built the 2.6 stable release, I generated the libjitsi-tarball
myself and got version 598 and stuck with it, since it worked. I built
jitsi 2.8 against libjitsi 598, so there is no problem, so I just the
libjitsi I built jitsi against.

···

Am Wed, 1 Apr 2015 17:46:06 +0300 schrieb Damian Minkov <damencho@jitsi.org>:

You need to update everything, or stick to some versions. We currently
push to mentors the latest stable release.

Regards
damencho

On Wed, Apr 1, 2015 at 5:40 PM, Julian Wollrath <jwollrath@web.de> > wrote:
> Am Wed, 1 Apr 2015 16:35:37 +0200 > > schrieb Julian Wollrath <jwollrath@web.de>:
>
>> Hi,
>>
>> so I tried out jitsi_2.8.5426 with libjitsi_598 and the new dnsjava
>> version and the SIP account, which worked and was shown with
>> jitsi_2.4.4997-1.2, was not shown anymore and therefore did not
>> work. Furthermore, I was not able to add the account again.
>
> Btw.: With jitsi 2.6.5390 and libjitsi 598 it worked.
>
>>
>>
>> Cheers,
>> Julian


#9

> Hi,
>
> ok, we are fixing now the building stuff you reported. And will
> check later what can be the problem with sip account, cause without
> logs its hard to tell.
This should be, what your asking for:

16:07:42.679 SCHWERWIEGEND: [28]
impl.protocol.sip.SipStackSharing.<init>().139 Failed to get SIP
Factory. java.lang.NullPointerException: Specified service reference
cannot be null. at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at
net.java.sip.communicator.impl.protocol.sip.SipActivator.getNetworkAddressManagerService(SipActivator.java:159)
at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:134)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.initialize(ProtocolProviderServiceSipImpl.java:378)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:304)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)
16:07:42.679 SCHWERWIEGEND: [28]
impl.protocol.sip.ProtocolProviderFactorySipImpl.createService().312
Failed to initialize account
net.java.sip.communicator.service.protocol.OperationFailedException:
Failed to get SIP Factory at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:140)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.initialize(ProtocolProviderServiceSipImpl.java:378)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:304)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)
Caused by: java.lang.NullPointerException: Specified service reference
cannot be null. at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at
net.java.sip.communicator.impl.protocol.sip.SipActivator.getNetworkAddressManagerService(SipActivator.java:159)
at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:134) ...
8 more

···

Am Wed, 1 Apr 2015 17:03:50 +0200 schrieb Julian Wollrath <jwollrath@web.de>:

Am Wed, 1 Apr 2015 17:46:06 +0300 > schrieb Damian Minkov <damencho@jitsi.org>:

16:07:42.680 SCHWERWIEGEND: [28]
service.protocol.AccountManager.doLoadStoredAccounts().208 Failed to
load account {Encodings.speex/16000=14,
OPT_CLIST_USE_SIP_CREDETIALS=false, AUTHORIZATION_NAME=xxx,
OVERRIDE_ENCODINGS=false, speex/8000=13, Encodings.GSM/8000=6,
Encodings.SILK/24000=11, SILK/12000=2, ACCOUNT_UID=SIP:xxx@xxx,
POLLING_PERIOD=30, PROTOCOL_NAME=SIP, DTMF_METHOD=AUTO_DTMF,
H263-1998/90000=0, Encodings.SILK/8000=1, SAVP_OPTION=0,
Encodings.SILK/16000=10, Encodings.H263-1998/90000=0, H264/90000=1100,
Encodings.PCMA/8000=8, USER_ID=xxx@xxx, KEEP_ALIVE_INTERVAL=25,
XCAP_ENABLE=false, ENCRYPTION_PROTOCOL_STATUS.SDES=false,
telephone-event/8000=3, SILK/8000=1, ENCRYPTION_PROTOCOL.ZRTP=0,
XIVO_ENABLE=false, PCMA/8000=8, PROXY_AUTO_CONFIG=false,
opus/48000=750, Encodings.VP8/90000=0, DISPLAY_NAME=xxx,
Encodings.speex/8000=13, Encodings.SILK/12000=2,
IS_PRESENCE_ENABLED=true, DEFAULT_SIPZRTP_ATTRIBUTE=true,
Encodings.PCMU/8000=9, Encodings.iLBC/8000=7, SILK/24000=11,
VP8/90000=0, DEFAULT_ENCRYPTION=true, Encodings.H264/90000=1100,
SERVER_ADDRESS=xxx, Encodings.G722/8000=12,
ENCRYPTION_PROTOCOL_STATUS.ZRTP=true, PROXY_ADDRESS=xxx,
KEEP_ALIVE_METHOD=OPTIONS, SILK/16000=10, PREFERRED_TRANSPORT=UDP,
SERVER_PORT=5060, Encodings.telephone-event/8000=3, PCMU/8000=9,
speex/32000=15, iLBC/8000=7, Encodings.speex/32000=15,
ENCRYPTED_PASSWORD=xxx, G722/8000=12, GSM/8000=6,
FORCE_P2P_MODE=false, PROXY_PORT=5060, Encodings.opus/48000=750,
ENCRYPTION_PROTOCOL.SDES=1, SUBSCRIPTION_EXPIRATION=3600,
SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32,
speex/16000=14} java.lang.IllegalArgumentException: Failed to
initialize accountFailed to get SIP Factory at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:313)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)

> Hum on mentors libjitsi is 593. I'm not sure where you get 598, but
> version mismatch can lead to unpredictable results.

When I built the 2.6 stable release, I generated the libjitsi-tarball
myself and got version 598 and stuck with it, since it worked. I built
jitsi 2.8 against libjitsi 598, so there is no problem, so I just the
libjitsi I built jitsi against.

> You need to update everything, or stick to some versions. We
> currently push to mentors the latest stable release.
>
> Regards
> damencho
>
>
> On Wed, Apr 1, 2015 at 5:40 PM, Julian Wollrath <jwollrath@web.de> > > wrote:
> > Am Wed, 1 Apr 2015 16:35:37 +0200 > > > schrieb Julian Wollrath <jwollrath@web.de>:
> >
> >> Hi,
> >>
> >> so I tried out jitsi_2.8.5426 with libjitsi_598 and the new
> >> dnsjava version and the SIP account, which worked and was shown
> >> with jitsi_2.4.4997-1.2, was not shown anymore and therefore did
> >> not work. Furthermore, I was not able to add the account again.
> >
> > Btw.: With jitsi 2.6.5390 and libjitsi 598 it worked.
> >
> >>
> >>
> >> Cheers,
> >> Julian


#10

Hi,

it seems for some reason it is not loading network address service.
Can you send me the logs as described https://jitsi.org/logs.

Regards
damencho

···

On Wed, Apr 1, 2015 at 6:07 PM, Julian Wollrath <jwollrath@web.de> wrote:

Am Wed, 1 Apr 2015 17:03:50 +0200 > schrieb Julian Wollrath <jwollrath@web.de>:

Am Wed, 1 Apr 2015 17:46:06 +0300 >> schrieb Damian Minkov <damencho@jitsi.org>:

> Hi,
>
> ok, we are fixing now the building stuff you reported. And will
> check later what can be the problem with sip account, cause without
> logs its hard to tell.
This should be, what your asking for:

16:07:42.679 SCHWERWIEGEND: [28]
impl.protocol.sip.SipStackSharing.<init>().139 Failed to get SIP
Factory. java.lang.NullPointerException: Specified service reference
cannot be null. at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at
net.java.sip.communicator.impl.protocol.sip.SipActivator.getNetworkAddressManagerService(SipActivator.java:159)
at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:134)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.initialize(ProtocolProviderServiceSipImpl.java:378)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:304)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)
16:07:42.679 SCHWERWIEGEND: [28]
impl.protocol.sip.ProtocolProviderFactorySipImpl.createService().312
Failed to initialize account
net.java.sip.communicator.service.protocol.OperationFailedException:
Failed to get SIP Factory at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:140)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.initialize(ProtocolProviderServiceSipImpl.java:378)
at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:304)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)
Caused by: java.lang.NullPointerException: Specified service reference
cannot be null. at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at
net.java.sip.communicator.impl.protocol.sip.SipActivator.getNetworkAddressManagerService(SipActivator.java:159)
at
net.java.sip.communicator.impl.protocol.sip.SipStackSharing.<init>(SipStackSharing.java:134) ...
8 more

16:07:42.680 SCHWERWIEGEND: [28]
service.protocol.AccountManager.doLoadStoredAccounts().208 Failed to
load account {Encodings.speex/16000=14,
OPT_CLIST_USE_SIP_CREDETIALS=false, AUTHORIZATION_NAME=xxx,
OVERRIDE_ENCODINGS=false, speex/8000=13, Encodings.GSM/8000=6,
Encodings.SILK/24000=11, SILK/12000=2, ACCOUNT_UID=SIP:xxx@xxx,
POLLING_PERIOD=30, PROTOCOL_NAME=SIP, DTMF_METHOD=AUTO_DTMF,
H263-1998/90000=0, Encodings.SILK/8000=1, SAVP_OPTION=0,
Encodings.SILK/16000=10, Encodings.H263-1998/90000=0, H264/90000=1100,
Encodings.PCMA/8000=8, USER_ID=xxx@xxx, KEEP_ALIVE_INTERVAL=25,
XCAP_ENABLE=false, ENCRYPTION_PROTOCOL_STATUS.SDES=false,
telephone-event/8000=3, SILK/8000=1, ENCRYPTION_PROTOCOL.ZRTP=0,
XIVO_ENABLE=false, PCMA/8000=8, PROXY_AUTO_CONFIG=false,
opus/48000=750, Encodings.VP8/90000=0, DISPLAY_NAME=xxx,
Encodings.speex/8000=13, Encodings.SILK/12000=2,
IS_PRESENCE_ENABLED=true, DEFAULT_SIPZRTP_ATTRIBUTE=true,
Encodings.PCMU/8000=9, Encodings.iLBC/8000=7, SILK/24000=11,
VP8/90000=0, DEFAULT_ENCRYPTION=true, Encodings.H264/90000=1100,
SERVER_ADDRESS=xxx, Encodings.G722/8000=12,
ENCRYPTION_PROTOCOL_STATUS.ZRTP=true, PROXY_ADDRESS=xxx,
KEEP_ALIVE_METHOD=OPTIONS, SILK/16000=10, PREFERRED_TRANSPORT=UDP,
SERVER_PORT=5060, Encodings.telephone-event/8000=3, PCMU/8000=9,
speex/32000=15, iLBC/8000=7, Encodings.speex/32000=15,
ENCRYPTED_PASSWORD=xxx, G722/8000=12, GSM/8000=6,
FORCE_P2P_MODE=false, PROXY_PORT=5060, Encodings.opus/48000=750,
ENCRYPTION_PROTOCOL.SDES=1, SUBSCRIPTION_EXPIRATION=3600,
SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32,
speex/16000=14} java.lang.IllegalArgumentException: Failed to
initialize accountFailed to get SIP Factory at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderFactorySipImpl.createService(ProtocolProviderFactorySipImpl.java:313)
at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.loadAccount(ProtocolProviderFactory.java:967)
at
net.java.sip.communicator.service.protocol.AccountManager.doLoadStoredAccounts(AccountManager.java:199)
at
net.java.sip.communicator.service.protocol.AccountManager.loadStoredAccounts(AccountManager.java:460)
at
net.java.sip.communicator.service.protocol.AccountManager.runInLoadStoredAccountsThread(AccountManager.java:576)
at
net.java.sip.communicator.service.protocol.AccountManager.access$100(AccountManager.java:25)
at
net.java.sip.communicator.service.protocol.AccountManager$2.run(AccountManager.java:501)

> Hum on mentors libjitsi is 593. I'm not sure where you get 598, but
> version mismatch can lead to unpredictable results.

When I built the 2.6 stable release, I generated the libjitsi-tarball
myself and got version 598 and stuck with it, since it worked. I built
jitsi 2.8 against libjitsi 598, so there is no problem, so I just the
libjitsi I built jitsi against.

> You need to update everything, or stick to some versions. We
> currently push to mentors the latest stable release.
>
> Regards
> damencho
>
>
> On Wed, Apr 1, 2015 at 5:40 PM, Julian Wollrath <jwollrath@web.de> >> > wrote:
> > Am Wed, 1 Apr 2015 16:35:37 +0200 >> > > schrieb Julian Wollrath <jwollrath@web.de>:
> >
> >> Hi,
> >>
> >> so I tried out jitsi_2.8.5426 with libjitsi_598 and the new
> >> dnsjava version and the SIP account, which worked and was shown
> >> with jitsi_2.4.4997-1.2, was not shown anymore and therefore did
> >> not work. Furthermore, I was not able to add the account again.
> >
> > Btw.: With jitsi 2.6.5390 and libjitsi 598 it worked.
> >
> >>
> >>
> >> Cheers,
> >> Julian


#11

Hi,

actually I now think, that dnsjava is the source of the problem, since
jitsi 2.4.4997-1.2 had the same problem with dnsjava 2.1.7-0.1 but not
with dnsjava 2.1.5-0.1.

Cheers,
Julian

···

Am Wed, 1 Apr 2015 18:19:03 +0200 schrieb Julian Wollrath <jwollrath@web.de>:

Hi,

> it seems for some reason it is not loading network address service.
> Can you send me the logs as described https://jitsi.org/logs.
no problem, see the attached file.

Furthermore, here is also the system information:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.3 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jitsi depends on:
ii default-jre [java6-runtime] 2:1.7-52
ii jitsi-common 2.8.5426-1
ii jitsi-jni 2.8.5426-1
ii libbcprov-java 1.49+dfsg-3
ii libcommons-codec-java 1.9-1
ii libcommons-lang3-java 3.3.2-1
ii libcommons-logging-java 1.2-1
ii libdbus-java 2.8-6
ii libfelix-framework-java 4.4.0-1
ii libfelix-main-java 4.4.0-1
ii libguava-java 17.0-1
ii libhsqldb-java 2.2.9+dfsg-4
ii libhttpclient-java 4.3.5-2
ii libhttpcore-java 4.3.3-1
ii libhttpmime-java 4.3.5-2
ii libjcalendar-java 1.3.3-3
ii libjgoodies-forms-java 1.6.0-4
ii libjitsi 593-1
ii libjitsi-jni 593-1
ii libjmdns-java 3.4.1-2
ii libjna-java 4.1.0-1
ii libjna-platform-java 4.1.0-1
ii libjson-simple-java 1.1.1-3
ii liblaf-widget-java 4.3-2
ii liblog4j1.2-java 1.2.17-5
ii libmac-widgets-java 0.10.0+svn416-dfsg1-1
ii libphonenumber6-java 6.3~svn698-3
ii libslf4j-java 1.7.7-1
ii libunixsocket-java 0.7.3-1
ii libweupnp-java 0.1.2-1
ii openjdk-7-jre [java6-runtime] 7u75-2.5.4-3

Cheers,
Julian


#12

Hi again,

we have updated libjitsi and jitsi package on mentors. We fixed the
problem you mention with offline building.
We also fixed the problem with loading the sip account which was due
to the new dnsjava package, which we also updated. It had a wrong
bundle import which cannot be resolved: "android.os".

Regards
damencho

···

On Wed, Apr 1, 2015 at 7:27 PM, Julian Wollrath <jwollrath@web.de> wrote:

Hi,

actually I now think, that dnsjava is the source of the problem, since
jitsi 2.4.4997-1.2 had the same problem with dnsjava 2.1.7-0.1 but not
with dnsjava 2.1.5-0.1.

Cheers,
Julian

Am Wed, 1 Apr 2015 18:19:03 +0200 > schrieb Julian Wollrath <jwollrath@web.de>:

Hi,

> it seems for some reason it is not loading network address service.
> Can you send me the logs as described https://jitsi.org/logs.
no problem, see the attached file.

Furthermore, here is also the system information:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.3 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jitsi depends on:
ii default-jre [java6-runtime] 2:1.7-52
ii jitsi-common 2.8.5426-1
ii jitsi-jni 2.8.5426-1
ii libbcprov-java 1.49+dfsg-3
ii libcommons-codec-java 1.9-1
ii libcommons-lang3-java 3.3.2-1
ii libcommons-logging-java 1.2-1
ii libdbus-java 2.8-6
ii libfelix-framework-java 4.4.0-1
ii libfelix-main-java 4.4.0-1
ii libguava-java 17.0-1
ii libhsqldb-java 2.2.9+dfsg-4
ii libhttpclient-java 4.3.5-2
ii libhttpcore-java 4.3.3-1
ii libhttpmime-java 4.3.5-2
ii libjcalendar-java 1.3.3-3
ii libjgoodies-forms-java 1.6.0-4
ii libjitsi 593-1
ii libjitsi-jni 593-1
ii libjmdns-java 3.4.1-2
ii libjna-java 4.1.0-1
ii libjna-platform-java 4.1.0-1
ii libjson-simple-java 1.1.1-3
ii liblaf-widget-java 4.3-2
ii liblog4j1.2-java 1.2.17-5
ii libmac-widgets-java 0.10.0+svn416-dfsg1-1
ii libphonenumber6-java 6.3~svn698-3
ii libslf4j-java 1.7.7-1
ii libunixsocket-java 0.7.3-1
ii libweupnp-java 0.1.2-1
ii openjdk-7-jre [java6-runtime] 7u75-2.5.4-3

Cheers,
Julian


#13

Hi,

we have updated libjitsi and jitsi package on mentors. We fixed the
problem you mention with offline building.
We also fixed the problem with loading the sip account which was due
to the new dnsjava package, which we also updated. It had a wrong
bundle import which cannot be resolved: "android.os".

thank you for the quick response and the fixes.

Cheers,
Julian


#14

Hi,

we have updated libjitsi and jitsi package on mentors.

lintian still reports some warnings (see below for the verbose versions
of them). Some of them are not very important but you should really have
a look at the ones concerning debian/copyright.

Furthermore, the tarball one gets with uscan (with help debian/watch)
for libjitsi-593 is not the same as you provided as the original
tarball, instead the tarball you provided can be generated from that
one. The way I see it, others may disagree, one should get the original
tarball you provided via uscan. If that is not possible, than I do not
see the value in having debian/watch since it only brings confusion.

Cheers,
Julian

$ lintian --info --pedantic --display-info libjitsi_593-1_amd64.changes
I: libjitsi source: quilt-patch-missing-description remove-gsm
N:
N: quilt patch files should start with a description of patch. All lines
N: before the start of the patch itself are considered part of the
N: description. You can edit the description with quilt header -e when the
N: patch is at the top of the stack.
N:
N: As well as a description of the purpose and function of the patch, the
N: description should ideally contain author information, a URL for the bug
N: report (if any), Debian or upstream bugs fixed by it, upstream status,
N: the Debian version and date the patch was first included, and any other
N: information that would be useful if someone were investigating the patch
N: and underlying problem. Please consider using the DEP-3 format for this
N: information.
N:
N: Refer to http://dep.debian.net/deps/dep3/ for details.
N:
N: Severity: wishlist, Certainty: certain
N:
N: Check: patch-systems, Type: source
N:
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.capture/net/sf/fmj/media/protocol/javasound/SimpleAudioRecorder.java (paragraph at line 15)
N:
N: The wildcard that was specified matches no file in the source tree. This
N: either indicates that you should fix the wildcard so that it matches the
N: intended file or that you can remove the wildcard. Notice that in
N: contrast to shell globs, the "*" (star or asterisk) matches slashes and
N: leading dots.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTPParticipant.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPReport.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPSenderInfo.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPHeader.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPSenderReport.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTPHeader.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPFeedback.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright lib/src/bccontrib/src/main/java/prng/* (paragraph at line 56)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright lib/src/sdes4j/* (paragraph at line 73)
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 15
N:
N: The Files paragraph in debian/copyright is superfluous as it is never
N: used to match any files. You should be able to safely remove it.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 19
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 30
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 56
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 73
I: libjitsi source: unused-license-paragraph-in-dep5-copyright lgpl-2 (paragraph at line 113)
N:
N: The license paragraph in the machine-readable copyright file is not
N: referenced by any files paragraph. It could be a typo in the license
N: name or the license paragraph is simply not needed and can be removed.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
P: libjitsi source: debian-watch-may-check-gpg-signature
N:
N: This watch file does not include a means to verify the upstream tarball
N: using cryptographic signature.
N:
N: If upstream distributions provide such signatures, please use the
N: pgpsigurlmangle options in this watch file's opts= to generate the URL
N: of an upstream GPG signature. This signature is automatically downloaded
N: and verified against a keyring stored in
N: debian/upstream-signing-key.asc.
N:
N: Of course, not all upstreams provide such signatures, but you could
N: request them as a way of verifying that no third party has modified the
N: code against their wishes after the release. Projects such as
N: phpmyadmin, unrealircd, and proftpd have suffered from this kind of
N: attack.
N:
N: Refer to the uscan(1) manual page for details.
N:
N: Severity: pedantic, Certainty: certain
N:
N: Check: watch-file, Type: source
N:
P: libjitsi: no-upstream-changelog
N:
N: The package does not install an upstream changelog file. If upstream
N: provides a changelog, it should be accessible as
N: /usr/share/doc/<pkg>/changelog.gz.
N:
N: It's currently unclear how best to handle multiple binary packages from
N: the same source. Some maintainers put a copy of the upstream changelog
N: in each package, but it can be quite long. Some include it in one
N: package and add symlinks to the other packages, but this requires there
N: be dependencies between the packages. Some only include it in a
N: "central" binary package and omit it from more ancillary packages.
N:
N: Refer to Debian Policy Manual section 12.7 (Changelog files) for
N: details.
N:
N: Severity: pedantic, Certainty: wild-guess
N:
N: Check: changelog-file, Type: binary
N:
I: libjitsi-jni: spelling-error-in-binary usr/lib/jni/libjnsctp.so prefered preferred
N:
N: Lintian found a spelling error in the given binary. Lintian has a list
N: of common misspellings that it looks for. It does not have a dictionary
N: like a spelling checker does.
N:
N: If the string containing the spelling error is translated with the help
N: of gettext or a similar tool, please fix the error in the translations
N: as well as the English text to avoid making the translations fuzzy. With
N: gettext, for example, this means you should also fix the spelling
N: mistake in the corresponding msgids in the *.po files.
N:
N: You can often find the word in the source code by running:
N:
N: grep -rw <word> <source-tree>
N:
N: This tag may produce false positives for words that contain non-ASCII
N: characters due to limitations in strings.
N:
N: Severity: minor, Certainty: wild-guess
N:
N: Check: binaries, Type: binary, udeb
N:
P: libjitsi-jni: no-upstream-changelog


#15

Hi,

we wanted to submit the stable build, the one we submitted in jitsi's
repo. The watch file was required to have it when we were submitting
the package the previous time, I can remove it, but I'm not sure that
somebody will again want to include it.
I don't see the problem of pushing a particular version. Anyway the
process of accepting a package is so slow and sometimes takes months,
it will always have updates as the project is alive and have few
builds a day, so I can keep pushing builds... but cannot be sure what
will be in there. So that is the reason we want to push those
particular versions.

Regards
damencho

···

On Thu, Apr 2, 2015 at 8:13 PM, Julian Wollrath <jwollrath@web.de> wrote:

Hi,

we have updated libjitsi and jitsi package on mentors.

lintian still reports some warnings (see below for the verbose versions
of them). Some of them are not very important but you should really have
a look at the ones concerning debian/copyright.

Furthermore, the tarball one gets with uscan (with help debian/watch)
for libjitsi-593 is not the same as you provided as the original
tarball, instead the tarball you provided can be generated from that
one. The way I see it, others may disagree, one should get the original
tarball you provided via uscan. If that is not possible, than I do not
see the value in having debian/watch since it only brings confusion.

Cheers,
Julian

$ lintian --info --pedantic --display-info libjitsi_593-1_amd64.changes
I: libjitsi source: quilt-patch-missing-description remove-gsm
N:
N: quilt patch files should start with a description of patch. All lines
N: before the start of the patch itself are considered part of the
N: description. You can edit the description with quilt header -e when the
N: patch is at the top of the stack.
N:
N: As well as a description of the purpose and function of the patch, the
N: description should ideally contain author information, a URL for the bug
N: report (if any), Debian or upstream bugs fixed by it, upstream status,
N: the Debian version and date the patch was first included, and any other
N: information that would be useful if someone were investigating the patch
N: and underlying problem. Please consider using the DEP-3 format for this
N: information.
N:
N: Refer to http://dep.debian.net/deps/dep3/ for details.
N:
N: Severity: wishlist, Certainty: certain
N:
N: Check: patch-systems, Type: source
N:
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.capture/net/sf/fmj/media/protocol/javasound/SimpleAudioRecorder.java (paragraph at line 15)
N:
N: The wildcard that was specified matches no file in the source tree. This
N: either indicates that you should fix the wildcard so that it matches the
N: intended file or that you can remove the wildcard. Notice that in
N: contrast to shell globs, the "*" (star or asterisk) matches slashes and
N: leading dots.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTPParticipant.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPReport.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPSenderInfo.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPHeader.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPSenderReport.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTPHeader.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright src.rtp/net/sf/fmj/media/rtp/RTCPFeedback.java (paragraph at line 19)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright lib/src/bccontrib/src/main/java/prng/* (paragraph at line 56)
I: libjitsi source: wildcard-matches-nothing-in-dep5-copyright lib/src/sdes4j/* (paragraph at line 73)
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 15
N:
N: The Files paragraph in debian/copyright is superfluous as it is never
N: used to match any files. You should be able to safely remove it.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 19
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 30
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 56
I: libjitsi source: unused-file-paragraph-in-dep5-copyright paragraph at line 73
I: libjitsi source: unused-license-paragraph-in-dep5-copyright lgpl-2 (paragraph at line 113)
N:
N: The license paragraph in the machine-readable copyright file is not
N: referenced by any files paragraph. It could be a typo in the license
N: name or the license paragraph is simply not needed and can be removed.
N:
N: Refer to
N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N: details.
N:
N: Severity: minor, Certainty: possible
N:
N: Check: source-copyright, Type: source
N:
P: libjitsi source: debian-watch-may-check-gpg-signature
N:
N: This watch file does not include a means to verify the upstream tarball
N: using cryptographic signature.
N:
N: If upstream distributions provide such signatures, please use the
N: pgpsigurlmangle options in this watch file's opts= to generate the URL
N: of an upstream GPG signature. This signature is automatically downloaded
N: and verified against a keyring stored in
N: debian/upstream-signing-key.asc.
N:
N: Of course, not all upstreams provide such signatures, but you could
N: request them as a way of verifying that no third party has modified the
N: code against their wishes after the release. Projects such as
N: phpmyadmin, unrealircd, and proftpd have suffered from this kind of
N: attack.
N:
N: Refer to the uscan(1) manual page for details.
N:
N: Severity: pedantic, Certainty: certain
N:
N: Check: watch-file, Type: source
N:
P: libjitsi: no-upstream-changelog
N:
N: The package does not install an upstream changelog file. If upstream
N: provides a changelog, it should be accessible as
N: /usr/share/doc/<pkg>/changelog.gz.
N:
N: It's currently unclear how best to handle multiple binary packages from
N: the same source. Some maintainers put a copy of the upstream changelog
N: in each package, but it can be quite long. Some include it in one
N: package and add symlinks to the other packages, but this requires there
N: be dependencies between the packages. Some only include it in a
N: "central" binary package and omit it from more ancillary packages.
N:
N: Refer to Debian Policy Manual section 12.7 (Changelog files) for
N: details.
N:
N: Severity: pedantic, Certainty: wild-guess
N:
N: Check: changelog-file, Type: binary
N:
I: libjitsi-jni: spelling-error-in-binary usr/lib/jni/libjnsctp.so prefered preferred
N:
N: Lintian found a spelling error in the given binary. Lintian has a list
N: of common misspellings that it looks for. It does not have a dictionary
N: like a spelling checker does.
N:
N: If the string containing the spelling error is translated with the help
N: of gettext or a similar tool, please fix the error in the translations
N: as well as the English text to avoid making the translations fuzzy. With
N: gettext, for example, this means you should also fix the spelling
N: mistake in the corresponding msgids in the *.po files.
N:
N: You can often find the word in the source code by running:
N:
N: grep -rw <word> <source-tree>
N:
N: This tag may produce false positives for words that contain non-ASCII
N: characters due to limitations in strings.
N:
N: Severity: minor, Certainty: wild-guess
N:
N: Check: binaries, Type: binary, udeb
N:
P: libjitsi-jni: no-upstream-changelog


#16

Hi,

we wanted to submit the stable build, the one we submitted in jitsi's
repo.

that is totally reasonable and I wholeheartedly agree that it only makes
sense to push stable builds and not some random development builds. The
point I tried to make is the following: If I download the
libjitsi_593.orig.tar.gz from mentors.debian.net it has different
contents than the 593.tar.gz I get at [1], which would be the one uscan
would download since debian/watch points to it. One could generate the
libjitsi_593.orig.tar.gz you provided from the tarball one gets from
[1] but in my opinion that should not be necessary; one should be able
to get the libjitsi_593.orig.tar.gz via uscan or the debian/watch file
should be omitted since, it provides - at least in my opinion - not
much of a value otherwise. I hope that makes it clearer, what I tried
to say.

The watch file was required to have it when we were submitting
the package the previous time, I can remove it, but I'm not sure that
somebody will again want to include it.

Then keep it but, as I tried to explain, in my opinion it does not have
to much of a value in its current state.

Cheers,
Julian

[1] https://github.com/jitsi/libjitsi/archives/593.tar.gz

···

I don't see the problem of pushing a particular version. Anyway the
process of accepting a package is so slow and sometimes takes months,
it will always have updates as the project is alive and have few
builds a day, so I can keep pushing builds... but cannot be sure what
will be in there. So that is the reason we want to push those
particular versions.


#17

we wanted to submit the stable build, the one we submitted in jitsi's
repo.

that is totally reasonable and I wholeheartedly agree that it only makes
sense to push stable builds and not some random development builds. The
point I tried to make is the following: If I download the
libjitsi_593.orig.tar.gz from mentors.debian.net it has different
contents than the 593.tar.gz I get at [1], which would be the one uscan
would download since debian/watch points to it. One could generate the
libjitsi_593.orig.tar.gz you provided from the tarball one gets from
[1] but in my opinion that should not be necessary; one should be able
to get the libjitsi_593.orig.tar.gz via uscan or the debian/watch file
should be omitted since, it provides - at least in my opinion - not
much of a value otherwise. I hope that makes it clearer, what I tried
to say.

Damian, would it be possible to upload the modified 2.8.5426 version again to download.jitsi.org, say as jitsi_2.8.5426-1.orig.tar.gz? For libjitsi, a branch could be created that has tag 593 as its base, then cherry-pick the Debian changes on top of it, and tag it again as 593-1.

Then modify the watch-regex accordingly to catch -n versions if they're available.

The watch file was required to have it when we were submitting
the package the previous time, I can remove it, but I'm not sure that
somebody will again want to include it.

Then keep it but, as I tried to explain, in my opinion it does not have
to much of a value in its current state.

Cheers,
Julian

[1] https://github.com/jitsi/libjitsi/archives/593.tar.gz

Ingo


#18

Hi,

we wanted to submit the stable build, the one we submitted in jitsi's
repo.

that is totally reasonable and I wholeheartedly agree that it only makes
sense to push stable builds and not some random development builds. The
point I tried to make is the following: If I download the
libjitsi_593.orig.tar.gz from mentors.debian.net it has different
contents than the 593.tar.gz I get at [1], which would be the one uscan
would download since debian/watch points to it. One could generate the
libjitsi_593.orig.tar.gz you provided from the tarball one gets from
[1] but in my opinion that should not be necessary; one should be able
to get the libjitsi_593.orig.tar.gz via uscan or the debian/watch file
should be omitted since, it provides - at least in my opinion - not
much of a value otherwise. I hope that makes it clearer, what I tried
to say.

Damian, would it be possible to upload the modified 2.8.5426 version again to download.jitsi.org, say as jitsi_2.8.5426-1.orig.tar.gz? For libjitsi, a branch could be created that has tag 593 as its base, then cherry-pick the Debian changes on top of it, and tag it again as 593-1.

We can create such branches for libjitsi and jitsi as both has
modified debian folder.
What about the .orig.tar.gz why we need it? Or you mean to upload it
on the download where we auto-generate those ? Well I can upload it
once the package is accepted as it may have more modifications to come
... and it is uploaded currently on mentors, why we need it on two
places, or I'm getting it wrong?

Then modify the watch-regex accordingly to catch -n versions if they're available.

Didn't get this?
The current watch files are checking the release page on github.

Regards
damencho

···

On Fri, Apr 3, 2015 at 12:23 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The watch file was required to have it when we were submitting
the package the previous time, I can remove it, but I'm not sure that
somebody will again want to include it.

Then keep it but, as I tried to explain, in my opinion it does not have
to much of a value in its current state.

Cheers,
Julian

[1] https://github.com/jitsi/libjitsi/archives/593.tar.gz

Ingo


#19

we wanted to submit the stable build, the one we submitted in jitsi's
repo.

that is totally reasonable and I wholeheartedly agree that it only makes
sense to push stable builds and not some random development builds. The
point I tried to make is the following: If I download the
libjitsi_593.orig.tar.gz from mentors.debian.net it has different
contents than the 593.tar.gz I get at [1], which would be the one uscan
would download since debian/watch points to it. One could generate the
libjitsi_593.orig.tar.gz you provided from the tarball one gets from
[1] but in my opinion that should not be necessary; one should be able
to get the libjitsi_593.orig.tar.gz via uscan or the debian/watch file
should be omitted since, it provides - at least in my opinion - not
much of a value otherwise. I hope that makes it clearer, what I tried
to say.

Damian, would it be possible to upload the modified 2.8.5426 version again
to download.jitsi.org, say as jitsi_2.8.5426-1.orig.tar.gz? For libjitsi, a
branch could be created that has tag 593 as its base, then cherry-pick the
Debian changes on top of it, and tag it again as 593-1.

We can create such branches for libjitsi and jitsi as both has
modified debian folder.

That would be really good to have.

What about the .orig.tar.gz why we need it? Or you mean to upload it
on the download where we auto-generate those ? Well I can upload it
once the package is accepted as it may have more modifications to come
... and it is uploaded currently on mentors, why we need it on two
places, or I'm getting it wrong?

As far as I understand the process, it should be possible to build the Debian binaries by only having the /debian folder (or the xxx.debian.tar.xz). A part of the build process (uscan?) should then be able to download the xxx.orig.tar.gz from upstream (download.jitsi.org). Julian, please correct me if I got this wrong.

Then modify the watch-regex accordingly to catch -n versions if they're
available.

Didn't get this?
The current watch files are checking the release page on github.

Yes, for libjitsi. Example: if there are the versions 592, 593, 593-1, 594, then it should pick up 593-1 but not 593. As we don't have a stable/unstable release line there, I'm not sure how to deal with the 594 version. Then the watch to Github is IMO a bit dangerous anyway: the archive-zip you can download from there is not the libjits_X.orig.tar.gz that Debian will use (I don't even know where to get that).

Currently all the tags we have are the autogenerated ones from Jenkins. Maybe we could start creating manual tags for stable releases, like the one I did for 2.2, and then only use these in the watch file. Currently every update fix for a Debian upload will make the upstream-watcher complain when it shouldn't, but it should report when we've done a stable release.

Regards
damencho

Ingo

···

On Fri, Apr 3, 2015 at 12:23 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:


#20

Hi,

ok I will try to summarize the tasks so we can create issues cause it
can be really confusing and forget something.
There are a lot of things we must do, for such a simple thing to
publish a packet ...

Regards
damencho

···

On Fri, Apr 3, 2015 at 1:14 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

On Fri, Apr 3, 2015 at 12:23 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

we wanted to submit the stable build, the one we submitted in jitsi's
repo.

that is totally reasonable and I wholeheartedly agree that it only makes
sense to push stable builds and not some random development builds. The
point I tried to make is the following: If I download the
libjitsi_593.orig.tar.gz from mentors.debian.net it has different
contents than the 593.tar.gz I get at [1], which would be the one uscan
would download since debian/watch points to it. One could generate the
libjitsi_593.orig.tar.gz you provided from the tarball one gets from
[1] but in my opinion that should not be necessary; one should be able
to get the libjitsi_593.orig.tar.gz via uscan or the debian/watch file
should be omitted since, it provides - at least in my opinion - not
much of a value otherwise. I hope that makes it clearer, what I tried
to say.

Damian, would it be possible to upload the modified 2.8.5426 version again
to download.jitsi.org, say as jitsi_2.8.5426-1.orig.tar.gz? For libjitsi, a
branch could be created that has tag 593 as its base, then cherry-pick the
Debian changes on top of it, and tag it again as 593-1.

We can create such branches for libjitsi and jitsi as both has
modified debian folder.

That would be really good to have.

What about the .orig.tar.gz why we need it? Or you mean to upload it
on the download where we auto-generate those ? Well I can upload it
once the package is accepted as it may have more modifications to come
... and it is uploaded currently on mentors, why we need it on two
places, or I'm getting it wrong?

As far as I understand the process, it should be possible to build the Debian binaries by only having the /debian folder (or the xxx.debian.tar.xz). A part of the build process (uscan?) should then be able to download the xxx.orig.tar.gz from upstream (download.jitsi.org). Julian, please correct me if I got this wrong.

Then modify the watch-regex accordingly to catch -n versions if they're
available.

Didn't get this?
The current watch files are checking the release page on github.

Yes, for libjitsi. Example: if there are the versions 592, 593, 593-1, 594, then it should pick up 593-1 but not 593. As we don't have a stable/unstable release line there, I'm not sure how to deal with the 594 version. Then the watch to Github is IMO a bit dangerous anyway: the archive-zip you can download from there is not the libjits_X.orig.tar.gz that Debian will use (I don't even know where to get that).

Currently all the tags we have are the autogenerated ones from Jenkins. Maybe we could start creating manual tags for stable releases, like the one I did for 2.2, and then only use these in the watch file. Currently every update fix for a Debian upload will make the upstream-watcher complain when it shouldn't, but it should report when we've done a stable release.

Regards
damencho

Ingo