Re: Manual creation of dpkg package
Dan Dragos wrote: I have created a script in perl to create a dpkg from a specs file for rpm. I create the package, it begins to install but only copies some data. Have a look at the version I wrote: http://www.deepnet.cx/debbuild/ Note that it will probably fail on very complex .spec files, but those are the ones that will typically need some rewriting anyway due to differences in eg dependency handling. -kgd -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d234b83.7060...@vianet.ca
dpkg 1.15.8.7 MIGRATED to testing
FYI: The status of the dpkg source package in Debian's testing distribution has changed. Previous version: 1.15.8.5 Current version: 1.15.8.7 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1pa9uk-0004et...@franck.debian.org
Re: Accepted bup 0.17b-2squeeze1 (source i386)
On Tue, Jan 4, 2011 at 10:03:00 +, Jon Dowland wrote: bup (0.17b-2squeeze1) testing-proposed-updates; urgency=low . * use python-support to tightly version python dependency, needed due to the binary extensions. Thanks Jakub Wilk. Closes: #608568. *sigh* if you're going to use dpkg v3, could you please avoid the automatic patch feature? It turns a trivial fix into 5 files changed, 70 insertions(+), 61 deletions(-) because patches/debian-changes-0.17b-1 | 58 patches/debian-changes-0.17b-2squeeze1 | 59 + Anyway, approved. Cheers, Julien signature.asc Description: Digital signature
Re: Accepted bup 0.17b-2squeeze1 (source i386)
Julien Cristau jcris...@debian.org writes: On Tue, Jan 4, 2011 at 10:03:00 +, Jon Dowland wrote: bup (0.17b-2squeeze1) testing-proposed-updates; urgency=low . * use python-support to tightly version python dependency, needed due to the binary extensions. Thanks Jakub Wilk. Closes: #608568. *sigh* if you're going to use dpkg v3, could you please avoid the automatic patch feature? It turns a trivial fix into 5 files changed, 70 insertions(+), 61 deletions(-) because patches/debian-changes-0.17b-1 | 58 patches/debian-changes-0.17b-2squeeze1 | 59 + If you're going to always generate a single Debian patch for whatever reason (I do this because the packaging is managed in Git with separate branches per change and I don't like any of the systems that turn Git branches into patches), add a debian/source/options file containing: single-debian-patch (and ideally add a debian/source/patch-header file with the header explaining why you're doing this). That will force the patch name to always be debian-changes. People reviewing the package will still see a diff of a diff unless they unpack the package and and diff the trees with the patch applied, but at least the file name won't change and the diff of the diff will be relatively meaningful. Some might argue for using local-options instead of options so that NMU diffs would be separated into their own files. I prefer using options, but opinions will vary. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyhogksf@windlord.stanford.edu
Streaming Package Installation for dpkg/APT
Hi, I would like to know about the streaming package installation for dpkg/APT. I read about this from last year's summer of code ideas list of Debian [1], and found it interesting. I also found that it had not been taken by any of the applicants, and, therefore, I would like to work on it this summer. Is there any ongoing development related to that idea? There is a description given in [1] and apart from that, are there any concerns of it? I would like to know your ideas and suggestions about it, to proceed. Please let me know if you have something to share with me, I'm looking forward to your feedback. [1] http://wiki.debian.org/SummerOfCode2010/StreamingPackageInstall Thank you. -- Regards, Ishan Jayawardena. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikew9zujplwmdamxlje6690_pgmkxt9khs4w...@mail.gmail.com
Re: Streaming Package Installation for dpkg/APT
Hi! On Wed, 2011-01-05 at 09:55:29 +0530, Ishan Jayawardena wrote: I would like to know about the streaming package installation for dpkg/APT. I read about this from last year's summer of code ideas list of Debian [1], and found it interesting. I also found that it had not been taken by any of the applicants, and, therefore, I would like to work on it this summer. You might want to talk with the people involved in that proposal, as I don't think/remeber it ever being discussed on this list. CCed them now. CCed Lars too which AFAIR mentioned something like this to me at some point? Is there any ongoing development related to that idea? I don't know of any. There is a description given in [1] and apart from that, are there any concerns of it? I would like to know your ideas and suggestions about it, to proceed. Please let me know if you have something to share with me, I'm looking forward to your feedback. Michael and Simon might be able to fill the blanks. About concerns, the one that comes to mind immediately is that dpkg treats the packages as the basic units of operation, when invoked it first parses the control files for all provided packages, and then operates on them, reordering if needed, bailing out if dependencies cannot be satisfied, breaking cycles, etc. If the packages are not on disk, and they are streamed to dpkg, then it might not be able to operate properly. Which might not be an unsurmountable issue, but then I've not thought this through too much... Something which I guess would speed up the installation process could be to just make apt download the packages in self-contained batches, which can be unpacked/configured independently. This would also not really need any change in dpkg AFAICS. This way the installation process could start sooner than having to wait for the whole thing to get downloaded. It does not remove the need to store those batched packages on disk, but still. [1] http://wiki.debian.org/SummerOfCode2010/StreamingPackageInstall thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110105060107.ga...@gaara.hadrons.org
Bug#608884: dpkg-vendor: please document format of /etc/dpkg/origins/ files
Package: dpkg Version: 1.15.8.6 Severity: wishlist Hello, in order to properly resolve #607850 we'd like to know the full specification of /etc/dpkg/origins/ files (we couldn't find the documentation). Thanks in advance, Sandro -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 8.5-1 GNU core utilities ii libbz2-1.01.0.5-6high-quality block-sorting file co ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib ii libselinux1 2.0.89-2 SELinux runtime shared libraries ii xz-utils 4.999.9beta+20100713-1 XZ-format compression utilities ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.8.10 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#548415: reportbug: Package upgrade information in bug reports
Processing commands for cont...@bugs.debian.org: clone 548415 -1 Bug#548415: reportbug: Package upgrade information in bug reports Bug 548415 cloned as bug 608930. reassign -1 dpkg Bug #608930 [reportbug] reportbug: Package upgrade information in bug reports Bug reassigned from package 'reportbug' to 'dpkg'. Bug No longer marked as found in versions reportbug/4.8. retitle -1 please provide a tool to parse dpkg.log* files Bug #608930 [dpkg] reportbug: Package upgrade information in bug reports Changed Bug title to 'please provide a tool to parse dpkg.log* files' from 'reportbug: Package upgrade information in bug reports' block 548415 by -1 Bug #548415 [reportbug] reportbug: Package upgrade information in bug reports Was not blocked by any bugs. Added blocking bug(s) of 548415: 608930 thanks Stopping processing here. Please contact me if you need assistance. -- 548415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548415 608930: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608930 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608829: dpkg-dev - dpkg-source rejects valid patch files
Hi! On Mon, 2011-01-03 at 21:41:57 +0100, Raphael Hertzog wrote: On Mon, 03 Jan 2011, Bastian Blank wrote: I don't know whether I'm going to accept this request. I'm rather enclined to tag it wontfix. But I welcome supplementary feedback. Okay, another nail in the cofin of the quilt source format. It looks like a mistake to even thought about using it. I haven't taken any decision yet, but you're the first to complain about this particular (mis-)feature so it can't be so annoying as you make it sound like. Or maybe I should turn it into a warning and not die. I personally don't see any harm in allowing it, even w/o a warning. ISTR using this at some point in the past with v1 sources and quilt patches when manually editing something (for whatever reason) and appending a new hunk for an existing patches file which belonged in the same logical patch. I don't think I've had the need for this at all lataly, given that I tend to refresh the patches to avoid fuzzies. But I can see how not divering from an upstream provided patch makes sense, although then that argument does not apply if one ends up concatenating them anyway. There's though still the possible argument that the patch is like that upstream already. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
tag 21941 wontfix thanks [ Goswin, removing the wontfix tag is not something for you to decide. ] On Sun, 2010-12-26 at 16:56:49 +0100, Andreas Barth wrote: re usage of /var: dpkg puts the package data into /var/lib/dpkg/info. This includes the list of files, the list of conffiles, templates, md5sums and also the maintainer scripts of each package. According to FHS: | /var contains variable data files. This includes spool directories and | files, administrative and logging data, and transient and temporary | files. re /var/lib: | This hierarchy holds state information pertaining to an application or | the system. The usage of /var/lib/dpkg matches that description IMHO. ... as those files are clearly state for dpkg. Those scripts are variable in the sense that they might appear, disappear, or change during a dpkg run. So the location seems perfectly fine to me. It's more relevant though the snippet Goswin pasted: | /var/lib/name is the location that must be used for all distribution | packaging support. Different distributions may use different names, of | course. The same equivalent path rpm is using for example. And thus I don't see the point in changing the current location. Even if the /usr/lib location could be interpreted and argued as valid too, I'd not see the point in changing it, given the coding and transition work involved, susceptible to system breakage, and unfortunately also because there are programs out there which rely on those paths (which could be solved with symlinks, but then we'd be getting into really ugly territory, for no really good reason). But mostly given the solution below. possible ways for /var to be no-exec [...] per local admin 4. remount /var with exec ~ AFAICS there is no option within dpkg (or not documented) to always execute commands prior to an dpkg writing invocation (while there is within apt). It might make sense to remount /var with exec in case it's noexec before running any scripts. I think adding hooks for dpkg to run scripts pre-/post-changing requests (e.g. configure, remove, install, ...) might make sense. There's already the invoke hooks (see man dpkg), present since 1.15.4, which allow just that. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#21941: dpkg usage of /var
Processing commands for cont...@bugs.debian.org: tag 21941 wontfix Bug #21941 [dpkg] scripts under /var prevent mounting /var with noexec Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 21941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21941 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
