>I would like to tag the current sources and binaries R14.0.0 RC1,
>as it
>appears that we have finally cleared the Blocker and Critical
>reports from
>the R14 Etherpad.
>
>Are we ready for this or are there any objections?
The etherpad hasn't received updates in a while. We need some
hacking.
Blocker:
========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd
=Blocker
Critical:
=========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd
=Critical
Michele is working on 1825, but could use help. That is an ugly bug
from a public relations perspective. The comments provide a lot of
details.
1853 needs attention.
1821 hasn't been touched.
1813 can be closed after the last comment is implemented.
Regressions:
============
1825 is bad (already mentioned in Critical). The others should
receive attention but probably could survive the R14.0.0 cut.
Patches Available:
==================
Lots of patches sitting out there that have not been reviewed.
Likely many could be pushed.
Other:
======
* The new web site should be tested before moving toward a release
date.
* There is a laundry list of items in the R14 checklist etherpad
that need attention.
Darrell
All,
I would like to tag the current sources and binaries R14.0.0 RC1, as it
appears that we have finally cleared the Blocker and Critical reports from
the R14 Etherpad.
Are we ready for this or are there any objections?
Thanks!
Tim
>A bit strange, but yes, I now have the cups.sock interface, but I
>have a catch
>22 that prevents remote printer setup. As a user, you do not have
>sufficient to
>generate ppd files for this printer at home (normal HP Laserjet
>4). In
>administrator mode, after selecting the printer and pressing
>'Next' the select
>printer driver page loads, but the Manufacturer List and Printer
>List are blank
>-- nada....
>
>Have a look:
>
>That's one I can't explain. (1) user sees manufacturer and
>printers, but can't
>gen the ppd, (2) root just can't see the printer in order to be
>able to generate
>the ppd file. (God I miss the days of just selecting the PPD
>instead of a
>autogenerate on the fly scheme...)
>
>Any thoughts?
Share the exact steps.
That you see a list of available printers probably means CUPS is
configured correctly.
My printer is connected as a network device. After you share the
exact steps I'll try to duplicate here.
Darrell
>> I've seen this before, when logging in with the same account
>> between two systems that have different sound hardware.
>>
>> Try terminating kmix, delete the two kmix* rc files, then start
>> kmix.
>>
>Good thought. I killed it, removed the
>.trinity/share/config/kmixrc and
>restarted. No change and no regeneration of kmixrc. I'll keep
>poking at the
>underlying sound system to see if there is something there causing
>the issue.
After deleting the two kmixrc* files, the default should be to
autostart. If kmix is not autostarting, then try manually starting
from the command line.
Darrell
>I have a proposal for a new script :)
>
>The primary difference is that the patches are referenced directly
>into
>the GIT => do not need separate files with patches, not need
>additional
>space for these files. To generate the page so just processing the
>output
>from: git submodule foreach "git log ..." (yes, there is a little
>magic
>due to multiline comments). On my elderly machine this takes 16
>seconds.
>
>A side effect is that each commit is in html a single line - it
>might be
>easy to add pagination option.
>
>What do you think?
I just want to see something that we can use locally. The web page
is great for visitors and community members. But those of us on the
development team should have a way of creating the same list
locally. I'll be happy to test anything like that.
Darrell
>>> >I can't find it in the Service Manager. What's the trick for
>>> >finding it?
>> Shame on me: There is no GUI control. Refer to bug report 1613.
>>
>> Edit tdenetworkmanagerrc:
>>
>> [General]
>> Autostart=false
>
>The file did not exist. (I guess the crash occurs before the point
>of
>tdenetworkmanagerrc generation). I created it and it works as
>expected. It seems
>like we should have a Service Manger toggle for that one. (flag it
>for R15)
tdenetworkmanager is an app and not a service. That said, bug
report 1613 addresses the issue of no GUI method to control
autostart.
I tested moving my tdenetworkmanagerrc file. tdenetworkmanager
started but no rc file was created initially. When I terminated
tdenetworkmanager from the popup menu and responded to the dialog
not to ask me again, then the rc file created. Seems then the rc
file normally is not created.
Darrell
>Oh, it's autostarting every time - it just comes up with a big red
>X over it and
>and it is dead as a doornail. Can't find any mixer, nothing..
Place the following at the top of kmixrc:
Autostart=false
The key and value goes at the top of the rc file. No group category.
Then with no autostarting, after Trinity starts, open konsole and
start kmix manually. Hopefully the stdout/stderr provides a clue.
Darrell
>Please, with RC1, I would suggest a few more days to wait. First,
>I'm
>briefly before completing the patch for tdepowersave (see bug
>1597), I
>would like to incorporate this patch before RC1. Furthermore, we
>should
>check and fix all FTBFS caused by recent patches.
Perhaps not just FTBFS, but as many build issue reports as possible:
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd
=Build%20issues
I would like to see us push as many PATCHAVAIL as possible. Many
people put in the effort to supply patches. We should thank them by
pushing the patches if possible.
I'm working continually on the help handbooks. At the pace we're
going, I think I'll be complete with most of the major interface
issues before RC1. But we have lots to do between now and an
agreement of declaring RC1.
Darrell
>Ah, then TDevelop pages are just more to throw on the heap. A few
>meetings
>today, then I'll add TDevelop to the etherpad. If you have any
>other etherpads
>currently in use that would be a better place for the TDevelop
>stuff, let me know.
TDevelop is somewhat a mess: a hodge-podge mixture of tdev* and
kdev* naming. Horribly inconsistent. We need to perform massive
renaming on tdevelop much like we did recently with tdebindings. I
started working on this several weeks aog, but then got entrenched
in the help handbook surgeries.
We should perform this before RC1.
Darrell
> I don't know if you have opened TDevelop and looked for any of
>the help pages,
>but apparently there is a problem with the search path to the
>help/man files for
>a lot of the information can't be found. TDevelop looks like it is
>operating
>correctly, but most pages (including help pages for TQt, TQt
>Designer and TQt
>Assistant) can't be found. Here is what is working/not working:
>
>libxml2 API pages -- working
>libglade -- working
>User Agent Acces.. -- working
>SVG Pages -- working
>SDL Pages -- Man Page Dependent
>OpenGL -- Man Page Dependent
>KDevelop API Docs -- NOT working (bad links?)
>Document Object Mod -- working
>The KDE API Reference -- NOT working (bad path?)
>qmake User Guide -- NOT working
>TQt Reference Docs -- NOT working
>TQt Designer Manual -- NOT working
>TQt Assistant Manual -- NOT working
>Guide of the TQt Trans. -- NOT working
Refer to bug report 1859. :)
Darrell