uncommit up to before merge - bazaar

When I have a history
-rev 100, merge
-- rev 95.3
-- rev 95.2
-- rev 95.1
-rev 99
-rev 98
and I try bzr uncommit -r 95.3.. it writes an error message. How can I fix the problem?
Error is
bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors
return run_bzr(argv)
File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
ret = run(*run_argv)
File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
return self.run(**all_cmd_args)
File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3694, in run
local=local)
File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3717, in _run
revno = revision[0].in_history(b).revno + 1
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
bzr 1.5 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'uncommit', '-r', '11955.2.32..']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'pl_PL.UTF-8'
plugins:
bzrtools /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools [1.5.0]
gtk /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk [0.94.0]
interactive /home/adi/.bazaar/plugins/interactive [1.2.0]
launchpad /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
rebase /home/adi/.bazaar/plugins/rebase [0.3.0]
*** Bazaar has encountered an internal error.
Please report a bug at https://bugs.launchpad.net/bzr/+filebug
including this traceback, and a description of what you
were doing when the error occurred.

This is really just a guess, but I suspect that the revision spec isn't accepting 95.3 as a revision.
The merge will have been committed to your branch as revision 100, so you should be able to just do:
bzr uncommit
or:
bzr uncommit -r 100
If you want to merge in changes 95.1 and 95.2 (part of the original merge), you will probably have to do:
bzr uncommit -r 100
bzr merge -r 95..97 /path/to/merge/source
or something like that.
If you need to refer to the 95.3, I'd recommend having a read of the Bazaar revision spec documentation to see if that helps. You may need a more explicit revision number such as revno:95.3 (which probably won't work) or revno:97:/path/to/merge/source (which might work). Most of that was a guess though...

You can't uncommit to dotted revision like 95.1.3, because this revision is not in your mainline history. You can use pull command instead to get your tree to desired revision:
bzr pull . -r95.1.3 --overwrite
The main difference between uncommit and pull is: uncommit leaves changes after revision to which you uncommit in the working tree, while pull simply overwrite your working tree with files of specified revision.
Also if you need to uncommit to the state just before merge you need to use bzr uncommit without specifying revisions if r100 is the last revision in the branch.

Related

GNU Radio TypeError: primitive_connect(): incompatible function arguments when executing simple graph

When trying to execute the following graph I get the error below. Any ideas what might be causing this? I'm on Ubuntu 20.10.
<<< Welcome to GNU Radio Companion 3.9.0.0-git >>>
Block paths:
/usr/share/gnuradio/grc/blocks
Loading: "/home/gnuradiouser/Dev/SDR/Lesson 1.grc"
>>> Done
Generating: '/home/gnuradiouser/Dev/SDR/Lesson_1.py'
Executing: /usr/bin/python3 -u /home/gnuradiouser/Dev/SDR/Lesson_1.py
Warning: failed to XInitThreads()
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] [UHD] linux; GNU C++ version 10.2.0; Boost_107100; UHD_3.15.0.0-3build2
Using HackRF One with firmware 2018.01.1
Traceback (most recent call last):
File "/home/gnuradiouser/Dev/SDR/Lesson_1.py", line 193, in <module>
main()
File "/home/gnuradiouser/Dev/SDR/Lesson_1.py", line 169, in main
tb = top_block_cls()
File "/home/gnuradiouser/Dev/SDR/Lesson_1.py", line 142, in __init__
self.connect((self.osmosdr_source_0, 0), (self.qtgui_freq_sink_x_0, 0))
File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped
func(self, src, src_port, dst, dst_port)
File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 100, in connect
self.primitive_connect(*args)
TypeError: primitive_connect(): incompatible function arguments. The following argument types are supported:
1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: gnuradio.gr.gr_python.basic_block) -> None
2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: gnuradio.gr.gr_python.basic_block, src_port: int, dst: gnuradio.gr.gr_python.basic_block, dst_port: int) -> None
Invoked with: <gnuradio.gr.gr_python.top_block_pb object at 0x7fac59391970>, <Swig Object of type 'gr::basic_block_sptr *' at 0x7fac575a4990>, 0, <gnuradio.gr.gr_python.basic_block object at 0x7fac5953a1f0>, 0
swig/python detected a memory leak of type 'gr::basic_block_sptr *', no destructor found.
>>> Done (return code 1)
I'm new to GNU Radio, so not sure where to start troubleshooting this issue. I've tried plugging in a signal generator instead of the osmocom source, and got the graph to execute, so I'm guessing there's a bad parameter in the osmocom object or a bad version of a library?
I've also tried installing an earlier version of GNU Radio (3.7 and 3.8), but couldn't get that going on Ubuntu 20.10.
Managed to resolve this, by uninstalling GNU Radio and removing the 'master' ppa repository sudo add-apt-repository ppa:gnuradio/gnuradio-master, which was in one of the installation instructions I came across.
After that I simply installed GNU Radio using the standard 20.10 repositories and all works fine now.

How do I get KDiff3 to auto merge with no UI?

How do I get KDiff3 to automatically do a 3-way merge such that it shows no UI? Ideally, if it succeeds, it returns success, and if it can't (it needs manual merging), it returns an error code.
Everything I've read seems to imply that the following should work:
"c:\Program Files\KDiff3\kdiff3.exe" --auto base.txt src.txt tar.txt -o merge.txt
However, it doesn't. When I run it, a message box pops up that says:
Total number of conflicts: 3
Nr of automatically solved conflicts: 3
Nr of unsolved conflicts: 0
How do I get it to run without this popup, and no GUI at all if it fails?
I figured it out. I need to add a "--cs" and "ShowInfoDialogs=0" to the command line. So this:
"c:\Program Files\KDiff3\kdiff3.exe" --auto base.txt src.txt tar.txt -o merge.txt
...becomes this:
"c:\Program Files\KDiff3\kdiff3.exe" --auto base.txt src.txt tar.txt -o merge.txt --cs "ShowInfoDialogs=0"
...and now it works.

How to upgrade odoo 8 to odoo 9 database?

I am trying to upgrade an odoo installation from 8.0 to 9.0. What I've done so far is the following:
Backup the odoo database from the production system
Installed the backup DB as test in my current system
Copied the odoo folder in a folder on my system
Checked, if everything works. It works!
Updated to the latest v8.0 version, still works
Did a git checkout 9.0 followed by a git pull.
Started odoo 9.0 with the command ./openerp-server -d testDB -u all
This commands breaks with the following error and does not update my database:
LINE 1: select model, transient from ir_model where state='manual'
^
, in query select model, transient from ir_model where state=%s
2015-10-26 00:37:29,823 4501 CRITICAL testDB openerp.service.server:
Failed to initialize database `testDB`.
Traceback (most recent call last):
File "/opt/odoo/openerp/service/server.py", line 885, in preload_registries
registry = RegistryManager.new(dbname, update_module=update_module)
File "/opt/odoo/openerp/modules/registry.py", line 385, in new
openerp.modules.load_modules(registry._db, force_demo, status, update_module)
File "/opt/odoo/openerp/modules/loading.py", line 279, in load_modules
loaded_modules, processed_modules = load_module_graph(cr, graph, status, perform_checks=update_module, report=report)
File "/opt/odoo/openerp/modules/loading.py", line 136, in load_module_graph
registry.setup_models(cr, partial=True)
File "/opt/odoo/openerp/modules/registry.py", line 185, in setup_models
cr.execute('select model, transient from ir_model where state=%s', ('manual',))
File "/opt/odoo/openerp/sql_db.py", line 139, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/openerp/sql_db.py", line 215, in execute
res = self._obj.execute(query, params)
ProgrammingError: column "transient" does not exist
LINE 1: select model, transient from ir_model where state='manual'
Are there any steps which I have to follow to upgrade the database or has everything to be done by hand? And if yes, what should I do? Obviously it failed because the specific column is non-existent in my database. But is there any update script because I fear, if I change this there will be the next error waiting for me.
Thanks in advance.
You can ask the odoo company to do that task for you by going to this link
.But they will charge money for that. If you can do it yourself here is the documentation on how to do that,
https://doc.therp.nl/openupgrade/intro.html
Option 2: We can use pgadmin(postgresql gui tool).Just select your database name and in the top you can see sql enabled,click it and issue an sql query to display all data(you must know the table name which you want to retreive) after that you can export it.The exported file contains all the data with column headings,we may have to rearrange columns according to odoo9 DB.Once it is done select odoo9 database,right click on the table name which you want to import data to and select import option.It may take a while and it should give message as "data imported successfully".
I found the answer on Github.
The trick is to create a field called transient which is Boolean with the default value false in the table ir_model.
As I expected, this is not the complete solution as there are other problem with the database needing adjustments.
You are trying to run a Odoo 8.0 database on Odoo 9.0.
The column 'transient' is in the code base for 9.0 and not in the 8.0 code base. Hence the 8.0 database is being ran on the 9.0 code base. Hence, the database has not been upgraded properly.
As stated in the previous answer. You can either get Odoo to do it or can do it yourself as well.

