I was wondering if you would send me the sheet music for Hazy Shade of
Winter - I want to transpose it for the piccolo, as that is the sexiest
of instruments.
thanks,
Jimmy James
the man so nice
they named him twice.
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote:
> On Sat, 21 Jun 2003, John Goerzen wrote:
> > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > > Note that my idea was about patching the kernel that so the newer opcodes
> > > would be emulated in software. Everyth
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote:
> On Sat, 21 Jun 2003, John Goerzen wrote:
> > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > > Note that my idea was about patching the kernel that so the newer opcodes
> > > would be emulated in software. Everyth
On Sun, Jun 22, 2003 at 11:24:57AM +0200, "Martin v. Löwis" wrote:
> John Goerzen wrote:
>
> >As I say this, I'm sure people can say the same about i486 and even i386
> >machines. Why exactly do we need to remove this support?
>
> Read the bug report with the number you put in your Subject.
Whi
On Sun, 22 Jun 2003, Kevin Edwards wrote:
> I was wondering if you would send me the sheet music for dueling banjoes -
> I want to transpose it for other instruments -
Sorry, can't help you there. I can give you the byte codes for dueling
flamewars, however.
On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> > Many video cards require XFree 4.3.x or above. They require agpgart in the
> > kernel. They require iwconfig and other wireless tools. There are a whole
>
> Tell me, you seriously think that there is a libc5 program still around
>
I was wondering if you would send me the sheet
music for dueling banjoes - I want to transpose it for other instruments -
On Sun, 2003-06-22 at 18:08, Alan Shutko wrote:
> Isaac Jones <[EMAIL PROTECTED]> writes:
>
> > How would Debian prefer to see this? Some people tell me that it'll
> > probably be too slow to build the packages on the end-user's system
> > (as is done for elisp),
>
> That's also done with Commo
On Sun, Jun 22, 2003 at 04:58:09PM +0200, Andreas Barth wrote:
> * Marco d'Itri ([EMAIL PROTECTED]) [030622 16:35]:
> > On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > >There is no technical reason why we can't support libc5 anymore. The only
> > >reason that this is being discussed is that
I'm going to be in Portland, Oregon, for June 22-28. I'll probably have
time for a keysigning and maybe a quick beer if any Debian developers
and/or users are interested. Just drop me a mail if you want to meet
somewhere.
-Brian
--
Poems... always a sign of pretentious inner turmoil.
pgp8Nkl
Isaac Jones <[EMAIL PROTECTED]> writes:
> How would Debian prefer to see this? Some people tell me that it'll
> probably be too slow to build the packages on the end-user's system
> (as is done for elisp),
That's also done with Common Lisp, and I don't think it's too slow
(as an end-user).
--
Package: wnpp
Version: unavailable; reported 2003-06-23
Severity: wishlist
* Package name : matroska
Version : CVS
Upstream Authors : Ludovic "Blacksun" Vialle
Christian HJ Wiesner
Steve "robUx4" Lhomme
* URL : http://www.matr
On Sunday 22 June 2003 19:45, Isaac Jones wrote:
> There has been a lot of discussion recently on the Haskell mailing
> lists about the best ways to package Haskell libraries and tools for
> Debian. The main issues are:
>
> 1) there are a variety of "compiler" implementations, one of which is
> an
On Sun, Jun 22, 2003 at 11:16:54AM +0200, Xavier Roche wrote:
> > this is not a problem due to devpts filesystem.
> Okay, using devfs it works perfectly.
> A remaining problem is also Samba:
> [2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85)
> unable to open or create fil
Mike Hommey <[EMAIL PROTECTED]> writes:
> On Sunday 22 June 2003 19:21, Allan Jacobsen wrote:
>> I have been looking for working j2re1.4 packages for some times, but
>> unfortunatly this does not work for me:
>>
>> isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot
>> dpkg-buildpackage: source pac
Hello,
I noticed a few transitional and dummy packages on my system, but there was
no common way to identify them. I think the following packages exist:
a) dummy packages which depend on the new name of a package for
1 - automatic updates after split or rename (e.g. xpdf-i)
2 - dependencie
On Sun, Jun 22, 2003 at 12:06:16PM +0200, Andreas Barth wrote:
> * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
> > problem here (C++ ABI compatibility with other Linux distributions). The
> > discussion is now about *how* to fix this bug:
> > 1. just bump minimum supported i386-family pr
Greetings,
There has been a lot of discussion recently on the Haskell mailing
lists about the best ways to package Haskell libraries and tools for
Debian. The main issues are:
1) there are a variety of "compiler" implementations, one of which is
an interpreter :)
2) not all Haskell implementati
I have been looking for working j2re1.4 packages for some times, but
unfortunatly this does not work for me:
isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package is j2se1.4-i586
dpkg-buildpackage: source version is 1.4.1.0.1-4
dpkg-buildpackage: source maintainer i
On Sunday 22 June 2003 19:21, Allan Jacobsen wrote:
> I have been looking for working j2re1.4 packages for some times, but
> unfortunatly this does not work for me:
>
> isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot
> dpkg-buildpackage: source package is j2se1.4-i586
> dpkg-buildpackage: source
On Sun, 2003-06-22 at 00:48, Adam Majer wrote:
> I once read somewhere that you should _never_ compile in 486
> optimizations for use in processors other than the 486. Apparently
> since 486 optimized code is padded a lot with NOPs.
>
> Apparently you are much better off on a Pentium or Athlon w
On Sun, Jun 22, 2003 at 02:46:12PM +0100, Andrew Suffield wrote:
> > Apparently you are much better off on a Pentium or Athlon with
> > i386 optimized code than i486 optimized one.
> I vaguely recall something similar about the i586.
FWIK, almost everything that can be done in two ways on ix86, li
* Marco d'Itri ([EMAIL PROTECTED]) [030622 16:35]:
> On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote:
> >There is no technical reason why we can't support libc5 anymore. The only
> >reason that this is being discussed is that nobody has stood up to maintain
> >the package.
> This looks like a
Op zo 22-06-2003, om 13:53 schreef Andrew Lau:
> Hey everyone,
>
> I haven't seen anyone mention this on debian-devel or debian-68k yet,
> so before anymore time is wasted, could someone please take a look into
> kullervo (sbuild/m68k)? Every build the last few days has failed due to
> the followi
On Thursday 19 June 2003 18:36, Thomas E. Vaughan wrote:
> Has anyone else noticed this?
This is due to the fact that Mozilla is now compiled with gcc 3.3, and that
j2re1.3 is still compiled with gcc 2.95 ; both are incompatible.
You can get a working j2re1.4 (blackdown doesn't provide 1.3 compi
> Has anyone else noticed this?
I know that the unofficial j2se1.4 packages consistently crash under
certain conditions when using JNI with C++ code; this is related to the
fact that the j2se1.4 packages are still built using g++-2.95 whereas
the default C++ compiler for debian is g++-3.x.
Don't
On Sat, Jun 21, 2003 at 11:48:26PM -0500, Adam Majer wrote:
> Sebastian Kapfer wrote:
> >I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> >would count...
> >
>
> I once read somewhere that you should _never_ compile in 486
> optimizations for use in processors other than
Thomas Hood wrote:
>No need. It is sufficient that /tmp/ and /dev/ be separate, writable,
>filesystems. It is a local decision whether to make these tmpfs and
>devfs, respectively.
I've successfully run without a writeable dev but with devptsfs. How
much "writeability" is required depends on ho
On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote:
>There is no technical reason why we can't support libc5 anymore. The only
>reason that this is being discussed is that nobody has stood up to maintain
>the package.
This looks like a good enough reason to me.
--
ciao, |
Marco | [1676 advirpG9
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote:
>[2003/06/22 11:13:11, 0] passdb/pdb_smbpasswd.c:startsmbfilepwent(237)
> startsmbfilepwent_internal: failed to set 0600 permissions on password file
> /etc/samba/smbpasswd. Error was Read-only file system
> .unable to open passdb database.
Has anyone else noticed this?
--
Thomas E. Vaughan <[EMAIL PROTECTED]>
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote:
>Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a
>good idea) for future releases?
For your ro-root system: definitely yes. For debian, don't dare.
--
ciao, |
Marco | [1679 corp.qbtCr/Hg]
On Jun 22, Thomas Hood <[EMAIL PROTECTED]> wrote:
>The question is: Should we concede that a separate /dev/ fs is
>required for running with a read-only root filesystem, or should we
>take steps to eliminate fiddling with /dev/ files? I haven't
Yes. Consoles *must* have their ownership changed
On Sun, 2003-06-22 at 11:52, Xavier Roche wrote:
> Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?)
> allows you not to resevre space for /tmp on a specific partition
Remark added.
> > The question is: Should we concede that a separate /dev/ fs is
> > required for running w
On 2003-06-22T21:53:01+1000 (Sunday), Andrew Lau wrote:
> I haven't seen anyone mention this on debian-devel or debian-68k yet,
> so before anymore time is wasted, could someone please take a look into
> kullervo (sbuild/m68k)? Every build the last few days has failed due to
> the following fatal
On Sat, Jun 21, 2003 at 12:26:52PM -0500, John Goerzen wrote:
> Why not just ship an old binutils/gcc to build the old libc5 binaries?
> I really don't understand why this is such a difficult problem. If, for
> instance, gcc 2.7.2 could build these things three years ago, why can't it
> now? It'
Andreas Barth wrote:
> * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
>
>>problem here (C++ ABI compatibility with other Linux distributions). The
>>discussion is now about *how* to fix this bug:
>>1. just bump minimum supported i386-family processor to i486
>
> 1a. like 1, but just for
On Sun, Jun 22, 2003 at 11:52:45AM +0200, Xavier Roche wrote:
> > To tell the truth, I didn't realize that so many files in /dev/
> > were being fiddled. Obviously, one solution to the problem is
> > to have a separate writable /dev/ filesystem, e.g., devfs.
>
> Note that devfs is still "experime
On Sun, Jun 22, 2003 at 11:32:57AM +0200, Thomas Hood wrote:
> On Sun, 2003-06-22 at 01:02, Xavier Roche wrote:
> > There are other problems : for example it seems that the system
> > changes the /dev/ttyXX or /dev/pts/XX ownership depending on who is being
> > logged in..
>
> To tell the truth
* "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
> problem here (C++ ABI compatibility with other Linux distributions). The
> discussion is now about *how* to fix this bug:
> 1. just bump minimum supported i386-family processor to i486
1a. like 1, but just for c++-packages.
> 2. like 1, but
Hi all,
I feel this whole discussion is somehow going into the wrong direction. What
does it matter now whether we drop support for i386 and i486 (and possibly
more), or just i386? Sooner or later we'll have the same problem (of changing
the arch support being so difficult) again, if not with
> To tell the truth, I didn't realize that so many files in /dev/
> were being fiddled. Obviously, one solution to the problem is
> to have a separate writable /dev/ filesystem, e.g., devfs.
Note that devfs is still "experimental" in 2.4
Another remark for the HOWTO : mounting /tmp in "tmpfs" (s
On Sun, 2003-06-22 at 01:02, Xavier Roche wrote:
> There are other problems : for example it seems that the system
> changes the /dev/ttyXX or /dev/pts/XX ownership depending on who is being
> logged in..
To tell the truth, I didn't realize that so many files in /dev/
were being fiddled. Obvio
John Goerzen wrote:
While we're at it, I fail to see the logic of removing support for i386
while we still support m68k.
Because there is a bug that only applies to i386 (see the subject). I
wish everybody would focus on fixing this specific bug. There may be
many good or bad things that can be s
> this is not a problem due to devpts filesystem.
Okay, using devfs it works perfectly.
A remaining problem is also Samba:
[2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85)
unable to open or create file /etc/samba/MACHINE.SID. Error was
Read-only file system
So actually s
John Goerzen wrote:
As I say this, I'm sure people can say the same about i486 and even i386
machines. Why exactly do we need to remove this support?
Read the bug report with the number you put in your Subject.
Regards,
Martin
On Sunday 15 June 2003 17:39, Marc Wilson wrote:
> On Sun, Jun 15, 2003 at 11:23:34AM +0200, Stefano Zacchiroli wrote:
> > What about a version _with_ all non-threaded interpreters, but _without_
> > gtk2/kde support?
>
> That would be console Vim, from either package. The GUI doesn't add so
> muc
Le sam 21/06/2003 à 19:26, John Goerzen a écrit :
> > You, and rest of the minority who use libc5 program, can dual-boot
> > an older distribution of Debian (say potato) where the programs still
> > work. Yes, it can be a hassle, but it works.
>
> Assuming it supports your hardware. Which it is n
On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> Tell me, you seriously think that there is a libc5 program still around
> that uses DRI ? Hell, libc5 was abandoned well before DRI even existed.
the only libc5 program I do use is netscape 4.77 because it is compatible to
some pages w
On Sat, Jun 21, 2003 at 12:37:21PM -0500, John Goerzen wrote:
> On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote:
> > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support
> > for 386 and 486, I'd love if I could keep my home edgge router running the
> > way it
On Sat, Jun 21, 2003 at 12:26:52PM -0500, John Goerzen wrote:
> On Thu, Jun 19, 2003 at 09:43:23PM +0200, David Weinehall wrote:
> > Alternative 1:
> >
> > You, and rest of the minority who use libc5 program, can dual-boot
> > an older distribution of Debian (say potato) where the programs still
>
Hi all,
I'm trying to package duali "an arabic spell checker" www.arabeyes.org
currently i'm having a small problem
there is duali itself and the data files.
the db files are built from the data files using a python script.
the upstream wants 2 things:
the script used to build the db files to be mo
On Sat, 21 Jun 2003, John Goerzen wrote:
> On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > Note that my idea was about patching the kernel that so the newer opcodes
> > would be emulated in software. Everything would still work even on a 386,
> > just slower -- and the speed d
John Goerzen <[EMAIL PROTECTED]> wrote:
>
> Why not just ship an old binutils/gcc to build the old libc5 binaries?
There is no technical reason why we can't support libc5 anymore. The only
reason that this is being discussed is that nobody has stood up to maintain
the package.
--
Debian GNU/Lin
>> But why at the end of http://home.tiscali.cz:8080/~cz210552/aptrsync.html :
>> # Get anything we missed due to failed rsync's. [EMAIL PROTECTED] 24 Mar
>> 2002.
>> os.system('apt-get update')
well, it seems for me this just starts apt-get getting everything all
over again, http_proxy or not.
Sebastian Kapfer wrote:
I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
would count...
I once read somewhere that you should _never_ compile in 486
optimizations for use in processors other than the 486. Apparently
since 486 optimized code is padded a lot with NOPs.
Appare
56 matches
Mail list logo
