On Fri, Apr 1, 2011 at 10:47 PM, Peter Palfrader wrote:
> > The problem there is you're trying to install and/or upgrade the sid one,
> > not the squeeze one.
>
> No, the squeeze package installed cleanly. now apt-get update &&
> upgrade breaks. That means the package is buggy.
>
Yes, I know i
On Fri, Apr 1, 2011 at 9:58 PM, Peter Palfrader wrote:
> all the other chroots are now fucked because we did as you asked, and
> for some reason it wants to bring in mlton-doc
The problem there is you're trying to install and/or upgrade the sid one,
not the squeeze one.
> I think we won't be
Good afternoon.
I am the maintainer for the Standard ML 97 (SML) compiler mlton. This
compiler is itself written in SML and is self-hosting. Thus, it needs an
older version of the compiler in order to bootstrap itself. Further
complicating things, the build needs in the ballpark of 1-2GB of physic
On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx wrote:
> On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
> > If I may ask, for what purpose do the buildds have a special list of
> > packages above and beyond those in unstable?
>
> So that in case variou
On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:
> Does mlton-basis depend on mlton-runtime or mlton-compiler to build?
>
If the answer is yes, then most likely these should not be three seperate
>
source packages.
>
It's all one source package. I split it
On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx wrote:
> Note that in unstable you don't see the arch arch all version
> until the arch any version is also available. Or you would see
> the old arch all version until the new arch any version is
> available.
>
That's great! My thanks to whomever ha
On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx wrote:
> As long as the Packages file for the buildds mentions this arch
> all package, no buildd can build it, because it only considers
> installing the latest version. But it should get removed
> from that file after 24 or 32 hours or something. I
On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau wrote:
> As far as I can tell the problem is that you switched the mlton binary
> package to 'Architecture: all'. Which means it's available on all
> architectures already in the new version, even though it's not
> installable.
>
Ahh! That makes a
I've read that there was a recent change made to the buildd resolution with
regards to ensuring that consistent package versions are used on the builds
[0]. Is it possible that this changed also messed up self-dependency
resolution?
My package, mlton, has a versioned dependency on itself for versi
I find the buildd logs on https://buildd.debian.org/ to be extremely
useful. They are nicely organized and it's easy to look back in time
and see previous build problems and/or get a quick overview of the
current build status. However, I find there's one piece of data that
is sadly missing: the log
On Wed, Oct 14, 2009 at 10:55 AM, Goswin von Brederlow wrote:
> > * Do the autobuilders build packages uploaded as experimental? (eg: to
> confirm
> > a successful port)
> The experimental autobuilders do. I think not all archs have one.
>
Ok, sounds like I'll have to upload to unstable then afte
The package MLton is a Standard ML compiler which is itself written in
Standard ML. To bootstrap the package building process on a new architecture
requires an initial by-hand cross-compile step (and occasionally some
source-level patching). Thus, the first upload for a new architecture must
be a m
emselves, all power to them.
I just don't want people who don't share to freeload off my work.
I personally hate any kind of algorithm patent, so I wouldn't opt for
that solution. I just included it as an option for completeness.
--
Wesley W. Terpstra <[EMAIL PROTECTED]>
wever, what I want to know is, if this
went to court, would things like the intention and degree of dependency be
considered in determining if the client was a derivative work or not?
What can I do to prevent the above scenario from happening?
Thank you very much for your time!
--
Wesley W. Terpstra
On Sat, Oct 23, 2004 at 12:27:25PM -0600, Gunnar Wolf wrote:
> Wesley W. Terpstra dijo [Mon, Oct 18, 2004 at 09:59:36PM +0200]:
> > At this point my question is only academic; the pure-gcc in main,
> > icc-prebuilt in contrib solution seems to solve my concerns just as well.
>
On Wed, Oct 20, 2004 at 02:06:46PM +0200, Wesley W. Terpstra wrote:
> On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote:
> > Possibly; however, I think bandwidth grows far slower than CPU speed and
> > overall system power. I do understand your concern, though.
>
ot;equivalent access" is
> offered. This is certainly questionable. It would also depend on
> mirroring; for example, if contrib were ever moved to a different server
> (which has been debated in the past), this would become clearly false.
>
> My advice would be this: unless the source is incredibly huge (such as
> with OO.o), then I don't think saving a few tens of MB is worth dealing
> with the questions and complexities this raises.
That's my conclusion too.
Thanks again!
--
Wesley W. Terpstra
is a stream of measurements of some variable. My code can
not presently handle this correctly, but that is future work for me.
I am not a very imaginative person; I am sure there are many other
situations where this could be applied.
From another point of view, research doesn't *need* to be practical. ;)
If other people have ideas, I'd like to hear them.
--
Wesley W. Terpstra
idn't really know why. Now I can explain
it better. The proposal of keeping one version in main and one in contrib
also addresses my concern about usability.
So, I am happy with the outcome of this discussion already. =)
--
Wesley W. Terpstra
On Tue, Oct 19, 2004 at 02:49:09AM +0200, Wesley W. Terpstra wrote:
> find -name testing.part.\* -print0 | xargs -0 parchive a -n 16384 testing.par
After taking a look in the source code for par, I found this in rs.c:
|*| Calculations over a Galois Field, GF(8)
What does that mean? It me
On Tue, Oct 19, 2004 at 02:49:09AM +0200, Wesley W. Terpstra wrote:
> I would wager that par is using the Berklekamp-Masey algorithm for decoding;
That would be Berlekamp-Massey. Appologies to both.
I should add their names to my spell checker. =)
--
Wesley W. Terpstra
On Mon, Oct 18, 2004 at 07:45:39PM -0400, Glenn Maynard wrote:
> On Tue, Oct 19, 2004 at 12:59:42AM +0200, Wesley W. Terpstra wrote:
> > To which, I say, wtf!
> You're using it wrong.
Well thank goodness, b/c otherwise that would be really awful. :)
This gives me a great sou
.
rsgt aims not to add 'parity' as I think 'par'2 is intended to suggest.
Rather, it transforms a file into a stream of user-defined-size packets
which goes on practically forever. ANY of the packets will do to get back
the original file, as long as the sum is the same size.
--
Wesley W. Terpstra
oint my question is only academic; the pure-gcc in main,
icc-prebuilt in contrib solution seems to solve my concerns just as well.
--
Wesley W. Terpstra
made other
> arrangements with its copyright holders, you need to refrain from
> supplying the code or binaries to anyone unless under the GPL.
Oh, that's a good point.
I withdrawl my offer of private pre-release.
You can only have a copy after I publish. ;)
Thank you for your detailed explanation and answer.
--
Wesley W. Terpstra
et
under the GPL. Only after I publish a paper about the algorithm will the
code be released under the GPL.
--
Wesley W. Terpstra <[EMAIL PROTECTED]>
After running into yet two more problems with staged installs ala DESTDIR,
I was reminded of an idea I originally had for fink packages.
... but, let's begin from the beginning.
Why is DESTDIR a problem?
---
1: libtool cannot relink inter-dependent libraries during a staged install.
2: some upst
27 matches
Mail list logo
