Refresh my new plasmoid - reparse source - kde-plasma

I'm learning how to develop Kde Plasma 5 plasmoids, and testing it with a small widget, consistent of just two qmls. I read some information sources, like https://techbase.kde.org or https://api.kde.org/frameworks/ and created a package structure and sources for my test plasmoid, which looks like this:
$ ls -lR test
test:
total 8
drwxr-xr-x 3 alberto alberto 4096 nov 26 14:28 contents
-rw-r--r-- 1 alberto alberto 459 nov 26 14:28 metadata.desktop
test/contents:
total 4
drwxr-xr-x 2 alberto alberto 4096 nov 26 14:33 ui
test/contents/ui:
total 8
-rw-r--r-- 1 alberto alberto 275 nov 26 14:28 main.qml
-rw-r--r-- 1 alberto alberto 465 nov 26 14:33 RootContainer.qml
The RootContainer is just the fullRepresentation of the widget, and contains only a label with the text "prueba1". So, as i read in the documentation, i used the command plasmapkg2 to install the widget as follows:
$ plasmapkg2 --install test
pluginname: "org.matrixland.test"
Generated "/home/xxx/.local/share/plasma/plasmoids//kpluginindex.json" ( 3 plugins)
/home/xxx/Programación/proyectos/plasmoides/test instalado con éxito
Then, i can use it in the kde desktop and everything is fine. It is shown in the desktop, with the text label.
But now, if i change the text of the label, "prueba2", and i remove and reinstall the plugin as follows
$ plasmapkg2 --remove test
Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for "" instead of kservice_desktop_to_json() in your CMake code.
Calling KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated, use KPluginInfo::pluginName() in "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/packagestructure/plasma_packagestructure_share.so" instead.
Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for "" instead of kservice_desktop_to_json() in your CMake code.
Calling KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated, use KPluginInfo::pluginName() in "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/packagestructure/plasma_packagestructure_share.so" instead.
Generated "/home/xxx/.local/share/plasma/plasmoids//kpluginindex.json" ( 2 plugins)
/home/xxx/Programación/proyectos/plasmoides/test desinstalado con éxito
>xxx#eleanor:~/Programación/proyectos/plasmoides$ plasmapkg2 --install test
pluginname: "org.matrixland.test"
Generated "/home/alberto/.local/share/plasma/plasmoids//kpluginindex.json" ( 3 plugins)
/home/alberto/Programación/proyectos/plasmoides/test instalado con éxito
If now, i add it again to the desktop, i see the old text instead of the new one. I checked in the /home/xxx/.local/share/plasma/plasmoids/org.matrixland.test directory that the source is up to date and refreshed, so i can't guess why am i obtaining the old text instead of the new one.
Obviously my problem is that none of the changes i make in the qml is reflected in the widget, not only text changes. I don't know if i am doing something wrong, or if i must do anything else to update the widget. Can anybody help me with that?

This is because the old QML is "cached" still. You'll need to restart plasmashell in order to see the changes.
killall plasmashell; kstart5 plasmashell
I used this script to reinstall applets when I want to test live. When I want to test quickly though, I'll use plasmoidviewer with:
plasmoidviewer -a package -l bottomedge -f horizontal
like in this script.

Related

What is the difference between the permissions tags -rwxr-xr-x and -rwxrwxrwx?

Before trying to assemble sequence data, I get a file size estimate for my raw READ1/READ2 files by running the command ls -l -h from the directory the files are in. The output looks something like this:
-rwxrwxrwx# 1 catharus2021 staff 86M Jun 11 15:03 pluvialis-dominica_JJW362-READ1.fastq.gz
-rwxrwxrwx# 1 catharus2021 staff 84M Jun 11 15:03 pluvialis-dominica_JJW362-READ2.fastq.gz
For a previous run using the identical command, but a different batch of data, the output was as such:
-rwxr-xr-x 1 catharus2021 staff 44M Mar 16 2018 lagopus_lagopus_alascensis_JJW1970_READ1.fastq.gz
-rwxr-xr-x 1 catharus2021 staff 52M Mar 16 2018 lagopus_lagopus_alascensis_JJW1970_READ2.fastq.gz
It doesn't seem to be affecting any downstream commands, but does anyone know why the strings at the very beginning (-rwxrwxrx# vs. -rwxr-xr-x) are different? I assume that they're permissions flags, but google has been less-than-informative when I try to type those in and search.
Thanks in advance for your time.
The coding describes who can access a file in which way. It is oredred:
owner - group - world
rwxr-xr-x
user can read, write and execute
group can only read and execute
world can only read and execute
This prevents that other people can overwrite your data. If you change to
rwxrwxrwx
Everybody can overwrite your data.

How to get information on latest successful pod deployment in OpenShift 3.6

