Re: Splitting the debian-changes list...
On May 12, Tom Lees wrote > On Wed, 7 May 1997, Christian Schwarz wrote: > > > Perhaps you can split dinstall into two scripts: One script that is run, > > say once an hour, that just checks incoming for new uploads and posts the > > .changes files in the appropriate lists. This script could check for > > missing files, bad md5sums, bad pgp signs, etc. > > Here's my idea:- > [...] 3 Script way, minor differences i like both ideas (no matter how implemented). having one script checking every hour or so for new files, posting announcements, sending emails if there is something wrong is a good thing. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Please remove your /dev/cu* devices !
On May 12, Brian C. White wrote > The following message is a list of items to be completed for the upcoming > releases of Debian GNU/Linux. If something is missing, incorrect, or you want > to take responsibility for one or more items, please send email to: > Brian White <[EMAIL PROTECTED]> ... > - Use ttyS* devices instead of cua* devices (???) [10] To All Developers : on most systems you will still have /dev/cu* devices (cui* (isdn), cua* (serial), you should not have others, except if you have special serial cards). you don't need them. please remove these devices, so we will find packages still using these devices and can change them to use the corrensponded tty* device. note : current makedev can create and remove cu* devices. but it will not remove the cu* devices during an install script, because that may breake existing setup. new bootdisks and base do not have cu* devices, but you can create them with "/dev/MAKEDEV serial-cu|isdn-cu|...". regards, andreas ... > Footnotes > ~ > ... > 10 - /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are > only going to be using one set of tty devices, you should be using > /dev/ttySxx. > > /dev/cuaXX devices are different from /dev/ttySXX in two ways --- first > of all, they will allow you to open the device even if CLOCAL is not set > and the O_NONBLOCK flag was not given to the open device. This allows > programs that don't use the POSIX-mondated interface for opening > /dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone > calls on their modem (cu stands for "callout", and is taken from SunOS). > > The second way in which /dev/cuaXX differs from /dev/ttySXX is that if > they are used, they will trigger a simplistic kernel-based locking > scheme: If /dev/ttySXX is opened by one or more processes, then an > attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened > by one or more processes, then an attempt to open /dev/ttySXX will result > the open blocking until /dev/cuaXX is closed, and the carrier detect line > goes high. > > While this will allow for simple lockouts between a user using a modem > for callout and a getty listening on the line for logins, it doesn't work > if you need to arbitrate between multiple programs wanting to do dialout > --- for example, users wanting to do dialout and UUCP. > > I originally implemented the cuaXX/ttySXX lockout mechanism back before > FSSTND established a standard convention for the use of tty lock files. > Now that it's there, people should use the tty lock files and not try > using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet > is for backwards compatibility reasons. > -- Theodore Ts'o <[EMAIL PROTECTED]> > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Ideas for `bug'.
On May 13, Nicolás Lichtmaier wrote > On Mon, 12 May 1997, Andreas Jellinghaus wrote: > > > no. bug should prompt the user with a list of conffiles before the > > editor is called. then the user will select the config files to be > > included, and leater in the editor he can edit them (like replaceing > > passwords with SECRET and such stuff). > > What about a `dialog' interface? =) i didn't try, but it could work : PARAM="" for A in `cat /var/lib/dpkg/info/$PACKAGE.conffiles`; do PARAM="$PARAM `basename $A` $A 0" done dialog --checklist "Include Config Files into Bug Report" 0 0 10 \ $PARAM 2> /tmp/bug.dialog.$$ if [ -s "`cat /tmp/bug.dialog.$$`" ]; then for A in `cat /tmp/bug.dialog.$$`; do echo "-- $A" cat $A done >> /tmp/bug.report.$$; fi rm /tmp/bug.dialog.$$ of course a better description would be great. maybe individual packages can come with there own dialog script like dialog --checklist "Bug Report about makedev $VERSION" 0 0 10 \ /etc/devinfo "Database with device descriptions" 1 \ /etc/makedev.cfg "Database with permissions for various devices" 1 \ /dev "List of all devices in your /dev (ls -alr /dev)" 1 \ 2>/tmp/bug.makedev.$$ ... regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Source Formats and Source Package Verification
On May 12, Jim Pick wrote > > Excellent write-up, Klee. Thanks for doing it. I second this; a lot of thought has obviously gone into this, and it shows! > Since I've been attacking this topic lately, I'll try to post some (hopefully) > constructive criticisms. But, overall, I agree with what you said. > > > * [1.1] It must be possible to reconstruct exactly the construction > > of a Debian-format source package directly from upstream sources, > > possibly with the addition of Debian-specific patches or source > > files. Where bit-for-bit archive equivalence of upstream sources is > > not practical (because of troublesome upstream source formats), > > file-for-file equivalence must be provided. > > What's an example of a situation where bit-for-bit upstream archive > equivalence cannot be maintained? I can't think of any situations > where this might happen. Are there archive formats that need to be > used that don't have utilities to unpack them available in Debian? > > * [1.4] The end-user of a Debian system must be able to unpack and > > examine a Debian source package without executing any code other > > than the Debian source unpacking tool. > > Please clarify - unpacking a Debian source package is different > than unpacking an upstream source package (which may require tar, > unzip, zoo, lha, jar, etc.). Right? Personally, I'd be inclined to disagree here, especially given [1.5] below. If I've gone to all the trouble of downloading, putting onto floppies, taking home and unpacking a Debian source package which I need, I would be slightly irritated to discover that it needed some obscure decompression tool, which not only was going to delay my actually having the source for another day, but which would take up yet more space on my already overcrowded hard disc. Admittedly, I personally am unlikely to be in this situation, but I thought it needed pointing out. It's all very well to keep the upstream sources unmodified, but I think we should be sensible about it, and not take it to extremes. At the very least, _ensure_the_dependencies_are_ _readable_under_dos_! Might it be possible to, say, have a list of `supported formats' -- .tar.gz, .zip, others? -- and at least give the option of downloading upstream sources which were originally in other formats as a tarball? This is far from ideal, for any number of reasons (maintainer upload time, archive space), but on the other hand it's IMHO important not to force people to install piles of random decompression programs just to get at the source archives. > > * [1.5] Users of arbitrary UNIX distributions should be able to > > unpack and examine a Debian source package with a minimum of > > complexity, and must be able to unpack it without any non-standard > > tools, and without executing any arbitrary code. > > Same thing as my previous comment. I just want to make sure that > you're not suggesting that we impose conditions on the format of the > packages that come from upstream sources. So our hypothetical user can unpack all the required .lha files and Debian patches, but cannot actually see the source without finding and compiling an lha program (which may well come as a .lha archive from the upstream maintainer anyway)? > > * [2.7] It should be possible to build a Debian-format source package > > in a controlled build environment, without the need for root privileges. I concur; IMHO, this should have happened a while ago. But then, ISTR some security objections etc, which I never really understood: anyone? [snip] > > * [3.3] It should be independent of dpkg and the binary packaging > > system --- those are complex enough already. > > Why? I think it would be a good idea to re-use the new cryptographically > signed binary format you are going to have to create to also package > the source packages. Red Hat does this. Go reread [1.5] above, and then consider whether you /really/ want to require dpkg to be present in order to unpack the dpkg source ... that is at least part of the reason for `why'. And it's been snipped, but one of the points was that it should be possible to generate .tar.gz, .rpm, and so on from the same source archive; if we're going to do this, then forcing the whole world to install dpkg first is going to seriously reduce the chances of this being viable. > It just makes sense. You will also want to reuse the "dependencies > on binary packages" from out of dpkg. I'm sure a lot of the code will come from dpkg; when it's done, it would seem to make sense to use the projected `libdpkg' for this sort of purpose. But I see absolutely no reason to constrain ourselves to the format we already have just because we already have it. > An easy way to do this would be to modify dpkg to consider source packages > as just a special type of binary package. Again, Red Hat already > does this. It would only add another 2-3% more complexity to dpkg, > if done right. That's a lot les
Re: IMP: downgrade ldso to bo: no ldso left!
> On May 11, joost witteveen wrote > > I just downgraded my ldso from the one in unstable, to the one > > in bo, and I appear to be left with a system that doesn't have > > a dynamic linker! > > This is because of a change from a hard link to a symlink in one of > the 1.9.x versions. I'm not sure that I can do anything about it > except to not allow ldso to be downgraded. Well, as the problem is rather serious (very, very, very!), I think the least you can do is warn the user who wants to downgrade to the bo version, and offer him to quit the install if no statically linked version of "cp" or "ln" is available. Or, maybe provide a statically linked version of ln in the preinst (uuencoded) of the bo version of ldso, that the preisnt stores in /tmp/ln-static. Then you could use that /tmp/ln-static to: -maybe use to correct the damage yourself in the postinst, -or, simply "rm /tmp/ln-static" in the postinst: if the system still works, this will safely delete that ln. if the system is broken, the rm doesn't work, and the user at least has a statically linked "ln" available. then just an "echo" will suffice to tell the users what to do (well, it would have worked with me). $ ls -al ln -rwxr-xr-x 1 root root 172383 May 13 12:05 ln* $ ldd ln statically linked (ELF) Yes, it's big, I know. But the problem really is big to. BTW, it isn't unlikely people will want to downgrade to the bo version of ldso, as it's the only version that still allows us to build .deb packages: dpkg-shlib doesn't work with the new ld.so. Yes, I know there's an experimental dpkg out that does work with the new ld.so, but we've just been warned about the dangers of that experimental version. Also, we need to new ldso in order to run libc6 packages (loads already in unstable). So, I can well envisage the situation where people want to switch between the two ldso's -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777i
compiling with gettext
I have been trying for some time to solve Bug #8882 against the 'sp' package, which says that in order to make it buildable under glibc, I need to call libintl as well as libnls in order to accommodate glibc, and to define LINUX_TYPES_H for glibc. I made those changes and could no longer get the program to compile. After a while I realized that the changes were unrelated to my inability to compile the program; which I tested by going back to the original sources and trying recompilation without the fixes. Sure enough, I got the same error messages: 1. First there's a complaint about an undefined dgettext in lib/MessageTable.cxx. I think I bludgeoned this one by inserting the line #include "/usr/share/gettext/intl/libgettext.h" in the top of that file. 2. When I then recompile the program I get the message: MessageTable.cxx:102: parse error before `const' MessageTable.cxx:103: parse error before `const' MessageTable.cxx:104: parse error before `while' MessageTable.cxx:105: parse error before `while' where the four lines in question are: extern char *dgettext(const char *, const char *); extern char *gettext(const char *); extern char *textdomain(const char *); extern char *bindtextdomain(const char *, const char *); I thought I saw a message in debian-devel that gettext was now outmoded. Perhaps this is related to my problem? I notice that Ulrich Drepper has version 0.27 of gettext on his server, but he still has the generic gettext package pointing to 0.26, which is what we have in the distribution and what I have installed. Anyway, it would seem pretty meaningless to me to have a package in the Debian distribution which can't even be compiled. If 'sp' is removed, then so should a lot of other programs that depend on it. If anyone could provide any pointers or advice, I'd try to upload a fixed version very quickly. Susan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
Jim Pick wrote: > Vincent Renardias wrote: > >A while ago there has been a thread about KDE and Qt's licence; some > > people (can't remember who) told they were interested into re-writting a > > GPL'd clone of Qt (possibly on the top on LessTif). What's the status on > > this? I.e: has someone began to code or has the idea been dropped? Just > > wondering... > > Even if we wrote one, I doubt the KDE guys, especially Matthias Ettrich, would > be willing to use it. Really an unfortunate situation, IMHO. :-( Berate me for missing the obvious, but couldn't KDE just be compiled with a QT clone for Debian? What am I missing? -- "Some Internet functionality may require Internet access..." - Microsoft Office 97 requirements Noel Maddy <[EMAIL PROTECTED]> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: IMP: downgrade ldso to bo: no ldso left!
On May 13, joost witteveen wrote > > On May 11, joost witteveen wrote > > > I just downgraded my ldso from the one in unstable, to the one > > > in bo, and I appear to be left with a system that doesn't have > > > a dynamic linker! > > > > This is because of a change from a hard link to a symlink in one of > > the 1.9.x versions. I'm not sure that I can do anything about it > > except to not allow ldso to be downgraded. > > Well, as the problem is rather serious (very, very, very!), > I think the least you can do is warn the user who wants to > downgrade to the bo version, and offer him to quit the install > if no statically linked version of "cp" or "ln" is available. > > Or, maybe provide a statically linked version of ln in the > preinst (uuencoded) of the bo version of ldso, that the preisnt > stores in /tmp/ln-static. Then you could use that /tmp/ln-static to: This problem is not that simple. With the current dpkg, there is no way to fix this even with a statically linked cp or ln. This is because dpkg will remove ld-linux.so.1 before any postinst script gets a chance to repair the damage. What is needed is a generic way to tell dpkg that a file should no longer be considered part of a package so dpkg won't remove it. However, since this particular problem is only fatal to ldso it's probably not worth adding. Without changing dpkg, I don't see any way to fix this except to not allow downgrades. > BTW, it isn't unlikely people will want to downgrade to the bo > version of ldso, as it's the only version that still allows us > to build .deb packages: dpkg-shlib doesn't work with the new > ld.so. Yes, I know there's an experimental dpkg out that does > work with the new ld.so, but we've just been warned about the > dangers of that experimental version. Then Klee, or whomever, should update the current stable version for unstable. The change is trivial and is needed for people to build libc6 packages. 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: IMP: downgrade ldso to bo: no ldso left!
On May 13, David Engel wrote > This problem is not that simple. With the current dpkg, there is no > way to fix this even with a statically linked cp or ln. This is > because dpkg will remove ld-linux.so.1 before any postinst script gets > a chance to repair the damage. How about putting something in prerm. Dpkg gives you a lot of query options, I think you could detect a bad transition and force an error if it's detected. > Then Klee, or whomever, should update the current stable version for > unstable. The change is trivial and is needed for people to build > libc6 packages. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
-BEGIN PGP SIGNED MESSAGE- On Tue, 13 May 1997, Susan G. Kleinmann wrote: > I have been trying for some time to solve Bug #8882 against the 'sp' > package, which says that in order to make it buildable under glibc, > I need to call libintl as well as libnls in order to accommodate glibc, > [ ... ] > > If anyone could provide any pointers or advice, I'd try to upload a fixed > version very quickly. Wait until there is a new gettext. [ gettext 0.10.27 does not even compile under libc5 ]. Galen and I have contacted Ulrich recently. He said there will be a 0.10.28, but he has to find the time to make that release. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: latin1 iQCVAgUBM3iYRiqK7IlOjMLFAQFgKgQAqhJCLzXrJwiT0zrvQmBoqzxvwW4yZ8vm /165r55m13YdK82qxiRg/cOWDjjWtqvQUMfsikgBgndstQ3ztBTHSH8eFy72CK1t s6IgOS5X29rkZF19rvyjiLM6Bchz+0F8gXVR74AhVTy+0iq0+fj2+oQ73mMaFOVN JAhtoN9DcJ8= =Vj89 -END PGP SIGNATURE- Santiago Vila <[EMAIL PROTECTED]> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Source Formats and Source Package Verification
> > Please clarify - unpacking a Debian source package is different > > than unpacking an upstream source package (which may require tar, > > unzip, zoo, lha, jar, etc.). Right? Andy Mortimer wrote: > Personally, I'd be inclined to disagree here, especially given [1.5] > below. If I've gone to all the trouble of downloading, putting onto > floppies, taking home and unpacking a Debian source package which I need, > I would be slightly irritated to discover that it needed some obscure > decompression tool, which not only was going to delay my actually having > the source for another day, but which would take up yet more space on my > already overcrowded hard disc. > > Admittedly, I personally am unlikely to be in this situation, but I > thought it needed pointing out. It's all very well to keep the upstream > sources unmodified, but I think we should be sensible about it, and not > take it to extremes. At the very least, _ensure_the_dependencies_are_ > _readable_under_dos_! > > Might it be possible to, say, have a list of `supported formats' -- > .tar.gz, .zip, others? -- and at least give the option of downloading > upstream sources which were originally in other formats as a tarball? > This is far from ideal, for any number of reasons (maintainer upload > time, archive space), but on the other hand it's IMHO important not to > force people to install piles of random decompression programs just to > get at the source archives. Well, either we are going to wrap the pristine upstream sources in a "Debian format source package" -- or we are going to just store the pristine upstream sources (in tar.gz, .zip, etc, etc) in the source archive individually. If we go with pristine sources, we can't modify the package they originally came in (or the md5 checksum is different). I think that it would be pragmatic though to not allow any upstream source packages that come in a file format that can't be unwrapped by an available Debian package. Also, it might be wise to limit the variety of upstream source package formats for packages in the base system. Actually, if we used the same basic file format for source packages as we do for binary packages, we could generate Packages files for the source tree in the ftp archive. This would surely make things easier from dos. BTW: Do you know anybody who really needs to put all the tools needed to build source packages onto floppies? :-) > So our hypothetical user can unpack all the required .lha files and > Debian patches, but cannot actually see the source without finding and > compiling an lha program (which may well come as a .lha archive from the > upstream maintainer anyway)? We should require that a Debian package is available to extract .lha files before we allow upstream .lha files into our source archive. > > > * [3.3] It should be independent of dpkg and the binary packaging > > > system --- those are complex enough already. > > > > Why? I think it would be a good idea to re-use the new cryptographically > > signed binary format you are going to have to create to also package > > the source packages. Red Hat does this. > > Go reread [1.5] above, and then consider whether you /really/ want to > require dpkg to be present in order to unpack the dpkg source ... that > is at least part of the reason for `why'. And it's been snipped, but one > of the points was that it should be possible to generate .tar.gz, .rpm, > and so on from the same source archive; if we're going to do this, then > forcing the whole world to install dpkg first is going to seriously > reduce the chances of this being viable. Currently, it is possible to extract the files out of any .deb file without having dpkg by using 'ar' and 'tar'. This is comparable to the effort required to extracting our current source packages by hand, for which you need 'tar' and 'patch'. There is a section in the packaging manual that explains how to do it. I wonder if it is possible to extract the files out of a .rpm file without using rpm? > > It just makes sense. You will also want to reuse the "dependencies > > on binary packages" from out of dpkg. > > I'm sure a lot of the code will come from dpkg; when it's done, it would > seem to make sense to use the projected `libdpkg' for this sort of > purpose. But I see absolutely no reason to constrain ourselves to the > format we already have just because we already have it. I have no problem with that. I just thought it should be mentioned. > Hoping I've written at least something useful, Yes, you sure have, thanks for joining in to the debate! Cheers, - Jim pgpvogDHeyJBQ.pgp Description: PGP signature
Re: FreeQt ?
> Jim Pick wrote: > > Even if we wrote one, I doubt the KDE guys, especially Matthias Ettrich, > > would > > be willing to use it. Really an unfortunate situation, IMHO. :-( Noel Maddy wrote: > Berate me for missing the obvious, but couldn't KDE just be compiled with > a QT clone for Debian? What am I missing? That's true. However, since the primary users of Qt are the KDE guys, and since they wouldn't like what you were doing if you were re-writing it -- it just doesn't seem like it would be a very rewarding way to spend one's time. Especially since there are already free application frameworks like wxWindows and V that do essentially the same thing (unless I'm missing something). If someone wants to contribute to an effort to clone a toolkit, they'd probably be much better off contributing to the WINE project (Windows emulator) or Jolt project (Java clone - kaffe, biss-awt, guavac, etc.). Besides, Qt is 'almost-free' software. If it doesn't become a runaway commercial success, I'd bet Troll Tech would re-release it as free software after a few years. Cheers, - Jim pgpZ2mlXHyxRM.pgp Description: PGP signature
Re: FreeQt ?
On Tue, 13 May 1997, Jim Pick wrote: > If someone wants to contribute to an effort to clone a toolkit, they'd > probably be much better off contributing to the WINE project (Windows > emulator) or Jolt project (Java clone - kaffe, biss-awt, guavac, etc.). What do you think about "Lesstiff"? -- Enrique Zanardi[EMAIL PROTECTED] Dpto. Fisica Fundamental y Experimental Univ. de La Laguna -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> On Tue, 13 May 1997, Jim Pick wrote: > > > If someone wants to contribute to an effort to clone a toolkit, they'd > > probably be much better off contributing to the WINE project (Windows > > emulator) or Jolt project (Java clone - kaffe, biss-awt, guavac, etc.). > > What do you think about "Lesstiff"? That's a good one to help out with too. I am sure that there are others (Gtk, Free-LIP, etc...). Or someone could always write their own - one more couldn't possibly hurt. :-) I'm not really clear on what the best toolkit for development really is, but some of the free ones look really, really good. I'll probably end up doing most of my GUI stuff using a higher-level toolkit like Java or Tcl/tk though. Cheers, - Jim pgpqHhvmoUfdn.pgp Description: PGP signature
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On 12 May 1997, Manoj Srivastava wrote:
> >> say that if the source is well behaved (that is, it is a tar file
> >> that unpacks into *some* directory other than ., compressed or
>
> Kai> You seem to think a tar that unpacks into "." is a problem. I
> Kai> still fail to see why.
>
> Kai> Just unpack into a temporary subdirectory.
>
> I was just thinking of the problem of determining which case
> it was ...
>
> Suppose I hace A.tar.gz and B.tar.gz, and I need to apply a
> diff to them to get the debianised source. In each case, I unpack
> into ./temp.
>
> Case 1: I get ./temp/A/{1,2,3}, in the second case I get
> ./temp/{4,5}. In case 1 I should cd into ./temp/A before applying
> the diff, in the second case I have to cd into ./temp and apply the
> patch.
>
> At first glance, it may be difficult to determine whether
> currently we are facing case one or two.
>
> There may be an easy solution that is not obvious to me.
Write our own "safe" scripting language. Not difficult, and really rather
useful. So, eg:-
Unpack A.tar.gz in /A
Patch A.diff in /A
Unpack B.tar.gz in /
Patch B.diff in /
This would be very nice IMHO.
--
Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
On Tue, 13 May 1997, Susan G. Kleinmann wrote: > I have been trying for some time to solve Bug #8882 against the 'sp' > package, which says that in order to make it buildable under glibc, > I need to call libintl as well as libnls in order to accommodate glibc, > and to define LINUX_TYPES_H for glibc. I made those changes and could > no longer get the program to compile. After a while I realized that > the changes were unrelated to my inability to compile the program; which > I tested by going back to the original sources and trying recompilation > without the fixes. Sure enough, I got the same error messages: > > 1. First there's a complaint about an undefined dgettext in > lib/MessageTable.cxx. I think I bludgeoned this one by inserting the > line > #include "/usr/share/gettext/intl/libgettext.h" > in the top of that file. This means you compiled with libc6 headers but didn't link with libc6. Linking with libc6 will fix the above, and fully gettextizing the sources will fix it for libc5. > 2. When I then recompile the program I get the message: > MessageTable.cxx:102: parse error before `const' > MessageTable.cxx:103: parse error before `const' > MessageTable.cxx:104: parse error before `while' > MessageTable.cxx:105: parse error before `while' > > where the four lines in question are: > extern char *dgettext(const char *, const char *); > extern char *gettext(const char *); > extern char *textdomain(const char *); > extern char *bindtextdomain(const char *, const char *); The problem is that gettext, etc., are being recognized by the preprocessor! You don't need these, you should #include the appropriate libintl.h instead. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 12.05.97 in <[EMAIL PROTECTED]>: > >>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes: Kai>> Well, yes. Scan the temp dir after unpacking. If it contains one Kai>> directory and nothing else, that directory is the main package Kai>> directory. If it contains anything else, the temp dir is the main Kai>> package dir. Rename the right directory to the right name and Kai>> place, and if the temp dir is still around, throw it away. > Unless the sources (like angband-2.7.6) just contained a > single directory, and unpacked in . (granted, this is a pathological > case, but it prevents us from saying we have a fool-proof method). There seems to be a communication breakdown somewhere. My above method handles *all* cases, without exception, though from your description I can't quite make out if angband is the first or the second case. (Actually, I think the idea may orignally have come from Bruce, though I won't swear to that. It's kind of a "duh, why didn't I think of that" idea.) > Anyway, the algorithm above _would* handle most cases, and > that might be good enough. Nope. It does indeed handle *all* cases. Well, all cases where the tar doesn't contain pathnames going outside the current directory, but people building tars like that should be shot anyway - that's not a tar, that's a breakin attempt. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Source Formats and Source Package Verification
[EMAIL PROTECTED] (Andy Mortimer) wrote on 13.05.97 in <[EMAIL PROTECTED]>: > On May 12, Jim Pick wrote > > > > Excellent write-up, Klee. Thanks for doing it. > > I second this; a lot of thought has obviously gone into this, and it > shows! Me too! > > > * [1.1] It must be possible to reconstruct exactly the construction > > > of a Debian-format source package directly from upstream sources, > > > possibly with the addition of Debian-specific patches or source > > > files. Where bit-for-bit archive equivalence of upstream sources is > > > not practical (because of troublesome upstream source formats), > > > file-for-file equivalence must be provided. > > > > What's an example of a situation where bit-for-bit upstream archive > > equivalence cannot be maintained? I can't think of any situations > > where this might happen. Are there archive formats that need to be > > used that don't have utilities to unpack them available in Debian? How about where part of the upstream archive could go into the main distribution, but part needs to go into non-free or non-US, even for the sources? That's a case where you _must_ repack the original archive. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: > Lars Wirzenius: > > They might not understand enough about shell scripts (or Perl, or > > whatever the script is written in) and whatever tools the script uses > > to make an informed decision of whether the script is safe. With the > > current scheme, they only have to trust gzip, tar, patch, and chmod, > > And all of debian/rules. And debmake or anoy other programs called by it. > They are planning on building this package, right? IMHO this is where we ought to be looking to improve our source packaging system. At least we should allow building as a non-root user as soon as possible (using the new GNU tar). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug system `followup' messages
On 12 May 1997, Manoj Srivastava wrote: > Hi, > > I think, from the volume of discussion on bugs-dist, that most > developers have signed up on that list (and I at least follow it > quite diligently). I would rather not clutter up debian-devel with > that traffic (if we send all reports to debian-devel, please arrange > to have the debian-bugs* list stopped, since they will be largely > useless). I agree. However, I have cut back on following debian-bugs-dist, as I don't have the time at the moment, and I consider debian-devel more important. I suspect other people may do this as well. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: > Kai Henningsen: > > Remember: no shell scripts in the source packages that are needed for > > unpacking. It's just too dangerous. > > I don't understand why this is more dangerous than debian/rules. Why? You don't get to review it before it's run. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sending closed bug notices to interested parties.
On Sun, 11 May 1997, Chris Walker wrote: > Further to the announcement from Ian Jackson about the creation of a > mailing list for closed bugs > > There may be circumstances when I wish to know if a bug has been closed, > but am not the person who reported the bug (eg I want to know when the > CVS/inetd.conf bug is fixed so I can feel safe upgrading). Bad example. Upgrading is what causes that bug to happen :( > Would some mechanism of saying "when this bug is closed notify me as > well" eg by sending a specially formulated e-mail, or perhaps some web > interface. This might be useful, as in general I probably don't want to > see all bug report closures. Maybe a "watch" feature, where you can tell the bug system what you want to see about a bug report (if you have ever used CVS watches, you will know what I'm talking about). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#8794: wrong arch declaration in dpkg.
On Sun, 11 May 1997, Ian Jackson wrote: > > The good definition of powerpc processors is 'powerpc', not 'ppc'. > > Was this issue settled ? This will be hard to change later, so it's > important to get it right quickly. I believe it was. > > --- archtable Thu Feb 27 21:53:23 1997 > > +++ archtable.new Wed Apr 16 16:22:49 1997 > > @@ -21,4 +21,4 @@ > > alpha alpha alpha > > m68k m68km68k > > armarm arm > > -ppcppc ppc > > +powerpcpowerpc powerpc This is already in dpkg 1.4.0.15. But it should also have:- ppc powerpc powerpc -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: > > You might want to unpack a source package for other reasons than > > to build it -- e.g., I've sometimes searched for documentation. A > > non-programmer might want to do this so that they can typeset the > > documentation in LaTeX, instead of printing out the LaTeX2HTML'd > > version. > > The srcpostinst thing was just a trial baloon - I don't think it > went over very well. So I'll drop that idea. But if we go with > a source package file format that is the same basic thing as > what a .deb file is, we can always add it later (if needed). > I think it's better to unpack the upstream sources in the > debian/rules makefile anyways (using any tool available on the > system). I'd oppose having a specialized script file for > unpacking them, since it's unnecessary -- you can already do > that from the debian/rules makefile. This would be better - someone can overlook the debian/rules file first. > As I said before, I'm quite interested in having a source package > that automatically unpacks the upstream sources and patches itself > for the purposes of debugging -- and also can be set to automatically > build too. This is the equivalent of a "make world". But nobody's This would be difficult. I always thought that make world was simpler than this, though - what does is do exactly? (I haven't used any of the *BSD distributions). > saying that the system administrator can't have the option of > just "installing" the source, without running any scripts. This > should probably be the default behaviour. Maybe we should limit our support to only certain formats instead of needing scripts to unpack it - the dpkg end of this could get messy with pipes or temp. files. I propose we support zip and the various tar formats only. > Before I was advocating the use of a separate "sdpkg" program to > install source packages, but it could probably be done with > just "dpkg". > > ie. > > dpkg -i jdk_1.0.2-7.sdeb > > Since the extension is .sdeb, dpkg would know that it was a source > package, and just put it in the appropriate place. Maybe > /var/lib/dpkg/source/jdk_1.0.2-7 possibly? Since the package > has dependencies (to .upsdeb's for upstream source, and .deb's for > binaries needed to build it), those would also need to be installed too. This should probably be /usr/src/debian. Then we could have a nice set of Makefiles installed to let us do a "make world" style system. (If I understand "make world" properly). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Wishing to maintain package 'dpkg-ftp'
It seems that this package hasn't evolved for quite a long time. As there are many bug-reports, and as I worked out fixes for some of them, I suppose its maintainer has no time for it, and I'm wishing to maintain it. If I get no response within a week, I'll take for granted that there's no opposition to that, and start releasing fixes. Is there any reason not to do so ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9242: dpkg: dpkg could be smart about Changes information
On Sun, 11 May 1997, Ian Jackson wrote: > > It would be useful if the kind of information sent to the debian-changes > > mailing list were integrated into dpkg. For available updated packages, a > > user > > could use information about the number and Urgency: of each intervening > > update. > > Also useful would be access to the developer's comments on each upgrade. > > I can see why this would be useful. However, there is the problem of > transferring all of this data to the user's system. > > The more information we try to provide the user with the more they > will have to download for each package that they choose not to install > or upgrade. > > In this particular case, I'm unconvinced that supplying the user with > the whole change history of a package is a reasonable thing to > attempt. IMHO, a parser for the "Last week's uploads into i386" files regularly posted to debian-(devel-)changes would be ideal. Then you create another mailing list to house these announcements only, and make dpkg remove the old info when the package is upgraded. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I'm (almost) back (and Linuxconf)
I am almost finished with my AP's, only having Biology tomorrow. During my free time I have thaught up a way that may allow us to use Linuxconf, and all of it's starting/stoping features w/o replacing init. The author of linuxconf liked the idea so it looks like we might have an easier time of getting linuxconf and debian to work than before. However, I'll go into that later as I am mentally exahusted from all these AP's. who knew it would be so hard to learn 5 full year college classes in a 2 week period. :-). Shaya -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Unidentified subject!
hi i,m just wondering if any of you companies can offer me any help with my ansi c progrmming assignment. Thanks waseem -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dpkg verify mode for security?
Hi, I was asking over Linux-ISP about doing cleanup after breakins and got many "use tripwire" answers, and one which says that RPM has a verify mode which checks for files which were changed since they were installed. Can the dpkg maintainers consider adding such a feature for Debian? Chees, --Amos --Amos Shapira | "Of course Australia was marked for | glory, for its people had been chosen [EMAIL PROTECTED] | by the finest judges in England." | -- Anonymous -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: > The point I was trying to make was that having dependencies on > binary packages would be really, really nice. This gets more complicated. To allow for cross-compiling or bootstrapping, some packages need to be compilable using the Source from another package, so eg:- SrcPackage: xmp Depends: awe-drv | src.awe > > > Klee favours having a simple .sdeb and no upstream .upsdeb's. I think > > > we need to debate this some more. > > > > Well, my mind's decided. Bandwidth costs, cross-Atlantic especially, > > and the trivial inconvenience of having three files instead of one > > is very well worth it in real money. > > I basically agree with this. But I'm going to keep an open mind, until I > see more debate. I totally agree. RPM's way _is_ broken. > > > I think you missed the point -- this system enables a single source > > > tree. > > > > The current system can be a single tree as well (put all source > > packages in one directory, and do a loop with "dpkg-source -x", > > and "dpkg-buildpackage -rsudo -uc -us"), but both systems are > > pretty far from the BSD source tree, I think. > > Unfortunately, with the current state of the source tree, this doesn't > really work. It's way too easy to build source packages that > don't unpack with dpkg-source -x. I've seen way too many packages > for my liking that won't build out of the box. Many of them > depend on specialized environments that only exist on the > original maintainers machines. IMHO this is where we need the possibility of dependencies on Source or Binary packages. Also a standardized "build lab" (build-i386.debian.org, etc.) being enforced would be a really nice way of ensuring a self-consistent distribution. But I'm not sure if we have the resources to do that. > > But that's beside my point -- there's so much other work to > > do at the moment that I don't think big changes the source > > packaging format at this point will improve things. > > There's always too much to do... :-) We should be planning this for Debian 2.0. The release of that will have lots of nice new features (deity for one). > > > Actually, I think the scheme I proposed is actually very incremental, > > > > It would change all source package file formats, and all tools > > relevant to source packaging, and would require our developers > > to learn to deal with a third source packaging format. A bit > > too much of an increment for me. :-) > > I agree that the current source packaging system works, but it is broken > in many ways. So we're going to have to fix it sooner or later. Preferably sooner. It would be really nice if deity could handle *source* packages :>. But its getting designed pretty quickly, and might not be flexible enough by the time the new source stuff gets done. > If we wait until later, there's going to be even more of an installed > base of tools and packages that are going to need to be changed. So my > personal preference is to spend some time up front to get our act > in order. Right now, this ranks #2 on my list of things Debian has to > fix -- dselect/diety is #1. dselect/deity and this are basically part of the same overall problem - the packaging and distribution system needs a bit of an overhaul. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and Linuxconf (again :-) ) (fwd)
This is the message I got from the developer. If you have any comments
cc: me, as I have resubscribed to the lists yet.
Shaya
-- Forwarded message --
Date: Mon, 12 May 1997 23:37:51 -0400 (EDT)
From: Jacques Gelinas <[EMAIL PROTECTED]>
To: Shaya Potter <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Debian and Linuxconf (again :-) )
On Sat, 3 May 1997, Shaya Potter wrote:
> Since I have had a lot of time off for exams, I have been thinking about
> what whould be neccesary for Linuxconf and Debian to coexist. (and a
> method that the debian developers would go for). Is it possible, that
> some of Linuxconf's init features could be folded into SysV init. Then
> Linuxconf wouldn't have to start up applications. However, Linuxconf
> would still be able to manage the applications, because the init.d
> scripts would be written in a standard way to give Linuxconf all the
> information it needs. With a simple parsing of the
> /etc/rc{1,2,3,4,5,6}.d scripts. and /etc/init.d. Linuxconf would be
> able to tell the users what daemons are running, and to give them the
> ability to start and stop them. With a little more work, Linuxconf
> would also be able to move the links around the rc{1,2,3,4,5,6}.d tree
> and give the user many different run levels.
>
> The main advantage that I see in going in this direction would be that
> the people who are nervous about replacing init, will have all their
> fears assuaged, and Linuxconf will still run like you want it to. or am
> I missing something.
Hello Shaya
Before I start, I would like to point something. Currently, I am dealing
with two other Debian users. By far they are the most "demanding" testers.
(which is a quality btw) I am including their email address as I know
they have voiced their interest for linuxconf on Debian mailing list. It
would be good if you could exchange with them.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
They are also CC on this mail (hello both of you) as I feel we have
something going on here. I am writting this line before sending this
pretty long message, so read it up to the end. I hope this is
constructive.
---
I understand your idea about letting linuxconf get in more easily. There
is a major drawback with your scheme. One big issue with linuxconf is that
it is monitoring and controlling the boot process. This give a level a
quality that no bunch of scripts could emulate. To give you an example, I
suggest the following experiment.
unplug your ethernet adaptor (or give a faulty config
in /etc/conf.modules)
reboot
Do the experiment with and without linuxconf.
Then take a picture of the one without linuxconf and show that to your a
friend for a clue (for sure you know what is going on). Linuxconf will
tell you that the ethernet adaptor is not working. The scripts will be
called one after the other and produce all kind of neat result like
-long timeout
-meaningless error message
Further, there is no hierarchy in the sysV scripts. They are executed in
order, without a clue that if one does not succeed (generally the result
code of the commands is not even looked at) the next one should not even
be attempted (why setting IP alias on eth0 if there is no eth0).
While linuxconf is already providing something, it will have to be enhance
to make error condition much more useful and allow reconfiguration on the
spot available in more place (This is available only on some error
condition). The current framework of linuxconf is there to grow, while
the sysv script system is oversimple.
If you are attacking the mass market, sysv script are not the solution,
especially in a world where the idea that "unix is difficult" is a trend.
With linuxconf, we stand a fair chance of providing something that is open
and yet informative and easy (as oppposed to close and broken like w95,
but looking good: You have no idea what is going when it boots).
Think of something you want to give to a newbie.
Ok, linuxconf publicity done :-)
Now, this being said, I understand most people don't realise the benefit
of this concept for a very simple reason: Once you have a working
"workstation" setup (read simple configuration), the sysv scripts will
reliably activate it any time. If you had a service, it will be activated
also. This is only when something goes wrong that the sysv init script are
falling apart (user interface wise).
Now, to say something useful :-)
Maybe we have a strategy along what you are proposing. One key concept of
linuxconf is that it does not have a "boot" or "goto this state"
command. Linuxconf have indeed a more complex concept where it can compute
the proper path (set of commands) to bring the current state (whatever it
is) to the "configured" or "wanted" state. For example, you can do
netconf --update
netconf --update
several time. The first will do something, while the oth
Re: New Source Formats and Source Package Verification
> How about where part of the upstream archive could go into the main > distribution, but part needs to go into non-free or non-US, even for the > sources? > > That's a case where you _must_ repack the original archive. > > > MfG Kai No. I'd just say upload the upstream sources to the non-US site. I agree that it's not nice having the binary package on one site, and the source package on the other - but it's the stupid US regulations that are the problem. BTW, I recently discovered that it is legal for me to mirror the non-US stuff in Canada (or reg's exempt free software -- whoopee!). That would be good -- there currently isn't a mirror of the crypto stuff on this continent. I'll try to set it up by the end of this week. Cheers, - Jim pgpjFqvKKnqvb.pgp Description: PGP signature
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
Tom Lees wrote: > This gets more complicated. To allow for cross-compiling or bootstrapping, > some packages need to be compilable using the Source from another package, > so eg:- > > SrcPackage: xmp > Depends: awe-drv | src.awe I don't think it adds any complexity if upstream source packages, debian source packages, and binary packages are all treated the exact same way. > IMHO this is where we need the possibility of dependencies on Source or > Binary packages. Also a standardized "build lab" (build-i386.debian.org, > etc.) being enforced would be a really nice way of ensuring a > self-consistent distribution. But I'm not sure if we have the resources > to do that. If we can do it on a piece-meal, automated basis - just a lowly 386 that someone's planning on chucking out might work. I've got one -- but it's currently being used as an internet gateway. > We should be planning this for Debian 2.0. The release of that will have > lots of nice new features (deity for one). I don't see too much of a need to rush it. The current system does work. Really, all a new system will do is make life a bit easier for the Debian developers. However, we may collectively decide that the ability to have cryptographically signed packages is so important that it is worth rushing it. Cheers, - Jim pgpurUXkgLk2n.pgp Description: PGP signature
Re: dpkg verify mode for security?
> Hi, > > I was asking over Linux-ISP about doing cleanup after breakins and got > many "use tripwire" answers, and one which says that RPM has a verify > mode which checks for files which were changed since they were > installed. Can the dpkg maintainers consider adding such a feature > for Debian? > > Chees, > > --Amos Check out Klee Diene's dpkgcert package (in experimental). You might have to write to him to find out where to get the certificates that go along with it. It really helped me recover from drive corruption. Cheers, - Jim pgpBt06MowdnQ.pgp Description: PGP signature
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
Hi, [This is getting silly, I really have no objection to the proposal] >>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes: Kai> [EMAIL PROTECTED] (Manoj Srivastava) wrote on 12.05.97 in Kai> <[EMAIL PROTECTED]>: >> >>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes: Kai> Well, yes. Scan the temp dir after unpacking. If it contains one Kai> directory and nothing else, that directory is the main package Kai> directory. If it contains anything else, the temp dir is the main Kai> package dir. Rename the right directory to the right name and Kai> place, and if the temp dir is still around, throw it away. >> Unless the sources (like angband-2.7.6) just contained a single >> directory, and unpacked in . (granted, this is a pathological case, >> but it prevents us from saying we have a fool-proof method). Kai> There seems to be a communication breakdown somewhere. My above Kai> method handles *all* cases, without exception, though from your Kai> description I can't quite make out if angband is the first or the Kai> second case. package A:, in A-1.0.tar.gz; % tar zfx A-1.0.tar.gz ./B ./B/C ./B/C/D ./B/C/D/1 ./B/C/D/2 ./B/C/D/3 ./B/C/D/4 ./B/C/D/5 Though this is pathological, I have really seen sources on the net distributed like this (though I don't think current packages have sources anything this wierd.) I was being pedantic when I said all source packages can't be handled by the algorithm, but it would handle most real world sources and IMHO could be considered quite adequate (but not perfect). Kai> (Actually, I think the idea may orignally have come from Bruce, Kai> though I won't swear to that. It's kind of a "duh, why didn't I Kai> think of that" idea.) >> Anyway, the algorithm above _would* handle most cases, and that >> might be good enough. Kai> Nope. It does indeed handle *all* cases. Well, all cases where Kai> the tar doesn't contain pathnames going outside the current Kai> directory, but people building tars like that should be shot Kai> anyway - that's not a tar, that's a breakin attempt. Oh yes, pathanmes with .. components would _also_ break the algorithm. manoj nit-picking -- "In the Bowling Alley of Tomorrow, there will even be machines that wear rental shoes and throw the ball for you. Your sole function will be to drink beer." Dave Barry Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Wishing to maintain package 'dpkg-ftp'
On May 13, Yann Dirson wrote > > It seems that this package hasn't evolved for quite a long time. As > there are many bug-reports, and as I worked out fixes for some of > them, I suppose its maintainer has no time for it, and I'm wishing to > maintain it. Have you tried to email the current maintainer directly first? I don't think there'd be any objections to you doing a non-maintainer (bugfix) release (as documented in the policy manual, methinks) if the current maintainer doesn't pop up on debian-devel this week. But just taking over his package like that (without getting his ok) would be, IMHO, a bit rude. People do take vacations, etc. Christian pgpOUpDhDMxU0.pgp Description: PGP signature
Re: New Source Formats and Source Package Verification
Hi, >>"Jim" == Jim Pick <[EMAIL PROTECTED]> writes: >> Might it be possible to, say, have a list of `supported formats' -- >> .tar.gz, .zip, others? -- and at least give the option of >> downloading upstream sources which were originally in other formats >> as a tarball? This is far from ideal, for any number of reasons >> (maintainer upload time, archive space), but on the other hand it's >> IMHO important not to force people to install piles of random >> decompression programs just to get at the source archives. Jim> Well, either we are going to wrap the pristine upstream sources Jim> in a "Debian format source package" -- or we are going to just Jim> store the pristine upstream sources (in tar.gz, .zip, etc, etc) Jim> in the source archive individually. If we go with pristine Jim> sources, we can't modify the package they originally came in (or Jim> the md5 checksum is different). I think that it would be Jim> pragmatic though to not allow any upstream source packages that Jim> come in a file format that can't be unwrapped by an available Jim> Debian package. Also, it might be wise to limit the variety of Jim> upstream source package formats for packages in the base system. Or, thirdly, we use pristine sources iff they are in supported formats, or else the upstream source is massaged into a supported format, and BIG signs are posted pointing to the real sources and the steps taken to massage it into the supported format. manoj -- Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Behaviour of "Conflicts:"
[ NOTE: I don't subscribe to debian-devel, and my question is geared towards the developers, so please ensure that responses are CC:'d back to me ([EMAIL PROTECTED]). Thanks. ] G'Day, I'm curious about how dpkg handles the "Conflicts:" line of packages that are already installed on the machine. If package X conflicts with package Y, and Y is already installed, I cannot install X. This is normal. BUT... if X is installed, what happens if I try to install Y? Y doesn't say that it conflicts with X. Does dpkg somehow scan thru the installed packages' control files to check for conflict? I would hope that dpkg would somehow catch this and prevent the installation of Y. This could be a serious problem otherwise. If this has been pointed out before, just let me know and I'll shut up. Cheers, -- Todd Harper"Damn it Smithers, this isn't rocket science, [EMAIL PROTECTED] it's brain surgery!" -- Mr. Burns -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