Bigquery query returning "pagetoken missing" - query works on other tables

So I have my bigquery tables split up by day - each table as that day's worth of data.
When running a select statement it seemed to work for some tables (for example adroit.raw_data_2013_12_09) but not for tables that are created over 3 days ago (for example adroit.raw_data_2013_12_05)
Here is the error readout:
bigquery service returned an invalid reply in query operation: pagetoken missing
for table '123856490061:_2863529bd240bcbd666b3debc039d3c62827fd67.anon64863979ca
e70f1bf67661ed0fafb2a8c5bb36e1'.
please make sure you are using the latest version of the bq tool and try again.
if this problem persists, you may have encountered a bug in the bigquery client.
google engineers monitor and answer questions on stack overflow, with the tag
google-bigquery:
http://stackoverflow.com/questions/ask?tags=google-bigquery
please include a brief description of the steps that led to this issue, as well
as the following information:
========================================
== platform ==
cpython:2.7.5:linux-2.6.26-2-xen-amd64-x86_64-with-debian-5.0.8
== bq version ==
v2.0.12
== command line ==
['/usr/local/bin/bq', 'query', '--max_rows=100000', '--format=csv', '-q', 'select count(*) as views, template_id, string_id, state_id, reel_1,reel_2,reel_3,reel_4,reel_5,reel_6,reel_7,reel_8,reel_9,reel_10 from adroit.raw_data_2013_12_03 where operation_type in (1,3) and template_id in (2659,2660,2661) group by template_id, string_id, state_id, reel_1,reel_2,reel_3,reel_4,reel_5,reel_6,reel_7,reel_8,reel_9,reel_10']
== utc timestamp ==
2013-12-10 23:15:43
== error trace ==
file "build/bdist.linux-x86_64/egg/bq.py", line 652, in runsafely
return_value = self.runwithargs(*args, **kwds)
file "build/bdist.linux-x86_64/egg/bq.py", line 932, in runwithargs
max_rows=self.max_rows)
file "build/bdist.linux-x86_64/egg/bq.py", line 383, in _printtable
fields, rows = client.readschemaandrows(table_dict, **extra_args)
file "build/bdist.linux-x86_64/egg/bigquery_client.py", line 668, in readschemaandrows
self.readtablerows(table_dict, max_rows))
file "build/bdist.linux-x86_64/egg/bigquery_client.py", line 649, in readtablerows
apiclienthelper.tablereference.create(**table_dict),))
========================================
unexpected exception in query operation: pagetoken missing for table '1238564900
61:_2863529bd240bcbd666b3debc039d3c62827fd67.anon64863979cae70f1bf67661ed0fafb2a
8c5bb36e1'
So I tried easy_install update and the script says that my bq client is up to date. I'm at a loss as to why I'm getting this error. Thanks.
Looks like you're using an old version of bq. The latest version is 2.0.17.
$ bq version
This is BigQuery CLI v2.0.17
When you ran easy_install, did you use the --upgrade flag? If not, it doesn't actually update the version that you're using.
You can see the latest version at the download page here.

