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 th
> 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 b
> 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
> > 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 so
> 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
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 ru
> 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
> 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 (
> 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
> 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
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]
> 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 qu
> 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 use
> 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:
> 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 solut
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,
> 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
> 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. t
> 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 gen
> 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] .
T
> 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 gli
> 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 :-),
> 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 program
> 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/
> 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, IM
> > 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 versio
> 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
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
> 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
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
> 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
32 matches
Mail list logo
