Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Marc

Certainly. If you know those I'm happy to fix them.

I thought I had fixed them all already.

Cheers

// Ola

On Tue, 11 Jun 2024 at 15:52, Marc Haber  wrote:
>
> On Mon, Jun 10, 2024 at 11:02:30PM +0200, Ola Lundqvist wrote:
> > Sorry, I meant to run with dash -x. Or do dash not have that option?
>
> It has this option.
>
> But I see a problem in cron-apt using bashisms while using the /bin/sh
> shebang line. I don't know whether this have to do with this, bug, but
> it should be fixed anyway.
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Marc

Sorry, I meant to run with dash -x. Or do dash not have that option?

Cheers

// Ola

On Wed, 15 May 2024 at 10:36, Marc Haber  wrote:
>
> > Can you run it with bash -x from cron? Hopefully it tells where it breaks
>
> Using bash will not help here, that's the problem. cron-apt is a /bin/sh
> script, and on many systems /bin/sh is dash. And, $RANDOM doesn't exist
> in dash.
>
> Change cron-apt's shebang line to use /bin/bash and it should be fine.
>
> Now we probably can move on to stage 6 of debugging "how did that
> ever work?", since we're having /bin/sh point to dash for a while and
> this issue just appeared on of my _stable_ systems.
>
> Greetings
> Marc
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#947478: Fwd: freeimage and CVE-2019-12214

[Ola Lundqvist]

Information about this CVE and bug.

-- Forwarded message -
From: Cyrille Bollu 
Date: Sun, 14 Apr 2024 at 12:24
Subject: Re: freeimage and CVE-2019-12214
To: Ola Lundqvist 
Cc: 


Hi,

I've performed a more thoroughful investigation and have informed NIST
that the offending line is actually to be found in openjpeg between
version 2.0.0 up to (excluding) 2.1.0.

Debian Buster isn't affected as it uses version 2.3.0-2+deb10u2.

Hereunder copy of the email I've sent ot NIST.

Best regards,

Cyrille

>Message-ID: <981f8fc77d9e0fee8399a19e6e4c9c64ceeea9a7.ca...@bollu.be>
>Subject: CVE-2019-12214: missing vulnerable configuration
>From: Cyrille Bollu 
>To: cpe_diction...@nist.gov
>Date: Sun, 14 Apr 2024 12:01:43 +0200
>Content-Type: text/plain; charset="UTF-8"
>Content-Transfer-Encoding: quoted-printable
>User-Agent: Evolution 3.46.4-2
>MIME-Version: 1.0
>X-Evolution-Identity: 953def08ae37ee7006cd76b472f065ecb205f7e1
>X-Evolution-Fcc:
>folder://d19e895bfc6f11c136a14747fb40c471b2a393e7/Sent
>X-Evolution-Transport: 80f305883d50f910e4b81fcb40b6c46360542068
>X-Evolution-Source:
>
>Dear NIST,
>
>As part of an investigation performed on-behalf of Debian-LTS team,
>I've found out that CVE-2019-12214 is actualy located in code from the
>openjpeg project (https://github.com/uclouvain/openjpeg) which
>freeimage copied in its source tree.
>
>The offending line, "memcpy(l_cp->ppm_data_current, p_header_data,
>l_N_ppm);", has been introduced in version 2.0.0 (see
>https://github.com/uclouvain/openjpeg/archive/refs/tags/version.2.0.tar.gz
)
>and removed in version 2.1.1 (see
>https://github.com/uclouvain/openjpeg/archive/refs/tags/v2.1.1.tar.gz)
.
>
>So, all intermediatory versions (version 2.0.0 included) might be
>vulnerables (I haven't investigated more than just the presence of
>absence of this line though).
>
>I think it's worth updating CVE-2019-12214 with this information.
>
>Best regards,
>
>Cyrille Bollu

Le samedi 13 avril 2024 à 09:56 +0200, Cyrille a écrit :
> I don’t know anything about your procedures, but I don’t see why we
> wouldn’t…
>
> I would also contact NIST (or whoever is in charge of the CVE
> database; I can’t remember by heart who it is) to let them know this,
> so they update the CVE’s vulnerable configurations. I’ll try to do
> that next week, but I will probably first have to find out which
> exact versions of openjpeg2 have been affected (which will probably
> be quite difficult for me)
>
> Nice week-end
>
> Cyrille
>
> > Le 13 avr. 2024 à 00:22, Ola Lundqvist  a écrit :
> >
> > Hi Cyrille
> >
> > > On Fri, 12 Apr 2024 at 16:32, Cyrille Bollu 
> > > wrote:
> > >
> > > Hi Ola,
> > >
> > > Thank you for your help.
> > >
> > > So, IIUC:
> > >
> > > 1. CVE-2019-12214 shouldn't be assigned to freeimage in Debian
> > > Buster;
> > > 2. CVE-2019-12214 might be assigned to source package openjpeg2
> > > or
> > > openjpeg (the later doesn't seem to be available in Buster
> > > though)
> >
> > Yes, potentially so. At least if I understand the email from
> > Santiago correctly.
> >
> > freeimage build depends on libopenjp2-7-dev which is built from
> > openjpeg2 so in buster it is openjpeg2 where it should belong.
> >
> > But I do not know whether we typically re-assign things like this
> > or
> > not so I do not want to give advice for this. Better if someone
> > else
> > who knows the practice answers this.
> >
> > // Ola
> >
> > --
> > --- Inguza Technology AB --- MSc in Information Technology 
> > >  o...@inguza.como...@debian.org|
> > >  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> > ---
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1042875: cron-apt: man cron-apt mentions a configuration example file without any configuration

[Ola Lundqvist]

Hi

Thank you for noticing. I hope to fix on next update.

// Ola

On Wed, 2 Aug 2023 at 08:51, Carles Pina i Estany  wrote:

> Package: cron-apt
> Version: 0.13.0+nmu1
> Severity: minor
>
> Dear Maintainer,
>
> I've tested this in cron-apt versions 0.13.0.1 (Bookworm) and
> 0.13.0+nmu1 (Bullseye).
>
> I was trying to change some configuration and did: man cron-apt
>
> It says (under "CONFIGURATION"):
> """
> The  variables  that you can set in /etc/cron-apt/config is documented
> in the configuration example in /usr/share/doc/cron-apt/examples/config
> """
>
> The file /usr/share/doc/cron-apt/examples/config does not contain any
> example but two lines:
> """
> # Configuration for cron-apt. For further information about the possible
> # configuration settings see /usr/share/doc/cron-apt/README.gz.
> """
>
> I would suggest that the "man" should mention
> /usr/share/doc/cron-apt/README.gz straight away.
>
> Also, I think that reads better ".../etc/cron-apt/config are documented in
> the..." (change is to are).
>
> Thanks for cron-apt! I use it in quite a few systems for a long time and
> I'm really happy with it.
>
> Thank very much!
>
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 11.7
>   APT prefers oldstable-security
>   APT policy: (500, 'oldstable-security'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 cron-apt depends on:
> ii  apt  2.2.4
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon]  3.0pl1-137
> ii  liblockfile11.17-1+b1
> ii  postfix [mail-transport-agent]  3.5.18-0+deb11u1
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/action.d/3-download changed [not included]
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1051791: Patch: add InRelease files with signature

[Ola Lundqvist]

Hi Cyprien

Thank you very much for this. I guess this could even be a candidate for a
point release.

Do I understand correctly that the file is "InRelease" and not
"InRelease.gpg". If that is the case, the patch looks good.

Cheers

// Ola

On Tue, 12 Sept 2023 at 18:09, Cyprien Nicolas  wrote:

> Package: debarchiver
> Version: 0.11.7
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> We use debarchiver for a company repository, and since we started
> upgrading our servers to Bookworm, our hosts fail to verify our
> repository:
>
> W: Pas d'entrée de hachage dans le fichier Release
> /var/lib/apt/lists/partial/debian.octopuce.fr_octopuce_dists_bookworm_Release
> E: Le dépôt http://debian.octopuce.fr/octopuce bookworm Release ne
> fournit que de faibles informations de sécurité.
>
> Sorry for the French, I no longer have the full LC_ALL=C output, the
> first one said "No Hash entry in Release file", and the second one
> someting about "weak security".
>
> With respect to #825123, we checked our signing key (rsa2048) and the
> default signature algorithm (sha256) but the issue is unreleated.
>
> We found out that the InRelease file is not generated by
> debarchiver. We patched debarchiver to do so, along with the
> Release.gpg file, and now the repository is verified.
>
> I'm not sure how to add patches with reportbug yet, so I put it inline
> here:
>
> -*- Patch Begins here -*-
> --- debarchiver.orig2021-09-07 15:10:31.0 +0200
> +++ debarchiver 2023-09-12 17:23:12.171618835 +0200
> @@ -1302,17 +1302,26 @@
>   3);
>  if ($gpgkey) {
>  unlink("$path/Release.gpg");
> +unlink("$path/InRelease");
> if ($gpgpassfile) {
> cmdaction("cat $gpgpassfile | gpg --batch --no-tty -a -b -s -u
> $gpgkey " .
>   "--pinentry-mode loopback --passphrase-fd 0 -o
> $path/Release.gpg $path/Release",
>   "Sign Release file for $path with key '$gpgkey'",
>   3);
> +   cmdaction("cat $gpgpassfile | gpg --batch --no-tty --clearsign
> -u $gpgkey " .
> + "--pinentry-mode loopback --passphrase-fd 0 -o
> $path/InRelease $path/Release",
> + "Sign InRelease file for $path with key '$gpgkey'",
> + 3);
> }
> else {
> cmdaction("gpg -a -b -s -u $gpgkey " .
>   "-o $path/Release.gpg $path/Release",
>   "Sign Release file for $path with key '$gpgkey'",
>   3);
> +   cmdaction("gpg --clearsign -u $gpgkey " .
> + "-o $path/InRelease $path/Release",
>



> + "Sign InRelease file for $path with key '$gpgkey'",
> + 3);
> }
>  }
>  unlink("$configpath");
> -*- Patch Ends here -*-
>
> Kind regards,
> Cyprien
>
> -- System Information:
> Debian Release: 12.1
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/bash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages debarchiver depends on:
> ii  adduser3.134
> ii  apt-utils  2.6.1
> ii  dpkg-dev   1.21.22
> ii  opalmod0.2.2.1
>
> Versions of packages debarchiver recommends:
> ii  mailutils [mailx]   1:3.15-4
> ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2
>
> Versions of packages debarchiver suggests:
> pn  devscripts  
> ii  gnupg   2.2.40-1.1
>
> -- Configuration Files:
> /etc/cron.d/debarchiver changed:
> MAILTO=""
> */5 * * * * debarchiver /usr/local/bin/debarchiver-patch-inrelease
> --scanall -so | logger -t debarchiver -p daemon.info
>
> /etc/debarchiver.conf changed:
> $destdir = "/var/www/debian/octopuce/dists";
> $inputdir = "/var/lib/debarchiver/incoming";
> $copycmd = "mv -f";
> $rmcmd = "true";
> $vrfycmd = "dscverify";
> $cinstall = "installed";
> $verifysignatures = 1;
> $ignoredestcheck = 0;
> $verifysignaturesdistinput = 0;
> $bzip = 1;
>  %distinputdirs =
> (
> oldoldoldstable => 'oldoldoldstable',
> oldoldstable => 'oldoldstable',
> oldstable => 'oldstable',
> stable => 'stable',
> testing => 'testing',
> unstable => 'unstable',
> experimental => 'experimental'
> );
> @distributions = ('oldoldoldstable', 'oldoldstable','oldstable', 'stable',
> 'testing', 'unstable', 'experimental');
> $majordefault = "main";
>  %distmapping =
> (
> oldoldoldstable => 'stretch',
> oldoldstable => 'buster',
> oldstable => 'bullseye',
> stable => 'bookworm',
> testing => 'trixie',
> unstable => 'sid',
> 

Bug#1050468: ITS: icmpush

[Ola Lundqvist]

Hi

It is maintained but I do not think it is used by almost anyone. So please
go ahead.

// Ola

On Thu, 24 Aug 2023 at 23:27, Bastian Germann  wrote:

> Source: icmpush
> Severity: important
>
> icmpush does not seem to be maintained anymore. I intend to salvage it
> with the plan to orphan it in three weeks. Please notify me if you object.
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

 -f /tmp/cron-apt.rAN9JY/runlog ']'
> + '[' -n /tmp/cron-apt.rAN9JY/actionlog ']'
> + '[' -f /tmp/cron-apt.rAN9JY/actionlog ']'
> + tomsg /tmp/cron-apt.rAN9JY/actionlog /var/log/cron-apt/log ''
> + TCAT=/tmp/cron-apt.rAN9JY/actionlog
> + TFILE=/var/log/cron-apt/log
> + TSTD=
> + '[' -n /tmp/cron-apt.rAN9JY/actionlog ']'
> + '[' -r /tmp/cron-apt.rAN9JY/actionlog ']'
> + '[' -n '' ']'
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + cat /tmp/cron-apt.rAN9JY/actionlog
> + rm -f /tmp/cron-apt.rAN9JY/actionlog
> + tomsg /tmp/cron-apt.rAN9JY/temp /var/log/cron-apt/log ''
> + TCAT=/tmp/cron-apt.rAN9JY/temp
> + TFILE=/var/log/cron-apt/log
> + TSTD=
> + '[' -n /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -r /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -n '' ']'
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + cat /tmp/cron-apt.rAN9JY/temp
> + grep -qvE '^[[:space:]]*$|CRON-APT' /tmp/cron-apt.rAN9JY/temp
> + '[' always = output ']'
> + '[' upgrade = output ']'
> + '[' verbose = upgrade ']'
> ++ echo 'autoclean -y'
> ++ md5sum
> ++ sed -e 's/[[:space:]].*//;'
> + TLINE=58797c9195c34287e12120e4b46fb611
> + '[' -n '' ']'
> + echo 'CRON-APT DIFF'
> + '[' '!' -r
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-58797c9195c34287e12120e4b46fb611
> ']'
> + diff -u
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-58797c9195c34287e12120e4b46fb611
> /tmp/cron-apt.rAN9JY/temp
> + rm -f /tmp/cron-apt.rAN9JY/difftemp
> + read LINE
> + echo 'CRON-APT LINE: /usr/bin/apt-get -o quiet=1 dist-upgrade -d -y -o
> APT::Get::Show-Upgraded=true'
> ++ umask
> + UMASK_SAVE=0077
> + umask 022
> + /usr/bin/apt-get -o quiet=1 dist-upgrade -d -y -o
> APT::Get::Show-Upgraded=true
> + RET=0
> + umask 0077
> + '[' 0 -ne 0 ']'
> + grep -q 'The following packages will be upgraded'
> /tmp/cron-apt.rAN9JY/temp
> + '[' always = always ']'
> + createsysloginfo 3-download
> + '[' -n always ']'
> + '[' -f /etc/cron-apt/syslogonmsgs/always ']'
> + createdivinfo syslog /tmp/cron-apt.rAN9JY/temp
> /etc/cron-apt/syslogmsg.d/3-download /tmp/cron-apt.rAN9JY/runsyslog
> /tmp/cron-apt.rAN9JY/actionsyslog
> + FILE=syslog
> + CAT=/tmp/cron-apt.rAN9JY/temp
> + OPTCAT=/etc/cron-apt/syslogmsg.d/3-download
> + OPTRUNCAT=/tmp/cron-apt.rAN9JY/runsyslog
> + OPTACTIONCAT=/tmp/cron-apt.rAN9JY/actionsyslog
> + TMPSTDOUT=
> + '[' syslog '!=' syslog ']'
> + '[' -n /etc/cron-apt/syslogmsg.d/3-download ']'
> + '[' -f /etc/cron-apt/syslogmsg.d/3-download ']'
> + '[' -n /tmp/cron-apt.rAN9JY/runsyslog ']'
> + '[' -f /tmp/cron-apt.rAN9JY/runsyslog ']'
> + '[' -n /tmp/cron-apt.rAN9JY/actionsyslog ']'
> + '[' -f /tmp/cron-apt.rAN9JY/actionsyslog ']'
> + tomsg /tmp/cron-apt.rAN9JY/temp syslog ''
> + TCAT=/tmp/cron-apt.rAN9JY/temp
> + TFILE=syslog
> + TSTD=
> + '[' -n /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -r /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -n '' ']'
> + '[' syslog '!=' syslog ']'
> + logger -p user.notice -t cron-apt -f /tmp/cron-apt.rAN9JY/temp
> + '[' upgrade = always ']'
> + '[' verbose = verbose ']'
> + createloginfo 3-download
> + createdivinfo /var/log/cron-apt/log /tmp/cron-apt.rAN9JY/temp
> /etc/cron-apt/logmsg.d/3-download /tmp/cron-apt.rAN9JY/runlog
> /tmp/cron-apt.rAN9JY/actionlog ''
> + FILE=/var/log/cron-apt/log
> + CAT=/tmp/cron-apt.rAN9JY/temp
> + OPTCAT=/etc/cron-apt/logmsg.d/3-download
> + OPTRUNCAT=/tmp/cron-apt.rAN9JY/runlog
> + OPTACTIONCAT=/tmp/cron-apt.rAN9JY/actionlog
> + TMPSTDOUT=
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + touch /var/log/cron-apt/log
> + '[' -n /etc/cron-apt/logmsg.d/3-download ']'
> + '[' -f /etc/cron-apt/logmsg.d/3-download ']'
> + '[' -n /tmp/cron-apt.rAN9JY/runlog ']'
> + '[' -f /tmp/cron-apt.rAN9JY/runlog ']'
> + '[' -n /tmp/cron-apt.rAN9JY/actionlog ']'
> + '[' -f /tmp/cron-apt.rAN9JY/actionlog ']'
> + tomsg /tmp/cron-apt.rAN9JY/temp /var/log/cron-apt/log ''
> + TCAT=/tmp/cron-apt.rAN9JY/temp
> + TFILE=/var/log/cron-apt/log
> + TSTD=
> + '[' -n /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -r /tmp/cron-apt.rAN9JY/temp ']'
> + '[' -n '' ']'
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + cat /tmp/cron-apt.rAN9JY/temp
> + grep -qvE '^[[:space:]]*$|CRON-APT' /tmp/cron-apt.rAN9JY/temp
> + '[' always = output ']'
> + '[' upgrade = output ']'
> + '[' verbose = upgrade ']'
> ++ echo 'dist-upgrade -d -y -o APT::Get::Show-Upgraded=true'
> ++ md5sum
> ++ sed -e 's/[[:space:]].*//;'
> + TLINE=e647be386a7d1853e0e4b05248391d8e
> + '[' -n '' ']'
> + echo 'CRON-APT DIFF'
> + '[' '!' -r
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-e647be386a7d1853e0e4b05248391d8e
> ']'
> + diff -u
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Really strange!

Not sure what could be wrong here.

// Ola

On Fri, 27 Jan 2023 at 13:17, Richard Rosner 
wrote:

> Oddly enough, that doesn't work. I already did set the MAILTO directive so
> I should get the mail. But even after changing it to
>
> */5 * * * * root bash -x test -x /usr/sbin/cron-apt && bash -x
> /usr/sbin/cron-apt > /root/cron-apt.log 2>&1
>
> nothing is being written to the mentioned file. File permissions are 644,
> owned by root. journalctl does list the execution of the cron job, but
> nothing else, no errors.
>
> Richard
>
> Am Freitag, 27. Januar 2023 07:45 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Hi Richard
>
> It is a different email I'm referring to. When a script, run by
> cron, prints something on standard output that will be sent to the root
> user as an email. At least in standard configuration.
> You should therefore have received two emails. One from cron-apt itself.
> We know that will not arrive due to this problem. The other email should
> also be sent by cron itself, but that do not seem to arrive either. Strange.
>
> Can you change the line in cron so it outputs stdout and stderr to a file
> instead?
>
> // Ola
>
> On Fri, 27 Jan 2023 at 07:20, Richard Rosner 
> wrote:
>
>> They are supposed to be sent to the mail address defined in the cron-apt
>> config. It didn't arrive there. Or did the change of executing cron-apt
>> change anything about that?
>>
>> Richard
>>
>> On January 27, 2023 12:18:13 AM GMT+01:00, Ola Lundqvist 
>> wrote:
>>
>>> Hi Richard
>>>
>>> I thought you would get the cron output from bash -x in an email so I
>>> could see more what happens. It should be sent to the root user. Or have
>>> you redirected those emails so you do not get them?
>>>
>>> Sorry for not being clear on that.
>>>
>>> Best regards
>>>
>>> // Ola
>>>
>>> On Thu, 26 Jan 2023 at 15:15, Richard Rosner <
>>> rros...@fsmuw.rwth-aachen.de> wrote:
>>>
>>>> With RUNSLEEP disabled, I get
>>>> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x
>>>> test -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
>>>> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
>>>> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>>>>
>>>> No kernel errors. I didn't receive a mail about updates, though, but I
>>>> also don't know the time the server I get the updates from updates its
>>>> repository the last time.
>>>>
>>>> With RUNSLEEP set to 3600 I get the same (running with no delay). And
>>>> even though I did run apt update between these two runs (28 updates
>>>> available) I didn't receive the mail.
>>>> ​​
>>>> Richard
>>>>
>>>>
>>>> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
>>>> o...@inguza.com>:
>>>>
>>>>
>>>> Argh!
>>>>
>>>> Can you run it with bash -x from cron? Hopefully it tells where it
>>>> breaks
>>>>
>>>> Den tis 24 jan. 2023 17:06Richard Rosner 
>>>> skrev:
>>>>
>>>>> No, and it did send a mail.
>>>>>
>>>>> --
>>>>> Richard Rosner
>>>>>
>>>>> Studierendenschaft der RWTH Aachen University
>>>>> Fachschaft Materialwissenschaft und Werkstofftechnik
>>>>> Intzestraße 1
>>>>> 52072 Aachen
>>>>> Tel.: +49 241 80-95781
>>>>> rros...@fsmuw.rwth-aachen.de
>>>>> www.fsmuw.rwth-aachen.de
>>>>>
>>>>> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
>>>>> o...@inguza.com>:
>>>>>
>>>>>
>>>>> Did you get that kernel error?
>>>>>
>>>>> Den tis 24 jan. 2023 14:12Richard Rosner 
>>>>> skrev:
>>>>>
>>>>>> This is the output (not sure if attachments are possible here, so I
>>>>>> put it into the body):
>>>>>>
>>>>>> + export
>>>>>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>>>>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>>>>> + UMASK_TIGHT=077
>>>>>> + UMASK_APT=022
>>>>>> + umask 077
>

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Richard

It is a different email I'm referring to. When a script, run by
cron, prints something on standard output that will be sent to the root
user as an email. At least in standard configuration.
You should therefore have received two emails. One from cron-apt itself. We
know that will not arrive due to this problem. The other email should also
be sent by cron itself, but that do not seem to arrive either. Strange.

Can you change the line in cron so it outputs stdout and stderr to a file
instead?

// Ola

On Fri, 27 Jan 2023 at 07:20, Richard Rosner 
wrote:

> They are supposed to be sent to the mail address defined in the cron-apt
> config. It didn't arrive there. Or did the change of executing cron-apt
> change anything about that?
>
> Richard
>
>
> On January 27, 2023 12:18:13 AM GMT+01:00, Ola Lundqvist 
> wrote:
>
>> Hi Richard
>>
>> I thought you would get the cron output from bash -x in an email so I
>> could see more what happens. It should be sent to the root user. Or have
>> you redirected those emails so you do not get them?
>>
>> Sorry for not being clear on that.
>>
>> Best regards
>>
>> // Ola
>>
>> On Thu, 26 Jan 2023 at 15:15, Richard Rosner <
>> rros...@fsmuw.rwth-aachen.de> wrote:
>>
>>> With RUNSLEEP disabled, I get
>>> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x
>>> test -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
>>> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
>>> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>>>
>>> No kernel errors. I didn't receive a mail about updates, though, but I
>>> also don't know the time the server I get the updates from updates its
>>> repository the last time.
>>>
>>> With RUNSLEEP set to 3600 I get the same (running with no delay). And
>>> even though I did run apt update between these two runs (28 updates
>>> available) I didn't receive the mail.
>>> ​​
>>> Richard
>>>
>>>
>>> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
>>> o...@inguza.com>:
>>>
>>>
>>> Argh!
>>>
>>> Can you run it with bash -x from cron? Hopefully it tells where it
>>> breaks
>>>
>>> Den tis 24 jan. 2023 17:06Richard Rosner 
>>> skrev:
>>>
>>>> No, and it did send a mail.
>>>>
>>>> --
>>>> Richard Rosner
>>>>
>>>> Studierendenschaft der RWTH Aachen University
>>>> Fachschaft Materialwissenschaft und Werkstofftechnik
>>>> Intzestraße 1
>>>> 52072 Aachen
>>>> Tel.: +49 241 80-95781
>>>> rros...@fsmuw.rwth-aachen.de
>>>> www.fsmuw.rwth-aachen.de
>>>>
>>>> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
>>>> o...@inguza.com>:
>>>>
>>>>
>>>> Did you get that kernel error?
>>>>
>>>> Den tis 24 jan. 2023 14:12Richard Rosner 
>>>> skrev:
>>>>
>>>>> This is the output (not sure if attachments are possible here, so I
>>>>> put it into the body):
>>>>>
>>>>> + export
>>>>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>>>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>>>> + UMASK_TIGHT=077
>>>>> + UMASK_APT=022
>>>>> + umask 077
>>>>> + STDOUT=
>>>>> + ALLCONFIGS=
>>>>> + '[' -n '' ']'
>>>>> + '[' -z '' ']'
>>>>> + CONFIG=/etc/cron-apt/config
>>>>> + ALLCONFIGS=/etc/cron-apt/config
>>>>> + LIBDIR=/var/lib/cron-apt
>>>>> + SHAREDIR=/usr/share/cron-apt
>>>>> ++ echo /etc/cron-apt/config
>>>>> ++ sed 's|/|_-_|g'
>>>>> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
>>>>> ++ mktemp -d -t cron-apt.XX
>>>>> + TMPDIR=/tmp/cron-apt.X5DFeL
>>>>> + '[' 0 -ne 0 ']'
>>>>> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
>>>>> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
>>>>> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
>>>>> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
>>>>> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
>>>>> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
>>>>> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
>>>>> + ACTIONLOG=/tmp/cron-apt

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Richard

I thought you would get the cron output from bash -x in an email so I could
see more what happens. It should be sent to the root user. Or have
you redirected those emails so you do not get them?

Sorry for not being clear on that.

Best regards

// Ola

On Thu, 26 Jan 2023 at 15:15, Richard Rosner 
wrote:

> With RUNSLEEP disabled, I get
> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x test
> -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>
> No kernel errors. I didn't receive a mail about updates, though, but I
> also don't know the time the server I get the updates from updates its
> repository the last time.
>
> With RUNSLEEP set to 3600 I get the same (running with no delay). And even
> though I did run apt update between these two runs (28 updates available) I
> didn't receive the mail.
> ​​
> Richard
>
>
> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Argh!
>
> Can you run it with bash -x from cron? Hopefully it tells where it breaks
>
> Den tis 24 jan. 2023 17:06Richard Rosner 
> skrev:
>
>> No, and it did send a mail.
>>
>> --
>> Richard Rosner
>>
>> Studierendenschaft der RWTH Aachen University
>> Fachschaft Materialwissenschaft und Werkstofftechnik
>> Intzestraße 1
>> 52072 Aachen
>> Tel.: +49 241 80-95781
>> rros...@fsmuw.rwth-aachen.de
>> www.fsmuw.rwth-aachen.de
>>
>> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
>> o...@inguza.com>:
>>
>>
>> Did you get that kernel error?
>>
>> Den tis 24 jan. 2023 14:12Richard Rosner 
>> skrev:
>>
>>> This is the output (not sure if attachments are possible here, so I put
>>> it into the body):
>>>
>>> + export
>>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>> + UMASK_TIGHT=077
>>> + UMASK_APT=022
>>> + umask 077
>>> + STDOUT=
>>> + ALLCONFIGS=
>>> + '[' -n '' ']'
>>> + '[' -z '' ']'
>>> + CONFIG=/etc/cron-apt/config
>>> + ALLCONFIGS=/etc/cron-apt/config
>>> + LIBDIR=/var/lib/cron-apt
>>> + SHAREDIR=/usr/share/cron-apt
>>> ++ echo /etc/cron-apt/config
>>> ++ sed 's|/|_-_|g'
>>> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
>>> ++ mktemp -d -t cron-apt.XX
>>> + TMPDIR=/tmp/cron-apt.X5DFeL
>>> + '[' 0 -ne 0 ']'
>>> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
>>> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
>>> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
>>> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
>>> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
>>> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
>>> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
>>> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
>>> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
>>> + TEMP=/tmp/cron-apt.X5DFeL/temp
>>> + MAIL=/tmp/cron-apt.X5DFeL/mail
>>> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
>>> + STATUS=/tmp/cron-apt.X5DFeL/status
>>> + LOCKFILE=/var/lib/cron-apt/lockfile
>>> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
>>> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
>>> + ACTIONDIR=/etc/cron-apt/action.d
>>> + ACTIONCONFDIR=/etc/cron-apt/config.d
>>> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
>>> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
>>> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
>>> + REFRAINFILE=/etc/cron-apt/refrain
>>> + NOLOCKWARN=
>>> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
>>> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
>>> + LOGMSGDIR=/etc/cron-apt/logmsg.d
>>> + LOGDIR=/var/log/cron-apt
>>> + LOG=/var/log/cron-apt/log
>>> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
>>> + DIFFONCHANGES=prepend
>>> + SUBJECTPREFIX=CRON-APT
>>> + MAILTO=root
>>> + MAILWIDTH=900
>>> + SYSLOGON=upgrade
>>> + MAILON=error
>>> + EXITON=error
>>> + DEBUG=verbose
>>> + OPTIONS='-o quiet=1'
>>> + DONTRUN=
>>> + RUNSLEEP=3600
>>> + MINTMPDIRSIZE=10
>>> + APTCOMMAND=/usr/bin/apt-get
>>> + HOSTNAME=
>>> + DIFFIGNORE=
>>> + DIFFONCHANGES=prepend
>>> + export DEBIAN_FRONTEND=noninteractive
>>> + DEBIAN_FRO

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Argh!

Can you run it with bash -x from cron? Hopefully it tells where it breaks

Den tis 24 jan. 2023 17:06Richard Rosner 
skrev:

> No, and it did send a mail.
>
> --
> Richard Rosner
>
> Studierendenschaft der RWTH Aachen University
> Fachschaft Materialwissenschaft und Werkstofftechnik
> Intzestraße 1
> 52072 Aachen
> Tel.: +49 241 80-95781
> rros...@fsmuw.rwth-aachen.de
> www.fsmuw.rwth-aachen.de
>
> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Did you get that kernel error?
>
> Den tis 24 jan. 2023 14:12Richard Rosner 
> skrev:
>
>> This is the output (not sure if attachments are possible here, so I put
>> it into the body):
>>
>> + export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>> + UMASK_TIGHT=077
>> + UMASK_APT=022
>> + umask 077
>> + STDOUT=
>> + ALLCONFIGS=
>> + '[' -n '' ']'
>> + '[' -z '' ']'
>> + CONFIG=/etc/cron-apt/config
>> + ALLCONFIGS=/etc/cron-apt/config
>> + LIBDIR=/var/lib/cron-apt
>> + SHAREDIR=/usr/share/cron-apt
>> ++ echo /etc/cron-apt/config
>> ++ sed 's|/|_-_|g'
>> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
>> ++ mktemp -d -t cron-apt.XX
>> + TMPDIR=/tmp/cron-apt.X5DFeL
>> + '[' 0 -ne 0 ']'
>> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
>> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
>> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
>> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
>> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
>> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
>> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
>> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
>> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
>> + TEMP=/tmp/cron-apt.X5DFeL/temp
>> + MAIL=/tmp/cron-apt.X5DFeL/mail
>> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
>> + STATUS=/tmp/cron-apt.X5DFeL/status
>> + LOCKFILE=/var/lib/cron-apt/lockfile
>> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
>> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
>> + ACTIONDIR=/etc/cron-apt/action.d
>> + ACTIONCONFDIR=/etc/cron-apt/config.d
>> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
>> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
>> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
>> + REFRAINFILE=/etc/cron-apt/refrain
>> + NOLOCKWARN=
>> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
>> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
>> + LOGMSGDIR=/etc/cron-apt/logmsg.d
>> + LOGDIR=/var/log/cron-apt
>> + LOG=/var/log/cron-apt/log
>> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
>> + DIFFONCHANGES=prepend
>> + SUBJECTPREFIX=CRON-APT
>> + MAILTO=root
>> + MAILWIDTH=900
>> + SYSLOGON=upgrade
>> + MAILON=error
>> + EXITON=error
>> + DEBUG=verbose
>> + OPTIONS='-o quiet=1'
>> + DONTRUN=
>> + RUNSLEEP=3600
>> + MINTMPDIRSIZE=10
>> + APTCOMMAND=/usr/bin/apt-get
>> + HOSTNAME=
>> + DIFFIGNORE=
>> + DIFFONCHANGES=prepend
>> + export DEBIAN_FRONTEND=noninteractive
>> + DEBIAN_FRONTEND=noninteractive
>> + export LANG=C
>> + LANG=C
>> + export LC_ALL=C
>> + LC_ALL=C
>> + for cfg in $ALLCONFIGS
>> + '[' -f /etc/cron-apt/config ']'
>> + . /etc/cron-apt/config
>> ++ APTCOMMAND=/usr/bin/apt-get
>> ++ MAILTO=administra...@fsmuw.rwth-aachen.de
>> ++ MAILON=upgrade
>> ++ SYSLOGON=always
>> + test '' = yes
>> + . /usr/share/cron-apt/functions
>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges ']'
>> + '[' -e /etc/cron-apt/refrain ']'
>> + checktmpsize
>> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
>> + SSIZE=4096
>> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
>> + FSCOUNT=1021394
>> + '[' 1021394 -lt 33554432 ']'
>> + '[' 4085576 -lt 10 ']'
>> ++ date
>> + echo 'CRON-APT RUN [/etc/cron-apt/config]: Tue Jan 24 13:15:27 CET 2023'
>> + '[' -n 3600 ']'
>> + '[' 3600 -gt 0 ']'
>> + '[' -z 10031 ']'
>> + TIME=842
>> + sleep 842
>> ++ date
>> + echo 'CRON-APT SLEEP: 842, Tue Jan 24 13:29:29 CET 2023'
>> + '[' -e /etc/cron-apt/refrain ']'
>> + checktmpsize
>> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
>> + SSIZE=4096
>> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
>> + FSCOUNT=1021393
>> + '[' 1021393 -lt 33554432 ']'
>> + '[' 4085572 -lt 10 ']'
>> + '[' -x /usr/bin/dotlockfile ']'

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

-apt.X5DFeL/actionsyslog ']'
> + tomsg /tmp/cron-apt.X5DFeL/temp syslog ''
> + TCAT=/tmp/cron-apt.X5DFeL/temp
> + TFILE=syslog
> + TSTD=
> + '[' -n /tmp/cron-apt.X5DFeL/temp ']'
> + '[' -r /tmp/cron-apt.X5DFeL/temp ']'
> + '[' -n '' ']'
> + '[' syslog '!=' syslog ']'
> + logger -p user.notice -t cron-apt -f /tmp/cron-apt.X5DFeL/temp
> + '[' upgrade = always ']'
> + '[' verbose = verbose ']'
> + createloginfo 3-download
> + createdivinfo /var/log/cron-apt/log /tmp/cron-apt.X5DFeL/temp
> /etc/cron-apt/logmsg.d/3-download /tmp/cron-apt.X5DFeL/runlog
> /tmp/cron-apt.X5DFeL/actionlog ''
> + FILE=/var/log/cron-apt/log
> + CAT=/tmp/cron-apt.X5DFeL/temp
> + OPTCAT=/etc/cron-apt/logmsg.d/3-download
> + OPTRUNCAT=/tmp/cron-apt.X5DFeL/runlog
> + OPTACTIONCAT=/tmp/cron-apt.X5DFeL/actionlog
> + TMPSTDOUT=
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + touch /var/log/cron-apt/log
> + '[' -n /etc/cron-apt/logmsg.d/3-download ']'
> + '[' -f /etc/cron-apt/logmsg.d/3-download ']'
> + '[' -n /tmp/cron-apt.X5DFeL/runlog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/runlog ']'
> + '[' -n /tmp/cron-apt.X5DFeL/actionlog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/actionlog ']'
> + tomsg /tmp/cron-apt.X5DFeL/temp /var/log/cron-apt/log ''
> + TCAT=/tmp/cron-apt.X5DFeL/temp
> + TFILE=/var/log/cron-apt/log
> + TSTD=
> + '[' -n /tmp/cron-apt.X5DFeL/temp ']'
> + '[' -r /tmp/cron-apt.X5DFeL/temp ']'
> + '[' -n '' ']'
> + '[' /var/log/cron-apt/log '!=' syslog ']'
> + cat /tmp/cron-apt.X5DFeL/temp
> + grep -qvE '^[[:space:]]*$|CRON-APT' /tmp/cron-apt.X5DFeL/temp
> + '[' always = output ']'
> + '[' upgrade = output ']'
> + '[' verbose = upgrade ']'
> ++ echo 'dist-upgrade -d -y -o APT::Get::Show-Upgraded=true'
> ++ md5sum
> ++ sed -e 's/[[:space:]].*//;'
> + TLINE=e647be386a7d1853e0e4b05248391d8e
> + '[' -n '' ']'
> + echo 'CRON-APT DIFF'
> + '[' '!' -r
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-e647be386a7d1853e0e4b05248391d8e
> ']'
> + diff -u
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-e647be386a7d1853e0e4b05248391d8e
> /tmp/cron-apt.X5DFeL/temp
> + cp /tmp/cron-apt.X5DFeL/temp
> /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges/3-download-e647be386a7d1853e0e4b05248391d8e
> + '[' -n /tmp/cron-apt.X5DFeL/difftemp ']'
> + '[' -r /tmp/cron-apt.X5DFeL/difftemp ']'
> + '[' prepend = only ']'
> + '[' prepend = append ']'
> + '[' prepend = prepend ']'
> + echo '- DIFF END HERE -'
> + cat /tmp/cron-apt.X5DFeL/temp
> + mv /tmp/cron-apt.X5DFeL/difftemp /tmp/cron-apt.X5DFeL/temp
> + '[' upgrade = changes ']'
> + '[' always = changes ']'
> + '[' verbose = changes ']'
> + rm -f /tmp/cron-apt.X5DFeL/difftemp
> + read LINE
> + '[' -e /tmp/cron-apt.X5DFeL/status ']'
> + herevariables_restore
> + general_varmove STORED ''
> + PREFIX=STORED
> + STORE=
> + SIFS='
> '
> ++ set
> ++ grep '^[a-zA-Z][a-zA-Z0-9_]*_STORED='
> ++ sed -e 's|=.*||;'
> + LIST=
> + onexit
> + '[' -f /tmp/cron-apt.X5DFeL/initlog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/temp ']'
> + rm -f /tmp/cron-apt.X5DFeL/temp
> + '[' -f /tmp/cron-apt.X5DFeL/actionlog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/actionsyslog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/actionmail ']'
> + '[' -f /tmp/cron-apt.X5DFeL/actionerror ']'
> + rm -f /tmp/cron-apt.X5DFeL/actionerror
> + '[' -f /tmp/cron-apt.X5DFeL/runlog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/runsyslog ']'
> + '[' -f /tmp/cron-apt.X5DFeL/runerror ']'
> + rm -f /tmp/cron-apt.X5DFeL/runerror
> + '[' -f /tmp/cron-apt.X5DFeL/runmail ']'
> + '[' -f /tmp/cron-apt.X5DFeL/mail ']'
> + '[' upgrade '!=' never ']'
> + '[' -n upgrade ']'
> + HDR='To: administra...@fsmuw.rwth-aachen.de'
> + '[' -z '' ']'
> ++ uname -n
> + HOSTNAME=ts
> + '[' -f /tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error ']'
> ++ printf 'To: administra...@fsmuw.rwth-aachen.de\nSubject: CRON-APT
> completed on ts [/etc/cron-apt/config]'
> + HDR='To: administra...@fsmuw.rwth-aachen.de
> Subject: CRON-APT completed on ts [/etc/cron-apt/config]'
> + i=1
> + eval 'VAL=${XHEADER1}'
> ++ VAL=
> + '[' '!' -z '' ']'
> + umask 022
> + printf 'To: administra...@fsmuw.rwth-aachen.de
> Subject: CRON-APT completed on ts [/etc/cron-apt/config]\n\n'
> + fold --spaces --width=900 /tmp/cron-apt.X5DFeL/mail
> + command -v sendmail
> + sendmail -t -oi
> + rm -f /tmp/cron-apt.X5DFeL/mail
> + '[' -f /tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error ']'
> + '[' -d /tmp/cron-apt.X5DFeL ']'
> + rmdir /tmp/cron-apt.X5DFeL
> + '[' -x /usr/bin/dotlockfile ']'
> + dotlockfile -u /var/lib/cron-apt/lockfile
>
>
>
> Am Dienstag, 24. Januar 2023 09:16 CET, schrieb Ola Lundqvist <
> o...@inguza.com&g

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Richard

Strange!

Can you try to copy cron-apt and comment this:

if [ -t 0 ]; then
RUNIMMEDIATELY="yes"
fi

And then run manually.

bash -x your-cron-apt-copy

It would help to understand what happens.

// Ola

On Mon, 23 Jan 2023 at 23:30, Richard Rosner 
wrote:

> Hi,
> sleep 456 and sleep 1200 work without any problems. Also, I don't have any
> special kernel. Currently, Output of uname -a is "Linux ts 6.1.0-1-amd64 #1
> SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64 GNU/Linux". I don't
> even have any other repository active other than the typical Debian ones
> (testing, testing-updates, testing-backports, testing-security).
>
> Also, I'm noticing cron-apt becoming less reliable in the last weeks (I
> actually wanted to report this before Christmas, but something must have
> went wrong so I only got the email, but it probably was never sent to the
> bugreport mailing list). It used to reliably send mails every day at which
> it finds any updates. But in the last weeks, it mostly doesn't do that
> anymore. The log in journalctl/syslog always shows the same text (only
> difference in the checksum and so on). RUNSLEEP has been commented out for
> weeks now.
>
> Richard
>
> Am Montag, 23. Januar 2023 22:10 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Hi
>
> When you run cron-apt from a terminal RUNSLEEP is not used. This is why it
> works when running manually.
>
> Please try running the following in a command
>
> sleep 456
>
> or any large number for sleep.
>
> Do you have some special kernel? The kernel should not give that problem.
>
> cron-apt do not do anything magic. It just executes sleep
>
> It could also be that it is not the sleep command itself. It could be the
> random number generation done a few lines earlier in that script.
>
> // Ola
>
> On Wed, 18 Jan 2023 at 15:12, Richard Rosner 
> wrote:
>
>> Package: cron-apt
>> Version: 0.13.0.1
>> Severity: important
>> X-Debbugs-Cc: sub...@bugs.debian.org
>>
>> Dear Maintainer,
>> when running cron-apt as shipped it works normal, running at 4 am and
>> sending an email when anything can be updated. But when adding the
>> recommended RUNSLEEP variable to the config, the only thing that happens is
>> throwing a kernel error at 4 am:
>>
>>  2022-12-19T04:00:01.425628+01:00 ts CRON[75874]: (root) CMD (test -x
>> /usr/sbin/cron-apt && /usr/sbin/cron-apt)
>>  2022-12-19T04:00:01.468596+01:00 ts kernel: [276052.628108] traps:
>> cksum[75885] trap invalid opcode ip:562d9fe03cf5 sp:7ffd9b53fe20 error:0 in
>> cksum[562d9fded000+17000]
>>  2022-12-19T04:00:02.525060+01:00 ts sSMTP[75887]: Sent mail for
>> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=691
>>
>> Even though it says a mail is sent, it's not received. Since cron-apt
>> clearly doesn't run at all, that might be the reason. Running cron-apt
>> manually with RUNSLEEP set with "cron-apt -s" works without problems.
>>
>>
>> -- System Information:
>> Debian Release: bookworm/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
>> Kernel taint flags: TAINT_WARN
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US:en
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages cron-apt depends on:
>> ii  apt  2.5.4
>>
>> Versions of packages cron-apt recommends:
>> ii  cron [cron-daemon]3.0pl1-156
>> ii  liblockfile1  1.17-1+b1
>> ii  ssmtp [mail-transport-agent]  2.64-11
>>
>> cron-apt suggests no packages.
>>
>> -- Configuration Files:
>> /etc/cron-apt/config changed:
>> APTCOMMAND=/usr/bin/apt-get
>> MAILTO="administra...@fsmuw.rwth-aachen.de"
>> MAILON=upgrade
>> SYSLOGON=always
>> #RUNSLEEP=3600
>>
>> -- no debconf information
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi

When you run cron-apt from a terminal RUNSLEEP is not used. This is why it
works when running manually.

Please try running the following in a command

sleep 456

or any large number for sleep.

Do you have some special kernel? The kernel should not give that problem.

cron-apt do not do anything magic. It just executes sleep

It could also be that it is not the sleep command itself. It could be the
random number generation done a few lines earlier in that script.

// Ola

On Wed, 18 Jan 2023 at 15:12, Richard Rosner 
wrote:

> Package: cron-apt
> Version: 0.13.0.1
> Severity: important
> X-Debbugs-Cc: sub...@bugs.debian.org
>
> Dear Maintainer,
> when running cron-apt as shipped it works normal, running at 4 am and
> sending an email when anything can be updated. But when adding the
> recommended RUNSLEEP variable to the config, the only thing that happens is
> throwing a kernel error at 4 am:
>
>  2022-12-19T04:00:01.425628+01:00 ts CRON[75874]: (root) CMD (test -x
> /usr/sbin/cron-apt && /usr/sbin/cron-apt)
>  2022-12-19T04:00:01.468596+01:00 ts kernel: [276052.628108] traps:
> cksum[75885] trap invalid opcode ip:562d9fe03cf5 sp:7ffd9b53fe20 error:0 in
> cksum[562d9fded000+17000]
>  2022-12-19T04:00:02.525060+01:00 ts sSMTP[75887]: Sent mail for
> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=691
>
> Even though it says a mail is sent, it's not received. Since cron-apt
> clearly doesn't run at all, that might be the reason. Running cron-apt
> manually with RUNSLEEP set with "cron-apt -s" works without problems.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages cron-apt depends on:
> ii  apt  2.5.4
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon]3.0pl1-156
> ii  liblockfile1  1.17-1+b1
> ii  ssmtp [mail-transport-agent]  2.64-11
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/config changed:
> APTCOMMAND=/usr/bin/apt-get
> MAILTO="administra...@fsmuw.rwth-aachen.de"
> MAILON=upgrade
> SYSLOGON=always
> #RUNSLEEP=3600
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1012654: systemd timers?

[Ola Lundqvist]

Hi Marc

Sorry again for the late reply. Yes such a patch can be considered.
It must be clear on how the cron-fallback would work though.

// Ola

On Sat, 11 Jun 2022 at 08:51, Marc Haber 
wrote:

> Package: cron-apt
> Version: 0.13.0.1
> Severity: wishlist
>
> Hi,
>
> would you be open to a patch that adds the possibility to use systemd
> timers? Quite some packages in Debian have adopted a way to run through
> systemd timers and systemd units on systems that have systemd, falling
> back to the "old" cron job configuration if there is no systemd. for
> example, apt is doing it this way.
>
> I am attaching the four preliminary systemd units I am using on a test
> system without problems. You might notice that they're using systemd's
> RandomizedDelaySec feature and call cron-apt -i instead. I find that
> more elegant.
>
> The systemd units would also make it easier to run with reduced
> privileges, having parts of the file system read-only and have other
> nice security features. My preliminary units don't do that yet, but I
> would be willing to do that if there is a chance to get the work into
> the package.
>
> Let me know what you think.
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'unstable'), (500,
> 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.3-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cron-apt depends on:
> ii  apt  2.5.0
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon] 3.0pl1-142
> ii  exim4-daemon-light [mail-transport-agent]  4.95-6
> ii  liblockfile1   1.17-1+b1
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
> /etc/logrotate.d/cron-apt changed [not included]
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1012692: missing dotlockfile warning not included in e-mail

[Ola Lundqvist]

Hi Marc

Sorry for the late reply. Interesting report. I wonder what the problem
is...

// Ola

On Sat, 11 Jun 2022 at 23:03, Marc Haber 
wrote:

> Package: cron-apt
> Version: 0.13.0+nmu1
> Severity: normal
>
> Hi,
>
> cron-apt correctly detects if the dotlockfile package is missing and
> generates an error message. This causes the e-mail message to be
> subjected as "CRON-APT error", but the actual error message does not
> seem to end up in the message.
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: 11.3
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-14-amd64 (SMP w/2 CPU threads)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cron-apt depends on:
> ii  apt  2.2.4
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon] 3.0pl1-137
> ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
> pn  liblockfile1   
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
> /etc/logrotate.d/cron-apt changed [not included]
>
> -- no debconf information
>
> -- debsums errors found:
> debsums: changed file /usr/share/cron-apt/functions (from cron-apt package)
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?

[Ola Lundqvist]

Hi Paul

The current possibilities in cron-apt are:

SYSLOGON="upgrade"

  When to log the cron-apt results to syslog.
  Value:
error   (syslog on error runs)
upgrade (when packages is upgraded)
changes (syslog when change in output from an action)
output  (syslog when output is generated)
always  (always syslog)
never   (never syslog)
(else never syslog)


MAILON="error"

  When to send email about the cron-apt results.
  Value:
error   (send mail on error runs)
upgrade (when packages are upgraded)
changes (mail when change in output from an action)
output  (send mail when output is generated)
always  (always send mail)
never   (never send mail)
(else never send mail)

I guess "output" is what you are after.


// Ola

On Wed, 1 Dec 2021 at 01:54, Paul Wise  wrote:

> On Tue, 2021-11-30 at 23:05 +0100, Ola Lundqvist wrote:
>
> > Emails are sent by default only when apt fails.
> >
> > All output is logged to the cron-apt log file.
> >
> > Logs are sent to syslog on "upgrade".
> > By default upgrade is not enabled.
>
> Thanks for that info.
>
> If this feature gets implemented in logcheck, there could be cron-apt
> options to apply it to either syslog or mails for each of the types of
> output cron-apt sends. An option to send mail/syslog for success too
> would be good for users of this logcheck feature and possibly also
> users who do processing of the results either in a mail client plugin
> or in a syslog database and search system like Elasticsearch or Loki.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

[Ola Lundqvist]

Hi

Thank you.

I guess the main reason for the lack of documentation is that it is not
provided by upstream. This was the case also for tightvnc, vnc4 and vnc(3).
I wrote some documentation for those other packages but I guess it was
never done for tigervnc.

I do not think you made anything wrong.

Cheers

// Ola

On Wed, 1 Dec 2021 at 00:12, Celejar  wrote:

> Primarily the segfault, although the problem is compounded by the
> absence of documentation, which makes it difficult to know whether I'm
> doing something wrong with my invocation.
>
> On Tue, 30 Nov 2021 23:07:11 +0100
> Ola Lundqvist  wrote:
>
> > Hi
> >
> > Just a check question. Is your bug about the lack of useful documentation
> > or the fact that it segfaults?
> > It should not segfault...
> >
> > // Ola
> >
> > On Tue, 30 Nov 2021 at 15:03, Celejar  wrote:
> >
> > > Package: tigervnc-standalone-server
> > > Version: 1.11.0+dfsg-3
> > > Severity: important
> > > X-Debbugs-Cc: cele...@gmail.com
> > >
> > > This package contains no useful documentation or explanation of how to
> > > start the server in /usr/share/doc. As per 'man tigervncserver', I
> > > tried:
> > >
> > > *
> > >
> > > ~$ tigervncserver
> > >
> > > *
> > >
> > > And the server promptly segfaulted:
> > >
> > > *
> > >
> > > New Xtigervnc server '.:1 ()' on port 5901 for
> > > display :1.
> > > Use xtigervncviewer -SecurityTypes VncAuth -passwd
> > > /home//.vnc/passwd :1 to connect to the VNC server.
> > >
> > >
> > > === tail /home//.vnc/.:5901.log
> > > ===
> > > Segmentation fault
> > > X connection to :1 broken (explicit kill or server shutdown).
> > >  ComparingUpdateTracker: 0 pixels in / 0 pixels out
> > >  ComparingUpdateTracker: (1:-nan ratio)
> > > Killing Xtigervnc process ID 9433... success!
> > >
> > >
> ==
> > >
> > > Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly
> > > exited too early (< 3 seconds)!
> > >
> > > Maybe try something simple first, e.g.,
> > > tigervncserver -xstartup /usr/bin/xterm
> > > The Xtigervnc server cleanly exited!
> > > The X session cleanly exited!
> > >
> > > *
> > >
> > > As per the above output, I tried:
> > >
> > > *
> > >
> > > ~$ tigervncserver -xstartup /usr/bin/xterm
> > >
> > > *
> > >
> > > No segfault, but it still didn't work:
> > >
> > > *
> > >
> > > New Xtigervnc server '.:1 ()' on port 5901 for
> > > display :1.
> > > Use xtigervncviewer -SecurityTypes VncAuth -passwd
> > > /home//.vnc/passwd :1 to connect to the VNC server.
> > >
> > >
> > > === tail /home//.vnc/.:5901.log
> > > ===
> > >
> > >
> ==
> > >
> > > Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too
> early
> > > (< 3 seconds)!
> > >
> > > Maybe try something simple first, e.g.,
> > > tigervncserver -xstartup /usr/bin/xterm
> > > The X session cleanly exited!
> > > Killing Xtigervnc process ID 9525... success!
> > >
> > > *
> > >
> > > -- System Information:
> > > Debian Release: bookworm/sid
> > >   APT prefers unstable
> > >   APT policy: (500, 'unstable')
> > > Architecture: amd64 (x86_64)
> > > Foreign Architectures: i386
> > >
> > > Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 tigervnc-standalone-server depends on:
> > > ii  libaudit1   1:3.0.6-1+b1
> > > ii  libbsd0 0.11.3-1
> > > ii  libc6   2.32-4
> > > ii  libfile-readbackwards-perl  1.06-1
> > > ii  libg

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

[Ola Lundqvist]

Hi

Just a check question. Is your bug about the lack of useful documentation
or the fact that it segfaults?
It should not segfault...

// Ola

On Tue, 30 Nov 2021 at 15:03, Celejar  wrote:

> Package: tigervnc-standalone-server
> Version: 1.11.0+dfsg-3
> Severity: important
> X-Debbugs-Cc: cele...@gmail.com
>
> This package contains no useful documentation or explanation of how to
> start the server in /usr/share/doc. As per 'man tigervncserver', I
> tried:
>
> *
>
> ~$ tigervncserver
>
> *
>
> And the server promptly segfaulted:
>
> *
>
> New Xtigervnc server '.:1 ()' on port 5901 for
> display :1.
> Use xtigervncviewer -SecurityTypes VncAuth -passwd
> /home//.vnc/passwd :1 to connect to the VNC server.
>
>
> === tail /home//.vnc/.:5901.log
> ===
> Segmentation fault
> X connection to :1 broken (explicit kill or server shutdown).
>  ComparingUpdateTracker: 0 pixels in / 0 pixels out
>  ComparingUpdateTracker: (1:-nan ratio)
> Killing Xtigervnc process ID 9433... success!
>
> ==
>
> Session startup via '/etc/X11/Xtigervnc-session' 'startxfce4' cleanly
> exited too early (< 3 seconds)!
>
> Maybe try something simple first, e.g.,
> tigervncserver -xstartup /usr/bin/xterm
> The Xtigervnc server cleanly exited!
> The X session cleanly exited!
>
> *
>
> As per the above output, I tried:
>
> *
>
> ~$ tigervncserver -xstartup /usr/bin/xterm
>
> *
>
> No segfault, but it still didn't work:
>
> *
>
> New Xtigervnc server '.:1 ()' on port 5901 for
> display :1.
> Use xtigervncviewer -SecurityTypes VncAuth -passwd
> /home//.vnc/passwd :1 to connect to the VNC server.
>
>
> === tail /home//.vnc/.:5901.log
> ===
>
> ==
>
> Session startup via '/usr/bin/xterm' 'startxfce4' cleanly exited too early
> (< 3 seconds)!
>
> Maybe try something simple first, e.g.,
> tigervncserver -xstartup /usr/bin/xterm
> The X session cleanly exited!
> Killing Xtigervnc process ID 9525... success!
>
> *
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 tigervnc-standalone-server depends on:
> ii  libaudit1   1:3.0.6-1+b1
> ii  libbsd0 0.11.3-1
> ii  libc6   2.32-4
> ii  libfile-readbackwards-perl  1.06-1
> ii  libgcrypt20 1.9.4-4
> ii  libgl1  1.3.4-2+b1
> ii  libgnutls30 3.7.2-2
> ii  libjpeg62-turbo 1:2.1.2-1
> ii  libpam0g1.4.0-10
> ii  libpixman-1-0   0.40.0-1
> ii  libselinux1 3.3-1+b1
> ii  libstdc++6  11.2.0-12
> ii  libsystemd0 249.7-1
> ii  libunwind8  1.3.2-2
> ii  libxau6 1:1.0.9-1
> ii  libxdmcp6   1:1.1.2-3
> ii  libxfont2   1:2.0.5-1
> ii  perl5.32.1-6
> ii  tigervnc-common 1.11.0+dfsg-3
> ii  x11-xkb-utils   7.7+5
> ii  xauth   1:1.1-1
> ii  xkb-data2.33-1
> ii  zlib1g  1:1.2.11.dfsg-2
>
> Versions of packages tigervnc-standalone-server recommends:
> ii  libgl1-mesa-dri21.2.6-1
> ii  x11-xserver-utils  7.7+9
> ii  xfonts-base1:1.0.5
>
> Versions of packages tigervnc-standalone-server suggests:
> ii  xfonts-100dpi1:1.0.4+nmu1.1
> ii  xfonts-75dpi 1:1.0.4+nmu1.1
> ii  xfonts-scalable  1:1.0.3-1.2
>
> -- no debconf information
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?

[Ola Lundqvist]

Hi Paul

If my memory is correct. I should know since I wrote the cron-apt software
but it was quite some time ago. ... Checking the code now to refresh my
memory...

Emails are sent by default only when apt fails.

All output is logged to the cron-apt log file.

Logs are sent to syslog on "upgrade". By default upgrade is not enabled.

I'm not sure this helps in any way, but I thought I could at least respond
with what I know.

Cheers

// Ola




On Wed, 24 Nov 2021 at 14:42, Paul Wise  wrote:

> Package: logcheck
> Severity: wishlist
> X-Debbugs-CC: a...@packages.debian.org,
> unattended-upgra...@packages.debian.org, cron-...@packages.debian.org,
> aptitude-ro...@packages.debian.org
>
> Currently logcheck focuses on /var/log/syslog and /var/log/auth.log but
> it would be nice to have separate filtering for other types of logs
> that normally don't get merged into syslog or the journal.
>
> One of those types of logs is apt upgrade logs. When apt itself is
> invoked, it sends terminal output (including \r but not colours) to the
> apt term.log file. If unattended-upgrades is being run then the same
> output and also output of the apt hooks goes to the additional log file
> unattended-upgrades-dpkg.log (which also contains \r but not colours).
> The unattended-upgrades code may also send a mail with that log output
> but without any \r or colors.
>
> The unattended-upgrades wrapper around apt print various uninteresting
> messages. The cron-apt/aptitude-robot alternatives probably also do the
> same. apt itself prints a lot of messages that aren't interesting.
> The apt hooks shipped by various packages print various uninteresting
> messages. The maintainer scripts shipped by various packages print
> various uninteresting messages.
>
> I'm currently using the attached hacky script with lots of regexes to
> implement apt upgrade log filtering. It seems to me that a better way
> to do this would be to integrate separate apt filtering into logcheck
> and then integrate into each package (including apt) logcheck ignore
> configs containing the regexes that represent uninteresting messages.
>
> There could be an apt hook to use logcheck to filter the apt term.log
> to an apt term-interesting.log and an unattended-upgrades hook to
> filter unattended-upgrades-dpkg.log to a corresponding file and an
> option/hook to filter unattended-upgrades mails. The same could be done
> for cron-apt/aptitude-robot.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#989089: [Pkg-tigervnc-devel] Bug#989089: tigervnc-standalone-server: when a vncserver instance is invoked, mate-panel starts grabbing memory

[Ola Lundqvist]

Hi

Now I understand better. What I do not understand is why you have filed the
bug on vnc when it is the mate-panel that hogs the memory.
For this to be a vnc bug I think we need some proof that this is VNC
specific and this does not happen when starting a normal X session.

Vnc starts a desktop environment and mate-panel is a component of the Mate
desktop environment.

Or am I completely wrong?

// Ola

On Sat, 29 May 2021 at 08:58, deltagam...@gmx.net 
wrote:

> The relevant machine has 8 GB RAM, 2 GB RAM is fix reserved for oracle DB
> 18c xe.
>
> As you can see here
>
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
> Fr 30. Apr 16:09:49 CEST 2021
>   totalusedfree  shared  buff/cache
> available
> Mem:   79782761 89112784325
> 3636
>
> 3.6 GB available memory before starting vncserver on 30. April  ...
>
> ===  after some days  ==
> [user__at__machine:pts/4 ~/.vnc]$ date && sudo pmap 8903 | head -10
> Do 6. Mai 13:21:39 CEST 2021
> [sudo] Passwort für user:
> 8903:   mate-panel
> 55ec1bd26000128K r mate-panel
> 55ec1bd46000324K r-x-- mate-panel
> 55ec1bd97000140K r mate-panel
> 55ec1bdba000 16K r mate-panel
> 55ec1bdbe000  4K rw--- mate-panel
> 55ec1cb34000 1698228K rw---   [ anon ]
> 7f9e9000   1416K rw---   [ anon ]
> 7f9e90162000  64120K -   [ anon ]
> 7f9e9400   1448K rw---   [ anon ]
> [user__at__machine:pts/4 ~/.vnc]$
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
>
> After 6 days, on 6 May mate-panel has grabbed more than 1698228K  ==> 1.69
> GB,
> the available memory sunk to 2 GB , the difference is approx. the 1.6 GB
> that mate-panel has grabbed.
>
>
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
> Do 6. Mai 13:24:07 CEST 2021
>   totalusedfree  shared  buff/cache
> available
> Mem:   79784357 54112683079
> 2049
> Swap:  664925544095
> Total:1462869124636
> [user__at__machine:pts/4 ~/.vnc]$
>
> After killing the vncserver now, on 6. May, the mate-panel process
> disappeared also ( it seems there is a strong interaction between
> tigervnc-standalone-server and mate-panel ) , the new available memory is
> also again around 3.6 GB
> which indicates again that mate-panel has grabbed the difference between
> the 2 "avaibale memory" states, namely 3.6GB and 2.0GB
>
>
> On a reference machine, same Debian buster, same 8 GB RAM, but DB not
> installed yet, the mate-panel has stable about 35 MB memory , after a week
> with a running vncserver:
>
> =  reference machine with running vncserver AND connected client for 
> a week ==
>
> user__at__refmachine:~/.vnc$ sudo pmap 19726 |head -10
> 19726:   mate-panel
> 558100ac1000128K r mate-panel
> 558100ae1000324K r-x-- mate-panel
> 558100b32000140K r mate-panel
> 558100b55000 16K r mate-panel
> 558100b59000  4K rw--- mate-panel
> 55810215e000  35224K rw---   [ anon ]
> 7fcc3000132K rw---   [ anon ]
> 7fcc30021000  65404K -   [ anon ]
> 7fcc3400132K rw---   [ anon ]
> user__at__refmachine:~/.vnc$
>
>
> I think the relevant address, process, is the first  [ anon ]  entry in the 
> pmap listing of the mate-panel.
>
> It is about 35 MB at ref-machine,
>
> and started with about 13 MB  { 5620203f9000  13064K rw---   [ anon ] }  
> on the production machine
> to 266 MB { 5620203f9000 266824K rw---   [ anon ] } 1 day later  on the 
> production machine
> up to 1.69 GB {  55ec1cb34000 1698228K rw---   [ anon ] } after 1 week on 
> the production machine, where I killed/stopped the vncserver.
>
> I let the mate-panel reach also between 2.5 GB and 3 GB before I killed the 
> vncserver, the mate-panel process disappeared also,
> and the freed memroy  corresponded to the memory mate-panel has grabbed.
>
> The displayed lines are all protocolled in the 2 attached files.
>
> Hope this clarifies the case.
>
> Greets
>
>
>
>
> Am 26.05.2021 um 08:27 schrieb Ola Lundqvist:
>
> Hi
>
> When you are referring to "grabbing memory" how much are you expecting
> mate-panel to use?
> Is it much more than what the mate-panel use to use in other X servers?
> I can see that mate-panel use some 70 to 100 MB memory but since I have no
> knowledge about this software I cannot tell whether that is a lot of not.
>
> Cheers
>
> // Ola
>
> On Tue, 25 May 2021 at 18:19, delt

Bug#989089: [Pkg-tigervnc-devel] Bug#989089: tigervnc-standalone-server: when a vncserver instance is invoked, mate-panel starts grabbing memory

[Ola Lundqvist]

Hi

When you are referring to "grabbing memory" how much are you expecting
mate-panel to use?
Is it much more than what the mate-panel use to use in other X servers?
I can see that mate-panel use some 70 to 100 MB memory but since I have no
knowledge about this software I cannot tell whether that is a lot of not.

Cheers

// Ola

On Tue, 25 May 2021 at 18:19, deltagam...@gmx.net 
wrote:

> forgot to attach some files
>
>
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#860372: hp-search-mac: please make the build reproducible

[Ola Lundqvist]

Hi

Really strange. Tried again now.

// Ola

On Mon, 17 May 2021 at 10:09, Chris Lamb  wrote:

> Hi,
>
> > It is still not in the archives?
> > I wonder what I do wrong then...
>
> No, I'm afraid not. :)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#860372: hp-search-mac: please make the build reproducible

[Ola Lundqvist]

Hi

It is still not in the archives?
I wonder what I do wrong then...

/ Ola

Den mån 15 feb. 2021 11:15Chris Lamb  skrev:

> Hey Ola,
>
> > Thank you for the reminder. It turns out that I did update it 3 years ago
> > but forgot to upload. Doing that now.
>
> Just wondering whether you had a problem uploading this package? :)
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#860372: hp-search-mac: please make the build reproducible

[Ola Lundqvist]

Hi Chris

Thank you for the reminder. It turns out that I did update it 3 years ago
but forgot to upload. Doing that now.

// Ola

On Wed, 2 Sep 2020 at 01:03, Chris Lamb  wrote:

> Chris Lamb wrote:
>
> > Would you consider applying this patch and uploading?
>
> Friendly ping on this? Seems like there hasn't been any update on this bug
> in
> 971 days now (!).
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#961154: debarchiver: diff for NMU version 0.11.5+nmu1

[Ola Lundqvist]

Thank you

On Tue, 10 Nov 2020 at 23:51, Dominic Hargreaves  wrote:

