Dear all,
in etherpad 63 (http://trinity.etherpad.trinitydesktop.org/63) we had some discussions about switching to a fixed-time release cycle after R14.0.0 is out of the door. The end result of those discussions and the preliminary agreement of some developers is to use a 90-day release cycle (pending Tim's agreement too :) ).
The idea is to issue a maintenance release R14.0.x every 3 months, containing bug fixes and minor improvements, and issue a minor release R14.y.0 every year containing bigger improvements. This will require bugs to be backported from the trunk to the R14.0.x branch for up to 9 months (which could become not that easy after several changes are done in the trunk) and would provide major improvements to the users only once a year. On the other hand, it may prove a more stable solution.
An alternative scenario I have been tinkering for a while lately is one where every 3 months we ship whatever is in the trunk as the next release. In this case we do not need to backport any bug and users would be able to get major improvements up to 4 times each year. On the other hand we may introduce some degree of instability if a feature is not well tested before shipping it (but in any case that risk would exist also with the minor R14.y.0 releases of the first scenario), with the "fixing time" being the same (3 months in both scenarios).
Given the limited amount of development resources that we have, I have come to like the second scenario the most, and I would like to hear the opinion of other developers as well.
If we end up adopting the second scenario, I would also like to propose an alternative release version numbering schema: Ryy.x, where yy is the year number and x is a progressive release number within the yy year.
So for example this year we would have R14.0, R14.1, R14.2 (and R14.3 is R14.0 is released before March 31). Then next year we would have R15.0, R15.1, R15.2 and R15.3 and so on....
Coincidentally, this year is 2014, so the year number matches the R14 release number too :)
Also, a side-effect benefit would be that TDE would look more active to the general public with Ryy.x release numbers than R14.0.x release numbers, since the last would probably be thought of as "nothing major, just minor fixes".
Looking forward for your opinions.
Cheers
Michele
All,
I had never built tork before and had no idea what it was, much less what it
did -- well -- it works! Basically it is an internet anonymity extension and
functions both as a proxy client and proxy server (configurable). It is
basically a tool that allows you to browse/email/ssh anonymously. I still have
no idea how to fully use it, but it was refreshing to see that some random app
near the end of the applications build tree -- works -- without a lot of CPR. I
haven't checked the code, but did see KDE4 patched tork for ipv6. We may need to
do that as well.
http://www.3111skyline.com/dl/dt/trinity/ss/tork-01.jpg
--
David C. Rankin, J.D.,P.E.
>That brings us to the point of -- "What is a proper XDG_*
>environment for
>trinity?" Right now in tqtinterface, we have complete control over
>the XDG
>environment with trinity.sh. I currently have:
>
>What additional can we do/(do better) with the environment setup?
As I wrote previously, Debian based distros do not use
/etc/profile.d. We need to explore how to modify the XDG_*variables
without using /etc/profile.d.
>+1 When I was shopping desktops, it was not uncommon to have kde3,
>kde4, wm2
>fvmwm2, e-16, e-17, gnome, fluxbox, twm, blackbox, openbox, etc.
>all installed
>simultaneously. The only real havoc was caused by kde3/kde4/gnome.
>That's why
>the X11 project put out an entire menuing standard to handle what
>is isn't
>visible in each desktop. I've picked through the standard, but
>never compared
>between what we have and what is says. Further, in doing so, I
>don't ever recall
>seeing a clean way of preventing the kde3/kde4/gnome menu mess. It
>is almost as
>if there is a need for a global 'menuedit' to manage /etc/xdg/menu
>on a global
>and per/user basis to include/exclude apps in menus when multiple
>desktop environments are installed.
The menus we now install work well enough within Trinity. We have
the option to compile with a "[KDE]" suffix. To reduce menu clutter
from duplicate naming, the default Trinity menu places all KDE menu
items in a separate "KDE" submenu. We also have an alternate menu
that must be installed manually that excludes all KDE menu items.
We probably should have a GUI option somewhere to swap those two
menu options.
The menu mess begins outside of Trinity.
Darrell
> Do you want a bug open on this one, or just push it? I think it
>is small
>enough just to push it. Get our fearless leader to comment, but
>unless someone
>wants a bug opened, I'd just push it if all give the nod.
I will push changes for the few *.desktop files discussed.
As I mentioned, the core problem is not OnlyShowIn=TDE but the
XDG_* environment variables. In the broader scheme, we have no
remedy for getting other environments to source /opt/trinity in the
XDG_* environment variables.
In distros that use /etc/profile.d, the solution is to ensure a
script is installed (could be nothing more than the normal
trinity.sh script). For the distros that don't use /etc/profile.d,
such as Debian, I don't know how to ensure XDG_* variables are
modified to recognize /opt/trinity.
As I mentioned, when KDE4 is concurrently installed with Trinity,
the result will be a menu mess one way or another, unless we
provide distro maintainers a more organized menu structure to
handle the KDE4/Trinity overload.
Some might ask, why would users install Trinity and use a different
environment? Many users prefer window managers rather than full
desktops, but prefer a selection of apps from the full desktop
environments. Many systems are multi-user, and the various users
select what to run. In those instances, all options must be
installed.
There is a growing restlessness in the KDE4 community for PIM apps
that do not rely on the akonadi/nepomuk foundation. Trinity PIM
apps could fill that role, but without modifying the XDG_*
environment variables, the apps won't be found in non-Trinity
desktops.
Darrell
>This topic deserves further investigation.
Some quick testing reveals the problem experienced by the blog
author is the XDG environment variables.
That said, here is a list of Trinity *.desktop files using
OnlyShowIn=TDE
==========================================================
applications/adept/adept/notifier/adept_notifier_auto.desktop
applications/desktop-effects-tde/desktop-effects-tde.desktop
applications/gtk-qt-engine/kcm_gtk/kcmgtk.desktop
applications/knutclient/src/knutclient.desktop
applications/krusader/krusader/krusader_root-mode.desktop
applications/tde-guidance/powermanager/guidance-power-
manager.desktop
libraries/pytdeextensions/pytdeextensions.desktop
tdebase/kappfinder/kappfinder.desktop
tdebase/kcontrol/kcontrol/KControl.desktop
tdebase/kcontrol/randr/tderandrtray.desktop
tdebase/kdesktop/init/Home.desktop
tdebase/kdesktop/init/System.desktop
tdebase/kfind/Kfind.desktop
tdebase/khelpcenter/Help.desktop
tdebase/kicker/kicker/kcmkicker.desktop
tdebase/kicker/kicker/panel.desktop
tdebase/klipper/klipper.desktop
tdebase/kmenuedit/kmenuedit.desktop
tdebase/konqueror/Home.desktop
tdebase/konqueror/preloader/konqy_preload.desktop
tdebase/kpersonalizer/kpersonalizer.desktop
tdebase/ktip/ktip.desktop
tdebase/tdescreensaver/KBlankscreen.desktop
tdebase/tdescreensaver/KRandom.desktop
tdelibs/tdeabc/tdeab2tdeabc.desktop
tdelibs/tderesources/tderesources.desktop
tdemultimedia/arts/builder/artsbuilder.desktop
tdemultimedia/arts/builder/x-artsbuilder.desktop
tdemultimedia/arts/tools/artscontrol.desktop
tdemultimedia/arts/tools/artscontrolapplet.desktop
tdemultimedia/kmix/kmix.desktop
tdemultimedia/kmix/restore_kmix_volumes.desktop
tdenetwork/filesharing/advanced/kcm_sambaconf/kcmsambaconf.desktop
tdepim/kalarm/kalarm.desktop
tdepim/korganizer/korgac/korgac.desktop
tdepim/tdeabc/tdeabcdistlistupdater/tdeabcdistlistupdater.desktop
tdeutils/kdf/kwikdisk.desktop
tdeutils/superkaramba/src/superkaramba.desktop
==========================================================
From this list, I think only the following are candidates for
change:
tdepim/kalarm/kalarm.desktop -> NotShowIn=KDE
tdepim/korganizer/korgac/korgac.desktop -> NotShowIn=KDE
tdeutils/kdf/kwikdisk.desktop -> NotShowIn=KDE
Of the remaining Trinity *.desktop files, the question remains
whether any TDE app that has the same name as in KDE4 should use
NotShowIn=KDE. Such a change would be noticeable only when a user
or admin modifies the XDG_* environment variables to search
/opt/trinity. When KDE4 and Trinity are installed concurrently, any
such change would remove the Trinity version from the menu and
leave only the KDE4 version.
I think a better strategy is find a way to improve the menus of
other environments.
There are two anomalies:
NotShowIn=GNOME:
tdebase/konqueror/konquerorsu.desktop
tdebase/ksysguard/gui/x-ksysguard.desktop
Darrell
> There are a number of png files in TDE that generate errors on
>opening due to
>outdated png header information. I would like to identify which
>icons these are.
>For example when opening khelpcenter I receive the following
>messages:
>
>03:03 valhalla:~> khelpcenter help:/khelpcenter/releasenotes
>khelpcenter: WARNING: Main template file name is empty.
>libpng warning: iCCP: known incorrect sRGB profile
>libpng error: IDAT: invalid distance too far back
>libpng error: IDAT: invalid distance too far back
>libpng error: IDAT: invalid distance too far back
>libpng warning: Interlace handling should be turned on when using
>png_read_image
>libpng error: IDAT: invalid distance too far back
>libpng error: IDAT: invalid distance too far back
>libpng error: IDAT: invalid distance too far back
>libpng warning: Interlace handling should be turned on when using
>png_read_image
>
> Apparently, the problem is out-of-date png header information.
>Searching I
>stumbled across a minimal bit of source that is supposed to fix
>the issue, but
>only if compiled on older versions of libpng. Looking at the code,
>the crux of
>it is to rewrite the first 8 bytes of the png header. I've
>attached it for
>experimentation. It builds well on all of the boxes I have, but I
>suspect you
>have to force it to build against libpng 1.2 in order for it to do
>what it is
>supposed to. I'll continue to experiment. If you have few spare
>minutes give it
>a try and let me know if you can see any discernible difference in
>the new/old
>png files. I haven't yet.
This is a bug report against newer versions of libpng. I don't seen
any such errors with libpng 1.4.12.
I suspect a rite of initiation to become a libpng developer is to
introduce new code that breaks something for everybody downstream.
Cousins to the BOFH.
Darrell
>Well, I did a cursory test ages ago just to get a handle on what
>had
>CMakeLists.txt and what didn't. If we could identify solid
>criteria like you
>suggested "directories with both CMakeLists and Makefile.am"
>files, then it
>would be a simple process of walking the git tree with 'find' and
>identifying
>apps which met the checks and those that partially met and those
>that were just
>autofoo.
>
>One issue I see is the use of .in.in and .in instead of .am, so we
>may need a
>fairly broad search of the variants of Makefile.am, configure.blah
>to get a
>valid picture of the state of the build setup.
>
>I'll look for some tests, if you can think of others, let us know.
>
>Everybody else as well.
Here is a preliminary list of modules converted to cmake that
contain directories with a Makefile.am but no corresponding
CMakeLists.txt. The list offers no conclusions. Just a list. Which
items are legitimate remains to be investigated.
amarok/amarok/src/engine/helix
amarok/amarok/src/engine/helix/config
amarok/amarok/src/engine/helix/helix-sp
amarok/amarok/src/engine/kdemm
amarok/amarok/src/engine/mas
amarok/amarok/src/engine/nmm
amarok/amarok/src/engine/nmm/icons
amarok/amarok/src/metadata/speex
amarok/amarok/src/metadata/trueaudio
amarok/amarok/src/metadata/wavpack
amarok/amarok/src/scripts/graphequalizer
amarok/amarok/src/sqlite
dolphin/doc
dolphin/doc/en
dolphin/po
knetworkmanager8/knetworkmanager-0.8/introspection
knetworkmanager8/knetworkmanager-0.8/po
knetworkmanager8/knetworkmanager-0.8/vpn-plugins
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/openvpn
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/openvpn/src
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/pptp
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/pptp/src
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/strongswan
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/strongswan/src
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/vpnc
knetworkmanager8/knetworkmanager-0.8/vpn-plugins/vpnc/src
tdebase/doc/kappfinder
tdebase/kcontrol/accessibility
tdebase/kcontrol/smartcard
tdebase/khelpcenter/htmlsearch
tdebase/kicker/applets/swallow
tdebase/kicker/kicker/plugins
tdebase/kicker/menuext/tom
tdebase/konqueror/sidebar/test
tdebase/konsole/doc
tdebase/konsole/doc/VT100
tdebase/ksysguard/ksysguardd/FreeBSD
tdebase/ksysguard/ksysguardd/Irix
tdebase/ksysguard/ksysguardd/NetBSD
tdebase/ksysguard/ksysguardd/OpenBSD
tdebase/ksysguard/ksysguardd/Solaris
tdebase/ksysguard/ksysguardd/Tru64
tdebase/libkonq/tests
tdebase/nsplugins/test
tdebase/nsplugins/wrapper
tdebase/tdeprint/descriptions
tdebase/twin/clients/kwmtheme
tdebase/twin/clients/kwmtheme/cli_installer
tdebase/twin/clients/test
tdebase/twin/tools
tdebase/twin/tools/decobenchmark
tdegraphics/ksvg/plugin/backends/agg
tdegraphics/kview/kviewcanvas/test
tdegraphics/kview/kviewviewer/test
tdegraphics/kview/modules/scale
tdegraphics/kview/modules/template
tdelibs/arts/kde/mcop-dcop
tdelibs/dcop/tests
tdelibs/doc/tdelibs
tdelibs/interfaces/terminal/test
tdelibs/kate/plugins/autobookmarker
tdelibs/kded/test
tdelibs/libtdemid/tests
tdelibs/tdeabc/plugins/evolution
tdelibs/tdeabc/plugins/sql
tdelibs/tdeabc/scripts
tdelibs/tdeabc/tests
tdelibs/tdecore/tdeconfig_compiler/example
tdelibs/tdecore/tdeconfig_compiler/tests
tdelibs/tdecore/tests
tdelibs/tdehtml/java/tests
tdelibs/tdeinit/tests
tdelibs/tdeio/tdefile/tests
tdelibs/tdeioslave/http/kcookiejar/tests
tdelibs/tdemdi/test
tdelibs/tdeparts/tests
tdelibs/tdeprint/foomatic
tdelibs/tdeprint/lpd
tdelibs/tdeprint/tests
tdelibs/tdespell2/tests
tdelibs/tdestyles/klegacy
tdelibs/tdestyles/web
tdelibs/tdeui/colors
tdelibs/tdeutils/tests
tdelibs/tdewallet/backend/tests
tdelibs/tdewallet/tests
tdelibs/tdewidgets/tests
tdenetwork/kopete/kopete/chatwindow/tests
tdenetwork/kopete/libkopete/compat
tdenetwork/kopete/libkopete/tests
tdenetwork/kopete/libkopete/tests/mock
tdenetwork/kopete/plugins/smpppdcs/unittest
tdenetwork/kopete/protocols/groupwise/libgroupwise/tasks/tests
tdenetwork/kopete/protocols/groupwise/libgroupwise/tests
tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples
tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples/ca
ll
tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples/lo
gin
tdenetwork/kopete/protocols/oscar/liboscar/tests
tdenetwork/kopete/protocols/yahoo/libkyahoo/tests
tdenetwork/ksirc/puke
tdepim/certmanager/lib/backends/kpgp
tdepim/certmanager/lib/tests
tdepim/indexlib/tests
tdepim/karm/test
tdepim/kitchensync/opensyncdbus
tdepim/kmail/tests
tdepim/kmobile/tdeioslave
tdepim/kmobile/tdeioslave/mimetypes
tdepim/kode/kwsdl
tdepim/kode/kwsdl/kung
tdepim/kode/kwsdl/schema
tdepim/kode/kwsdl/tests
tdepim/kode/kwsdl/tests/google
tdepim/kode/kwsdl/wscl
tdepim/kontact/plugins/kitchensync
tdepim/kontact/plugins/kpilot
tdepim/kontact/plugins/test
tdepim/korganizer/plugins/printing/list
tdepim/korganizer/plugins/printing/whatsnext
tdepim/korganizer/plugins/projectview
tdepim/korganizer/plugins/timespanview
tdepim/ktnef/tests
tdepim/libemailfunctions/tests
tdepim/libkcal/tests
tdepim/libkmime/tests
tdepim/libksieve/tests
tdepim/libtdenetwork/libgpg-error-copy
tdepim/libtdenetwork/libgpgme-copy
tdepim/libtdenetwork/libgpgme-copy/assuan
tdepim/libtdenetwork/libgpgme-copy/gpgme
tdepim/libtdenetwork/qgpgme/tests
tdepim/libtdepim/cfgc
tdepim/libtdepim/interfaces
tdepim/libtdepim/komposer
tdepim/libtdepim/komposer/core
tdepim/libtdepim/komposer/core/tests
tdepim/libtdepim/komposer/plugins
tdepim/libtdepim/komposer/plugins/default
tdepim/libtdepim/komposer/test
tdepim/libtdepim/tests
tdepim/tdeabc/frontend
tdepim/tdefile-plugins/palm-databases
tdepim/tdefile-plugins/rfc822
tdepim/tdeioslave/opengroupware
tdepim/tderesources/blogging
tdepim/tderesources/groupware
tdepim/tderesources/tvanytime
tdesdk/doc/kapptemplate
tdesdk/kbabel/kbabeldict/modules/dbsearchengine2
tdesdk/poxml/antlr/antlr
tdesdk/tdeunittest/example
tdesdk/tdeunittest/example/module
tdesdk/tdeunittest/example/simple
tdesdk/umbrello/umbrello/autolayout
tdevelop/buildtools/lib/parsers/autotools/tests
tdevelop/buildtools/lib/parsers/qmake/tests
tdevelop/doc/kdearch
tdevelop/doc/tools
tdevelop/kdevdesigner/plugins
tdevelop/languages/cpp/app_templates/generichello
tdevelop/languages/cpp/app_templates/gnome2mmapp
tdevelop/languages/cpp/app_templates/kmake
tdevelop/languages/cpp/app_templates/prc-tool
tdevelop/languages/java/newclass_templates
tdevelop/languages/kjssupport
tdevelop/languages/kjssupport/subclassing_template
tdevelop/languages/kjssupport/template
tdevelop/parts/documentation/plugins/djvu
tdevelop/parts/documentation/plugins/pdb
tdevelop/parts/documentation/plugins/pdf
Darrell
>Perhaps it is worth do a complete check of what is completed and
>what not. That means check every single package.
I agree. How?
For example, dolphin was listed in the etherpad as completed. Yet I
compiled dolphin with cmake and no doc or po files were compiled.
Therefore I deleted the 'completed' tag in the etherpad and wrote a
note.
I know that not all components of amarok were converted and I filed
a bug report against that a very long time ago.
As I mentioned, the cmake packages do not build man pages. Another
bug report filed.
This is part of why I am suspicious of whether all packages have
been converted completely.
To my knowledge we no longer can build the core packages with
automake. Only cmake. Therefore the only file-by-file comparison we
can attempt is with a fully compiled 3.5.13.2 package. We have to
account for the renaming changes. Yet everybody builds packages
differently. Using a 3.5.13.2 package as a baseline does not mean
all components were compiled.
Darrell
Hi all!
Could sombody please send me a build script for debian?
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA.