Re: Removing dpkg arch definition for arm64ilp32?
On Sat, Nov 11, 2023 at 08:36:16PM +, Wookey wrote: >On 2023-11-11 18:57 +0100, Guillem Jover wrote: >> Hi! >> >> On Fri, 2023-10-27 at 20:17:21 -0400, Lennart Sorensen wrote: >> > On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote: >> > > Are either of those ports (armeb/arm64ilp32) actually useful / alive >> > > at this point? >> > >> > Not that I have seen. I didn't think anything other than the IXP ever >> > really used big endian and that's a long time ago. arm64ilp32 seems >> > to serve less purpose than x32 did (and x32 doesn't seem to be doing >> > much either). Certainly looks essentially dead at this point. >> >> While scanning the libc-alpha list recently I read [M] that arm64ilp32 >> was never upstreamed in Linux nor glibc? If so, I think there's little >> point in carrying the arch definitions in dpkg, and I guess that would >> not make the cut if requested now (for reference this was requested in >> bug #824742). Does anyone know whether it was ever used or it is being >> used even if privately/internally somewhere? > >It was being used internally/developmentally for a while (at CISCO) >but, as you observe, only with large kernel and toolchain >patches. Various groups dragged their feet on this to disourage it >becoming a thing we'd all have to maintain for years. I was doing the >debian development at ARM at the time and the bootstrap was never >completed. A few people (largely just CISCO) wanted it quite >badly. Nearly everyone else thought it was not worth the maintenance >effort. No-one has asked about it for quite a few years now (last mail >Oct 2018) so I think we can assume that it is indeed dead and no-one >would notice for years/ever if you removed it from dpkg. +1 on the story and on dropping it. >> For armeb, I assume it was properly upstreamed at the time, and it was >> actually used, even if it's currently not in use (like arm) I see tons >> of references in Sources files, and thus removing the arch definitions >> for either of these would not be safe right now I think. > >It is obsolete. It probably doesn't work any more having been unused >since the early days of the NSLU2/Sarge (circa 2006/2007). It might >still have been in use till 2011ish?. As you say it should probably be >removed from upstream sources before it is removed from >dpkg. Interesting question on how much effort (if any) (and when) >should be applied to tidying up stuff like this which is simply no >longer in use. If/when 'arm' is removed 'armeb' should certainly go >with it. armeb was mostly before my involvement in any arm stuff, as Wookey says. It did at least have some life as a functioning port, at least. I'd agree on leaving it in place for now, assuming it's not causing any trouble in terms of maintenance / support. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches
Hey Guillem! On Thu, Apr 27, 2023 at 11:27:47PM +0200, Guillem Jover wrote: >Hi Steve! > >I was recently working on the Dpkg::Shlibs::Objdump module code >related to ELF and ABI tracking, and when seeing the ARM handling >missing there, recalled the issues we saw some time ago with ARM >when I tried to make that tracking more strict, which had to be >reverted due to issues with objects in the wild. For context that >was #853793. Oh $deity, that's going back a while... :-) >I was wondering whether you (or know if someone else) had worked on >the ARM port side of things to clean up those issues, from toolchain to >specific objects in packages? I'm not in a hurry to add that code back >so do not feel any pressure from this, I'm mostly wondering where we are >at with this, and whether there is something I can improve from dpkg side >in that regard, but if not that's also fine, and then I'd probably try >to update the status somewhere (code comment or wiki or something). I've moved on from being employed by Arm 3 years ago, and I've got plenty of other things to keep me busy now. If we're still seeing issues in packages today, then maybe we might find some help from Wookey or Emmanuel (who should both be reading this list!). >(I think at least the issue with wine should be solved now with commit >https://salsa.debian.org/wine-team/wine/-/commit/51f48d3e6c04cef760610d14ba5f368e7f2baf7a) Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: debsigs - status and plans?
On Mon, May 17, 2021 at 02:14:09PM +0200, Guillem Jover wrote: >Hi! > >On Mon, 2021-05-17 at 12:32:52 +0100, Steve McIntyre wrote: >> I'm working on a project where inline signatures on Debian-style >> packages would be very useful, so I've started playing with debsigs >> and debsig-verify. Both packages *appear* to be maintained, with >> uploads during the Bullseye development cycle. But right now things >> don't work with gpg2, as shipped in Buster onwards (#988368, >> #988646). > >The debsig-verify one seems like a non-issue to me. :) But then both >should really be switching away from --list-packets, as that's not a >supported interface to be used by third-parties, but at the time I >looked for how the fetch the same information, it either looked painful >or not possible. I need to recheck, but what I ended up doing instead >is add support for Sequoia PGP which has better interfaces. :) Nod, that's fair enough. :-) >> I'm also very surprised that debsigs doesn't have any >> verification code (#988369) - I'd always expect tools like this to be >> able to verify their own output! > >I guess debsig-verify has filled that role since the beginning? I suppose so, yes. I'm a firm believer in writing tools that can do the round-trip directly - I find it helps for debugging issues. :-) >> AIUI there was a plan to integrate signing more closely with dpkg. Is >> that likely to happen at some point, and if so will it be compatible >> with what's already shipped? If so, I may be able to help with the >> existing tools. Alternatively, I may need to develop a parallel >> implementation for my project, and obviously I'd like to stay >> compatible if that's possible. > >dpkg already supports running debsig-verify at unpack time. The >changes that were in "the plans" were mainly to make the signature >format acceptable to ftp-masters so that signed binaries could be >uploaded there. > >The idea has been to pack all such signatures inside a single member >(called something like sigs.tar.*), which would then indeed be >incompatible with the current format. The way I see it, the old format >would be kept supported though. Right, OK. >I guess at the same time it might be worth pondering about one of the >complaints that caused dpkg-sig to be created, which is the ability to >sign remote .debs, which would require signing digests of the ar members >instead of the members themselves, but that means needing to encode what >digest to use and how to transition to new ones, etc. > >Another problem with adding support for signed binaries to DAK is >that this would need a rethink of reproducible builds support, and >how to replay those signatures from other archives or similar. > >This was partially tracked at ><https://wiki.debian.org/Teams/Dpkg/Spec/DebSignatures>. Ah, excellent. I did some searches, but my google-fu failed today. >All this has made this a not very urgent issue to tackle, TBH. > >> Can you give me some advice here please? > >If there is no requirement of having to upload those signed binaries >into Debian, then I don't think any such format change are limiting >factors, and the current design and implementation should be enough >as is (barring specific bugs). > >If there other needs or requirements involved, I've happy to hear! Actually, I think that's it! This is a work project and we're not intending any of this to go anywhere near the main Debian archive. Your clue in #988646 has helped enormously. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
debsigs - status and plans?
[ Added Peter on CC in case he's not reading the -dpkg list ] Hi folks, I'm working on a project where inline signatures on Debian-style packages would be very useful, so I've started playing with debsigs and debsig-verify. Both packages *appear* to be maintained, with uploads during the Bullseye development cycle. But right now things don't work with gpg2, as shipped in Buster onwards (#988368, #988646). I'm also very surprised that debsigs doesn't have any verification code (#988369) - I'd always expect tools like this to be able to verify their own output! AIUI there was a plan to integrate signing more closely with dpkg. Is that likely to happen at some point, and if so will it be compatible with what's already shipped? If so, I may be able to help with the existing tools. Alternatively, I may need to develop a parallel implementation for my project, and obviously I'd like to stay compatible if that's possible. Can you give me some advice here please? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Optional Build-Depends
On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote: ... >Rationales: > > >1. You can start optionally build-depending on stuff available > only on some architectures, without having to use arch restriction > lists. > > Arch restriction lists are tediuous, especially also because in > the case of libraries, they need to be recursively applied: > > libfoo is only available on bar > libbaz depends on libfoo > > results in build-depends: libbaz [bar] > > With optional build-depends, you can just write libbaz? and > not have to update the dep each time libfoo appears on a new > arch. (apply argument to longer recursive chains) Hmmm. What happens if a build-dep is transiently not available? How can you guarantee controllable, predictable behaviour? -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: [RFC] Switching dpkg-deb --uniform-compression by default
On Fri, Jul 15, 2016 at 04:50:27AM +0200, Cyril Brulebois wrote: >Hi, > >Guillem Jover (2016-07-06): >> I'd like consider switching dpkg-deb --uniform-compression by default, >> so that both control.tar and data.tar members use the same >> compression, which currently would be xz (or gzip with -Zgzip). > >(AFAICT 'none' is still supported, contrary to 'bzip2' and 'lzma'). > >That wouldn't seem crazy to me. > >> This would give us more uniform and smaller packages. I think the d-i >> people wanted something like this (?). > >[ Adding debian-boot@, where “the d-i people” are, and debian-cd@ for > completeness. ] > >A few years ago we pushed for xz compression in some key packages to try >and squeeze more packages into installation images, notably CD#1; ISTR >that would only change the data part and not the control one, which >would limit the size gain for some specific packages. debian-cd only >generates netinst CDs nowadays so that's no longer a hot topic for us >AFAIK. Almost - after some pleas we've added back a CD-only build for Xfce too. But that's not massively relevant here I think. :-) >> Not all .deb parsers support control.tar.xz yet, but most do: >> <https://wiki.debian.org/Teams/Dpkg/DebSupport> > >udpkg's status there seems correct (supports gz/xz/no compression), and >just to be sure: I've just checked that compression_type is indeed >handled independently for control (in udpkg.c's dpkg_unpackcontrol) and >for data (dpkg_dounpack). > >> Would there be any objections to this? > >Bottom-line from a d-i point of view: having both compression in sync by >default shouldn't change anything on our side (shouldn't gain us much >but shouldn't do much harm either). Agreed. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane signature.asc Description: Digital signature
Re: Bug#771971: dpkg hangs installing "init" during upgrade from wheezy to jessie
On Fri, Jan 30, 2015 at 02:47:20AM +0100, Guillem Jover wrote: >Hi! > >On Sun, 2015-01-25 at 20:34:48 +0000, Steve McIntyre wrote: >> >> I still have my backup of the VM image at the time, so it should be >> possible to try upgrading it using snapshot.d.o from that time too, if >> it's likely to be useful. > >If it's not too cumbersome or might take too much of your time, it >would be useful, indeed, as the timing seems wrong, and I'd expect >a fixed dpkg to have been in place. So it would be nice to discard >any possible remaining problems that might still be lurking around. OK. I'll see what I can do... -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150131091440.ga8...@einval.com
Re: Bug#771971: dpkg hangs installing "init" during upgrade from wheezy to jessie
On Sun, Jan 25, 2015 at 09:11:57PM +0100, Guillem Jover wrote: >On Sun, 2015-01-25 at 14:18:03 +0100, Guillem Jover wrote: >> >> Adding -D7 to the dpkg call through apt's DPkg::options would be >> helpful. It would also be helpful to know which process hangs, and if >> it's dpkg itself an easy recipe to reproduce this? > >I just noticed this was a bug report from December, so I assume this >was possibly one of the dpkg bugs where it was busy looing (#766242 >or #766322), which is now fixed? Possibly, yes. >Although those fixes migrated to testing on 2014-11-03, so I'm not >sure. It would be nice to get more information of the environment at >the time. But if it does not happen anymore then it might indeed be >fixed already. :/ I still have my backup of the VM image at the time, so it should be possible to try upgrading it using snapshot.d.o from that time too, if it's likely to be useful. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150125203448.gh27...@einval.com
Re: Bug#771971: dpkg hangs installing "init" during upgrade from wheezy to jessie
Control: tags -1 -moreinfo On Sun, Jan 25, 2015 at 12:30:51PM +0100, Niels Thykier wrote: >Control: tags -1 moreinfo > >On Thu, 4 Dec 2014 00:56:48 +0000 Steve McIntyre wrote: >> This is reproducible on demand \o/ >> >> I realised that the VM image had a few unneeded packages, so I did >> >> # apt-get remove --purge x11-common libx11-6 libx11-data >> >> then >> >> # apt-get update >> # apt-get dist-upgrade >> >> and got the same result as my first run. >> >> On a *second* run I did not do that purge up-front and the upgrade did >> *not* block in the same way. > >Just to confirm, is this correctly understood? > > * If you purge "x11-common libx11-6 libx11-data" before upgrading, the > upgrade hangs. > * If you keep "x11-common libx11-6 libx11-data" as-is, the upgrade > succeeds. That *was* the case, yes. It seems that package changes in the archive since last month have changed things. Following the same process including the purge works correctly up until I get a failure to upgrade live-build due to bugs in that package. See the typescript of the upgrade (test-with-purge.gz). If I restore the VM image, start again and remove the live-tools package along with x11-common libx11-6 libx11-data, all works flawlessly in one step. >What state are the above packages before the upgrade? See attached dpkg-l.gz -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. test-with-purge.gz Description: Binary data dpkg-l.gz Description: Binary data
DPL teams review 2008
k all of your tasks in order of importance? f. Finally, are you having fun working on Debian? Why/why not? 2. Teams you're in -- (please answer this section multiple times where appropriate, once per team, but *excluding* teams for maintenance of individual packages) a. What teams do you work on? Are you an "official" member of those teams? b. How well do you think those teams are performing, in terms of getting things done? How are daily/regular tasks dealt with? And how about less common, one-off things? c. How do members of your teams communicate with each other about what they're working on? And how do they (as individuals or as a team) communicate with people outside of the team? Do you feel they coordinate well? d. Are there enough resources for your teams to do their jobs well? If not, what's missing? e. Anything else you'd like to mention? 3. Other teams -- a. What contact, if any, do you (as an individual) have with other teams? How well does that contact work? b. How well do your team(s) interact with other teams? c. If you have any issues in (a) or (b), how would you suggest to fix them? d. Any other observations about the various teams in Debian? === Other stuff === That's the list of things I'm hoping to learn more about from this review of teams. Of course, I'm sure there are many other things in Debian that you'd like to ask or tell me about. By all means, talk to me about them - I see it as part of my job to listen and do what I can to help. But please keep those separate from this survey - it'll help me to avoid my head exploding in all directions... :-) -- Steve McIntyre, Debian Project Leader <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: How are things going?
Guillem Jover wrote: >On Mon, 2006-09-25 at 23:33:48 +0100, Steve McIntyre wrote: > >> While I was in Tenerife last week, I met up with Esteban >> Manchado Velazquez and he told me about his ideas for a testing >> framework for dpkg. To me as a rank outsider, this sounds like a cool >> idea, but he was concerned that he hadn't had any responses to his >> mails. > >Yes it is, but right now it's a bit painful to do development on dpkg. >I don't really like to use experimental for something like it, even if >I've state in -devel that I've been thinking on branching it. I prefer >to do incremental changes, deploy them, get testing for few weeks, see >if something breaks, and upload again. Creating a big delta in >experimental make me feel unconfortable with something like dpkg. Yeah, I can understand that... :-) >Also l10n, documentation and similar are cheap to get in, that's why >I've not worried much about pushing that into sid. But any other kind >of changes needs RMs approval and thus takes their time by reviewing >the patches and the justifications, which I prefer to minimize if >possible. Yup, OK. >> So, I have a couple of questions: Who (if anybody) is working on dpkg >> at the moment? Is more help needed at the moment? > >Christian explained already what's the status right now, who is who >etc. About needed help, I suppose more help would not harm, but I >don't think right now is a good moment to evaluate this, I'd say after >the release we can check what the status is. Ok, that's fair enough. >thanks for the interest, *grin* I was just a little worried things had gone quiet; I've been watching the list for a while. But you all seem happy enough with where things are at the moment, and that's cool. I'd volunteer to help myself, but right now it would just be another project for me to feel guilty about not working on due to lack of time... :-( -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How are things going?
Christian Perrier wrote: > >When Scott decided to lower his involvment in March or April, he >handed the maintenance to a couple of DD's who, at some moment, >involved themselves in dpkg maintenance: > >-Frank Lichtenheld >-Guillem Jover >-Brendan O'Dea >-myself > >Speaking for myself, I was mostly handling the i18n/l10n part which >essentially consists in dealing with translation updates. Not a very >big part, indeed, and definitely no code maintenance. > >The team auto-organized itself, without much coordination (not a >criticism, mostly a fact). The most visible part of work has been done >by Guillem with a few achievments (which he probably can described >better than myself). >There has also been, IIRC, some exchanges with Ian Jackson. Probably >more could be done here. OK... Ian, do you have any comments/suggestions to make at this point? >In short, the manpower is more or less here but probably not enough >organized. We probably need someone to stand up, act as a team leader >and drive dpkg development. This is not vital now...but could become >vital after the release of etch. > >1 or 2 more contributors would certainly be welcomedafter we have >solved this leadership issue. > >There is probably a lot more to say, indeed but I wanted to give you my >own views after something like 2 years lurking on dpkg development. Great, thanks! -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How are things going?
Hi folks, How is dpkg development going atm? I know it's not necessarily a good indicator of activity, but I've not seen much happening on this list. While I was in Tenerife last week, I met up with Esteban Manchado Velazquez and he told me about his ideas for a testing framework for dpkg. To me as a rank outsider, this sounds like a cool idea, but he was concerned that he hadn't had any responses to his mails. So, I have a couple of questions: Who (if anybody) is working on dpkg at the moment? Is more help needed at the moment? Thanks, -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "This dress doesn't reverse." -- Alden Spiess signature.asc Description: Digital signature
Bug#130509: Patch for large file support in dpkg's md5sum
On Sun, Apr 07, 2002 at 08:51:45PM -0500, Adam Heath wrote: >tags 130509 + patch >thanks > >Please redo this patch against cvs HEAD, and do it for all of dpkg, >not just md5sum. > >There is no way this patch will ever be applied to the 1.9 branch. It's just >too late. and Wichert wrote: >This looks surprisingly like a patch I have on my laptop already :). >I'll see about getting somethign commited to CVS today that does this >properly. Guys, I'd like to help - do you want me to? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] http://www.einval.com/steve/>My home page "Can't keep my eyes from the circling sky, +-- "Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#130509: Patch for large file support in dpkg's md5sum
tags 130509 +patch
thanks
I've worked out the attached patch for large file support in md5sum as
supplied with dpkg, blatantly borrowed from the configure code in the
textutils package which has a working md5sum. This should also help
with LFS for the rest of dpkg - as a start, make sure that config.h is
#included in each source file before the system headers like stdio.h
and unistd.h:
sledge:/$ grep -irl __USE_LARGEFILE64 /usr/include
/usr/include/dirent.h
/usr/include/fcntl.h
/usr/include/features.h
/usr/include/ftw.h
/usr/include/sys/types.h
/usr/include/sys/statfs.h
/usr/include/sys/stat.h
/usr/include/sys/resource.h
/usr/include/sys/mman.h
/usr/include/sys/statvfs.h
/usr/include/bits/dirent.h
/usr/include/bits/confname.h
/usr/include/bits/stat.h
/usr/include/bits/statfs.h
/usr/include/bits/statvfs.h
/usr/include/bits/fcntl.h
/usr/include/bits/resource.h
/usr/include/stdio.h
/usr/include/stdlib.h
/usr/include/unistd.h
/usr/include/aio.h
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
http://www.einval.com/steve/>My home page
"Can't keep my eyes from the circling sky, +--
"Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key
diff -uNr dpkg-1.9.20/aclocal.m4 dpkg-1.9.20.steve/aclocal.m4
--- dpkg-1.9.20/aclocal.m4 Sun Mar 17 09:49:48 2002
+++ dpkg-1.9.20.steve/aclocal.m4Mon Apr 8 00:45:25 2002
@@ -663,3 +663,116 @@
fi
])
+dnl By default, many hosts won't let programs access large files;
+dnl one must use special compiler options to get large-file access to work.
+dnl For more details about this brain damage please see:
+dnl http://www.sas.com/standards/large.file/x_open.20Mar96.html
+
+dnl Written by Paul Eggert <[EMAIL PROTECTED]>.
+
+dnl Internal subroutine of AC_SYS_LARGEFILE.
+dnl AC_SYS_LARGEFILE_FLAGS(FLAGSNAME)
+AC_DEFUN(AC_SYS_LARGEFILE_FLAGS,
+ [AC_CACHE_CHECK([for $1 value to request large file support],
+ ac_cv_sys_largefile_$1,
+ [ac_cv_sys_largefile_$1=`($GETCONF LFS_$1) 2>/dev/null` || {
+ac_cv_sys_largefile_$1=no
+ifelse($1, CFLAGS,
+ [case "$host_os" in
+ # IRIX 6.2 and later require cc -n32.
+changequote(, )dnl
+ irix6.[2-9]* | irix6.1[0-9]* | irix[7-9].* | irix[1-9][0-9]*)
+changequote([, ])dnl
+ if test "$GCC" != yes; then
+ ac_cv_sys_largefile_CFLAGS=-n32
+ fi
+ ac_save_CC="$CC"
+ CC="$CC $ac_cv_sys_largefile_CFLAGS"
+ AC_TRY_LINK(, , , ac_cv_sys_largefile_CFLAGS=no)
+ CC="$ac_save_CC"
+ esac])
+ }])])
+
+dnl Internal subroutine of AC_SYS_LARGEFILE.
+dnl AC_SYS_LARGEFILE_SPACE_APPEND(VAR, VAL)
+AC_DEFUN(AC_SYS_LARGEFILE_SPACE_APPEND,
+ [case $2 in
+ no) ;;
+ ?*)
+ case "[$]$1" in
+ '') $1=$2 ;;
+ *) $1=[$]$1' '$2 ;;
+ esac ;;
+ esac])
+
+dnl Internal subroutine of AC_SYS_LARGEFILE.
+dnl AC_SYS_LARGEFILE_MACRO_VALUE(C-MACRO, CACHE-VAR, COMMENT,
CODE-TO-SET-DEFAULT)
+AC_DEFUN(AC_SYS_LARGEFILE_MACRO_VALUE,
+ [AC_CACHE_CHECK([for $1], $2,
+ [$2=no
+changequote(, )dnl
+ $4
+ for ac_flag in $ac_cv_sys_largefile_CFLAGS no; do
+case "$ac_flag" in
+-D$1)
+ $2=1 ;;
+-D$1=*)
+ $2=`expr " $ac_flag" : '[^=]*=\(.*\)'` ;;
+esac
+ done
+changequote([, ])dnl
+ ])
+ if test "[$]$2" != no; then
+ AC_DEFINE_UNQUOTED([$1], [$]$2, [$3])
+ fi])
+
+AC_DEFUN(AC_SYS_LARGEFILE,
+ [AC_REQUIRE([AC_CANONICAL_HOST])
+ AC_ARG_ENABLE(largefile,
+ [ --disable-largefile omit support for large files])
+ if test "$enable_largefile" != no; then
+ AC_CHECK_TOOL(GETCONF, getconf)
+ AC_SYS_LARGEFILE_FLAGS(CFLAGS)
+ AC_SYS_LARGEFILE_FLAGS(LDFLAGS)
+ AC_SYS_LARGEFILE_FLAGS(LIBS)
+
+ for ac_flag in $ac_cv_sys_largefile_CFLAGS no; do
+ case "$ac_flag" in
+ no) ;;
+ -D_FILE_OFFSET_BITS=*) ;;
+ -D_LARGEFILE_SOURCE | -D_LARGEFILE_SOURCE=*) ;;
+ -D_LARGE_FILES | -D_LARGE_FILES=*) ;;
+ -D?* | -I?*)
+ AC_SYS_LARGEFILE_SPACE_APPEND(CPPFLAGS, "$ac_flag") ;;
+ *)
+ AC_SYS_LARGEFILE_SPACE_APPEND(CFLAGS, "$ac_flag") ;;
+ esac
+ done
+ AC_SYS_LARGEFILE_SPACE_APPEND(LDFLAGS, "$ac_cv_sys_largefile_LDFLAGS")
+ AC_SYS_LARGEFILE_SPACE_APPEND(LIBS, "$ac_cv_sys_largefile_LIBS")
+ AC_SYS_LARGEFILE_MACRO_VALUE(_FILE_OFFSET_BITS,
+ ac_cv_sys_file_offset_bits,
+ [Number of bits in a file offset, on hosts where this is settable.]
+ [case "$host_os" in
+# HP-UX 10.20 and later
+hpux10.[2-9][0-9]* | hpux1[1-9]* | hpux[2-9][0-9]*)
+ ac_cv_sys_file_offset_bits=64 ;;
+esac])
+ AC_SYS_LAR
Bug#25173: More helpful dselect interface
Package: dpkg Version: 1.4.0.23.2 Severity: wishlist I did a new install of hamm at the weekend for/with a newbie. One thing that would make dselect easier to use with CDs is some help as to what the name of the CD device is, similar to the choices given on the boot floppies. -- Steve McIntyre, Allstor Software [EMAIL PROTECTED] Also available from [EMAIL PROTECTED] "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