127 Return code from $?

What is the meaning of return value 127 from $? in UNIX.
Value 127 is returned by /bin/sh when the given command is not found within your PATH system variable and it is not a built-in shell command. In other words, the system doesn't understand your command, because it doesn't know where to find the binary you're trying to call.
Generally it means:
127 - command not found
but it can also mean that the command is found,
but a library that is required by the command is NOT found.
127 - command not found
example: $caat
The error message will
bash:
caat: command not found
now you check using echo $?
A shell convention is that a successful executable should exit with the value 0. Anything else can be interpreted as a failure of some sort, on part of bash or the executable you that just ran. See also $PIPESTATUS and the EXIT STATUS section of the bash man page:
For the shell’s purposes, a command which exits with a zero exit status has succeeded. An exit status
of zero indicates success. A non-zero exit status indicates failure. When a command terminates on a
fatal signal N, bash uses the value of 128+N as the exit status.
If a command is not found, the child process created to execute it returns a status of 127. If a com-
mand is found but is not executable, the return status is 126.
If a command fails because of an error during expansion or redirection, the exit status is greater than
zero.
Shell builtin commands return a status of 0 (true) if successful, and non-zero (false) if an error
occurs while they execute. All builtins return an exit status of 2 to indicate incorrect usage.
Bash itself returns the exit status of the last command executed, unless a syntax error occurs, in
which case it exits with a non-zero value. See also the exit builtin command below.
It has no special meaning, other than that the last process to exit did so with an exit status of 127.
However, it is also used by bash (assuming you're using bash as a shell) to tell you that the command you tried to execute couldn't be executed (i.e. it couldn't be found). It's unfortunately not immediately deducible though, if the process exited with status 127, or if it couldn't found.
EDIT:
Not immediately deducible, except for the output on the console, but this is stack overflow, so I assume you're doing this in a script.
If you're trying to run a program using a scripting language, you may need to include the full path of the scripting language and the file to execute. For example:
exec('/usr/local/bin/node /usr/local/lib/node_modules/uglifycss/uglifycss in.css > out.css');
This error is also at times deceiving. It says file is not found even though the files is indeed present. It could be because of invalid unreadable special characters present in the files that could be caused by the editor you are using. This link might help you in such cases.
-bash: ./my_script: /bin/bash^M: bad interpreter: No such file or directory
The best way to find out if it is this issue is to simple place an echo statement in the entire file and verify if the same error is thrown.
If the IBM mainframe JCL has some extra characters or numbers at the end of the name of unix script being called then it can throw such error.
In addition to the given answers, note that running a script file with incorrect end-of-line characters could also result in 127 exit code if you use /bin/sh as your shell.
As an example, if you run a shell script with CRLF end-of-line characters in a UNIX-based system and in the /bin/sh shell, it is possible to encounter some errors like the following I've got after running my script named my_test.sh :
$ ./my_test.sh
sh: 2: ./my_test.sh: not found
$ echo $?
127
As a note, using /bin/bash, I got 126 exit code, which is in accordance with gnu.org documentation about the bash :
If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126.
Finally, here is the result of running my script in /bin/bash :
arman#Debian-1100:~$ ./my_test.sh
-bash: ./my_test.sh: /bin/bash^M: bad interpreter: No such file or directory
arman#Debian-1100:~$ echo $?
126
go to C:\Program Files\Git\etc
open gitconfig with notepad
change
[core]
autocrlf = true
To
[core]
autocrlf = false