Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #1381 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 28 January 2020 - 21:05

I missed that, sorry. The plan was remove it, not rename it.

 

This one: https://github.com/O...947abdad1a16eaf (merged by Littlesat)?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1382 Abu Baniaz

  • PLi® Contributor
  • 2,497 posts

+64
Good

Posted 28 January 2020 - 21:10

Yes, that is the one.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

Re: merge requests for PLi's git #1383 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 28 January 2020 - 21:17

Duplicate dealt with.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1384 Abu Baniaz

  • PLi® Contributor
  • 2,497 posts

+64
Good

Posted 28 January 2020 - 23:15

Thanks. How do you resolve this:

 

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch upstream
From github.com:OpenPLi/enigma2
   ae6c82b64..bbf959937  develop    -> upstream/develop


git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks pull upstream develop
From github.com:OpenPLi/enigma2
 * branch                develop    -> FETCH_HEAD

Updating 2af98b0b0..bbf959937
error: Your local changes to the following files would be overwritten by merge:
    lib/python/Components/opkg.py
Please commit your changes or stash them before you merge.
Aborting



Completed with errors, see above.


Re: merge requests for PLi's git #1385 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 28 January 2020 - 23:49

I don't have that problem, and "lib/python/Components/opkg.py" doesn't exist anymore after my commit.

 

I wonder what you are trying to do, because I don't have a commit hash "bbf959937":

=> /data/Development/OpenPLi/0.0-develop/enigma2  (develop)
[hverton@catwoman] $ git log
commit ae6c82b646cc0cb77bae5dbc3f756c4bb111c791 (HEAD -> develop, origin/develop, origin/HEAD)
Author: Harro Verton <wanwizard@openpli.org>
Date:   Tue Jan 28 20:16:56 2020 +0000

    Remove the duplicate opkg.py

commit d221424878cf80e7d0ade5376fd2b003392fe30c
Author: nautilus7 <spyros.n7@gmail.com>
Date:   Tue Jan 28 20:41:10 2020 +0200

    Fixed "LcdSkinSelector" for 3rd party skins
    
    If a skin defines only the "SkinSelector" skin, enigma2 crashes when opening the "Lcd Skin" screen.

commit 2af98b0b0bfca44a1f43cd414a99413f68c86e09
Author: nautilus7 <spyros.n7@gmail.com>
Date:   Tue Jan 28 16:21:13 2020 +0200

    Updated all .po files and Greek translation

commit 9c55cf0b69c9beba43dd7e017186552f410f357e
Author: IanSav <IS.OzPVR@gmail.com>
Date:   Tue Jan 28 10:56:24 2020 +1100

    [skin_default] Add missing "no preview" image

commit 98aac9e66f29d49787e31d1aff806024be435a7b
Author: Harro Verton <wanwizard@openpli.org>
Date:   Mon Jan 27 22:41:43 2020 +0000

    moved skin_default to the correct folder

commit b7a005943b2462027d3035e922a2e2e7300e3831
Author: Harro Verton <wanwizard@openpli.org>
Date:   Mon Jan 27 20:35:05 2020 +0000

    fixed incorrect skin_default copy path

which suggests your local copy has deviated from origin (which is also suggested by the remark that you have local changes you need to stash).

 

If you have nothing worth saving locally, I would do:

git reset 2af98b0b0bfca44a1f43cd414a99413f68c86e09 -hard
git pull

and you should be in sync again.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1386 Abu Baniaz

  • PLi® Contributor
  • 2,497 posts

+64
Good

Posted 28 January 2020 - 23:59


which suggests your local copy has deviated from origin (which is also suggested by the remark that you have local changes you need to stash).

Windows sees Opkg and opkg as the same and caused the issue. Thanks ofr the advice to resolve issue. I deleted the file/files and could pull updates from upstream

 

BTW, the files were not duplicates, they had some differences.



Re: merge requests for PLi's git #1387 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 29 January 2020 - 00:13

BTW, the files were not duplicates, they had some differences.

 

Yes, I know,

 

I moved the 3 functions from opkg.py to Opkg.py, and changed the PluginBrowser, which was the only file that still used the old code. I also ran a grep on enigma-plugins for a quick check.
 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1388 littlesat

  • PLi® Core member
  • 57,154 posts

+698
Excellent

Posted 29 January 2020 - 07:49

And possibly some plugins might use it.... (no idea what)...
This was indeed a riskey one and in addition I had idea’s to replace these code as all can be done in a few lines...

Edited by littlesat, 29 January 2020 - 07:51.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1389 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 29 January 2020 - 08:22

To Persian Prince, he is committing, you are merging :DSorry, havoc is a bit extreme.

 

Te reproduce:

Fork the project again, don't do anything, you will get a file has changed. This is because of upper/lowercase issue that windows does not recognise as being different.

 

Cause:

There was an opkg.py and Ipkg.py. He has renamed Ipkg.py to Opkg. So you now have Opkg.py and opkg.py which Linux will see as two different files, but not windows.

 

The thing is I don't use Windows for months.

 

That's why I didn't see this problem.


