Ubuntu MOTU Application

[Łukasz 'sil2100' Zemczak]

Hello!

On 16.05.2014 16:47, Dimitri John Ledkov wrote:
> Hi,
> 
> Very elaborate answers, thanks a lot for these.
> 
> On 13 May 2014 15:48, Łukasz 'sil2100' Zemczak
> <lukasz.zemczak at canonical.com> wrote:
>> Hi!
>>
>> Thank you for handling my application through e-mail! Let me try
>> answering the outlined questions below - I apologize if some answers
>> might seem a bit chaotic though.
>>
>> On 13.05.2014 15:23, Iain Lane wrote:
>>> Hi Łukasz,
>>>
>>> On Tue, Apr 29, 2014 at 03:23:21PM +0200, Łukasz 'sil2100' Zemczak wrote:
>>>  - (to get off the topic of the CI train :P) What do you think the main
>>>    aims of the MOTU team as a whole are?
>>
>> In my understanding, the MOTU are an awesome group of individuals that
>> add, manage and maintain packages in universe and multiverse of Ubuntu.
>> The main aim is to have someone that could help out with sponsoring new
>> uploads of various packages, but also things like syncing changes both
>> ways to and from Debian when needed.
>> This doesn't only imply packaging, but also fixing bugs and FTBFS when
>> possible.
>>
> 
> - In your own words, can you explain the difference between universe
> and multiverse?

I think by intuition the difference is the licensing of the packages
provided in those repositories. All packages in universe have to have a
free, open-source license, while multiverse contains those projects
which licensing does not comply to our licensing policy. So it means it
might have a project that even restricts its usage somehow. Therefore
those might be harder to maintain, as I suppose some of them might be a
bit harder to contribute/cooperate when resolving potential issues.

But I must say that personally I didn't have much first-hand experience
with multiverse.

> And another question from me:
> 
> - Should debian/rules execute compiled unit-tests unconditionally? If
> not, how would you implement that in debian/rules?
> 

Not sure if I completely understood the question, but let me try
answering it the way I understand it.
In most cases running unit-tests on build time happens automatically (as
in the case of dh and known build-systems) and is the 'right' way of
doing it - since running unit-tests on build is a nice way of
auto-checking if there are any regressions/errors introduced in a new
version/patch. Sometimes, though, there are certain cases where running
tests is not feasible for a given architecture (or, we need to
temporarily override not running them, hacky, because they are known to
be failing). For packages using debhelper (which is most often used and
easiest), one can do something like:

include /usr/share/dpkg/default.mk

ifeq ($(DEB_HOST_ARCH),foo64)
override_dh_auto_test:
  # here we can either:
  true
  # or (better) actually run and don't care about the results:
  dh_auto_test || true
endif

Instead using the include, we can also get the arch manually by calling
dpkg-architecture ourselves, like DEB_HOST_ARCH ?= $(shell
dpkg-architecture -qDEB_HOST_ARCH)
Not sure if I answered the question though!

Best regards,

-- 
Łukasz 'sil2100' Zemczak
 lukasz.zemczak at canonical.com
 www.canonical.com