Bug#485552: reprepro: Patches for portability to AIX
After installing zlib 1.2.3, and configuring with CC='gcc -pthread' CPPFLAGS=-DO_NOFOLLOW=0 LIBS=-liberty, the remaining changes I need to get reprepro to compile are detecting big- or little-endian systems, defining _D_EXACT_NAMELEN, and including stdlib.h. On a 32-bit platform, having NULL defined as 0 doesn't matter. This is a much smaller set of changes. Sorry for including so many unnecessary modifications in the first patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485552: reprepro: Patches for portability to AIX
On Wed, Jun 11, 2008 at 4:00 AM, Bernhard R. Link <[EMAIL PROTECTED]> wrote: > Thanks for testing reprepro there. But please note reprepro is targeted > for systems using glibc or other compatible ones having all the gnu > extensions I like to use, as I deem reprepro seldom useful outside Debian > systems. No problem. >> - The last parameter for execl() should be (char*)NULL, not just NULL, >> in case char* is a different size to whatever NULL resolves to. GCC >> 4.3 warns about this on AIX. > > What is NULL there? I'm assuming NULL is (void)0 (and not simply 0). > Does compiling with "-DNULL=(void*)0" help? NULL is 0, as per C99 sections 7.17.3 and 6.3.2.3.3; defining NULL to (void*)0 helps. The Open Group examples at http://www.opengroup.org/onlinepubs/95399/functions/exec.html do all use (char *)0. > I think that can also easily worked around by just adding -DO_NOFOLLOW=0 > to CPPFLAGS. True. This could also go into configure with AC_CHECK_DECL, but that might be a bit dangerous. > Aren't vasnprintf and dprintf in libiberty, too? At least vasnprintf I > would have expected there. It is, though I don't see dprintf. Of course, I only started looking for getopt_long once I'd reimplemented mprintf(); I could have saved myself quite a bit of time. >> - _D_EXACT_NAMELEN is a GNU extension. I just use strlen(r->d_name) if >> it isn't defined. > > Well, this could be fixed with a -D, too. But I think that is garanteed > to be an #define and it's only three lines in an header, so I added > that. And for what it's worth, _D_EXACT_NAMELEN would expand to exactly that in this case. > Does it really produce correct .gz files when you just prevent the > safety guard against too old versions (At least I an hardly imagine > they have an gz header)? Thanks for setting me straight, I should have looked further first. Now I get to see whether I can recompile zlib without breaking the custom version of OpenSSH here. I'll see how I go with libiberty and zlib 1.2. Thanks. -- Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485552: reprepro: Patches for portability to AIX
Package: reprepro
Version: 3.5.0
Tags: patch
This bug is not about the Debian packaging of reprepro, but about
compiling the upstream source on a non-Linux system.
For various reasons, I'm compiling reprepro for AIX 5.3 with GCC, to
use on IBM i5/OS V5R4 for a few hundred Debian PCs. I encountered a
handful of problems that needed changes, as listed below, and I'm
including a patch for most of them. Overall I'm very impressed with
the portability of the code.
- A number of the files use malloc() and free() without including
. The AIX C library is careful only to define these where
the various standards say they should be found. I haven't provided a
patch for this one.
- The last parameter for execl() should be (char*)NULL, not just NULL,
in case char* is a different size to whatever NULL resolves to. GCC
4.3 warns about this on AIX.
- AIX 5.3 doesn't provide O_NOFOLLOW. I most cases, this is combined
with O_EXCL which seems to be redundant, and I've removed it; in
donefile.c I've taken the potential security exposure and not used it.
You might wish to define it to 0 instead.
- AIX 5.3 doesn't have , but does get the BSD-ish
BYTE_ORDER, BIG_ENDIAN and LITTLE_ENDIAN macros if you include
and/or . I haven't included a patch for
configure.ac, etc., to get them to detect HAVE_ENDIAN_H on Linux, but
it should be trivial. Alternatively, there's AC_C_BIGENDIAN.
- AIX 5.3 doesn't have vasnprintf (or dprintf). I've removed
vmprintf(), changed formaterror to use snprintf with a static buffer
that is much larger than anything it will have to hold, and changed
mprintf() and dprintf() to call vsnprintf twice, as shown in the GNU
libc manual. I figure that there's no point making dprintf() use
vasprintf(), because they're both GNU libc extensions.
- _D_EXACT_NAMELEN is a GNU extension. I just use strlen(r->d_name) if
it isn't defined.
- I don't check zlibCompileFlags() when using zlib 1.1, which is what
I have available.
- AIX doesn't have getopt_long, but I've compiled against libiberty from GCC.
- AIX GCC needs an option "-pthread" to compile and link threadsafe
code (like Berkeley DB), not -D_REENTRANT. I added this option to the
CFLAGS when running configure. I don't know how autoconf is supposed
to discover this.
Please let me know if you'd like any more information.
--
Laissez lire, et laissez danser; ces deux amusements ne feront jamais
de mal au monde.
*** aptmethod.c.origFri Jun 6 21:07:53 2008
--- aptmethod.c Tue Jun 10 11:40:10 2008
***
*** 335,341
if( methodname == NULL )
exit(255);
! (void)execl(methodname,methodname,NULL);
e = errno;
fprintf(stderr, "Error %d while executing '%s': %s\n",
--- 335,341
if( methodname == NULL )
exit(255);
! (void)execl(methodname,methodname,(char*)NULL);
e = errno;
fprintf(stderr, "Error %d while executing '%s': %s\n",
*** checks.c.orig Wed Apr 9 01:01:42 2008
--- checks.cTue Jun 10 10:34:11 2008
***
*** 171,185
static const char *formaterror(const char *format, ...) {
va_list ap;
! static char *data = NULL;
- if( data != NULL )
- free(data);
va_start(ap, format);
! data = vmprintf(format, ap);
va_end(ap);
- if( data == NULL )
- return "Out of memory";
return data;
}
--- 171,181
static const char *formaterror(const char *format, ...) {
va_list ap;
! static char data[1024];
va_start(ap, format);
! snprintf(data, sizeof(data), format, ap);
va_end(ap);
return data;
}
*** database.c.orig Wed Apr 9 01:01:43 2008
--- database.c Tue Jun 10 11:28:38 2008
***
*** 84,90
lockfile = calc_dirconcat(db->directory, "lockfile");
if( lockfile == NULL )
return RET_ERROR_OOM;
! fd =
open(lockfile,O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW|O_NOCTTY,S_IRUSR|S_IWUSR);
while( fd < 0 ) {
int e = errno;
if( e == EEXIST ) {
--- 84,90
lockfile = calc_dirconcat(db->directory, "lockfile");
if( lockfile == NULL )
return RET_ERROR_OOM;
! fd = open(lockfile,O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY,S_IRUSR|S_IWUSR);
while( fd < 0 ) {
int e = errno;
if( e == EEXIST ) {
***
*** 95,101
while( timetosleep > 0 )
timetosleep = sleep(timetosleep);
tries++;
! fd =
open(lockfile,O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW|O_NOCTTY,S_IRUSR|S_IWUSR);
continue;
}
--- 95,101
while( timetosleep > 0 )
Bug#418731: tn5250: F13-F24 no longer work
% infocmp xterm | grep kf13 kf11=\E[23~, kf12=\E[24~, kf13=\EO2P, kf14=\EO2Q, I already have some customised resources for xterm started by the xt5250 command, so it would be easy to add *modifyFunctionKeys: 0 to those in /usr/share/tn5250/XTerm. I guess that would break if the xterm definition in ncurses-base is changed (so would gnome-terminal), so I may add some more keyboard translations directly to the key sequences that tn5250 expects. This avoids any assumption that Shift-F1 is even supposed to be kf13, and so on, on a given keyboard and terminal emulator. (For my own reference, I need to something similar for rxvt, where Shift-F1 appears to be kf11.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418731: tn5250: F13-F24 no longer work
It looks like Shift-F1 to Shift-F4, at least, no longer generate kf13 to kf16 according to the xterm terminfo entry, and there's nothing in terminfo for the control sequences that are generated instead. tn5250 uses terminfo kf13 to kf24 for the shifted function keys. I'll have a look at the resource that Thomas Dickey mentioned, and see what I need to change to match terminfo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363682: linux-image-2.6.16-1-k7: amd76x_edac blocks amd_k7_agp
Package: linux-image-2.6.16-1-k7 Version: 2.6.16-7 Severity: normal Loading both the amd76x_edac module and the amd_k7_agp module in either order stops the second module from being initialised. This appears to be because they're both associated with the same host bridge, class 0600, device 1022:700e. In my case, I prefer working AGP to EDAC, so I've created a new file in /etc/hotplug/blacklist.d/ to prevent amd76x_edac from being loaded automatically. However, I don't see why both modules shouldn't be able to be loaded at the same time. When amd76x_edac is loaded first, I get these messages from dmesg during boot: MC: drivers/edac/edac_mc.c version edac_mc Ver: 2.0.0 Apr 15 2006 EDAC MC0: Giving out device to "amd76x_edac" AMD761: PCI :00:00.0 then later, when X starts: [drm] Initialized radeon 1.22.0 20051229 on minor 0 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:drm_unlock] *ERROR* Process 3963 using kernel context 0 With amd76x_edac blacklisted, I get: agpgart: Detected AMD 761 chipset agpgart: AGP aperture is 64M @ 0xe000 then: [drm] Initialized radeon 1.22.0 20051229 on minor 0 agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 1x mode agpgart: Putting AGP V2 device at :01:05.0 into 1x mode [drm] Loading R300 Microcode PCI 0:1:5.0 is my Radeon 9550, class 0300, device 1002:4153. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.16-1-k7 depends on: ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-9 Yet Another mkInitRD Versions of packages linux-image-2.6.16-1-k7 recommends: ii libc6-i6862.3.6-7GNU C Library: Shared libraries [i -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311777: ifupdown: dhclient.leases file deleted on reboot
For what it's worth, I'm using the script below in /etc/init.d/local-leases to copy the leases file back and forth. This only works because eth0 is the only interface using DHCP for me, although I do have some untested sh and sed code to split and recombine the separate files. -- #!/bin/sh perm=/var/lib/dhcp3/dhclient.leases temp=/var/run/dhclient.eth0.leases case "$1" in start) cp -u "$perm" "$temp" ;; stop) cp -u "$temp" "$perm" ;; esac -- This was installed with: update-rc.d local-leases start 39 S . start 36 0 6 . It seems to me that ifup shouldn't pass the -lf option at all, letting dhclient3 manage its own leases. If there are problems with this, it should at least use a permanent directory like /var/lib/ifupdown/dhclient.%iface%.leases or /etc/network/run/dhclient.%iface%.leases. -- Quis custodiet ipsos custodes?
Bug#307859: tn5250: New upstream
Alex Mauer wrote: > There's a new version of tn5250 available, 0.17.3. I'd appreciate if it > could be packaged. Thank you! Hi Alex. Some minor issues have been reported with 0.17.3 on the mailing list, which is not surprising since it's been so long since 0.16.5. I'd like to wait until it stabilises a bit before uploading the new version to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
