port issues

[Craig Treleaven]

At 7:33 PM -0600 1/12/12, Ryan Schmidt wrote:
>On Jan 12, 2012, at 09:31, Arno Hautala wrote:
>
>> On 2012-01-12, Craig Treleaven <ctreleaven at cogeco.ca> wrote:
>>>
>>> BTW, would there be any possibility of an enhancement to MacPorts to report
>>> known issues with a port and its dependants?  Ie generate the list of
>>> dependencies for a port and query the trac database for any open tickets.
>>> aka
>>>
>>>> port issues mkvtoonix
>>> boost - #32558 (mkvtoolnix: error: 'boost::BOOST_FOREACH' has not been
>>> declared)
>>
>> That sounds like it'd be really useful.
>>
>> Currently, you can do this manually by running "port rdeps mkvtoolnix"
>> and then running a query on trac for each :
>> https://trac.macports.org/report/16?PORT=boost
>> or
>> http://trac.macports.org/query?status=assigned&status=new&status=reopened&port=%7Eboost&summary=%7E&order=priority
>>
>> Being able to combine these in port would be a nice shortcut.
>> You should open a feature request on trac for this.
>
>Let's take a look at this.
>
>Here is the recursive list of dependencies of mkvtoolnix:
>
>$ port rdeps mkvtoolnix
>The following ports are dependencies of mkvtoolnix @5.0.1_0:
>  ruby
>    libiconv
>      gperf
>    readline
>      ncurses
>        ncursesw
>    openssl
>      zlib
>    gdbm
>      gettext
>        expat
>  boost
>    bzip2
>    icu
>  file
>  flac
>    libogg
>  libvorbis
>    pkgconfig
>      glib2
>        xz
>        libffi
>        perl5
>          perl5.12
>  lzo2
>  pcre
>    libedit
>
>Here is a script that constructs and opens a Trac search page to find issues filed against a port (or ports) and optionally any of its recursive dependencies, sorted in descending ticket number order (i.e. newest first):
>
>https://trac.macports.org/browser/users/ryandesign/scripts/portissues
>
>Running this script as follows:
>
>portissues --deps mkvtoolnix
>
>The script opens this URL:
>
>https://trac.macports.org/report/16?sort=ticket&asc=0&PORT=(%5E%7C%20%7C,)(mkvtoolnix%7Cruby%7Clibiconv%7Cgperf%7Creadline%7Cncurses%7Cncursesw%7Copenssl%7Czlib%7Cgdbm%7Cgettext%7Cexpat%7Cboost%7Cbzip2%7Cicu%7Cfile%7Cflac%7Clibogg%7Clibvorbis%7Cpkgconfig%7Cglib2%7Cxz%7Clibffi%7Cperl5%7Cperl5.12%7Clzo2%7Cpcre%7Clibedit)($%7C%20%7C,)
>
>There are 58 tickets. Would seeing this list have been helpful? I would argue that there are a lot of tickets in that list that are not relevant to the issue being experienced -- lots of text to sift through before you find what you're looking for.

Hi Ryan:

Did you just write that script today?!  Wow, I never even considered that somebody would put together a prototype--let alone that quickly.  I was worried that my idea might be impractical--and in this case with 58 reported issues--it wouldn't help anyone.  Just a couple more thoughts before abandoning it...

I'm a very light user of MacPorts; is this case an exception or more typical?  I've normally used MacPorts to install stuff like wget and yasm where the list of deps is pretty small.

Are there other attributes in the Trac database that could help narrow down to problems that are potential blockers?  I would think that by default ticket type "Enhancement" could normally be excluded.  I'm (slightly) more familiar with MythTV where status is changed to Assigned after ticket-triage to ensure that the issue reported really is a bug and not just a mis-configuration or user error.  I take it you folks don't work that way?  Finally, MythTV uses a severity field (something like trivial, minor, major, blocker)--anything like that here?

Anyway, I'm not trying to push anything...just had an idea and wondered if it might be useful.  I certainly don't have the skills to implement anything like this and I'm just grateful that you folks who CAN do it are so generous in sharing your work.

Thanks,

Craig