Edited by Persian Prince, 29 January 2020 - 08:23.

Open Vision sources: https://github.com/OpenVisionE2


Re: merge requests for PLi's git #1390 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 29 April 2020 - 07:24

https://github.com/O...igma2/pull/2544

 

py files: E101 and E121 PEP8 cleanup

Indentation contains mixed spaces and tabs (E101)
Continuation line under-indented for hanging indent (E121)

 

Done in all Open Vision repos, if you're up for it let me know to do it for all PLi repos as well.

And later for ViX, ATV and OE-A because it's the standard.


Open Vision sources: https://github.com/OpenVisionE2


Re: merge requests for PLi's git #1391 littlesat

  • PLi® Core member
  • 57,154 posts

+698
Excellent

Posted 29 April 2020 - 09:15

It is such an huge 'thing' that blindly merge it is at a relative high risk.... 

I'm happy that this kind of work is done... but a bit co-ordination might be a better approach.

 

I merge it... when it breaks things we need to revert! Please test it... I do not have time to do so...


Edited by littlesat, 29 April 2020 - 09:20.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1392 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 29 April 2020 - 09:46

Sorry but I don't have access to your private test sections for discussing these kind of things ;)

 

In OV I did this for all repos (except python 3 branches for now) and we're testing it and so far with no problem.

 

I say accept no more PRs and first test this if it was ok then I will send PRs for all other repos, is it ok?

 

I hope we could do this once for all.


Edited by Persian Prince, 29 April 2020 - 09:47.

Open Vision sources: https://github.com/OpenVisionE2


Re: merge requests for PLi's git #1393 Dimitrij

  • PLi® Core member
  • 10,322 posts

+349
Excellent

Posted 29 April 2020 - 11:58

py files: E101 and E121 PEP8 cleanup

Please revert it.

These are not tabs, but spaces!
Do not do this, for convenient reading / editing of the code you need tabs.


Edited by Dimitrij, 29 April 2020 - 11:59.

GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: merge requests for PLi's git #1394 ims

  • PLi® Core member
  • 13,781 posts

+214
Excellent

Posted 29 April 2020 - 12:09

Spaces are the preferred indentation method.

Tabs should be used solely to remain consistent with code that is already indented with tabs.

Python 3 disallows mixing the use of tabs and spaces for indentation.


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #1395 Dimitrij

  • PLi® Core member
  • 10,322 posts

+349
Excellent

Posted 29 April 2020 - 12:17

openPli use only tabs.

Have you tried editing the code from spaces alone?


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: merge requests for PLi's git #1396 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 29 April 2020 - 12:29

tabs vs spaces is the most polarized discussion in the development world :)

 

In PHP it is the same, and also there tabs are loosing. When editing with vi or emacs tabs has an advantage, but in any more advanced editor or IDE, it is no longer relevant.

 

I edit with Geany on linux, and it adapts without problems. And with "Ctrl-A, Tab, Shift-Tab", all indentation is changed (to either tabs or spaces, what your setting is (it can even detect from the file itself).

 

Maybe we should, while we're at it, change all tabs to spaces (or all spaces to tabs, I don't care), so it not mixed anymore?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1397 littlesat

  • PLi® Core member
  • 57,154 posts

+698
Excellent

Posted 29 April 2020 - 12:29

I revert it I was already scared of it.. I prefer spaces.!it was also most common in e2. Changing it over so many girls and so massive also blocks a lot of maintanance.... (blocks reverts etc....).
We need first think properly about this...
Python 3 disallows mixing them... but still it are tabs or spaces.... but 4 spaces is also extra code instead of one tab... that is why I prefer tabs.

Edited by littlesat, 29 April 2020 - 12:37.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1398 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 29 April 2020 - 12:53

I do prefer what PEP8 tells so OV will use it but I guess future merges would be hard for me to do ;)


Open Vision sources: https://github.com/OpenVisionE2


Re: merge requests for PLi's git #1399 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 29 April 2020 - 13:04

The entire world is moving to spaces. I don't like it, but a standard is a standard, it isn't about anyone's personal taste.

 

The space (as in disk space :)) argument is void too. A PC can deal with a few extra bytes, the repo is compressed, and on the box is no source.

 

Most if not all editors can be told what the intentation character is, so that is not an issue as well. The only thing that needs ajusting is the mindset. ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1400 WanWizard

  • PLi® Core member
  • 70,485 posts

+1,810
Excellent

Posted 29 April 2020 - 13:12

From an episode of HBO’s Silicon Valley:

 

“Truth be told, I do have a slight preference for tabs. But that’s only because I’m anal and because I prefer precision.”

 

“Well, not to pick a fight here, but if you really care about precision, wouldn’t you use spaces? But whatever, once it goes through the compiler, it’s the same thing, right…?”

 

“If it’s all the same, why not just use tabs?”

 

“Because it could look different on other people’s computers.”

 

“Tabs create smaller file sizes, all right…? I mean, why not just use Vim over Emacs?”

 

“I do use Vim over Emacs.”

 

“Oh, god help us!”


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.



12 user(s) are reading this topic

0 members, 12 guests, 0 anonymous users