Bug#334450: Review of proposed stable changes
Hi, On Sun, Oct 30, 2005, Loic Minier wrote: There's something wrong, still no buildd logs appear for libgnomeprint. libgnomeprint now appears for all architectures, please consider it for the next stable release. Cheers, -- Loïc Minier [EMAIL PROTECTED] What do we want? BRAINS!When do we want it? BRAINS!
Bug#334450: Review of proposed stable changes
Loic Minier wrote: On Wed, Oct 26, 2005, Martin Schulze wrote: Indeed, they're missing. Your source package is in the archive, though, and looks good. There's something wrong, still no buildd logs appear for libgnomeprint. Would you please have a look at wanna-build? Hmm, that's strange. wanna-build says: alpha: libs/libgnomeprint_2.8.2-1: Installed [optional:] arm: libs/libgnomeprint_2.8.2-1: Installed [optional:] hppa: libs/libgnomeprint_2.8.2-1: Installed [optional:] i386: libs/libgnomeprint_2.8.2-1: Installed [optional:] ia64: libs/libgnomeprint_2.8.2-1: Installed [optional:] m68k: libs/libgnomeprint_2.8.2-1: Installed [optional:] mips: libs/libgnomeprint_2.8.2-1: Installed [optional:] mipsel: libs/libgnomeprint_2.8.2-1: Installed [optional:] powerpc: libs/libgnomeprint_2.8.2-1: Installed [optional:] s390: libs/libgnomeprint_2.8.2-1: Installed [optional:] sparc: libs/libgnomeprint_2.8.2-1: Installed [optional:] So it doesn't even know about the new version 2.8.2-1.1. I'll ping neuro. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
On Wed, Oct 26, 2005, Martin Schulze wrote: Indeed, they're missing. Your source package is in the archive, though, and looks good. There's something wrong, still no buildd logs appear for libgnomeprint. Would you please have a look at wanna-build? Thanks, -- Loïc Minier [EMAIL PROTECTED] What do we want? BRAINS!When do we want it? BRAINS!
Bug#334450: Review of proposed stable changes
On Wed, Oct 26, 2005, Martin Schulze wrote: That looks a lot better. There's one more thing, though, you'll have to do before you can upload: bump up the version number since you had already uploaded the other package with the large diff. After that, it should be fine. (the urgency should be at least medium, though, but that's not that important). When I uploaded it, that was with a .2 NMU number (ie. I bumped the version). The urgency was low though, but you said that's not as important. I don't see buildd logs for this version though. Cheers, -- Loïc Minier [EMAIL PROTECTED] What do we want? BRAINS! When do we want it? BRAINS!
Bug#334450: Review of proposed stable changes
Loic Minier wrote: On Wed, Oct 26, 2005, Martin Schulze wrote: That looks a lot better. There's one more thing, though, you'll have to do before you can upload: bump up the version number since you had already uploaded the other package with the large diff. After that, it should be fine. (the urgency should be at least medium, though, but that's not that important). When I uploaded it, that was with a .2 NMU number (ie. I bumped the version). The urgency was low though, but you said that's not as important. I don't see buildd logs for this version though. Indeed, they're missing. Your source package is in the archive, though, and looks good. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
Loic Minier wrote: Hi, I'm willing to do a stable-proposed-updates upload of libgnomeprint2.2-0 to address #334450. It is an important usability bug, but I know that important bugs can not always be addressed in stable. Joey: please check the severity of #334450 and the length of the patch and tell me whether you would accept such an upload to SPU. If I understand the problem correctly, for some reason libgnomeprint does not use the proper lpr command. However, the patch does not implicate the execution location. Let's take a look at the patch: +#if !defined(HAVE_POPEN) +#ifdef G_OS_WIN32 +#include stdio.h +#define popen(f,m) _popen(f,m) +#endif +#endif + +#if !defined(HAVE_PCLOSE) +#ifdef G_OS_WIN32 +#include stdio.h +#define pclose(f) _pclose(f) +#endif +#endif + Redefining popen/pclose to internal routines. Why? - tcustom-pipe = popen (command, wb); + tcustom-pipe = popen (command, +#ifdef G_OS_WIN32 + wb +#else + w +#endif Taking care of windows. No thanks. -#if !defined(HAVE_CLOSE) +#if !defined(HAVE_PLOSE) Turning a valid ifdef into an invalid one. Don't look suited for me. Please explain. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
On Tue, Oct 25, 2005, Loic Minier wrote:
I also attach a test case showing that Linux popen fails with the b
flag.
Oups, here you go.
--
Loïc Minier [EMAIL PROTECTED]
What do we want? BRAINS! When do we want it? BRAINS!
#include stdio.h /* popen(), fprintf(), pclose() */
int main(void) {
FILE * f;
f = popen(cat, w);
if (NULL == f)
return 1;
fprintf(f, Foo 1.\n);
pclose(f);
f = popen(cat, wb);
if (NULL == f)
return 2;
fprintf(f, Foo 2.\n);
pclose(f);
return 0;
}
Bug#334450: Review of proposed stable changes
Hi,
On Tue, Oct 25, 2005, Martin Schulze wrote:
If I understand the problem correctly, for some reason libgnomeprint does
not use the proper lpr command. However, the patch does not implicate
the execution location.
Actually, the problem is not the PATH or the availability of the lpr
command, but simply a mistake in the arguments passed to popen(3).
Linux' popen doesn't support the b flag which means binary under
windows (windows doesn't assume binary by default).
I'm sorry for having wasted your time with the first patch, attached is
a clean patch which fixes only the flags passed to popen(). It is a
one-liner.
[ The first patch had 1/ a typo, 2/ the upstream fix which also takes
care of keeping the b flag under Windows, 3/ intended to have an
ifdef fix for Windows (#if !defined(HAVE_PCLOSE) instead of #if
!defined(HAVE_CLOSE)). ]
I also attach a test case showing that Linux popen fails with the b
flag.
Cheers,
--
Loïc Minier [EMAIL PROTECTED]
What do we want? BRAINS! When do we want it? BRAINS!
diff -urN
libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
--- libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
2004-12-03 19:25:09.0 +0100
+++ libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
2005-10-25 12:41:38.0 +0200
@@ -146,7 +146,7 @@
command = g_strdup (lpr);
}
- tcustom-pipe = popen (command, wb);
+ tcustom-pipe = popen (command, w);
if (tcustom-pipe == NULL) {
g_warning (Opening '%s' for output failed, command);
Bug#334450: Review of proposed stable changes
Loic Minier wrote: Hi, On Tue, Oct 25, 2005, Martin Schulze wrote: If I understand the problem correctly, for some reason libgnomeprint does not use the proper lpr command. However, the patch does not implicate the execution location. Actually, the problem is not the PATH or the availability of the lpr command, but simply a mistake in the arguments passed to popen(3). Linux' popen doesn't support the b flag which means binary under windows (windows doesn't assume binary by default). I'm sorry for having wasted your time with the first patch, attached is a clean patch which fixes only the flags passed to popen(). It is a one-liner. Understood. I misparsed the patch. Please upload a fixed package based on the patch you attached. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
Loic Minier wrote: On Tue, Oct 25, 2005, Martin Schulze wrote: Please upload a fixed package based on the patch you attached. Uploaded. Attached are the relevant interdiff and debdiff. I'm afraid the huge debdiff exposes that: - the Uploaders were updated with the latest version of the GNOME team as found in the gnome-pkg-tools package in sarge - the config.guess and config.sub were updated by CDBS and both the new and the old files appear in the interdiff Both parts aren't easily avoidable. BOTH PARTS ARE VERY EASY TO AVOID. cp patch foo/debian/patches dch -i / emacs debian/changelog fine. I'm sorry, but please reupload with only the patch you provided in the last mail, the onliner. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
On Tue, Oct 25, 2005, Martin Schulze wrote: BOTH PARTS ARE VERY EASY TO AVOID. cp patch foo/debian/patches dch -i / emacs debian/changelog fine. I'm sorry, but please reupload with only the patch you provided in the last mail, the onliner. This is exactly what I did, and then I built the package (I called pdebuild --configfile ~/.pbuilder/sarge.pbuilderrc -- --pkgname-logfile). I couldn't find any option to prevent dpkg-buildpackage or debuild or pdebuild of calling the clean target (the -nc flag implies a binary only upload), and the uploaders are generated during clean. The config.guess config.sub part is copied at build time by CDBS, in a target that can't be skipped. Please have a look in /usr/share/cdbs/1/rules/buildcore.mk and share my pain. :-/ Or do you want me to do a source-only upload? I doubt that. Cheers, -- Loïc Minier [EMAIL PROTECTED] What do we want? BRAINS! When do we want it? BRAINS!
Bug#334450: Review of proposed stable changes
Loic Minier wrote: On Tue, Oct 25, 2005, Martin Schulze wrote: BOTH PARTS ARE VERY EASY TO AVOID. cp patch foo/debian/patches dch -i / emacs debian/changelog fine. I'm sorry, but please reupload with only the patch you provided in the last mail, the onliner. That should be followed by dpkg-source -b, of course. This is exactly what I did, and then I built the package (I called pdebuild --configfile ~/.pbuilder/sarge.pbuilderrc -- --pkgname-logfile). I couldn't find any option to prevent dpkg-buildpackage or debuild or pdebuild of calling the clean target (the -nc flag implies a binary only upload), and the uploaders are generated during clean. The config.guess config.sub part is copied at build time by CDBS, in a target that can't be skipped. Please have a look in /usr/share/cdbs/1/rules/buildcore.mk and share my pain. :-/ Or do you want me to do a source-only upload? I doubt that. No, but a binary upload based on a clean source package. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
Hi,
On Tue, Oct 25, 2005, Martin Schulze wrote:
That should be followed by dpkg-source -b, of course.
Ok, I didn't knew about that, and it offered a shorter debdiff at the
end indeed. I did:
dpkg-source -x libgnomeprint_2.8.2-1.dsc
cd libgnomeprint-2.8.2 patch -p1 libgnomeprint_2.8.2-1.1.diff cd -
dpkg-source -b libgnomeprint-2.8.2
interdiff -z -p1 libgnomeprint_2.8.2-1.diff.gz libgnomeprint_2.8.2-1.2.diff.gz
~/libgnomeprint_2.8.2-1.2.diff
cd libgnomeprint-2.8.2 dpkg-buildpackage -rfakeroot -us -uc cd -
debdiff libgnomeprint-2.8.2-1.dsc libgnomeprint-2.8.2-1.2.dsc
I attach the updated debdiff and interdiff (interdiff is identical).
Bye,
--
Loïc Minier [EMAIL PROTECTED]
diff -u libgnomeprint-2.8.2/debian/changelog
libgnomeprint-2.8.2/debian/changelog
--- libgnomeprint-2.8.2/debian/changelog
+++ libgnomeprint-2.8.2/debian/changelog
@@ -1,3 +1,11 @@
+libgnomeprint (2.8.2-1.2) stable; urgency=low
+
+ * Non-maintainer upload tagetted at stable-proposed-updates.
+ * Fix calling of custom print commands. popen() was called with an invalid
+b flag. (Closes: #334450) [debian/patches/64_popen_without_b_flag.patch]
+
+ -- Loic Minier [EMAIL PROTECTED] Tue, 25 Oct 2005 13:16:24 +0200
+
libgnomeprint (2.8.2-1) unstable; urgency=medium
* New upstream release
only in patch2:
unchanged:
--- libgnomeprint-2.8.2.orig/debian/patches/64_popen_without_b_flag.patch
+++ libgnomeprint-2.8.2/debian/patches/64_popen_without_b_flag.patch
@@ -0,0 +1,12 @@
+diff -urN
libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
+--- libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
2004-12-03 19:25:09.0 +0100
libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
2005-10-25 12:41:38.0 +0200
+@@ -146,7 +146,7 @@
+ command = g_strdup (lpr);
+ }
+
+- tcustom-pipe = popen (command, wb);
++ tcustom-pipe = popen (command, w);
+
+ if (tcustom-pipe == NULL) {
+ g_warning (Opening '%s' for output failed, command);
diff -u libgnomeprint-2.8.2/debian/changelog
libgnomeprint-2.8.2/debian/changelog
--- libgnomeprint-2.8.2/debian/changelog
+++ libgnomeprint-2.8.2/debian/changelog
@@ -1,3 +1,11 @@
+libgnomeprint (2.8.2-1.2) stable; urgency=low
+
+ * Non-maintainer upload tagetted at stable-proposed-updates.
+ * Fix calling of custom print commands. popen() was called with an invalid
+b flag. (Closes: #334450) [debian/patches/64_popen_without_b_flag.patch]
+
+ -- Loic Minier [EMAIL PROTECTED] Tue, 25 Oct 2005 13:16:24 +0200
+
libgnomeprint (2.8.2-1) unstable; urgency=medium
* New upstream release
only in patch2:
unchanged:
--- libgnomeprint-2.8.2.orig/debian/patches/64_popen_without_b_flag.patch
+++ libgnomeprint-2.8.2/debian/patches/64_popen_without_b_flag.patch
@@ -0,0 +1,12 @@
+diff -urN
libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
+--- libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c
2004-12-03 19:25:09.0 +0100
libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
2005-10-25 12:41:38.0 +0200
+@@ -146,7 +146,7 @@
+ command = g_strdup (lpr);
+ }
+
+- tcustom-pipe = popen (command, wb);
++ tcustom-pipe = popen (command, w);
+
+ if (tcustom-pipe == NULL) {
+ g_warning (Opening '%s' for output failed, command);
Bug#334450: Review of proposed stable changes
Loic Minier wrote: Hi, On Tue, Oct 25, 2005, Martin Schulze wrote: That should be followed by dpkg-source -b, of course. Ok, I didn't knew about that, and it offered a shorter debdiff at the end indeed. I did: That looks a lot better. There's one more thing, though, you'll have to do before you can upload: bump up the version number since you had already uploaded the other package with the large diff. After that, it should be fine. (the urgency should be at least medium, though, but that's not that important). Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334450: Review of proposed stable changes
Hi, I'm willing to do a stable-proposed-updates upload of libgnomeprint2.2-0 to address #334450. It is an important usability bug, but I know that important bugs can not always be addressed in stable. Joey: please check the severity of #334450 and the length of the patch and tell me whether you would accept such an upload to SPU. Thanks, -- Loïc Minier [EMAIL PROTECTED]
