The pypi name for this project is `kcc`, so we will be repackaging it
with that name.
Signed-off-by: Patrick McCarty <patrick.mccarty(a)intel.com>
---
bundles/python-extras | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bundles/python-extras b/bundles/python-extras
index 542587c6..7e7dd58b 100644
--- a/bundles/python-extras
+++ b/bundles/python-extras
@@ -32,7 +32,7 @@ flake8-docstrings
glibc-lib-avx2
intelhex
jdcal
-kernel-config-checker
+kcc
lxml
MonkeyType
mypy
--
2.26.2
On Wednesday, 27 May 2020 08:13:18 PDT Christian Betz wrote:
> On Mon, Apr 6, 2020 at 9:38 AM Arjan van de Ven <arjan(a)linux.intel.com>
> wrote:
> > On 4/5/2020 3:02 PM, Thiago Macieira wrote:
> > > /usr/lib64/libstdc++.so.6.* and /usr/lib64/haswell/libstdc++..so.6.* are
> > > provided by two different packages. It's possible they're out of sync.
> >
> > Again.
> >
> > we fixed that they're now part of the same package :)
>
> is this an issue that could be discovered and flagged automatically as part
> of the release QA process?
I thought I'd made a test for that. Let me check that I pushed it...
No, it was a manual test. I'll retrieve it and automate it.
> is there a way I can help when this happens? do you want know what bundles
> i'm using or anything like that?
>
> i'd be happy to contribute with a PR or file an issue if you have some
> pointers on where to look/start (this is the dev list, after all).
>
> in the meantime i am using a terrible and evil hack -- a cron job that
> deletes this pesky file every minute ;)
This file should not exist on 33190. So can you tell us what bundle your swupd
thinks is installing it?
$ sudo swupd search-file /usr/lib64/haswell/libstdc++.so.6
Downloading all Clear Linux manifests
[100%]
Searching for '/usr/lib64/haswell/libstdc++.so.6'
Search term not found
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
On 4/4/20 7:46 AM, Christian Betz wrote:
> * i discovered that swupd is indeed running ldconfig without the "-X"
> argument
That's definitely something we should consider, since this appears to be
the second time we've seen this issue appear (previously was a p11-kit
library).
Auke
I mix my own customized CL image in my home server, along with my own
packages built with autospec. I'm trying to understand the common developer
tooling framework.
>From https://github.com/clearlinux/common/blob/master/Makefile.toplevel:
PKGS = $(shell cat $(PACKAGES_FILE))
PKGS_LOCAL = $(sort $(filter ${PKGS},$(subst packages/,,$(wildcard
packages/*))))
PKGS_ORPHANED = $(sort $(filter-out common ${PKGS},$(subst
packages/,,$(wildcard packages/*))))
clean_PKGS = $(addprefix clean_,$(PKGS_LOCAL))
#help clean: Run 'make clean' for every package.
clean: $(clean_PKGS)
proper_PKGS = $(addprefix proper_,$(PKGS_LOCAL))
#help proper: Run 'make proper' for every package, and purge the local
#help repo and image.
proper: $(proper_PKGS)
rm -rf repo
rm -f clear.img
rm -f image-content.lst
rm -f report.html
.PHONY: $(clean_PKGS)
.PHONY: $(proper_PKGS)
$(clean_PKGS):
@echo "cleaning $(patsubst clean_%,%,$@)"
-@$(MAKE) -s -C $(addprefix packages/,$(patsubst clean_%,%,$@)) clean
$(proper_PKGS):
-@$(MAKE) -s -C $(addprefix packages/,$(patsubst proper_%,%,$@)) proper
Any special reason why I shouldn't modify make clean and make proper
in order to target it towards all folders under packages/*? In my use
case of using autospec and the common tooling over a personal mix, it
makes no sense to only being able to clean (local) packages that have
an upstream correspondent and while leaving the other packages (i.e.
PKGS_ORPHANED) untouched. In this use case, the whole concept of
orphaned packages make no sense.
Thanks in advance,
Francisco Boni
There is an interesting new PGO flag in 10.1, perhaps it could be useful in packages compiled with PGO:
-fprofile-partial-training
With -fprofile-use all portions of programs not executed during train run are optimized agressively for size rather than speed. In some cases it is not practical to train all possible hot paths in the program. (For example, program may contain functions specific for a given hardware and trianing may not cover all hardware configurations program is run on.) With -fprofile-partial-training profile feedback will be ignored for all functions not executed during the train run leading them to be optimized as if they were compiled without profile feedback. This leads to better performance when train run is not representative but also leads to significantly bigger code. (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#Optimiz…)
Bonus: Phoronix's GCC 10.1 Compiler Optimization Benchmarks
https://www.phoronix.com/scan.php?page=news_item&px=GCC-10.1-Compiler-Optim…
We have a `dtc` bundle already, so it's helpful to provide development
headers for the library (libfdt) provided by that bundle.
Signed-off-by: Patrick McCarty <patrick.mccarty(a)intel.com>
---
bundles/devpkg-dtc | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 bundles/devpkg-dtc
diff --git a/bundles/devpkg-dtc b/bundles/devpkg-dtc
new file mode 100644
index 00000000..290cb826
--- /dev/null
+++ b/bundles/devpkg-dtc
@@ -0,0 +1,10 @@
+# [TITLE]: devpkg-dtc
+# [DESCRIPTION]: All content for dtc-dev.
+# [STATUS]: Active
+# [CAPABILITIES]:
+# [TAGS]: Developer Tools
+# [MAINTAINER]: Patrick McCarty <patrick.mccarty(a)intel.com>
+
+include(devpkg-base)
+
+dtc-dev
--
2.26.2
On Wed, May 20, 2020 at 10:44 AM Warden, Brett T
<brett.t.warden(a)intel.com> wrote:
>
> What's the preferred way to do that for these? Neither ships any .pc.
>
> Or should create a single paho-mqtt bundle that provides both -lib packages, and then add it to auto.devbundles?
I'd like to keep the structure the same for the devpkg-* bundles so
one per package.
