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

Re: [MoM] Outreachy 2016 application



Hi Anna,

let’s see if I can help out to the best of my knowledge:

> First of all Sascha, thanks so much for your comments -- I managed to do the setup for schroot backend! Actually, I wonder why does the documentation suggest 'debci setup' for lxc if it doesn't work, but I guess this is the question for Debian mentors team.

I guess so too. I haven’t used the documentation you mentioned before, it may be out of date?

> One more (not urgent) question here. I tried to run
> 'adt-run --user debci --output-dir /tmp/output-dir SOURCEPACKAGE --- schroot debci-unstable-amd64'
> and I got an error all the times:
> "gpg: no default secret key: secret key not available
> gpg: signing failed: secret key not available
> adt-run [02:26:18]: ERROR: unexpected error: apt-ftparchive or signature failed, code 2"
> 
> I manually generated gpg key, I checked it with gpg --list-key, I tried to add its ID to  ~/.gnupg/gpg.conf but nothing helped. Eventually I executed the command with sudo and it worked. Is 'sudo' really necessary or may I fix it somehow?

I always call my LXC-based adt-run using sudo but the GPG issue may be unrelated. It’s difficult to say more without the context of the error. Did you create the keys as root?

> Dear all, I have a bunch of questions and I would appreciate your help!
> Here they are:
> 
> 1. Do I understand correctly that for creating a test I have to create debian/tests folder, put bash script in it and to create debian/tests/control file. Are there any other actions required?

The script does not necessarily need to be a bash script, it can be anything executable as long as its dependencies, e.g. interpreter, are declared in debian/tests/control. 
But otherwise, you got it. Just make sure you define all the dependencies for the test and pick the correct set of restrictions. For instance, if the tests write to stderr without that being an error (logging, for example) you need to specify ‘allow-stderr’. If the test needs to start services (e.g. dbus etc) for the test to run, you will also set an isolation level of at least ‘container’. Good that you chose LXC because that isolation level wouldn’t work with a simple chroot.
See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html for detailed descriptions of the restrictions.

> 2. As far as I understand, from the test script I can call the tools being tested as if they are installed in /usr/bin/ or as if they have an alias in the system. Is it right?

Exactly. The idea of the autopkgtest is to test the package as it would look like in the installed state.

> 3. In test scripts I notices some relative paths (like "for f in test/*.sh"). Do we always assume that the tests are executed from the exact directory? Is it "debian”?

The working directory of each test is guaranteed to be the root of the source package, which will have been unpacked but not built. See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html for more information.

> 4. Do I always need to rebuild the package if I want to change the test script? Is there a faster way to check changes?

If all you are changing is the test script, it should be enough to just build a new source package (all, please correct me if I’m wrong).

> 5. In the artfastqgenerator package I saw the following: "cp -a /usr/share/doc/artfastqgenerator/examples/*" Does it mean that these examples are provided by from upstream and they will be placed in that directory while package installation?

Thats’s what I expect, yes.

> 6. Tests for axe-demultiplexer change my font and background colors to blue and black respectively. Is something wrong with my system settings or is it an expected behaviour?
> 7. I ran test for eigensoft package (which checks that it prints usage info). It is marked as PASS, but stdout clearly says that it has an error: "error: eigenstrat do not print usage information". What's the matter? Why does it fail and why isn't this failure detected? (I guess the matter is in exit code -- it is alway equal to zero). Again, are my system settings incorrect or is it a common behaviour?

No idea about these, these seem to be quite package specific.

> 8. I'm looking for the test data for bwa. How do I check the licence for a dataset? May I use the test data from the other package? (Say bowtie2 -- it has test data inside). May I put the data in debian/tests or do I need to use some other location?

I wouldn’t put larger (say >1MB) test data into the debian/tests directory, but rather create a bwa-test package containing the data and make it a dependency of the test. Can anyone perhaps comment on this idea?
IMHO you can use test data from other packages, but keep in mind that these can change without warning.

Best regards
Sascha


> 2016-02-23 1:50 GMT+03:00 Sascha Steinbiss <satta@tetrinetsucht.de>:
> Hi Anna and Andreas,
> 
> […]
> >> I got the following error: "Error: container adt-sid-amd64 is not defined"
> >>
> >> This <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799760> discussion
> >> looks relevant, but the executed command here is slightly different.
> >>
> >> Do you have any ideas how to fix this issue? What am I doing wrong?
> >
> > Hmmmm, good question.  Its a long time ago thyt I used adt-run and I
> > need to refresh my mind myself.  I would need some more time to check
> > myself which I do not have currently.  I'd recommend you stick to a
> > shell script that runs in your *local* machine for the moment.
> >
> > Or may be somebody else here on the list can help?
> 
> I think that 'debci setup’ only prepares a schroot environment to use as a testbed, so you need to use:
> 
>   $ adt-run --user debci foobar.changes --- schroot debci-sid-amd64
> 
> where I’m not completely sure about the name of the environment, it may be different for you.
> 
> LXC uses a different container format and you need to use a different command for building. For LXC I had to use ’act-build-lxc’, e.g.
> 
>   $ sudo adt-build-lxc debian sid
> 
> will build you a LXC container for sid.
> 
> > If not and you
> > want to get this up and running before I'm back from vacation you have
> > very good chances to ask this question on the mailing list
> >   debian-mentors@lists.debian.org
> > Just do not hesitate to ask there.
> 
> Seconded. They are usually quite responsive :)
> 
> Cheers,
> Sascha
> 


Reply to: