Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

So, should this issue be forwarded/moved to systemd then?

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

Thanks for your quick reply.

Am 06.04.24 um 06:37 schrieb Alexandre Detiste:


Can you please try to reproduce the problem without systemd-cron involved;
by copying the .timer / .service / .sh triplet from /run/systemd/generator
into /etc/systemd/system and see what happens when
you do manually what cron-update.service would do.

It does:
  - systemctl daemon-reload
  - systemctl restart .timer  (via cron.target)
  - systemctl reset-failed .timer
(hint: systemctl cat cron-update.service)

If the same problem persists; then the bug is definitively in systemd itself.
Yes, indeed, on restart of the .timer unit, the service is executed 
immediately!


So, my mwe looks like this:

$ cat /etc/systemd/system/timerconfusion.timer

[Timer]
Unit=timerconfusion.service
OnCalendar=*-*-* *:0/5

$ cat /etc/systemd/system/timerconfusion.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'date --iso-8601=seconds >> 
/var/log/timerconfusion.log'


$ systemctl daemon-reload

$ systemctl starttimerconfusion.timer

$ # wait until timer is executed for the first time

$ cat /var/log/timerconfusion.log

2024-04-06T12:55:07+02:00

$ systemctl restart timerconfusion.timer

$ cat /var/log/timerconfusion.log

2024-04-06T12:55:07+02:00
2024-04-06T12:55:24+02:00


In my test, only the very first restart of the timer after a regular 
scheduled timer execution caused an extraneous service start.


Thanks.

Best,
Maximilian

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

Package: systemd-cron
Version: 2.3.4-1
Severity: normal

Dear Maintainer,

Today I noticed that a run of cron-update.service apparently causes
some past cron jobs to re-run.

In particular, I have a cron job of "5 5 5 * *" which correctly
executed this morning at 2024-04-05T05:05:08.401635+02:00.

Then, at 6:24 an automatic configuration script caused a re-run of
cron-update.service. This, however, did not only cause a restart of
the generated timer unit but also started the service itself, i.e.,
the service ran again at 2024-04-05T06:24:40.798393+02:00.

I was able to reproduce the behavior with other timers, too. It seems
that the generated cron services are executed by cron-update.service
if they are within a certain time limit in the past.

Best,
Maximilian

Bug#1067225: equivs-build fails due to duplicate debhelper compat level

[Maximilian Stein]

Package: equivs
Version: 2.3.1
Severity: normal

Dear Maintainer,

I tried to install all build dependencies given in a control file
using `mk-build-deps -ir` from devscripts. However, equis-build of the
package fails:

> dh: error: debhelper compat level specified both in debian/compat and via 
> build-dependency on debhelper-compat
> make: *** [debian/rules:3: clean] Error 255

I dug a bit into the issue and noticed that equivs-build uses the file
/usr/share/equivs/template/debian/control.in as template for the
generated debian/control. The control.in lists a Build-Depends on
"debhelper-compat (= 12)". However, equivs-build also directly creates
a debian/compat with the content 12, which explains the observed
behavior.

Probably, equivs-build should simply stop writing the legacy
debian/compat file, i.e.,

--- /usr/bin/equivs-build   2021-11-01 11:37:21.859615519 +0100
+++ equivs-build2024-03-20 14:17:06.560194426 +0100
@@ -331,10 +331,6 @@
   "Essential",
   "Description");
   close OUT;
-  open OUT, '>', "$builddir/debian/compat" or
-die "Cannot open $builddir/debian/compat for writing: $!\n";
-  print OUT "12";
-  close OUT;
 }

Best,
Maximilian




-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'oldstable-security'), (990, 
'oldoldstable'), (990, 'testing'), (990, 'stable'), (100, 'stable-updates'), 
(100, 'oldstable-updates'), (100, 'oldoldstable-updates'), (100, 
'oldoldstable'), (100, 'unstable'), (100, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages equivs depends on:
ii  debhelper  13.14.1
ii  dpkg-dev   1.22.4
ii  make   4.3-4.1
ii  perl   5.38.2-3

equivs recommends no packages.

equivs suggests no packages.

-- no debconf information

Bug#1065421: extrepo-offline-data: Gitlab GPG key is expired

[Maximilian Stein]

Hello Juri,

Awesome, thanks!

Best
Maximilian

Bug#1065421: extrepo-offline-data: Gitlab GPG key is expired

[Maximilian Stein]

Package: extrepo-offline-data
Version: 1.0.4
Severity: normal

Dear Maintainer,

The GPG key of the Gitlab repository is expired since March 1st.

The new one can be downloaded at [1].

Best
Maximilian

[1]: https://packages.gitlab.com/gpg.key

Bug#1060918: extrepo-offline-data: anydesk GPG key is expired

[Maximilian Stein]

Package: extrepo-offline-data
Version: 1.0.4
Severity: normal

Dear Maintainer,

The anydesk key included in the extrepo repo is expired since
2023-12-17.

The updated key can be fetched from the same URL as commented in the
yaml file [1].

Best,
Maximilian

[1]: 
https://salsa.debian.org/extrepo-team/extrepo-data/-/blob/master/repos/debian/anydesk.yaml?ref_type=heads#L17

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Maximilian Stein]

> LaTeX2e <2018-12-01>
> ...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:292: 
attempt to cal

> l method 'read' (a nil value)


I am seeing the exact same issue. Downgrading "texlive-binaries" to 
"2018.20181218.49446-1" has fixed it for me (while leaving all other 
packages up to date), so I assume that "texlive-binaries" has the issue 
here.


Best,
Maximilian

Bug#1028460: extrepo-offline-data: gitlab_ce repo appears empty

[Maximilian Stein]

Package: extrepo-offline-data
Version: 1.0.3
Severity: normal

Dear Maintainer,

Apperently, the repository gitlab_ce is empty.

According to the website of the Gitlab CE repository [1], there are
only packages for buster and bullseye available currently.

Should the suite then be fixed to bullseye?

Best,
Maximilian

Bug#1025001: gitlab: Some UI elements, including buttons, are replaced with "undefined"

[Maximilian Stein]

Dear Maintainer,

I am indeed experiencing the same issues since the last upgrade. I 
noticed, however, that some buttons are still there and useable, but 
they are simply invisible unless hovered or clicked (i.e., they only 
lack text). Especially modal dialogs are entirely unusable, though.


Best,
Max

Bug#1018935: kwin-x11: kwin_x11 crashing periodically while rendering a popup notification

[Maximilian Stein]

> I have now, on 2 occasions, had a crash in kwin while rendering a popup
> notification.
>


I am seeing kwin crashes when a notification popup appears, too. In many 
cases, plasmashell becomes unresponsive, too, so I need to restart them 
both.

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Maximilian Stein]

