apt.Cache.update with alternative sources.list

[Ole Streicher]

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('sources_list='/etc/blends/sources.list.testing')
LockFailedException: Failed to lock /var/lib/apt/lists/lock
```

Then I tried to use an alternative root directory:

```
>>> import apt
>>> c = apt.Cache(rootdir='/tmp/myapttmp')
>>> c.update('sources_list='/etc/blends/sources.list.testing')
FetchFailedException: W:GPG error: http://ftp.debian.org/debian testing 
InRelease: The following signatures couldn't be verified because the public key 
is not available: NO_PUBKEY 7638D0442B90D010, E:The repository 
'http://ftp.debian.org/debian testing InRelease' is not signed.
```

To which place in the new root directory do I need to copy the keyring?
I tried <>/usr/share/keyrings/ but this didn't work.

And/or how can I disable authentication (--allow-unauthenticated,
resp. APT::Get::AllowUnauthenticated)?

Version of python3_apt is 1.4.0~beta3+b1

Best regards

Ole

Re: GitLab CI on salsa.debian.org

[Hans-Christoph Steiner]

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 runners can be any
Debian box or VM.  It works easiest with Docker setups.  CI runners can
be tagged, the jobs can be marked for the required tags.  So the CI
runners could be tagged based on arch.

I hope that salsa.debian.org will also have some shared CI runners for
other arches.

> (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 each build?

It runs on each new push to git, so if you push commits one at a time,
it'll run per commit.

.hc

> On Wed, 2018-03-21 at 15:27 +0100, Hans-Christoph Steiner wrote:
>> 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.
> 

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Rebecca N. Palmer]

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.)


(Has anyone checked whether there are more of these?)

dpkg-buildpackage: info: source package sympy
dpkg-buildpackage: info: source version 1.1.1-4
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Yaroslav Halchenko 


dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build sympy-1.1.1
 fakeroot debian/rules clean
dh  clean --with python2,python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'

dh_auto_clean
I: pybuild base:217: python2.7 setup.py clean
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'install_requires'

  warnings.warn(msg)
running clean
I: pybuild base:217: python3.6 setup.py clean
Traceback (most recent call last):
  File "setup.py", line 46, in 
from setuptools import setup, Command
ModuleNotFoundError: No module named 'setuptools'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "setup.py", line 49, in 
from distutils.core import setup, Command
ModuleNotFoundError: No module named 'distutils'
E: pybuild pybuild:330: clean: plugin distutils failed with: exit 
code=1: python3.6 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit 
code 13

make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
make[1]: Leaving directory 
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'

make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess 
returned exit status 2

Re: pybuild: how to get the build directory name

[Ole Streicher]

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 regards

Ole

Re: GitLab CI on salsa.debian.org

[Diane Trout]

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 each build?

On Wed, 2018-03-21 at 15:27 +0100, Hans-Christoph Steiner wrote:
> 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.

Re: RFS: mwic 0.7.4-1

[Paul Wise]

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 "formal process" around this, besides opening
> a new bug?

Just the new bug and the judgement of the lintian maintainers.

> Changes pushed to git, package on m.d.n updated.

I'll take a look, probably on Friday.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: RFS: mwic 0.7.4-1

[Georg Faerber]

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 them in
> >> `debian/rules clean` and very early in `debian/rules build` so that
> >> the package will never depend on the existing upstream files.
> >
> > I've searched quite a bit on the Internets how to do this, and
> > leverage, for now, dh_clean. I hope that this is an acceptable
> > method for this, I didn't found any "official" source. I'll approach
> > upstream regarding these files.
> 
> It needs to be done in both debian/rules clean and build, otherwise
> building the package without the clean step will use the prebuilt
> file. dh_clean is fine for the first one, but you need to override
> dh_auto_configure or dh_auto_build for the second one.

Fixed. I've used dh_auto_build to limit the needed override targets.

> > Also, the man page is now generated during dh_auto_install. I've
> > added a build dependency on python3-docutils for this.
> 
> That is the wrong time to generate it, please change that to
> dh_auto_build.

Fixed.

> > See above. (Personally, I really dislike the trailing comma.)
> 
> The reason for the trailing comma option is that when you add a new
> item to the end of a list of dependencies, you don't also have to
> modify the line before it, making the diff easier to read, which is
> most of the point of the wrap-and-sort tool.

I see, thanks for the explanation, makes sense.

> > I'm aware that this was recently added to lintian, and reading the
> > bug, again, makes me wonder what's the process of getting a new
> > check into lintian.
> 
> The process for adding a check is to file a bug on lintian and wait a
> day, lamby is incredibly active on incoming lintian requests.

lamby does a great job, I didn't referred to him personally above.

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 "formal process" around this, besides opening
a new bug?

> > Correct. Still, my question stands: How do I enable autopkgtests for
> > this package?
> 
> I haven't yet dealt with autopkgtests so I'm not sure.

This is fixed as well, see 20180321010428.GJ8754@debian.

> > The texts are the same, there are only differences in special chars
> > like ", so I guess this is a false positive.
> 
> You may want to file a bug on license-reconcile about these false
> positives re Expat vs MIT/X11.

Will do, once mwic hits the archive, to serve as a proof of concept.

Changes pushed to git, package on m.d.n updated.

Thanks!
Cheers,
Georg


signature.asc
Description: Digital signature