I am currently working on making a CICD script to deploy a complex environment into another environment. We have multiple technology involved and I currently want to optimize this script because it's taking too much time to fetch information on each environment.
In the OpenShift 3.6 section, I need to get the last successful deployment for each application for a specific project. I try to find a quick way to do so, but right now I only found this solution :
oc rollout history dc -n <Project_name>
This will give me the following output
deploymentconfigs "<Application_name>"
REVISION STATUS CAUSE
1 Complete config change
2 Complete config change
3 Failed manual change
4 Running config change
deploymentconfigs "<Application_name2>"
REVISION STATUS CAUSE
18 Complete config change
19 Complete config change
20 Complete manual change
21 Failed config change
....
I then take this output and parse each line to know which is the latest revision that have the status "Complete".
In the above example, I would get this list :
<Application_name> : 2
<Application_name2> : 20
Then for each application and each revision I do :
oc rollout history dc/<Application_name> -n <Project_name> --revision=<Latest_Revision>
In the above example the Latest_Revision for Application_name is 2 which is the latest complete revision not building and not failed.
This will give me the output with the information I need which is the version of the ear and the version of the configuration that was used in the creation of the image use for this successful deployment.
But since I have multiple application, this process can take up to 2 minutes per environment.
Would anybody have a better way of fetching the information I required?
Unless I am mistaken, it looks like there are no "one liner" with the possibility to get the information on the currently running and accessible application.
Thanks
Assuming that the currently active deployment is the latest successful one, you may try the following:
oc get dc -a --no-headers | awk '{print "oc rollout history dc "$1" --revision="$2}' | . /dev/stdin
It gets a list of deployments, feeds it to awk to extract the name $1 and revision $2, then compiles your command to extract the details, finally sends it to standard input to execute. It may be frowned upon for not using xargs or the like, but I found it easier for debugging (just drop the last part and see the commands printed out).
UPDATE:
On second thoughts, you might actually like this one better:
oc get dc -a -o jsonpath='{range .items[*]}{.metadata.name}{"\n\t"}{.spec.template.spec.containers[0].env}{"\n\t"}{.spec.template.spec.containers[0].image}{"\n-------\n"}{end}'
The example output:
daily-checks
[map[name:SQL_QUERIES_DIR value:daily-checks/]]
docker-registry.default.svc:5000/ptrk-testing/daily-checks#sha256:b299434622b5f9e9958ae753b7211f1928318e57848e992bbf33a6e9ee0f6d94
-------
jboss-webserver31-tomcat
registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift#sha256:b5fac47d43939b82ce1e7ef864a7c2ee79db7920df5764b631f2783c4b73f044
-------
jtask
172.30.31.183:5000/ptrk-testing/app-txeq:build
-------
lifebicycle
docker-registry.default.svc:5000/ptrk-testing/lifebicycle#sha256:a93cfaf9efd9b806b0d4d3f0c087b369a9963ea05404c2c7445cc01f07344a35
You get the idea, with expressions like .spec.template.spec.containers[0].env you can reach for specific variables, labels, etc. Unfortunately the jsonpath output is not available with oc rollout history.
UPDATE 2:
You could also use post-deployment hooks to collect the data, if you can set up a listener for the hooks. Hopefully the information you need is inherited by the PODs. More info here: https://docs.openshift.com/container-platform/3.10/dev_guide/deployments/deployment_strategies.html#lifecycle-hooks

How to prevent ._ (dot underscore) files?

I am using Textmate 2 to edit a rails project on remote Linux server via sshfs.
When I save a file (e.g. README.rdoc) there is another file created (i.e. ._README.rdoc):
-rw-rw-r-- 1 4096 Feb 17 17:19 ._README.rdoc
-rw-rw-r-- 1 486 Feb 17 17:19 README.rdoc
The Textmate doc mentioned how to disable extended attributes:
defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1
but ._ files are still created after the above defaults write.
Is there a way to disable creation of ._ files when using sshfs + Textmate 2?
To disable Extended Attributes in Textmate 2, use:
defaults write com.macromates.TextMate.preview volumeSettings '{ "/Users/ohho/Mount/" = { extendedAttributes = 0; }; }'
Where /Users/ohho/Mount/ is the parent folder of all my sshfs mounted folders.
As I have tried with following command THIS IS NOT WORKING :
NOT WORKING:-"defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1"
I have taken reference from :
https://github.com/textmate/textmate/wiki/Hidden-Settings
and its working fine now.
TextMate use extended attributes to store caret position, etc.
On file systems which don’t support extended attributes
(most network file systems), OS X will create an auxiliary file with
a dot-underscore prefix (e.g. ._filename).
If you don’t want these files, you can disable the use of extended
attributes. This is presently controlled with the volumeSettings key.
Its values are (1) an associative array with path prefix; and (2) another associative array with settings for that path. (Presently, only extendedAttributes
is supported.)
So, if we wanted to disable extended attributes for files under /net/:
defaults write com.macromates.TextMate.preview volumeSettings '{ "/net/" = { extendedAttributes = 0; }; }'

How to remove -journal file without compromising the database?

I'm using SQLite and a php application that runs in background. I have blocked the application using (Ctrl-c) and I just noticed that i have database.sqlite and database.sqlite-journal.
At the moment, How can I remove -journal file without compromising the database?
Thank you!
P.S. SQLite version 3.7.9
EDIT:
-rw-r--r--. 1 damiano damiano 51M 8 mar 18.15 test.sqlite2
-rw-r--r--. 1 damiano damiano 2,6K 8 mar 18.15 test.sqlite2-journal
[damiano#localhost backup]$ sqlite3 test.sqlite2
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
[damiano#localhost backup]$ ls -lh
-rw-r--r--. 1 damiano damiano 51M 8 mar 18.15 test.sqlite2
-rw-r--r--. 1 damiano damiano 2,6K 8 mar 18.15 test.sqlite2-journal
[damiano#localhost backup]$
Execute this command:
sqlite3 test.sqlite2 vacuum
It will make your database as small as possible and apply possible outstanding transactions or rollbacks in -journal file (and remove it in process). You can actually execute any other transaction that does something (but simply connect/disconnect is NOT enough), but vacuum seems like easiest approach.
Just open the database (with your program or with the sqlite3 command-line tool).
SQLite will then roll back the changes of your interrupted transaction and afterwards remove the journal.

Re-structuring CVS repositories and retaining history

Currently, we have the following in our CVS Repository :
Module1
|
|
+-----A
|
+-----B
We want o restructure this module such that the sub directories A and B appears as high level modules. What I could do is to check Module1 out and then pull A and B out and then do a fresh cvs add for A and B individually, thus making them new cvs modules. But I am sure if I do this, I am going to lose the history as well as I would have to remove all internal CVS folders under A and B.
Q1: So is there a way to restructure this and retain the history?
What I essentially am trying to do is to filter out access between A and B.
So -
Q2: Is there a way to set up security so that certain users can check out Module1/A only and not Module1/B ? and vice-versa?
Q1: So is there a way to restructure this and retain the history?
Like you wrote in your comment, if you have sys privs you can mv modules around the repository and keep the history of all the files below A and B but in doing so, you lose the history that /A used to be Module1/A and /B used to be in Module1/B (not to mention build scripts probably break now). Subversion resolves this for you by offering the move (or rename) command which remembers the move/rename history of a module.
Q2: Is there a way to set up security so that certain users can check out Module1/A only and not Module1/B ? and vice-versa?
There sure is, used group permissions. From this page,
http://www.linux.ie/articles/tutorials/managingaccesswithcvs.php
Here's the snip I'm referring to in case that page ever goes away
To every module its group
We have seen earlier how creating a
cvsusers group helped with the
coordination of the work of several
developers. We can extend this
approach to permit directory level
check-in restrictions.
In our example, let's say that the
module "cujo" is to be r/w for jack
and john, and the module "carrie" is
r/w for john and jill. We will create
two groups, g_cujo and g_carrie, and
add the appropriate users to each - in
/etc/group we add
g_cujo:x:3200:john,jack
g_carrie:x:3201:john,jill>
Now in the repository (as root), run
find $CVSROOT/cujo -exec chgrp g_cujo {} \;
find $CVSROOT/carrie -exec chgrp g_carrie {} \;
ensuring, as before, that all
directories have the gid bit set.
Now if we have a look in the
repository...
john#bolsh:~/cvs$ ls -l
total 16
drwxrwsr-x 3 john cvsadmin 4096 Dec 28 19:42 CVSROOT
drwxrwsr-x 2 john g_carrie 4096 Dec 28 19:35 carrie
drwxrwsr-x 2 john g_cujo 4096 Dec 28 19:40 cujo
and if Jack tries to commit a change
to carrie...
jack#bolsh:~/carrie$ cvs update
cvs server: Updating .
M test
jack#bolsh:~/carrie$ cvs commit -m "test"
cvs commit: Examining .
Checking in test;
/home/john/cvs/carrie/test,v <-- test
new revision: 1.2; previous revision: 1.1
cvs [server aborted]: could not open lock file
`/home/john/cvs/carrie/,test,': Permission denied
jack#bolsh:~/carrie$
But in cujo, there is no problem.
jack#bolsh:~/cujo$ cvs update
cvs server: Updating .
M test
jack#bolsh:~/cujo$ cvs commit -m "Updating test"
cvs commit: Examining .
Checking in test;
/home/john/cvs/cujo/test,v <-- test
new revision: 1.2; previous revision: 1.1
done
jack#bolsh:~/cujo$
The procedure for adding a user is now
a little more complicated that it
might be. To create a new CVS user, we
have to create a system user, add them
to the groups corresponding to the
modules they may write to, and (if
you're using a pserver method)
generate a password for them, and add
an entry to CVSROOT/passwd.
To add a project, we need to create a
group, import the sources, change the
groups on all the files in the
repository and make sure the set gid
on execution bit is set on all
directories inside the module, and add
the relevant users to the group.
There is undoubtedly more
administration needed to do all this
than when we jab people with a pointy
stick. In that method, we never have
to add a system user or a group or
change the groups on directories - all
that is taken care of once we set up
the repository. This means that an
unpriveleged user can be the CVS admin
without ever having root priveleges on
the machine.