Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

Hi,

A new strange thing, I don't know if you encountered that, today at 6h32
packagekit run, tried to restart gitlab, and failed:

Nov 27 06:32:18 weboob dbus-daemon[464]: [system] Activating via systemd: 
service name='org.freedesktop.PackageKit' unit='packagekit.service' requested 
by ':1.10456' (uid=0 pid=28562 comm="/usr/bin/gdbus call --system --dest 
org.freedeskto")
Nov 27 06:32:18 weboob systemd[1]: Starting PackageKit Daemon...
Nov 27 06:32:18 weboob PackageKit: daemon start
Nov 27 06:32:18 weboob dbus-daemon[464]: [system] Successfully activated 
service 'org.freedesktop.PackageKit'
Nov 27 06:32:18 weboob systemd[1]: Started PackageKit Daemon.
Nov 27 06:32:18 weboob gitlab-workhorse[20628]: git.weboob.org 46.229.168.139 - 
- [2019/11/27:06:32:18 +0100] "GET 
/P4ncake/devel/tree/6f5f41fe574ad35b11e024b7c10bb2950d0689b2 HTTP/1.1" 200 
40794 "" "Mozilla/5.0 (compatible; SemrushBot/6~bl; 
+http://www.semrush.com/bot.html)" %!f(int64=108)
Nov 27 06:32:19 weboob systemd[1]: Reloading.
Nov 27 06:32:19 weboob systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
Nov 27 06:32:19 weboob systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no effect as configuration data is accessible via 
APIs without restrictions. Proceeding anyway.
Nov 27 06:32:19 weboob systemd[1]: 
/lib/systemd/system/gitlab-sidekiq.service:18: Ignoring unknown escape 
sequences: "for i in 4 4 4 4 4 4 4 4; do sleep $i; (ps -h -o command -p 
$MAINPID | grep -q -P "sidekiq \d\.\d\.\d") && exit 0; done"
Nov 27 06:32:19 weboob systemd[1]: /lib/systemd/system/docker.socket:6: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/docker.sock → /run/docker.sock; please update the unit file 
accordingly.
Nov 27 06:32:20 weboob systemd[1]: Reloading.
Nov 27 06:32:20 weboob systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
Nov 27 06:32:20 weboob systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no effect as configuration data is accessible via 
APIs without restrictions. Proceeding anyway.
Nov 27 06:32:20 weboob systemd[1]: 
/lib/systemd/system/gitlab-sidekiq.service:18: Ignoring unknown escape 
sequences: "for i in 4 4 4 4 4 4 4 4; do sleep $i; (ps -h -o command -p 
$MAINPID | grep -q -P "sidekiq \d\.\d\.\d") && exit 0; done"
Nov 27 06:32:20 weboob systemd[1]: /lib/systemd/system/docker.socket:6: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/docker.sock → /run/docker.sock; please update the unit file 
accordingly.
Nov 27 06:32:20 weboob systemd[1]: Reloading.
Nov 27 06:32:20 weboob systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
Nov 27 06:32:20 weboob systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no effect as configuration data is accessible via 
APIs without restrictions. Proceeding anyway.
Nov 27 06:32:20 weboob systemd[1]: 
/lib/systemd/system/gitlab-sidekiq.service:18: Ignoring unknown escape 
sequences: "for i in 4 4 4 4 4 4 4 4; do sleep $i; (ps -h -o command -p 
$MAINPID | grep -q -P "sidekiq \d\.\d\.\d") && exit 0; done"
Nov 27 06:32:20 weboob systemd[1]: /lib/systemd/system/docker.socket:6: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/docker.sock → /run/docker.sock; please update the unit file 
accordingly.
Nov 27 06:32:20 weboob gitaly[20604]: time="2019-11-27T06:32:20+01:00" 
level=error msg="lstat /var/lib/gitlab/repositories/+gitaly/cache: no such file 
or directory" storage=default
Nov 27 06:32:20 weboob systemd[1]: Reloading.
Nov 27 06:32:21 weboob systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
Nov 27 06:32:21 weboob systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no effect as configuration data is accessible via 
APIs without restrictions. Proceeding anyway.
Nov 27 06:32:21 weboob systemd[1]: 
/lib/systemd/system/gitlab-sidekiq.service:18: Ignoring unknown escape 
sequences: "for i in 4 4 4 4 4 4 4 4; do sleep $i; (ps -h -o command -p 
$MAINPID | grep -q -P "sidekiq \d\.\d\.\d") && exit 0; done"
Nov 27 06:32:21 weboob 

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

On 14/Nov - 07:45, Pirate Praveen wrote:
>  has protobuf 3.7 and grpc 1.19.
> You need to downgrade both and use gitaly 1.59.3+dfsg-1~bpo10+2 (which
> allows these versions).
> 
> And because of 
> you may need to regenrate Gemfile.lock
> 
> # cd /usr/share/gitlab
> # sudo -u gitlab truncate -s0 Gemfile.lock
> # sudo -u gitlab bundle install --local
> # systemctl restart gitlab-sidekiq
> # systemctl restart gitlab gitaly
> 
> I had to use a separate repo with protobuf 3.10 and grpc 1.23 ->
> https://people.debian.org/~praveen/protobuf/ to build gitaly
> 
> I'm keeping this bug open till we can use same version of protobuf for both
> gitaly build and gitlab. I have opened
> https://gitlab.com/gitlab-org/gitaly/issues/2164 to work with upstream on
> this

Great it works, thank you. Please tell us when the issue is fixed in the
experimental repository and that we can upgrade all versions from this
repository, as it is currently somewhat a hot fix.

Romain

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

Hello,

The problem is still here, and is so not related to compatibility between
versions of gitlab/gitlab-shell/gitality…

Is there anything I can do to find the origin of this issue?

Romain

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

On 23/Oct - 14:31, Pirate Praveen wrote:
> just share apt policy gitaly for confirmation and the error messages once
> more (after you restart gitaly and gitlab services).

gitaly:
  Installed: 1.58.0+dfsg-2
  Candidate: 1.58.0+dfsg-2
  Version table:
 *** 1.58.0+dfsg-2 100
  1 http://ftp.de.debian.org/debian experimental/main amd64 Packages
100 /var/lib/dpkg/status
 1.20.0+debian-1+b1 -1
 -1 http://ftp.de.debian.org/debian unstable/main amd64 Packages

And the error message client side:

$ git fetch
gitaly-upload-pack: fatal: error: %v
fatal: Could not read from remote repository.

Server side:

