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

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



Hi Marcin,

On Thu, Jul 23, 2015 at 06:31:16PM +0200, Marcin Dulak wrote:
> On Thu, Jul 23, 2015 at 3:57 PM, Andreas Tille <andreas@an3as.eu> wrote:
> > 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".

No problem, just telling you what is general policy at lists.debian.org.
 
> > 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

Hmmm, that's a bit much to simply fetch a few packages from testing.
You should have checked

    man apt_preferences

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

You might like to ask on a general user list how to cope with this.  I
have not experienced this on my testing upgrade and no good idea.

> > 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://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.

That's unusual.
 
> I understand that this is due to Debian unstable not providing certain
> repository paths.

Most probably not.  May be a temporary failure of a single mirror or DNS.

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

That's work in progress as you can read here in a recent mail.

Kind regards

        Andreas.

-- 
http://fam-tille.de


Reply to: