$ ./change-override -c main -t pmdk
Override component to main
pmdk 1.7-1ubuntu1 in focal: universe/libs -> main
Override [y|N]? y
1 publication overridden.
$ ./change-override -c main libpmem1 libpmem-dev
Override component to main
libpmem1 1.7-1ubuntu1 in focal amd64: universe/libs/optional/100%
Thanks for explaining more details and backgrounds Adam!
But promotion to main isn't really done per-architecture.
That only exists via e.g. having a package build only x86 binaries and then
promoting it.
I've not yet seen a package building x86,arm64,ppc64 binaries but then
promoting only some
Sorry if I was unclear: libpmemobj and friends are well-tested on amd64,
it's only the ppc64el port of those that's very new (mostly because of
many hardcoded x86 assumptions, like page and especially cacheline size,
that are untrue on ppc). The library has gone through six years of
development al
@Andreas - take a look at these and ack+push if you are ok with that:
=> https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/ubuntu/+merge/378435
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
This seems to auto-inclue way too much:
From
https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
Rescued from pmdk (Uploader: ahasenack), libpmemblk-dev,
libpmemblk1-debug, libpmemlog-dev, libpmemobj-dev, libpmempool-dev,
librpmem-dev, libvmem-dev, libvmmalloc-dev
Let
Version 1.8 has just been released. As I mentioned before, besides
splitting out deprecated and out of scope for PMDK libvmem and
libvmmalloc, support for ppc64el has been added, thanks to Lucas
Magalhães of IBM.
While the ppc64el port is marked as experimental, this is mostly due to
higher-level
Splitting will serve another purpose too. rpmemd also links with
libfabric, which is in universe. By moving rpmemd out of pmdk-tools, and
into a new universe package, we won't have to MIR libfabric.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/377706
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR] pmdk
To manage notif
bug 1853506 and bug 1790856 are ready (process-wise) when you are @ahasenack.
As checked on IRC, let me know when all is ready to add the dependency pulling
it in.
** Changed in: pmdk (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => Andreas Hasenack
(ahasenack)
** Changed in: p
The split is doable. What hurts, though, is having these kind of changes
(like vmem and vmalloc moving to another source) still happening. We
don't expect a package in main to still be going through these types of
big changes. Has this stabilized?
--
You received this bug notification because you
Thanks for your review. There's next release coming probably this week; -rc1
is already out. The changes relevant for MIR are:
* vmem and vmmalloc are dropped (moved to another source, but it's not main
material).
These were the only parts doing custom memory management in DRAM.
* ppc64el
I reviewed pmdk 1.7-1ubuntu1 as checked into focal. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
pmdk comes from Persistent Memory Development Kit and it's a collection of
libraries and tool which allows applications to access persistent memory as
memory-
The hardware is commercially available for more than half a year, thus
proper support is more urgent than it was when this bug was initially
filed. At this time, the DIMMs work only with large servery machines,
for which large numbers of qemu VMs is one of most widespread uses.
Thus, it's importan
Since nothing happened for a while here an interim update, atm this
seems to be on track for security review on time to make it into Ubuntu
20.04.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Just hit a snag with the new 1.5 upstream version, which I now realize
Adam mentioned earlier.
It changed the ondisk format[1] and requires an external tool[2] to
convert to the new format. This tool (pmdk-convert) is not packaged yet.
If we upgrade to 1.5, we would leave 1.4 users with no way to
The pmdk 1.5 update is needed to unblock
https://launchpad.net/ubuntu/+source/libpmemobj-cpp in disco-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR] pmdk
To manage noti
I'm working on syncing with debian's 1.5. I might first update ours to
1.5, and then merge.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR] pmdk
To manage notifications about thi
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: pmdk (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR]
PMDK is since recently in Debian, maintained by me. Version 1.5 (Ubuntu
still has only 1.4).
Real architecture support is limited to amd64. The nature of this
software (mmapping hundreds of GB -- or terabytes -- of pmem) means i386
and armhf are outright out. Upstream support for arm64 is unmai
** Changed in: pmdk (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR] pmdk
To manage notifications ab
The feedback so far was answered and seems ok:
- ABIs experimental -> only pmemcto which will not get into MAIN
- amd64-only -> clarified with upstream really is only amd64 only atm
- bundled jemalloc -> explained by upstream has to stay bundled
- package subscription -> done by powersj in comment
ubuntu-server is now subscribed to the bugs for pmdk
marking as 'new'
** Changed in: pmdk (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MI
ok, then pmemcto should stay in universe.
The package is still missing a bug scubscriber.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790856
Title:
[MIR] pmdk
To manage notifications about this
I got confirmation from upstream @intel that pmdk is amd64 only, and there is
some experimental arm64 code:
"""
There's no official support for architectures other than x86_64, because PMDK
requires per-architecture code (see src/libpmem/$(ARCH)/).
Aarch64-specific code exists in the tree (it wa
On Fri, Sep 14, 2018 at 4:21 PM Andreas Hasenack
wrote:
> Only pmemcto is flagged as experimental: http://pmem.io/pmdk/libpmemcto/
>
> If qemu doesn't link with it, directly or indirectly, this particular
> binary package could remain in universe.
>
pmemcto is not a binary needed by qemu for wha
Only pmemcto is flagged as experimental: http://pmem.io/pmdk/libpmemcto/
If qemu doesn't link with it, directly or indirectly, this particular
binary package could remain in universe.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ht
Regarding jemalloc, I asked about that point exactly before submitting
this package for archive inclusion:
https://bugs.launchpad.net/ubuntu/+bug/1752378/comments/69
Upstream's answer was:
https://bugs.launchpad.net/ubuntu/+bug/1752378/comments/72
I will ask upstream about non-amd64 support. The
some comments:
- the package descriptions mention the ABIs as experimental. How do you want
to handle that in main, it's not ideal.
- I don't like the idea of only building that for amd64. Please could you
build
that everywhere, and see where it fails? This doesn't hide the fact that the
To add one more reason to do this like "now" (=early 19.04) from my personal
POV.
While rare today, looking into the future I'd think the availability of nvdimms
will rise.
So looking forward to 20.04 we have multiple options:
- nvdimms are a thing by then, so we better start in 19.04 to get thi
29 matches
Mail list logo