time="2019-10-23T15:53:54+02:00" level=info msg="finished HTTP request" 
duration=0.03395727 gitaly_embedded=false method=POST pid=8834 
url="http://localhost:8080/api/v4/internal/allowed;
time="2019-10-23T15:53:54+02:00" level=info msg="executing git command" 
command="gitaly-upload-pack unix:/run/gitlab/sockets/private/gitaly.socket 
{\"repository\":{},\"gl_repository\":\"project-2\",\"gl_project_path\":\"romain/weboob\",\"gl_id\":\"key-3\",\"gl_username\":\"romain\",\"git_config_options\":[],\"git_protocol\":null}"
 pid=8834 user="user with id key-3"
time="2019-10-23T15:53:54+02:00" level=error msg="error: %v" error="rpc error: 
code = InvalidArgument desc = Storage can not be found by name ''" pid=8834

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

On 22/Oct - 22:47, Pirate Praveen wrote:
> All those packages are available in experimental. I have updated
> https://wiki.debian.org/gitlab with these packages added to the list of
> pcakges needed from experimental.

I've installed these packages and correctly upgraded gitlab and all
dependencies, even gitlab-shell, and the problem still exists…

What can I do to help debugging?

Romain

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

On 22/Oct - 19:18, Pirate Praveen wrote:
> This is building fine on my system. So uploaded binary included as work
> around.

Note that I see a newer version of gitlb available:

 root@weboob ~ # apt-cache policy gitlab
gitlab:
  Installed: 12.1.14-1
  Candidate: 12.1.14-1
  Version table:
 12.2.8-1 1
  1 http://ftp.de.debian.org/debian experimental/contrib amd64 Packages
 *** 12.1.14-1 100
100 /var/lib/dpkg/status
 11.8.10+dfsg-1 -1
 -1 http://ftp.de.debian.org/debian unstable/contrib amd64 Packages

But it is not possible to install it as there are broken dependencies:

 root@weboob ~ # apt install gitlab/experimental
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '12.2.8-1' (Debian:experimental [all]) for 'gitlab'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gitlab : Depends: ruby-invisible-captcha (>= 0.12.1~) but it is not installable
  Depends: ruby-gitlab-sidekiq-fetcher (>= 0.5.1~) but 0.4.0-2 is to be 
installed
  Depends: ruby-redis (>= 4.0~) but 3.3.5-1 is to be installed
  Depends: ruby-gitlab-labkit (>= 0.4.2-2~) but 0.4.2-1 is to be 
installed
  Depends: ruby-statistics but it is not installable
  Depends: ruby-gitaly (>= 1.58~) but 1.37.0+dfsg-1 is to be installed
E: Unable to correct problems, you have held broken packages.

Do you think you'll be able to upload a newer fixed version of gitaly soon? Or
is there any workaround?

Romain

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

Hi,

On 21/Oct - 21:21, Pirate Praveen wrote:
> > At least for Romain that seems to be the problem.
> > 
> > ii  gitaly   1.47.3+debian-1
> > 
> > $ apt policy gitaly
> > gitaly:
> >   Installed: 1.53.3+debian-1~bpo10+1
> >   Candidate: 1.53.3+debian-1~bpo10+1
> >   Version table:
> >  *** 1.53.3+debian-1~bpo10+1 500
> > 500 
> > buster-backports/main amd64 Packages
> > 100 /var/lib/dpkg/status
> 
> This is actually a bug as minimum version for gitaly was not updated in
> gitlab.

1.47.3+debian-1 is the latest version available on Debian experimental.

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

Package: gitlab
Version: 12.1.14-1
Severity: important

Dear Maintainer,

During the installation of the package, this warning is displayed:

GitLab Shell: ... GitLab Shell version >= 9.3.0 ? ... FAIL. Please update 
gitlab-shell to 9.3.0 from 9.1.0

But currently the latest version of gitlab-shell available in
experimental is 9.1.0.

It is not possible anymore to interact with the repository through ssh:

$ git fetch
gitaly-upload-pack: fatal: error: %v
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
$

Server-side, this error is displayed in gitlab-shell logs:

time="2019-10-19T11:04:07+02:00" level=info msg="finished HTTP request" 
duration=0.014533625 gitaly_embedded=false method=POST pid=426 
url="http://localhost:8080/api/v4/internal/allowed;
time="2019-10-19T11:04:07+02:00" level=info msg="executing git command" 
command="gitaly-upload-pack unix:/run/gitlab/sockets/private/gitaly.socket 
{\"repository\":{},\"gl_repository\":\"project-2\",\"gl_project_path\":\"romain/weboob\",\"gl_id\":\"key-3\",\"gl_username\":\"romain\",\"git_config_options\":[],\"git_protocol\":null}"
 pid=426 user="user with id key-3"
time="2019-10-19T11:04:07+02:00" level=error msg="error: %v" error="rpc error: 
code = InvalidArgument desc = Storage can not be found by name ''" pid=426

I don't know if the two issues are related, but there is a good chance.

The solution would be to package gitlab-shell 9.3.0 in experimental.

Best regards,

Romain

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.10-2
ii  bc  1.07.1-2+b2
ii  bundler 1.17.3-3
ii  bzip2   1.0.8-2
ii  dbconfig-pgsql  2.0.13
ii  debconf [debconf-2.0]   1.5.73
ii  gitlab-common   12.1.14-1
ii  gitlab-workhorse8.5.2+debian-1
ii  libjs-bootstrap4 [node-bootstrap]   4.3.1+dfsg2-1
ii  libjs-pdf   1.5.188+dfsg-1
ii  libjs-popper.js [node-popper.js]1.14.6+ds2-2
ii  libjs-uglify2.8.29-6
ii  lsb-base11.1.0
ii  nginx   1.16.1-2
ii  nginx-extras [nginx]1.16.1-2
ii  node-autosize   4.0.2~dfsg1-3
ii  node-axios  0.19.0+dfsg-2
ii  node-brace-expansion1.1.8-1
ii  node-cache-loader   2.0.1-2
ii  node-chart.js   2.7.3+dfsg-5
ii  node-core-js2.4.1-2
ii  node-css-loader 1.0.1-1
ii  node-d3 4.13.0-10
ii  node-d3-array   1.2.4-2
ii  node-d3-axis1.0.12-2
ii  node-d3-brush   1.0.6-3
ii  node-d3-ease1.0.5-2
ii  node-d3-scale   1.0.7-6
ii  node-d3-selection   1.4.0-5
ii  node-d3-shape   1.3.5-2
ii  node-d3-time1.0.11-3
ii  node-d3-time-format 2.1.3-2
ii  node-d3-transition  1.2.0-4
ii  node-dateformat 3.0.0-1
ii  node-exports-loader 0.7.0-2
ii  node-file-loader3.0.1-1
ii  node-fuzzaldrin-plus0.5.0+dfsg-3
ii  node-glob   7.1.3-2
ii  node-imports-loader 0.8.0-2
ii  node-jed1.1.1-1
ii  node-jquery 3.4.0+dfsg-1
ii  node-jquery-ujs 1.2.2-2
ii  node-jquery.waitforimages   2.4.0+ds-1
ii  

Bug#854262: gitlab: After upgrade, unable to push "The project you were looking for could not be found"

[Romain Bignon]

Package: gitlab
Version: 8.13.11+dfsg-1
Severity: important

Dear Maintainer,

After upgrading gitlab to 8.13.11 (stretch), my users can't push to any
repository:

$ git push
Counting objects: 47, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (47/47), done.
Writing objects: 100% (47/47), 6.32 KiB | 0 bytes/s, done.
Total 47 (delta 35), reused 0 (delta 0)
remote: GitLab: The project you were looking for could not be found.
To ssh+git://git.weboob.org/romain/weboob.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 
'ssh+git://git...@git.weboob.org/romain/weboob.git'

Here is the log in /var/log/gitlab-shell/gitlab-shell.log

I, [2017-02-05T16:56:47.538389 #9568]  INFO -- : POST 
http://localhost:8080/api/v3/internal/allowed 0.02896
I, [2017-02-05T16:56:47.538469 #9568]  INFO -- : gitlab-shell: executing git 
command  for 
user with key key-3.
I, [2017-02-05T16:56:47.758027 #9576]  INFO -- : POST 
http://localhost:8080/api/v3/internal/allowed 0.02061

Here from /var/log/gitlab/production.log

Started POST "/api/v3/internal/allowed" for 127.0.0.1 at 2017-02-05 16:58:17 
+0100
Started POST "/api/v3/internal/allowed" for 127.0.0.1 at 2017-02-05 16:58:17 
+0100

I've seen a similar problem on upstream tracker[1], but it concerns
upgrade to 8.15 and refers to a table named 'project_authorizations',
which does not exists in 8.13.

(Note: I've monkey patched to resolve #853251 before encountering this
new issue)

Best regards,

Romain

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/26194

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b2
ii  bundler   1.13.6-2
ii  debconf [debconf-2.0] 1.5.60
ii  git   1:2.11.0-2
ii  gitlab-shell  3.6.6-2
ii  gitlab-workhorse  0.8.5+debian-3
ii  init-system-helpers   1.47
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nginx 1.10.2-4
ii  nginx-extras [nginx]  1.10.2-4
ii  nodejs4.7.2~dfsg-1
ii  openssh-client1:7.4p1-6
ii  postfix [mail-transport-agent]3.1.4-3
ii  postgresql-client 9.6+179
ii  postgresql-client-9.6 [postgresql-client  9.6.1-2
ii  postgresql-contrib9.6+179
ii  rake  10.5.0-2
ii  redis-server  3:3.2.6-1
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-3
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1

Bug#775717: unblock: weboob/1.0-3

[Romain Bignon]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

The package weboob has been marked for autoremoval because of a RC which
reports that weboob applications don't ask user before accepting a new
modules repository's keyring:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774838

To fix it, I've applied a patch from upstream to let user accept or not
the keyring of a new repository after displaying him the fingerprint of the
keyring.

Please unblock package weboob to allow it to re-enter jessie.

diff -Nru weboob-1.0/debian/changelog weboob-1.0/debian/changelog
--- weboob-1.0/debian/changelog 2014-12-10 10:05:31.0 +0100
+++ weboob-1.0/debian/changelog 2015-01-18 19:56:20.0 +0100
@@ -1,3 +1,11 @@
+weboob (1.0-3) unstable; urgency=medium
+
+  *debian/patches/0004-prompt-user-to-accept-an-untrusted-keyring.patch:
+   prompt user to accept an untrusted keyring when updating repositories
+   (Closes: #774838).
+
+ -- Romain Bignon rom...@symlink.me  Sun, 18 Jan 2015 16:07:58 +0100
+
 weboob (1.0-2) unstable; urgency=low

   * 
debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch:
diff -Nru 
weboob-1.0/debian/patches/0004-prompt-user-to-accept-an-untrusted-keyring.patch 
weboob-1.0/debian/patches/0004-prompt-user-to-accept-an-untrusted-keyring.patch
--- 
weboob-1.0/debian/patches/0004-prompt-user-to-accept-an-untrusted-keyring.patch 
1970-01-01 01:00:00.0 +0100
+++ 
weboob-1.0/debian/patches/0004-prompt-user-to-accept-an-untrusted-keyring.patch 
2015-01-18 19:56:20.0 +0100
@@ -0,0 +1,183 @@
+From: Romain Bignon rom...@budget-insight.com
+Date: Fri, 16 Jan 2015 12:21:51 +0100
+Subject: prompt user to accept an untrusted keyring
+
+---
+ weboob/applications/weboobcfg/weboobcfg.py |  3 ++-
+ weboob/core/repositories.py| 25 -
+ weboob/tools/application/console.py| 20 +---
+ weboob/tools/application/qt/backendcfg.py  |  5 +
+ 4 files changed, 40 insertions(+), 13 deletions(-)
+
+diff --git a/weboob/applications/weboobcfg/weboobcfg.py 
b/weboob/applications/weboobcfg/weboobcfg.py
+index 822325c..3c4e96b 100644
+--- a/weboob/applications/weboobcfg/weboobcfg.py
 b/weboob/applications/weboobcfg/weboobcfg.py
+@@ -25,6 +25,7 @@ import re
+ from weboob.capabilities.account import CapAccount
+ from weboob.core.modules import ModuleLoadError
+ from weboob.tools.application.repl import ReplApplication
++from weboob.tools.application.console import ConsoleProgress
+ from weboob.tools.ordereddict import OrderedDict
+
+
+@@ -261,4 +262,4 @@ class WeboobCfg(ReplApplication):
+
+ Update weboob.
+ 
+-self.weboob.update()
++self.weboob.update(ConsoleProgress(self))
+diff --git a/weboob/core/repositories.py b/weboob/core/repositories.py
+index dbf7448..89ff23f 100644
+--- a/weboob/core/repositories.py
 b/weboob/core/repositories.py
+@@ -26,6 +26,7 @@ import re
+ import sys
+ import os
+ import subprocess
++import hashlib
+ from datetime import datetime
+ from contextlib import closing
+ from compileall import compile_dir
+@@ -180,7 +181,7 @@ class Repository(object):
+ # Save the repository index in ~/.weboob/repositories/
+ self.save(repo_path, private=True)
+
+-def retrieve_keyring(self, browser, keyring_path):
++def retrieve_keyring(self, browser, keyring_path, progress):
+ # ignore local
+ if self.local:
+ return
+@@ -202,11 +203,11 @@ class Repository(object):
+ if keyring.exists():
+ if not keyring.is_valid(keyring_data, sig_data):
+ raise InvalidSignature('the keyring itself')
+-print('The keyring was updated (and validated by the previous 
one).')
+-else:
+-print('First time saving the keyring, blindly accepted.')
++progress.progress(0.0, 'The keyring was updated (and 
validated by the previous one).')
++elif not progress.prompt('The repository %s isn\'t trusted 
yet.\nFingerprint of keyring is %s\nAre you sure you want to continue?' % 
(self.url, hashlib.sha1(keyring_data).hexdigest())):
++raise RepositoryUnavailable('Repository not trusted')
+ keyring.save(keyring_data, self.key_update)
+-print(keyring)
++progress.progress(0.0, str(keyring))
+
+ def parse_index(self, fp):
+ 
+@@ -378,6 +379,9 @@ class IProgress(object):
+ def error(self, message):
+ raise NotImplementedError()
+
++def prompt(self, message):
++raise NotImplementedError()
++
+ def __repr__(self):
+ return '%s' % self.__class__.__name__
+
+@@ -389,6 +393,10 @@ class PrintProgress(IProgress):
+ def error(self, message):
+ print('ERROR: %s' % message, file=sys.stderr)
+
++def prompt(self, message):
++print('%s (Y/n

Bug#774838: weboob: insecure keyring handling

[Romain Bignon]

Hi,

On 08/Jan - 11:11, Cyril Brulebois wrote:
 I would expect the Debian packages to contain some kind of trust chain
 to bootstrap the keyring handling, and weboob to abort instead of
 “blindly accepting” in other cases.

You're right we should have the official keyring distributed in the Debian
package, but in case the user adds a new repository, we shouldn't reject it but
ask him to accept (like ssh)?

I'm going to send a patch on the package this week.

Romain


signature.asc
Description: Digital signature

Bug#772709: unblock: weboob/1.0-2

[Romain Bignon]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

The package weboob has been marked for autoremoval because of a RC bug
introduced by a patch made on Python to remove a deprecated constant
(PROTOCOL_SSLv3) which breaks weboob:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771499

To fix this issue, I've uploaded a new version of the package in unstable which
removes the use of this constant, and replaces it with PROTOCOL_SSLv23 (bad
named, it chooses the highest protocol version, cf
https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_SSLv23).

diff -Nru weboob-1.0/debian/changelog weboob-1.0/debian/changelog
--- weboob-1.0/debian/changelog 2014-10-20 22:16:20.0 +0200
+++ weboob-1.0/debian/changelog 2014-12-10 10:05:31.0 +0100
@@ -1,3 +1,11 @@
+weboob (1.0-2) unstable; urgency=low
+
+  * 
debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch:
+disable SSLv3 to be compliant with changes introduced by #768611 in Python
+(Closes: #771499).
+
+ -- Romain Bignon rom...@symlink.me  Mon, 08 Dec 2014 20:25:54 +0100
+
 weboob (1.0-1) unstable; urgency=low

   * New Upstream Release
diff -Nru 
weboob-1.0/debian/patches/0002-fix-StatusField-to-be-a-BaseObject.patch 
weboob-1.0/debian/patches/0002-fix-StatusField-to-be-a-BaseObject.patch
--- weboob-1.0/debian/patches/0002-fix-StatusField-to-be-a-BaseObject.patch 
2014-10-20 22:16:20.0 +0200
+++ weboob-1.0/debian/patches/0002-fix-StatusField-to-be-a-BaseObject.patch 
2014-12-10 10:05:31.0 +0100
@@ -3,11 +3,11 @@
 Subject: fix StatusField to be a BaseObject

 ---
- weboob/capabilities/account.py | 12 +---
- 1 file changed, 9 insertions(+), 3 deletions(-)
+ weboob/capabilities/account.py | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/weboob/capabilities/account.py b/weboob/capabilities/account.py
-index 0acd88d..cfac8a5 100644
+index 0acd88d..a742377 100644
 --- a/weboob/capabilities/account.py
 +++ b/weboob/capabilities/account.py
 @@ -18,7 +18,7 @@
diff -Nru 
weboob-1.0/debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch
 
weboob-1.0/debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch
--- 
weboob-1.0/debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch
1970-01-01 01:00:00.0 +0100
+++ 
weboob-1.0/debian/patches/0003-fix-compatibility-with-a-patch-introduced-by-768611.patch
2014-12-10 10:05:31.0 +0100
@@ -0,0 +1,23 @@
+From: Romain Bignon rom...@symlink.me
+Date: Mon, 8 Dec 2014 20:20:19 +0100
+Subject: fix compatibility with a patch introduced by #768611
+
+SSLv3 has been disabled in Debian's package of Python, so we have to
+change the protocol constant to use to let browser work.
+---
+ weboob/deprecated/browser/browser.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/weboob/deprecated/browser/browser.py 
b/weboob/deprecated/browser/browser.py
+index e85b701..61ebbd3 100644
+--- a/weboob/deprecated/browser/browser.py
 b/weboob/deprecated/browser/browser.py
+@@ -730,7 +730,7 @@ socket.getaddrinfo = my_getaddrinfo
+
+ class HTTPSConnection2(httplib.HTTPSConnection):
+ _HOSTS = {}
+-_PROTOCOLS = [ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv3]
++_PROTOCOLS = [ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23]
+
+ def _my_create_connection(self):
+ sock = socket.create_connection((self.host, self.port), self.timeout)
diff -Nru weboob-1.0/debian/patches/series weboob-1.0/debian/patches/series
--- weboob-1.0/debian/patches/series2014-10-20 22:16:20.0 +0200
+++ weboob-1.0/debian/patches/series2014-12-10 10:05:31.0 +0100
@@ -1,2 +1,3 @@
 0001-Set-copyright-in-applications.patch
 0002-fix-StatusField-to-be-a-BaseObject.patch
+0003-fix-compatibility-with-a-patch-introduced-by-768611.patch

Please unblock package weboob

unblock weboob/1.0-2

Regards,

Romain

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771499: [PATCH] use PROTOCOL_SSLv23 instead of PROTOCOL_SSLv3

[Romain Bignon]

Hello,

I've pushed a commit on the Weboob package git repository to add a patch to fix 
this issue:

http://anonscm.debian.org/gitweb/?p=collab-maint/weboob.git;a=summary

I'm waiting for a DD to upload a new version of the package.

Romain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771499: [weboob] boobank not usable because of SSLv3 errors

[Romain Bignon]

Hi,

That's because of this patch introduced few days ago on python:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611

I'm going to add a patch on the weboob package to disable use of PROTOCOL_SSLv3
constant.

Romain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

On 11/Jun - 17:55, Romain Bignon wrote:
 Ping me if I forgot.

Ping :). I wouldn't miss 0.c in wheezy.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

On 09/Jun - 09:43, Vincent Danjean wrote:
 I'm just thinking about two lines per program to describe them
 and one line to tell the user where they have been installed.

Well, I don't know if this is really useful to tell in /usr/share/weboob/README
that scripts described are installed into /usr/share/weboob/ :).

 You are the maintainer, prepare the package as you wish. Improvements
 or changes can come later if required.

Ok. I've merged your changes into
git://git.symlink.me/pub/romain/weboob-packaging.git, without the four last
commits:

- Add support for local read-only repositories and put modules in their own
  package
- Fix permissions
- Add official modules locally
- Install contrib in /usr/share/doc/weboob/examples

Can you upload the package from my git repository? We should add enhancements
later if needed, but it's very important to have weboob 0.c into the next
stable, because weboob 0.b (and especially modules) isn't supported anymore by
our team.

Romain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

On 11/Jun - 10:33, Vincent Danjean wrote:
 I think it is important: a Debian user will look for information about
 a software in:
 - the binary itself if it is a gui program
 - the help text of the command
 - /usr/share/doc/'package'
 It will not look into /usr/share/weboob/ that is a directory managed
 by dpkg for archtecture-neutral data for the application (not for the
 user of the application).
   I'm still convince that, if scripts in /usr/share/weboob/ are not
 called directly by weboob or its plugins, they belong more into a
 (sub?)directory of /usr/share/doc/weboob/. But, in any case, this
 is minor and should not block an upload.

Ok, I'll have a look soon, but the main priority is to upload weboob 0.c into
Debian Wheezy :)

 Ok, I will try to review the package and upload it within two days.
 Ping me if I forgot.

Right, thanks.

Romain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

On 07/Jun - 21:42, Vincent Danjean wrote:
 The tarball is the one found on the upstream website (weboob-0.c.tar.gz).
 I think you made a mistake or the tarball changed on the website without
 changing the version number

I generated the tarball for Debian with “./setup.py sdist”, because it didn't
contained modules and any other unneeded files.

 The idea is to allow a local admin-managed repository. As plugins
 for iceweal can be installed by the user (he is then responsible for
 update) or by the admin (and update and security can be handled by
 the usual tools such as apt-get...)
   With my solution, a user can install his modules with the Debian
 package (or with other local Debian packages...) or he can download
 them manually. Debian package for stable can be updated through
 backport.
   But perhaps the order of upstream repo and Debian one should be
 changed. There is no version number for modules ? Else, weboob can
 load the one with the highest version number when a module exists
 in several repo.

Unfortunately, for a given module, weboob installs it from the first repository
(from last to first in sources.list) where it is found, regardless of the
version number. If you keep your current sources.list file, modules will
*always* be installed from the local repository, and only new modules added
after the release of weboob and uploaded to our repository will be downloaded
from it.

Perhaps we should enhance the system in a future version of weboob, but
currently you may let the upstream content of sources.list.

  - Scripts in contrib/ are not examples, they can be used as is.
 
 They were not packaged.

They were installed into usr/share/weboob/, see your commit
09954b555c50c14619f5bff454f6286511c2c53f:

-../../contrib/* usr/share/weboob/
+../../contrib/* usr/share/doc/weboob/examples

 I prefer to find them in example than having
 to download the sources and find them in it. Of course, the best
 solution would be to install them into the path, but then a manpage
 is required...

Yes, I don't think it's useful to install them into the path.

Anyway, do you think there are chances to weboob 0.c to be included into the
next stable before the freeze?

Romain



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

On 08/Jun - 22:23, Vincent Danjean wrote:
 Debian packages need to be built from upstream tarball. This allows
 people to download and check the tarball (md5sum). Moreover, uscan
 and friends (git-import-orig --uscan, ...) also look at the upstream
 website to download it and prepare the next version. If you really
 want to change the tarball used to built the package, you need to
 rename it. It is often done when this is required to remove non-dsfg
 files but it is best to avoid it if not required.

Ok, alright.

 Ok, you convince me that adding the local repo by default is not
 a good thing. However, I'm still convinced that this should be
 possible for people that want to (ie to have the possibility to
 have a *read-only* local repo).

Your point of view is interesting and in a future version of weboob we should
enhance the system to allow this kind of things.

 Oups, I forgot. If you prefer to lets them in usr/share/weboob/,
 I'm ok if you provided a documentation (just a text file) in
 /usr/share/doc/weboob to tell about them. For myself, I would have
 not find them without looking into the sources directly. That why
 I move them.

No problem. What kind of documentation do you want to have?

 Why not. But the upload should be done very soon.

Yes, we should reach a consensus quickly :)

Regards,

Romain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674144: weboob: New upstream available and proposition for numerous fix

[Romain Bignon]

Hi,

Sorry I did not have time to answer to your mail.

On 23/May - 12:55, Vincent Danjean wrote:
   I tried to improve it a little. You can find the result here:
 git://git.ligforge.imag.fr/git/users/vdanjean/debian/weboob.git
 I would be very pleased if you are interested my my suggestions.
 Note that debian patches whose name begin by for-upstream should
 probably be pushed upstream instead of beeing kept as debian patches.

Nice changes! But I have some questions:

- Why have you changed the tarball?
- Why do you install modules locally? The goal of the repository system is to
  publish fixes of modules (for example when a module is broken because of a
  change on the associated website) without releasing a new version of Weboob.
  If you force Debian users to use local modules, half of the modules will be
  unusable in six months.
- Scripts in contrib/ are not examples, they can be used as is.

Thanks for your work.

Romain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#576343: python-elementtidy: Crash when no error occures

[Romain Bignon]

Package: python-elementtidy
Version: 1.0-7
Severity: important
Tags: patch

When there are no errors while parsing a HTML page, the tidyBufFree()
crashes, because it tries to access to dereference the err.allocator
which is NULL.

Here is a patch to check it before calling this function.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-elementtidy depends on:
ii  libc6  2.10.2-2  GNU C Library: Shared libraries
ii  libtidy-0.99-0 20091223cvs-1 HTML syntax checker and reformatte
ii  python 2.5.4-9   An interactive high-level object-o
ii  python-support 1.0.6 automated rebuilding support for P

python-elementtidy recommends no packages.

python-elementtidy suggests no packages.

-- no debconf information
--- elementtidy-1.0.orig/_elementtidy.c
+++ elementtidy-1.0/_elementtidy.c
@@ -112,16 +112,16 @@
 goto error;
 }
·
-tidyBufFree(out);
-tidyBufFree(err);
+if (out.allocator) tidyBufFree(out);
+if (err.allocator) tidyBufFree(err);
·
 tidyRelease(doc);
·
 return Py_BuildValue(NN, pyout, pyerr);
·
   error:
-tidyBufFree(out);
-tidyBufFree(err);
+if (err.allocator) tidyBufFree(out);
+if (err.allocator) tidyBufFree(err);
·
 tidyRelease(doc);

Bug#483541: python-qwt5-qt4 doesn't find symbole in Qwt.so

[Romain Bignon]

Package: python-qwt5-qt4
Version: 5.0.1.dfsg-3

When I try to import the python's module, there is this error:

Python 2.5.2 (r252:60911, Apr 17 2008, 13:15:05)
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2
Type help, copyright, credits or license for more information.
 import PyQt4.Qwt5 as Qwt
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python2.5/site-packages/PyQt4/Qwt5/__init__.py, line 23, in 
module
from Qwt import *
ImportError: /usr/lib/python2.5/site-packages/PyQt4/Qwt5/Qwt.so: undefined 
symbol: _ZN16QwtPlotMagnifier16widgetWheelEventEP11QWheelEvent

I'm using Debian/lenny.

-- 
Romain Bignon -- http://romain.peerfuse.net

http://peerfuse.net


pgpHHtfVoSA9O.pgp
Description: PGP signature

Bug#434994: fglrx-kernel-src: Unable to build module with kernel 2.6.21

[Romain Bignon]

Package: fglrx-kernel-src
Version: 8.38.6-2
Severity: grave
Justification: renders package unusable


The module can't be built because of a license problem.

In firegl_public.c:249 we have:

MODULE_LICENSE(Proprietary. (C) 2002 - ATI Technologies, Starnberg,
GERMANY);

When you try to build module with make.sh, this error will occure:

FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol
'paravirt_ops'

I can change MODULE_LICENSE() string to GPL and additional rights
and it will build, but I think it isn't the solution, because of license
rights.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages fglrx-kernel-src depends on:
ii  bzip2 1.0.3-6high-quality block-sorting file co
ii  debhelper 5.0.53 helper programs for debian/rules
ii  make  3.81-3 The GNU version of the make util

Versions of packages fglrx-kernel-src recommends:
ii  kernel-package11.001 A utility for building Linux kerne
ii  module-assistant  0.10.11tool to make module package creati

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]