We need to set the password for user root, otherwise the
sudo package refuses to get removed. See e.g.
See https://jenkins.mgm.sipwise.com/view/piuparts/job/metapackages-piuparts/290/consoleFull
| Removing sudo (1.8.10p3-1+deb8u3) ...
| You have asked that the sudo package be removed,
| but no root password has been set.
| Without sudo, you may not be able to gain administrative privileges.
|
| If you would prefer to access the root account with su(1)
| or by logging in directly,
| you must set a root password with "sudo passwd".
|
| If you have arranged other means to access the root account,
| and you are sure this is what you want,
| you may bypass this check by setting an environment variable
| (export SUDO_FORCE_REMOVE=yes).
|
| Refusing to remove sudo.
| dpkg: error processing package sudo (--purge):
| subprocess installed pre-removal script returned error exit status 1
Change-Id: Id49bfa2cdf1f4018d26c13d240682967a8507caa
Before piuparts is recording its metadata of the chroot it's
supposed to be brought up2date, so that installed packages match
what's provided by the repositories being refered to in
sources.list.
piuparts until and including v0.66 executes the apt-get
dist-upgrade only when either the basetgz or schroot option is
present. We've switched from the basetgz approach to
--existing-chroot= though, because that speeds up build times.
With the recent Debian point release the libsqlite3-0 package
(which is a dependency of aptitude and therefore pre-installed in
the chroot) received an update which caused our piuparts runs to
fail because of wrongly recorded metadata, as mentioned above.
Reported against upstream including a patch in http://bugs.debian.org/798266
Change-Id: I4427d339f163bd92756e6ea71f0c0c99b766be7f
Nowadays we have two major improvements in our setup:
* *-get-code Jenkins jobs provide files for sources.list and apt_preferences
setup, so we no longer need to duplicate logic for generating those files
inside our piuparts wrapper
* the cowbuilder environments ("/var/cache/pbuilder/base-$distri-amd64.cow")
provide all the required apt keys, so we don't have to deal with
ngcp-keyring install nor wget runs to retrieve the keys any longer
As a result get rid of the piuparts tar file generation (like
/var/cache/pbuilder/base-wheezy-amd64.tgz), instead copy the
existing cowbuilder environment to a temporary place and use that
as input for piuparts' --existing-chroot option.
Change-Id: I8ba458e6088361f3f5a793512fa61d87ee711306
Otherwise fails with:
| 0m8.8s ERROR: Command failed (status=1): ['chroot', '/var/cache/pbuilder/tmp.upxyAfmDXA_piuparts_tmp/tmpN0qCK0', 'tmp/scripts/pre_install_add_sipwise_repos.sh']
| ** Setting up http://deb.sipwise.com/autobuild/680FBA8A.asc for apt-get usage ***
| mktemp: failed to create file via template `/var/cache/pbuilder/tmp.upxyAfmDXA_piuparts_tmp/tmp.XXXXXXXXXX': No such file or directory
The tarball that is used for unpacking doesn't include Sipwise'
apt-key so (dist-)upgrading it fails and the wrong checksums
are used. E.g. our tarball ships an older version of perl-base
than you get with the 7.7 point release nowadays and therefore
we get:
| After purging files have been modified: /usr/share/doc/perl/changelog.Debian.gz owned by: perl-base
as a result. By ensuring that our chroot is properly updated
we can avoid this issue.
To use this feature it requires the patch I provided in
Debian's #767485, I'll provide an according backport on our
infrastructure.
We can't use just "Pin: origin deb.sipwise.com" any longer
when also hosting the Debian mirror on deb.sipwise.com,
so be more specific about the pinning rules.
While at it also report 'apt-cache policy' before and
after modifying the setup.
Problem as noted in several piupart runs since 7th of March:
| After purging files have been modified: /usr/lib/perl/5.14.2/Config_heavy.pl owned by: perl-base
perl[-base] 5.14.2-21+deb7u1 was uploaded on 2013-09-29 (see
http://packages.qa.debian.org/p/perl/news/20130929T211706Z.html),
while our piuparts base.tgz files for wheezy have been created on
2013-08-19 with perl[-base] version 5.14.2-21. This means that on
each piuparts run the perl-base package needs to be updated.
When switching to our own Debian mirror using deb.sipwise.com
(see MT#6171) this resulted in the following warning message:
| W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.sip
| W: Failed to fetch http://deb.sipwise.com/debian/dists/wheezy/Release
This wasn't considered as a fatal error. But as a result our
self-signed Debian repository caused apt-get to not consider
packages from deb.sipwise.com for inclusion in the dist-upgrade
process which is executed by piuparts.
When installing the "Debian-package-under-test" though the
perl-base package was considered as part of the installation, but
perl-base was also upgraded during this installation process.
The perl-base package actually *has* this flaw within the
5.14.2-21->5.14.2-21+deb7u1 upgrade, but it's not our problem.
Michael Prokop