Could not read network connection list.
/root/.DCOPserver_m7ncd_0
Please check that the "dcopserver" program is running!"
These messages pop up twice at each attempt to start a TDE session, then the
attempt aborts, regardless whether sessuib start attempt is via TDM or startx.
This is hardly the first time I've encountered this. What is the usual cause?
32 bit Bullseye & trinity-sb.
http://fm.no-ip.com/Tmp/Linux/TDE/xsession-errors
--
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Dear developers,
every now and then I would like to add an issue in gitea workspace. But
I find it hard to find particular apps.
For example, I would like to add an issue for kweather (what I reported
earlier on tde-users) but when I enter "kweather" in the search field
it tells me that it didn't find any repositories.
What's the way to go from here? How could I find out in which of all
those sub repositories kweather resides?
To get more familiar with this gitea workspace probably would motivate
me to contribute to it more often. Any help appreciated. Thanks.
Kind regards,
Stefan
Hi all,
I have one easier topic to discuss.
We already have several cases where it would be useful to have a general
email address for the "team". For example, in deb packing files, Tim is
specifically listed as the "Maintainer:" with his address, while it would
be more appropriate to use the general "deb team" address. Similarly for
Gentoo packaging it would be useful to have an email address for the
Gentoo team.
Here are three ways to create such addresses:
1. An alias that ensures delivery of emails to a manually maintained list
of recipients.
This is a simple solution, but it can run into a problem due to SPF/DKIM
and at the same time it does not provide much comfort in answering - so
that other team members are informed as well.
2. Mailing list open to all for incoming mails and with a moderated
subscription.
There is good comfort for subscribing team members, it handles replying to
a mailing list well and can provide an archive - it is possible to choose
whether private or public.
3. Shared mailbox for each team.
A full IMAP mailbox is good - all emails in one place, but it has the
disadvantage of having to share a password.
What way do you think is best?
Cheers
--
Slávek
...when these settings are used in tdmrc in openSUSE 15.2:
SelectedUsers=root,me
HiddenUsers=
UseTheme=false
Theme=
PreselectUser=me
FocusPasswd=true
LoginMode=DefaultLocal
Users list with no user preselected is a real problem, because user "me" is really
my 90 year old mom. She can manage the password when it's the default, but I don't
seem to be able to make it the default. Am I overlooking something? Or, is this a
bug nobody notices because everybody uses the mousetype default theme or autologin?
--
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Hi,
I did upgrade freshly compiled 14.1, but hit the one in the Subject.
Subsequent "apt-get -f install" solved it (I hope).
Removing 'diversion
of /opt/trinity/share/apps/konqueror/servicemenus/media_safelyremove.desktop
to /opt/trinity/share/apps/konqueror/servicemenus/media_safelyremove.desktop.distrib
by tdeio-umountwrapper-trinity'
Removing 'diversion
of /opt/trinity/share/apps/d3lphin/servicemenus/media_safelyremove.desktop
to /opt/trinity/share/apps/d3lphin/servicemenus/media_safelyremove.desktop.distrib
by tdeio-umountwrapper-trinity'
rmdir: failed to remove '/opt/trinity/share/apps/d3lphin/servicemenus/': No
such file or directory
dpkg: error processing package tdeio-umountwrapper-trinity (--configure):
installed tdeio-umountwrapper-trinity package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
tdeio-umountwrapper-trinity
E: Sub-process /usr/bin/dpkg returned an error code (1)
Hi all,
with the arrival of the new year, in addition to wishing you good health
and well-being, I open another topic for discussion - arrangement
between the project and contributors.
As with many other open source projects, there were concerns about
patent trolls and other potential legal risks that led Tim to propose
the use of a CLA (Contributor License Agreement) in 2014. The questions
following the CLA's proposal were mainly technical and focused on how to
confirm compliance with these arrangements for smaller contributors. The
discussion that followed led to a consensus on the fact that it was
essential for the contributors to add a "Signed-off-by:" line to their
contributions.
As a result, the "Signed-off-by" requirement is exactly the same as the
one for the DCO (Developer Certificate of Origin). DCO is significantly
simpler than a CLA and now used by a lot of open source projects. For
these reasons, in recent years we have already been using DCO rather
than CLA for all contributions made.
We would like to officially declare the CLA obsolete and replace it by a
DCO. This would actually officially reconcile the declared state and the
way it is actually used. Therefore, I ask you if anyone is aware of any
obstacles, why this could not be done?
See the CLA discussion thread:
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesk…
See DCO:
https://developercertificate.org/
Cheers
--
Slávek
On Mon December 28 2020 04:28:20 Tim Bishop wrote:
> Looks to me like it has completed a sync now? I guess it was just
> running slowly.
Yup. Kuiper seemed to be running slower and doing fewer syncs and
ultimately getting behind for 2-3 days but it was back in sync as
of last night.
Thank you for mirroring TDE!
--Mike
Hi,
I note on this page
https://www.trinitydesktop.org/mirrorstatus.php
that you list our backend servers (copernicus and kuiper) separately.
Could you change that to list a single URL please?
http://www.mirrorservice.org/sites/trinitydesktop.org/trinity/
(you may use https too if you prefer)
We're also testing out shorter URLs if this looks better:
http://trinitydesktop.mirrorservice.org/trinity/
(https available within the next 10 days)
The reason for this request is that these URLs go through our load
balancer. This allows us to transparently handle node failure, do
patching and maintenance, distribute traffic, etc, without impacting the
user visible service. The backends are not intended to be accessed
directly.
Thanks,
Tim.
--
Tim Bishop,
Computing Officer, School of Computing, University of Kent.
PGP Key: 0x6C226B37FDF38D55
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Hi Michael,
As discussed we're now mirroring the whole thing so there's no
separate "backup" option any more. A key factor in mirroring
is to minimize traffic to and from the primary server.
On Wed December 23 2020 08:35:05 Michael via tde-users wrote:
> Requirements for Mirror:
> Time frame good for:
> HD:
> Data:
> Pipe:
> CPU:
> Software:
Slávek posted the current size:
> Current size and occupied space of the partition:
> /dev/mapper/lvm1-tde_data 400G 336G 65G 84% /srv/tde
- and there was some discussion of trying to stay under 600GB over
the next few years.
I posted the bandwidth info:
> Primary mirror has 4TB/month bandwidth and has used 876GB about two thirds
> of the way thru this month. So about 1.3TB in a quiet month for the
> primary mirror. Secondary mirrors will probably see a third of that.
> There's more when a release is finalizing - maybe double or triple. So a
> 2TB/month cap should be OK for a secondary mirror and you might even get by
> with 1TB/month.
All other decisions are up to the mirror operator. I did post some
details of the script I use. Other mirrors use different scripts.
I use Debian Buster and Apache2 currently but that may change and
other mirrors may use entirely different software. The CPU and
RAM will of course depend upon the bandwidth which we have discussed
and the software which you choose but in reality it would probably
run fine on a twenty year old Pentium with a gig of RAM.
Please join the TDE devel list if you wish to discuss mirroring further
as that is a more appropriate forum.
Thanks,
--Mike
In addition to the regular development tool programs in /opt/trinity/bin, I
also see numerous tq* programs in /usr/bin, which are installed from the
Trinity repository. What are these for? Which should be used for
application development?
TIA,
Leslie
