Hi Martin,
On Tue, Apr 9, 2024 at 6:09 PM Martin Pitt wrote:
>
> Nathan Scott [2024-04-09 17:30 +1000]:
> > > It's not really unknown, it's "just" a file conflict:
> >
> > Yeah - the unknown bit for me is "why tho" - I cannot see conflicting
> &
Hi Eric, all,
| The only thing missing that I can think of right now are to release the
| upstream fixes for which I think has been merged upstream in 4.0.0 version
Just a heads up that the pcp-4.0.0 release happened a few weeks back, and
included all of Eric's fixes as well as several others
| Using a proper 3.0 (quilt) package would make it easier to [...]
This sounds like a good way to go. I'll assume Eric (or someone else from
Canonical/Ubuntu) is going to follow up with us on this ... chatting to Ken
earlier, this is a bit beyond our knowledge and it'll be best all round if
the
> - Why is this set as a native package?
This is for convenience of PCP developers - in particular,
both Ken and I regularly build and use the .deb packages in
our testing processes. The PCP project also release binary
debs with each release using the local (native) packaging -
Update #2.
All unchecked calls to the [v]s[n]printf family of string manipulation
routines have been fixed in the github pcp master branch now as well.
That area, and the __pmProcess* APIs Ken has added (and associated, on
going conversion of system/popen/... call sites) covers most, if not
all,
Hi all,
I was only just made aware of this bug today, apologies for not being
involved earlier.
I'm involved with PCP upstream and Debian packaging, and I'm in the
same $TZ as Ken - I'd be quite interested in chatting about the PCP
packages in Ubuntu.
| "I'd be happy to expand my notes for an
Hi Samuel,
This bug has just been fixed upstream. It was reported by someone to the
(upstream) developers directly - google found this bug report as well, so I
just wanted to let you know there's a fix available. pcp-2.9.0 will be released
within the next week, and pushed into Debian unstable
