Summary

I’m running debsums -c daily, hoping to catch file corruption and/or other abnormalities early. (The Debian package even provides a pre-made cronjob for this task.)

debsums -c gitlab-ce reports .gitlab_kas_secret as deviating from the provided md5sum.

Steps to reproduce

1. apt install gitlab-ce
2. vi /etc/gitlab/gitlab.rb # set external URL
3. gitlab-ctl reconfigure
4. debsums -c gitlab-ce

What is the current bug behavior?

# debsums -c gitlab-ce
/opt/gitlab/embedded/service/gitlab-rails/.gitlab_kas_secret

What is the expected correct behavior?

# debsums -c gitlab-ce
#

Details of package version

ii  gitlab-ce      14.5.1-ce.0  amd64        GitLab Community Edition (including NGINX, Postgres, Redis)

Environment details

• Operating System: Ubuntu 20.04
• Installation Target, remove incorrect values:
  • VM
• Installation Type, remove incorrect values:
  • New Installation
• Is there any other software running on the machine: plenty
• Is this a single or multiple node installation? single

Configuration details

external_url 'http://localhost'

Related issues

#2635 is basically the same, but I’ve never seen debsums complain about schema.rb.

• VSCode Version: 1.53.0
• OS Version: Ubuntu Linux 20.04

Steps to Reproduce:

1. install .deb package
2. run debsums -s

Does this issue occur when all extensions are disabled?: Yes

I’d like to resurrect #37762: the checksums for .desktop files included in the .deb archive fail to pass post-install.

$ debsums -s code
debsums: changed file /usr/share/applications/code.desktop (from code package)
debsums: changed file /usr/share/applications/code-url-handler.desktop (from code package)

This happens because the postinst script calls desktop-file-install for the .desktop files, which adds an X-Desktop-File-Install-Version entry to them, and hence the checksums change.

I don’t know why the desktop-file-install call is there, as including the .desktop files in the deb archive is sufficient to have them installed (in their proper place under /usr/share/applications/), with the checksum intact.

I built the package with just those desktop-file-install calls removed (see below), after which the checksums pass post-install (with no other changes that I can see).

diff --git a/resources/linux/debian/postinst.template b/resources/linux/debian/postinst.template
index c72fe5f9f5..dcc147de93 100755
--- a/resources/linux/debian/postinst.template
+++ b/resources/linux/debian/postinst.template
@@ -12,12 +12,6 @@ ln -s /usr/share/@@NAME@@/bin/@@NAME@@ /usr/bin/@@NAME@@
 # developers would prefer a terminal editor as the default.
 update-alternatives --install /usr/bin/editor editor /usr/bin/@@NAME@@ 0
 
-# Install the desktop entry
-if hash desktop-file-install 2>/dev/null; then
-       desktop-file-install /usr/share/applications/@@NAME@@.desktop
-       desktop-file-install /usr/share/applications/@@NAME@@-url-handler.desktop
-fi
-
 # Update mimetype database to pickup workspace mimetype
 if hash update-mime-database 2>/dev/null; then
        update-mime-database /usr/share/mime

1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:

ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android

> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk

./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log

The top of that file, build.sh, refers to /bin/sh, but on Ubuntu and Debian, /bin/sh has been Dash for quite a while, whereas build.sh seems to written for Bash (where function is a valid keyword):

ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh 
#!/bin/sh

function execute() {
    cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}

I suggest switching the shebang to #/bin/bash, or better yet, #!/usr/bin/env bash (for path-agnosticity). In my environment, using either one fixes the build.

A fix has recently been committed upstream: https://salsa.debian.org/debian/ddclient/-/commit/82d99d1dfb0fb002a15e081fdc7ccf8f96215dc6

The Debian BTS has a related report [1] which suggests to me this issue should have been fixed way back in v1.11. But even if installing wasn’t broken, with the legacy databases discontinued, it’s not much use in the long term.

Geoip-database-contrib has already been removed from Debian entirely [2] due to deprecation by upstream, apparently in favor of geoipupdate [3].

(I’m not affiliated with either package and have no solutions; I’m just documenting the connections here.)

* [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666063
* [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900400
* [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885441

Replace instruction using ln -s to enable Apache site to use a2ensite instead in Debian and derivatives. Closes #884.

Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:

ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf

As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:

a2ensite nextcloud.conf

The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.

Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.

Aikoinaan kun Squeezeä Lennyä testasin, tuota hidastelua aiheutti se, että Nautilus (tai jokin) halusi nuuskia verkossa näkyviä Windows-verkkokansioita. Sen keksittyäni sen estäminen oli helppoa, mutten kyllä enää kuollaksenikaan muista että miten.

Edit: Taisi olla niinkin vanha kuin Lenny se jota testasin.