-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 3 Apr 2005 13:56:55 +0200
Source: dosfstools
Binary: dosfstools
Architecture: source i386
Version: 2.11-2
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 12 Mar 2005 17:19:27 +0100
Source: dosfstools
Binary: dosfstools
Architecture: source i386
Version: 2.11-1
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 29 Feb 2004 16:25:17 +0100
Source: atari-fdisk
Binary: atari-fdisk-cross atari-fdisk-udeb atari-fdisk
Architecture: source m68k i386
Version: 0.7.1-5
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 29 Feb 2004 14:25:53 +0100
Source: setsccserial
Binary: setsccserial
Architecture: source m68k
Version: 0.1-5
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 29 Feb 2004 14:03:33 +0100
Source: nvram
Binary: nvram
Architecture: source m68k
Version: 0.1-7
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL PROTECTED]
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 29 Feb 2004 14:52:20 +0100
Source: atari-bootstrap
Binary: atari-bootstrap
Architecture: source m68k
Version: 3.3-4
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 22 Sep 2003 22:36:55 +0200
Source: atari-fdisk
Binary: atari-fdisk-cross atari-fdisk
Architecture: source i386
Version: 0.7.1-4
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 22 Sep 2003 22:15:32 +0200
Source: dosfstools
Binary: dosfstools
Architecture: source i386
Version: 2.10-1
Distribution: unstable
Urgency: low
Maintainer: Roman Hodek [EMAIL PROTECTED]
Changed-By: Roman Hodek [EMAIL PROTECTED
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
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
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 somewhat
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
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
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 James2 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
graph http://master.debian.org/~wakkerma/graph.png
I guess Nov 2nd would have been the ideal date for releasing slink ;-)
Why the hell we missed that! :-))
Roman
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.
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
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.
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
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]
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
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:
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,
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
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
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
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 linux/netdevice.h, which in turn goes
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] .
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.
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
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
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
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
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
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
39 matches
Mail list logo
