ITP: mconfig -- kernel configuration tool
Package: wnpp Version: N/A; reported 2001-12-23 Severity: wishlist * Package name: mconfig Version : 0.20 Upstream Author : Christoph Hellwig <[EMAIL PROTECTED]> * License : GPL Description : mconfig is a tool to configure a Linux kernel. Unlike the scripts that come with kernel source it has a grammar written in yacc and that is compiled once not for each new kernel release. It supports severals interfaces modes for different uses. A test package can be found as http://www.hodek.net/mconfig_0.20-1_i386.deb. Source and .changes also there.
Bug#46388: NO 2.1r3 M68K CDs: trn depends
> trn: > Depends: libc6, libncurses4 (>= 4.2-3.1), inews [...] > 68k - I think this is a bug in your build daemon - it's built a > slink package against the potato libraries. Can any of you give me > access to a slink machine to fix this? cd - as requested. It's not (strictly speaking) a bug in buildd, but the package simply has been built on the wrong machine... (probably by rbuilder). However, I've already heard of this problem and have immediately rebuilt trn (3.6-9.3.2). This version depends on "libc6, libncurses4, inews", i.e. no versioned libncurses dependency. It's installed in proposed-updates. If you want to make the m68k CDs from stable only, please nudge the FTP admins to install the package now. Roman
Re: Upload queue software?
> Well, it's about time I upgraded from the fairly ancient version of > this that I'm using on www.uk.debian.org, and making a package will > probably only add a minor overhead to the procedure, so if you like, > I'll look at packaging it. Sure, go ahead; I won't mind :-) Roman
Re: Upload queue software?
> > It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian > > package because it runs on other Unixes, too (mine runs under > > Solaris). > > Hmm, why does that prevent you from packaging it? :> It doesn't really :-), but: - A Debian package plus the still necessary .tar.gz is somewhat more effort for me... - For a proper Debian package, I'd have to write some config stuff etc., for which I'm too lazy :-) So it basically comes down to laziness, yes :-) Roman
Re: Uploading to pandora (nonus)
> Practical question from a porter: imagine some of my recent uploads > have rejected, because they do not follow yet the new sceme. > Allthough when the source package was uploaded, there was no new > scheme yet. Now when I build that package I have to edit > debian/control as a porter otherwise the port will not be included > until the maintainer edits debian/control? I'd edit the resulting .changes file instead (before signing). That's easier. > And when I edit it, I'll have to find out myself in which section > the package will go, ie by locating the source/i386-bin package on > the non-US server? Yes :-( Roman
Re: Upload queue software?
Hi Jason! > Does anyone know where I can find the software to run a debian > upload queue? I thought it was packaged but I can't seem to find it > using the obvois searches.. It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian package because it runs on other Unixes, too (mine runs under Solaris). Roman
Re: Wish to orphan or kill: dbuild; Or: Is it of any actual use?
> does buildd have a package ? Not yet. James is working on it, but it's not trivial and may take some time (and James and James<2> are constantly low on spare time :-) > can it be used interactively, and not as a demon ? Yes and no :-) buildd itself is non-interactive, of course, but it uses a script sbuild for the actual unpacking and compiling, and sbuild is rather similar in purpose to dbuild, with the addition that it can also fetch source packages from different locations and that it knows about source dependencies. Roman
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
> SOLUTION 3 > -- > Well, we can also decide that to leave the situation as it is. In this > way, however, users would not be able to install the new version of the > library without also installing libpaperg (and libc6...) That isn't the real problem, but the upgrade from an old system (e.g. bo). The libc6 version libpaperg surely conflicts with older versions of libpaper, where the libs weren't installed to /usr/lib/libc5-compat yet. So to upgrade, the user has to: - Install a new libpaper before libpaperg (due to conflict) - Install libpaperg before libpaper (due to dependency) Obviously, this is Catch-22 :-) The only remedy is to remove the old libpaper, and then to install libpaper and libpaperg. I guess apt will do something like this, and dftp can handle those cases, too. But dselect surely not :-) In any case, it's unconvenient and not obvious to the average user. Additionally, you loose your paper config in the process. > SOLUTION 1 (Suggested by Wichert) - > Create the packages: libpaper - the old libc5 library. May suggest > libpaper-bin. libpaperg - the new libc6 library. May suggest > libpaper-bin. libpaper-bin - the binaries&manpages. Depend on > libpaperg > > Here the problems are that we do not guarantee, by installing > libpaper, that the executables are present in the system. OTOH, by > making libpaper depend on libpaper-bin, the installation of libpaper > would also force the installation of libpaperg, which is what we > wanted to avoid. Yep. Such a dependency would reintroduce the problem we wanted to fix. But I think this alternative is the only one that fix the problem really, so I'd vote for it. > Moreover, one on the executables (paperconfig) is used in the > postinst of libpaper to configure the library; if the executables do > not appear in the libpaper package, it is not possible to call > paperconfig in the postinst, so a different way to initialize the > library should be used (for instance, a subset of paperconfig should > be included in the postinst). I don't know what paperconfig exactly does now, but the idea of replacing the call to it by some simple script can do the job. Additionally you should recommend libpaper-bin, in whose postinst paperconfig can be called. Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signals and atomicity
> if you implement "interruptible" system calls this way: 1. UNBLOCK
> SIGNAL 2. SYSTEM CALL 3. BLOCK SIGNAL it may happen that the signal
> handler is called just after unblocking the signal but before the
> call. this way no EINTR happens, the signal is lost and (2) is stuck
> in the system call.
>
> because of this, i have to do a siglongjmp() in the signal handler.
> now it isn't anymore possible that signals get lost. BUT ! i do not
> know the return value of the system call, if it was interrupted.
> remember, after the call , the signal is blocked again. now, if the
> call succeeded, but still before the BLOCK SIGNAL command, if now
> again a signal is received, siglongjmp jumps away, and the fact,
> that the system call succeeded is just lost.
You can solve it this way (at least I hope... :-) :
static int timeout;
static void alarm_handler(int sig) {
timeout = 1;
}
int wait_or_timeout (int *status) {
struct sigaction act;
int wait_retval;
timeout = 0;
sigaction(SIGALRM, 0, &act);
act.sa_handler = alarm_handler;
act.sa_flags &= ~SA_RESTART;
sigaction(SIGALRM, &act, 0);
alarm(1);
wait_retval = wait(status);
alarm(0);
/* ... */
}
If 'timeout' is set at the end, SIGALRM was delivered before the
alarm(0). On the other hand, wait_retval is -EINTR if and only if the
system call itself has been interrupted. So you can distinguish
between the cases "system call interrupted" and "signal arrived, but
somewhere around the syscall".
Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libfdisk problem in dinstall
> I was receiving the message "error reading sector 0" all the time, > but cfdisk handled the partitioning just fine, so I expect this is a > problem in libfdisk or dinstall somewhere. That's really strange, since the message is about a real read error. Is something special about the disk or the location of that swap partition? Can you send me the partition layout (fdisk -l)? Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I'm away for a week
I'm on vacation from tomorrow till 04/20, so if something serious should be with my packages, feel free to make non-maintainer uploads. Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dinstall and PGP
> Can someone hack dinstall to install packages which are not PGP > signed but has been copied to incoming? If the UID of the files is > the one of a developer we can know who did upload the package. No, because the upload queues also use known UIDs, but may allow everyone to upload. (BTW, the queues in Erlangen and open.hands.com require the files to be PGP-signed.) Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New required base packages for Amiga, Atari, ... detection
> As in, ISA vs. MCA vs. PCI? :-) No, as in e.g. Intel-PC vs. Sun :-) Ok, you're right that we could leave the user on his own and tell him "just don't install packages you can't make any use of", but I think we can do it better... Aren't dependencies exactly for that purpose? I.e., keep the user installing e.g. a libc6 package without having libc6? Sorry for the bit of sarcasm :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
> Is this any different from Intel packages that only make sense when > you have specific hardware installed? We have several of those. It's not just that you have different hardware installed, but you have a totally different kind of computer... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
> This sounds exactly the same as the i386 vs Pentium thing. It's the
> name BASE architecture but different... implementations?
Yep, sounds similar. I haven't closely followed followed the Pentium
discussion (too much traffic here...), but it's obvious that there are
some parallels.
> One solution could be creating more distributions, like binary-i586,
> binary-atari, binary-amiga, and simlink shared files from, e.g.,
> binary-i586 back to binary-i386. This complicates things a bit,
> since a i386 package has to get an entry on i586, just like an all
> package gets and entry on all the architectures, but only if a i586
> specific package isn't already there. I think it would be the same
> with the m68k stuff. The alphas won't be as easy, I think.
This is possible, but sounds a like bit too much trouble for my
problem. There are currently only two packages for m68k that need this
special treatment. Ok, the number will grow, but it never will be that
much that separate binary-{atari,amiga,..} trees really make sense.
They would consist of > 99% symlinks.
> For the "not really arch-all" part... could overrides be
> used/extended for this? Like in "the package says it's arch-all but
> it's really just arch-i386 and arch-sparc"
I think this is an extension, but don't know exactly. Guy, you know
your scripts better than me... :-) But if it wouldn't be too much
trouble to implement it, it would be worthwile.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
New required base packages for Amiga, Atari, ... detection
There are now some packages for m68k that make sense only on a specific machine type. Currently we have such packages only for Atari, but others can follow easily. The packages are nvram and setsccserial, and atari-fdisk is about to be debianized. Those packages are currently Architecture: m68k, but this alone isn't sufficient, because it still allows their installation on e.g. an Amiga, where they don't make sense at all. Currently the preinst script of such packages makes some tests that the machine really is an Atari (via /proc files), but this isn't the cleanest solution. It would be much better if already dependencies could forbid installation on non-Atari machines (or whatever...). James Troup had a fine idea for this: We could introduce new required and essential packages in the base section, like base-atari, base-amiga, base-mac, and so on. (Those packages won't have any files in them for now, but maybe we have something to include in them in future.) Machine-specific packages then can depend on those base- packages. The appropriate base- package will be included in the base.tgz of the install disk set for the machine, so it will be installed automatically for new installations. For existing installations, the user has to choose the right one... (We could move the /proc based tests to their preinst, to do it only once.) Of course, the packages should be Architecture: m68k, they're useless for other architectures (that don't need distinction between Atari, Amiga, Mac, ...) All the base- packages should conflict with each other, so that only one can be installed. The best way to ensure this would be to create a new virtual package 'base-machine', that all base- packages provide and conflict with. Since policy says that introduction of essential packages and new virtual packages requires discussion on debian-devel, I now ask here if there are any objections to the above. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Why does gcc no longer link .sos with -lc by default?
> The difference seems to be that the gcc on the alpha is linking in
> -lgcc -lc -lgcc, where gcc on the i386 is just doing -lgcc twice.
>
> So which is right, and if it's the i386, since moving to gcc-2.7.2.3
> isn't an option for the alphw, does anyone know enough about specs
> files to be able to suggest what should be done about the alpha
> setup?
The difference is just in the specs, I guess. In the i386 version,
there's something like
%{!shared: ... %{profile:-lc_p} %{!profile: -lc}}
I.e., libc is only linked if -shared is not given. Basically the same
thing is done for m68k and sparc. So I guess that is what is intended.
Don't know why the -lc isn't ommited on the alpha.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
Re: Experiences with compiling Debian
> This will execute /bin/bash[1], and set environmen varable > "LD_PRELOAD" to a libfakeroot.so.0.0. This libfakeroot currently > overloads only chown and lstat[2]. Now, when you type in the thus > executed shell: > > $ chown root:users somefile > > this will call the wrapper "chown" function. this wrapper calls the > real chown, _and_ it sends (via SYSV IPC calls) a message to the > (still running) fakeroot "daemon". This daemon records the new fake > onerships of the file in an internal variable. Looks fine so far! BTW, I guess the daemon is also started by 'fakeroot', right? > - yes fstat and fchown will be somewhat of a problem, but I'll just > have to overlod open() etc too, and keep a list of inodes/filenames. Hmm... to be more exactly: You have to wrap open(), create(), and close(), and have to keep a table of fd -> name mappings for fchown() and fchmod(). > - I probably will go wrong for pathalogical cases like > >ln file1 file2 >chown mail:sys file2 >rm file2 >ls -al file2 > > I doubt whether these are important, and even if they are, I > guess it will be possible to get it right. Ok, it's a really pathological case, maybe we can delay a solution until we need it. I think the way to handle it would be to wrap link() and unlink() calls, too... But that could become a bit more complicated :-( > [2] Well, I've olverloaded lstat all right, but it doesn't seem to > get called don't know why yet. Why would chown() work and lstat() > not? Better also wrap stat() and fstat(), too. Maybe that's the reason. Another possibility is that the shell uses some other library function that indirectly does the stat, and that function uses _lstat or _stat instead of lstat/stat. Then you'd have to wrap those '_' versions, too. A real drawback of this: You then can't call the real functions anymore :-((, you have to write your own versions using the macros from , which isn't very clean anymore. Maybe use gdb on the shell to learn what's going on. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> I think inode->name mappings will be better than fd-> name mappings: > - we have a chance of solving the pathalogical case below > - fd->name mappings are no good, have to be (pid,fd)-> name mappings, > complicates matters: Hmm... I admit you're right here. BTW, why not generally work on (device,inode) pairs instead of filenames? The data structures would be easier to maintain inside the daemon (just numbers, no strings), we wouldn't have to watch for symlinks, and of course hard links are obviously solved. We'd also save wrapping open/close, since inside the fchown()/fchmod() wrappers you can call stat to get the inode numbers, you don't need the name anymore! Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> if you create files and directories as root, you also need to be > root, to delete them. but this is far easier, of course. You shouldn't be root, so you don't create files/dirs as root... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dhcpcd compile problem with libc6
> In file included from /usr/include/linux/if.h:23, > from /usr/include/linux/netdevice.h:30, > from if.c:28: > /usr/include/linux/socket.h:9: redefinition of `struct sockaddr' Seems if.c includes , which in turn goes to . With glibc you should generally prefer the headers in sys to those in linux (the linux header is included by the sys header if needed). Maybe it helps to explicitly include before netdevice.h (since there is no ). If this doesn't help, I'd say it's some inconsistency between glibc headers and Linux headers, which should be reported to the glibc maintainers. (It should be possible to include a header if there's no corresponding header.) A temporary fix could be to avoid reading with #define _LINUX_SOCKET_H. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> Has anyone considered writing a svgalib replacement that simply > translates svgalib calls into X Windows calls? This would allow > those of us with cards that are unsupported under svgalib to still > use svgalib programs, though admittedly at a speed penalty. I haven't yet thought of that :-), but basically it should be possible. Just not that "simple"... I guess it's a bunch of work... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
> Well, I personally distrust cross-compilers...at least gcc cross > compilers. I know that at least one crossover (i386->alpha) has been > known to produce broken binaries at one time, In that case, 32/64 bit stuff has been the cause... > Since you can't actually test the cross-compiled programs you > generated, you never know when you might be uploading something > _really_ broken into stable. > > Cross compilers are very good for bootstrapping new linux ports and > things like that, but I wouldn't want to upload "production > binaries" built by a cross-compiler, and would be _very_ upset to > find that I was using one. I use cross-compiling most of the time for m68k, just because the Intel machines are much faster... But I test the resulting packages on the 68k machine :-) In that case, I think there's nothing to say against cross-compiling... BTW, what really doesn't work with cross-compiling is floating point, due to deficiencies in gcc. But you can avoid problems if you use the standard installed with a cross-gcc. That one just contains an #error, so you'll be notified at compile time. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> If my server is gonna be a "build server", I'd *very* much prefer a > modified dpkg-dev that allows for non-root package builds. > > (in fakt so much, that I may be tempted to write it myself. You > don't need that many changes). AFAICS, the only thing needed to be done as root is the install/chown stuff, right? I see two possibilities for this: Either put in the file owner information into the tar archive directly afterwards (this can be done as a post-processing to the proper tar, and is rather easy [1]), or provide special suid versions of install/chown/... (as needed) just for the install process. These special binaries should be available only for debian/rules, and can check the paths of the files given so that debian/rules can't change owners of arbitrary files, only those under some debian/tmp dir. Ok, I see there are possibly many holes in this scheme... :-( But for the first possibility the problem is how to pass the owner information to the entity the modifies the tar archive... Roman [1]: For some other application, I've once written such a tar-post-processor that changes certain path patterns in the tar archive. It was really easy, the tar format is simple enough... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> Better method: Remove the version from svgalib1g shlibs (as the > other libc6 libraries have done). The version would be needed again > if a new upstream release of svgalib with an incompatible library > arrives, as this seems far from happening this would be a perfect > solution for svgalib, IMO. Yup, removing the version solves all problems :-) Why haven't we had that idea earlier?? Nicolas, you're a genius :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> > dpkg's current dependency mechanism doesn't allow it to be a > > substitute for svgalib, because that is a shared lib and so all > > dependencies on it are versioned dependencies (coming from the .shlibs > > file). > > Well, more to the point: when package foo "Depends" on a particular version > of package bar, dpkg ignores all packages that provides: bar. > (It'll only look at the exact package bar, and it's version). Clear. What I meant with "because it's a shared lib" is that usually all dependencies on a shlib are versioned dependencies, because they come from the .shlibs file. > Well, it isn't the library stuff that goes wrong, it's the specific > versions that cause dpkg to ignore the Provides: packages. That's what I'm saying, isn't it? > Only if the *dpending* packages depends: on a particular version of > the shared lib package. Usually, this isn't the case (the soname of > the library is encoded in the package name, so a package could just > depends: "libfoo272", with 272 the soname of libfoo. But yes, with > the current shlibs files, they will always depend on a particular > version of the library, and it will always go wrong. Yup, that's it. AFAICR, the (>= x.y.z) there has been introduced to avoid that people use too-old shlibs at runtime, which is basically a good thing. > Well, this at least woudn't hurt, I guess. Unless anyone objects > against this, I'll add this to the svgalib1g I'll upload > tonight/tomorrow. That would be fine! Would at least fix the problem for packages that are recompiled with the new glibc version of svgalib. > They have to be rebuilt for libc6 anyway. So that's no problem. You're right here. > I strongly prefer method 1. I really think dpkg should be improved, Me too... > but as that doesn't seem to happen any time soon, I don't think > method 2 will hurt in the mean time. Ok. Any other opinions? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
> Does this mean I could upload all architecture version for my > packages? If so yes, I think it's useful. But if you do that, you haven't tested whether your package is really running on another architecture... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
svgalib-dummy again
Now that svgalib seems orphaned, allow me to come up with this topic again... But first a brief summary of the history and the problems: svgalib-dummy is a dummy replacement for svgalib, which doesn't require any configuration, doesn't spit out messages when initialized by applications, and last but not least, can be used as a substitute on architectures where the real svgalib doesn't exist. Unfortunately, it cannot be easily installed. Though it Conflicts: and Replaces: svgalib1, dpkg's current dependency mechanism doesn't allow it to be a substitute for svgalib, because that is a shared lib and so all dependencies on it are versioned dependencies (coming from the .shlibs file). I now see two solution for this problem: 1) dpkg's dependency handling could be extended so that it knows about versioned Provides:. Then svgalib-dummy could provide "svgalib1 (>= 1:1.2.10-2)" or something similar, and a dependency "svgalib1 (>= 1:1.2.10-1") could be satisfied by this. Not only that this is the most elegant way, it also solves another potential problem: The problem with versioned dependencies doesn't only hit svgalib-dummy, which wants to replace a shared lib, it will also effectively make replacements of any shlib package impossible... Just imagine we sometime want to rename a shared lib, or replace it by another, improved package. This won't be possible without rebuilding the *depending* packages, because providing a shared lib isn't possible... 2) A not-so-nice solution would be to change the .shlibs files of both, svgalib and svgalib-dummy, so that they read libvga1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 libvgagl 1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 This signals that either package is ok for providing libvga.so. The drawback is that all packages depending on svgalib must be rebuilt with an updated version of svgalib to get in this change. This could be handled by first announcing here that those packages should be rebuilt, and if no uploads follow in some reasonable amout of time, I could report bugs against those packages. So, what method do you prefer? Or do you have better ideas? How hard would it be to implement versioned Provides: in dpkg? Or are there other reasons not to implement it? Is solution 2) too kludgy? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Orphaning dftp.
> I'd like to officially offer dftp up for adoption. I don't use it > anymore -- dselect works much better for me now that I came to terms > with it -- and so I don't really have much interest in maintaining > dftp anymore (that and the fact that I have a bunch of other things > I'm supposed to be doing). I'd volunteer for maintaining dftp, at least for a while, if nobody else does. I also have a lot of things to do and not too much time left, but I need dftp for my two machines at home, and there are some things in dftp that really should be done (re-add the .installed file, at least some kind of dependency checking). Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency
I've missed the start of this discussion, but I'm the maintainer of svgalib-dummy, and the issue of dependencies came up already several times... > Are there other people that would like the dependancy change > > - Depends: svgalib1 (>= 1:1.2.10-2) > + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy This would indeed be a fix for the dependency stuff, but only for the package that adds this |svgadummy. To fix the svgalib/svgalib-dummy problems with way, every depending packages would have to be changed similarily. svgalib-dummy indeed has a "Provides: svgalib", but unfortunately this doesn't have any effect... Since svgalib is a shared lib, all packages depending on it depend on >= some version. And such versioned dependencies can't be fulfilled by a Provides: :-(( This is not only a problem for svgalib-dummy (which can't really be used as a proper substitute for svgalib due to this), but it has also other implications: We'll never be able to replace or rename a shared library package! Currently, packages that are to replace an older one (renaming is a special case of this) have fields Replaces: and Provides:. But this works only as long as no other package has a *versioned* dependency on the package to be replaced. I see this as a kind of shortcoming of the dependency checking: It should be allowed to have versioned Provides: fields also (e.g.: "Provides: svgalib1 (1:1.2.10-2)". With that, you also give the version of the other package whose functionality is provided, and some dependency (e.g. "Depends: svgalib1 (>= 1:1.2.10-1)") can be fulfilled. I don't know how difficult this would be to implement in dpkg, but it would be a win not only for svgalib-dummy, but also for the future, in case we'll need to replace a shlib package sometimes... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
> That's why we have the altgcc and the altdev packages. You'll still > be able to compile libc5 programs by just putting > /usr/i486-linuxlibc1/bin first in your path. Just a note to one thing where this doesn't work: Some programs use -I/usr/include/bsd on the command line to get BSD behaviour for certain stuff, e.g. signal handling. But that directory doesn't exist anymore if libc6-dev is installed. This is no problem with libc6 itself, since BSD signals are default there, but SysV semantics are default for libc5. If you now compile such a program with i486-linuxlibc1-gcc, no headers in /usr/include/bsd are found (they're in /usr/i486-linuxlibc1/include/bsd ...) and you get the wrong signal semantics. Just a note, but already happened ... :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
