Re: xforms0.86 package insanity
Ben == Ben Gertzfield [EMAIL PROTECTED] writes: Ben Should I distribute the binary-only .tar.gz as the Ben .orig.tar.gz, and make the diff as usual? *grin* Also, shouldn't the package be named 'libforms0.88'? I can also release a 'libforms0.86' that replaces, provides, and conflicts with xforms0.86. -- Brought to you by the letters V and W and the number 19. Hello! We are only joke. It is funny enough. -- Orz, SCII Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xforms0.86 package insanity
Ben Gertzfield wrote: Well, I guess I'll do so, since nobody else is stepping forward to do it. Should I distribute the binary-only .tar.gz as the .orig.tar.gz, and make the diff as usual? Hmm... xforms0.86 is .deb only. I think having a source package would be preferable, yes. It will make future releases much easier. Perhaps you can ask Heiko Schlittermann for the source he used to create the xforms0.86 .deb? That would save you some work. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: tecra patch?
Hi Bruce! Who maintains the tecra patch, and where can I find it? I don't know if there is a Debian maintainer for the patch, but I always get it from Jens Maurer's Linux on the Toshiba Tecra series page at http://www.cck.uni-kl.de/misc/tecra710/ The file is at http://www.cck.uni-kl.de/misc/tecra710/toshiba-small.diff Shouldn't all the patches to kernels that Debian distributes be included in some source package? There should be a note mentioning their purpose so that, for instance, someone rolling their own kernel for a Tecra (perhaps to get APM) will have the Tecra patch at hand and know to apply it. Kirk Hilliard (sending from my Dad's account since ghoti.com is temporarily down) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-28
On Sun, Dec 28, 1997 at 03:47:22PM +0100, Richard Braakman wrote: Philippe Troin [EMAIL PROTECTED]: perlmagick-1.15-2 imagemagick-3.9.0-1 libhdf4g-dev-4.0.2-4 (Depends on libhdf4) It's a strange dependency, but libhdf4 actually depends on libhdf4g rather than just requiring a particular version, too. Oh well. I remember Philippe said he was taking a break, is anyone looking at these packages? The only thing that turns me off looking at imagemagick is the huge number of libraries it uses. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-28
On Sat, 3 Jan 1998, Hamish Moffatt wrote: On Sun, Dec 28, 1997 at 03:47:22PM +0100, Richard Braakman wrote: Philippe Troin [EMAIL PROTECTED]: perlmagick-1.15-2 imagemagick-3.9.0-1 libhdf4g-dev-4.0.2-4 (Depends on libhdf4) It's a strange dependency, but libhdf4 actually depends on libhdf4g rather than just requiring a particular version, too. Oh well. I remember Philippe said he was taking a break, is anyone looking at these packages? The only thing that turns me off looking at imagemagick is the huge number of libraries it uses. I've got an updated imagemagick/perlmagick package set compiled, however it just replaces the existing libraries without attempting to provide libc5-based libraries. Does anything other than imagemagick and perlmagick need libmagick anyway? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 pine ?
Hello, I was just informed (thanks, Che ;)) that there is a newer pine source-only package in non-free... does it compile and work with libc6 ? I remember that a couple of months ago there were some problems with libc6 pine, I dont know if it was corrected yet... the changelog is not informative enough... It would be so nice to remove libc5 from one of my machines... and pine is the only obstacle (no, i cannot tell 30 people to switch to mutt :)) Greg Ps. please CC me when replying -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Missing libpthread0_7-1.deb?
Hello, I hope that this is the right list to post this to. I have been trying to install the latest libc6 and libc6-dev packages (2.0.6-2 I believe) and have to this point been unsuccessful. The libc6 package depends on libpthreads0.7-1. The latest version on ftp.debian.org (and on my machine) is 0.6-1. Anybody have any ideas on where the package might be found? I had posted a message concerning this matter to debian-user about three nights ago and as of yet, no response. I also posted a message to the package maintainer 2 days ago. Again, no response. Thanks, Steve Mayer [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
debhelper design change - RFC (long)
Ben Gertzfield has convinced me that debhelper's special treatment of the first package listed in debian/control isn't a good thing. I'm thinking about redesigning debhelper to act in a more consitent fasion. Of course, backwards compatability is very important. (Especially since people enjoy cutting on debhelper and debstd for backwards compatability issues. I really don't want to give you guys more ammo. ;-) First, some background - each debhelper program can take parameters on the command line, as well as from a file in debian/. For example, dh_installdocs can be passed the filenames of documentation to install into usr/doc/package, and it also reads debian/package.docs for more filenames. If debhelper is working on building more than 1 binary package, then it treats the first binary package listed in debian/control specially. For this package and this package only, it uses the command line parameters. For all the other packages in debian/control, you must use the debian/package.docs files. (If I've lost you already, go take a look at the debhelper man pages and docs. I'm concerned about changing this behavior exactly because it is so confusing.) This can lead to confusing situations. Suppose the control file has 2 packages, foo is first, and bar second. If the maintainer tries something like: dh_installdocs -pbar README BUGS Then dh_installdocs is only acting on package bar. However, since bar is not the first package listed in debian/control, the 2 filenames specified are ignored. This is confusing. I've come up with a variety of different solutions, and am trying to chose between them: 1. Add a -f flag, that makes debhelper programs apply the command line arguments to all packages it's acting on. With this switch, you could use: dh_installdocs -f -pbar README BUGS And README and BUGS would be installed into usr/doc/bar/ Of course, you could also say this: dh_installdocs -f README BUGS And README and BUGS would be installed into both packages (since debhelper acts on both by default). Backwards - compatability problems: none, since the -f flag is a new flag. 2. Add a -f flag, like above, but it only makes the command line arguments apply to the first package you ask debhelper to act on. Then you could use the same command line as above, with identical effects, as well as things like: dh_installdocs -f -pbar -pfoo README BUGS This would make README and BUGS be installed into package bar only. Backwards - compatability problems: none, since the -f flag is a new flag. 3. Don't bother with the -f flag, make debhelper _always_ apply the command line arguments to the first package you ask it to act on. So, you could use: dh_installdocs -pbar README BUGS And README and BUGS would be installed into usr/doc/bar/ If you ran: dh_installdocs -pbar -pfoo README BUGS This would make README and BUGS be installed into package bar only, since it's listed first. And if you ran: dh_installdocs README BUGS README and BUGS would be installed into package foo only (since it's the first package in debian/control, just as happens today with the current debhelper.) Backwards - compatability problems: If someone accidentialy has the following type of command in their debian/rules today, debhelper's behaviour would change: dh_installdocs -pbar README BUGS With current debhelper, this is a no-op. If I implement option #3, then this installs README and BUGS into package bar. Let me stress that this is only a problem that will only happen if someone didn't understand how debhelper worked in the first place. Debhelper will do something different, but it probably wasn't doing what they wanted it to do before, either, since they didn't understand why it was acting as it did. I far prefer #3, I feel it's the cleanest way to go (it will simplify the man pages a lot), but its backwards compatability problems worry me. If people think #3 is too radical, I can easily fall back to #2, but it's not as clean. #1 doesn't appeal. Comments? -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
Joey == Joey Hess [EMAIL PROTECTED] writes: *excellent explanation of what can happen snipped* Joey I far prefer #3, I feel it's the cleanest way to go (it will Joey simplify the man pages a lot), but its backwards Joey compatability problems worry me. If people think #3 is too Joey radical, I can easily fall back to #2, but it's not as Joey clean. #1 doesn't appeal. Comments? I agree, and would prefer #3 -- but is there anything but dh_installdirs that needs to be changed if we do it that way? -- Brought to you by the letters B and Q and the number 0. Mmm.. Soylent Green.. -- Homer Simpson Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
Ben Gertzfield wrote: I agree, and would prefer #3 -- but is there anything but dh_installdirs that needs to be changed if we do it that way? Yes. This change would effect at least: dh_installdirs, dh_installdocs, dh_installchangelogs, dh_installexamples, dh_undocumented, dh_installmanpages, and dh_suidregister. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Ben Gertzfield wrote: Ben I agree, and would prefer #3 -- but is there anything but Ben dh_installdirs that needs to be changed if we do it that way? Joey Yes. This change would effect at least: Joey dh_installdirs, dh_installdocs, dh_installchangelogs, Joey dh_installexamples, dh_undocumented, dh_installmanpages, and Joey dh_suidregister. Okay. Is there any way we can possibly detect and issue a warning if someone tries the old behavior (when would this happen) if we go with #3, also? -- Brought to you by the letters Q and U and the number 14. It is sad. *Campers* cannot *dance*. Not even a *party*. -- Orz, SCII Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
Ben Gertzfield wrote: Okay. Is there any way we can possibly detect and issue a warning if someone tries the old behavior (when would this happen) if we go with #3, also? I thought about that. I can test to see if parameters are specified and the package being acted on is not the first binary package in debian/control and print a big fat warning message. But, that is: * Likely to be missed by a harried debian developer who made this mistake in the first place. * Ugly to see 30 times when you're building your package. :-) Still, better than nothing if I do go with #3.. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 pine ?
On Sat, 3 Jan 1998, Gergely Madarasz wrote: Hi I was just informed (thanks, Che ;)) that there is a newer pine source-only package in non-free... does it compile and work with libc6 ? I remember that a couple of months ago there were some problems with libc6 pine, I dont know if it was corrected yet... the changelog is not informative enough... No, unfortunately its rather broken. Im using the libc5 bo pine on my system. Works ok, just doenst have some of the newer features of the Pine (source) package in hamm/non-free. It would be so nice to remove libc5 from one of my machines... and pine is the only obstacle (no, i cannot tell 30 people to switch to mutt :)) Heh.. you could try :), although I don't like Mutt myself, so I went back to libc5 Pine. Regards, Dave +-+ | Dave Cook Perth, Western Australia | | Internet: [EMAIL PROTECTED] | | on IRC as Cevad | +-+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 is missing swab
When trying to compile nfsroot for libc6, I got a implicit declaration of swab(...). I fixed it by copying the declaration out of unistd.h. Then, during linking, I got an undefined reference to swap(...). I ran objdump on libc.a, and found swap.o, but it only had a text section, and no code! Strsep, right above it, had text and code associated with it. Needless to say, I did get nfsroot to compile. I copied the function from libc5 into nrprobenet.cc, and it compiles and runs fine. But why doesn't libc6 contain this standard function? I wish I had a life outside Quake. Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort. Email http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with http://wwp.mirabilis.com/3375265 - Page Me the word subscribe in the body. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 is missing swab
| On Saturday, 3 January 98, at 4:12:27 AM | Adam wrote about libc6 is missing swab When trying to compile nfsroot for libc6, I got a implicit declaration of swab(...). I fixed it by copying the declaration out of unistd.h. Then, during linking, I got an undefined reference to swap(...). I ran objdump on libc.a, and found swap.o, but it only had a text section, and no code! Strsep, right above it, had text and code associated with it. Needless to say, I did get nfsroot to compile. I copied the function from libc5 into nrprobenet.cc, and it compiles and runs fine. But why doesn't libc6 contain this standard function? Sorry. These should all say swab Why do keyboards get replaced? Because people run Windows, and they can't hit Bill! Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort. Email http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with http://wwp.mirabilis.com/3375265 - Page Me the word subscribe in the body. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Checklist request
Hello everyone, -- BACKGROUND AND CURRENT STATUS: -- Ok, I'm finally ready to start doing this. For those that are reading this for the first time, the checklist will be used by the testers to verify a package is working correctly. Scripts welcome (I finally gave in) in /usr/doc/pkgname/testme.sh . Non-maintainers can send scripts to me (cc the maintainer), and I'll put them on the web page when it's put together. The Debian Testing Group encouraged to modify any scripts and save them for package testing in the future. When submitting a list, please try to include things any user can do, e.g. don't require the package source or an external program that is difficult to obtain. My personal intention is to make a testing directory containing a sub-directory for each package, and use a shell script with diff to run and verify the testing scripts in each directory. Hopefully this just means a huge one time setup cost for me. Here's the list after my first small request: - EXAMPLES: - Package: diff - cmp works on identical and different binary or text files - diff works on files, directories, normal or 2 column - sdiff correctly merges two files - diff3 correctly compares 3 files Package: grep - Maintainer uses khadaffy test-set. - Try a bunch of greps using different search patterns - Also try -v switch. Package: gzip - These will be tested by dpkg itself - verify compression works - verify uncompression works Package: tar - These will be tested by dpkg itself - create a compressed tarball and verify contents - YOUR MISSION: - What I'm asking for new is checklist for any package in main, however, try to focus on required or at least standard packages in the beginning. I'm also opening this up to non-maintainer submissions, but cc the maintainer if you do this. Additions to the current list are welcome. As these come in, I'll post a change log to the testing and devel list, and point interested readers to the online location (which isn't quite ready yet). Please use the above subject line and send them directly to me so we don't accidentally flood the mailing list (and cc the maintainer if appropriate). Thanks to all the supporters, this is going to be a big job, and I'll need all the help I can get. Happy New Year! Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Not i386 Debian
What about Digital Alpha and Sun Sparc debian version? Marco. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
It should be possible to construct a regexp that detects these usage patterns. Then you could grep through the .diff.gz files on the archive to see if they are used anywhere, and file individual bugreports. With a few exceptions, the diffs are not very large -- you won't be grepping through 500 MB :-) This way you'll miss the native packages. Is there a list of those? Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I am having trouble downloading
The base system has installed smoothly however the packages are proving cumbersome, is there a distributer of Debian on CD in Sydney Austrlaia I could not find a reference to one on the website thanks in advance Suthagar -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[6]: My own libc6 progress, and package adoption drive. Give me an account on master!
On Fri, Jan 02, 1998 at 03:14:31PM -0500, Adam Heath wrote: No, the new package should be named similar to the upstream source but the control file should contain these lines: Conflicts: mdutils Replaces: mdutils Provides: mdutils But what if they currently have mdutils selected, and they don't notice that a new package called raidtools is there? I want the package raidtools to be automatically installed if mdutils is installed. How about this? Package: mdutils Pre-depends: raidtools Package: raidtools Conflicts: mdutils Replaces: mdutils Provides: mdutils This way, as I see it, raidtools will have to be installed before mdutils, and when raidtools is installed, it will deselect mdutils. Any problems with this? As I understand this won't work. mdutils and raidtools contain the same binaries (ok, a different version though). Therefore mdutils will be removed from the archive in favour of raidtools. Another point is that Pre-depends are not supposed for this stuff. It's supposed to help installing packages that need other packages fully working, even at its pre installation scripts. 2B OR NOT 2B=FF Errr... Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / pgpE473ge4VgS.pgp Description: PGP signature
Re: Not i386 Debian
On Sat, Jan 03, 1998 at 12:42:36PM +0100, Marco Bellini wrote: What about Digital Alpha and Sun Sparc debian version? Both ports exist but are not quite complete. They are usable though. There are two mailing lists debian-sparc and debian-alpha@lists.debian.org where you should get further information. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / pgpoPDquvIo1t.pgp Description: PGP signature
Re: dhelp 0.2 - a online help system
On Thu, 1 Jan 1998 [EMAIL PROTECTED] wrote: Today I've released the latest version of my HTML online help system for Debian. Bugs reports are welcome :). I like it but... 1) How about dwww? (Yes, I know dwww needs a web server...) 2) I really dont like to have 2/3/... methods of building indexes of documentation installed in the debian system. What about integrating all that stuff? (menu, dwww, dhelp, etc...) 3) The policy says the preferred doc format is HTML (fine) but it says nothing about how to access it. Any ideas before we poor developer have to write a dozen of different conf files to support all that new help systems? (menu entries, .dwww-index, .dhelp, etc...) We are aware of this problem. The different menu systems (menu, dwww, dhelp, etc.) all have their advantages and disadvantages so I guess they will all stay around for a while. The solution is to provide a unique interface where all packages can register their documentation files. This interface programm will than support the different menu systems, depending on which are installed. This way, the local sysadmin can choose whether he/she prefers dhelp, dwww, or both, etc. I'm currently working on a draft for this interface. It looks like we're going to implement that together with a new Documentation Policy for Debian 2.1. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
On Fri, 2 Jan 1998, Chris Fearnley wrote: '[EMAIL PROTECTED] wrote:' Actually, I'm not sure there is a problem with libc5-altdev. There definitely is a dependency clash between libc5 and libc6, which David Engel thinks we should patch by producing an upgrade for libc5. This will have to be installed before hamm. It's not yet clear to me that we can make this automatic with pre-depends or not. I don't think we should make it automatic. But it should be documented in the libc5 - libc6 transition FAQ. If it is possible, we should make it automatic, since most users don't read any documentation before trying it first. And try and error really fails here... If an automatic upgrade should not be possible at all (that's not what I believe), then we should at least find a way to make dselect _stop_ the upgrade process before the system gets damaged. AFAIK, the only real problem during a bo-hamm upgrade is that if you install several packages at once, they will be unpacked but not configured immediately afterwards. This results into segfaults when libs get moved from /usr/lib to /usr/lib/libc5-compat . A possible solution has been discussed some time ago: We should implement a Immediate-Configure: Yes control field, which causes dpkg to configure the package _right after_ unpacking it. This new field would also solve upgrade problems in the case of watchdog for example. (The old watchdog gets deleted, new unpacked, but it's configured after all other packages are unpackaged too. If a lot of packages are unpacked, this takes too long so the system reboots :-) It would be good to hear a few comments regarding the Immediate-Configure solution. (Other solutions are welcomed too, of course!) Cheers, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
Christian Schwarz wrote: [Immediate-Configure: Yes field] If I recall correctly, there were two reasons for delaying the configuration step until all packages had been unpacked: 1.- Packages are more likely to have their dependencies satisfied if all of the packages being installed have been unpacked. 2.- Some configurations are interactive, and it is annoying to have to stay at the console while the packages are being unpacked. An Immediate-Configure field is not going to help with 1. The way to solve that is to unpack the packages in the right order. That might be too much to attempt just before the hamm release, but I think it would be the best solution if it is possible. An Immediate-Configure field will help with 2, but I think there is a better solution. If there is a way to specify that a package's postinst is _not interactive_, then dpkg can attempt to configure those packages right away; there is no reason not to try. (If dependencies are not satisfied, it can try again after all packages have been unpacked.) Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 pine ?
On Sat, 3 Jan 1998, Gergely Madarasz wrote: It would be so nice to remove libc5 from one of my machines... and pine is the only obstacle (no, i cannot tell 30 people to switch to mutt :)) You don't have to... Tell'em to use emacs... :) Just kidding, I'm using pine on a libc6 machine, and I _think_ it's libc6... --- Turbo_ /// If there are no Amigas in heaven, send me to HELL! ^\\\/ Unix _IS_ user friendly - it's just selective about who its friends are ! Turbo Fredriksson Tel: +46-704-697645 S-415 10 Göteborg[EMAIL PROTECTED] SWEDEN www5.tripnet.se/~turbo My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html' Key fingerprint = B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 pine ?
On Sat, 3 Jan 1998, Turbo Fredriksson wrote: You don't have to... Tell'em to use emacs... :) Just kidding, I'm using pine on a libc6 machine, and I _think_ it's libc6... Just double checked... I'm using a libc5 pine to... sorry... Emacs is still greate... :) --- Turbo_ /// If there are no Amigas in heaven, send me to HELL! ^\\\/ Unix _IS_ user friendly - it's just selective about who its friends are ! Turbo Fredriksson Tel: +46-704-697645 S-415 10 Göteborg[EMAIL PROTECTED] SWEDEN www5.tripnet.se/~turbo My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html' Key fingerprint = B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 pine ?
-BEGIN PGP SIGNED MESSAGE- Gergely Madarasz wrote: I was just informed (thanks, Che ;)) that there is a newer pine source-only package in non-free... does it compile and work with libc6 ? It compiles, but it does not work (it does, but not in a multi-user environment, so installing it in a 30-user machine is highly discouraged). If somebody here wants to take it and fix the huge bugs it has, go ahead. Or else: If you want to fix it but do not want to maintain it, send me the patches and they will be included in the next release with appropriate credits in changelog.Debian. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNK5yHyqK7IlOjMLFAQFFBAP9EIlMm8ZLUeNzuaflNOCEz3GjwDWxMyXd v7QngBngXcN4MS8Od0iJsuZyZNfbxJwiw6080utuUIcYVX6f+8gJVpOWo8bsmlfp 5KdzfY+8ia3jNX5rMuLstr2tPWZxQuntaJOlr/SYdDJ0BLnJxZj4PWttGMLr7ZHy QE0ga1QvFsA= =YDAq -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
'Christian Schwarz wrote:' On Fri, 2 Jan 1998, Chris Fearnley wrote: '[EMAIL PROTECTED] wrote:' Actually, I'm not sure there is a problem with libc5-altdev. There definitely is a dependency clash between libc5 and libc6, which David Engel thinks we should patch by producing an upgrade for libc5. This will have to be installed before hamm. It's not yet clear to me that we can make this automatic with pre-depends or not. I don't think we should make it automatic. But it should be documented in the libc5 - libc6 transition FAQ. If it is possible, we should make it automatic, since most users don't read any documentation before trying it first. And try and error really fails here... In general, you would be correct. But pre-depends (or even depends) in libc6 on libc5 (which would be required to make it automatic) would force everyone who intalls hamm to also install libc5 in perpetuity. Which IMHO is equally bad. So I suggest the tradeoff: document the transition for those who want libc5 development support. But don't require it. Unless someone sees a clean solution? -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naive -- Bucky Fuller -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xforms0.86 package insanity
Ben Gertzfield [EMAIL PROTECTED] writes: Scott == Scott Hanson [EMAIL PROTECTED] writes: Scott As soon as someone packages xforms0.88, I'll rebuild both Scott xmysql and xmysqladmin with it... Well, I guess I'll do so, since nobody else is stepping forward to do it. Talk about quick service... I found the packages in Incoming this morning :) I've just uploaded revised packages of xmysql and xmysqladmin linked to the new libforms0.88. Scott -- Scott Hanson [EMAIL PROTECTED] [EMAIL PROTECTED] Johmsweg 9a, D-21266 Jesteburg, Germany -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Missing libpthread0_7-1.deb?
On Fri, Jan 02, 1998 at 11:04:51PM -0700, Steve Mayer wrote: I have been trying to install the latest libc6 and libc6-dev packages (2.0.6-2 I believe) and have to this point been unsuccessful. The libc6 package depends on libpthreads0.7-1. The latest version on ftp.debian.org (and on my machine) is 0.6-1. Anybody have any ideas on where the package might be found? Look at the control info for libc6 again. libc6 CONFLICTS with libpthread0 version less than 0.7-10! This is so the, currently non-existent, libpthread0 maintainer can update the package to not conflict with libc6. To install libc6, you must uninstall the current libpthread0. FYI, libc6 conflicts with libpthread0 because they both provide libraries with an soname of libpthread.so.0. The libpthread0 package (for libc5) must be reworked to move its library to /usr/lib/libc5-compat. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 is missing swab
well, swab() isn't a standard function, for one thing. It's a rarely used old-BSD bit, that people occasionally use anyway. Putting the code directly inline is probably all you can do... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Removing directories in postrm ?
A few of python's postinst scripts byte-compile the source files they install. The byte-compiled files are to be removed by the postrm scripts (a script removes all byte-compiled files where sources can't be found). Now if the python package had created a new directory, this directory is not empty until after postrm and won't be removed therefore. Should I keep this procedure and perhaps try to remove the directory in postrm with something like (rmdir /usr/lib/python1.5/lib-tk 2/dev/null || true) ? The user still will get a warning about the non-empty directory. Should I come up with a solution that tries to remove the byte-compiled files in the prerm ? (I had to keep track of the files that were created in postinst). Or should I include the byte-compiled files in the packages ? Gregor --- |Gregor Hoffleit Mathematisches Institut, Uni HD| | [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 | | We will make windows invisible | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 27 Dec 1997, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: On 17 Dec 1997, James Troup wrote: [snip] If the binary changes, the version number should change. Completely agreed. Everything else will only result in a big mess. I'll check our how I can make policy more clearly on this point and include something in the next policy weekly posting. Of course, are you talking about the binary program, or the binary .deb? The binary program in question *did not change*, because its compilation and linkage environment's (effectively) did not. The *only* think that changed here was the dependency in the .deb. Just a twist to consider. By changing the dependencies you changed the source package before, or? With that, you'll have to use a new version number anyways. Anyway, I guess I didn't mean to start a big debate---I was pretty much convinced after Sven first mailed me that I probably ought to have bumped the version number. I just thought the policy should also be more explicit. Agreed. (That's why we should continue the discussion until we have a consensus.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking shared libraries with -lc
On Fri, 2 Jan 1998, Richard Braakman wrote: I made a list of packages that include shared libraries for which ldd says statically linked. I plan to use this list to automatically generate bug reports (about 50). However, I am unsure of the text to use. This is my first try: [snip] First of all, thanks for collecting all the infos! Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. Everything else is likely to result into big flame wars. (Maintainers usually don't like to see bugs reported against their packages unless you refer to the policy manual :-) Anyways, the bug report should probably not contain that much information. The info should go into the policy manual. Then, you just have to refer to section x.x in the bug report. So, if you like, I'd appreciate it if you could come up with a suggestion for the policy text. (If not, then I'll do it when I have time for this.) Thanks in advance, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking shared libraries with -lc
On Sat, Jan 03, 1998 at 07:09:38PM +0100, Christian Schwarz wrote: On Fri, 2 Jan 1998, Richard Braakman wrote: [-lc issue] Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. IMHO, the link issue itself does not need more discussion; the issue itself has been known for a long time, and nobody has expressed any objections that I can recall. As such, I don't think Richard should wait with filing the bugreports; perhaps he can just put in a details will soon be available in an upgraded policy document. Perhaps the phrasing of this needs discussion, but not the implementation. Don't get me wrong: in general, I'm very much in favour of discussing things before putting them into policy; just in this case, I think that there is already a concensus, and waiting for it to go into policy officially before submitting bugreports just delays implementation. Everything else is likely to result into big flame wars. (Maintainers usually don't like to see bugs reported against their packages unless you refer to the policy manual :-) Hmmm... I've never felt this way; I do feel free to ignore bugs that I don't consider bugs and that don't have to do with policy. Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: By changing the dependencies you changed the source package before, or? Technically, no. The dependencies are build by dpkg-shlibdeps, so for all intents and purposes, the *only* difference between the old package and the new was the things totally external to the package and sources that were installed at the time. Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Intent to package mrtg nntpcache...
I am going to be installing both of these on a Debian system, so it behooves me to package them, assuming no one is already in the process of doing so. Unfortunately, nntpcache must go in non-free, but it is worlds more capable than leafnode, and I must have the features. If I've missed something, someone please let me know. Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package mrtg nntpcache...
Michael Alan Dorman [EMAIL PROTECTED] writes: If I've missed something, someone please let me know. from hamm/contrib/Packages: Package: mrtg Version: 2.5.1-1 Priority: extra Section: contrib/net Maintainer: Joey Hess [EMAIL PROTECTED] Depends: libc6, libgd1g, perl (= 5.003) Recommends: httpd Architecture: i386 Filename: dists/unstable/contrib/binary-i386/net/mrtg_2.5.1-1.deb Size: 182634 MD5sum: 58862a90f6ea3c18c02531317a894f04 Description: Multi Router Traffic Grapher The Multi Router Traffic Grapher is a tool to monitor the traffic load on network links using SNMP. MRTG generates HTML pages containing GIF images which provide a LIVE visual representation of this traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs. installed-size: 418 -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking shared libraries with -lc
Christian Schwarz wrote: Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. Oh. Er. I just sent them out. I think your mail arrived while I was sending them :) I didn't expect this to be a matter of determining policy; I thought that because it was listed in the Upcoming Releases file, it had been decided on before I joined. That's why I didn't wait very long for comments. (I'm impatient because I have a lot of free time this week, and I'll be much more busy next week. I want to get Debian stuff done :-) So, if you like, I'd appreciate it if you could come up with a suggestion for the policy text. (If not, then I'll do it when I have time for this.) I don't think I have the expertise for that. Ray Dassen's version contains many remarks that I can't explain. I just know that it's useful to have the linker warn if you try to link a libc5 library with a libc6 one, especially now that we're building a libc6 release. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package mrtg nntpcache...
In article [EMAIL PROTECTED], Michael Alan Dorman [EMAIL PROTECTED] wrote: I am going to be installing both of these on a Debian system, so it behooves me to package them, assuming no one is already in the process of doing so. Unfortunately, nntpcache must go in non-free, but it is worlds more capable than leafnode, and I must have the features. Did you look at newscache, http://www.infosys.tuwien.ac.at/NewsCache/ It's supposed to do the same as nntpcache, but it's GPL'ed Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed [EMAIL PROTECTED] | awake all night wondering if there is a doG -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debhelper design change - RFC (long)
Richard Braakman wrote:
It should be possible to construct a regexp that detects these usage
patterns. Then you could grep through the .diff.gz files on the
archive to see if they are used anywhere, and file individual
bugreports. With a few exceptions, the diffs are not very large --
you won't be grepping through 500 MB :-)
Here's my try at doing that:
[EMAIL PROTECTED]:~irc/mirror/debian/main/sourcefind |grep diff.gz | xargs
zcat |
perl -ne 'chomp ;if (/dh_.*\s+(.*?)(-p.*|-i|-a)(.*?)/ ($1 || $2)) {
$args=$1 $2; $args=~tr/\s/\s/s; foreach $word (split(/\s/,$args)) { if
(! $word=~m/^-/) { print $_: $word\n } } }'
It comes up empty, no matches. (I checked non-free and contib and non-us
too). I don't think it's a bug in my command line, though others are
welcome to try alternate ways.
This way you'll miss the native packages. Is there a list of those?
Just grep for .tar.gz files that are not .orig.tar.gz files:
[EMAIL PROTECTED]:~irc/mirror/debian/main/sourcefind |grep .tar.gz | grep -v
.orig.
|xargs -n 1 tar xzOf | perl -ne 'chomp ;if (/dh_.*\s+(.*?)(-p.*|-i|-a)(.*?)/
($1 || $2)) { $args=$1 $2; $args=~tr/\s/\s/s; foreach $word
(split(/\s/,$args)) { if (! $word=~m/^-/) { print $_: $word\n } } }'
This also comes up empty.
--
see shy jo
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
What's going on with gpc?
[EMAIL PROTECTED] (Richard Davies) wrote on 07.12.97 in [EMAIL PROTECTED]: This is a request for some feedback from current and potential users of GPC. I have GPC 2.0 compiled for hamm, built using GCC 2.7.2.3. The next version of GPC (currently 971001) is in beta, but is already more stable than GPC 2.0. There seems to be a few possibilities available. I could package GPC 2.0, GPC 971001 beta, both versions, or wait until GPC 971001 beta is released as GPC 2.1. Let me know your preferences, if any, within the next few of days and I will then decide which course of action to take. The archive has 2.0-3 in both bo and project/orphaned (well, the latter is source-only), from 1996, from Christoph Lameter. And WNPP claims that Christoph orphaned them, and Paul J. Thompson took it. Is anybody working on it? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package mrtg nntpcache...
James Troup [EMAIL PROTECTED] writes: Michael Alan Dorman [EMAIL PROTECTED] writes: If I've missed something, someone please let me know. from hamm/contrib/Packages: Thanks, James, I guess I must have looked at the available list on my alpha, not for i386... Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package mrtg nntpcache...
[EMAIL PROTECTED] (Miquel van Smoorenburg) writes: Did you look at newscache, http://www.infosys.tuwien.ac.at/NewsCache/ I have now. It's supposed to do the same as nntpcache, but it's GPL'ed It does seem to do the things I wanted from nntpcache (primarily the ability to proxy from multiple servers while presenting a unified list of newsgroups), so I may well do this instead of nntpcache. I don't suppose anyone has packaged it yet? :-) Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Removing directories in postrm ?
A few of python's postinst scripts byte-compile the source files they install. The byte-compiled files are to be removed by the postrm scripts (a script removes all byte-compiled files where sources can't be found). Now if the python package had created a new directory, this directory is not empty until after postrm and won't be removed therefore. Should I keep this procedure and perhaps try to remove the directory in postrm with something like (rmdir /usr/lib/python1.5/lib-tk 2/dev/null || true) ? The user still will get a warning about the non-empty directory. Should I come up with a solution that tries to remove the byte-compiled files in the prerm ? (I had to keep track of the files that were created in postinst). Or should I include the byte-compiled files in the packages ? If that directory contains files generted in package's postinst, I think you should also create that directory there, and remove it in postrm. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
Originally on debian-announce, but it seems development related... Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Before 2036 we must define time_t, to be a 64-bit variable instead of a 32-bit one, and recompile all programs. This is a very simple process compared to the anguish the non-Unix world is going through - we go through more work to produce a major release of Debian. Once time_t is a 64 bit variable, it's good for another 4000 years. Don't you think you're overstating this just a bit? What about programs that store time_t's in ints? Or write them out to some kind of storage? What about compatibility with other software (netscape or staroffice, for example) that you can't recompile? (Yes, I know they're not part of the distribution, but it's unrealistic to ignore them.) If it were as easy as you're making it out to be, it would have already been done. -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, [EMAIL PROTECTED]finger, or email with Subject: get pgp key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
