Hi all,
we do second this. While we always installed workstations automatically
with debian preseeding and the default receipts (lvm encrypted) we
noticed the defaults suddenly changed in bullseye.
I would support the assumption that for server installations this is
not a big issue since one (at
Hi again,
Am 17.09.19 um 18:02 schrieb Mike Gabriel:
> Hi,
> completing the story...
>
> During package upgades, I see upgrade failures:
>
> ```
> root@jessie:~# apt-get install 389-ds-base --reinstall
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
>
Hi Mike,
Am 17.09.19 um 17:38 schrieb Mike Gabriel:
> What I did:
>
> 1. Setup a fresh 389-ds instance using jessie's original version
> (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)
>
> 2. Upgrade to +deb8u4, test login, LDAP queries, etc.
>
> -> worked
>
> 3. Upgrade to
Hi Mike,
hi Hugo,
Am 11.09.19 um 14:04 schrieb Mike Gabriel:
> Hi Hugo,
>
> sorry for the late reply on this urgent matter.
>
> On So 08 Sep 2019 10:46:26 CEST, Hugo Lefeuvre wrote:
>
>> Sorry for the very late answer. For some reason, it looks like the LTS
>> team
>> was not aware of this
to mention: with version 1.3.5.17-2 in stretch everything works fine again.
Package: 389-ds
Version: 1.3.3.5-4+deb8u5
Severity: high
since 26.10.2018 our nextcloud installations can't authenticate against
389-ds anymore. This seems to have an relation to the latest update in
389-ds - it happend after we applied these two updates:
389-ds-base (1.3.3.5-4+deb8u5)
Package: debian-mate-default-settings
Version: 1.16.1-1
Severity: normal
Since iceweasel and icedove are replaced in Debian stretch completely,
the mate defaults.list should be updated accordingly.
The actual settings leads e.g. to the problem, that in ltsp environment
an remote thunderbird
Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: serious
Even if I have configured 'Remove-Unused-Dependencies "false";' in
apt.conf.d/50unattended-upgrades:
// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
solves the issue:
--- updates.orig/60upgradeconfigfiles.pl2018-09-03 09:58:45.911804203
+0200
+++ updates/60upgradeconfigfiles.pl 2018-09-03 09:59:36.420699451 +0200
@@ -31,7 +31,7 @@
next if (! -f $oldname); # does not exist - skip - already
(re)moved
my $newname
Hi Timo,
sorry for delay, I missed the mail.
> What if you change 'rename' with 'move' in /usr/share/dirsrv/updates/*.pl?
It's suffucient to change it in
/usr/share/dirsrv/updates/60upgradeconfigfiles.pl
then it works fine.
Regards
Jan
Package: 389-ds-base
Version: 1.3.5.17-2
Severity: serious
Upgrade to newer version of 389-ds-base fails with dpkg configuration
error on postinstall script /var/lib/dpkg/info/389-ds-base.postinst
After getting full log of postinstall I saw:
[18/08/01:10:33:37] - [Setup] Info Could not rename
11 matches
Mail list logo
