Leonid Aronov Publishing Services. We can help you in many things:

2021-03-17 Thread Leonid Publisher via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Dear Colleagues,

This is the site of Leonid Aronov Publishing Services. We are a small
office in Belgium. Phone: +32 2 598 42 19, https://leonidpublisher.blogspot.com/

 We can help you in many things:
a) We can help you to find a good Scopus, Web of Science, EI Compendex
Indexed Journal to publish your papers with very low fees. We collect
many papers, we organize a pre-screen review and we are sending them
massively to many Open Access Publishers. So, we obtain much lower
fees! Open Access Publishers usual give to our Office a 30% - 80&
discount, when we provide them many good papers together.

Do not lose the opportunity send us your paper now (or at least a
Draft of 3 pages).

In December 8, 2020, we promoted to a Journal indexed in ISI
Web of Science and Scopus 30 good papers with good English and good
format. Our Authors obtained 40% discount!

b) We have collaboration with big publishers (Springer, Elsevier, ACM,
Emerald, AIP, IEEE, WorldScientific, SAGE etc) and small publishers.

c) We can find you also a good University in North America or West
Europe to elaborate M.Sc. or Ph.D. Dissertation

d) We can also help you in the Format of your paper or to improve the
language in your articles.

e) We can find the appropriate Journals for Authors from some
countries (like India, Italy, China) that have Specific Lists for
Journals that are recognized by their Countries or their Universities.

Note that you pay only if you receive the official letter of
acceptance from these publishers from their professional emails like
*@springer.com, *@ieee.org  etc


Do not hesitate to ask our advice!
Please, contact us for more details!

Dr. Leonid Aronov




LEONID PUBLISHER
Carrefour de l'Europe 3,
1000 Bruxelles, Belgium
Phone: +32 2 598 42 19
dr.leonid.aro...@gmail.com
https://leonidpublisher.blogspot.com/


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: compiling only packages that have patented functionality

2021-03-17 Thread Paul Spooren



Mar 17, 2021 12:37:26 AM Alberto Bursi :

I'm investigating about making an unofficial third party repository 
with OpenWrt (non-kmod) packages where patented functionality is 
enabled. For example ffmpeg from packages is missing some functionality 
in its "non-patented" form and most end users won't be able to just 
recompile from sources with that option enabled.


Is there a non-hacky way to build only packages that are affected by 
the "patented functionality" switch in the build system?


At the moment the only thing I can think about is a script that parses 
the package makefiles and compiles a list, and then builds only those 
packages with the SDK or buildroot.


The packages.git CI uses a little script to determine what packages 
changes. I think that step could be trivially modified to find patent 
packages.


Once you have the names, you could pass them to a GitHub action to 
automatically compile and upload/store.


I briefly describe a setup here:
https://forum.openwrt.org/t/github-action-for-package-building-and-testing/91324

Paul ___

openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH opkg] libopkg: pkg_hash: prefer original packages to satisfy dependencies

2021-03-17 Thread Matthias Schiffer

On 3/13/21 3:52 AM, Daniel Golle wrote:

On Sat, Mar 13, 2021 at 02:00:40AM +0100, Matthias Schiffer wrote:

When one package "provides" another non-virtual package, prefer to use
the original package instead of the providing package.

Example:

Consider packages "foo" and "bar", where "foo" provides "bar".
The current code will sort all candidates by name and use the last entry
by default, so "foo" would be used to satisfy a dependency on "bar".
Change the logic to prefer the actual package "bar" in this case.



Reviewed-by: Daniel Golle 


Signed-off-by: Matthias Schiffer 
---
  libopkg/pkg_hash.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index dbed3febfbbe..a07a25ec1e0b 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg/pkg_hash.c
@@ -284,6 +284,7 @@ pkg_t 
*pkg_hash_fetch_best_installation_candidate(abstract_pkg_t * apkg,
int nmatching = 0;
int wrong_arch_found = 0;
int arch_priority;
+   int good_pkg_score = 0;
pkg_vec_t *matching_pkgs;
abstract_pkg_vec_t *matching_apkgs;
abstract_pkg_vec_t *provided_apkg_vec;
@@ -409,9 +410,18 @@ pkg_t 
*pkg_hash_fetch_best_installation_candidate(abstract_pkg_t * apkg,
for (i = 0; i < matching_pkgs->len; i++) {
pkg_t *matching = matching_pkgs->pkgs[i];
if (constraint_fcn(matching, cdata)) {
-   opkg_msg(DEBUG, "Candidate: %s %s.\n",
-matching->name, pkg_get_string(matching, 
PKG_VERSION));
+   int score = 1;
+   if (strcmp(matching->name, apkg->name) == 0)
+   score++;


++score;

As you are not using the return value, no need for post-increment.
The compiler should be able to recognize and optmize that away by now
though, so probably it doesn't matter.


The difference is only meaningful in C++, where preincrement and 
postincrement may use different operator overloads. In C, I prefer the 
postincrement when I don't need the result, simply for aesthetic reasons ;)





+
+   opkg_msg(DEBUG, "Candidate: %s %s (score %d).\n",
+matching->name, pkg_get_string(matching, 
PKG_VERSION),
+score);
+   if (score < good_pkg_score)
+   continue;
+
good_pkg_by_name = matching;
+   good_pkg_score = score;
/* It has been provided by hand, so it is what user 
want */
if (matching->provided_by_hand == 1)
break;
--
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel





OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


compiling only packages that have patented functionality

2021-03-17 Thread Alberto Bursi
I'm investigating about making an unofficial third party repository with 
OpenWrt (non-kmod) packages where patented functionality is enabled. For 
example ffmpeg from packages is missing some functionality in its 
"non-patented" form and most end users won't be able to just recompile 
from sources with that option enabled.


Is there a non-hacky way to build only packages that are affected by the 
"patented functionality" switch in the build system?


At the moment the only thing I can think about is a script that parses 
the package makefiles and compiles a list, and then builds only those 
packages with the SDK or buildroot.


-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: Buildbot infrastructure upgrade

2021-03-17 Thread Andre Heider

On 13/03/2021 07:16, Andre Heider wrote:

On 13/03/2021 07:03, Petr Štetiar wrote:

Petr Štetiar  [2021-03-12 16:38:46]:

Hi,

I would like to let you know, that we've prepared upgrade of the 
Buildbot

based infrastructure and there is a plan to make those changes alive.


we've just finished the migration.


Oh nice, didn't see that coming so soon!

Does that mean it's possible to reconsider this patch now?
http://patchwork.ozlabs.org/project/openwrt/patch/20210216072108.26107-1-a.hei...@gmail.com/ 


I see it's merged by now, thanks!

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel