>And... the only reason I got a working printer is I made myself a
>member of the
>'sys' group otherwise creation of /etc/cups/printer.conf would
>have failed due
>to lack of permission. Since I was a member of the sys group,
>permission for
>cups operation was satisfied, however, apparently printer driver
>generation with
>the 'foomatic-db-generation' package uses another scheme prompting
>the error.
>How to solve for a normal user?
I believe users have to be a member of the lp group. Perhaps that
is the root cause of the problems?
Darrell
>Hah - knew it. Story of my life...
Be aware when you update your local repo that you have to update
your build script configurations for sip4-tqt and python-tqt.
Slavek and Francois snookered all of us with some patches. :)
I've updated my build script environment. Copy those build scripts.
The full grimy details are in bug report 1790.
Darrell
> That raised the question, do we have a list somewhere of what
>has been
>renamed? Some things have been renamed 'k'->'t' others 'k'->'tde'
>others not
>renamed at all. Doing 'tcmshell --list | sort' somewhat
>exemplifies the problem.
Do you have a full install of 3.5.13.2? If yes then grab a list of
/opt/trinity/bin and /opt/trinity/lib. We then can diff that list
to R14.
Darrell
>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
>As I mentioned, a side effect of the processing git log in the
>proposed script
>is that each commit is on output in a single line. This would be
>possible to
>simply add the pagination.
>
>For example - adding one simple "sed" to a previously sent crazy
>command for
>listing on the console... see attached script.
Okay. Thank you. :)
Darrell
>Hmmm.. No release notes :(
>
>How long ago did you push them? My first build was on tarballs
>from 1/15 -- and
>I got not releasenotes. They come from tdebase correct?
Commit 32f7a85c, 2014-01-19.
Looks like you are 4 days late and a dollar short. :)
Darrell
>You are correct that the CPU use is in the 3-5% range, that in
>itself isn't the
>problem. The problem is that it is ALWAYS 3-5% and ALWAYS at the
>top of the
>list. That signifies a runaway process in tdepowersave that is not
>playing
>nicely. tdepowersave should only require 3-5% of the cpu when it
>does something,
>not continually. tdepowersave should only be monitoring input and
>starting
>timers, screensavers, suspend, etc.... Those are all negligible
>and darn sure
>less that was X is doing. So there is a live Gremlin in
>tdepowersave somewhere....
Yes, I understood that ALWAYS 3% is an unhealthy indication. That
was what I was implying when I shared that kmix and knotification-
daemon were always at about 2%.
I don't know whether Slavek's patch will remedy the ALWAYS problem,
but we should look at all three apps for why they are consistently
at the top of top.
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
> Messing with tdepowersave I ran into a problem figuring out what
>kcmshell was
>called. I tried Alt+F2:
>
> kcmshell foo
> tcmshell foo
> tdecmshell foo - Bingo!
>
> That raised the question, do we have a list somewhere of what
>has been
>renamed? Some things have been renamed 'k'->'t' others 'k'->'tde'
>others not
>renamed at all. Doing 'tcmshell --list | sort' somewhat
>exemplifies the problem.
>
> I was thinking some khelpcenter (t,tde)helpcenter page called
>something like
>"Trinity Desktop Naming Cross-reference" that would simple provide
>a brief
>introduction that in order to avoid name conflict with KDE4, the
>following files
>and modules have been renamed:
>
>kfoo1 -> tfoo1
>kfoo2 -> tfoo2
>...
>
> Absolutely falls under the 'nice to have' not 'need to have'
>column, but if it
>doesn't exist, then we may want to collect a list of obvious
>things that users
>might experience difficulty with and include those in the list.
>Like:
>
>kcmshell -> tdecmshell
You're a day late and a dollar short. :)
A list is available in the release notes. To read the release
notes, open the "Welcome to TDE" handbook and then select the "TDE
Release Notes" link.
Or run the following:
khelpcenter help:/khelpcenter/releasenotes
For new R14 users, this document appears once and once only after
starting Trinity the first time in R14. Likewise for git users.
Now the interesting twist: somehow kcmshell->tdecmshell slipped
through the cracks and is not in the list. I'll push a patch to the
docbook file. :)
Darrell
Darrell, All,
Messing with tdepowersave I ran into a problem figuring out what kcmshell was
called. I tried Alt+F2:
kcmshell foo
tcmshell foo
tdecmshell foo - Bingo!
That raised the question, do we have a list somewhere of what has been
renamed? Some things have been renamed 'k'->'t' others 'k'->'tde' others not
renamed at all. Doing 'tcmshell --list | sort' somewhat exemplifies the problem.
I was thinking some khelpcenter (t,tde)helpcenter page called something like
"Trinity Desktop Naming Cross-reference" that would simple provide a brief
introduction that in order to avoid name conflict with KDE4, the following files
and modules have been renamed:
kfoo1 -> tfoo1
kfoo2 -> tfoo2
...
Absolutely falls under the 'nice to have' not 'need to have' column, but if it
doesn't exist, then we may want to collect a list of obvious things that users
might experience difficulty with and include those in the list. Like:
kcmshell -> tdecmshell
--
David C. Rankin, J.D.,P.E.