Bug#729800: Installing kernel 3.10 from wheezy-backports fails.
Package: linux-image-3.10-0.bpo.3-amd64 Version: 3.10.11-1~bpo70+1 I am running Debian wheezy amd64 with default kernel (3.2). When I try to kernel 3.10 from wheezy-backports by running "apt-get -t wheezy-backports install linux-image-amd64", it fails. I think it's a error with the depends, conflicts tags of the package. I suspect that the backports kernel conflicts with live-tools from wheezy but the backports package doesn't contains the correct meta-data to resolve gracefully. Here is output from command line: sudo apt-get -t wheezy-backports install linux-image-amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: initramfs-tools linux-image-3.10-0.bpo.3-amd64 Suggested packages: linux-doc-3.10 debian-kernel-handbook The following NEW packages will be installed: linux-image-3.10-0.bpo.3-amd64 The following packages will be upgraded: initramfs-tools linux-image-amd64 2 upgraded, 1 newly installed, 0 to remove and 121 not upgraded. Need to get 25.1 MB of archives. After this operation, 116 MB of additional disk space will be used. Do you want to continue [Y/n]? y Get:1 http://ftp.debian.org/debian/ wheezy-backports/main initramfs-tools all 0.113~bpo70+1 [92.0 kB] Get:2 http://ftp.debian.org/debian/ wheezy-backports/main linux-image-3.10-0.bpo.3-amd64 amd64 3.10.11-1~bpo70+1 [25.0 MB] Get:3 http://ftp.debian.org/debian/ wheezy-backports/main linux-image-amd64 amd64 3.10+52~bpo70+1 [5,844 B] Fetched 25.1 MB in 25s (999 kB/s) Reading changelogs... Done Preconfiguring packages ... (Reading database ... 282948 files and directories currently installed.) Preparing to replace initramfs-tools 0.109.1 (using .../initramfs-tools_0.113~bpo70+1_all.deb) ... Unpacking replacement initramfs-tools ... dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.113~bpo70+1_all.deb (--unpack): trying to overwrite '/usr/sbin/update-initramfs', which is also in package live-tools 3.0.20-1 update-initramfs: deferring update (trigger activated) Selecting previously unselected package linux-image-3.10-0.bpo.3-amd64. dpkg: considering deconfiguration of initramfs-tools, which would be broken by installation of linux-image-3.10-0.bpo.3-amd64 ... dpkg: yes, will deconfigure initramfs-tools (broken by linux-image-3.10-0.bpo.3-amd64) Unpacking linux-image-3.10-0.bpo.3-amd64 (from .../linux-image-3.10-0.bpo.3-amd64_3.10.11-1~bpo70+1_amd64.deb) ... De-configuring initramfs-tools ... Preparing to replace linux-image-amd64 3.2+46 (using .../linux-image-amd64_3.10+52~bpo70+1_amd64.deb) ... Unpacking replacement linux-image-amd64 ... Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/initramfs-tools_0.113~bpo70+1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696583: apper: "Edit Origins" does not seem to do anything
I can confirm this bug. "Edit Origins" button does nothing on my installation either (Debian 7.1 stable). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662946: bug 662946 equivs: does not strip subdirectories from files to be installed
Well, I can agree with you to a certain extent. I wouldn't use whitespace in any of my projects files. However I'm packaging Digikam, one of the shining stars of the open source world IMHO. And it includes a few files with white space in the names, files designed for humans, not computers or programmers like us. Bottom line is I can't package it unless I do something far worse than white space in file names. PS, thanks for the reply... and for the great software that got me into debian packaging. I use equivs-build to package for PCLinuxOS too. I found it easier to make a simple deb and alien it rpm than to figure out how make a simple rpm. Thomas Koch wrote: >Euan Thoms: >> I started hacking a solution to the white spaces in files names. I got it >> working for the equivs-build script but then hit a wall when I discovered >> that dh_install itself does not support white-space in file names / paths. >> The issue was raised in 2003 and basically the maintainer is not >> interested in resolving the situation. I find it quite disturbing and >> unacceptable that we can't have white-space in file names for core >> packaging tools. Is there something I'm missing here? How can this stay >> like this for nearly a decade? >I can't help but smile and consider it a wonderful feature that the core >packaging tools shield my system against files with whitespace... :-) > >Thomas Koch, http://www.koch.ro
Bug#198507: bug 198507 - dh_install: fails if filenames have an embedded space
I just spent half a day hacking the equivs-build script to support white space in file names. Only to find it is a limitation in dh_install as well. I was understanding of equivs-build limitation as it is only a basic entry level tool for packaging and thus not needing for every situation. But that this is a limitaion in the core packaing tools has dumbfounded me. And that it has been raised almost a decade ago and seemingly ignored is quite hard to believe. I'm just getting into debian, starting to package some of my own stuff. This is more than a bit off-putting to be honest. Why would allowing for white space to be escaped encourage all other problematic chraracters to require escaping? 1) white space is common, unlike other problematic characters. 2) white space was chosen as the delimiter between the file and the destination directory. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662946: bug 662946 equivs: does not strip subdirectories from files to be installed
Sorry, my last message was sent in HTML, so I'll repeate below: > I agree with RjY, this is undesired behaviour to not allow full path of source files int the "Files:" section. What if there are two files with same name in different directories, copying them to the same dir as control file is not possible. Also, it can't parse white space in file names. < I've tested RjY's patch and it works well. It's a simple ans small change that makes a real big difference to anyone doing basic packaging with equivs. Please consider the fix before it's too late to get into wheezy. I started hacking a solution to the white spaces in files names. I got it working for the equivs-build script but then hit a wall when I discovered that dh_install itself does not support white-space in file names / paths. The issue was raised in 2003 and basically the maintainer is not interested in resolving the situation. I find it quite disturbing and unacceptable that we can't have white-space in file names for core packaging tools. Is there something I'm missing here? How can this stay like this for nearly a decade? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662946: equivs: does not strip subdirectories from files to be installed
I agree with RjY, this is undesired behaviour to not allow full path of source files int the "Files:" section. What if there are two files with same name in different directories, copying them to the same dir as control file is not possible. Also, it can't parse white space in file names. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