> Control: tags 961154 + patch
> Control: tags 961154 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for debarchiver (versioned as 0.11.5+nmu1) and
> uploaded it to DELAYED/0. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#586415: ITA: tightvnc-java -- TightVNC java applet and command line program

[Ola Lundqvist]

Yay. Please go ahead.

Den tis 29 sep. 2020 20:56Mike Gabriel 
skrev:

> On  Di 29 Sep 2020 20:46:17 CEST, Sven Geuer wrote:
>
> > owner -1 debma...@g-e-u-e-r.de
> > retitle -1 ITA: tightvnc-java -- TightVNC java applet and cli program
>
> > [ ... @Ola ...]
>
> > Hi Mike,
> >
> > I'd like to maintain tightvnc-java under the umbrella of the Debian
> > Remote Packaging Team as I already do for tightvnc. Please add the
> > tightvnc-java project to the team repository as soon as Ola gave his
> > OK.
>
> Awesome! And yes, will do.
>
> > [1] https://salsa.debian.org/sven-geuer-guest/tightvnc-java
>
> Mike
>
> --
>
> DAS-NETZWERKTEAM
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>
>

Bug#586413: ITA: tightvnc -- virtual network computing server software

[Ola Lundqvist]

Hi

No git here. Just regular packaging.

/ Ola

Den tors 18 juni 2020 09:54Mike Gabriel  skrev:

> Hi Sven,
>
> On  Mi 17 Jun 2020 20:34:39 CEST, Sven Geuer wrote:
>
> > Owner: debma...@g-e-u-e-r.de
> >
> > Hi Ola,
> >
> > thank you for your consent. I take ownership of this bug now. It will
> > be closed with the upcoming upload of tightvnc.
> >
> > Thanks for having maintained tightvnc for all these years.
> >
> > If there's anything in contrast to what you intended, please let me
> > know. We'll get it sorted out.
> >
> > Sven
>
> I have created a tightvnc repo for you.
> https://salsa.debian.org/debian-remote-team/tightvnc/
>
>
> As I see it, the package has never been maintained in Git. It would be
> cool to have its complete history (Debian package imports via gbp
> import-dsc) added to that new Git repo.
>
> Sven, do you know you to do such an import (including all recent
> Debian release branches)?
>
> If not, I am happy to help you with that.
>
> @Ola: or do you have some packaging Git around locally that you used
> in the past?
>
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#586413: ITA: tightvnc -- virtual network computing server software

[Ola Lundqvist]

Thank you very much.

Den ons 17 juni 2020 20:34Sven Geuer  skrev:

> Owner: debma...@g-e-u-e-r.de
>
> Hi Ola,
>
> thank you for your consent. I take ownership of this bug now. It will
> be closed with the upcoming upload of tightvnc.
>
> Thanks for having maintained tightvnc for all these years.
>
> If there's anything in contrast to what you intended, please let me
> know. We'll get it sorted out.
>
> Sven
>
> Am Mittwoch, den 17.06.2020, 11:25 +0200 schrieb Ola Lundqvist:
> > Hi
> >
> > Wonderful!
> >
> > It would be great if someone else take over. Please remove me as
> > uploader.
> > I have maintained it for many years now and it is time for someone
> > else to
> > take it over.
> >
> > / Ola
> >
> >
> > Den ons 17 juni 2020 08:14Mike Gabriel  skrev:
> >
> > > Hi Sven,
> > >
> > > On  Di 16 Jun 2020 23:07:27 CEST, Sven Geuer wrote:
> > >
> > > > Hi Mike,
> > > > Hi Ola,
> > > >
> > > > I would be interested in maintaining tightvnc as a new member of
> > > > the
> > > > Debian Remote Maintainers Team. I already started some work on it
> > > > in a
> > > > private repository on salsa [1]. 'FTBFS with gcc-10' is already
> > > > fixed.
> > > >
> > > > Being a DM, I currently maintain two packages under the umbrella
> > > > of the
> > > > Debian Security Tools Packaging Team, and had contributed to
> > > > other
> > > > packages of this team [2].
> > > >
> > > > @Mike: May I ask you to accept me as team member to debian-
> > > > remote?
> > > > @Ola: Would you want to stay listed as uploader with moving
> > > > tightvnc to
> > > > the team?
> > > >
> > > > Please let me know, if you accept my application.
> > > >
> > > > Best,
> > > > Sven
> > > >
> > > > [1] https://salsa.debian.org/sven-geuer-guest/tightvnc
> > > > [2]
> > > > https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de
> > >
> > > Awesome! Regarding your Debian Remote Team applications: Welcome
> > > in!
> > >
> > > I'll wait for Ola's response, then I'll give you permissions on the
> > > tightvnc.git repo.
> > >
> > > Mike
> > > --
> > >
> > > mike gabriel aka sunweaver (Debian Developer)
> > > mobile: +49 (1520) 1976 148
> > > landline: +49 (4351) 486 14 27
> > >
> > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577
> > > 1B31
> > > mail: sunwea...@debian.org, http://sunweavers.net
> > >
> > >
>

Bug#586413: RFA: a lot of packages

[Ola Lundqvist]

Hi

Wonderful!

It would be great if someone else take over. Please remove me as uploader.
I have maintained it for many years now and it is time for someone else to
take it over.

/ Ola


Den ons 17 juni 2020 08:14Mike Gabriel  skrev:

> Hi Sven,
>
> On  Di 16 Jun 2020 23:07:27 CEST, Sven Geuer wrote:
>
> > Hi Mike,
> > Hi Ola,
> >
> > I would be interested in maintaining tightvnc as a new member of the
> > Debian Remote Maintainers Team. I already started some work on it in a
> > private repository on salsa [1]. 'FTBFS with gcc-10' is already fixed.
> >
> > Being a DM, I currently maintain two packages under the umbrella of the
> > Debian Security Tools Packaging Team, and had contributed to other
> > packages of this team [2].
> >
> > @Mike: May I ask you to accept me as team member to debian-remote?
> > @Ola: Would you want to stay listed as uploader with moving tightvnc to
> > the team?
> >
> > Please let me know, if you accept my application.
> >
> > Best,
> > Sven
> >
> > [1] https://salsa.debian.org/sven-geuer-guest/tightvnc
> > [2] https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de
>
> Awesome! Regarding your Debian Remote Team applications: Welcome in!
>
> I'll wait for Ola's response, then I'll give you permissions on the
> tightvnc.git repo.
>
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#961154: debarchiver: needs a build dependency on libpod-parser-perl

[Ola Lundqvist]

Thank you. Will add on next ipload.

Den ons 20 maj 2020 22:06Niko Tyni  skrev:

> Package: debarchiver
> Version: 0.11.5
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.32-transition
>
> This package uses /usr/bin/podselect, part of the Pod-Parser distribution
> which will be removed from the Perl core in upcoming version 5.32.
> It is being packaged separately for Debian as libpod-parser-perl
> (#960790), and affected packages need to declare appropriate dependencies
> on that.
>
> As the perl core packages already Provide libpod-parser-perl, these
> dependencies can be added at any time and do not need to wait for the
> separate package to enter sid.
>
> Please consider adding a build dependency sooner rather than later,
> to help our testing efforts.
>
>  make[3]: Entering directory '/<>/po4a'
>  podselect ../src/debarchiver.pl > debarchiver.pod
>
> --
> Niko Tyni   nt...@debian.org
>

Bug#954340: debarchiver: gpg now needs extra option for signing the Release file

[Ola Lundqvist]

Hi Jörgen

Thank you. Will upload a corrected package shortly.
Sorry for the delay in responding.

// Ola

On Fri, 20 Mar 2020 at 14:51, Jörgen Hägg  wrote:
>
> Package: debarchiver
> Version: 0.11.3
> Severity: important
> Tags: patch
>
> It seems as if gnupg needs an extra option (--pinentry-mode loopback) to
> be able to run in batch mode. I discovered this when I upgraded the
> archive server from stretch to buster.
>
> /jh
>
>
> --- /usr/bin/debarchiver.org2020-03-20 14:12:17.0 +0100
> +++ /usr/bin/debarchiver2020-03-20 14:13:27.0 +0100
> @@ -1301,7 +1301,7 @@
>  unlink("$path/Release.gpg");
> if ($gpgpassfile) {
> cmdaction("cat $gpgpassfile | gpg --batch --no-tty -a -b -s -u 
> $gpgkey " .
> - "--passphrase-fd 0 -o $path/Release.gpg $path/Release",
> + "--pinentry-mode loopback --passphrase-fd 0 -o 
> $path/Release.gpg $path/Release",
>   "Sign Release file for $path with key '$gpgkey'",
>   3);
> }
>
>
>
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.19.0-8-686 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages debarchiver depends on:
> ii  adduser3.118
> ii  apt-utils  1.8.2
> ii  dpkg-dev   1.19.7
> ii  opalmod0.2.2
>
> Versions of packages debarchiver recommends:
> ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
> ii  mailx1:20071201-3
> ii  sendmail-bin [mail-transport-agent]  8.15.2-14~deb10u1
>
> Versions of packages debarchiver suggests:
> ii  devscripts  2.19.5+deb10u1
> ii  gnupg   2.2.19-2~bpo10+1
>
> -- no debconf information



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#954158: Re: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Ola Lundqvist]

Yes then it is really strange...

Den ons 18 mars 2020 13:59  skrev:

>
> I looked through the folder /usr/bin just now, and found the xrdp is also
> in the folder /usr/bin
>
> # ls xr*
> xrandr  xrdb  xrdp-dis  xrdp-genkeymap  xrdp-keygen  xrdp-sesadmin
> xrdp-sesrun  xrefresh
>
> So the message in the vnc log fle is so strange.
>
>
>
> > -原始邮件-
> > 发件人: "Ola Lundqvist" 
> > 发送时间: 2020-03-18 20:35:00 (星期三)
> > 收件人: gulfstream 
> > 抄送: "Ola Lundqvist" , 954...@bugs.debian.org
> > 主题: Re: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver
> output a blank screen with gray color under gnome
> >
> > Hi
> >
> > Yes root does not help because the search path is not including
> > /usr/sbin for vnc.
> > /usr/sbin and /sbin is only intended for system commands that root run
> > for system maintenance and for system services.
> > This is why I do not understand why xrdb has moved its location. The
> > intention of this tool is for the user to run.
> >
> > In your case you can edit your startup file manually to include the
> > path directly.
> >
> > Best regards
> >
> > // Ola
> >
> > On Wed, 18 Mar 2020 at 13:24,  wrote:
> > >
> > > But when I start vnc with root, the smae log is also got:
> > >
> > > 18/03/20 20:21:01 Xvnc version TightVNC-1.3.9
> > > 18/03/20 20:21:01 Copyright (C) 2000-2007 TightVNC Group
> > > 18/03/20 20:21:01 Copyright (C) 1999 AT Laboratories Cambridge
> > > 18/03/20 20:21:01 All Rights Reserved.
> > > 18/03/20 20:21:01 See http://www.tightvnc.com/ for information on
> TightVNC
> > > 18/03/20 20:21:01 Desktop name 'X' (athena:2)
> > > 18/03/20 20:21:01 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t,
> 3.8t
> > > 18/03/20 20:21:01 Listening for VNC connections on TCP port 5902
> > > xrdb: No such file or directory
> > > xrdb: can't open file '/root/.Xresources'
> > > Terminated
> > >
> > > 18/03/20 20:21:24 Got connection from client 127.0.0.1
> > > 18/03/20 20:21:24 Using protocol version 3.8
> > > 18/03/20 20:21:24 Enabling TightVNC protocol extensions
> > > 18/03/20 20:21:27 Full-control authentication passed by 127.0.0.1
> > > 18/03/20 20:21:27 Pixel format for client 127.0.0.1:
> > > 18/03/20 20:21:27   32 bpp, depth 24, little endian
> > > 18/03/20 20:21:27   true colour: max r 255 g 255 b 255, shift r 16 g 8
> b 0
> > > 18/03/20 20:21:27   no translation needed
> > > 18/03/20 20:21:27 Using raw encoding for client 127.0.0.1
> > > 18/03/20 20:21:27 Using compression level 1 for client 127.0.0.1
> > > 18/03/20 20:21:27 Using image quality level 6 for client 127.0.0.1
> > > 18/03/20 20:21:27 Enabling X-style cursor updates for client 127.0.0.1
> > > 18/03/20 20:21:27 Enabling cursor position updates for client 127.0.0.1
> > > 18/03/20 20:21:27 Enabling LastRect protocol extension for client
> 127.0.0.1
> > >
> > >
> > > And the same blank screen was got in the client.
> > >
> > >
> > >
> > > -原始邮件-
> > > 发件人:"Ola Lundqvist" 
> > > 发送时间:2020-03-18 19:55:05 (星期三)
> > > 收件人: gulfstream , 954...@bugs.debian.org
> > > 抄送: "Ola Lundqvist" 
> > > 主题: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver
> output a blank screen with gray color under gnome
> > >
> > > Hi
> > >
> > > Then I understand. It must have changed path from /usr/bin to /usr/sbin
> > >
> > > I do not really understand why. It is not only for root to run...
> > >
> > > // Ola
> > >
> > > On Wed, 18 Mar 2020 at 11:39,  wrote:
> > >>
> > >> I installed xrdp with apt-get, so its path is default of debian.
> > >>
> > >> $ whereis xrdp
> > >> xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp
> /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz
> > >>
> > >>
> > >> -原始邮件-
> > >> 发件人:"Ola Lundqvist" 
> > >> 发送时间:2020-03-18 16:29:28 (星期三)
> > >> 收件人: wg...@china.com, 954...@bugs.debian.org
> > >> 抄送:
> > >> 主题: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank
> screen with gray color under gnome
> > >>
> > >> What is the path of xrdb on your installation?
> > >>
> > >> // Ola
> > >>
> > >> On Wed, 18 Mar 2020 at 06:57,  wrote:
> &g

Bug#954158: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Ola Lundqvist]

Hi

Yes root does not help because the search path is not including
/usr/sbin for vnc.
/usr/sbin and /sbin is only intended for system commands that root run
for system maintenance and for system services.
This is why I do not understand why xrdb has moved its location. The
intention of this tool is for the user to run.

In your case you can edit your startup file manually to include the
path directly.

Best regards

// Ola

On Wed, 18 Mar 2020 at 13:24,  wrote:
>
> But when I start vnc with root, the smae log is also got:
>
> 18/03/20 20:21:01 Xvnc version TightVNC-1.3.9
> 18/03/20 20:21:01 Copyright (C) 2000-2007 TightVNC Group
> 18/03/20 20:21:01 Copyright (C) 1999 AT Laboratories Cambridge
> 18/03/20 20:21:01 All Rights Reserved.
> 18/03/20 20:21:01 See http://www.tightvnc.com/ for information on TightVNC
> 18/03/20 20:21:01 Desktop name 'X' (athena:2)
> 18/03/20 20:21:01 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
> 18/03/20 20:21:01 Listening for VNC connections on TCP port 5902
> xrdb: No such file or directory
> xrdb: can't open file '/root/.Xresources'
> Terminated
>
> 18/03/20 20:21:24 Got connection from client 127.0.0.1
> 18/03/20 20:21:24 Using protocol version 3.8
> 18/03/20 20:21:24 Enabling TightVNC protocol extensions
> 18/03/20 20:21:27 Full-control authentication passed by 127.0.0.1
> 18/03/20 20:21:27 Pixel format for client 127.0.0.1:
> 18/03/20 20:21:27   32 bpp, depth 24, little endian
> 18/03/20 20:21:27   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
> 18/03/20 20:21:27   no translation needed
> 18/03/20 20:21:27 Using raw encoding for client 127.0.0.1
> 18/03/20 20:21:27 Using compression level 1 for client 127.0.0.1
> 18/03/20 20:21:27 Using image quality level 6 for client 127.0.0.1
> 18/03/20 20:21:27 Enabling X-style cursor updates for client 127.0.0.1
> 18/03/20 20:21:27 Enabling cursor position updates for client 127.0.0.1
> 18/03/20 20:21:27 Enabling LastRect protocol extension for client 127.0.0.1
>
>
> And the same blank screen was got in the client.
>
>
>
> -原始邮件-
> 发件人:"Ola Lundqvist" 
> 发送时间:2020-03-18 19:55:05 (星期三)
> 收件人: gulfstream , 954...@bugs.debian.org
> 抄送: "Ola Lundqvist" 
> 主题: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a 
> blank screen with gray color under gnome
>
> Hi
>
> Then I understand. It must have changed path from /usr/bin to /usr/sbin
>
> I do not really understand why. It is not only for root to run...
>
> // Ola
>
> On Wed, 18 Mar 2020 at 11:39,  wrote:
>>
>> I installed xrdp with apt-get, so its path is default of debian.
>>
>> $ whereis xrdp
>> xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp 
>> /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz
>>
>>
>> -原始邮件-
>> 发件人:"Ola Lundqvist" 
>> 发送时间:2020-03-18 16:29:28 (星期三)
>> 收件人: wg...@china.com, 954...@bugs.debian.org
>> 抄送:
>> 主题: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen 
>> with gray color under gnome
>>
>> What is the path of xrdb on your installation?
>>
>> // Ola
>>
>> On Wed, 18 Mar 2020 at 06:57,  wrote:
>>>
>>> Hi, I am glad to receive your reply. I have checked the xstartup which in 
>>> the folder ~/.vnc. It is created by tightvncserver automatically. It is as 
>>> below,
>>>
>>> #!/bin/sh
>>>
>>> xrdb $HOME/.Xresources
>>> xsetroot -solid grey
>>> #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" 
>>> &
>>> #x-window-manager &
>>> # Fix to make GNOME work
>>> export XKL_XMODMAP_DISABLE=1
>>> /etc/X11/Xsession
>>>
>>>
>>> And the log file is,
>>>
>>> 20 23:07:54 Xvnc version TightVNC-1.3.9
>>> 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group
>>> 17/03/20 23:07:54 Copyright (C) 1999 AT Laboratories Cambridge
>>> 17/03/20 23:07:54 All Rights Reserved.
>>> 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC
>>> 17/03/20 23:07:54 Desktop name 'X' (athena:1)
>>> 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
>>> 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901
>>> xrdb: No such file or directory
>>> xrdb: can't open file '/home/wgl/.Xresources'
>>>
>>> 17/03/20 23:08:29 Got connection from client 127.0.0.1
>>> 17/03/20 23:08:29 Using protocol version 3.8
>>> 17/03/20 23:08:29 Enabling TightVNC protocol extensions
>>> 17/03/20 23:08:32 Full-control authentication passe

Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Ola Lundqvist]

Hi

Then I understand. It must have changed path from /usr/bin to /usr/sbin

I do not really understand why. It is not only for root to run...

// Ola

On Wed, 18 Mar 2020 at 11:39,  wrote:

> I installed xrdp with apt-get, so its path is default of debian.
>
> $ whereis xrdp
> xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp
> /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz
>
>
> -----原始邮件-
> *发件人:*"Ola Lundqvist" 
> *发送时间:*2020-03-18 16:29:28 (星期三)
> *收件人:* wg...@china.com, 954...@bugs.debian.org
> *抄送:*
> *主题:* Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank
> screen with gray color under gnome
>
> What is the path of xrdb on your installation?
>
> // Ola
>
> On Wed, 18 Mar 2020 at 06:57,  wrote:
>
>> Hi, I am glad to receive your reply. I have checked the xstartup which in
>> the folder ~/.vnc. It is created by tightvncserver automatically. It is as
>> below,
>>
>> #!/bin/sh
>>
>> xrdb $HOME/.Xresources
>> xsetroot -solid grey
>> #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP
>> Desktop" &
>> #x-window-manager &
>> # Fix to make GNOME work
>> export XKL_XMODMAP_DISABLE=1
>> /etc/X11/Xsession
>>
>>
>> And the log file is,
>>
>> 20 23:07:54 Xvnc version TightVNC-1.3.9
>> 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group
>> 17/03/20 23:07:54 Copyright (C) 1999 AT Laboratories Cambridge
>> 17/03/20 23:07:54 All Rights Reserved.
>> 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on
>> TightVNC
>> 17/03/20 23:07:54 Desktop name 'X' (athena:1)
>> 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
>> 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901
>> xrdb: No such file or directory
>> xrdb: can't open file '/home/wgl/.Xresources'
>>
>> 17/03/20 23:08:29 Got connection from client 127.0.0.1
>> 17/03/20 23:08:29 Using protocol version 3.8
>> 17/03/20 23:08:29 Enabling TightVNC protocol extensions
>> 17/03/20 23:08:32 Full-control authentication passed by 127.0.0.1
>> 17/03/20 23:08:32 Pixel format for client 127.0.0.1:
>> 17/03/20 23:08:32   32 bpp, depth 24, little endian
>> 17/03/20 23:08:32   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
>> 17/03/20 23:08:32   no translation needed
>> 17/03/20 23:08:32 Using raw encoding for client 127.0.0.1
>> 17/03/20 23:08:32 Using compression level 1 for client 127.0.0.1
>> 17/03/20 23:08:32 Using image quality level 6 for client 127.0.0.1
>> 17/03/20 23:08:32 Enabling X-style cursor updates for client 127.0.0.1
>> 17/03/20 23:08:32 Enabling cursor position updates for client 127.0.0.1
>> 17/03/20 23:08:32 Enabling LastRect protocol extension for client
>> 127.0.0.1
>> 17/03/20 23:09:23 Client 127.0.0.1 gone
>> 17/03/20 23:09:23 Statistics:
>> 17/03/20 23:09:23   key events received 0, pointer events 34
>> 17/03/20 23:09:23   framebuffer updates 1, rectangles 3, bytes 3145834
>> 17/03/20 23:09:23 cursor shape updates 1, bytes 82
>> 17/03/20 23:09:23 cursor position updates 1, bytes 12
>> 17/03/20 23:09:23 raw rectangles 1, bytes 3145740
>> 17/03/20 23:09:23   raw bytes equivalent 3145740, compression ratio
>> 1.00
>>
>>
>> There is a message "xrdb: No such file or directory" in the log, but the
>> xrdb was installed in the computer.
>>
>> I don't know if it is a bug of tightvnc or a mistake configuration of
>> xstratup. Btw, I test the tightvncserver in Debian Buster, and same result
>> was got.
>>
>>
>>
>>
>> Best regards,
>> Gulfstream
>>
>>
>> -原始邮件-
>> *发件人:*"Ola Lundqvist" 
>> *发送时间:*2020-03-18 04:31:44 (星期三)
>> *收件人:* gulfstream , 954...@bugs.debian.org
>> *抄送:* cont...@bugs.debian.org
>> *主题:* Re: Bug#954158: tightvncserver output a blank screen with gray
>> color under gnome
>>
>> tags 954158 + moreinfo
>> severity 954158 minor
>> thanks
>>
>> Hi
>>
>> Have you checked your vnc startup script in ~/.vnc/xstartup or
>> alternatively the startup script in ~/.vncstartup
>>
>> This is the set of commands used to start the window manager and other
>> stuff.
>>
>> When reading the manual I can see that this is not really clear. This
>> could be improved.
>>
>> // Ola
>>
>>
>>
>> On Tue, 17 Mar 2020 at 16:33, gulfstream  wrote:
>>
>>> Package: tightvncserver
>>> Version: 1:1.3.9-9.1
>>> Severity: grave
>&

Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Ola Lundqvist]

What is the path of xrdb on your installation?

// Ola

On Wed, 18 Mar 2020 at 06:57,  wrote:

> Hi, I am glad to receive your reply. I have checked the xstartup which in
> the folder ~/.vnc. It is created by tightvncserver automatically. It is as
> below,
>
> #!/bin/sh
>
> xrdb $HOME/.Xresources
> xsetroot -solid grey
> #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP
> Desktop" &
> #x-window-manager &
> # Fix to make GNOME work
> export XKL_XMODMAP_DISABLE=1
> /etc/X11/Xsession
>
>
> And the log file is,
>
> 20 23:07:54 Xvnc version TightVNC-1.3.9
> 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group
> 17/03/20 23:07:54 Copyright (C) 1999 AT Laboratories Cambridge
> 17/03/20 23:07:54 All Rights Reserved.
> 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC
> 17/03/20 23:07:54 Desktop name 'X' (athena:1)
> 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
> 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901
> xrdb: No such file or directory
> xrdb: can't open file '/home/wgl/.Xresources'
>
> 17/03/20 23:08:29 Got connection from client 127.0.0.1
> 17/03/20 23:08:29 Using protocol version 3.8
> 17/03/20 23:08:29 Enabling TightVNC protocol extensions
> 17/03/20 23:08:32 Full-control authentication passed by 127.0.0.1
> 17/03/20 23:08:32 Pixel format for client 127.0.0.1:
> 17/03/20 23:08:32   32 bpp, depth 24, little endian
> 17/03/20 23:08:32   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
> 17/03/20 23:08:32   no translation needed
> 17/03/20 23:08:32 Using raw encoding for client 127.0.0.1
> 17/03/20 23:08:32 Using compression level 1 for client 127.0.0.1
> 17/03/20 23:08:32 Using image quality level 6 for client 127.0.0.1
> 17/03/20 23:08:32 Enabling X-style cursor updates for client 127.0.0.1
> 17/03/20 23:08:32 Enabling cursor position updates for client 127.0.0.1
> 17/03/20 23:08:32 Enabling LastRect protocol extension for client 127.0.0.1
> 17/03/20 23:09:23 Client 127.0.0.1 gone
> 17/03/20 23:09:23 Statistics:
> 17/03/20 23:09:23   key events received 0, pointer events 34
> 17/03/20 23:09:23   framebuffer updates 1, rectangles 3, bytes 3145834
> 17/03/20 23:09:23 cursor shape updates 1, bytes 82
> 17/03/20 23:09:23 cursor position updates 1, bytes 12
> 17/03/20 23:09:23 raw rectangles 1, bytes 3145740
> 17/03/20 23:09:23   raw bytes equivalent 3145740, compression ratio
> 1.00
>
>
> There is a message "xrdb: No such file or directory" in the log, but the
> xrdb was installed in the computer.
>
> I don't know if it is a bug of tightvnc or a mistake configuration of
> xstratup. Btw, I test the tightvncserver in Debian Buster, and same result
> was got.
>
>
>
>
> Best regards,
> Gulfstream
>
>
> -原始邮件-
> *发件人:*"Ola Lundqvist" 
> *发送时间:*2020-03-18 04:31:44 (星期三)
> *收件人:* gulfstream , 954...@bugs.debian.org
> *抄送:* cont...@bugs.debian.org
> *主题:* Re: Bug#954158: tightvncserver output a blank screen with gray
> color under gnome
>
> tags 954158 + moreinfo
> severity 954158 minor
> thanks
>
> Hi
>
> Have you checked your vnc startup script in ~/.vnc/xstartup or
> alternatively the startup script in ~/.vncstartup
>
> This is the set of commands used to start the window manager and other
> stuff.
>
> When reading the manual I can see that this is not really clear. This
> could be improved.
>
> // Ola
>
>
>
> On Tue, 17 Mar 2020 at 16:33, gulfstream  wrote:
>
>> Package: tightvncserver
>> Version: 1:1.3.9-9.1
>> Severity: grave
>>
>>
>> Hello, I want to use tightvnc under the gnome desktop, but only a blank
>> screen was got in the client. Nothing is on the screen except a cursor.
>>
>> What is the matter? Would you please resolve it?
>>
>> Thank you very much!
>>
>>
>>
>> Best regards,
>> Gulfstream
>>
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
>> LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages tightvncserver depends on:
>> ii  libc62.29-10
>> ii  libjpeg62-turbo  1:1.5.2-2+b1
>> ii  li

Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Ola Lundqvist]

tags 954158 + moreinfo
severity 954158 minor
thanks

Hi

Have you checked your vnc startup script in ~/.vnc/xstartup or
alternatively the startup script in ~/.vncstartup

This is the set of commands used to start the window manager and other
stuff.

When reading the manual I can see that this is not really clear. This could
be improved.

// Ola



On Tue, 17 Mar 2020 at 16:33, gulfstream  wrote:

> Package: tightvncserver
> Version: 1:1.3.9-9.1
> Severity: grave
>
>
> Hello, I want to use tightvnc under the gnome desktop, but only a blank
> screen was got in the client. Nothing is on the screen except a cursor.
>
> What is the matter? Would you please resolve it?
>
> Thank you very much!
>
>
>
> Best regards,
> Gulfstream
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
> LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages tightvncserver depends on:
> ii  libc62.29-10
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libx11-6 2:1.6.9-2
> ii  perl 5.30.0-9
> ii  x11-common   1:7.7+20
> ii  x11-utils7.7+5
> ii  xauth1:1.0.10-1
> ii  xserver-common   2:1.20.7-4
> ii  zlib1g   1:1.2.11.dfsg-2
>
> Versions of packages tightvncserver recommends:
> ii  x11-xserver-utils  7.7+8
> ii  xfonts-base1:1.0.5
>
> Versions of packages tightvncserver suggests:
> pn  tightvnc-java  
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#940787: Progress. Package filed for removal.

[Ola Lundqvist]

You can follow progress on this Bug here: 947604:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947604.

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#947604: RM: vnc4 -- ROM; Transitional package

[Ola Lundqvist]

Package: ftp.debian.org
Severity: normal

Hi

I'd like to request the removal of vnc4 source package.
The reason is that it has been a transitional package
for two releases and can now safely be removed.

Best regards

// Ola

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)

[Ola Lundqvist]

Thanks.

Den sön 22 dec. 2019 23:02Mike Gabriel  skrev:

> Hi Ola,
>
> On  Sa 21 Dez 2019 19:27:24 CET, Ola Lundqvist wrote:
>
> > Thank you. You can skip the delay.
> >
>
> just issues a
>
>dcut reschedule -f tightvnc_1.3.9-9.1_source.changes -d 0
>
> Greets,
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)

[Ola Lundqvist]

Thank you. You can skip the delay.

Den lör 21 dec. 2019 19:12Mike Gabriel  skrev:

> Package: src:tightvnc
> Version; 1.3.9-9
> Severity: important
>
> Hi Ola et al,
>
> I have just dput tightvnc 1.3.9-9.1 targetting unstable to DELAYED/10.
>
> This is the upload's changelog:
>
> ```
> diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
> --- tightvnc-1.3.9/debian/changelog 2017-01-27 22:08:21.0 +0100
> +++ tightvnc-1.3.9/debian/changelog 2019-12-21 10:35:50.0 +0100
> @@ -1,3 +1,26 @@
> +tightvnc (1:1.3.9-9.1) unstable; urgency=medium
> +
> +  * Security upload. (Closes: #945364).
> +  * CVE-2014-6053: Check malloc() return value on client->server
> ClientCutText
> +message.
> +  * CVE-2019-8287 (aka CVE-2018-20020): Fix heap out-of-bound write
> +vulnerability inside structure in VNC client code.
> +  * CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client
> code.
> +  * CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
> +  * CVE-2018-7225: Uninitialized and potentially sensitive data could be
> +accessed by remote attackers because the msg.cct.length in
> rfbserver.c was
> +not sanitized.
> +  * CVE-2019-15678: LibVNCClient: ignore server-sent cut text longer
> than 1MB.
> +  * Extra patch similar to the fix for CVE-2019-15678: LibVNCClient:
> ignore
> +server-sent reason strings longer than 1MB (see CVE-2018-20748/
> +libvncserver).
> +  * CVE-2019-15679: rfbproto.c/InitialiseRFBConnection: Check desktop name
> +length received before allocating memory for it and limit it to 1MB.
> +  * CVE-2019-15680: Fix null-pointer-deref issue in vncviewer/zlib.c.
> +  * CVE-2019-15681: rfbserver: don't leak stack memory to the remote.
> +
> + -- Mike Gabriel   Sat, 21 Dec 2019 10:35:50 +0100
> +
>   tightvnc (1:1.3.9-9) unstable; urgency=high
>
> * Reverted the transition. Tigervnc is not ready for being a full
>
> ```
>
> The .debdiff for the made upload is attached. Please let me know, if
> you want to let it just pass through after 10 days or if I shall
> cancel the upload and do the upload to unstable yourself.
>
> Please also note my proposal to move tightvnc over under the umbrella
> of the Debian Remote Maintainers Team (debian-rem...@lists.debian.org).
>
> Thanks+Greets,
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi

Ok, thank you. Then I'll use the version Thomas used for Debian old and
oldold stable. I'll use that as I have tested it already and it is easier
to read for someone wanting to compare the difference compared to an older
version.

Best regards

// Ola

On Mon, 4 Nov 2019 at 21:25, Sergey Poznyakoff  wrote:

> Hi Ola,
>
> > Hi Sergey
> >
> > I can see that the fix is quite different from the one Thomas proposed.
> Do
> > I understand correctly that this fix go around the problem in a different
> > way?
>
> Not quite so.  It takes basically the same approach as the fix Thomas
> proposed, but also removes unnecessary code duplication and ensures
> informative error diagnostics.
>
> > I do not see any explicit value > 0 check.
>
> See the return from the to_ascii function.
>
> > it looks like the fix allows larger file sizes
>
> No, of course all size limits remain the same,
>
> Regards,
> Sergey
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi Sergey

I can see that the fix is quite different from the one Thomas proposed. Do
I understand correctly that this fix go around the problem in a different
way? I do not see any explicit value > 0 check. Instead it looks like the
fix allows larger file sizes instead of telling that they are not ok. Is
that correct?

// Ola

On Mon, 4 Nov 2019 at 15:34, Sergey Poznyakoff  wrote:

> Hi Ola & Thomas,
>
> > I have been preparing fixes for CVE-2019-14866 for Debian oldstable
>
> Thank you.  The issue has been fixed in commit 7554e3e4 [1].
>
> Regards,
> Sergey
>
> [1]
> http://git.savannah.gnu.org/cgit/cpio.git/commit/?id=7554e3e42cd72f6f8304410c47fe6f8918e9bfd7
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi again

The new patch can be found here:
http://apt.inguza.net/wheezy-security/cpio/CVE-2019-14866.patch

It is not perfectly properly documented since it refers to a commit that do
not contain it all. But I think you get the point anyway.

// Ola

On Mon, 4 Nov 2019 at 08:10, Ola Lundqvist  wrote:

> Hi Sergey, Thomas and cpio Debian maintainers
>
> I have been preparing fixes for CVE-2019-14866 for Debian oldstable and
> oldoldstable. While doing that I realized that the patch mentioned here (1)
> do work for amd64 but do not work for i386.
> I was able to build on both amd64 and i386 but the fix obviously did not
> work on i386 since I could reproduce the problem.
>
> I think the reason for this is that a long is 32 bit on i386 while it is
> 64 bits on amd64.
>
> (1) https://lists.gnu.org/archive/html/bug-cpio/2019-08/msg3.html
>
> The fix is very simple. Change the "long" to a "long long" in
> to_out_or_error.
>
> With that correction it works when I build and test on i386.
> Please let me know what you think. I'm going to upload a fixed package to
> debian old and oldold stable tomorrow.
>
> Best regards
>
> // Ola
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi Sergey, Thomas and cpio Debian maintainers

I have been preparing fixes for CVE-2019-14866 for Debian oldstable and
oldoldstable. While doing that I realized that the patch mentioned here (1)
do work for amd64 but do not work for i386.
I was able to build on both amd64 and i386 but the fix obviously did not
work on i386 since I could reproduce the problem.

I think the reason for this is that a long is 32 bit on i386 while it is 64
bits on amd64.

(1) https://lists.gnu.org/archive/html/bug-cpio/2019-08/msg3.html

The fix is very simple. Change the "long" to a "long long" in
to_out_or_error.

With that correction it works when I build and test on i386.
Please let me know what you think. I'm going to upload a fixed package to
debian old and oldold stable tomorrow.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#932264: [Pkg-tigervnc-devel] Bug#932264: tigervnc-standalone-server: vncserver does not read config file from /etc/tigervnc

[Ola Lundqvist]

Hi

You are correct the config file is named /etc/vnc.conf
It is the same config file as for all the other vnc packages.

You mean you think it should be in /etc/tigervnc instead?

// Ola

On Wed, 17 Jul 2019 at 09:06, ButuiHu  wrote:

> Package: tigervnc-standalone-server
> Version: 1.9.0+dfsg-3
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
> LANGUAGE=zh_CN:zh (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages tigervnc-standalone-server depends on:
> ii  libaudit1   1:2.8.4-3
> ii  libbsd0 0.9.1-2
> ii  libc6   2.28-10
> ii  libfile-readbackwards-perl  1.05-2
> ii  libgcc1 1:8.3.0-6
> ii  libgcrypt20 1.8.4-5
> ii  libgl1  1.1.0-1
> ii  libgnutls30 3.6.7-4
> ii  libjpeg62-turbo 1:1.5.2-2+b1
> ii  libpam0g1.3.1-5
> ii  libpixman-1-0   0.36.0-1
> ii  libselinux1 2.8-1+b1
> ii  libstdc++6  8.3.0-6
> ii  libsystemd0 241-5
> ii  libunwind8  1.2.1-9
> ii  libx11-62:1.6.7-1
> ii  libxau6 1:1.0.8-1+b2
> ii  libxdmcp6   1:1.1.2-3
> ii  libxfont2   1:2.0.3-1
> ii  libxshmfence1   1.3-1
> ii  perl5.28.1-6
> ii  x11-xkb-utils   7.7+4
> ii  xauth   1:1.0.10-1
> ii  xkb-data2.26-2
> ii  zlib1g  1:1.2.11.dfsg-1
>
> Versions of packages tigervnc-standalone-server recommends:
> ii  libgl1-mesa-dri18.3.6-2
> ii  tigervnc-common1.9.0+dfsg-3
> ii  x11-xserver-utils  7.7+8
> ii  xfonts-base1:1.0.5
>
> Versions of packages tigervnc-standalone-server suggests:
> ii  xfonts-100dpi1:1.0.4+nmu1
> ii  xfonts-75dpi 1:1.0.4+nmu1
> ii  xfonts-scalable  1:1.0.3-1.1
>
> -- Configuration Files:
> /etc/vnc.conf changed:
> $fontPath = undef;
> $vncStartup = "/etc/X11/Xvnc-session";
> $geometry = "1900x1000";
> $localhost = "no";
> 1;
>
>
> -- no debconf information
>
> According to man vncserver, which is `/usr/bin/tigervncserver` in the
> case, the system-wide config file is
> `/etc/tigervnc/vncserver-config-defaults` and
> `/etc/tigervnc/vncserver-config-mandatory`. However, Debian actually uses
> `/etc/vnc.conf`. `man vnc.conf` tells me that `/etc/vnc.conf` is the
> system-wide config file for tigervncserver. But, it seems that it's for
> TigerVNC 1.7? According to the latest manpage from
> https://tigervnc.org/doc/vncserver.html, the upstream use `/etc/tigervnc`.
> So, did Debian patch it or modify something. `man vncserver` and `man
> vnc.conf` give me different introduction, which really make me confused.
> And usually, user might try `man vncserver` not `man vnc.conf`?
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel



-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: Bug#929410: Bug#929410: RANDR extension not present

[Ola Lundqvist]

Hi Joachim

Thank you. Thinking of this some more we actually did not have this package
at all in old stable. Did we have RANDR support in the other vnc packages?

// Ola

On Thu, 18 Jul 2019 at 22:24, Joachim Falk  wrote:

> Hi Ola,
>
> Am 30.06.19 um 19:04 schrieb Ola Lundqvist:
> > Hi
> >
> > It is too late for buster. Deadline has passed more than a week ago. If
> I had been faster maybe it had been possible.
> >
> > Maybe we can get it to a point release. Do you know how much changes
> there are between 1.9.0+dfsg-3 and the one you mentioned?
> > It seems to fall in the criteria to fix regression against current
> stable.
> should fit. Debdiff attached. There are three minor bugs fixed 929410,
> 932264, and 905905. Only code change is a
> different WM_CLASS for xtigervncviewer. Moreover, xrandr libraries are now
> enabled. Thus, additional code will be active
> in x0tigervncserver.
>
> Best,
>
> Joachim
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel



-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: Bug#929410: RANDR extension not present

[Ola Lundqvist]

Hi

It is too late for buster. Deadline has passed more than a week ago. If I
had been faster maybe it had been possible.

Maybe we can get it to a point release. Do you know how much changes there
are between 1.9.0+dfsg-3 and the one you mentioned? It seems to fall in the
criteria to fix regression against current stable.

Best regards

// Ola



// Ola

On Sat, 15 Jun 2019 at 21:12, Joachim Falk  wrote:

> Hi Ola,
>
> Am 26.05.19 um 21:54 schrieb Ola Lundqvist:
> > Hi
> >
> > Thank you for the report. I cannot reproduce the problem on Debian
> stable with version 1.7.0.
> > I do not have a system running sid right now.
>
> I could reproduce this on buster. Fix is integrated in 1.9.0+dfsg-4~RC2
> which is present
> on salsa in the master branch. Maybe you or Mike can release this so we
> might still hit the buster
> release with the bug fix.
>
> Best,
>
> Joachim
>
>

-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: RANDR extension not present

[Ola Lundqvist]

Hi

Thank you for the report. I cannot reproduce the problem on Debian stable
with version 1.7.0.

I do not have a system running sid right now.

// Ola

On Thu, 23 May 2019 at 00:51, Floris Bos  wrote:

> Package: tigervnc-scraping-server
>
> Version: 1.9.0+dfsg-3
>
>
> Seems the tigervnc package is missing randr support.
>
>
> ==
>
> $ x0tigervncserver -SecurityTypes none
>
> Wed May 22 22:20:30 2019
>   Geometry:Desktop geometry is set to 1024x768+0+0
>   XDesktop:Using evdev codemap
>
>   XDesktop:XTest extension present - version 2.2
>   XDesktop:RANDR extension not present
>   XDesktop:Will not be able to handle session resize
>   Main:Listening on port 5900
> ^C
>
> ==
>
>
> While my system/X server certainly has the RANDR extension:
>
>
> ==
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 7680 x 7680
> HDMI-1 connected primary 1024x768+0+0 (normal left inverted right x axis
> y axis) 0mm x 0mm
> 1024x768  60.00*
> 800x600   60.3256.25
> 848x480   60.00
> 640x480   59.94
>
> ==
>
>
> Think you are missing a build dependeny on the libxrandr2 library.
>
> If HAVE_XRANDR is not set at compile time, it always prints the message
> (
>
> https://github.com/TigerVNC/tigervnc/blob/master/unix/x0vncserver/XDesktop.cxx#L182
> )
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel



-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#927420: debarchiver: [INTL:pt] Update on Portuguese translation of manpage

[Ola Lundqvist]

Thank you. Will be added on next upload.

// Ola

On Fri, 19 Apr 2019 at 14:03, Américo Monteiro  wrote:

> Package: debarchiver
> Version: 0.11.3
> 3ags: l10n, patch-
> Severity: wishlist
>
> Updated Portuguese translation for  debarchiver's manpage
> Translator: Américo Monteiro 
> Feel free to use it.
>
> For translation updates please contact 'Last Translator'
>
> --
> Melhores cumprimentos/Best regards,
>
> Américo Monteiro
>
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#928112: icmpush FTCBFS: does not pass cross tools to make

[Ola Lundqvist]

Hi

Thank you. You are free to make an NMU of this if you want.

// Ola

On Sun, 28 Apr 2019 at 15:00, Helmut Grohne  wrote:

> Source: icmpush
> Version: 2.2-6.1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> icmpush fails to cross build from source, because it does not pass cross
> tools to make. The simplest way of fixing that - using dh_auto_build -
> makes icmpush cross buildable. Please consider applying the attached
> patch.
>
> Helmut
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Ola Lundqvist]

Hi again

I finally found out why I could not use xstrdup so with that fixed I run
the tests again. No crash. My guess is that the crash is some other part of
the code and not the newly introduced functions.

// Ola

On Mon, 11 Mar 2019 at 00:09, Ola Lundqvist  wrote:

> Hi Mike
>
> I have had a look at this. First of all I do not think the CVE is
> completely fixed even with the additional patch. I also do not fully
> understand how 6111-2.patch is supposed to work. More about this below.
> Let us give some example commands.
>
> [1] scp host:/foobar/a* b
> [2] scp host:a* b
> [3] scp -r host /foobar/a* b
> [4] scp -r host a* b
>
> My understanding is that only case 1 is protected by 6111-1.patch
> 6111-2.patch seems to protect against case 2.
>
> But to my understanding we do not protect against 3 and 4. Am I missing
> something?
>
> Anyway I have tried to see if I could reproduce the segfault. I do not
> know fully how you have tested it so I decided to copy the new code to a
> new test.c file and test different patterns.
> The functionality as such seems to be working fine.
>
> I did one change though to make it work. I changed xstrdup to strdup
> because I could not find link against it for some reason. Could that be
> your problem too?
>
> Essentially my test.c file looks like this:
> #include 
> #include 
> #include 
> #include 
> #include 
> #define fatal sprintf
>
> ... the new functions code here ...
>
> int testpattern(char* pattern) {
>   char **patterns = NULL;
>   size_t npatterns = 0;
>   int i = 0;
>   printf(" Test pattern %s \n", pattern);
>   brace_expand(pattern, , );
>   for (i = 0; i < npatterns; i++) {
> printf("Pattern %d: %s\n", i, patterns[i]);
>   }
> }
>
> int main(int argc, char** argv) {
>   testpattern("filea");
>   testpattern("dira/filea");
>   testpattern("dira/file{a,b}");
>   testpattern("file{a,b}");
>   testpattern("file*");
>   testpattern("file{a,b}{c,d}");
>   testpattern("file{a,b}*");
>   testpattern("dir{a,b}*/d");
>   testpattern("dir{a,b}/file*{a,b}*");
> }
>
> I could not reproduce the crash. How did you reproduce it?
>
> Best regards
>
> // Ola
>
>
> On Fri, 8 Mar 2019 at 23:41, Mike Gabriel  wrote:
>
>> Hi Colin, hi Debian LTS team,
>>
>> On  Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>>
>> > And yes, it looks OK - I'll upload it to unstable shortly.
>>
>> I have prepared a backport of this newly added patch [1] (see #923486
>> for details) to openssh in Debian jessie LTS, but with that patch
>> backported to openssh in Debian jessie, I get a segmentation fault
>> whenever I copy something using the scp cmdline tool (I have of course
>> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>>
>> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
>> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>>
>> The critical patch is CVE-2019-6111-2.patch. With that patch added I
>> get segfaults with scp. Without that patch scp works, but is
>> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>>
>> I am a bit lost here and would appreciate some ideas about what is
>> going wrong here.
>>
>> I will only be able to continue on this on Monday, but maybe someone
>> else can offer some genuine input over the weekend. Will be much
>> appreciated.
>>
>> Thanks+Greets,
>> Mike
>>
>> [1]
>>
>> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
>> --
>>
>> mike gabriel aka sunweaver (Debian Developer)
>> mobile: +49 (1520) 1976 148
>> landline: +49 (4354) 8390 139
>>
>> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
>> mail: sunwea...@debian.org, http://sunweavers.net
>>
>>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Ola Lundqvist]

Hi Mike

I have had a look at this. First of all I do not think the CVE is
completely fixed even with the additional patch. I also do not fully
understand how 6111-2.patch is supposed to work. More about this below.
Let us give some example commands.

[1] scp host:/foobar/a* b
[2] scp host:a* b
[3] scp -r host /foobar/a* b
[4] scp -r host a* b

My understanding is that only case 1 is protected by 6111-1.patch
6111-2.patch seems to protect against case 2.

But to my understanding we do not protect against 3 and 4. Am I missing
something?

Anyway I have tried to see if I could reproduce the segfault. I do not know
fully how you have tested it so I decided to copy the new code to a new
test.c file and test different patterns.
The functionality as such seems to be working fine.

I did one change though to make it work. I changed xstrdup to strdup
because I could not find link against it for some reason. Could that be
your problem too?

Essentially my test.c file looks like this:
#include 
#include 
#include 
#include 
#include 
#define fatal sprintf

... the new functions code here ...

int testpattern(char* pattern) {
  char **patterns = NULL;
  size_t npatterns = 0;
  int i = 0;
  printf(" Test pattern %s \n", pattern);
  brace_expand(pattern, , );
  for (i = 0; i < npatterns; i++) {
printf("Pattern %d: %s\n", i, patterns[i]);
  }
}

int main(int argc, char** argv) {
  testpattern("filea");
  testpattern("dira/filea");
  testpattern("dira/file{a,b}");
  testpattern("file{a,b}");
  testpattern("file*");
  testpattern("file{a,b}{c,d}");
  testpattern("file{a,b}*");
  testpattern("dir{a,b}*/d");
  testpattern("dir{a,b}/file*{a,b}*");
}

I could not reproduce the crash. How did you reproduce it?

Best regards

// Ola


On Fri, 8 Mar 2019 at 23:41, Mike Gabriel  wrote:

> Hi Colin, hi Debian LTS team,
>
> On  Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>
> > And yes, it looks OK - I'll upload it to unstable shortly.
>
> I have prepared a backport of this newly added patch [1] (see #923486
> for details) to openssh in Debian jessie LTS, but with that patch
> backported to openssh in Debian jessie, I get a segmentation fault
> whenever I copy something using the scp cmdline tool (I have of course
> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>
> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>
> The critical patch is CVE-2019-6111-2.patch. With that patch added I
> get segfaults with scp. Without that patch scp works, but is
> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>
> I am a bit lost here and would appreciate some ideas about what is
> going wrong here.
>
> I will only be able to continue on this on Monday, but maybe someone
> else can offer some genuine input over the weekend. Will be much
> appreciated.
>
> Thanks+Greets,
> Mike
>
> [1]
>
> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#922193: debarchiver: [INTL:fr] French program translation update

[Ola Lundqvist]

Thank you

// Ola
-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#921663: Please add python-certbot update to jessie-backports

[Ola Lundqvist]

Hi

Yes I have also been thinking that it would be possible to provide them in
a separate repository.

Best regards

// Ola

On Sun, 10 Feb 2019 at 15:40, Holger Levsen  wrote:

> Hi Ola & Brad,
>
> thank you for your quick feedback!
>
> On Sat, Feb 09, 2019 at 09:27:53PM +0100, Ola Lundqvist wrote:
> > Here is a little more extensive list of dependencies:
> >
> > python-certbot (of course as it is the one providing certbot)
> > python3-acme (>= 0.26.0~) - not in jessie, available in backports
> > python3-configargparse - not in jessie, available in backports
> > python3-cryptography (>= 1.2) - update needed (affecting something
> else?),
> > available in backports
> > python3-josepy - not in jessie
> > python3-rfc3339 - not in jessie, available in backports
> > python3-sphinx (>= 1.6) - update needed (affecting something else?)
> > python-certbot-nginx
> > python-certbot-apache
> >
> > python-certbot-nginx and python-certbot-apache do not seem to add any
> > additional dependencies that are not already in jessie.
> >
> > I have not checked if any of the above packages require further
> > dependencies so the list may grow larger.
>
> I think this list is too large, also just python3-cryptography has too
> many rdepends to make me comfortable updating it (and I havent looked
> at the other packages at all), so I think we should stop here (for
> jessie LTS).
>
> What however could be done, is to provide these updates in another repo
> outside of jessie LTS...
>
>
> --
> tschau,
> Holger
>
>
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#921663: Please add python-certbot update to jessie-backports

[Ola Lundqvist]

Hi

Here are the reverse dependencies for that.

(jessie_chroot)root@tigereye:~/build/certbot/python-certbot-0.28.0#
apt-rdepends -r python3-cryptography
Reading package lists... Done
Building dependency tree
Reading state information... Done
python3-cryptography
  Reverse Depends: python3-openssl (0.14-1)
python3-openssl
  Reverse Depends: python3-service-identity (1.0.0-3)
python3-service-identity

Does not look like much.

// Ola

On Sat, 9 Feb 2019 at 23:20, Brad Warren  wrote:

> Thanks for looking into that Ola.
>
> I think we could work around the python3-sphinx problem. It’s just used
> for building the docs and python3-sphinx (>= 1.6) is not in Stretch despite
> the Certbot package being updated there. It seems to me like something
> similar could be done here.
>
> python3-cryptography certainly might be a problem though.
>
> > On Feb 9, 2019, at 12:27 PM, Ola Lundqvist  wrote:
> >
> > Hi Holger and Brad
> >
> > Here is a little more extensive list of dependencies:
> >
> > python-certbot (of course as it is the one providing certbot)
> > python3-acme (>= 0.26.0~) - not in jessie, available in backports
> > python3-configargparse - not in jessie, available in backports
> > python3-cryptography (>= 1.2) - update needed (affecting something
> else?), available in backports
> > python3-josepy - not in jessie
> > python3-rfc3339 - not in jessie, available in backports
> > python3-sphinx (>= 1.6) - update needed (affecting something else?)
> > python-certbot-nginx
> > python-certbot-apache
> >
> > python-certbot-nginx and python-certbot-apache do not seem to add any
> additional dependencies that are not already in jessie.
> >
> > I have not checked if any of the above packages require further
> dependencies so the list may grow larger.
> >
> > Best regards
> >
> > // Ola
> >
> > On Sat, 9 Feb 2019 at 20:58, Brad Warren  wrote:
> >
> >
> > > On Feb 9, 2019, at 6:19 AM, Holger Levsen 
> wrote:
> > >
> > > On Sat, Feb 09, 2019 at 02:54:43PM +0100, Ola Lundqvist wrote:
> > >> I can also add that I have looked into this for myself and the number
> of
> > >> needed dependencies is rather large. So it is not just certbot that
> need an
> > >> update, we also need to include quite a few other packages too.
> > >
> > > how large exactly?
> > >
> > All of:
> >
> > - python-acme
> > - python-certbot
> > - python-certbot-apache
> > - python-certbot-nginx
> > - python-josepy
> >
> > would need to be added/updated like they were in Stretch. (The new
> python-josepy package comes from it being split out of python-acme.)
> >
> > We have spent a lot of time upstream keeping compatibility with older
> versions of our dependencies and not adding new dependencies with the goal
> of making situations like this easier.
> >
> > With that said, these Debian packages have switched from Python 2 to
> Python 3 since the last time they were updated in jessie-backports. The
> switch to Python 3 would either need to be undone (as we have kept
> compatibility with Python 2 upstream) or Python 3 versions of some of our
> dependencies would need to be added. I am not sure how many packages would
> be affected if the latter approach was taken.
> >
> > >
> > > --
> > > tschau,
> > >   Holger
> > >
> > >
> ---
> > >   holger@(debian|reproducible-builds|layer-acht).org
> > >   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A
> AA1C
> >
> >
> >
> > --
> >  --- Inguza Technology AB --- MSc in Information Technology 
> > /  o...@inguza.comFolkebogatan 26\
> > |  o...@debian.org   654 68 KARLSTAD|
> > |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> > \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
> >  ---
> >
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#921663: Please add python-certbot update to jessie-backports

[Ola Lundqvist]

Hi Holger and Brad

Here is a little more extensive list of dependencies:

python-certbot (of course as it is the one providing certbot)
python3-acme (>= 0.26.0~) - not in jessie, available in backports
python3-configargparse - not in jessie, available in backports
python3-cryptography (>= 1.2) - update needed (affecting something else?),
available in backports
python3-josepy - not in jessie
python3-rfc3339 - not in jessie, available in backports
python3-sphinx (>= 1.6) - update needed (affecting something else?)
python-certbot-nginx
python-certbot-apache

python-certbot-nginx and python-certbot-apache do not seem to add any
additional dependencies that are not already in jessie.

I have not checked if any of the above packages require further
dependencies so the list may grow larger.

Best regards

// Ola

On Sat, 9 Feb 2019 at 20:58, Brad Warren  wrote:

>
>
> > On Feb 9, 2019, at 6:19 AM, Holger Levsen  wrote:
> >
> > On Sat, Feb 09, 2019 at 02:54:43PM +0100, Ola Lundqvist wrote:
> >> I can also add that I have looked into this for myself and the number of
> >> needed dependencies is rather large. So it is not just certbot that
> need an
> >> update, we also need to include quite a few other packages too.
> >
> > how large exactly?
> >
> All of:
>
> - python-acme
> - python-certbot
> - python-certbot-apache
> - python-certbot-nginx
> - python-josepy
>
> would need to be added/updated like they were in Stretch. (The new
> python-josepy package comes from it being split out of python-acme.)
>
> We have spent a lot of time upstream keeping compatibility with older
> versions of our dependencies and not adding new dependencies with the goal
> of making situations like this easier.
>
> With that said, these Debian packages have switched from Python 2 to
> Python 3 since the last time they were updated in jessie-backports. The
> switch to Python 3 would either need to be undone (as we have kept
> compatibility with Python 2 upstream) or Python 3 versions of some of our
> dependencies would need to be added. I am not sure how many packages would
> be affected if the latter approach was taken.
>
> >
> > --
> > tschau,
> >   Holger
> >
> >
> ---
> >   holger@(debian|reproducible-builds|layer-acht).org
> >   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#921663: Please add python-certbot update to jessie-backports

[Ola Lundqvist]

Hi

I can also add that I have looked into this for myself and the number of
needed dependencies is rather large. So it is not just certbot that need an
update, we also need to include quite a few other packages too.

// Ola

On Sat, 9 Feb 2019 at 09:37, Ian Campbell  wrote:

> [[ Resending to correct debian-lts, I forgot the "lists." bit... ]]
>
> On Fri, 2019-02-08 at 11:18 -0800, Brad Warren wrote:
> > To provide a little more information as an upstream maintainer of
> > Certbot, the lack of an upgrade here will affect a lot of Debian
> > Jessie users.
> >
> > Let’s Encrypt started sending out multiple emails telling affected
> > users they needed to upgrade their client or they will become unable
> > to renew their certificates 3 weeks ago. Looking at server side data
> > from the past week on how many Jessie users continue to rely on these
> > soon to be broken packages, I estimate it is 20,000 users maintaining
> > 37,000 certificates for 64,000 domains.
> >
> > Is there really nothing that can be done here? Is it possible to make
> > an exception to Debian’s normal policy to prevent TLS configurations
> > from breaking on tens of thousands of websites?
>
> There is no need for an exception, jessie-backports is not the right
> place to be fixing this issue even if it were still open. It should be
> fixed by an update to either Jessie itself of the security suite.
>
> Jessie(-security) is currently maintained (until June 2020) by the LTS
> team[0], who I've cc-d here.
>
> There was a similar thread on the backports list which ended with [1]
> but I don't know if this ever formally came to the LTS team.
>
> Ian (not involved with LTS nor backports nor letsencrypt team).
>
> [0] https://wiki.debian.org/LTS/
> [1] https://lists.debian.org/debian-backports/2019/01/msg00052.html
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors

[Ola Lundqvist]

Hi

The control file was written by me so it is not blocking.

I fail to see how changelog entries block anything.

So I guess it is ok.

/ Ola

Sent from a phone

Den lör 2 feb. 2019 00:46 skrev Nicholas D Steeves :

> Dear Ola, Pontus, and Debian Legal team,
>
> It seems Thierry is MIA, and will not be confirming permission to
> relicense his contributions to d/changelog and d/control.  Please let
> me know if the following blocks moving to GPL-3+ debian/* and a
> machine-readable format: 1.0 debian/copyright.  At this point I
> suspect it does, but I am erring on the side of caution.
>
> On Mon, Jul 30, 2018 at 05:46:27PM +0200, pon...@ullgren.com wrote:
> >This is acceptable by me.
> >// Pontus
> >
> >  > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves
> wrote:
> >  >> Package: php-elisp
> >  >> Version: 1.13.5-3
> >  >> Severity: normal
> >  >>
> >  >> Dear Ola, Moritz, Thierry, and Pontus,
> >  >>
> >  >> The Debian Emacsen team is adopting php-elisp.Ã*Â  At this time
> we
> >  would
> >  >> like to move to machine-readable copyright format 1.0 and
> harmonise
> >  >> update the copyright of debian/* to GPL-3+, which upstream has
> >  >> migrated to.
> >  >>
> >  >> Please reply to this bug to confirm that you consent to GPL-3+
> >  >> relicensing of your past contributions.
> >
> >  Php-elisp is ready to upload. Would you please confirm if GPL-3+ is
> >  an acceptable license for your contributions to this package?
>
> d/copyright:
>
>   This package was debianized by Ola Lundqvist  on
>   Mon, 26 Feb 2001 21:33:20 +0100.
>   New co-maintainer since Thu, 14 Aug 2003 18:30:27 +0200 is
>   Pontus Ullgren .
>
>   It was downloaded from:
>   https://github.com/ejmr/php-mode
>
>   Copyright:
>  Copyright (C) 1999, 2000, 2001, 2003, 2004 Turadg Aleahmad
>2008 Aaron S. Hawley
>2011, 2012, 2013, 2014 Eric James Michael Ritz
>
>   License:
>
>   This program is free software; you can redistribute it and/or
>   modify it under the terms of the GNU General Public License
>   as published by the Free Software Foundation; either version 2
>   of the License, or (at your option) any later version.
>
>
> d/changelog:
> ...
> php-elisp (1.5.0-1.1) unstable; urgency=low
>
>   * Non-maintainer upload.
>   * Prevent byte compilation on xemacs21, since it's incompatible
> (Closes: #584698)
>
>  -- Moritz Muehlenhoff   Thu, 05 Aug 2010 16:37:37 -0400
>
> php-elisp (1.5.0-1) unstable; urgency=low
>
>   * New upstream release (Closes: #368061, #291207)
>   * New maintainer (Closes: #525947)
>   * debian/control:
> + bumped Standards-Version to 3.8.4
> + added ${misc:Depends} in Depends
> + updated Depends to emacs23 | emacs22 | emacsen
> + updated Suggests to php5 | php5-cli
> + updated Section to lisp
> + added in Recommends field speedbar (Closes: #500120)
> + used debhelper 7
> + added Homepage field
> + added texi2html in Build-Depends to generate manual (Closes: #476197)
>   * debian/rules:
> + removed emacs21 references (Closes: #269650)
> + used binary-indep instead of binary-arch target
>   * debian/copyright
> + added copyright notice
>   * Added compat, docs, watch files
>   * switched to dpkg-source 3.0 (quilt) format
>
>  -- Thierry Randrianiriana   Sun, 09 May 2010
> 09:00:55 +0300
>
> php-elisp (1.4.0-3) unstable; urgency=low
>
>
> Thanks!
> Nicholas
>

Bug#323615: Propose to NMU debarchiver

[Ola Lundqvist]

Hi

Now I have also uploaded 0.11.3. For some reason the last upload failed.

// Ola

On Fri, 4 Jan 2019 at 19:36, Helge Kreutzmann  wrote:

> Hello Ola,
> On Fri, Dec 28, 2018 at 10:06:34PM +0100, Ola Lundqvist wrote:
> > Uploading a new version now.
>
> Thanks. You are referring to 0.11.2?
>
> > // Ola
> >
> > On Wed, 19 Dec 2018 at 17:38, Helge Kreutzmann 
> wrote:
> >
> > > To: Colin Watson 
> > > Cc: 575...@bugs.debian.org
> > > User-Agent: Mutt/1.5.23 (2014-03-12)
> > >
> > > Hello Ola,
> > > I propose to NMU icoutils to solve the long standing translation bugs
> > > 858851, 863618 and the request for examples (which you acked some 13
> > > years ago).
>
> 858851 is not changed / fixed. 863618 most likely not (the file date
> is too old). And did you consider 323615?
>
> > > I would prefer if you could add this to your next MU (before the
> > > freeze), but if I don't hear from you I would upload this NMU
> > > early January.
> > >
> > > If you have any questions do not hesitate to ask.
>
> If you need I can help you with an updated package, e.g. provide you
> with an updated version where you basically just need to upload it.
> (Or, if your at salsa, I could put it in your VCS, or send you the
> updated files directly, … whatever suits you best).
>
> Thanks!
>
> Greetings
>
>Helge
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>    Dipl.-Phys.
> http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#917904: tightvncserver does not ask for password set by vncpasswd

[Ola Lundqvist]

Hi

You should have a log file in ~/.vnc

I think the following configuration files are worth saving and checking:
/etc/vnc.conf
~/.vncrc
/etc/X11/xorg.conf (should only be for font stuff though)

I think the $authType is of most importance. It should be
$authType = "-rfbauth $vncUserDir/passwd";

Also an output of "ps xa" can help as you will then know if -rfbauth hass
been added to the Xtightvncserver command or not run by tightvncserver
script.

// Ola

On Wed, 2 Jan 2019 at 15:46, Christoph Terasa  wrote:

> Hi Ola,
>
> thank you for your answer. I checked:
>
> $ ls -l /etc/alternatives/vnc*
> lrwxrwxrwx 1 root root 24 Jul 27  2017 /etc/alternatives/vncconnect ->
> /usr/bin/tightvncconnect
> lrwxrwxrwx 1 root root 40 Jul 27  2017 /etc/alternatives/vncconnect.1.gz
> -> /usr/share/man/man1/tightvncconnect.1.gz
> lrwxrwxrwx 1 root root 23 Jul 27  2017 /etc/alternatives/vncpasswd ->
> /usr/bin/tightvncpasswd
> lrwxrwxrwx 1 root root 39 Jul 27  2017 /etc/alternatives/vncpasswd.1.gz ->
> /usr/share/man/man1/tightvncpasswd.1.gz
> lrwxrwxrwx 1 root root 23 Jul 27  2017 /etc/alternatives/vncserver ->
> /usr/bin/tightvncserver
> lrwxrwxrwx 1 root root 39 Jul 27  2017 /etc/alternatives/vncserver.1.gz ->
> /usr/share/man/man1/tightvncserver.1.gz
>
>
> Before I will purge my configuration as well, I would try to keep my
> system in its current state. Is there are way to get more debugging info
> from tightvncserver, or a log file? The man page does not seem to mention
> anything in that regard.
>
>
> kind regards,
> Christoph
>
>
> On 1/2/19 1:26 AM, Ola Lundqvist wrote:
>
> Hi Jan
>
> Thank you for the report.
> I have now tested this myself. I purged all vnc software installed,
> installed tightvncserver, run tightvncserver and then run vncpasswd to set
> a password.
> I failed to reproduce the problem. I'm asked for a password.
>
> So the question is what you did differently. Can it be so that you have
> some other vncpasswd software as an alternative and that happen to not be
> updating the same things?
>
> Best regards
>
> // Ola
>
> On Mon, 31 Dec 2018 at 15:33, Jan Christoph Terasa 
> wrote:
>
>> Package: tightvncserver
>> Version: 1:1.3.9-9
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>>
>> Dear Maintainer,
>>
>> I installed tightvncserver on my VPS machine via apt. This did set up
>> tightvncserver as an alternative for vncserver. Using a normal user
>> account and
>> starting vncserver for the first time asks for a 8-letter password. My
>> assumption
>> is this password will be used to authenticate users when connecting to
>> the vnc
>> server.
>>
>> After starting the vnc server via vncserver script, it is served on port
>> 5901.
>> On the client machine I use vinagre to connect to the server on port
>> 5901. When
>> connecting, I am not asked for a password, but rather directly taken to
>> the X
>> session. I would have expected the server to ask for the password I
>> specified
>> earlier.
>>
>> As a workaround, to ensure the integrity of the system, I set up iptable
>> rules to
>> not allow direct WAN connections to this port, but only allow local
>> connections
>> and use an SSH tunnel for connecting to the vnc server.
>>
>>
>> kind regards,
>> Christoph
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers oldstable-updates
>>   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
>> 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.14.17--std-ipv6-64 (SMP w/2 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages tightvncserver depends on:
>> ii  libc62.27-8
>> ii  libjpeg62-turbo  1:1.5.2-2+b1
>> ii  libx11-6 2:1.6.7-1
>> ii  libxext6 2:1.3.3-1+b2
>> ii  perl 5.28.0-3
>> ii  x11-common   1:7.7+19
>> ii  x11-utils7.7+4
>> ii  xauth1:1.0.10-1
>> ii  xserver-common   2:1.20.3-1
>> ii  zlib1g   1:1.2.11.dfsg-1
>>
>> Versions of packages tightvncserver recommends:
>> ii  x11-xserver-utils  7.7+8
>> ii  xfonts-base1:1.0.4+nmu1
>>
>> Versions of packages tightvncserver suggests:
>> pn  tightvnc-java  
>>
>> -- no debconf information
>>
>
>
> --
>  -

Bug#917904: tightvncserver does not ask for password set by vncpasswd

[Ola Lundqvist]

Hi Jan

Thank you for the report.
I have now tested this myself. I purged all vnc software installed,
installed tightvncserver, run tightvncserver and then run vncpasswd to set
a password.
I failed to reproduce the problem. I'm asked for a password.

So the question is what you did differently. Can it be so that you have
some other vncpasswd software as an alternative and that happen to not be
updating the same things?

Best regards

// Ola

On Mon, 31 Dec 2018 at 15:33, Jan Christoph Terasa 
wrote:

> Package: tightvncserver
> Version: 1:1.3.9-9
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> I installed tightvncserver on my VPS machine via apt. This did set up
> tightvncserver as an alternative for vncserver. Using a normal user
> account and
> starting vncserver for the first time asks for a 8-letter password. My
> assumption
> is this password will be used to authenticate users when connecting to the
> vnc
> server.
>
> After starting the vnc server via vncserver script, it is served on port
> 5901.
> On the client machine I use vinagre to connect to the server on port 5901.
> When
> connecting, I am not asked for a password, but rather directly taken to
> the X
> session. I would have expected the server to ask for the password I
> specified
> earlier.
>
> As a workaround, to ensure the integrity of the system, I set up iptable
> rules to
> not allow direct WAN connections to this port, but only allow local
> connections
> and use an SSH tunnel for connecting to the vnc server.
>
>
> kind regards,
> Christoph
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
> 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.17--std-ipv6-64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages tightvncserver depends on:
> ii  libc62.27-8
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libx11-6 2:1.6.7-1
> ii  libxext6 2:1.3.3-1+b2
> ii  perl 5.28.0-3
> ii  x11-common   1:7.7+19
> ii  x11-utils7.7+4
> ii  xauth1:1.0.10-1
> ii  xserver-common   2:1.20.3-1
> ii  zlib1g   1:1.2.11.dfsg-1
>
> Versions of packages tightvncserver recommends:
> ii  x11-xserver-utils  7.7+8
> ii  xfonts-base1:1.0.4+nmu1
>
> Versions of packages tightvncserver suggests:
> pn  tightvnc-java  
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#902633: Any progress?

[Ola Lundqvist]

Hi

If the package is renamed we need to do the following:
- Wait for FTP masters to accept the new package
- Upload a new php-mode package as a transitional package, meaning it do
not provide anything useful more than removing old stuff from itself and
depending on the new package including potentially some more stuff.

The new package should probably not provide php-mode. Maybe conflict with
it.

// Ola

On Sat, 29 Dec 2018 at 13:40, Nicholas D Steeves  wrote:

> Replying from my phone.  The work is done, just waiting for copyright
> confirmation of debian/*.  With the new upstream, conversion to dh-elpa
> (total repackaging minus the changelog), etc. I wonder if it might be
> necessary to upload as src:php-mode.  Bin:elpa-org-mode provides
> bin:php-elisp in any case.
>
> Please ping me in a week :-)
>
> On Wed, Dec 26, 2018, 05:45 Eugen Dedu 
>> Hi everybody,
>>
>> Nicholas, is there any progress on updating this package?
>>
>> Also, any progress on "Clarify a point in README.md wrt PSR-5 status and
>> PSR-7 status" https://github.com/ejmr/php-mode/issues/473 ?  Is it so
>> important to delay the packaging of the latest release?
>>
>> Ola, is there any svn of git repository for the Debian files of the
>> package?  I do not see it at
>> https://packages.qa.debian.org/p/php-elisp.html.  Or the latest version
>> is in the package itself?
>>
>> Note that someone else took over the software, Kenta Usami,
>> https://github.com/emacs-php/php-mode.
>>
>> I would like to work on this a few hours, hopefully today.  I do not
>> plan to take over this package, just package the latest release of the
>> software.  I am Debian maintainer, and maintained for a few years ekiga,
>> ptlib, and opal.  I could send to Ola a few patches to solve this.
>>
>> Regards,
>> --
>> Eugen Dedu
>> Associate Professor / Maître de conférences HDR
>> OMNI team leader
>> FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS
>> Montbéliard, France
>> tel. +33 3 81 99 47 75
>> http://eugen.dedu.free.fr
>>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#323615: Propose to NMU debarchiver

[Ola Lundqvist]

Hi

Uploading a new version now.

// Ola

On Wed, 19 Dec 2018 at 17:38, Helge Kreutzmann  wrote:

> To: Colin Watson 
> Cc: 575...@bugs.debian.org
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> Hello Ola,
> I propose to NMU icoutils to solve the long standing translation bugs
> 858851, 863618 and the request for examples (which you acked some 13
> years ago).
>
> I would prefer if you could add this to your next MU (before the
> freeze), but if I don't hear from you I would upload this NMU
> early January.
>
> If you have any questions do not hesitate to ask.
>
> Greetings
>
>Helge
>
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.
> http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#902633: Any progress?

[Ola Lundqvist]

Hi

No svn or git repo.

/ Ola

Sent from a phone

Den ons 26 dec. 2018 15:18Kenta Usami  skrev:

> Hi Eugen and everybody.
>
> My name is Kenta, I'm currently maintainer of PHP Mode and Emacs-PHP.
>
> I plan to change PHP Mode in the future, but I think that the current
> version can be distributed as a stable version.
> I do not know which version of Debian will be offered, but it will
> probably be helpful to many users.
>
> Thank you.
>
> 2018年12月26日(水) 21:33 Eugen Dedu :
>
>> Hi everybody,
>>
>> Nicholas, is there any progress on updating this package?
>>
>> Also, any progress on "Clarify a point in README.md wrt PSR-5 status and
>> PSR-7 status" https://github.com/ejmr/php-mode/issues/473 ?  Is it so
>> important to delay the packaging of the latest release?
>>
>> Ola, is there any svn of git repository for the Debian files of the
>> package?  I do not see it at
>> https://packages.qa.debian.org/p/php-elisp.html.  Or the latest version
>> is in the package itself?
>>
>> Note that someone else took over the software, Kenta Usami,
>> https://github.com/emacs-php/php-mode.
>>
>> I would like to work on this a few hours, hopefully today.  I do not
>> plan to take over this package, just package the latest release of the
>> software.  I am Debian maintainer, and maintained for a few years ekiga,
>> ptlib, and opal.  I could send to Ola a few patches to solve this.
>>
>> Regards,
>> --
>> Eugen Dedu
>> Associate Professor / Maître de conférences HDR
>> OMNI team leader
>> FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS
>> Montbéliard, France
>> tel. +33 3 81 99 47 75
>> http://eugen.dedu.free.fr
>>
>
>
> --
> ヾ(〃＞＜)ﾉﾞ☆ Kenta Usami (宇佐美健太)
> github.com/zonuexe ; https://tadsan.github.io/
>

Bug#895743: php-elisp package too old

[Ola Lundqvist]

Hi

I thought I had already filed an RFA for this package.

You are most welcome to take it over.

I have too little time to spend on this unfortunately.

But I should really try as the release is closing.

If you have the possibility to take it over I would be grateful.

/ Ola

Sent from a phone

Den sön 23 dec. 2018 10:45Eugen Dedu  skrev:

> Hi Ola,
>
> I use PHP within Emacs.  As far as I know, php-mode (php-elisp) is the
> only Emacs package to provide a PHP mode.  The current version of
> php-elisp in Debian does not even start in Emacs (I use 26.1).  This
> means that currently Emacs in Debian does not support PHP language.
>
> Would it be possible to update the php-elisp package in Debian?
>
> Alternatively, package another recent package providing PHP mode?
>
> Finally, if you do not have time to maintain this Debian package, can
> you orphan it or fill an RFA, cf. https://wiki.debian.org/Orphaning?
>
> Best regards,
> --
> Eugen Dedu
> Associate Professor / Maître de conférences HDR
> OMNI team leader
> FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS
> Montbéliard, France
> tel. +33 3 81 99 47 75
> http://eugen.dedu.free.fr
>

Bug#323615: Propose to NMU debarchiver

[Ola Lundqvist]

Hi Helge

A check question here. Are you really referring to icoutils here? Not
debarchiver?

If you have a patch file, please send it to me and I'll release an updated
version with the examples section included.

Best regards

// Ola

On Wed, 19 Dec 2018 at 17:42, Helge Kreutzmann  wrote:

> To: Colin Watson 
> Cc: 575...@bugs.debian.org
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> Hello Ola,
> I propose to NMU icoutils to solve the long standing translation bugs
> 858851, 863618 and the request for examples (which you acked some 13
> years ago).
>
> I would prefer if you could add this to your next MU (before the
> freeze), but if I don't hear from you I would upload this NMU
> early January.
>
> If you have any questions do not hesitate to ask.
>
> Greetings
>
>Helge
>
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.
> http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#827827: ERROR: php-elisp is broken - called emacs-package-install as a new-style add-on, but has no compat file.

[Ola Lundqvist]

Thanks, I'll check it out.

On Wed, 31 Oct 2018 at 16:46, Antoine Beaupre 
wrote:

> On Fri, Jul 29, 2016 at 07:42:00AM +0200, Ola Lundqvist wrote:
> > Hi
> >
> > Sorry for the delayed answer. I tried to reproduce your problem myself
> but
> > failed.
> >
> > What was your from version?
> >
> > Are you running sid or what version of debian in general?
>
> This is reproducible right now in Debian Buster.
>
> $ sudo apt install php-elisp
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état... Fait
> Paquets suggérés :
>   php5 php5-cli
> Paquets recommandés :
>   speedbar
> Les NOUVEAUX paquets suivants seront installés :
>   php-elisp
> 0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
> Il est nécessaire de prendre 26,7 ko dans les archives.
> Après cette opération, 150 ko d'espace disque supplémentaires seront
> utilisés.
> Réception de:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64
> php-elisp all 1.13.5-3 [26,7 kB]
> 26,7 ko réceptionnés en 1s (52,9 ko/s)
> [master baf904a] saving uncommitted changes in /etc prior to apt run
>  Author: Antoine Beaupré 
>  2 files changed, 70 deletions(-)
>  delete mode 100644 libvirt/qemu/stretch64_default.xml
> Récupération des rapports de bogue… Fait
> Analyse des informations Trouvé/Corrigé… Fait
> Sélection du paquet php-elisp précédemment désélectionné.
> (Lecture de la base de données... 616958 fichiers et répertoires déjà
> installés.)
> Préparation du dépaquetage de .../php-elisp_1.13.5-3_all.deb ...
> Dépaquetage de php-elisp (1.13.5-3) ...
> Paramétrage de php-elisp (1.13.5-3) ...
> ERROR: php-elisp is broken - called emacs-package-install as a new-style
> add-on, but has no compat file.
> Install php-elisp for emacs
> Install php-elisp for emacs
>

Bug#695524: jpeginfo: 1.6.1 is out

[Ola Lundqvist]

Hi

I should probably orphan this package. I do not really have the time to
properly maintain it. If you want you are free to take it over.

Best regards

// Ola

On Fri, 26 Oct 2018 at 08:51, Mathieu Malaterre  wrote:

> ping ?
>
> On Tue, Aug 23, 2016 at 9:18 AM Mathieu Malaterre 
> wrote:
> >
> > ...while at it, it would be nice to populate d/control: Homepage
> > infomation as well as a d/watch file.
> >
> > See package src:jpegoptim in case this helps.
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#905905: [Pkg-tigervnc-devel] Bug#905905: [tigervnc-viewer] Missing .desktop file and icon

[Ola Lundqvist]

severity 905905 wishlist
thanks

Hi

Thank you for the report and workaround. We will see what we can do about
this.

We need to adjust your workaround a little. For example the command should
be tigervncviewer instead of vncviewer. The rest looks ok to me.
We also need to install and remove and so on, but that is quite obvious I
guess (and no sudo needed in our case).

In any case, very good to know what we need to do about this.

// Ola

On 11 August 2018 at 14:54, Robert Braumann  wrote:

> Package: tigervnc-viewer
> Version: 1.9.0+dfsg-1
> Severity: normal
>
> --- Please enter the report below this line. ---
> After installing tigervnc-viewer, there is no .desktop file for it under
> "/usr/share/applications".
> Please add a .desktop file with a proper .svg icon for being able to
> comfortable launch the TigerVNC Viewer from the DE.
>
> Workaround:
> Generate the File "tigervncviewer.desktop" with the content shown below,
> and install it with the command
> sudo desktop-file-install tigervncviewer.desktop
>
> tigervncviewer.desktop content:
> ==
> [Desktop Entry]
> Name=TigerVNC Viewer
> Exec=vncviewer
> Icon=tigervnc
> Terminal=false
> Type=Application
> Categories=Network;
>
>
>
> Regards,
> Robert
>
> --- System information. ---
> Architecture:
> Kernel:   Linux 4.17.0-1-amd64
>
> Debian Release: buster/sid
>   990 testing ftp.at.debian.org
>   500 unstableftp.at.debian.org
>   500 stable  packages.microsoft.com
>
> --- Package information. ---
> Depends   (Version) | Installed
> ===-+-==
> libc6 (>= 2.15) |
> libfltk-images1.3(>= 1.3.3) |
> libfltk1.3   (>= 1.3.4) |
> libfontconfig1  (>= 2.12.6) |
> libgcc1  (>= 1:3.0) |
> libgnutls30  (>= 3.5.6) |
> libjpeg62-turbo  (>= 1.3.1) |
> libpam0g  (>= 0.99.7.1) |
> libstdc++6   (>= 5) |
> libx11-6|
> libxcursor1  (>> 1.1.2) |
> libxext6|
> libxfixes3  |
> libxft2  (>> 2.1.1) |
> libxinerama1|
> libxrender1 |
> zlib1g (>= 1:1.1.4) |
>
>
> Package's Recommends field is empty.
>
> Suggests (Version) | Installed
> ==-+-===
> tigervnc-common        |
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-tigervnc-devel
>



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#905801: wwwconfig-common: script directly accesses internal dpkg database

[Ola Lundqvist]

Hi

Thank you for the report. I have checked the archives and it looks like it
is just one package that actually use wwwconfig-common and then not this
script. This is a good thing because then I may finally be able to remove
this package altogether.

// Ola

On 10 August 2018 at 01:41, Guillem Jover  wrote:

> Source: wwwconfig-common
> Source-Version: 0.3.0
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker
>
> Hi!
>
> This package contains a script that directly accesses the dpkg
> internal database [S], instead of using the correct public interface
> such as «dpkg-query --showformat '${db:Status-Status} ${Package}\n'
> --show 'php?.?-*'|grep '^installed '» (also notice that the current
> glob will not match current php packages in the archive with N.M
> versioning, although perhaps the code should instead be dropped?).
>
>   [S] php-extensions.sh
>
> This a problem for multiple reasons. Even though the layout and format
> of the dpkg database is administrator friendly, and it's expected that
> those might need to mess with it, in case of emergency, this interface
> does not extend to other programs besides the dpkg suite of tools. The
> admindir can also be configured differently at dpkg build or run-time.
> And finally, the contents and its format, will be changing in the near
> future.
>
> Thanks,
> Guillem
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#902633: ITA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Hi

What issue are you referring to? This issue is about who should maintain
the package. I guess it is not the problem youbran into.

/ Ola

Sent from a phone

Den mån 16 juli 2018 01:12Nicholas D Steeves  skrev:

> Hi Ola,
>
> On Fri, Jul 06, 2018 at 09:44:19AM +0200, Ola Lundqvist wrote:
> >Thank you! Let me know when/if you need any help.
> >
> >Sent from a phone
> >Den fre 6 juli 2018 02:57Nicholas D Steeves 
> skrev:
> >
>
> Are you able to respond to this issue?  I ran into it while updating
> the long description's definition of this package's capabilities.
>
> "Clarify a point in README.md wrt PSR-5 status and PSR-7 status"
> https://github.com/ejmr/php-mode/issues/473
>
> Thanks,
> Nicholas
>

Bug#903092: permission to relicense php-mode/debian/* required for past contributors

[Ola Lundqvist]

Confirmed!

Sent from a phone

Den fre 6 juli 2018 08:51Moritz Mühlenhoff  skrev:

> On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote:
> > Package: php-elisp
> > Version: 1.13.5-3
> > Severity: normal
> >
> > Dear Ola, Moritz, Thierry, and Pontus,
> >
> > The Debian Emacsen team is adopting php-elisp.  At this time we would
> > like to move to machine-readable copyright format 1.0 and harmonise
> > update the copyright of debian/* to GPL-3+, which upstream has
> > migrated to.
> >
> > Please reply to this bug to confirm that you consent to GPL-3+
> > relicensing of your past contributions.
>
> Confirmed!
>
> Cheers,
> Moritz
>

Bug#902633: ITA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Thank you! Let me know when/if you need any help.

Sent from a phone

Den fre 6 juli 2018 02:57Nicholas D Steeves  skrev:

> Control: owner -1 !
> Control: retitle -1 ITA: php-elisp -- php mode for emacs
>
> On Mon, Jul 02, 2018 at 10:08:07PM +0200, Ola Lundqvist wrote:
> >Hi
> >With this I say I can still be co maintainer.
> >/ Ola
> >Sent from a phone
> >Den mån 2 juli 2018 22:07Ola Lundqvist 
> skrev:
> >
> >  Hi
> >  I still use it so I can do some limited tests if necessary.
> >  But I only use stable so it must be installable on stable in that
> case.
> >  Sounds ok?
>
> Sounds like a plan, I'll adopt the package under Emacsen Team
> maintenance.
>
> Yes, the vast majority of elpafied arch:all packages are installable
> on stretch, and of course testing with emacs25 would be more valuable
> than emacs24 ;-)
>
> Cheers,
> Nicholas
>

Bug#839787: php-elisp: Pleae add URL to package description debian/control

[Ola Lundqvist]

Sounds like a good plan to me.

I do not think renaming the source package matters much. Do as you usually
do or as you think is best.

/ Ola

Sent from a phone

Den fre 6 juli 2018 03:21Nicholas D Steeves  skrev:

> Hi Jari,
>
> On Wed, Oct 05, 2016 at 12:42:10AM +0300, Jari Aalto wrote:
> > Package: php-elisp
> > Version: 1.13.5-3
> > Severity: minor
> >
> > When listing the package desction with apt-cache show it would be
> > helpful to let reader know which PHP Emacs package is in question.
> > (There are few PHP modes for Emacs in Emacs wiki).
> >
> > Please include URL to upstream in the debian/control::Description
> >
> >http://php-mode.sf.net
> >
> > Jari
>
> The Debian Emacsen team is adopting php-elisp.  We plan to convert the
> package to use dh-elpa; php-elisp will become a dummy transitional
> package, and elpa-php-mode will contain everything else.  All elpafied
> packages' names must correspond to their equivalent GNU ELPA and/or
> MELPA distributed version.
>
> Consequently, there should no longer be any ambiguity that this one is
> intended:
>   https://stable.melpa.org/#/php-mode
>
> The following webpage is already defined as Homepage:
>   https://github.com/ejmr/php-mode
>
> http://php-mode.sf.net is now obsolete.  I'm hesitant to add
> https://stable.melpa.org/#/php-mode to the long description, because
> none of our team's other packages provide links to MELPA.  Also, our
> team avoids packaging anything that doesn't provide either a release
> tarball or tagged releases in a proper VCS.
>
> Do you think renaming src:php-elisp to src:php-mode would reduce the
> ambiguity of which PHP Emacs package is in question?
>
> Cheers,
> Nicholas
>

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Hi

With this I say I can still be co maintainer.

/ Ola

Sent from a phone

Den mån 2 juli 2018 22:07Ola Lundqvist  skrev:

> Hi
>
> I still use it so I can do some limited tests if necessary.
>
> But I only use stable so it must be installable on stable in that case.
>
> Sounds ok?
>
> / Ola
>
> Sent from a phone
>
> Den mån 2 juli 2018 21:51Nicholas D Steeves  skrev:
>
>> On Thu, Jun 28, 2018 at 11:24:03PM +0200, Ola Lundqvist wrote:
>> >Package: php-elisp
>> >I still use the package but I do not have the time to update to newer
>> >releases.
>> >So if anyone would like to help or even better take it over, please
>> do so.
>> >Send me an email so I know
>> >/ Ola
>>
>> I'm willing to update the package to the newest upstream release,
>> current standards, convert the package to use dh-elpa, etc, and keep
>> the package up to date.
>>
>> But as I don't use PHP at all, and consequently won't actually be
>> using this mode, I'd like to share the responsibility of maintaining
>> the package with a comaintainer.
>>
>> Ola, if a more qualified maintainer doesn't volunteer, how does the
>> following sound as a worst-case scenario:  Adopt php-elisp under
>> Debian Emacsen team maintenance and give you permission to commit to
>> the salsa project, set you as the primary uploader, and myself as
>> another uploader.  Do you still use the package?
>>
>> Regards,
>> Nicholas
>>
>

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Hi

I still use it so I can do some limited tests if necessary.

But I only use stable so it must be installable on stable in that case.

Sounds ok?

/ Ola

Sent from a phone

Den mån 2 juli 2018 21:51Nicholas D Steeves  skrev:

> On Thu, Jun 28, 2018 at 11:24:03PM +0200, Ola Lundqvist wrote:
> >Package: php-elisp
> >I still use the package but I do not have the time to update to newer
> >releases.
> >So if anyone would like to help or even better take it over, please
> do so.
> >Send me an email so I know
> >/ Ola
>
> I'm willing to update the package to the newest upstream release,
> current standards, convert the package to use dh-elpa, etc, and keep
> the package up to date.
>
> But as I don't use PHP at all, and consequently won't actually be
> using this mode, I'd like to share the responsibility of maintaining
> the package with a comaintainer.
>
> Ola, if a more qualified maintainer doesn't volunteer, how does the
> following sound as a worst-case scenario:  Adopt php-elisp under
> Debian Emacsen team maintenance and give you permission to commit to
> the salsa project, set you as the primary uploader, and myself as
> another uploader.  Do you still use the package?
>
> Regards,
> Nicholas
>

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Package: php-elisp

I still use the package but I do not have the time to update to newer
releases.

So if anyone would like to help or even better take it over, please do so.

Send me an email so I know

/ Ola

Bug#901985: jpeginfo FTCBFS: configures for the build architecture

[Ola Lundqvist]

Thank you for the report. I'll consider this for next upload. Please note
that the package is very rarely updated so this may take some time.
And of course thank you for the patch.

Best regards

// Ola

On 21 June 2018 at 05:56, Helmut Grohne  wrote:

> Source: jpeginfo
> Version: 1.6.0-6
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> jpeginfo fails to cross build from source, because it configures for the
> build architecture. Using dh_auto_build does not fix that, because
> jpeginfo's ./configure is so old that it doesn't understand --host.
> Rather it needs a suitable CC exported. After doing so, jpeginfo cross
> builds succesfully. Please consider applying the attached patch.
>
> Helmut
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#858851: debarchiver: [INTL:de] updated German man page translation

[Ola Lundqvist]

Hi Helge

Thank you for the reminder. I have updated the package in subversion now.

https://svn.inguza.org/fsp/trunk/debarchiver/

Yes the certificate is outdated and for wrong host. I'll fix that
eventually.

// Ola

On 31 May 2018 at 18:35, Helge Kreutzmann  wrote:

> Hello Ola,
> On Wed, Jun 07, 2017 at 08:16:40AM +0200, Ola Lundqvist wrote:
> > Sorry for very late response. I did a brief check and yes it looks
> > odd. I'll have a look at this more as soon I can find the time. There
> > are some other odd sentences as well if I remember correctly.
> >
> > Best regards
> >
> > // Ola
> >
> > On 31 March 2017 at 17:47, Helge Kreutzmann 
> wrote:
> > > Hello Ola,
> > > this one new string does not make sense:
> > > "The verify command. @vrfycmd is set to the list ($vrfycmd) just
> before the "
> > > "verify command is executed is the array is empty. It was made like
> this for "
> > > "backwards compatibility reasons."
> > >
> > > The second sentence is somehow broken, can you check it?
>
> Is there any news on this?
>
> If you plan an upload, please provide the de.po beforehand so that I
> can update it before your upload.
>
> Thanks!
>
> Greetings
>
>  Helge
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.   http://www.helgefjell.de/
> debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#900324: [Pkg-tigervnc-devel] Bug#900324: mouse buttons not working in fullscreen mode

[Ola Lundqvist]

Hi

Thank you for your report. Does it work if you exit full screen mode?

// Ola

On 29 May 2018 at 07:19, Harald Dunkel  wrote:

> Package: tigervnc-viewer
> Version: 1.7.0+dfsg-8
>
> If I switch to full screen mode, than the mouse buttons are not
> working anymore. F8 shows me just a white rectangle, i.e. I cannot
> switch back to Window mode, either.
>
> Desktop is fvwm.
>
>
> Regards
> Harri
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-tigervnc-devel




-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#899397: cron-apt: mail subject never indicates error on completion

[Ola Lundqvist]

Hi

Sorry for long delay. Thank you for the patch. A patched package will be
uploaded shortly.

// Ola

On 23 May 2018 at 20:06, Sebastian Klamar <
bug.cron-...@sebastian.klamar.name> wrote:

> Package: cron-apt
> Version: 0.10.0
> Severity: minor
>
> Dear Ola,
>
> /usr/share/cron-apt/functions contains an error (cf. code extract
> below): The mail subject never will be "... error on ..." (line 103)
> because the error file tested for existance gets deleted beforehand
> (line 84ff.).  Thus one cannot trust mails like "completed on..."
>
> I've solved the issue by moving the "if -f ... rm -f ..." clean-up below
> the mail command (cf. patch below).
>
> /usr/share/cron-apt/functions:
>  84 if [ -f "$ERROR" ] ; then
>  85 rm -f "$ERROR"
>  86 fi
>  87 if [ -f "$RUNSYSLOG" ] ; then
>  88 rm -f "$RUNSYSLOG"
>  89 fi
>  90 if [ -f "$RUNERROR" ] ; then
>  91 rm -f "$RUNERROR"
>  92 fi
>  93 if [ -f "$RUNMAIL" ] ; then
>  94 rm -f "$RUNMAIL"
>  95 fi
>  96 if [ -f "$MAIL" ] && [ "$MAILON" != "never" ] && [ -n "$MAILON" ]
> ; then
>  97 if command -v sendmail >/dev/null; then
>  98 HDR="To: $MAILTO"
>  99 if [ -z "$HOSTNAME" ]; then
> 100 HOSTNAME="$(uname -n)"
> 101 fi
> 102 if [ -f "$ERROR" ] ; then
> 103 HDR=$(printf "$HDR\nSubject: CRON-APT error on
> $HOSTNAME [$CONFIG]")
> 104 else
> 105 HDR=$(printf "$HDR\nSubject: CRON-APT completed on
> $HOSTNAME [$CONFIG]")
> 106 fi
>
> --- /tmp/functions  2018-05-23 19:54:05.0 +0200
> +++ /usr/share/cron-apt/functions   2018-05-23 19:56:36.875793315
> +0200
> @@ -81,9 +81,6 @@
>  if [ -f "$RUNLOG" ] ; then
> rm -f "$RUNLOG"
>  fi
> -if [ -f "$ERROR" ] ; then
> -   rm -f "$ERROR"
> -fi
>  if [ -f "$RUNSYSLOG" ] ; then
> rm -f "$RUNSYSLOG"
>  fi
> @@ -123,6 +120,9 @@
>  if [ -f "$DIFF" ] ; then
> rm -f "$DIFF"
>  fi
> +if [ -f "$ERROR" ] ; then
> +   rm -f "$ERROR"
> +fi
>  if [ -d "$TMPDIR" ] ; then
> rmdir "$TMPDIR"
>  fi
>
>
> BTW, one could move all clean-up code ("if -f ... rm -f ...") below the
> mail function in order to prevent similar bugs when extending the mail
> function with other variables in the future.
>
> Thank you in advance for merging the patch into mainline version -- and
> for spending your free time as debian developer.
>
>
> Best regards -- Sebastian
>
> -- System Information:
> Debian Release: 9.4
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
> 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 cron-apt depends on:
> ii  apt  1.4.8
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon] 3.0pl1-128+deb9u1
> ii  liblockfile1   1.14-1+b1
> ii  nullmailer [mail-transport-agent]  1:1.13-1.2
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/action.d/0-update [Errno 2] No such file or directory:
> '/etc/cron-apt/action.d/0-update'
> /etc/cron-apt/action.d/3-download [Errno 2] No such file or directory:
> '/etc/cron-apt/action.d/3-download'
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
>
> -- no debconf information
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#288763: Calling apt-list-changes via cron-apt

[Ola Lundqvist]

Hi

Sorry for late reply. Thank you for the contribution. I'll consider adding
this suggestion to the documentation of the package. For the time being it
is good that it is here in the bug report.

Best regards

// Ola

On 4 April 2018 at 17:01, Alexander Reichle-Schmehl 
wrote:

> Hi!
>
> I recently run into the same problem, found that ticket, found a work
> around, and thought I update the ticket, as my workaround might be
> useful for someone else, too.
>
> The basic idea is to call apt-listchanges over all files downloaded to
> /var/cache/apt/archives. To avoid getting the changelog of cruft
> collected in that directory, I first run apt-get.
>
> To do that, I created /etc/cron-apt/action.d/1-clean which contains:
> clean
>
> I also created /etc/cron-apt/config.d/4-listchanges containing:
> APTCOMMAND="/usr/bin/apt-listchanges"
> OPTIONS=""
>
> And finnally I created /etc/cron-apt/4-listchanges containing:
> /var/cahce/apt/archives/*.deb
>
>
> WARNING: Using this solution might not be what you want, as you'll
> download package updates daily, just to remove them the next day from
> the cache and downloading them again (unless you install them in time).
> It might also remove packages from the archive cache, you might want to
> keep.
>
>
>
> Best regards,
>   Alexander
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#773585: php-elisp: Wrong indention of function arguments in subsequent lines

[Ola Lundqvist]

Hi

Thank you!

Sent from a phone

Den 7 feb 2018 16:48 skrev "Roland Rosenfeld" :

> On Mi, 07 Feb 2018, Roland Rosenfeld wrote:
>
> > Just for the records: https://github.com/ejmr/php-mode/issues/128
> > mentions the same issue since 2013-09-07, but is still open.
>
> I just tried to build 1.18.4 (current github version) as a Debian
> package.  This builds without any changes, throws some errors on
> installing but seems to work as expected (i.e. this bug seems to be
> solved).
>
> Tscho
>
> Roland
>

Bug#881097: To be removed from wheezy as well

[Ola Lundqvist]

Hi again

After some more reading I think removing it should be ok anyway. I'll
change the wording from "will be removed" to "may be removed" to allow
us the freedom to keep it if nobody takes the action to actually
remove it.

// Ola

On 17 December 2017 at 20:28, Ola Lundqvist <o...@inguza.com> wrote:
> Hi
>
> I agree that it may not be the best to remove it then. I suggest we
> mark it as no-dsa then. Any objections?
>
> // Ola
>
> On 22 November 2017 at 21:00, Emilio Pozuelo Monfort <po...@debian.org> wrote:
>> On 08/11/17 20:19, Ola Lundqvist wrote:
>>> Hi
>>>
>>> Considering that this package is about to be removed from jessie I
>>> guess it should be removed from wheezy too. How is that done? Should I
>>> contact the FTP maintainers about it, or do we simply ignore the
>>> issue?
>>
>> We don't have point releases, so I'm not sure we can get a package removed at
>> this stage without extra work by the ftp masters. So our options would be:
>>
>> - mark as no-dsa if it's not important enough
>> - mark as unsupported / end-of-life
>> - fix it
>> - get it removed
>>
>> The issue seems only exploitable if it's used by a service that is exposed
>> remotely or to other issues... and has no rdeps in wheezy. OTOH there is at
>> least one sponsor using that package. So removing it may not be the best 
>> course
>> given there is a proposed patch. So I'd go with either no-dsa or fix it,
>> depending on the assessed importance.
>>
>> Cheers,
>> Emilio
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#881097: To be removed from wheezy as well

[Ola Lundqvist]

Hi

I agree that it may not be the best to remove it then. I suggest we
mark it as no-dsa then. Any objections?

// Ola

On 22 November 2017 at 21:00, Emilio Pozuelo Monfort <po...@debian.org> wrote:
> On 08/11/17 20:19, Ola Lundqvist wrote:
>> Hi
>>
>> Considering that this package is about to be removed from jessie I
>> guess it should be removed from wheezy too. How is that done? Should I
>> contact the FTP maintainers about it, or do we simply ignore the
>> issue?
>
> We don't have point releases, so I'm not sure we can get a package removed at
> this stage without extra work by the ftp masters. So our options would be:
>
> - mark as no-dsa if it's not important enough
> - mark as unsupported / end-of-life
> - fix it
> - get it removed
>
> The issue seems only exploitable if it's used by a service that is exposed
> remotely or to other issues... and has no rdeps in wheezy. OTOH there is at
> least one sponsor using that package. So removing it may not be the best 
> course
> given there is a proposed patch. So I'd go with either no-dsa or fix it,
> depending on the assessed importance.
>
> Cheers,
> Emilio



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#883079: please consider patch to place last mail message in log dir

[Ola Lundqvist]

Hi

Thank you. Applied and now also uploaded.

Best regards

// Ola

On 29 November 2017 at 12:22, Marc Haber
 wrote:
> Package: cron-apt
> Version: 0.11.0
> Severity: wishlist
> Tags: patch
>
> Hi,
>
> please consider the attached patch. It makes cron-apt save the mail
> message sent out in the log dir, allowing processes on the system to
> access the current last mail message that was generated by cron-apt.
>
> This can, for example, be used to output pending updates to a user
> logging in in their .profile without the delay that comes with actually
> invoking apt, or to generate a monitoring check warning for pending
> updates, also without imposing a delay because the information is
> already there.
>
> For example, I do have the followingin my .bash_profile:
>
> if [ -r /var/log/cron-apt/lastfullmessage ]; then
>   echo "---"
>   < /var/log/cron-apt/lastfullmessage sed '/^---/,/^-/d' | grep -vE 
> '^((CRON-APT|To:|Subject:|Reading|Building|Initializing|Writing|Need) .*)?$'
>   echo "---"
> fi
>
> Greetings
> Marc



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#883078: marker for diff beginning

[Ola Lundqvist]

Thank you. Applied and will upload soon.

On 29 November 2017 at 12:18, Marc Haber
 wrote:
> Package: cron-apt
> Version: 0.11.0
> Severity: wishlist
> Tags: patch
>
> Please consider the attached patch that places a marker at the beginning
> of an attached diff to ease automatic processing, and cleans up a minor
> issue with the diff file handling.
>
> Greetings
> Marc



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#882309: should wrap lines in message body

[Ola Lundqvist]

Thank you. Applied, will upload soon.

On 29 November 2017 at 12:09, Marc Haber
 wrote:
> Package: cron-apt
> Version: 0.11.0
> Followup-For: Bug #882309
>
> Here we are.
>
> Greetings
> Marc



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#882309: should wrap lines in message body

[Ola Lundqvist]

Hi

Yes this is a good suggestion. A patch is welcome.

// Ola

On 21 November 2017 at 11:10, Marc Haber
 wrote:
> Package: cron-apt
> Version: 0.11.0
> Severity: normal
>
> Hi,
>
> the line length in SMTP is limited to 998 bytes. The exim packages in
> Debian do enforce this.
>
> When a system is way behind with its updates, the list of packages which
> is included in the apt output can exceed this length. In this case, the
> message is not fowarded by Debian's default MTA in its default
> configuration.
>
> cron-apt should wrap lines.
>
> fold(1), which is in coreutils, can do this job nicely, augmented by the
> --witdh=900 --spaces arguments. Maybe it would be a good idea to make
> the width configurable.
>
> If you want me to, I can cough up a patch.
>
> Greetings
> Marc



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#881097: To be removed from wheezy as well

[Ola Lundqvist]

Hi

Considering that this package is about to be removed from jessie I
guess it should be removed from wheezy too. How is that done? Should I
contact the FTP maintainers about it, or do we simply ignore the
issue?

For people who wonder what we are discussing it is about CVE-2008-7319

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#880587: [Pkg-tigervnc-devel] Bug#880587: xrandr -o left/right crashes the X server if libvnc.so loaded

[Ola Lundqvist]

Hi

Thank you for the report.

// Ola

On 2 November 2017 at 16:13, Pierre Dinh-van <pierre-...@qsdf.org> wrote:
> Package: tigervnc-xorg-extension
> Version: 1.7.0+dfsg-7
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> I set up libvnc.so from tigervnc-xorg-extension for my stretch
> workstations by adding a config file
> /usr/share/X11/xorg.conf.d/99-vnc.conf with in it :
>
>
> Section "Module"
>   Load  "vnc"
> EndSection
> Section "Screen"
>   Identifier "Screen0"
>   Device "Card0"
>   Monitor"Monitor0"
>   Option "SecurityTypes" "VncAuth"
>   Option "QueryConnect"
>   Option "QueryConnectTimeout" "30"
>   Option "IdleTimeout" "60"
>   Option "UserPasswdVerifier" "VncAuth"
>   Option "PasswordFile" "/etc/vncpasswd"
> EndSection
>
>
> I try to rotate locally my screen with 'xrandr -o left' or 'xrandr -o right'
>
> it crashes the X session and goes back to lightdm.
>
> If the resolution is not changed, for example with '-o inverted' then, the
> session runs further.
>
> I tried with the upstream release 1.8.0 and it's affected by the same
> problem
> I tried on computers with intel graphics, and in a VirtualBox VM. The result
> is the same on both.
>
> removing the /usr/share/X11/xorg.conf.d/99-vnc.conf and restarting ligthdm
> removes the issue.
>
>
> It's a problem for my users who might have the orientation of the display
> set up in the preferences of there XFCE4.
>
> I cannot upgrade such users, or they will be first unable to login until
> they fix there xfce4 profile and they are then unable to use a vertical
> layout for their screen.
>
>
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages tigervnc-xorg-extension depends on:
> ii  libaudit1  1:2.6.7-2
> ii  libbsd00.8.3-1
> ii  libc6  2.24-11+deb9u1
> ii  libgcc11:6.3.0-18
> ii  libgnutls303.5.8-5+deb9u3
> ii  libjpeg62-turbo1:1.5.1-2
> ii  libpam0g   1.1.8-3.6
> ii  libstdc++6 6.3.0-18
> ii  xserver-xorg-core  2:1.19.2-1+deb9u2
> ii  zlib1g 1:1.2.8.dfsg-5
>
> Versions of packages tigervnc-xorg-extension recommends:
> ii  tigervnc-common  1.7.0+dfsg-7
>
> tigervnc-xorg-extension suggests no packages.
>
> -- no debconf information
>
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Great, thanks!
Sent from a phone

Den 28 sep 2017 08:25 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:

> On Wed, Sep 27, 2017 at 10:36:55PM +0200, Ola Lundqvist wrote:
> > Yes, but maybe I accidentally signed it with the old key. I'll check
> > and re-upload.
>
> The second upload made it. Thanks.
>
> Greetigns
> Marc
>
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Hi

Yes, but maybe I accidentally signed it with the old key. I'll check
and re-upload.

// Ola

On 27 September 2017 at 16:54, Marc Haber <mh+debian-b...@zugschlus.de> wrote:
> On Tue, Sep 26, 2017 at 08:38:01PM +0200, Ola Lundqvist wrote:
>> Uploaded to unstable now.
>
> Did your upload work? Package is not in unstable as of now.
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Hi

Uploaded to unstable now.

// Ola

On 25 September 2017 at 12:14, Ola Lundqvist <ola.lundqv...@gmail.com> wrote:
> Will do.
> Sent from a phone
>
> Den 25 sep 2017 09:54 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:
>>
>> On Fri, Sep 22, 2017 at 08:08:30PM +0200, Ola Lundqvist wrote:
>> > If you can test http://apt.inguza.net/cron-apt_0.11.0_all.deb it would
>> > be great.
>> > The new option is named SUBJECTPREFIX.
>>
>> Looks good, please go ahead!
>>
>> Greetings
>> Marc
>>
>> --
>>
>> -
>> Marc Haber | "I don't trust Computers. They | Mailadresse im
>> Header
>> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224
>> 1600402
>> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224
>> 1600421

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Will do.
Sent from a phone

Den 25 sep 2017 09:54 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:

> On Fri, Sep 22, 2017 at 08:08:30PM +0200, Ola Lundqvist wrote:
> > If you can test http://apt.inguza.net/cron-apt_0.11.0_all.deb it would
> be great.
> > The new option is named SUBJECTPREFIX.
>
> Looks good, please go ahead!
>
> Greetings
> Marc
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Hi

New version for testing shebang fixed.
Same location and name as before.

// Ola

On 23 September 2017 at 13:42, Ola Lundqvist <ola.lundqv...@gmail.com> wrote:
> Whoops! I did not realize it was changed. Will fix
>
> Sent from a phone
>
> Den 23 sep 2017 09:36 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:
>>
>> On Sat, Sep 23, 2017 at 07:15:05AM +0200, Marc Haber wrote:
>> > On Fri, Sep 22, 2017 at 08:08:30PM +0200, Ola Lundqvist wrote:
>> > > If you can test http://apt.inguza.net/cron-apt_0.11.0_all.deb it would
>> > > be great.
>> > > The new option is named SUBJECTPREFIX.
>> > >
>> > > I'd like to get some testing feedback before I upload to unstable.
>> >
>> > I have installed this on a bunch of test systems and will report back on
>> > sunday night.
>>
>> The Shebang in /usr/sbin/cron-apt needs obvious fixing ;-)
>>
>> Greetings
>> Marc
>>
>> --
>>
>> -
>> Marc Haber | "I don't trust Computers. They | Mailadresse im
>> Header
>> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224
>> 1600402
>> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224
>> 1600421

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Whoops! I did not realize it was changed. Will fix

Sent from a phone

Den 23 sep 2017 09:36 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:

> On Sat, Sep 23, 2017 at 07:15:05AM +0200, Marc Haber wrote:
> > On Fri, Sep 22, 2017 at 08:08:30PM +0200, Ola Lundqvist wrote:
> > > If you can test http://apt.inguza.net/cron-apt_0.11.0_all.deb it
> would be great.
> > > The new option is named SUBJECTPREFIX.
> > >
> > > I'd like to get some testing feedback before I upload to unstable.
> >
> > I have installed this on a bunch of test systems and will report back on
> > sunday night.
>
> The Shebang in /usr/sbin/cron-apt needs obvious fixing ;-)
>
> Greetings
> Marc
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Hi Marc

If you can test http://apt.inguza.net/cron-apt_0.11.0_all.deb it would be great.
The new option is named SUBJECTPREFIX.

I'd like to get some testing feedback before I upload to unstable.

Best regards

// Ola

On 22 September 2017 at 13:51, Ola Lundqvist <ola.lundqv...@gmail.com> wrote:
> Will do!
>
> Sent from a phone
>
> Den 22 sep 2017 13:17 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:
>>
>> On Fri, Sep 22, 2017 at 12:54:09PM +0200, Ola Lundqvist wrote:
>> > Now I'm modifying your patch directly in this mail. It will not apply
>> > cleanly:
>>
>> Great, that's exactly what I meant. Go ahead with that  ;-)
>>
>> Greetings
>> Marc
>>
>> --
>>
>> -
>> Marc Haber | "I don't trust Computers. They | Mailadresse im
>> Header
>> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224
>> 1600402
>> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224
>> 1600421

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Will do!

Sent from a phone

Den 22 sep 2017 13:17 skrev "Marc Haber" <mh+debian-b...@zugschlus.de>:

> On Fri, Sep 22, 2017 at 12:54:09PM +0200, Ola Lundqvist wrote:
> > Now I'm modifying your patch directly in this mail. It will not apply
> cleanly:
>
> Great, that's exactly what I meant. Go ahead with that  ;-)
>
> Greetings
> Marc
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>