[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#950204: marked as done (transition: pcl)

Your message dated Sat, 8 Feb 2020 21:00:16 +0100
with message-id <232098c7-56f9-a0a3-3be2-71f5d79d79e1@debian.org>
and subject line Re: Bug#950204: transition: pcl
has caused the Debian Bug report #950204,
regarding transition: pcl
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
950204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950204
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Dear release team,

I would like to transition pcl to the new ABI version. I tested and
updated it's build-rdeps, so I don't expect any problems. Note that the
new version doesn't build on armel anymore due to virtual memory
exhaustion. I will ask the ftp-masters to remove the old binary after I
uploaded the new version.

Cheers Jochen

Ben file:

title = "pcl";
is_affected = .depends ~ /\b(libpcl\-apps1\.9|libpcl\-common1\.9|libpcl\-features1\.9|libpcl\-filters1\.9|libpcl\-io1\.9|libpcl\-kdtree1\.9|libpcl\-keypoints1\.9|libpcl\-ml1\.9|libpcl\-octree1\.9|libpcl\-outofcore1\.9|libpcl\-people1\.9|libpcl\-recognition1\.9|libpcl\-registration1\.9|libpcl\-sample\-consensus1\.9|libpcl\-search1\.9|libpcl\-segmentation1\.9|libpcl\-stereo1\.9|libpcl\-surface1\.9|libpcl\-tracking1\.9|libpcl\-visualization1\.9)\b/ | .depends ~ /\b(libpcl\-apps1\.10|libpcl\-common1\.10|libpcl\-features1\.10|libpcl\-filters1\.10|libpcl\-io1\.10|libpcl\-kdtree1\.10|libpcl\-keypoints1\.10|libpcl\-ml1\.10|libpcl\-octree1\.10|libpcl\-outofcore1\.10|libpcl\-people1\.10|libpcl\-recognition1\.10|libpcl\-registration1\.10|libpcl\-sample\-consensus1\.10|libpcl\-search1\.10|libpcl\-segmentation1\.10|libpcl\-stereo1\.10|libpcl\-surface1\.10|libpcl\-tracking1\.10|libpcl\-visualization1\.10)\b/;
is_good = .depends ~ /\b(libpcl\-apps1\.10|libpcl\-common1\.10|libpcl\-features1\.10|libpcl\-filters1\.10|libpcl\-io1\.10|libpcl\-kdtree1\.10|libpcl\-keypoints1\.10|libpcl\-ml1\.10|libpcl\-octree1\.10|libpcl\-outofcore1\.10|libpcl\-people1\.10|libpcl\-recognition1\.10|libpcl\-registration1\.10|libpcl\-sample\-consensus1\.10|libpcl\-search1\.10|libpcl\-segmentation1\.10|libpcl\-stereo1\.10|libpcl\-surface1\.10|libpcl\-tracking1\.10|libpcl\-visualization1\.10)\b/;
is_bad = .depends ~ /\b(libpcl\-apps1\.9|libpcl\-common1\.9|libpcl\-features1\.9|libpcl\-filters1\.9|libpcl\-io1\.9|libpcl\-kdtree1\.9|libpcl\-keypoints1\.9|libpcl\-ml1\.9|libpcl\-octree1\.9|libpcl\-outofcore1\.9|libpcl\-people1\.9|libpcl\-recognition1\.9|libpcl\-registration1\.9|libpcl\-sample\-consensus1\.9|libpcl\-search1\.9|libpcl\-segmentation1\.9|libpcl\-stereo1\.9|libpcl\-surface1\.9|libpcl\-tracking1\.9|libpcl\-visualization1\.9)\b/;


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--- End Message ---
--- Begin Message --- 
Hi Jochen,

On 30-01-2020 22:40, Paul Gevers wrote:
> On 30-01-2020 22:25, Jochen Sprickerhof wrote:
>>> Is the autotracker [1] correct? Then, let this bug know but you can go
>>> ahead.
>>>
>>> [1] https://release.debian.org/transitions/html/auto-pcl.html
>>
>> Good point, a rebuild of ros-pcl-conversions is needed as well, because
>> it encodes the PCL version into it's cmake files in the binary package
>> but doesn't depend on any .so. I don't see a way to teach that to ben,
>> though¹.
> 
> Maybe somebody (Emilio?) knows?
> 
>> Should I fill a separate NMU request or could you schedule that
>> one as well?
> 
> We'll do it from here. Please ping this bug if you notice we forgot.

If I am correct, everything migrated to testing. Closing this bug.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: