Bug#454628: Processed: forcibly merging 330256 454628
On Fri, 18 Jan 2008, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.13 forcemerge 330256 454628 Bug#330256: delete obsolescent not-locally-changed conffiles Bug#454628: obsolete conffiles are not deleted on purge Forcibly Merged 330256 454628. Note that while both are probably tightly related, they are not exactly the same problem. The first is speaking of removing conffiles on upgrade when they would be marked obsolete if the conffile is unmodified... and the second speaks of removing those obsolete files (modified or unmodified doesn't matter here, though if the first is fixed, we would only have modified files here) on purge. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#281057: Rebased patches
Hello,
FWIW I rebased the patchs. Please find them attached. It looks like 2 pretty
minor bugfixes that should be safe to apply.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From fb03c754185dfb50c34b6863ed5060e3d0a78490 Mon Sep 17 00:00:00 2001
From: Egmont Koblinger [EMAIL PROTECTED]
Date: Thu, 1 Nov 2007 16:17:12 +
Subject: [PATCH] Fix a bug in configuration file handling where dpkg didn't respect the --root argument
* src/processarc.c: lstat correct conffile path even with --root.
Previously we would incorrectly ignore --root here. Closes: #281057
---
src/processarc.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/processarc.c b/src/processarc.c
index 1550414..cbad9ba 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -60,7 +60,7 @@ void process_archive(const char *filename) {
static char *cidirbuf = NULL, *reasmbuf = NULL;
static struct fileinlist *newconffiles, *newfileslist;
static enum pkgstatus oldversionstatus;
- static struct varbuf infofnvb, fnvb, depprobwhy;
+ static struct varbuf infofnvb, fnvb, cfnvb, depprobwhy;
static struct tarcontext tc;
int c1, r, admindirlen, i, infodirlen, infodirbaseused, status;
@@ -670,7 +670,12 @@ void process_archive(const char *filename) {
for (cfile= newfileslist; cfile; cfile= cfile-next) {
if (!cfile-namenode-filestat) {
cfile-namenode-filestat= nfmalloc(sizeof(struct stat));
- if (lstat(cfile-namenode-name, cfile-namenode-filestat)) {
+ varbufreset(cfnvb);
+ varbufaddstr(cfnvb,instdir);
+ varbufaddc(cfnvb,'/');
+ varbufaddstr(cfnvb,cfile-namenode-name);
+ varbufaddc(cfnvb,0);
+ if (lstat(cfnvb.buf, cfile-namenode-filestat)) {
if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
--
1.5.3.8
From 88605d1adc515e052c7f7b29ff45b79925bb3343 Mon Sep 17 00:00:00 2001
From: Ian Jackson [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 21:19:36 +0100
Subject: [PATCH] * src/processarc.c (process_archive): Fix incorrect sizeof in a memset call.
---
src/processarc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/processarc.c b/src/processarc.c
index cbad9ba..ac48208 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -680,7 +680,7 @@ void process_archive(const char *filename) {
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
memset(cfile-namenode-filestat, 0,
- sizeof(cfile-namenode-filestat));
+ sizeof(*cfile-namenode-filestat));
continue;
}
}
--
1.5.3.8
Bug#20471: Rebased patch
FWIW, I just rebased Ian's patch and fixed the small conflict. It only
needs some further tweaking for the 0 = NULL changes in theory.
(But I did no tests by myself)
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 01738a918c6ec921e93df16bddf86ef389008641 Mon Sep 17 00:00:00 2001
From: Ian Jackson [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 19:50:06 +
Subject: [PATCH] Check dependencies _on_ the package we're to upgrade. Closes: #20471.
This ensures that the new package will (when it is configured)
satisfy the current setup. We don't mind already-broken dependencies.
Some additional useful comments about dependencies in processarc.c.
---
src/archives.c | 49 +++
src/archives.h |2 +
src/depcon.c | 17 +++
src/processarc.c | 56 +++--
4 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/src/archives.c b/src/archives.c
index 60ee2d5..c96cbc2 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -1059,6 +1059,55 @@ void check_conflict(struct dependency *dep, struct pkginfo *pkg,
return;
}
+static void cu_rdepends_istobe(int argc, void **argv) {
+ struct pkginfo *pkg= argv[0];
+ assert(pkg-clientdata-istobe == itb_normal);
+ pkg-clientdata-istobe= itb_installnew;
+}
+
+void check_rdepends(struct dependency *dep, struct pkginfo *pkg,
+const char *pfilename) {
+ static struct varbuf whynot;
+ int originally, afterwards;
+
+ /* Was this dependency previously satisfied ? If not we don't worry
+ * if it's not going to be satisfied, either. But we count it as
+ * having been previously satisfied even if it technically isn't
+ * because a satisfying package is only unpacked. That avoids
+ * accidentally permanently breaking the dependency just because the
+ * satisfying package happens not to be configured for some reason
+ * (eg because you have just unpacked the good version but haven't
+ * yet configured it).
+ */
+ assert(pkg-clientdata-istobe == itb_installnew);
+ pkg-clientdata-istobe= itb_normal;
+ push_cleanup(cu_rdepends_istobe,~0, 0,0, 1,(void*)pkg);
+ originally= depisok(dep,whynot,0,1);
+ pop_cleanup(ehflag_normaltidy);
+
+ if (!originally) {
+varbufaddc(whynot,0);
+debug(dbg_depcon, disregarding rdepends; dependency already
+ broken:\n %s, whynot.buf);
+return;
+ }
+
+ afterwards= depisok(dep,whynot,0,1);
+ if (afterwards)
+return;
+
+ varbufaddc(whynot,0);
+ fprintf(stderr, _(dpkg: %s containing %s breaks existing dependency:\n%s),
+ pfilename, pkg-name, whynot.buf);
+ if (!(fc_depends ||
+ ignore_depends(dep-up) ||
+ ignore_depends(pkg))) {
+ohshit(_(existing dependency problem - not installing %.250s),pkg-name);
+fprintf(stderr, _(dpkg: warning - ignoring
+ existing dependency problem!\n));
+ }
+}
+
void cu_cidir(int argc, void **argv) {
char *cidir= (char*)argv[0];
char *cidirrest= (char*)argv[1];
diff --git a/src/archives.h b/src/archives.h
index 5696c19..2824f2e 100644
--- a/src/archives.h
+++ b/src/archives.h
@@ -67,6 +67,8 @@ void check_conflict(struct dependency *dep, struct pkginfo *pkg,
const char *pfilename);
void check_breaks(struct dependency *dep, struct pkginfo *pkg,
const char *pfilename);
+void check_rdepends(struct dependency *dep, struct pkginfo *pkg,
+const char *pfilename);
struct fileinlist *addfiletolist(struct tarcontext *tc,
struct filenamenode *namenode);
diff --git a/src/depcon.c b/src/depcon.c
index 30e5936..4595326 100644
--- a/src/depcon.c
+++ b/src/depcon.c
@@ -341,12 +341,19 @@ int depisok(struct dependency *dep, struct varbuf *whynot,
switch (provider-up-up-clientdata-istobe) {
case itb_installnew:
-/* Don't pay any attention to the Provides field of the
- * currently-installed version of the package we're trying
- * to install. We dealt with that by using the available
- * information above.
+/* The Provides field of the currently-installed version
+ * of the package we're trying to install doesn't really
+ * help, but we should at least mention it. We dealt with
+ * the possibility that the to-be-installed version would
+ * help when we checked the available information, above.
*/
-continue;
+sprintf(linebuf, _( %.250s %.250s provides %.250s
+ but is to be supplanted.\n),
+ provider-up-up-name,
+ versiondescribe(provider-up-up-installed.version,
+vdew_nonambig),
+ possi-ed-name);
+break;
case itb_remove:
sprintf(linebuf, _( %.250s provides %.250s but is to be removed.\n),
provider-up-up-name,
Processed: setting package to dpkg dpkg-dev dselect, tagging 28701
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.13 package dpkg dpkg-dev dselect Ignoring bugs not assigned to: dselect dpkg-dev dpkg tags 28701 + pending Bug#28701: dpkg-genchanges should compare the version numbers There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Fri, Jan 18, 2008, Raphael Hertzog wrote: Do we have any idea of how many packages/services actually use dpkg-buildpackage -S ? I know a lot of people do sourceful uploads in Ubuntu (all uploads are sourceful in Ubuntu and PPAs); I don't know of services doing it, but I guess things like buildserver.net might. These can actually call clean manually if they want to take the risk. I think it's not a problem to checkbuilddeps if you skip the test when -nc is passed: people will simply have to learn to -S -nc or -S -d if they want to clean (or fakeroot debian/rules clean manually, as I do). -- Loïc Minier
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Sun, 07 Oct 2007, Frank Lichtenheld wrote: On Sat, Oct 06, 2007 at 09:17:21PM +0200, Loïc Minier wrote: Per policy 7.6, build-deps must be available for clean; pbuilder calls dpkg-buildpackage -S to generate a source suitable to be copied into the build environment; by default, this involves cleaning before building the source, but dpkg-checkbuilddeps isn't run before cleaning. I think dpkg-builcpackage should run dpkg-checkbuilddeps and fail at this point when called with -S. Currently, clean might fail if build-deps are unavailable (such as missing patch system package), but this should really be an error detected earlier on. This behaviour is as old as dpkg-checkbuilddeps itself (see cf5d2919f686a15e8e623130b74af3ba2428fbeb in git). Changing the behaviour would obviously be correct, the question is whether it would actually be better. Do we have any idea of how many packages/services actually use dpkg-buildpackage -S ? I'm leaning towards correctness if it doesn't break too many stuff. Alternatively, we could make it display a warning and not actually exit. And this warning can itself warn that in the future it might fail at that point if -d is not passed. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Processed: setting package to dpkg dpkg-dev dselect, tagging 459359
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.13 package dpkg dpkg-dev dselect Ignoring bugs not assigned to: dselect dpkg-dev dpkg tags 459359 + pending Bug#459359: dpkg-gensymbols: Provide a way to rely on symbol versioning when generating symbols files There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354999: setting package to dpkg dpkg-dev dselect, tagging 354999
Hi, On Fri, 18 Jan 2008, Justin Pryzby wrote: On Fri, Jan 18, 2008 at 08:38:03AM +0200, Guillem Jover wrote: tags 354999 + pending What change are you making? I just checked (after realizing that my http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=925bf488839ed0442700d80c0df681c34bf2ec87 It's the --help output that has been clarified. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#354999: setting package to dpkg dpkg-dev dselect, tagging 354999
On Fri, Jan 18, 2008 at 08:38:03AM +0200, Guillem Jover wrote: # Automatically generated email from bts, devscripts version 2.10.13 package dpkg dpkg-dev dselect tags 354999 + pending Hello, What change are you making? I just checked (after realizing that my bug report might have been unclear or wandering), and s-s-d now has a different message: $ /sbin/start-stop-daemon --start /sbin/start-stop-daemon: need at least one of --exec, --pidfile, --user or --name So the message is already consistent with what the code is (or used to be anyway). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Fri, Jan 18, 2008 at 04:02:56PM +0100, Raphael Hertzog wrote: Do we have any idea of how many packages/services actually use dpkg-buildpackage -S ? pbuilder is probably one of the most prominent. As a matter of fact it checks the build-deps before that though and warns if they aren't satisfied. I'm leaning towards correctness if it doesn't break too many stuff. Alternatively, we could make it display a warning and not actually exit. And this warning can itself warn that in the future it might fail at that point if -d is not passed. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354999: setting package to dpkg dpkg-dev dselect, tagging 354999
On Fri, Jan 18, 2008 at 07:46:52PM +0100, Raphael Hertzog wrote: Hi, On Fri, 18 Jan 2008, Justin Pryzby wrote: On Fri, Jan 18, 2008 at 08:38:03AM +0200, Guillem Jover wrote: tags 354999 + pending What change are you making? I just checked (after realizing that my http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=925bf488839ed0442700d80c0df681c34bf2ec87 It's the --help output that has been clarified. Oh. Might I suggest calling those matching options instead of mandatory options? Also they could be segregated in the manpage, too. Thanks Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
