Hi,
I see this as beta testing exercise, so here is what I did:
1. Long time ago I asked Michele to help me build local repository and build
system. This now works and I can build the packages from git repository,
which I checked out.
2. I then create a local repository and can use it from the local network
3. I had no problem installing, upgrading and testing - it is just great!
I just wanted to try installing TDE from scratch in clean chrooted
debootstrap from the repository I build last month, but I failed on few
metapackages. (This is perhaps related to a UL issue discussed few days
ago)
apt-get install tde-trinity
The following packages have unmet dependencies:
tde-trinity : Depends: tde-core-trinity (>= 4:14.0.0~) but it is not going
to be installed
Depends: desktop-base-trinity but it is not installable
E: Unable to correct problems, you have held broken packages.
Why I don't find desktop-base-trinity in stretch
$ grep desktop-base-trinity -r tde/1_git/tde-packaging/debian/stretch/ |
grep Package
but it is in
$ grep desktop-base -r tde/1_git/tde-packaging/ | grep Package
tde/1_git/tde-packaging/ubuntu/maverick/defaultsettings/desktop-base/debian/control:Package:
desktop-base-trinity
same for tde-core
$ grep tde-core -r tde/1_git/tde-packaging/ | grep Package
tde/1_git/tde-packaging/debian/squeeze/metapackages/meta-tde/debian/control:Package:
tde-core-trinity
tde/1_git/tde-packaging/debian/lenny/metapackages/meta-tde/debian/control:Package:
tde-core-trinity
Where do I log this bugzilla or gitea?
thanks
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Cheers
--
Slávek
Hi all!
Hope this helps others that try to get started with tdevelop:
As written some time ago I was not able to build any project with tdevelop due to a mismatch of "libtool": The one that is created ftom tdevelop does not match the one that is needed for devuan. I just found out, that is sufficient to replace "libtool" (that one that is created by configure) with a symlink to the installed libtool and the the project compiles perfect.
Now this is a dirty hack to get things working for all tde projects that are created by tdevelop:
cd /opt/trinity/share/apps/kdevappwizard/template-common
tar xzf admin.tar.gz
cat << XXX >> admin/configure.in.bot.end
rm libtool
ln -s $(which libtool) .
XXX
tar czf admin.tar.gz admin
rm -R admin
Now there is another "configure.in.bot.end" template for kde which is most likely to suffer from the same problem, but as I am not interested in kde I did not check.
Nik
--- /tmp/configure.in.bot.end 2019-02-03 14:02:56.102558045 +0100
+++ /opt/trinity/share/apps/kapptemplate/admin/configure.in.bot.end 2019-02-03 14:04:08.746918269 +0100
@@ -43,3 +43,11 @@
echo "Good - your configure finished. Start make now"
echo ""
fi
+
+rm libtool
+cat << XXX > libtool
+#!/bin/env libtool
+XXX
+chmod a+x libtool
+
+
--
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
# inxi -Gxxb
System: Host: gb250 Kernel: 4.15.0-42-generic x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Trinity R14.1.0 tk: Qt 3.5.0
wm: Twin dm: startx Distro: Ubuntu 18.04.1 LTS (Bionic Beaver)
Machine: Type: Desktop System: Gigabyte product: B250M-D3H v: N/A serial: N/A
Mobo: Gigabyte model: B250M-D3H-CF v: x.x serial: N/A UEFI: American Megatrends v: F9 date: 04/10/2018
CPU: Dual Core: Intel Core i3-7100T type: MT MCP arch: Kaby Lake speed: 800 MHz min/max: 800/3400 MHz
Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912
Display: server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa resolution: 2560x1440~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.0.5 compat-v: 3.0
direct render: Yes
Network: Device-1: Intel Ethernet I219-V vendor: Gigabyte driver: e1000e v: 3.2.6-k port: f040 bus ID: 00:1f.6
chip ID: 8086:15b8
Drives: Local Storage: total: 238.47 GiB used: 26.39 GiB (11.1%)
Info: Processes: 197 Uptime: 4h 11m Memory: 15.56 GiB used: 338.2 MiB (2.1%) Init: systemd v: 237 runlevel: 3 Compilers:
gcc: N/A Shell: bash v: 4.4.19 running in: konsole inxi: 3.0.30
TCC -> System Administration -> Monitor & Display has nothing enabled. Thus I would
expect no attempt from TDE to save power. Is this not the case? After 10 minutes, the
screen blanks for several seconds, after which the desktop wallpaper reappears, but
not the panel or open Windows. This happens whether the session is started from TDM
or with startx. I see nothing in /etc/X11 to account for this, though I'm not sure
what I would be looking for other than an Option "DPMS" statement in xorg.conf*. Is
this to be expected? Should I file a TDE bug?
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
I do a lot of mix and match with displays and PCs. The one I have now booted to Sid
has 2560x1440 and 2560x1080 displays on an old ATI dual DisplayPort PCIe card. I have
the larger configured as primary and the smaller as upper via an xrandr script in
/etc/X11/Xsession.d/. 14.0.6dev's first greeter appearance after booting is on the
upper/smaller display, but moves to the lower/larger display on logging out. I'd
rather it always be on the larger. Is this something configurable? If so, where &
how? Is this something worth or needing a bug report?
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
FWIW
I don't know if this impacts the way that debs are built for TDE.
--Mike
---------- Forwarded Message ----------
Subject: [britney]: Do you use --control-files or the "legacy package layout"
in your derivative?
Date: Sun December 30 2018, 11:13:00
From: Niels Thykier <niels(a)thykier.net>
To: Raphaël Hertzog <hertzog(a)debian.org>, Matthias Klumpp <mak(a)debian.org>,
Iain Lane <laney(a)debian.org>
CC: "debian-release" <debian-release(a)lists.debian.org>, "debian-derivatives"
<debian-derivatives(a)lists.debian.org>
Hi,
I am writing to you, because I know that you are (or have been) involved
in setting up or maintaining a britney instance for a Debian derivative.
If you are no longer involving please let me know who to contact
instead (where applicable).
We are considering to deprecate the "legacy package layout" and remove
the "--control-files" option.
1) Debian no longer uses these two features in our production runs at
all and now instead simply point britney at the metadata of a
standard mirror.
2) The "--control-files" option has not being updated and currently
generates incomplete Sources files for the target suite. We have
no test cases to safe guard against that. As it is not a feature
we use, it is unlikely to appear there.
3) The "legacy package layout" is currently used for tests and is
unlikely to disappear immediately. However, if a better layout for
test cases appear, we may migrate to it and remove the old code.
How can I tell if I use these features?
=======================================
Check your britney command line. If it includes "--control-files" then
you are using both features (as "--control-files" only works with the
"legacy package layout".
Otherwise, check your britney configuration. If the path set for the
"TESTING" configuration points to a standard APT mirror (with a Release
file) you are unaffected by this mail. If it instead points to a file
directory with some "Packages_X" files and a "Sources" file, you are
using what I refer to as the "legacy package layout".
You can also check the output with -v for a line like [1]. This
determine if britney actually believes it is working with a standard
mirror layout.
If you use "--control-files":
=============================
If you use "--control-files", then you can probably discard it.
If you rely on the updated target suite, please consider reusing
whatever tooling you use to generate your source suite data to also
generate the target suite. This ensures you have a sane full data set
for both source suite(s) and target suites.
If you use the legacy package layout:
=====================================
If feasible, consider migrating to using a standard mirror layout (e.g.
if you have a local mirror on the machine running britney). This also
enables you to remove the "ARCHITECTURES" and "COMPONENTS" fields from
your configuration file as britney simply reads those from the Release
file of the target suite.
If the mirror format it not an option, please let me know about your use
case to see if there is a better alternative.
Other bits while we are in contact. :)
======================================
Improving britney:
------------------
We are accepting contributions to britney via salsa.debian.org[2] in
form of Merge Requests and bug reports via the BTS as usual (with or
without patches).
Merge Requests are preferred over patches in the BTS as we have
configured salsa to run our test suite for britney along with our code
coverage report at [3].
More (technical) details can be found in our docs for contribution[4].
Request for info about your britney sources/configs/setups:
-------------------------------------------------
We would very much like an updated list of links to your britney sources
(e.g. forks/clones), configurations and setups. Our aim is to get a
better understanding of what is out there and how you use britney. If
you use britney to process data generated by other tools than the ones
in use by Debian (like dak), it might be good to mention that as well.
Please send this info to debian-release(a)lists.debian.org.
Thanks,
~Niels
[1]
I: [...] - Found a Release file in testing - using that for defaults
(Exact format depends on which version you are using)
[2] https://salsa.debian.org/release-team/britney2
[3] https://release-team.pages.debian.net/britney2/coverage/
[4]
https://release-team.pages.debian.net/britney2/docs/contributing-to-britney…
-------------------------------------------------------
Hi all!
I just wanted to let you know how TDE works on just-released FreeBSD 12:
Basicly everything works as expected, there are just 4 small problems.
- For 2 of them I've added bugs + fixes to the bugtracker.
- The 3rd is the test "tdeio/kmimetypetest" from "tdelibs", which still fails but mimetipes work after "make install".
- the 4rd is again a definition "#define ksize_t socklen_t", but I still have to find where that comes from.
So I'm quite pleased :-)
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
Hi,
I have ubuntu 18.4 with trinity R14.0.5. If I want to start the arduino
ide from arduino.cc (download and extract arduino-1.8.7-linux64.tar.xz)
there comes the splash-screen for one second and it crashes with this
message:
~/arduino-1.8.7$ ./arduino
Picked up JAVA_TOOL_OPTIONS:
TQSettings::sync: failed to open '/etc/tqt3/tqt_plugins_3.5rc.tmp' for
writing
What I have to install or change? Thank you very much for the great Desktop.