Hi,
I need some access (as normal user) to an apt cache with an alternative
sources.list (those in /etc/blends/ installed by blends-dev), but I have
problems to find out how to use it.
I first tried to just specify the alternative source file:
```
>>> import apt
>>> c = apt.Cache()
>>> c.update(
Diane Trout:
> Can you trigger test on dependencies changing?
You can cron test runs, that would then check the deps.
> Does CI run on architectures other than amd64?
That depends on the gitlab-ci-runners that are registered. Anyone can
register CI-runners for their own projects, and CI runner
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-python@lists.debian.org
python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so if you need it, please build-depend on it. (Or python3-setuptools,
given that this looks like it might prefer that.)
(
Dear Piotr,
Piotr Ożarowski writes:
> or even better (without using pybuild's internal paths):
>
> override_dh_auto_test:
> dh_auto_test -- --system=custom --test-args '{interpreter}
> {dir}/debian/tests/pyraf-test.py'
That is optimal for me. Thank you very much for the hint!
Best rega
Can you trigger test on dependencies changing?
Does CI run on architectures other than amd64?
(I was thinking of complex packages with many dependencies like dask,
or with fiddly bit manipulation like pandas)
So this would get tests on each commit instead of the current
autopkgtests which run on
Since I got only crickets on this email, let me elaborate: gitlab-ci
lets you run whatever you want as root via Docker images. That means
its easy to run full builds, installs, and tests in gitlab-ci. It also
makes it easy to add CI tests for various releases, like to support
backports.
.hc
H
On Wed, Mar 21, 2018 at 6:02 PM, Georg Faerber wrote:
> To put it differently, especially regarding this upstream metadata
> check: If someone opens a bug against lintian to add a new check, does
> "this new check" needs to be backed up by some general consensus within
> the project? Is there some
Hi,
On 18-03-21 11:36:58, Paul Wise wrote:
> On Wed, Mar 21, 2018 at 1:11 AM, Georg Faerber wrote:
> >> doc/mwic.1 and tests/coverage are generated files, they should be
> >> removed from the upstream VCS and tarballs and be always built from
> >> source. If upstream refuses, you should remove the
8 matches
Mail list logo
