Hi,
it would be perhaps for Slavek to answer this, but may be someone here knows
the answer too and can spare him the work.
I recently did reorganize emails identities etc. and one part was to stop
using the gmail account for writing to the lists and start using a private
domain account. However I was not able to post for some time
(work+vacation+many_other_activities). Now I went looking into the issue
and noticed that this ML is managed on
https://mail.trinitydesktop.org/mailman3/postorius/lists/
The information on the TDE web site seems to be newer than last time seen,
but never mind, I subscribed the lists from the webui and voila - it is
working now.
It seems that using the subscription in Gmain is not working, because I
tried subscribing from knode before and then on gmain.io, but in vain
So the question in context of TDE is how the subscribe can work from knode
for this list? For debian-user it worked in knode.
IMO it seems that something needs to be done in gmain, so that gmain can
forward the mail to trinitydesktop and trigger the subscription, but it's
just a guess based on described experience.
BR
Wicked and NetworkManager are both unnecessary when using systemd-networkd, which
I do in all Tumbleweed and 15.3 installations. Most TDE packages will not install
without wicked installed, which seems to be hung on libtdecore.so* from
trinity-tdelibs requiring wicked.
What's so special about wicked that systemd-networkd isn't good enough network
support to enable basic TDE/TDM packages to install?
After re-installing wicked I was able to get another 69 Trinity packages
installed. Afterward I force removed wicked, before starting TDM or a TDE session.
Zypper -v produces no complaint about missing wicked. Rpm -q -R trinity-tdelibs
output does not include wicked in output. TDM and TDE are apparently working as
expected.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Unzip (unzip-5.52-77.x86_64.rpm), some years ago, when listing files in an archive, showed the timestamp for those files in the format of MM-DD-YY. The latest versions of unzip (unzip-6.00-89.1.x86_64.rpm), when listing files in an archive, shows the timestamp for those files in the format of YYYY-MM-DD. This change in how unzip shows timestamps has caused KDE3.5.10 ARK to show a messed up timestamp when viewing a ZIP archive using the latest versions of unzip. Rolling back to the older version of unzip gets rid of the problem. However, that could create other problems.
Has this been fixed in TDE? Does TDE ARK show a valid timestamp when viewing a ZIP archive using the latest versions of unzip?
Debian Bullseye is in deep freeze and scheduled for release 08/14.
Often I wait until after release but this happened to be a good weekend
for me to start testing Bullseye. The non-TDE parts went much smoother
than usual. The only minor difficulty thus far was switching routing
from Quagga to FRR.
I see there's a TDE Bullseye version in trinity-sb. However if I test
this I'd like to get back onto TDE stable as soon as possible.
Any thoughts please on if I try trinity-sb/bullseye how much time or
how difficult will it be to get back to TDE stable with Bullseye?
Thanks,
--Mike
I'm not sure whether all packages suffer this, or just most, but it's annoying for
updating to keep getting interrupted. This has been going on for weeks, if not
months. Current instance is on host gx280 32bit Mageia 7.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
http://mirror.ppa.trinitydesktop.org/trinity/rpm/mga8/trinity-r14/RPMS/x86_…
refuses to install via urpmi, which claims bad MD5SUM file for both x86_64 and
noarch. Fetched with wget, rpm had no problem upgrading from the installed mga7
version.
While on the subject of Mageia, when installing or upgrading, screen output during
installation or upgrading is quite different for TDE packages vs. packages from
other repos. Standard package fetch and install are accompanied by no blank lines
output. With TDE packages around 5 out of 8 output lines are blanks, so roughly
2/3 of visual output is blank lines. This has been happening too long to remember,
but for certain back into last year if not before.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
http://mirror.ppa.trinitydesktop.org/trinity/rpm/mga8/trinity-r14/RPMS/x86_…
refuses to install via urpmi, which claims bad MD5SUM file for both x86_64 and
noarch. Fetched with wget, rpm had no problem upgrading from the installed mga7
version.
While on the subject of Mageia, when installing or upgrading, screen output during
installation or upgrading is quite different for TDE packages vs. packages from
other repos. Standard package fetch and install are accompanied by no blank lines
output. With TDE packages around 5 out of 8 output lines are blanks, so roughly
2/3 of visual output is blank lines. This has been happening too long to remember,
but for certain back into last year if not before.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Hi all,
from sks-keyservers.net web page:
This service is deprecated. This means it is no longer maintained, and new
HKPS certificates will not be issued. Service reliability should not be
expected.
Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records
for the pool will no longer be provided at all.
So, we need to do again to change the default key servers for KGpg.
Do you know any candidates we could use? I found the following:
https://keys.openpgp.org/https://pgp.key-server.io/https://keyserver.ubuntu.com/https://keyserver.pgp.com/
Cheers
--
Slávek
Hey guys,
I have noticed problems recently installing TDE on Devuan i386 systems.
I needed to test something else which led to do a fresh Devuan i386
install and a Debian Stretch i386 conversion to beowulf and the install
of tde-trinity or tdebase-trinity gave dependency issues. Not sure if
this applies to x64.
I can work round these using '--without-recommends' but 'non technical'
Devuan users may not appreciate this. Should the install docs highlight
this?
A sample output of 'aptitude install tdebase-trinity' is;
The following packages have unmet dependencies:
consolekit : Depends: libcgmanager0 (>= 0.28) but it is not going to
be installed
Depends: libck-connector0 (= 1.2.1-8) but it is not going
to be installed
Depends: libnih-dbus1 (>= 1.0.0) but it is not going to
be installed
Depends: libnih1 (>= 1.0.0) but it is not going to be
installed
libpolkit-backend-elogind-1-0 : Conflicts: consolekit but 1.2.1-8 is
installed
libpolkit-gobject-elogind-1-0 : Conflicts:
libpolkit-gobject-consolekit-1-0 but 0.105-25+devuan8 is installed
libpolkit-gobject-consolekit-1-0 : Conflicts:
libpolkit-gobject-elogind-1-0 but 0.105-25+devuan8 is to be installed
The following actions will resolve these dependencies:
Remove the following packages:
1) elogind [241.4-2 (now, stable)]
2) libpam-elogind [241.4-2 (now, stable)]
Install the following packages:
3) libpolkit-backend-consolekit-1-0 [0.105-25+devuan8 (stable)]
Keep the following packages at their current version:
4) libcgmanager0 [0.41-2+devuan1 (now, stable)]
5) libck-connector0 [1.2.1-8 (now, stable)]
6) libnih-dbus1 [1.0.3-10+b2 (now, stable)]
7) libnih1 [1.0.3-10+b2 (now, stable)]
8) libpolkit-backend-elogind-1-0 [Not Installed]
9) libpolkit-gobject-elogind-1-0 [Not Installed]
Leave the following dependencies unresolved:
10) consolekit recommends pm-utils
11) openssh-server recommends default-logind | logind | libpam-systemd
12) xserver-xorg-core recommends libpam-systemd
The above is just one example. Without elogind installed, another set of
issues is raised.
Also, using '--without-recommends' to avoid the conflicts results in
numerous tde & non tde packages not being installed, which might not be
what the user wants.
Cheers,
--
Michael Howard.