> My bad, I mixed things up: the 500 error I am experiencing is the one 
from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019403 
(undefined method `h' for LabelsHelper:Module).



Yeah, these two seem quite similar. The workaround for 1019403 has to be 
repeated after every update, though, while this one only needs to be 
implemented once.

Bug#1022972: konsole: Konsole does not handle arrow keys correctly anymore

[Maximilian Stein]

On Thu, 03 Nov 2022 10:07:47 +0100 Jonas =?ISO-8859-1?Q?Sch=E4fer?= 
 wrote:


> Max, Nathanael, could you confirm that you're too using Neo2, or 
similarly


> "exotic" layouts? Otherwise we're probably looking at different issues.

I can confirm that. I am using Neo2, too, with "Default (XFree 4)" 
keyboard mapping and observing the same issues in both Konsole and 
pinentry.


Simply switching to us layout is not enough, though, but it has to be 
the default layout (i.e., the topmost entry in the systems settings 
dialogue), but I guess this is expected as the default layout usually 
defines hotkeys in KDE, too.


As a workaround, I switched to the "Solaris" style which works good 
enough in many applications. Adding the broken keys as new mappings to 
"Default (XFree 4)" works, too. This is interesting, because as soon as 
there is an explicit mapping for "Up" key the "input" field executes the 
correct (new) rule when pressing "Up". But it is a bit cumbersome, of 
course, to add a dozen keys or so.



Best,
Max

Bug#1023291: gitlab-sidekiq spamming logs after upgrade to gitlab 15.4.2

[Maximilian Stein]

On Tue, 01 Nov 2022 20:59:49 +0100 Ondrej Zary  wrote:

> after upgrading gitlab to 15.4.2, gitlab-sidekiq is spamming logs 
like this:

>
> gitlab-sidekiq[311326]: Passing the timeout as a positional argument 
is deprecated, it should be passed as a keyword argument:
> gitlab-sidekiq[311326]: 
redis.brpop("resque:gitlab:queue:adjourned_project_deletion", "resque:git
> lab:queue:object_pool:object_pool_create", 
"resque:gitlab:queue:integrations_execute", 
"resque:gitlab:queue:gcp_cluster:clu
> sters_cleanup_service_account", 
"resque:gitlab:queue:pipeline_default:ci_drop_pipeline", 
"resque:gitlab:queue:status_page_p
> ublish", 
"resque:gitlab:queue:github_importer:github_import_stage_import_pull_requests", 
"resque:gitlab:queue:package_clean

> up:packages_mark_package_files_for_destruction", ..
>  blah maybe 100 more lines


I can confirm this, the same is happening on my system, too.

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Maximilian Stein]

Control: forwarded -1 https://gitlab.com/gitlab-org/gitlab/-/issues/374174


Hi there,

As discussed in the upstream Gitlab bug report [1], apparently the 
package `ruby-activerecord` in version 6.1.6.1 
(2:6.1.6.1+dfsg-3~fto11+1) is broken as it appears to contain file from 
version 6.1.6 (specifically 
/usr/share/rubygems-integration/all/gems/activerecord-6.1.6.1/lib/active_record/railtie.rb). 
So, probably, that package needs to be fixed to get merge request 
comments working again.


In the meantime, there is a workaround available for Gitlab [2].

Best,
Max


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

[2]: https://gitlab.com/gitlab-org/gitlab/-/issues/374174#note_1105638411

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Maximilian Stein]

> Some time after upgrading to 15.3.2 (but not from the beginning),
> loading of comments in merge requests started to fail.


Apparently, only merge requests with annotations in the diff view are 
affected. That's why I didn't notice the issue from the beginning.

Bug#988908: plantuml: Can plantuml work with default-jre-headless?

[Maximilian Stein]

> Would it be possible to change this to also accept the headless version,
> ie 'default-jre | default-jre-headless'? It would reduse the apt
> download by 21.4 MiB and the disk footprint by 214 MiB.


I'd like to second this. According to the PlantUML FAQ 
(https://plantuml.com/en/faq) headless operation is possible with a java 
flag.


An alternative approach would be a separate package "plantuml-headless" 
that might even run as server.


Best,
Maximilian

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Maximilian Stein]

Package: gitlab
Version: 15.3.2+ds1-1~fto11+1
Severity: normal

Dear Maintainer,

Some time after upgrading to 15.3.2 (but not from the beginning),
loading of comments in merge requests started to fail. This sounds
similar to #1019403, but I believe it is a different issue.

While loading a merge request with comments, this URI (relative to
project) fails:

-/merge_requests/346/discussions.json?per_page=20

In the production.log, I found:

Completed 500 Internal Server Error in 764ms (ActiveRecord: 493.9ms | 
Elasticsearch: 0.0ms | Allocations: 144723)

Psych::DisallowedClass (Tried to load unspecified class: 
Gitlab::Diff::Position):

app/models/diff_discussion.rb:13:in `position'
app/models/diff_discussion.rb:51:in `cache_key'
app/controllers/concerns/issuable_actions.rb:186:in `render_mr_discussions'


Unfortunately, I haven't found a workaround yet. Do you have any idea
how to get comments in merge requests again?

Best,
Maximilian

Bug#1019430: New release in preparation

[Maximilian Stein]

Apparently, the KDE team is preparing a new release of Krusader [1], 
that includes the fix for this bug (among many others).



[1]: https://invent.kde.org/utilities/krusader/-/issues/22

Bug#1019430: krusader: Cannot extract archive anymore

[Maximilian Stein]

Package: krusader
Version: 2:2.7.2-2
Severity: normal

Dear Maintainer,

Krusader offers options to extract an archive in the right click menu.
Unfortunately, these buttons do not work, simply nothing happens (no
error message etc.).

I believe this is the same bug which is reported and marked "fixed" in
the KDE bug tracker at [1].

Thanks for your effort.

Best,
Maximilian


[1]: https://bugs.kde.org/show_bug.cgi?id=441376


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'testing'), (990, 'stable'), 
(990, 'oldstable'), (100, 'stable-updates'), (100, 'oldstable-updates'), (100, 
'unstable'), (100, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages krusader depends on:
ii  kinit  5.97.0-1
ii  kio5.97.0-1
ii  libacl12.3.1-1
ii  libc6  2.34-7
ii  libkf5archive5 5.97.0-1
ii  libkf5bookmarks5   5.97.0-1
ii  libkf5codecs5  5.97.0-1
ii  libkf5completion5  5.97.0-1
ii  libkf5configcore5  5.97.0-2
ii  libkf5configgui5   5.97.0-2
ii  libkf5configwidgets5   5.97.0-1
ii  libkf5coreaddons5  5.97.0-1
ii  libkf5guiaddons5   5.97.0-1
ii  libkf5i18n55.97.0-1
ii  libkf5iconthemes5  5.97.0-1
ii  libkf5itemviews5   5.97.0-1
ii  libkf5jobwidgets5  5.97.0-1
ii  libkf5kiocore5 5.97.0-1
ii  libkf5kiofilewidgets5  5.97.0-1
ii  libkf5kiowidgets5  5.97.0-1
ii  libkf5notifications5   5.97.0-1
ii  libkf5parts5   5.97.0-1
ii  libkf5service-bin  5.97.0-1
ii  libkf5service5 5.97.0-1
ii  libkf5solid5   5.97.0-1
ii  libkf5textwidgets5 5.97.0-1
ii  libkf5wallet-bin   5.97.0-1
ii  libkf5wallet5  5.97.0-1
ii  libkf5widgetsaddons5   5.97.0-2
ii  libkf5windowsystem55.97.0-1
ii  libkf5xmlgui5  5.97.0-1
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5dbus55.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5printsupport55.15.4+dfsg-5
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libqt5xml5 5.15.4+dfsg-5
ii  libstdc++6 12.2.0-1
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages krusader recommends:
ii  kde-cli-tools   4:5.25.4-1
ii  keditbookmarks  21.12.3-1
ii  kio-extras  4:22.04.3-1+b1

Versions of packages krusader suggests:
ii  arj3.10.22-25
ii  ark4:22.04.3-1
ii  bzip2  1.0.8-5
ii  cpio   2.13+dfsg-7
ii  kate   4:22.04.3-1
ii  kdiff3 1.9.6-1
ii  kmail  4:22.04.3-1
ii  kompare4:21.12.3-1
ii  konsole4:22.04.1-1
ii  krename5.0.2-1
ii  lhasa [lha]0.3.1-4
pn  md5deep | cfv  
ii  okteta 5:0.26.9-1
ii  p7zip  16.02+dfsg-8
ii  rpm4.17.0+dfsg1-4+b1
ii  unace  1.2b-21
ii  unrar-free 1:0.0.2-0.1
ii  unzip  6.0-27
ii  zip3.0-12

-- no debconf information

Bug#1019403: gitlab: failed to fetch comments in issue (500 Internal Server Error)

[Maximilian Stein]

Package: gitlab
Version: 15.3.2+ds1-1~fto11+1
Severity: normal
Tags: patch

Dear Maintainer,

After upgrading Gitlab, issue comments failed to fetch. I got the
following log entries:

Completed 500 Internal Server Error in 234ms (ActiveRecord: 154.4ms | 
Elasticsearch: 0.0ms | Allocations: 66512)

NoMethodError (undefined method `h' for LabelsHelper:Module):

app/helpers/labels_helper.rb:250:in `render_label_text'
app/helpers/labels_helper.rb:61:in `render_colored_label'
lib/banzai/filter/references/label_reference_filter.rb:120:in 
`object_link_text'


To me, this seemed like a typo, so I simply removed "h " in
labels_helper.rb:250. This fixed the issue for me, as far as I can
tell.

Best,
Maximilian


---

--- a/usr/share/gitlab/app/helpers/labels_helper.rb
+++ b/usr/share/gitlab/app/helpers/labels_helper.rb
@@ -247,7 +247,7 @@
 class="#{css_class}"
 data-container="body"
 data-html="true"
-#{"style=\"background-color: #{h bg_color}\"" if bg_color}
+#{"style=\"background-color: #{bg_color}\"" if bg_color}
   >#{ERB::Util.html_escape_once(name)}#{suffix}
 HTML
   end

Bug#1017701: gitlab: Upgrade to 15.2.2: Error installing prometheus-client-mmap in configuration

[Maximilian Stein]

Package: gitlab
Version: 15.2.2+ds1-2~fto11+1
Severity: important

Dear Maintainer,

Unfortunately, upgrading to 15.2.2+ds1-2~fto11+1 fails for me since a
ruby extension cannot be built:



Building native extensions. This could take a while...
ERROR:  Error installing prometheus-client-mmap:
ERROR: Failed to build gem native extension.

current directory: 
/var/lib/gitlab/.gem/gems/prometheus-client-mmap-0.16.2/ext/fast_mmaped_file
/usr/bin/ruby2.7 -I /usr/lib/ruby/vendor_ruby -r 
./siteconf20220819-213524-100euls.rb extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/include/ruby.h

You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.

extconf failed, exit code 1

Gem files will remain installed in 
/var/lib/gitlab/.gem/gems/prometheus-client-mmap-0.16.2 for inspection.
Results logged to 
/var/lib/gitlab/.gem/extensions/x86_64-linux/2.7.0/prometheus-client-mmap-0.16.2/gem_make.out



According to the log file, ruby-dev must be installed to compile a
ruby extension (which makes sense) — is this really necessary here?

I actually have the package ruby-prometheus-client-mmap installed
(version 0.15.0-1~fto11+1), which actually installs shared libraries,
so I wonder why compiling anything is necessary at all.

Can I assist somehow in investigating the issue further?

Thank you very much for your help!

Best
Maximilian

Bug#1015301: gitlab: Upgrade to 15.0.4 fails because BackgroundMigrations could not finalize

[Maximilian Stein]

On Tue, 19 Jul 2022 19:22:02 +0200 Antoine Le Gonidec 
 wrote:
> I could work around the failure to execute the last remaining 
migration using the attached patch.

>

> This patch is provided only for helping in diagnosing the underlying 
issue, I would not suggest applying it as-is.



Thanks for the patch!

Unfortunately, the jobs still fails for me. I actually get the message:

    PG::UndefinedColumn: ERROR: Column integrations.type does not exist 
LINE 47: AND integrations.type = mapping.old_type ^


So I guess my database is now to new for this migration and I can only 
manually set it to "successful"…



Best,

Maximilian

Bug#1015303: gitlab: updating labels and assignee of issues/merge requests causes error messages

[Maximilian Stein]

Update from upstream maintainer [1]: The file /etc/gitlab/cable.yml 
should be set to


production:
 adapter: redis
 url: redis://localhost:6379

This way, also setting the assignee works correctly.


[1] https://gitlab.com/gitlab-org/gitlab/-/issues/362266#note_1030743220

Bug#1015302: Upgrading 14.10.5 to 15.0.4 aborts on db:migrate

[Maximilian Stein]

Hi Jakob,



After reading around the docs Patrick linked, I noticed that both

Feature.enabled?(:execute_batched_migrations_on_schedule)

and

Feature.enabled?(:optimize_batched_migrations)

returned false.



I just checked these settings for me and both returned true. I manually 
restarted the failed backgound migrations and all except one finished 
successfully (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015301).


Best,
Maximilian

Bug#1015301: Status of background jobs

[Maximilian Stein]

Update on the background migrations:

All except one background migrations finished successfully, leaving only 
"BackfillIntegrationsTypeNew: integrations 
" stuck at failed. 
This one is exactly the migration mentioned in [1], so I guess this one 
might cause trouble in general


I then tried to migrate manually with `gitlab-rake db:migrate:redo 
VERSION=20210727113447`. This actually worked, however, I still have the 
Background Migration job in the admin page. So I guess I simply set the 
job's state on success as I don't experience any issues.

Bug#1015303: Possible issue in Debian package only?

[Maximilian Stein]

Apparently, this file is generated automatically by upstream Gitlab [1], 
so this might have gotten lost somewhere in packaging?


[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/362266#note_1030722428

Bug#1015302: Upgrading 14.10.5 to 15.0.4 aborts on db:migrate

[Maximilian Stein]

Hi Patrick,

Your issue seems to be the same as Bug#1015301 that I just filed earlier 
today.


I actually shared a workaround that allowed me to finish the upgrade by 
temporarily marking the failed background migrations as successful in 
the database. Maybe you wanna have a look there: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015301.


Best,
Maximilian

Bug#1015303: gitlab: updating labels and assignee of issues/merge requests causes error messages

[Maximilian Stein]

Package: gitlab
Version: 14.10.5+ds1-1~fto11+1
Severity: normal
Tags: patch

Dear Maintainer,

In versions 14.10.5 and 15.0.4 I experienced an annoying issue when
updating the assignee or labels of issues and merge requests: After
doing the change, an error message pops up, however, the change
actually worked but becomes only visible after I reload the page. A
similar thing happened when I tried to move issues on the board:
A message indicating that moving the issue failed pops up and the
issue jumps back. After I reload the page, the issue is in its new
column.

The issue is already reported upstream [1]. A gitlab engineer actually
replied with a link to an Action Cable issue on Github where somebody
proposed a workaround [2].

So, I simply created an empty file at /etc/gitlab/cable.yml, and this
actually solved the problems mentioned above.

Maybe this could be automated during the package installation?

Best,
Maximilian


[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/362266
[2]: https://github.com/rails/rails/issues/23337#issuecomment-497975564

Bug#1015301: gitlab: Upgrade to 15.0.4 fails because BackgroundMigrations could not finalize

[Maximilian Stein]

Package: gitlab
Version: 15.0.4+ds1-1~fto11+2
Severity: important

Dear Maintainer,

I just tried to upgrade to Gitlab 15.0.4 on my two instances. While I
had no issues in my smaller instance, my bigger one had some issues.

First, postinst failed with the message

/etc/systemd/system/gitaly.service.d/override.conf already exist

I moved the file away and the upgrade could continue. At the end of
the upgrade, gitaly did not start anymore, so I restored the file (it
actually contains the setting of the user running gitaly).

Then, however, I stumbled upon a much more serious issue: The database
migration could not finish as there were pending background jobs that
failed to finalize:

gitlab_production database is not empty, skipping gitlab setup
Attention: used pure ruby version of MurmurHash3
/usr/share/gitlab/lib/gitlab.rb:47: warning: already initialized constant 
Gitlab::APP_DIRS_PATTERN
/usr/share/gitlab/lib/gitlab.rb:47: warning: previous definition of 
APP_DIRS_PATTERN was here
/usr/share/gitlab/lib/gitlab.rb:48: warning: already initialized constant 
Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:48: warning: previous definition of VERSION 
was here
/usr/share/gitlab/lib/gitlab.rb:49: warning: already initialized constant 
Gitlab::INSTALLATION_TYPE
/usr/share/gitlab/lib/gitlab.rb:49: warning: previous definition of 
INSTALLATION_TYPE was here
/usr/share/gitlab/lib/gitlab.rb:50: warning: already initialized constant 
Gitlab::HTTP_PROXY_ENV_VARS
/usr/share/gitlab/lib/gitlab.rb:50: warning: previous definition of 
HTTP_PROXY_ENV_VARS was here
== 20220213103859 RemoveIntegrationsType: migrating 
===
rake aborted!
StandardError: An error has occurred, all later migrations canceled:


Gitlab::Database::BackgroundMigration::BatchedMigrationRunner::FailedToFinalize
…

I did some research, and found somebody else having a similar issue
[1]. Unfortunately, manually running the background jobs [2] did not
work either as they continued to fail. In the database I identified
the following stuck background migrations [3]:


gitlab_production=# select id,status,job_class_name, table_name, 
column_name, job_arguments from batched_background_migrations where status <> 3;
 id | status |  job_class_name  |  
table_name  | column_name | job_arguments 

++--+--+-+---
 17 |  4 | BackfillNamespaceIdForNamespaceRoute | routes
   | id  | []
 19 |  4 | BackfillMemberNamespaceForGroupMembers   | members   
   | id  | []
 20 |  4 | MigratePersonalNamespaceProjectMaintainerToOwner | members   
   | id  | []
 23 |  4 | BackfillGroupFeatures| 
namespaces   | id  | [1]
 15 |  4 | BackfillIntegrationsTypeNew  | 
integrations | id  | []
 16 |  4 | BackfillUserNamespace| 
namespaces   | id  | []
 18 |  4 | BackfillIssueSearchData  | issues
   | id  | []


I then proceeded to simply change the status of the jobs to 3 in the
database as proposed in the issue mentioned above [1]. I could then
finish the upgrade normally with `apt upgrade`.

Afterwards, I simply undid the database change (i.e., reverted the
status of the failed background migrations to 4) and then restarted
the migrations in the web UI.

As far as I can tell, everything seems normal now. The seven
background migration jobs are still pending, but I can continue to use
Gitlab normally.

Do you need any more information on the matter?

Thanks for your investigation into the issue!

Best,
Maximilian


[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/340193
[2]: 
https://docs.gitlab.com/ee/user/admin_area/monitoring/background_migrations.html#manually-finishing-a-batched-background-migration
[3]: https://docs.gitlab.com/ee/update/index.html#batched-background-migrations

Bug#960489: mosquitto: Logrotate still reporting gzip errors

[Maximilian Stein]

Package: mosquitto
Version: 2.0.11-1
Followup-For: Bug #960489

Dear Maintainer,

I can still observe these error messages in version 2.0.11-1. They are
AFAIK caused by a missing `delaycompress` stanza in
`/etc/logrotate.d/mosquitto`. Without `delaycompress` logrotate always
tries to compress files immediately while there still opened by
mosquitto. Adding `delaycompress` delays the compression to the second
rotation, effectively preventing gzip errors.

Best,
Maximilian

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

Thanks for confirmation. Closing this bug.

I just tested your new version 14.8.5+ds1-1~fto11+2. Unfortunately, in 
the gitlab-rake command script, the export of GEM_HOME is missing, 
causing the script to fail. After adding GEM_HOME to the list of 
exports, I can run commands like gitlab-rake gitlab:check".


Best,

Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

So I will wait if anyone else can confirm or reproduce this issue 
before adding GEM_PATH. Did you have GEM_HOME set in 
/etc/gitlab/gitlab-debian.conf ?


No, actually not. I now tested with

  GEM_HOME=/var/lib/gitlab/.gem

and I can confirm that this alone suffices. So, setting GEM_PATH is not 
needed when GEM_HOME is set correctly.


Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

Run 'gem env gempath' and set GEM_PATH variable with this value and 
/var/lib/gitlab/.gem added in /etc/gitlab/gitlab-debian.conf

I will try to do this automatically too.



This has indeed worked immediately. Thank you very much for the fast 
support!


Best
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

A little addition: To also get gitlab-rake working, I needed to add 
GEM_PATH to the list of exported variables in /usr/sbin/gitlab-rake.


Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

Package: gitlab
Version: 14.7.7+ds1-2~fto11+2
Severity: normal

Dear Maintainer,

Recently, I tried to upgrade Gitlab to 14.7.7+ds1-2~fto11+2.
Unfortunately, gitlab-sidekiq does not start afterwards but fails as
it cannot find graphiql-rails:

gitlab-sidekiq[8334]: Could not find gem 'graphiql-rails (~> 1.8)' in any 
of the gem sources listed in your Gemfile

However, in /var/lib/gitlab/.gem/gems (I fixed the owner as described
in the wiki), the gem is present (in directory graphiql-rails-1.8.0).
Unfortunately, I cannot uninstall the apt package ruby-graphiql-rails
(version 1.4.10-1) as gitlab still depends on it.

So, I assumed that Gitlab finds the graphiql-rails package installed
by apt. After I had updated the Gemfile to require version 1.4 of
graphiql-rails, I can indeed successfully start gitlab-sidekiq.

With this, Gitlab starts again, however some features do not work.
Most notably, I cannot merge a morge request anymore.

Thanks for your support!

Best,
Maximilian

Bug#1006610: gnucash: Crash with std::bad_alloc when trying to create any report

[Maximilian Stein]

Dear Yuta,

Thanks for your suggestion. Indeed, both 2.34.5-1 and 2.34.6-1 worked 
fine for me!


Should wo forward this report to the maintainers of libwebkit2gtk-4.0-37 
then?


Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006610: gnucash: Crash with std::bad_alloc when trying to create any report

[Maximilian Stein]

Package: gnucash
Version: 1:4.8-1
Severity: important

Dear Maintainer,

Since recently, Gnucash crashes with an std::bad_alloc exception
whenever I try to open a report. I am unsure whether this bug is
related to #851783.

This is the valgrind output in the moment I try to open a report:


==56964== Warning: set address range perms: large range [0x59c83000, 
0x99c85000) (noaccess)
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
==56964== 
==56964== Process terminating with default action of signal 6 (SIGABRT)
==56964==at 0x5F348A1: raise (raise.c:50)
==56964==by 0x5F1E545: abort (abort.c:79)
==56964==by 0x5D70889: ??? (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C059: ??? (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C0C4: std::terminate() (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C358: __cxa_throw (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D73020: std::__throw_bad_alloc() (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0xE5A00CB: 
WTF::FileSystemImpl::pathByAppendingComponent(WTF::String const&, WTF::String 
const&) (in /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18.19.11)
==56964==by 0x9EA7B5E: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9EA7BEA: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9E9289A: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9E1ABA0: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964== 
==56964== HEAP SUMMARY:
==56964== in use at exit: 71,053,921 bytes in 773,876 blocks
==56964==   total heap usage: 7,066,048 allocs, 6,292,172 frees, 941,857,631 
bytes allocated
==56964== 
==56964== LEAK SUMMARY:
==56964==definitely lost: 80,109 bytes in 116 blocks
==56964==indirectly lost: 63,377 bytes in 2,639 blocks
==56964==  possibly lost: 415,818 bytes in 3,965 blocks
==56964==still reachable: 63,512,529 bytes in 734,429 blocks
==56964==   of which reachable via heuristic:
==56964== newarray   : 211,048 bytes in 30 
blocks
==56964== suppressed: 0 bytes in 0 blocks
==56964== Rerun with --leak-check=full to see details of leaked memory
==56964== 
==56964== Use --track-origins=yes to see where uninitialised values come from
==56964== For lists of detected and suppressed errors, rerun with: -s
==56964== ERROR SUMMARY: 20027 errors from 232 contexts (suppressed: 0 from 0)



Is this a known issue? Can I assist somehow in further diagnosis?

Thanks for your help!

Best,
Maximilian

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'oldstable'), (100, 'testing-debug'), 
(100, 'oldstable-updates'), (100, 'oldstable-debug'), (100, 'unstable'), (100, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.8-1
ii  guile-2.2  2.2.7+1-6+b1
ii  guile-3.0-libs 3.0.7-1+b1
ii  libaqbanking44 6.4.3beta-1
ii  libboost-filesystem1.74.0  1.74.0-14
ii  libboost-locale1.74.0  1.74.0-14
ii  libboost-program-options1.74.0 1.74.0-14
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-14
ii  libc6  2.33-6
ii  libcairo2  1.16.0-5
ii  libcrypt-ssleay-perl   0.73.06-1+b4
ii  libdate-manip-perl 6.86-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.51-1
ii  libgcc-s1  11.2.0-16
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.4-1
ii  libgtk-3-0 3.24.31-1
ii  libgwengui-gtk3-79 5.9.0-1
ii  libgwenhywfar795.9.0-1
ii  libhtml-tableextract-perl  2.15-1.1
ii  libhtml-tree-perl  5.07-2
ii  libicu67   67.1-7
ii  libofx71:0.10.3-1
ii  libpango-1.0-0 

Bug#996260: Bug#998693: btrbk: Regression with security mitigation for CVE-2021-38173

[Maximilian Stein]

On 23.11.21 16:30, Thorsten Alteholz wrote:

Hi Bart,

oh, no, I didn't know of that regression, sorry.
There is a new package [1] available. Can you please test whether 
things are better with it?


  Thorsten


[1] 
https://people.debian.org/~alteholz/packages/to-be-tested/btrbk_0.27.1-1+deb10u2/



Thanks for the quick fix! This works for me.

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996260: Acknowledgement (btrbk: Regression with security mitigation for CVE-2021-38173)

[Maximilian Stein]

This issue was fixed upstream in version 0.29.1. Is there a chance to 
get this patch into stable?



Line 165 just needed to be changed to:

    allow_exact_cmd "${sudo_prefix}btrfs subvolume (show|list)( 
${option_match})* ${file_match}";





OpenPGP_signature
Description: OpenPGP digital signature

Bug#998693: gitlab: Upgrade to 14.2.6 fails with undefined method `install_monkey_patches'

[Maximilian Stein]

I got the transaction_metrics.rb error during the upgrade of ./play.it 
forge, but not the gitlab-sidekiq one. I suspect they are unrelated, 
and it might be worth opening a dedicated issue for the 
gitlab-sidekiq/sudo error to make it easier to find by other people.


Yeah, you are right, this was completely unrelated.

I had tried to remove the google-protobuf and grpc gems that needed to 
be installed manually previously. Apparently, I was slightly too 
agressive. After restoring /var/lib/gems that I had moved away, the 
installation finished successfully.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#999739: fai-setup-storage: BTRFS-RAID on NVMe fails to install

[Maximilian Stein]

Package: fai-setup-storage
Version: 5.8.4
Severity: normal
Tags: patch

Dear Maintainer,

I observed an issue trying to setup an BTRFS RAID on NVMe disks. I
have used FAI version 5.8.4, however, I think that the bug is still
present in version 5.10.3.

My disk configuration (I deliberately have the 2nd partition
unconfigured):

disk_config disk1 disklabel:gpt-bios fstabkey:uuid
primary -   32G -   -
primary -   -100%   -   -

disk_config disk2 sameas:disk1

disk_config btrfs fstabkey:uuid
btrfs raid1 /   disk1.1,disk2.1 
rw,degraded,noatime,nodiratime,compress=lzo,subvol=@ createopts="-L root"

Installing this on a machine with two disks /dev/nvme0n1 and
/dev/nvme1n1 terminated with the error:

Cannot satisfy pre-depends for mkfs.btrfs -d raid1 -L root -f   \
/dev/nvme1n1p1 /dev/nvme0n1p1: pt_complete_/dev/nvmen1p1, --\
system left untouched.

Looking into /usr/share/fai/setup-storage/Commands.pm, sub
"build_btrfs_commands", I noticed that line 365 (`$tmp =~ s/\d//;`)
apparently tries to strip the partition number off a partition path.
This is, unfortunately, too simple for these NVMe disks. I changed the
regular expression to only strip the partition no at the end, including
any preceding "p":

$tmp =~ s/p?\d+$//;

At least my system could install successfully with this patch. It
would, however, now fail for "/dev/sdpX", so maybe the regex should
explicitly handle NVMe disks.

Best,
Maximilian

Bug#998693: gitlab: Upgrade to 14.2.6 fails with undefined method `install_monkey_patches'

[Maximilian Stein]

Unfortunately, now gitlab-sidekiq fails to start since it is 
apparently trying to run a command with `sudo`:



I noticed that it's the `ExecStartPre=` that fails. Maybe the behaviour 
of `bundle` has changed recently? Running


  sudo -u git bundle install --local

in /usr/share/gitlab fails now which definitely used to work before (I 
often used this while fixing dependency problems).



Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998693: gitlab: Upgrade to 14.2.6 fails with undefined method `install_monkey_patches'

[Maximilian Stein]

> Remove this initializer. I have added rm_conffile to remove this 
automatically in debian/gitlab.maintscript but it seems to be not working.


Thanks for the prompt response, removing 
/usr/share/gitlab/config/initializers/transaction_metrics.rb did the 
trick. The installation finishes now.



Unfortunately, now gitlab-sidekiq fails to start since it is apparently 
trying to run a command with `sudo`:


Nov 06 21:58:21 zgitlab sudo[3253]: pam_unix(sudo:auth): conversation failed
Nov 06 21:58:21 zgitlab sudo[3253]: pam_unix(sudo:auth): auth could not 
identify password for [git]
Nov 06 21:58:21 zgitlab sudo[3253]:  git : user NOT in sudoers ; 
PWD=/usr/share/gitlab ; USER=root ; COMMAND=/bin/true
Nov 06 21:58:21 zgitlab gitlab-sidekiq[3251]: Bundler requires sudo 
access to install at the moment. Try installing again,
Nov 06 21:58:21 zgitlab gitlab-sidekiq[3251]: granting Bundler sudo 
access when prompted, or installing into a different path.
Nov 06 21:58:21 zgitlab systemd[1]: gitlab-sidekiq.service: Control 
process exited, code=exited, status=30/n/a





OpenPGP_signature
Description: OpenPGP digital signature

Bug#998693: gitlab: Upgrade to 14.2.6 fails with undefined method `install_monkey_patches'

[Maximilian Stein]

Package: gitlab
Version: 14.2.6+ds1-2~fto11+1
Severity: important

Dear Maintainer,

Today I tried to upgrade from gitlab version 14.1.7+ds1-2~fto11+1 to
14.2.6+ds1-3~fto11+1. This failed unfortunately (see log below).

Best,
Maximilian


rake aborted!
NoMethodError: undefined method `install_monkey_patches' for 
Gitlab::Database:Module
Did you mean?  instance_methods
/usr/share/gitlab/config/initializers/transaction_metrics.rb:3:in `'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:681:in
 `load'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:681:in
 `block in load_config_initializer'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.4.1/lib/active_support/notifications.rb:205:in
 `instrument'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:680:in
 `load_config_initializer'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:634:in
 `block (2 levels) in '
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:633:in
 `each'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/engine.rb:633:in
 `block in '
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:32:in
 `instance_exec'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:32:in
 `run'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:61:in
 `block in run_initializers'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:50:in
 `each'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:50:in
 `tsort_each_child'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/initializable.rb:60:in
 `run_initializers'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/application.rb:391:in
 `initialize!'
/usr/share/gitlab/config/environment.rb:7:in `'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:332:in
 `block in require'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:299:in
 `load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:332:in
 `require'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/application.rb:367:in
 `require_environment!'
/usr/share/rubygems-integration/all/gems/railties-6.1.4.1/lib/rails/application.rb:533:in
 `block in run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/rake-13.0.3/exe/rake:27:in `'
Tasks: TOP => db:migrate => db:load_config => environment

Bug#996260: btrbk: Regression with security mitigation for CVE-2021-38173

[Maximilian Stein]

Package: btrbk
Version: 0.27.1-1+deb10u1
Severity: normal

Dear Maintainer,

In the security upload for CVE-2021-38173 the ssh_filter_btrbk.sh
script was changed. This, however, introduced a regression for me as
my btrbk clients use the command

  sudo -n btrfs subvolume list -a -c -u -q -R /srv/backup

However, ssh_filter_btrbk.sh only allows this pattern

  sudo -n btrfs subvolume list [0-9a-zA-Z_@+./-]*

I.e., options to `btrfs subvolume list` are not permitted.

I fixed this using this modified pattern:

  allow_exact_cmd "${sudo_prefix}btrfs subvolume list (${option_match}( 
${option_match})*)? ${file_match}";

Best,
Maximilian

Bug#995400: fcopy: allow conjunction of classes for file selection

[Maximilian Stein]

Package: fai-client
Version: 5.10.3
Severity: wishlist

Dear Maintainer,

When installing files with fcopy, I frequently struggle how to require
multiple classes for a certain file to match, e.g. for a file in
/etc/apt/preferences which I want to install ONLY for a certain debian
version AND a certain hardware architecture.

My solution in these situations is to combine multiple host classes in
the class/*.sh scripts. So, if there is a class ARCH_ARM and a class
BUSTER, the last script in class/ creates a new class BUSTER_ARCH_ARM.

This, however, feels a bit cumbersome. Is there a more elegant
solution for such situations right now? What I don't want to do is
adding conditions in scripts/ as I would then need to use different
file names (which is not always possible).

Maybe, fcopy could also be extended to understand files named
"CLASS1+CLASS2" or similar and only install such files if the host has
both classes CLASS1 and CLASS2 (the file priority could be defined by
the first class in a conjunction with the remaining classes as tie
breaker, so CLASS1+CLASS2 > CLASS1 > CLASS2+CLASS1 > CLASS2 if CLASS1
has a higher priority than CLASS2).

Thanks for any suggestions!

Best,
Maximilian

Bug#991979: python3: SSL errors trigger asyncio loop exceptions

[Maximilian Stein]

Package: python3
Version: 3.7.3-1
Severity: normal

Dear Maintainer,

I noticed an issue using aiohttp with Python 3.7.3 in Debian Buster.
When a request fails due to SSL certificate problems there are
asyncio loop exceptions triggered — although my code is wrapped in a
try-except-block, mwe:

import aiohttp
import asyncio

URI = 'https://www.debian.org/'

async def main():
print(">>BEGIN")
try:
async with aiohttp.request('GET', URI) as resp:
data = await resp.text()
except BaseException as e:
print(f"ERROR: {e!r}")
print(">>DONE")

if __name__ == '__main__':
asyncio.run(main())

Running this code with failing SSL, e.g. as `faketime 2025-01-01
python3 ./testssl.py` triggers loop exceptions that completely bypass
my exception handler:

>>BEGIN
SSL handshake failed on verifying the certificate
protocol: 
transport: <_SelectorSocketTransport fd=8 read=polling write=>
Traceback (most recent call last):
  File "/usr/lib/python3.7/asyncio/sslproto.py", line 625, in 
_on_handshake_complete
raise handshake_exc
  File "/usr/lib/python3.7/asyncio/sslproto.py", line 189, in feed_ssldata
self._sslobj.do_handshake()
  File "/usr/lib/python3.7/ssl.py", line 763, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed:
certificate has expired (_ssl.c:1056)
SSL error in data received
...
ERROR: ClientConnectorCertificateError()
>>DONE
Unclosed client session
client_session: 

Moreover, the stack traces are not related to my code at all and the
"Unclosed client session" message indicates that the cleanup code in
the `async with` statement did not run either.

Using Python 3.9.2 with aiohttp 3.7.4-1 works like intended in this
case: There is only the message from my exception handler:

>>BEGIN
ERROR: ClientConnectorCertificateError(ConnectionKey(host='www.debian.org', 
port=443,
is_ssl=True, ssl=None, proxy=None, proxy_auth=None, 
proxy_headers_hash=None),
SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify
failed: certificate has expired (_ssl.c:1123)'))
>>DONE

Since the code in the stack trace from the loop's handler above
indicates an issue in Python itself, I reported against python3,
however, I am not entirely sure if this is a problem in Python or in
aiohttp.

Best,
Maximilian

Bug#990103: gitlab: Conflicting dependencies on google-protobuf prevent package configuration during update

[Maximilian Stein]

Hi,
ruby-google-protobuf package no longer works and we need to install 
google-protobuf from rubygems.org now.


This is documented in https://wiki.debian.org/gitlab 




Thank you very much, this actually works!

Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990103: gitlab: Conflicting dependencies on google-protobuf prevent package configuration during update

[Maximilian Stein]

Package: gitlab
Version: 13.12.3+ds1-4~fto10+1
Severity: important

Dear Maintainer,

Unfortunately, upgrade to Gitlab 13.12.3+ds1-4~fto10+1 and gitaly
13.12.1+dfsg-4~fto10+1 fails since dependencies on google-protobuf are
conflicting apperently:

---

Setting up gitlab (13.12.3+ds1-4~fto10+1) ...
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Bundler could not find compatible versions for gem "google-protobuf":
  In Gemfile:
google-protobuf (~> 3.14)

grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  google-protobuf (~> 3.12)

gitlab-labkit (~> 0.17.1) was resolved to 0.17.1, which depends on
  pg_query (~> 2.0) was resolved to 2.0.3, which depends on
google-protobuf (~> 3.15, >= 3.15.5)

Could not find gem 'google-protobuf (~> 3.15, >= 3.15.5)', which is required by 
gem 'pg_query (~> 2.0)', in any of the sources.
dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned error 
exit status 1
Setting up gitaly (13.12.1+dfsg-4~fto10+1) ...
Resolving dependencies...
Bundler could not find compatible versions for gem "google-protobuf":
  In Gemfile:
grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  googleapis-common-protos-types (~> 1.0) was resolved to 1.0.6, which 
depends on
google-protobuf (~> 3.14)

grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  google-protobuf (~> 3.12)

gitlab-labkit (~> 0.17.1) was resolved to 0.17.1, which depends on
  pg_query (~> 2.0) was resolved to 2.0.3, which depends on
google-protobuf (~> 3.15, >= 3.15.5)
dpkg: error processing package gitaly (--configure):
 installed gitaly package post-installation script subprocess returned error 
exit status 6
Errors were encountered while processing:
 gitlab
 gitaly
E: Sub-process /usr/bin/dpkg returned an error code (1)



I tried to manually edit the Gemfile without success. How can I fix
the configuration?

Best,
Maximilian

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

[Maximilian Stein]

Hi,

We cannot support more than one version of gitlab at any time. Gitlab by nature 
has fast releases and only way to keep up is keep updating gitlab. Only if 
upstream provides a long term supported version, we can support a gitlab 
version for longer than a month. Currently our goal is to go along with the 
upstream releases.

If there are more volunteers we can probably extend it up to 3 months. Even 
more resources will be required if we want to provide support for more than 
that.


Yes, I can fully understand this, and this is basically ok. My issue is 
simply that I am kind of forced to upgrade as soon as possible and 
cannot even delay that for a week or so. Usually I automatically update 
all packages each night except Gitlab which is on hold, but since there 
might be updates to dependencies of Gitlab, Gitlab can still break 
easily… I do not see a very good solution to that either apart from 
holding all ruby packages.



Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

[Maximilian Stein]

Hi,


You should be installing gitlab 13.11.2. You need to add contrib section to 
people.debian.org/~praveen/gitaly. This is mentioned in 
https://wiki.debian.org/gitlab/#New_changes

All dependencies are compatible with this version.


Thanks for the hint, I hadn't gotton this.

However, this actually doesn't not fully solves the basic problem: 
Basically, I am forced to always update to the newest gitlab version as 
fast as possible or otherwise risking that updates of a dependency 
package breaks my installation. So, actually, the problems boils down 
to: The Gitlab dependencies are tighter in the Gemfile than in the 
package. That's why dependency packages are upgraded although they break 
another package which is not upgraded.



What about generating the required dependencies from the Gemfile? 
Basically that is what I am doing manually: The ruby package "example" 
is found in the Debian package "ruby-example" and then I only need to 
get the version right.


Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

[Maximilian Stein]

Package: gitlab
Version: 13.9.6+ds1-1~fto10+1
Severity: important

Dear Maintainer,

unfortunately, I have repeatedly issues when upgrading gitlab to a new
version. My system is basically as recommended in the Debian Wiki with
Buster as basis plus Backports and Fasttrack. However, I am often
running in a situation that packages are actually *too new* and Gitlab
fails configuring because it expects a certain version of a package in
its Gemfile.

E.g., to upgrade to Gitlab version 13.9.6+ds1-1~fto10+1 today, I
iteratively *downgraded* ruby packages, re-run the Gitlab
installation, which then failed because another package was too new,
and so on. Finally, for 13.9.6+ds1-1~fto10+1, I needed to downgrade
these packages:

* ruby-autoprefixer-rails=10.2.4.0+dfsg1+~cs14.2.17-1
* ruby-devise-two-factor=3.1.0-2~bpo10+1
* ruby-fog-google=1.12.1-1~fto10+1
* ruby-discordrb-webhooks=3.3.0-1
* ruby-ruby-magic-static=0.3.5-1
* ruby-gitlab-labkit=0.15.0-1~fto10+2
* ruby-batch-loader=1.4.1+dfsg.1-3
* ruby-gitlab-experiment=0.4.9-1~fto10+1
* ruby-lockbox=0.3.5-2~bpo10+1
* ruby-rotp=2.1.1+dfsg-1

Of course, I need to hold them all, since they'd be upgraded
automatically otherwise.

One solution I could think of would be to provide a dependency-package
with hard version requirements. So, in contrast to
gitlab-apt-pin-preferences, such a package would directly depend on
all Gitlab-dependencies in their correct version for a particular
version of Gitlab. That way, I'd only need to pin a single package and
get a reproducible working installation. What do you think about that?

Best,
Maximilian

Bug#985057: gitlab-apt-pin-preferences: Pin not specific enough to prevent breaking Gitlab

[Maximilian Stein]

apt install ruby-doorkeeper=5.3.0-2~bpo10+1

should fix it and I will be uploading gitlab 13.9.3 to fasttrack soon, 
which will fix this.

Awesome, thanks a lot!



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985057: gitlab-apt-pin-preferences: Pin not specific enough to prevent breaking Gitlab

[Maximilian Stein]

This matching is expected.

Can you share the error message? ruby-doorkeeper 5.3 to 5.5 update is 
not supposed to break gitlab.


Basically, the rake commands (check, backup, ...) started to fail:

$ gitlab-rake gitlab:check :(
Check if Gitlab is configured correctly...
fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum 
Einhängepunkt /)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht 
gesetzt).
fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum 
Einhängepunkt /)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht 
gesetzt).
Could not find gem 'doorkeeper (~> 5.3.0)' in any of the gem sources 
listed in your Gemfile.

Run `bundle install` to install missing gems.


Running gitlab-update-gemfile-lock did not help, unfortunately.

Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985057: gitlab-apt-pin-preferences: Pin not specific enough to prevent breaking Gitlab

[Maximilian Stein]

Package: gitlab-apt-pin-preferences
Version: 2021.03.09
Severity: normal

Dear Maintainer,

I am experimenting with gitlab-apt-pin-preferences to get Gitlab's
dependencies right. However, I noticed that now ruby-doorkeeper breaks
Gitlab.

In /etc/apt/preferences.d/99gitlab ruby-doorkeeper is pinned to
"release n=buster-backports", however, this also matches packages from
buster-backports in fasttrack such as ruby-doorkeeper 5.5.0-1~bpo10+1
which now breaks Gitlab. Consequently, I would suggest to pin these
packages more tightly. E.g., ruby-doorkeeper should be pinned to
"n=buster-backports,l=Debian Backports" instead of just
"n=buster-backports". This would avoid premature updates of gitlab's
dependencies.

Best,
Maximilian

Bug#962259: ruby-rqrcode 1.1.2-3 breaks 2FA settings page

[Maximilian Stein]

Hi,

I actually found the culprit — it's actually ruby-rqrcode. Downgrading 
to 0.4.2-3 fixed the issue of the 2FA page.


I also found this in my logs:

Started GET "/-/profile/two_factor_auth" for 10.32.5.1 at 2021-02-22 
17:25:44 +0100

Processing by Profiles::TwoFactorAuthsController#show as HTML
Completed 500 Internal Server Error in 368ms (ActiveRecord: 14.7ms | 
Elasticsearch: 0.0ms | Allocations: 89772)


NoMethodError (undefined method `module_count' for 
#

Did you mean?  modules):

app/controllers/profiles/two_factor_auths_controller.rb:134:in 
`build_qr_code'

app/controllers/profiles/two_factor_auths_controller.rb:39:in `show'
app/controllers/application_controller.rb:499:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'


So, apparently, the newer ruby-rqrcode version breaks the 2FA settings page.

Best,
Maximilian





OpenPGP_signature
Description: OpenPGP digital signature

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Maximilian Stein]

You will need to regenerate Gemfile.lock. See the wiki page for steps.

It saves the exact versions used during installation in Gemfile.lock

It is supposed to be handled automatically for most gems, but it does 
not work for native gems. There is an open bug about it.


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

Which I have fixed now in 13.6.7-2 and 13.6.7-1_fto10+2 (I was trying 
to fix by dpkg trigger which was not sufficient, now everytime 
gitlab-sidekiq service start, this will be fixed). So restarting 
gitlab service should be sufficient to fix this.



This has worked like a charm! As far as I can tell, Gitlab works with 
this setup now (gitlab=13.6.7-1~fto10+2, gitaly=13.7.5+dfsg-1~fto10+3).


This doesn't seem to cause any trouble but I noticed that gitlab's check 
is complaining:


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


Indeed, there does not seem to be any newer version of gitlab-shell 
available than 13.13.0+debian-1~bpo10+1.


Best
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Maximilian Stein]

Uploaded gitaly 13.7.5 to fasttrack-staging. If someone can confirm this, I 
will move it to fasttrack.



Hi,

I can confirm that gitaly-git2go is now present, however gitlab now 
refuses to start since it's missing gitaly-13.6.5. So I cannot confirm 
that gitaly-git2go is actually working.


But I guess the refusal to start is just due to the updated gitlab 
package still being missing? If gitlab requires an exact version of 
gitaly shouldn't that be an exact dependency (i.e., "gitaly (=13.6.5-1)" 
instead of "gitaly (>= 13.6~)")?


Best,

Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#962259: Creating Webhooks fails and returns error 500

[Maximilian Stein]

This issue should have been fixed by ruby-attr-encrypted 
3.1.0-3~bpo10+1 from buster-backports.
See the following bug report for more details: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968971


This is weird, it still fails for me. I tested on two independent 
instances both using gitlab 13.6.7-1~fto10+1 and ruby-attr-encrypted 
3.1.0-3~bpo10+1. I tested with a user with activated and with 
deactivated 2FA. In all cases, accessing "-/profile/two_factor_auth" 
failed with error 500.


Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Maximilian Stein]

Hi,

This particular binary is built using go build tags, which I'm not able 
integrate into dh-golang workflow yet.

I'm trying. I was able to build it once in the past but I don't seem to have 
committed it.


I was actually able to build it from the debian source package.

I installed the dependencies:

  golang-gopkg-libgit2-git2go.v31-dev=31.4.3-2 libgit2-dev=1.1.0+dfsg.1-4

Then, I could build the binary from the source package:

  go build -tags static,system_libgit2 ./cmd/gitaly-git2go/

This first failed at a version check at 
~/go/pkg/mod/github.com/libgit2/git2go/v30@v30.0.5/git_system_static.go, 
but I just commented it and it worked.


Best,
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#981124: incron: Zombie processes still piling up

[Maximilian Stein]

Package: incron
Version: 0.5.12-1+deb10u1
Severity: important

Dear Maintainer,

I have been using incron version 0.5.12-1+deb10u1 on Debian Buster and still
observe the issue in bug #930526. I also tried 0.5.12-2 and still see zombie
processes piling up. Moreover, I also occasionally get a SIGSEGV, although
— contrary to #973927 — I do not monitor IN_CREATE.

My current incrontab rule is:
/var/lib/foo/bar/ IN_CLOSE_WRITE,IN_MOVE,loopable=true,dotdirs=false 
/bin/systemctl start myservice.service

My current workaround is to always exit with error as mentioned in bug #930526
(/bin/systemctl start myservice.service && exit 1) and to limit the number of
processes incron.service may start.

Best,
Maximilian

Bug#972754: Bug fixed in 13.5.7-1

[Maximilian Stein]

Dear Maintainer,

In package version 13.5.7-1, this issue is still present. When I try to 
upload a JPG file to an issue, the upload fails unless I manually 
install libimage-exiftool-perl.


Best
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#968626: Error 500 during CI artifacts upload from gitlab-runner

[Maximilian Stein]

Hi!

same for me: after upgrading to 13.5.6, the artifacts upload works even after
reverting my local manual workaround (see "etag.patch" above).


I can confirm that the artifact upload works again without "etag.patch" 
in Gitlab 13.5.7-1, so I think that this issue can be closed now.



Best

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Someone affected should confirm it, I confirmed issue pages that was broken is 
fixed.


My broken pages are actually fixed with Gitlab 13.5.7-1. So for my side, 
this issue can be closed.


Thanks a lot for debugging & fixing!

Best

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Someone else reported the artifacts issue was resolved in 13.5.6. See 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968626#40


Oh, sorry, i didn't mean artifact upload (bug 968626), but the Gitlab 
internal artifacts that are missing from bug 977701 and break some pages.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Some good news finally.

After I switched to using only yarn for all modules (use unpatched 
package.json) webpack is working fine. Now I will try to add back the 
packaged modules one by one so we can know which module broke it.

This is indeed great news!


I will upload 13.5.7 to fasttrack now.

So, just to clarify, this version will still have the artifact issues?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

> Try copying that directory from older versions ?
I tried copying from 13.4.7-1, unfortunately without success. The issue
boards and other resources stay empty. I guess that older versions won't
work because the database might have been changed incompatibly, or?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Is there anything else that we could try to workaround the issues?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#872773: ITP: firefox-passff -- pass manager extension for Firefox

[Maximilian Stein]

On Sun, 4 Feb 2018 10:34:31 +0100 Michael Meskes  wrote:
 
> Where do we stand with this effort. I'd love to see passff in Debian.
As an
> alternative browserpass seems to work with both, Firefox and Chrome.


Has there been any progress on packaging passff? I'd love to see it in
Debian, too.

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#968626: Patch is not working

[Maximilian Stein]

>I have used the patch from Maximilian Stein, but I got the same error.

Have you tried to debug the exact cause of the failure in your case? In my 
message above I outlined how I debugged the issue — maybe that helps to 
investigate your situation.

Best,
Maximilian

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

>I tried the same and this does not fix the bug either.

Same here, just finished testing.

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

So, I got the asset compilation running, but I had to workaround some issues, 
including broken symlinks to js 
libs:_
cd /usr/share/gitlab

# move locale.static elsewhere
mv app/assets/javascripts/locale.static .
mv app/assets/javascripts/locale/index.js{,.bak}
ln -s /usr/share/gitlab/locale.static/index.js 
app/assets/javascripts/locale/index.js

# remove broken symlinks
mkdir /root/vendor_assets_javascripts
cd vendor/assets/javascripts/
mv -t /root/vendor_assets_javascripts chart-lib.min.js clipboard.js 
fuzzaldrin-plus.js g.bar-min.js g.raphael-min.js jquery.nicescroll.min.js
cd -

# create hash file
touch assets-hash.txt
chown git:git assets-hash.txt

# provide webpack
ln -s /usr/bin/webpack node_modules/.bin/webpack

# compile all assets
gitlab-rake gitlab:assets:compile_

However, this unfortunately didn't resolve the issues.
Best,
Maximilian

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

>Unfortunately updating css-loader and postcss did not fix this issue :(

Can I somehow help to untangle this issue? Are there any workarounds maybe?

Best,
Maximilian 

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[Maximilian Stein]

Hi folks,

I just found a workaround for that issue. Apparently, the issue is a
missing type check/type confusion in "etag" (or in the invocation of
this lib). With the patch attached to this mail, artifacts can be
uploaded again.

To debug the issue, I added a begin/resuce block around the failing call
to @app.call in lib/gitlab/middleware/read_only/controller.rb:51 and
dumped the entire stack trace:

  begin
    @app.call(@env)
  rescue NoMethodError => e
    Gitlab::AppLogger.error("Here we are")
    Gitlab::AppLogger.error(e.message)
    e.backtrace.each { |line| Gitlab::AppLogger.error(line) }
  end

The result was dumped into the "application.log" and clearly showed the
origin of the exception:

2020-12-19T15:54:30.166Z: Here we are
2020-12-19T15:54:30.168Z: undefined method `empty?' for 201:Integer
2020-12-19T15:54:30.169Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:70:in
`block in digest_body'
2020-12-19T15:54:30.169Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `block in each'
2020-12-19T15:54:30.169Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `each'
2020-12-19T15:54:30.170Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `each'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:68:in
`digest_body'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:31:in
`call'
2020-12-19T15:54:30.170Z:
/usr/lib/ruby/vendor_ruby/rack/conditional_get.rb:40:in `call'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/head.rb:14:in
`call'
2020-12-19T15:54:30.171Z:
/usr/share/rubygems-integration/all/gems/actionpack-6.0.3.1/lib/action_dispatch/http/content_security_policy.rb:18:in
`call'
2020-12-19T15:54:30.171Z:
/usr/share/gitlab/lib/gitlab/middleware/read_only/controller.rb:52:in `call'

So, right now, I do have a workaround, although I don't where the
problem is exactly (i.e., in gitlab or in etag) nor how it should be
fixed. I hope this helps debugging the issue further!

Best,
Maximilian

--- /usr/lib/ruby/vendor_ruby/rack/etag.rb.old  2020-12-19 18:54:53.266122418 +0100
+++ /usr/lib/ruby/vendor_ruby/rack/etag.rb.new  2020-12-19 18:54:04.169502266 +0100
@@ -67,7 +67,7 @@

 body.each do |part|
   parts << part
-  (digest ||= Digest::SHA256.new) << part unless part.empty?
+  (digest ||= Digest::SHA256.new) << part if part.is_a?(String) && !part.empty?
 end

 [digest && digest.hexdigest.byteslice(0, 32), parts]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

I tried to revert the webpack.config.js and the package.json to the
version from 13.4.7-1 and re-ran postinst, but with no success either.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Indeed, I also notices some minor issues like that one after I upgraded 
to 13.4.7-2~fto10+1. For me, e.g., the issue boards stay empty. In my 
browser's web console I see two error messages among many warnings:



Loading module from 
“https://git.example.org/group/project/-/boards/shortcuts/shortcuts” was 
blocked because of a disallowed MIME type (“text/html”).


Loading module from 
“https://git.example.org/group/project/-/boards/components/app.vue” was 
blocked because of a disallowed MIME type (“text/html”).



My browser added an explanation link to these error messages pointing to 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options.



Most notably, while the message about "app.vue" apparently appears on 
all of my Gitlab pages, the messages about "shortcuts" is only present 
at the issue board site.

Bug#977636: gitlab: Package upgrade hangs indefinitely and consumes all CPU/memory

[Maximilian Stein]

Am 18.12.20 um 09:44 schrieb Pirate Praveen:

One possibility is sassc, but it was affecting only unstable. See in the wiki.

Another thing I noticed, webpack takes more resources than earlier. Try adding 
more swap and upgrade again.

This seems to be the issue here. Indeed, I had version 3.6.4-3~bpo10+1 
of libsass1 and libsass-dev (i.e., buster-backports) installed, which 
have probably the same bug.


Sorry for the noise, I should read the wiki more carefully.


Thanks for your help!

Best,
Maximilian

Bug#977636: gitlab: Package upgrade hangs indefinitely and consumes all CPU/memory

[Maximilian Stein]

Package: gitlab
Version: 13.4.7-2~fto10+1
Severity: important

Dear Maintainer,

During an upgrade to version 13.4.7-1~fto10+1 or 13.4.7-2~fto10+1
there is a rake process in the postinst script that consumes 100 % cpu
and takes up a lot of memory but never finishes, even not after hours.
I finally killed the process with a SIGKILL, and gitlab seems to work
afterwards.

This is the last output I get during the installation:

 snip --

yarn install v1.22.4
[1/4] Resolving packages...
success Already up-to-date.
$ node ./scripts/frontend/postinstall.js

 
success Dependency postinstall check passed.
Done in 1.90s.   
WARNING on line 297, column 11 of 
/usr/share/gitlab/app/assets/stylesheets/framework/common.scss:
Compound selectors may no longer be extended.
Consider `@extend .card, .card-body` instead.
See http://bit.ly/ExtendCompound for details.   
 
WARNING on line 208, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/framework/filters.scss:
Compound selectors may no longer be extended.
Consider `@extend .form-control, :hover` instead.
See http://bit.ly/ExtendCompound for details.   
  
 
WARNING on line 31, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/pages/help.scss:
Compound selectors may no longer be extended.
Consider `@extend .badge, .badge-pill` instead.
See http://bit.ly/ExtendCompound for details.

WARNING on line 665, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/pages/issuable.scss:
Compound selectors may no longer be extended.
Consider `@extend a, :hover` instead.
See http://bit.ly/ExtendCompound for details.

WARNING on line 580, column 15 of 
/usr/share/gitlab/app/assets/stylesheets/pages/pipelines.scss:
Compound selectors may no longer be extended.
Consider `@extend .build-content, :hover` instead.
See http://bit.ly/ExtendCompound for details.

 snip --

Is there a known workaround for that issue?

Apparently, at least for me, a clean upgrade of gitlab is not possible
right now.

Best,
Maximilian

Bug#966653: same version of grpc rubygem from rubygems.org works

[Maximilian Stein]

Has there actually been any progress on these issues? With the latest 
update of gitlab I'm now forced to use the flawed versions of 
ruby-google-protobuf and ruby-grpc that keep on crashing ruby and rake 
processes... Before, I used to downgrade these packages after each 
upgrade as described above, but now the dependency of gitab is explicit.


Is there any workaround now?


Thanks for your help!

Best

Max

Bug#972754: gitlab: Uploading images to issues fails due to missing dependency on libimage-exiftool-perl

[Maximilian Stein]

Package: gitlab
Version: 13.2.10-1+fto10+1
Severity: normal

Dear Maintainer,

After upgrading to version 13.2.10-1+fto10+1 I could no longer upload
images to issues in the issue tracker. A quick [search on the
internet][1] pointed me to a missing dependency on
`libimage-exiftool-perl`. Installing the package manually indeed
fixed the issue and I can now upload images again.

Thanks for your commitment!

Best
Maximilian

[1]: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/60853#note_165956481

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[Maximilian Stein]

Package: gitlab
Version: 13.2.3-2+fto10+1
Severity: normal

Dear Maintainer,

Since the upgrade to above mentioned version, artifact uploads from
gitlab runners fail with an error 500.

Snippet from the job log:

---
Uploading artifacts...
time="2020-08-18T19:42:06+02:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platformarch=amd64 os=linux 
pid=32578 revision=13.0.1 version=13.0.1
debian/pkg/*: found 6 matching files
WARNING: Uploading artifacts to coordinator... failed  id=3633 
responseStatus=500 Internal Server Error status=500 Internal Server Error 
token=
WARNING: Retrying...context=artifacts-uploader 
error=invalid argument
WARNING: Uploading artifacts to coordinator... failed  id=3633 
responseStatus=500 Internal Server Error status=500 Internal Server Error 
token=
WARNING: Retrying...context=artifacts-uploader 
error=invalid argument
WARNING: Uploading artifacts to coordinator... failed  id=3633 
responseStatus=500 Internal Server Error status=500 Internal Server Error 
token=
---


In the production.log I found the following stack trace:

---
Started POST 
"/api/v4/jobs/3633/artifacts?artifact_format=zip_type=archive_in=12+hours"
 for 1.2.3.4 at 2020-08-18 19:42:06 +0200

NoMethodError (undefined method `empty?' for 201:Integer):

lib/gitlab/middleware/read_only/controller.rb:51:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:23:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call' 
---

Unfortunately, the call stack ends here. As far as I can tell, this is
only middelware code, and I was not able to easily find the
problematic usage of `empty?` anywhere nearby this code. Is there a
way to increase the number of lines in the stack trace?

Although the CI jobs fails with this error, the artifacts themselves
are still uploaded successfully and can be viewed/downloaded in the
gitlab UI. So, this only seems to be a minor problem in the artifact
logic.

The particular runner instance was at version 11.2.0+dfsg-2 and worked
with the previously installed gitlab version (13.1.6-1+fto10+1).
Upgrading the runner to version 13.0.1+dfsg-1 did not change the
situation.

Thank you very much!

Best,
Maximilian

Bug#964097: gitlab: "git push" fails with a stacktrace in gitlab code due to outdated ruby version

[Maximilian Stein]

>
> We discussed this in the ruby team [1] and preferred method is to
> patch gitlab to work with ruby 2.5, but we will need some volunteers
> for that. I will try add ruby 2.7 in fasttrack if we see a lot of
> issues with ruby 2.5.
>
Ok, I see. I'll of course continue to report issues that I notice. Is
there maybe an automatic test suite that can be run against gitlab to
systematically check for such issues? A "git push" seems like a very
basic operation that should be covered by such tests.


Best,
Maximilian




signature.asc
Description: OpenPGP digital signature

Bug#942545: gitlab: Issue still present in 13.1.1-1+fto10+1

[Maximilian Stein]

Source: gitlab
Version: 13.1.1-1+fto10+1
Followup-For: Bug #942545

Dear Maintainer,

After upgrading to 13.1.1-1+fto10+1 I noticed that this issue is still
present. I had to change owner and group of the directories `cache`
and `uploads` in /var/lib/gitlab/shared/artifacts/tmp manually in
order to make artifacts in CI work again.

Best,
Maximilian

Bug#964097: gitlab: "git push" fails with a stacktrace in gitlab code due to outdated ruby version

[Maximilian Stein]

Source: gitlab
Version: 13.1.1-1+fto10+1
Severity: important

Dear Maintainer,

After upgrade to above mentioned version, `git push`es started to fail
on my repositories (while `git pull`s continued working).
Investigating the issue I noticed that there were stack traces logged
into /var/log/gitlab/exceptions_json.log every time I tried pushing.

The stack traces pointed to lib/gitlab/gl_repository/identifier.rb:52,
where apparently a string is converted to an integer. The excetion
message reads "wrong number of arguments (given 3, expected 1..2)".
According to the documentation of ruby, there were only two arguments
to `Integer` in 2.5.1
(https://ruby-doc.org/core-2.5.1/Kernel.html#method-i-Integer), while
there was a third one added later (e.g. present in 2.7). However,
since my system is based on buster, I have ruby 2.5.1 installed.

I could work around my issue by removing the third `exception: false`
parameter to `Integer` in
/usr/share/gitlab/lib/gitlab/gl_repository/identifier.rb:52.

Since there is no newer ruby version available in backports or
fasttrack, I'd prefer to stick to the stable version. What solution
can you recommend? Do you need any more information?

Relevant package versions:

gitlab: 13.1.1-1+fto10+1
gitlab-common: 13.1.0+dfsg-1~bpo10+1
gitaly: 13.1.0+dfsg-1~bpo10+1
gitlab-shell: 13.3.0+debian-1~bpo10+1

Best,
Maximilian

Bug#961127: fai-client: Error in class definition script does not stop installation

[Maximilian Stein]

Package: fai-client
Version: 5.8.4~bpo9+2
Severity: normal

Dear Maintainer,

Today I discovered that a task error raised in a class definition
script does not stop the installation/softupdate.

In my example (see log excerpt below) the class script
/var/lib/fai/config/class/95-dep.sh sets an error calling
"task_error 800". FAI detects this and uploads log files, however then
continues with the next task (the remaining class definition scripts
are not executed). The softupdate continues as usual and the log files
are finally uploaded again (causing a conflict).

Looking at the code, `/usr/lib/fai/subroutines` apparently calls
`fai-class` but does not check if a fatal task error was set (or if
`fai-class` exited with error). As far as I can tell, the issue still
seems to be present in version 5.9.4.

Thanks for your help!

Best,
Maximilian


-- fai.log

 -
   Fully Automatic Installation  -  FAI

   5.8.4~bpo9+2   (c) 1999-2019
   Thomas Lange  
 -
Starting FAI execution - 20200520_140231

Using configuration files from /etc/fai
Calling task_confdir
FAI_FLAGS: 
Setting SERVER=fai.example.org. Value extracted from FAI_CONFIG_SRC.
Monitoring to server fai-monitor.example.org enabled.
FAI_CONFIG_SRC is set to git+ssh://f...@fai.example.org/srv/git/fai.git
Updating git copy in /var/lib/fai/config
HEAD is now at 12345678... foobar
Source hook: setup.DEFAULT.sh
hostname: examplehost
setup.DEFAULT.sh OK.
Calling task_setup
FAI_FLAGS: 
Calling task_defclass
fai-class: Defining classes.
Executing /var/lib/fai/config/class/10-base-classes.sh.
./10-base-classes.sh defined classes:  LINUX AMD64 DHCPC
10-base-classes.sh   OK.
...
Executing /var/lib/fai/config/class/70-custom-classes.sh.
70-custom-classes.sh OK.
Executing /var/lib/fai/config/class/95-dep.sh.
FATAL ERROR: class ABC conflicts with DEF
Error in task defclass. Code: 800
Traceback: task_error conflicts source main
Calling hook: savelog.DEFAULT
'//var/log/fai/last-localhost' -> 'localhost/last'
savelog.DEFAULT  OK.
Source hook: savelog.ADBASE.sh
savelog.ADBASE.shOK.
Save log files via ssh to 
f...@fai.example.org:log//examplehost/softupdate-2020-05-20T14:02:33+02:00
FATAL ERROR. Installation stopped.
List of all classes:  DEFAULT LINUX AMD64 DHCPC GRUB ARCH_PC DEBIAN STRETCH ABC 
DEF
Calling task_defvar
Executing DEBIAN.var
...

Bug#959232: linux-image-5.5.0-2-amd64: system freeze after suspend-to-ram: potentially IRQ-related issue

[Maximilian Stein]

Package: src:linux
Version: 5.5.17-1
Severity: normal

Dear maintainer,

Occasionally my system freezes after waking up from suspend-to-ram.
More precisely, the KDE lock screen appears, I can type my passphrase,
but then the screen just stays black leaving me movable mouse. I
neither can switch to a virtual terminal (Strg+Alt+F1 etc.) nor kill
the session with SysRq+K. Rebooting with SysRqs still works though.

Investigating the issues in the kernel logs reveals a message
indicating a NULL ptr derefererence in the kernel that is related to
IRQ (see below).

My device was in suspend-to-ram since yesterday so the attached log
includes all messages since I opened the laptop lid. It was generated
using:

  journalctl -b-1 --dmesg --since today --quiet --no-hostname --grep 
'^(?!iptables:)'

Such freezes happen about once a week and since I got the device (so
it also happened with older kernels).

The device is a Lenovo X1 Carbon 6th Generation with an Intel
i7-8650U with up-to-date BIOS running Debian Testing.

Any help is highly appreciated.

Best,
Maximilian


-- Package-specific info:
** Version:
Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15)

** Command line:
BOOT_IMAGE=/vmlinuz-5.5.0-2-amd64 root=/dev/mapper/mia--vg-root ro 
rootflags=subvol=@ quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Mai 01 10:49:38 kernel: Freezing user space processes ... (elapsed 0.002 
seconds) done.
Mai 01 10:49:38 kernel: OOM killer disabled.
Mai 01 10:49:38 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.
Mai 01 10:49:38 kernel: printk: Suspending console(s) (use no_console_suspend 
to debug)
Mai 01 10:49:38 kernel: wlp2s0: deauthenticating from e8:df:70:xx:xx:xx by 
local choice (Reason: 3=DEAUTH_LEAVING)
Mai 01 10:49:38 kernel: psmouse serio1: Failed to disable mouse on 
isa0060/serio1
Mai 01 10:49:38 kernel: e1000e: EEE TX LPI TIMER: 0011
Mai 01 10:49:38 kernel: ACPI: EC: interrupt blocked
Mai 01 10:49:38 kernel: ACPI: Preparing to enter system sleep state S3
Mai 01 10:49:38 kernel: ACPI: EC: event blocked
Mai 01 10:49:38 kernel: ACPI: EC: EC stopped
Mai 01 10:49:38 kernel: PM: Saving platform NVS memory
Mai 01 10:49:38 kernel: Disabling non-boot CPUs ...
Mai 01 10:49:38 kernel: smpboot: CPU 1 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 2 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 3 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 4 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 5 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 6 is now offline
Mai 01 10:49:38 kernel: smpboot: CPU 7 is now offline
Mai 01 10:49:38 kernel: ACPI: Low-level resume complete
Mai 01 10:49:38 kernel: ACPI: EC: EC started
Mai 01 10:49:38 kernel: PM: Restoring platform NVS memory
Mai 01 10:49:38 kernel: Enabling non-boot CPUs ...
Mai 01 10:49:38 kernel: x86: Booting SMP configuration:
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Mai 01 10:49:38 kernel: CPU1 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4
Mai 01 10:49:38 kernel: CPU2 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6
Mai 01 10:49:38 kernel: CPU3 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 4 APIC 0x1
Mai 01 10:49:38 kernel: CPU4 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 5 APIC 0x3
Mai 01 10:49:38 kernel: CPU5 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 6 APIC 0x5
Mai 01 10:49:38 kernel: CPU6 is up
Mai 01 10:49:38 kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7
Mai 01 10:49:38 kernel: CPU7 is up
Mai 01 10:49:38 kernel: ACPI: Waking up from system sleep state S3
Mai 01 10:49:38 kernel: ACPI: EC: interrupt unblocked
Mai 01 10:49:38 kernel: pcieport :00:1d.0: Intel SPT PCH root port ACS 
workaround enabled
Mai 01 10:49:38 kernel: pcieport :00:1c.2: Intel SPT PCH root port ACS 
workaround enabled
Mai 01 10:49:38 kernel: pcieport :00:1c.4: Intel SPT PCH root port ACS 
workaround enabled
Mai 01 10:49:38 kernel: pcieport :00:1c.0: Intel SPT PCH root port ACS 
workaround enabled
Mai 01 10:49:38 kernel: ACPI: EC: event unblocked
Mai 01 10:49:38 kernel: xhci_hcd :00:14.0: port 6 resume PLC timeout
Mai 01 10:49:38 kernel: usb 2-3: Disable of device-initiated U1 failed.
Mai 01 10:49:38 kernel: usb 2-3: Disable of device-initiated U2 failed.
Mai 01 10:49:38 kernel: nvme nvme0: Shutdown timeout set to 8 seconds
Mai 01 10:49:38 kernel: nvme nvme0: 8/0/0 default/read/poll queues
Mai 01 10:49:38 kernel: usb 2-3: reset SuperSpeed Gen 1 USB device number 2 
using xhci_hcd
Mai 01 10:49:38 kernel: usb 1-8: reset high-speed USB device number 4 using 
xhci_hcd
Mai 01 10:49:38 kernel: usb 1-9: reset full-speed USB device number 5 using 
xhci_hcd
Mai 01 10:49:38 kernel: acpi LNXPOWER:01: Turning OFF
Mai 01 10:49:38 

Bug#954440: linux-image-amd64: Dependency missing

[Maximilian Stein]

Package: linux-image-amd64
Version: 4.19+105+deb10u3~bpo9+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I am using the version of linux-image-amd64 available on backports.
Unfortunately, upgrading from 4.19+105+deb10u1~bpo9+1 to the current
version 4.19+105+deb10u3~bpo9+1 fails as the dependency package
linux-image-4.19.0-0.bpo.8-amd64 is unavailable.

This is also indicated in the package search:
https://packages.debian.org/stretch-backports/linux-image-amd64

Thanks for your commitment!

Cheers,
Maximilian

Bug#899143: strace

[Maximilian Stein]

On Tue, 18 Jun 2019 08:44:38 +0200 Martin Dosch 
wrote:

> I also have this problem in sid. As a user I get this error:


Hey,

I actually got the same issue on my machine after having updated to
bullseye/testing. Man pages were only viewable as root. I noticed that
this behaviour originates from firejail which happened to wrap "less"
through a symlink "/usr/local/bin/less" to "/usr/bin/firejail", which
was once installed by firecfg. However, there was no such link for man
itself.

I could solve the issue by either starting man in firejail right away
(`firejail man ls`), or by removing the link for less in
"/usr/local/bin/less".

Best

Maximilian



signature.asc
Description: OpenPGP digital signature

Bug#939858: cryptsetup-initramfs not installed by debian installer

[Maximilian Stein]

Package: cryptsetup-initramfs
Severity: normal
Tags: d-i

Dear Maintainer,

Recently, I installed a machine using the "Debian Bullseye Official
Snapshot amd64 DVD Binary-1 20190805-04:11". I chose to use an
encrypted LVM using the entire disk and continued to install the
system.

Unfortunately, after the installation had finished without any issues
(apparently), the system was unable to unlock the encrypted disk
during boot. I again booted from the installer image, unlocked the
disk, chrooted into the target system. There I noticed that no
initramfs support of cryptsetup was installed and manually installed
the package "cryptsetup-initramfs". The system was now able to boot.

Apparently, for some reason, cryptsetup-initramfs was not installed
automatically, although it was required for boot.

Best,
Maximilian

Bug#930410: scribus: Security-Update of Ghostscript 9.26a~dfsg-0+deb9u3 breaks scribus in Debian Stretch

[Maximilian Stein]

Dear Maintainer,

I can confirm this behaviour. Import of PS/EPS/PDF files in scribus
fails with ghostscript errors:

> PostScript import failed when calling gs as:
> -q -dNOPAUSE -dNODISPLAY -dBATCH -dDELAYBIND -g3368x2384 -r288
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 -c 0 0 translate
-sTraceFile=/home/steiny/.scribus//ps.out
-sExportFiles=/home/steiny/flyer /usr/lib/scribus/import.prolog
/home/steiny/file.pdf -c flush cfile closefile quit
>
> Ghostscript diagnostics:
>
>     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
>
>     alse
>
>     Execution stack:
>   
>    %interp_exit   .runexec2   --nostringval--  
--nostringval--   --nostringval--   2   %stopped_push  
--nostringval-- 
  

>    --nostringval--   --nostringval--   false   1  
%stopped_push   2044   1   3   %oparray_pop   2043   1   3  
%oparra 
  

>    y_pop   2024   1   3   %oparray_pop   1884   1   3  
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --no
>     stringval--   --nostringval--   --nostringval--   2  
%stopped_push   --nostringval--
>
>     Dictionary stack:
>
>    --dict:1236/1684(ro)(G)--   --dict:0/20(G)--  
--dict:78/200(L)--
>
>     Current allocation mode is global
>
>     Current file position is 2202


I temporarily downgraded ghostscript (and its libs) to
9.06~dfsg-2+deb8u7 (jessie) to be able to import these file types again.

Best

Maximilian



signature.asc
Description: OpenPGP digital signature

Bug#922070: gitlab: no diffs visible in merge requests and log

[Maximilian Stein]

> You can wait till it reaches the archive (max by 24 hours I think) or
add the following to your sources.list

> deb http://incoming.debian.org/debian-buildd buildd-stretch-backports
main contrib

> and apt -t buildd-stretch-backports install ruby-grape

Thanks! I just installed gitlab 11.4.9+dfsg-2~bpo9+1 and the issue is
apparently gone! So the bug can be closed.

Max




signature.asc
Description: OpenPGP digital signature

Bug#922070: gitlab: no diffs visible in merge requests and log

[Maximilian Stein]

Hi,


Am 18.02.19 um 12:17 schrieb Abhijith PA:
> We have updated gitlab to 11.4.x in stable backports. Can you update and
> check if it still persists.
>
>
> --abhijith
>
Thanks a lot! Unfortunately, I get a dependency problem right now:


# apt install -t stretch-backports gitlab

...

The following packages have unmet dependencies:
 gitlab : Depends: ruby-grape (>= 1.1~) but 1.0.2-1~bpo9+1 is to be
installed
  Recommends: certbot but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


# apt policy ruby-grape

ruby-grape:
  Installed: 1.0.2-1~bpo9+1
  Candidate: 1.0.2-1~bpo9+1
  Version table:
 1.1.0-2 50
 50 http://deb.debian.org/debian testing/main amd64 Packages
 50 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 1.0.2-1~bpo9+1 100
    100 http://deb.debian.org/debian stretch-backports/main amd64
Packages
    100 /var/lib/dpkg/status
 0.16.2-2 990
    990 http://deb.debian.org/debian stretch/main amd64 Packages

Will these dependencies be available in stretch-backports, too?


Best,

Maximilian


Maximilian Stein
E-Mail: m...@steiny.biz <mailto:m...@steiny.biz>



signature.asc
Description: OpenPGP digital signature

Bug#922070: gitlab: no diffs visible in merge requests and log

[Maximilian Stein]

Source: gitlab
Version: 11.2.8+dfsg-2~bpo9+2
Severity: normal
Tags: upstream

Dear Maintainer,

Since I upgraded my Gitlab installation to 11.2.8, I cannot see any
diffs anymore (e.g., in merge requests and the log). Instead, it
always says "This source diff could not be displayed because it is too
large.". This is quite annoying and forces me to view everything
locally.

This issue might be the one documented in [1], so it should be fixed
in Gitlab 11.4.

Thanks for your commitment!

Yours sincerely,
Max

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

-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#914360: Bug #914360: tinc: Random segfault after connection drop

[Maximilian Stein]

Dear Bernhard,

Thanks for your analysis!

In the meanwhile I have installed systemd-coredump, so I hope to be able
to provide more details in case tincd crashes again.

Indeed, I am running an unmodified version of the package from buster,
so your analysis should be correct. Maybe the connection object ptr c
was free'd or NULL?

Best,
Maximilian




signature.asc
Description: OpenPGP digital signature

Bug#914360: tinc: Random segfault after connection drop

[Maximilian Stein]

Package: tinc
Version: 1.0.35-1
Severity: normal

Dear Maintainer,

One instance of the tinc daemon crashed after running for quite a
while.

Syslog shows a peer's connection had dropped immediately before the
crash:

Nov 22 10:08:38 hostname tincd[691]: Flushing meta data to abcd (1.2.3.4 port 
30458) failed: Connection reset by peer
Nov 22 10:08:38 hostname tincd[691]: Closing connection with abcd (1.2.3.4 port 
30458)
Nov 22 10:08:38 hostname tincd[691]: Got ANS_KEY from efgh (5.6.7.8 port 50551) 
destination abcd which is not reachable
Nov 22 10:08:38 hostname tincd[691]: Connection from 1.2.3.4 port 22087
Nov 22 10:08:38 hostname kernel: [52018.886642] tincd[691]: segfault at 98c ip 
557ae018e29d sp 7c40f5b0 error 4 in tincd[557ae0189000+19000]


This is the first and only time I have observed this behaviour. I hope
the provided information can help finding the issue.

Thanks!
Maximilian


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tinc depends on:
ii  libc6  2.24-11+deb9u3
ii  liblzo2-2  2.08-1.2+b2
ii  libssl1.1  1.1.0f-3+deb9u2
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

tinc recommends no packages.

tinc suggests no packages.

-- Configuration Files:
/etc/default/tinc changed [not included]

-- no debconf information

Bug#899102: Cross-submit on Github

[Maximilian Stein]

Hey,

in the meantime, I cross-submitted this bug to the upstream Github
project: https://github.com/imaplib2/imaplib2/issues/3

Best,

Maximilian Stein
E-Mail: m...@steiny.biz <mailto:m...@steiny.biz>



signature.asc
Description: OpenPGP digital signature

Bug#899102: python3-imaplib2: connection to IMAP-SSL host fails on armhf

[Maximilian Stein]

Package: python3-imaplib2
Version: 2.57-1
Severity: important

Dear Maintainer,

Unfortunately, imaplib2 can only connect to an IMAP/IMAP-SSL host on amd64
but not on armhf. The behavior is consistent in 2.57-1 and
2.55-1+deb9u1.

In the python interactive interpreter:
>>> import imaplib2
>>> c=imaplib2.IMAP4('imap.strato.de')
  26:45.17 imap.strato.de reader last 20 log messages:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 400, in __init__
self.welcome = self._request_push(name='welcome', 
tag='continuation').get_response('IMAP4 protocol error: %s')[1]
TypeError: 'NoneType' object is not subscriptable

The same command sequence does not cause an exception on at least
amd64. Using "IMAP4_SSL" instead of "IMAP4" yields the exact same
result.

Thanks!

Best,
Maximilian


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (900, 'stable'), (500, 'stable-updates'), (100, 
'testing')
Architecture: armhf (armv7l)

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

Versions of packages python3-imaplib2 depends on:
ii  python3  3.5.3-1

python3-imaplib2 recommends no packages.

python3-imaplib2 suggests no packages.

-- no debconf information

Bug#898409: virtualbox-ext-pack: postinst script interferes with firejail

[Maximilian Stein]

Package: virtualbox-ext-pack
Version: 5.2.10-4~bpo9+1
Severity: normal

Dear Maintainer,

I installed firejail which includes firecfg(1) to setup symbolic links
in /usr/local/bin/ to run the linked programs in the firejail sandbox.
Among the configured programs is wget(1) which is then restricted by
its policy (/etc/firejail/wget.profile). Particularily, wget cannot
write to /usr/share/virtualbox-ext-pack according to this profile.

Therefore, the wget in virtualbox-ext-pack's postinst script fails.

Solution could be to explicitly use /usr/bin/wget to download the file
thus circumventing firejail's restrictions.

Best,
Maximilian

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (800, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages virtualbox-ext-pack depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  virtualbox 5.2.10-dfsg-6~bpo9+1
ii  wget   1.18-5+deb9u1

virtualbox-ext-pack recommends no packages.

virtualbox-ext-pack suggests no packages.

-- debconf information:
* virtualbox-ext-pack/license: true

Bug#891455: fai-setup-storage: Allow mount binds

[Maximilian Stein]

> I'm not sure when you really need the bind mounts during
> installation. If they are only needed when the customization scripts
> are executed, you could use ainsl(1) in one of your scripts and then
> add the admin user.
>
> If you really need the bind mounts before, go and use a hook. This is
> really easy and that's what hooks are made for.
>
> Currently I do not like to touch setup-storage for adding this,
> because it can easily achieved using a hook. Or is there any reason
> why it's important for setup-storage to support bind mounts?
>
Well, no, using hooks works fine. It would just have felt a little
"cleaner" to keep all information about partitions (i.e., everything
thats ends up in /etc/fstab) in one place... But I'm fine with my
current solution, too.