Re: RFS: gpaw/0.10.0.11364 ITP -- DFT and beyond within the projector-augmented wave method

On Thu, Jul 23, 2015 at 3:57 PM, Andreas Tille <andreas@an3as.eu> wrote:

Hi Marcin.

it would be nice if you would follow the list etiquette and not CC
single authors. Thanks.

OK, didn't know about that. Was just doing "replay all".

On Thu, Jul 23, 2015 at 03:41:07PM +0200, Marcin Dulak wrote:
> > Hi Marcin,
> >
> > On Thu, Jul 23, 2015 at 02:30:32PM +0200, Marcin Dulak wrote:
> > > ~/gpaw $ cme fix dpkg-control
> > > Unknown application: dpkg-control. Run 'cme list' to list available
> > > applications
> >
> > Did you installed libconfig-model-dpkg-perl ?

> >
>
> too late, now on a broken debian 8.

In how far broken?

> While still on debian 8, i did what
> http://debian-med.alioth.debian.org/docs/policy.html says:
> *apt-get* install cme libconfig-model-dpkg-perl libconfig-model-itself-perl
> and cme seems not available on jessie.

That's correct. In Jessie cme is provided by some other package.
The policy is adapted to testing / unstable. In any case you
can find out what package provided what file by

apt-file search /usr/bin/cme

it looks like on jessie the installation line should be then:
apt-get install libconfig-model-perl libconfig-model-dpkg-perl libconfig-model-itself-perl

and that works for:
~/gpaw $ cme fix dpkg-control

Check this out on your jessie system please since I simply forgot.

> actually I got 'cme fix dpkg-control' to work on a broken
> jessie/testing/sid,
> and commited that fix.

Again: In how far broken? In principle you can install packages from
testing / unstable inside stable, specifically these Perl packages
should not cause any harm (as long as there was no Perl migration).

starting from https://atlas.hashicorp.com/deb/boxes/jessie-amd64

$ sudo apt-get update

$ sudo apt-get -y upgrade

$ sudo sed -i 's/jessie/testing/g' /etc/apt/sources.list

$ sudo apt-get update

$ sudo apt-get -y dist-upgrade ... Setting up udev (221-1+deb9u2) ... Installing new version of config file /etc/init.d/udev ... Installing new version of config file /etc/init/udev-fallback-graphics.conf ... Installing new version of config file /etc/init/udev-finish.conf ... Installing new version of config file /etc/init/udevmonitor.conf ... Installing new version of config file /etc/udev/udev.conf ... update-initramfs: deferring update (trigger activated) Processing triggers for systemd (215-17+deb8u1) ... Processing triggers for initramfs-tools (0.120) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 cp: omitting directory ‘/etc/udev/rules.d/70-persistent-net.rules’ E: /usr/share/initramfs-tools/hooks/udev failed with return 1. update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 1. dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1)

> ...
> I think i saw a Vagrantfile like that somewhere, but it should be Debian
> that officially maintains such.

I can't follow this arguing. You should build in a pbuilder / unstable
environment and that's what all doc should recomment (sometimes instead
of pbuilder sbuild is used - the principle is the same). If you spot an
invalid doc please point the according author to this issue but you
should be more specific about the problem of the doc.

the point is that there are too many incomplete and scattered docs.

This is the result of everybody having typed slightly different commands on their machines prior to the state described by the docs.

For example there are at least docs which mention how to "install" unstable:
https://wiki.debian.org/DebianUnstable#How_do_I_install_Sid.3F
https://wiki.debian.org/InstallFAQ#Q._How_do_I_install_.22unstable.22_.28.22sid.22.29.3F

The latter says (the former does not mention which commands one is supposed to type):
"then again change your /etc/apt/sources.list file to unstable and again do an update and a dist-upgrade"

This is incorrect for my https://atlas.hashicorp.com/deb/boxes/jessie-amd64 VM:
$ sudo sed -i 's/testing/unstable/g' /etc/apt/sources.list

$ sudo apt-get update > /dev/null W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/main/source/Sources 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/contrib/source/Sources 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/non-free/source/Sources 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/main/binary-amd64/Packages 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/contrib/binary-amd64/Packages 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://ftp.uk.debian.org/debian/dists/unstable-updates/non-free/binary-amd64/Packages 404 Not Found [IP: 78.129.164.123 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/main/source/Sources 404 Not Found [IP: 195.20.242.89 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/contrib/source/Sources 404 Not Found [IP: 195.20.242.89 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/non-free/source/Sources 404 Not Found [IP: 195.20.242.89 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/main/binary-amd64/Packages 404 Not Found [IP: 195.20.242.89 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/contrib/binary-amd64/Packages 404 Not Found [IP: 195.20.242.89 80] W: Failed to fetch http://security.debian.org/dists/unstable/updates/non-free/binary-amd64/Packages 404 Not Found [IP: 195.20.242.89 80] E: Some index files failed to download. They have been ignored, or old ones used instead.

I understand that this is due to Debian unstable not providing certain repository paths.

Having a reproducible environment in Vagranfile/Dockerfile will help to improve the documentation,

because the commands inside of Vagranfile/Dockerfile are the documentation.

> > > i've clarified also with GPAW upstream that the latest GPAW release,
> > > 0.11.0, is not ready for python3 yet (e.g. it does not work in parallel
> > > with python3).
> >
> > :-(
> >
> what will happen then to gpaw packaging?

In any case I consider it sensible to package the latest version.
I could imagine that we could add some text to README.source about
the current upstream work regarding Python 3.

can we proceed with gpaw-0.10.0, otherwise if we go for gpaw-0.11.0 one needs to get python-ase-3.9.1 into Debian first.
It's now more than 2 months after my initial gpaw's ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782543

gpaw-0.11.0 is not ready for python3 so it probably does not matter if we package 0.10.0 first?

Marcin

Kind regards

Andreas.

--
http://fam-tille.de

--
To UNSUBSCRIBE, email to debian-science-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 20150723135708.GT11116@an3as.eu" rel="noreferrer" target="_blank">https://lists.debian.org/[🔎] 20150723135708.GT11116@an3as.eu