Override component to main
libtraceevent 1:1.8.2-1ubuntu2 in noble: universe/misc -> main
libtraceevent-dev 1:1.8.2-1ubuntu2 in noble amd64:
universe/libdevel/optional/100% -> main
libtraceevent-dev 1:1.8.2-1ubuntu2 in noble arm64:
universe/libdevel/optional/100% -> main
libtraceevent-dev 1:1.8.2
Hey everyone and Paul. First, sorry for the delayed answered (I was
thinking you would get me reassign and for some reason, I missed
subscribing to the bug)
> But I do not really understand the harm of having these entries kept
for documentation, except this could pile up and become a mess at some
We agreed that the "#MISSING: " lines will be downgraded to a
Recommended MIR TODO.
Do you want those #MISSING: symbols dropped? IMO it should be fine
as-is. Upstream is aware and want's to drop it anyway
#MISSING is fine unless it keeps adding more and more and more of
them
So this should be
I just subscribed the ~foundations-bugs team. Security review looking
good (comment #20).
I can now see proper autopkgtests and "dh_auto_test" during build.
The "#MISSING: " lines in libtraceevent1.symbols have been explained in
comment #3 & #4 after discussions with the upstream/Debian maintaine
I uploaded the patch in bug 2055258 for Paul, which addresses the TODOs
about build time tests and autopkgtest.
** Changed in: libtraceevent (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
I reviewed libtraceevent 1:1.8.2-1 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
> libtraceevent - Linux kernel trace event library
- CVE History:
- none
- Build-Depends?
- nothing concerning
- most dependencies are for buildin
> FWIW, the convention for ppa uploads is to append ~ppaX to the new
version number.
Oh my bad, I forgot about that!
> This was causing me a lot of confusion
Sorry about that, it was not clearly mentioned.
> If you want to keep using LIBTRACEEVENT_STATIC for this purpose,
I did this because I
FTR: There was an older MIR discussion around libtraceevent in bug
#2051916 (concerns were similar).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2051916
Title:
[MIR] promote libtraceevent as a tra
> Yes, because for now I am submitting the patch I am generating from
the build I submit to my PPA to test.
FWIW, the convention for ppa uploads is to append ~ppaX to the new
version number.
> Yes, this is done intentionally because AFAIU the static lib is not
supposed to be used by consumers of
> The version number for the package also looks wrong still.
Yes, because for now I am submitting the patch I am generating from the
build I submit to my PPA to test. I will fix this once everything is
done.
> Are you intentionally populating LIBRARY_STATIC with a path to a
*shared* library?
Yes
Passing `-l:libtraceevent.a` *will* use the installed library, unless
it's installed in some odd location outside of LIBRARY_PATH, which does
not appear to be the case. This is doing the same thing as any other
`-l` usage, but specifies that we specifically want the static
version of this library.
Is that what you had in mind? Because it looks like this is working as I
expected
See https://autopkgtest.ubuntu.com/results/autopkgtest-noble-upils-test-
ppa/noble/amd64/libt/libtraceevent/20240311_132302_36e50@/log.gz
Did I miss something?
** Patch added: "libtraceevent_1.8.2-1ubuntu11.diff"
Thanks for the review enr0n!
I like your solution of setting LIBTRACEEVENT_STATIC in
debian/tests/utest to have minimal changes in the Makefile.
> Shouldn't this be libtraceevent.a? Further, wouldn't it be better to make
> this `LIBTRACEEVENT_STATIC = -l:libtraceevent.a`?
In its review didrock
A few comments after a first look at the patch:
1. You should include bug numbers in the changelog, and in the relevant patch
files (using the Bug-Ubuntu dep3 field).
2. The version string is incorrect. The previous upload is 1:1.8.2-1, so this
should be 1:1.8.2-1ubuntu1. It's also generally goo
I now have a patch adding (and fixing) tests running at build and in
autopkgtest. See
https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/2055258/comments/11
I am now waiting for sponsorship on this upload.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Tags added: sec-3931
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2051916
Title:
[MIR] promote libtraceevent as a trace-cmd dependency
To manage notifications about this bug go to:
https://bugs
I have opened a dedicated bug to work on the patch as discussed with
slyon. See LP: #2055258
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2051916
Title:
[MIR] promote libtraceevent as a trace-cmd d
Updated patch. The test binary will now return 1 if at least one test
failed.
I will run autopkgtest when the pkg is published, and I expect it will
fail (and correctly report this failure) for s390x. We should then
decide if this failure is blocking the MIR process or not.
** Patch added: "libtr
Here is a patch to run utest at build time and build+run it with the
installed lib in autopkgtest.
I will update with the log of a successful autopkgtest run once this is
done.
** Patch added: "libtraceevent_1.8.2-1ubuntu3.diff"
https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/205
19 matches
Mail list logo
