Bug#477498: general: Unmounting network filesystems solution (for me at least)
Package: general Followup-For: Bug #477498 Similar to original report, my system would hang on shutdown / reboot due to inability to unmount network file systems (network was already taken down). /etc/init.d/umountnfs.sh is written such that when called with argument 'start' it does nothing. It does the unmounting when called with argument 'stop' In runlevels 0 (shutdown) and 6 (reboot), umountnfs.sh is the link target of S31umountnfs.sh - hence it gets called with the 'start' argument and does nothing. Renaming the links to K31umountnfs.sh (so that the script is called with 'stop' argument) solved the problem for me. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PHP] Placement of PHP programs?
On Mon, Sep 02, 2002 at 05:30:13PM -0700, Ian Zimmerman wrote: > Well, I have always held (right or wrong) pretty much the opposite > view to yours: /var/www _is_ for Debian content, and local content > belongs in /usr/local. (thats why you don't see all that much in my > /var/www :-] ) IMO this is wrong, too. Local variable content should go to /var/local. Alex -- Janusz A. Urbanowicz, stomil at jabber.org, PGP 0x21939169
Re: New maintainer process
On Fri, Nov 22, 2002 at 04:10:39PM +0100, Martin Michlmayr wrote: > > Never underestimate the power of Google's cache. :-) > > Google's cache was unfortunately out of date, too. So, while we > haven't lost everything, we have certainly lost the last few > months/weeks. I will post an announcement when I know more. In the what about www.archive.org? alex -- C _-=-_ H Janusz A. Urbanowicz, stomil at jabber.org, PGP 0x46399138* ; (_O : --- --+~| ! &~) ? PÅynÄÄ chcÄ na WschÃd, za Suez, gdzie jest dobrem kaÅde zÅo l_|/ A ~-=-~ O Gdzie przykazaÅ brak dziesiÄciu, a piÄ moÅna aÅ po dno; |
Re: gpg-agent?
On Wed, Nov 27, 2002 at 03:19:37PM +0100, martin f krafft wrote: > where can i find gpg-agent? is it packaged for debian? if not, then > i'll file an ITP unless someone has valid things to say against that. there are packages by Marcus Brinkmann on ftp.gnupg.org, and I'm working on adapting those to debian (with Marcus' permission). alex -- C _-=-_ H Janusz A. Urbanowicz, stomil at jabber.org, PGP 0x21939169* ; (_O : --- --+~| ! &~) ? PÅynÄÄ chcÄ na WschÃd, za Suez, gdzie jest dobrem kaÅde zÅo l_|/ A ~-=-~ O Gdzie przykazaÅ brak dziesiÄciu, a piÄ moÅna aÅ po dno; |
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998, Alan Cox wrote: [..] > A BSD license would have solved the problem nicely. No GPL code would have > been available to "be stolen" (subject to your license viewpoint) and no > GPL authors upset. And we'd all probably be better off. > And by now Sun would no doubt be shipping a binary only KDE that forbid > you to redistribute it and contained fixes you couldnt get back off them Ehm, the world hasn't gone to hell because not everything is GPL. Take for instance companies using FreeBSD, such as Whistle and Best Internet Communications. Both have tweaked fbsd throughly, and "kicked back" quite a few fixes and their other changes, without being legally obligated to release all of their source. Keep in mind it would be in Sun's best interest to help the KDE developers, as taking a BSD licensed KDE and running with it themselves would take a lot more effort. Your "the world outside of GPL is evil" attitude is quite bogus. - alex
Re: LICENSES [was: Re: Have you seen this?]
On Sat, 10 Oct 1998, Alan Cox wrote: [..] > And lots of people haven't kicked stuff back. Why doesn't *BSD run on an > SGI Indy - its because the BSD license didnt force all the neat stuff > to be contributed back. And there are thousands of other examples like it. I fail to see how this is all that much different from the GPL perhaps scaring off a comercial entity from contributing code. Of course I don't have a specific example off the top of my head :) > > Your "the world outside of GPL is evil" attitude is quite bogus. > > I don't know where you got that from. But its not my attitude. I get that feeling from this whole thread, but perhaps that's just me. - alex
Re: Please give a test to cron package, in experimental
Thank you for bringing this up @Georges ! I would like to add, that generally it is a bit confusing that you don't restrict merge requests against master on https://salsa.debian.org/ to maintainers, since the preferred way for contributors seems to be a patch/diff on top of a already patched repository. Having a discussion about a patch/diff can be much more cumbersome than having a discussion in a MR, directly on the related code lines. So I wonder why you don't just provide an additional branch "master-patched" against which merge requests can be opened without the risk of causing conflicts with existing patches. IMO that could ease the life of contributors and maintainers (You don't need to press "merge" when done .. gitlab always provides */merge_requests/408.patch, so you still could rely on patches) (And ofc it would be great to use gitlab issues, instead of bugs.debian.org ... though that's a different story) Sorry, it might be a bit off-topic, just wanted to throw in my 2cent, from a contributors POV. Cheers, Alexander Schwinn Am 08.10.23 um 13:54 schrieb Georges Khaznadar: Hello, I began to maintain cron (https://tracker.debian.org/pkg/cron) a few months ago, and lowered the bug report count by a few dozens, began also to write a few autopkgtests for it, and made it easier to test cron, by providing a possibility to run cron tasks immediately (not after a one minute wait) While discussing about bug report #830821 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830821), it appeared that Alexabner Schwinn wanted to contribute, but was not at ease with the packaging scheme which exists currently with cron package, in our distributions stable, testing and unstable : we are maintaing a big heap of patches to apply to Vixie's cron source version 3.0 (this latter is no longer available from Internet). The difference of difficulty is between: -8<--- ... hack something $ git commit -m "my awesome contribution" $ git diff HEAD^ and - $ export QUILT_PATCHES=debian/patches # if you're no debian maintainer $ quilt push -a $ quilt new my_awesome_contribution.patch $ quilt add , ... ... hack someting $ quilt refresh $ quilt pop -a $ git commit -m "my awesome contribution" $ git diff HEAD^ $ -8<--- Everyone can see that the second sequence is rather tricky for a volunteer contributor, and results probably from the history of cron's maintenance, which began far before our usage of version control systems (Vcs). So, I am trying to create a new upstream cron package, which is made from Vixie's cron version 3.0, with all of the debian patches applied, and packaging it; which results in a debian release 4.0-1, now uploaded to experimental. All of the comments which came with the headers of every patch are now included in Git's log, which preserves authorship information. If you have some free time, please can you give a try, or just share your thoughts about this change ? I intend to push version 4.0 to debian/sid shortly if we can agree. Best regards, Georges. OpenPGP_signature Description: OpenPGP digital signature
Bug#1081611: ITP: terminaltexteffects -- terminal visual effects engine, application
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: terminaltexteffects Version : 0.11.0+ds Upstream Authors: project> URL : https://github.com/ChrisBuilds/terminaltexteffects * License : MIT Description : terminal visual effects engine, application This is a terminal visual effects engine. TTE can be installed as a system application to produce effects in your terminal, or as a Python library to enable effects within your Python scripts/applications. TTE includes a growing library of built-in effects which showcase the engine's features.
Re: just making sure we're all really this quiet
> > > Is it me, or are the Debian lists really quiet? My secondary list server > hasn't transferred a single thing from the primary server in several > hours, perhaps even a day. > > Am I crazy, or did I break something? No you are not. During the last 24 hours I received only 2(!) debian lists-related messages. And one was actually reply on my message posted a few days ago (doesn't really count since it was replied directly to my address) and YOURS!! I tried to resubscribe to the different e-mail address several hours ago and didn't get even automatic confirmation. So I guess something really happend to the lists. Alex Y. > > I think I should suggest that we remove all of the editors except ae from > the entire Debian project, just to rekindle our classic flame war (and > verify that people are really out there!). > > If you've made any recent posts (within 24 hours) and haven't seen them > come through, please let me know so I have something to look for. Thanks! > > Pete > > -- > Peter J. Templin, Jr. Client Services Analyst > Computer & Communication Services tel: (717) 524-1590 > Bucknell University [EMAIL PROTECTED] > > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian 1.3 and "alien"
Hi. In 1.3 release announcement Debian compatibility with rpm and Slackware packages mentioned 2 times. And one time it explicitly states that it is achieved via enclosed utility to convert mentioned packages to Debian format. (This is "alien", right? :) How can we cope with the fact that Slackware support of the Bo release of "alien" is broken then? Thank you. Alex Y. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
jdk1.1 - no dynamic Motif linkage package
Jim, why didn't you upload shared Motif library version of jdk1.1-runtime? I just wonder if there is any reason for that. Thanks. Alex Y. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
> Okay, so say some random person who has installed Debian wants XEmacs 19.15
> because he needs some feature. This seems like a reasonable request... He
> could get it from the Hamm distribution, except that would mean he'd need
> libc6...and he doesn't want to do that, because he's heard that it will
> affect the stability of his system.
>
> What then can he do besides compile it himself? If the answer is only
> compile it himself...is there a way we can add a special update directory
> for 1.3, that will have later versions of programs, and people can
> optionally tell dselect to look there?
>
> Or am I missing a big part of the picture?
>
> Thanks,
> Sam
That is exactly what I posted on the list a few days ago. Unfotunately
there was the only response (from Brian White -- thanks). I proposed to
have "unsupported" directory with the updates of this kind which would not
officially belong to the Debian 1.3.* .
The most solid ground not to switch to libc6 is not instability from the
user's point of view (may be libc6 is not that bad), but from the point of
view of developer who's using different kind of commercial developmental
suits.
Unfortunately, as far as I can see, there is no clean way to
have both developmental trees (libc5 and libc6) on the same machine.
And what even more unfortunate, Debian's goal does not seem to have
a good "transformation period system", where ALL tricky points of two
libraries coexistence are resolved, but to switch EVERYTHING to libc6
as soon as possible. The only outcome of this would the loss of quite a
few serious developers for Debian's community.
Thank you,
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
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
> > I'm not entirely certain I see why we need to remove libc5 packages from
> > the system for Debian 2.0. While I agree that the primary packages should
> > really be glibc, I don't see how a few lib5 packages are going to hurt the
> > distribution
>
> Well, they won't hurt much, but they would:
>
> - make memory usage less favourable (if you're running a mix of
>libc5/libc6 binaries, you'll have both in memory).
> - make Debian look less attractive (We wouldn't appear in the
>list of distributions that are fully libc6).
Could you please point me to such a list?
Anyways, Debian just can't compete with commercial distributions which can
allow to suppose that they are self-contained. Debian is NOT. Unlike
RedHat (which has, for instance its "own" Motif and Metro-X), we can't
include ANY commercial product into the distribution.
They could recomplie them and have "fully libc6" distribution in a day.
There is a big world outside Debian, and the only way to compete is to
provide as much flexibility as possible. Yes, Debian must migrate to
libc6 ASAP, but it shouldn't just cut off the "conservative" part of the
users (they won't be back) and provide FULL choice for both environments.
Thanks.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
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
> Of cource, there isn't such a list now (as far as I know, at least I
> guess that list would be empty now).
>
> > Anyways, Debian just can't compete with commercial distributions which can
> > allow to suppose that they are self-contained. Debian is NOT. Unlike
> > RedHat (which has, for instance its "own" Motif and Metro-X), we can't
> > include ANY commercial product into the distribution.
>
> So, why does that mean we cannot compete?
> What has self-contained to do with Motif?
By self-contained I meant that *most* of the "users" of the particular
distribution would not need to install anything from outside of it.
The nature of Debian implies that ALL commercial products, even the
the most popular ones (like Motif) are outside of the distribution and has
to be purchased seperately. And once purchased, you can't just recompile
them with new library, you kinda stuck with them and expect that
distribution you've chosen (Debian) would still support you and provide
you with recent versions of other "free" developmental software.
Thanks.
Alex Y.
>
> Anyway, Lars just posted a script to auto-build the whole distribution,
> and I really think with such scripts (presumably improved ones, but
> the one from Lars apparently already works) we will get a self-contained
> distribution rather soon.
>
> > They could recomplie them and have "fully libc6" distribution in a day.
>
> Wait and see what Lars will do.
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Debian target audience
Hello all.
Some time ago there was a posting on the list stating that typical Debian
user is of SysAdmin type. The guy received a lot of negative responses and
as a result we have now dotfile-generator in the distribution as our
statement of being friendly to novices. Good thing, but what is Debian
target audience anyway?
Let's get serious, office worker would rather go with Caldera (if Linux at
all), ISP - with FreeBSD, newbie - with RedHat, etc. Debian is the effort
of a large number of developers and primararily *for* developers. No, we
don't forget newbies (dotfile-generator), office workers (Freedom
Desktop), ISPs (ongoing MTA discussions) but we DID forget dvelopers. Here
is why:
1) Every developer using commercially available libraries is forced to
stay with libc5 developmental tree for a while.
2) Every developer (even one NOT using commercial products) is interested
in having recent versions of the freely available libraries.
3) Every user (including developers) is interested in having recent
versions of freely available applications (editors, debuggers, viewers,
etc.)
4) It is preferable for everyone to have only one runtime library (either
libc5 or libc6). Having applications using both does eat up memory and
slow down system. (that's why we are having deadlines for converting
libc5 packages in hamm )
5) In the situation with libc5 -> libc6 transfer developer stuck
with libc5 will not be available to enjoy goddies from the 2)!!!, 3) and
4) because all new software will be compiled against libc6.
I hope you agree that situation is not acceptable. My proposition, which I
already stated, is to have in addition to "stable" and "unstable"
something called "unsupported" where would all newly available packages
(and versions) compiled against libc5 be placed. There were offers to make
sevral systems with good network connection available for compilation
libc6 and libc5 packages for the debian maintainers. (Thanks, guys) And I
think this could really help.
Thank you.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
>
> Alex Yukhimets:
> > Debian is the effort of a large number of developers and primararily
> > *for* developers.
>
> I disagree. I think Debian is for anyone who wants a good Linux
> system, and who doesn't need much non-free software.
^^^
That was exactly my point. Why should Debian cut off those
who *does* need non-free software? Especially developers.
>
> I don't agree that having both libc5 and libc6 run-time libraries
> in use at the same time is important enough to burden ourselves
> with duplicate packages.
The problem of having both libc5 and libc6 run-time libraries is minor,
the main one is that those stuck with libc5-dev cannot use other
newly-available versions of *libraries* from hamm.
Thanks.
Alex Y.
>
> I don't mind if someone maintains separate libc5 packages, but it
> should not be the project.
>
> --
> Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me.
> Please don't Cc: me when replying to my message on a mailing list.
>
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
> > The problem of having both libc5 and libc6 run-time libraries is minor,
> > the main one is that those stuck with libc5-dev cannot use other
> > newly-available versions of *libraries* from hamm.
>
> How do you mean? You can install the *libraries* just fine, it's just
> the development versions that fail to install.
That's exactly what I meant, sorry if it wasn't clear.
>
> And even then, why not install lib5-altdev? Then there is no problem
> whatsoever.
>
I am sorry to say, but you are wrong. Even on this list there were
several postings regarding this matter. There are several known
problems and who knows how many unknown. You just can't afford to
experiment with "production" system this way. Anyway, I could take some
burden on myself to compile libc5 counterparts, but on my 486DX2/66 with
2k/sec connection it would take years.
Alex Y.
> --
> joost witteveen, [EMAIL PROTECTED]
> #!/usr/bin/perl -sp0777i $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> #what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
> On Jun 16, Alex Yukhimets wrote
> >
> > I am sorry to say, but you are wrong. Even on this list there were
> > several postings regarding this matter. There are several known
> > problems and who knows how many unknown. You just can't afford to
> > experiment with "production" system this way. Anyway, I could take some
> > burden on myself to compile libc5 counterparts, but on my 486DX2/66 with
> > 2k/sec connection it would take years.
>
> Well, if it really is a production machine (people yell if it goes down,
> etc.) shouldn't it be tracking stable instead of unstable anyways? I don't
> think that kind of change (libc5 -> libc6) can't be made without some
> amount of instability and experimenting well, unless we get only
> perfect developpers who recompile all their packages for libc6 at the same
> time. :)
>
> Christian
>
Very good point, I can't agree more. That's what we expect from the "hamm"
release: ALL packages recompiled with libc6. The only problem that
commercial software won't be recompiled (or at least upgraded -- $$ issue)
by that time. And of course, that would prevent to install hamm.
Which means that I would be in situation equivalent of using "rex" NOW.
What answer would I get on the bug report against rex package? --
"It was fixed long time ago, upgrade to ...3.45-5.deb from bo".
And it is fine, 'cause bo and rex are based on libc5, but if I'll be using
bo at the time hamm is released I wouldn't have this possibility.
That's why I would really encourage Debian community to behave more like
respectable commercial distribution and give "customer" a choice:
to install libc6 hamm OR have at least some support for bo while hamm is
"stable".
Thank you.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
dpkg-source problem ?
Hello,guys.
At some point I found that when I try to execute dpkg-source -x *.dsc
(for the most recent ddd in hamm) I got the error message:
dpkg-source: error: diff contains unknown line `\ No newline at end of
file'
What could be the reason for that?
And more, executing it on hello (!) package (from bo), I get:
dpkg-source: extracting hello in hello-1.3
dpkg-source: failure: remove patch backup file
hello-1.3/debian/substvars.dpkg-orig: No such file or directory
I am using dpkg-dev 1.4.0.17
Thank you.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
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
pgpxvBvJPfRN3.pgp Description: PGP message
Re: Documentation Policy
> Option 3: We ship .texi files and produce HTML and/or info files on
> demand (in the postinst script).
>
> Advantages:
> - No work for the maintainers.
> - Great flexibility (the sysadmin could even produce PostScript
> files when needed!).
This is extremely good idea.
Possibility to have a hard copy of a ducumentation is a big plus!
Not saying that having document source is also not that bad.
>
> My prediction is that while a few people will like option 3) very much, it
> will be unacceptable by a few others. (People usually don't want to
> compile docs when installing a firewall :-)
So we should have an option not to compile *during* install.
Are there any utilities to get plain text documentation from .texi ?
It might take much less time then.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
> On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote:
>
> > What about the motif-dummy thingie we discussed? How can I run plan having
> > Motif and not lesstif installed? Can you make sure it doesn't Depends: on
> > lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a
> > to-be-created-dummy package for Motif owners, would provide. Is that doable?
> > CC'ed this to the virtual-package-list maintainer for comments.
>
> That's a good idea! AFAIK, Motif 1.x and 2.x are quite different.
> Shouldn't we use two different virtual package names for these major
> versions? (You can't use "versions" of a virtual package, yet.)
>
I don't think that support for different Moitfs are needed.
All known software despite of being compiled with Motif 2.0 does not
use features not present in Motif 1.2
The reason for this is that "big unices" does not have Motif 2.0 actively
shiped from the vendors yet and using Motif 2.0 features would make your
application imposible to port. *When* situation changes, I don't think
that anyone using Motif for i386 Linux would have Motif 1.2
(And franckly speaking, 2.0 also. By that time all vendors will be
shipping 2.1 which would _hopefully_ be compiled against glibc for Linux)
Alex Y.
> Thanks,
>
> Chris
>
> -- _,, Christian Schwarz
>/ o \__ [EMAIL PROTECTED], [EMAIL PROTECTED],
>! ___; [EMAIL PROTECTED], [EMAIL PROTECTED]
>\ /
> \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22
> BA
>\ / http://fatman.mathematik.tu-muenchen.de/~schwarz/
> -.-.,---,-,-..---,-,-.,.-.-
> "DIE ENTE BLEIBT DRAUSSEN!"
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
> > I don't think that support for different Moitfs are needed.
> > All known software despite of being compiled with Motif 2.0 does not
> > use features not present in Motif 1.2
> > The reason for this is that "big unices" does not have Motif 2.0 actively
> > shiped from the vendors yet and using Motif 2.0 features would make your
> > application imposible to port. *When* situation changes, I don't think
> > that anyone using Motif for i386 Linux would have Motif 1.2
> >
> > (And franckly speaking, 2.0 also. By that time all vendors will be
> > shipping 2.1 which would _hopefully_ be compiled against glibc for Linux)
> >
> > Alex Y.
> >
>
> But things linked against Motif 2.0 cannot link against and run with a
> Motif 1.2 library. Take for example nedit-dmotif, currently in
Not true.
> contrib. Try to run it on Lesstif and it won't work, because it will
> not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib.
Yeah, but Lesstif was not meant to be *binary* compatible with real
Motif, only *source code* compatible!
Alex Y.
> When I compiled nedit, I used a Motif 2.0 library. I agree with
> Chris that we should have both a motif12 and a motif20 virtual package.
>
> -Erik
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: jdk packages
> Whats the difference between the jdk packages and the jdk1.1 packages? I
> just found both in the archive.
Well, jdk packages represent jdk 1.0.2, the other -- jdk 1.1.1
Java interpreter is 2 times faster in 1.1.1 plus much expanded API, but it
is new and only a few browsers support it.
Though description claims that you can have both packages installed and
being used, you will have to fix some scripts which come with the package
(most notably /usr/bin/appletviewer-jdk) to make it happen.
Installing either one will probably work without a problem.
Alex Y.
>
> Michael
> --
> Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
> [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
> [EMAIL PROTECTED] | 52146 Wuerselen
> Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
> Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
> On Mon, 23 Jun 1997, Alex Yukhimets wrote:
>
> [snip]
> > > contrib. Try to run it on Lesstif and it won't work, because it will
> > > not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib.
> >
> > Yeah, but Lesstif was not meant to be *binary* compatible with real
> > Motif, only *source code* compatible!
>
> Is this true? Then there would be no reason to create the "motif-libs"
> virtual packages! (The only use for them would be to allow drop-in
> replacements of the compiled shared library packages.)
Yes, but... have we meant anything else?
I don't know how usefull would be the virtual package, but having
"dummy" motif (which provides run-time libs AND mwm) and motif-dev
packages would be nice.
Alex Y.
>
>
> Thanks,
>
> Chris
>
> -- Christian Schwarz
> [EMAIL PROTECTED], [EMAIL PROTECTED],
> Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED]
> for a logo! Have a
> look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22
> BA
> athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/
>
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
> On Mon, 23 Jun 1997, Philippe Troin wrote:
>
> > On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
> > ([EMAIL PROTECTED]) wrote:
> >
> > > Option 3: We ship .texi files and produce HTML and/or info files on
> > > demand (in the postinst script).
> >
> > I like this idea a lot. I *hate* having to fetch the source package
> > to produce a postscript output...
>
> This is a very different issue.
>
> I don't like the idea of producing .info files or .html files on demand.
> The purpose of a Linux distribution is to give a complete system, so that
> the user should not have to do anything by him/herself, nor waste CPU
> time.
>
> I realized that my earlier idea (foo-doc-ps and foo-doc-dvi) had a
> failure: .ps and .dvi documents are location-specific, american will like
> letter size, while european people will want a4 size.
Well, shipping everything in letter format wouldn't hurt much - it is
still possible to print on a4 paper (but not vice-versa).
>
> But I still dislike automatic building. If you just want not having to
> fetch the source package, what about a foo-doc-texi binary package (on a
> "do whatever you want with it" basis), which just ships the .texi source?
That would be the best, but what to do with html-info issue anyway?
In my opinion, both should be dropped out in favor of these doc-texi
packages, but I don't think that we will come to agreement on this.
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
> The reason we need virtual packages is so that we can allow people who
> (like myself) have gone out and bought real Motif to use it on Debian.
> I would be glad to throw away my Motif CD, and only use Lesstif. Last
> time I tried compiling Nedit against lesstif, the results were almost
> usable, but still disappointing. I am getting a new computer (K6-200)
> to replace my old 486, and I plan on compiling Nedit against the latest
> Lesstif again. If it works, i will upload it (and we can get it out of
> contrib). I still plan on compiling a statically linked version against
> REAL Motif though (for those who want everything to work perfectly).
> I don't believe Lesstif is quite ready for primetime. Regardless, since
> there are two versions of Motif, with different Library names that are
> not compatable (sure, you can recompile but they are not binary compatable),
> we need both motif12 and motif20 virtual packages. Lesstif should be
> modified to provide motif12. For other people that have commercial Motif,
> we need to have TWO motif dummy packages. Or one that provides both
> virtual packages...
O.K., First of all, Lesstif does *not* provide even motif12, it is NOT
binary compatible with real Motif 1.2 . As for the binary compatibility
of *real* motif 1.2 and 2.0, could anyone who have runtime package of
Motif 1.2 installed try to install and run nedit-dmotif. Anyone???
It was claimed by OSF that thay are binary compatible, but who knows...
Alex Y.
>
> Just my $0.02,
>
> -Erik
>
> --
> Erik B. Andersen Web:http://www.inconnect.com/~andersen/
>email: [EMAIL PROTECTED]
> --This message was written using 73% post-consumer electrons--
>
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: Documentation Policy
> MB> Why should we ship info files? HTML is better format. The most
> MB> system will use HTML as their help system in the future. KDE for
> MB> example uses HTML.
>
> The Info format is a lot better, tecnically, than HTML. That's what
> I've heard. Maybe the problem is that there is no Info browser that
> satisfies the non-Emacs adepts.
>
> Just because a lot of people prefer HTML, does not mean it's better.
> So, we have to choose: the better or the most popular.
People usually have this kind of choice when deciding which Linux
distribution to pick (Debian or RedHat :), but note, they have the
*choice*. The best way is to give user the choice at that point
(and ship .texi or SGML sources) but if this is considered technically
difficult to compile the proper documets on the fly, well, then I would
vote for HTML. It is not only most popular, but also *very* flexible
with all kinds of CGI scripting, MIME processing, etc.
BUT... *Do not drop (or convert to HTML) usual man pages*
It is the least featurefull way of browsing documentation, but it is
the fastest na dmany people got accustomed to it.
Thanks.
Alex Y.
>
> --
> Emilio C. Lopes <mailto:[EMAIL PROTECTED]>
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: How about e2compr? Was: fixhrefgz debate
> I am really irritated by such insistence on a view "my box at home" and
> nothing
> else matters. We are not all just hacking for fun at home. Some people
> actually
> make their living with the stuff.
>
I completely agree with you. But this is just some kind of a Debian
"sickness" not to think of this kind of users. I don't understand why we
should pay more attention to the "play at home" Un*x newbies than to the
people who are trying to "make their living with the stuff".
Please, think about it guys.
Alex Y.
P.S. Yes, I *am* that kind of user.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: fixhrefgz - tool for converting anchors to gzipped files
> Moin Christoph!
>
> CL> 200Mhz Pentiums are the standard fare today. And I am running
> CL> the boa webserver for example on some low memory 486DX66s with
>
> I'm using a 486/100 and a 486SL/33. In my opinion we should avoid using
> the server to uncompress the files. We should find another solution.
>
> CL> excellent performance. Boa serves directly from disk unless
> CL> there is the need to gunzip something.
>
> Right, but does all WWW server offer this feature? We can't force the user
> to install a specific server.
Why not? This could be a part of Debian documentation system.
The only restriction would be to run it on unconventional port
and preferably from inetd.
Alex Y.
>
> CL> The big issue here is that you want to change an existing
> CL> very public API (http protocol) to include compression which
> CL> may be a big hassle to install on many platforms and so far
> CL> has not been an issue on the more popular platforms such as
> CL> Win95 or other Unixes.
>
> I don't see the problem. The online help system should be designed for the
> Debian users. If a Windows, MAC, etc user want to use the help systen he
> has to install gzip as helper application.
>
> But maybe we would build a compressed file system using gzip and the loop
> back device?
>
> cu, Marco
>
> --
> Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15
> Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: fixhrefgz - tool for converting anchors to gzipped files
> Am 29.06.97 schrieb aqy6633 # is5.nyu.edu an Marco Budde ...
>
> Moin Alex!
>
> AY> > Right, but does all WWW server offer this feature? We can't force the
> AY> > user to install a specific server.
> AY> Why not? This could be a part of Debian documentation system.
>
> Because no admin would like to have to httpd on his system: one for our
> documentation and one for the other.
>
Why? If the server is started from inetd it doesn't eat up any resources
while not in use. And another option would just have two (or more)
document roots. It is not difficult to configure httpd this way, but
configuration differs for different servers. Changing web server would
then be not very trivial task.
> AY> The only restriction would be to run it on unconventional port
> AY> and preferably from inetd.
>
> Again, why should we use a WWW server? This is always slower than read the
> files direct from disc.
>
> cu, Marco
Yes, but as you mentioned to your e-mail to Christoph, we can't patch
Netscape to convert .gz files on the fly, not mentioning that if we
implement that using web server, there will be possibility to browse
documents from different host.
Thanks.
Alex Y.
>
> --
> Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15
> Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
>
>
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Priorities before hamm release
Hi.
After RedHat 5.0 got released we noticably increased reatre of package
conversion and this is extremely good. The sooner hamm is relesed the
better. But we might consider other opprtunities to *increase* our
"market share" in current situation. The problem with RH 5.0 is that there
are not that many commercial and even pre-compiled free applications and
development environments for libc6 nowdays. This will change but not
immediately. Users encoutered with this might consider falling back to
some libc5-based distribution for some time. And *up to date*
Debian 1.3.1 could very well be the distribution of choice.
But only *if* we provide updated versions of the packages.
Can't we finally decide that the creation of this "libc5-updates"
directory has higher priority *now* than putting some order with
hamm uploads. Developers are anyway accustomed to download new packages
directly from Incoming. What do you think about asking Guy to put that
on top of his list?
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
> One problem with doing backports of libc5 packages is that
> dpkg-dev in bo doesn't seem to support pristine sources;
> it complained that the original wasn't in the .orig subdirectory.
>
> Although dpkg-dev from hamm works fine on bo since it is not libc
> dependent, it's still not possible to backport on a completely-bo
> given this factor, unless I am missing something ..
Hi.
As far as I understand, you just told that you can use dpkg-dev from hamm
to produce binary package on bo system. So, what is the problem now?
I guess even earlier dpkg (from bo) can install them OK, right?
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
> > > Although dpkg-dev from hamm works fine on bo since it is not libc
> > > dependent, it's still not possible to backport on a completely-bo
> > > given this factor, unless I am missing something ..
> >
> > As far as I understand, you just told that you can use dpkg-dev from hamm
> > to produce binary package on bo system. So, what is the problem now?
> > I guess even earlier dpkg (from bo) can install them OK, right?
>
> The only prolbem is that you cannot produce these packages
> on a purely bo system as some have promised/hoped. For example,
> Tim Sailer is offering access to a bo system for backporting,
> but unless it has been upgraded to dpkg from hamm then pristine
> sources aren't supported.
Well, I guess then libc5 machines dedicated to backporting should have
dpkg-dev from hamm installed. And upload newer dpkg-dev to bo-unstable
for consistency.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: question about prep.ai.mit.edu -> ftp.gnu.org (fwd)
> Resent-Cc: recipient list not shown: ; > X-Envelope-Sender: [EMAIL PROTECTED] > Date: Tue, 9 Dec 97 14:08 GMT > From: Ian Jackson <[EMAIL PROTECTED]> > Resent-From: debian-devel@lists.debian.org > X-Mailing-List: archive/latest/12182 > X-Loop: debian-devel@lists.debian.org > Precedence: list > Resent-Sender: [EMAIL PROTECTED] > Content-Type: text > Content-Length: 1104 > > > Date: Thu, 4 Dec 1997 18:55:14 -0700 > > From: Richard Stallman <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: Re: question about prep.ai.mit.edu -> ftp.gnu.org > > > > Simple question: Is "ftp.gnu.org" definitely the new preferred name > for > > "prep.ai.mit.edu"? > > > > Yes. > > > > Thanks. > > However, > chiark:~> host -C gnu.org > NS1.GNU.AI.MIT.EDU does not exist (Authoritative answer) > gnu.org has lame delegation to NS1.GNU.AI.MIT.EDU > gnu.org NS LIFE.AI.MIT.EDU > Nameserver LIFE.AI.MIT.EDU not responding > gnu.org SOA record not found at LIFE.AI.MIT.EDU, try again > chiark:~> host -t ns gnu.org > gnu.org NS NS1.GNU.AI.MIT.EDU >!!! gnu.org NS host NS1.GNU.AI.MIT.EDU does not exist > gnu.org has lame delegation to NS1.GNU.AI.MIT.EDU > gnu.org NS LIFE.AI.MIT.EDU > chiark:~> > > Can someone (Santiago?) who can actually mail RMS tell him to get his > DNS fixed ? > > Ian. > > It seems to be working: $ host ftp.gnu.org 18.159.0.42 -- AENEAS.MIT.EDU ftp ftp.gnu.org Connected to ftp.gnu.org. 220 aeneas FTP server (Version wu-2.4(3) Mon Jun 5 16:40:22 EDT 1995) ready. Name (ftp.gnu.org:algo): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-Welcome, archive user! 230- 230-If you have problems downloading and are seeing "Access denied" or 230-"Permission denied", please make sure that you started your FTP client in 230-a directory to which you have write permission. 230- 230-If you have any problems with the GNU software or its downloading, please 230-refer your questions to <[EMAIL PROTECTED]>. If you have any other 230-unusual problems, please report them to <[EMAIL PROTECTED]>. 230- 230-If you do have problems, please try using a dash (-) as the first character 230-of your password -- this will turn off the continuation messages that may 230-be confusing your FTP client. 230- 230 Guest login ok, access restrictions apply. ftp> > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [PGP]: can someone in NYC sign me?
> I'm hoping to get my PGP keys signed by a known and registered debian
> developer in the NYC area so as to comply with the Debian Developer's
> Reference Section 1.2.
>
> I'm located in Manhattan; specifically on the Lower East Side.
> Any takers? Please reply to me offline. Thanks.
> ...A. P. [EMAIL PROTECTED]http://www.onShore.com/>
Dear A. P. Harris,
if you don't mind coming to NYU, that's fine with me.
Just one question to the "public": is it OK to take a floppy with his
public key, sign it without his phisical presence and than e-mail
him the signed file back (encripted with his key)?
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linux on a i286
> Is there a way I can get Linux to work on my old 286?
There is an attempt to port Linux to 086 called ELKS. Look for it's link
on LDP page (http://sunsite.unc.edu/LDP/). Last time I checked I still
couldn't even boot it on my 286 though.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress for contrib and non-free (Dec 1997)
> Alexander Yukhimets <[EMAIL PROTECTED]>:
> contrib: ddd-dmotif-2.1.1-2
> contrib: ddd-smotif-2.1.1-2
The thing with motif-linked packages is that Motif itself is not yet
available for libc6.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
> Please let noone think that just because that absurd and awful
> suggestion was the last thing anyone said that everyone is happy with
> it.
>
> Rather, the rest of us have more important things to do than to fight
> battles with people with broken mailers and broken ideas about how
> mailers ought to work.
>
> The list configuration should be left the way it is.
>
> Ian.
Ian,
it is not that I want to change the mailing list headers at all cost or
whatever, but could you please give some explanaion why you think this
way?
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
> >FWIW I've been using run-parts in ip-up and ip-down for some time now,
> >the scripts reconfigure stuff based on my ip address (2 ISPs) etc.
> >and everything works like a charm. I dunno about packages placing
> >scripts in ip-[up|down].d/ -- I'd rather put them in
> >/usr/doc//examples.
>
> One question. You're obviously carrying along the `ip-up' argument list,
> i.e.,
> Arg Name Example
> $1 Interface name ppp0
> $2 The ttyttyS1
> $3 The link speed 38400
> $4 Local IP number12.34.56.78
> $5 Peer IP number12.34.56.99
>
> These variables are clearly being propogated to your (custom rolled)
> ip-up.d/* scripts. How are you propogating these values? Environment
> variables? We'd have to std'ize the variable names too, if so.
>
> ...A. P. [EMAIL PROTECTED]http://www.onShore.com/>
Why not as the same command-line arguments?
And there is one thing which I would qualify as a mistake in the above
description: $2 is actually in the form "/dev/ttyS1" than just "ttyS1".
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ["Gonzalo A. Diethelm" ] Re: Moving topics from debian-private (was Re: SPI money out)
> --- Start of forwarded message ---
> Resent-Date: 16 Dec 1997 22:24:45 -
> Resent-Cc: recipient list not shown: ;
> Date: Tue, 16 Dec 1997 15:38:16 -0300
> Message-Id: <[EMAIL PROTECTED]>
> From: "Gonzalo A. Diethelm" <[EMAIL PROTECTED]>
> To: Ian Jackson <[EMAIL PROTECTED]>
> Cc: Debian developers list
>
> [ ... ]
>
> --- End of forwarded message ---
>
> [Note the Cc: to iwj, despite the fact he's obviously on debian-devel]
>
> Interesting to note that those whining about duplicate mails and
> advocating the Reply-To munging are themselves creating duplicates.
>
> --
> James
Hi.
And that's exactly the point!
When doing 'g'roup reply in elm, the e-mail of the person goes into the
"To:" header and list address (along with all other thread participant's
adresses) to "Cc:" header.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
> > And there is one thing
> > which I would qualify as a mistake in the above description: $2 is
> > actually in the form "/dev/ttyS1" than just "ttyS1".
>
> Doh! I wish they wouldn't do that. I guess it's for some kinda
> security?
>
> ...A. P. [EMAIL PROTECTED]http://www.onShore.com/>
Well, as it was already pointed out by someone, $2 is in exactly the same
form as the option passed to pppd. (Un)fortunately, pppd is flexible
enough to accept port in both /dev/ttyS1 and plain ttyS1 forms.
As a result, $2 can also be in one of the above two forms. The solution
would be to detect in ip-up (and ip-down) which one is used and convert
it to "ttyS1" form.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
ldd strange behaviour
i have a c++ program compiled with no debug flag. when i do an ldd on the executable i get the following: ldd ./vat libtk8.0.so.1 => /usr/lib/libtk8.0.so.1 (0x4000f000) libtcl8.0.so.1 => /usr/lib/libtcl8.0.so.1 (0x400af000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40115000) libnsl.so.1 => /lib/libnsl.so.1 (0x401b8000) libdl.so.2 => /lib/libdl.so.2 (0x401be000) --->libstdc++.so.2.7.2 => /usr/lib/libg++-dbg/libstdc++.so.2.7.2 (0x401c1000) libm.so.6 => /lib/libm.so.6 (0x401fe000) libc.so.6 => /lib/libc.so.6 (0x40218000) if i take /usr/lib/libg++-dbg out of /etc/ld.so.conf an rerun 'ldconfig -v' i get this: ldd ./vat libtk8.0.so.1 => /usr/lib/libtk8.0.so.1 (0x4000f000) libtcl8.0.so.1 => /usr/lib/libtcl8.0.so.1 (0x400af000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40115000) libnsl.so.1 => /lib/libnsl.so.1 (0x401b8000) libdl.so.2 => /lib/libdl.so.2 (0x401be000) --->libstdc++.so.2.7.2 => /usr/lib/libstdc++.so.2.7.2 (0x401c1000) libm.so.6 => /lib/libm.so.6 (0x401fe000) libc.so.6 => /lib/libc.so.6 (0x40219000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) which, i think, should be the right dependency. is this a bug? which version of the c++ library is the program actually linked against? i have both libg++272-dbg and libg++272-dev installed (version 2.7.2.8-0.1 from hamm). ldd is from ldso-1.9.6-2. any clues? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
> On 18 Dec 1997, Kai Henningsen wrote:
>
> > Remember there are people that can't stand Emacs.
>
> Strange... :)
Nothing strange. After a couple of _years_ of struggling in attempts to
learn emacs (I made about 6 attempts total) I found a *great* relief in...
vi (vim actually). I was able to get used to it only after 2-nd attempt.
And now, when vim-5.0 supports syntax highlighting, I am more then
satisfied with it.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Motif Software
It looks like you already have motif, right?
In this case I would recommend using all packages dynamicaly linked with
Motif (like ddd-dmotif, etc.) from contrib/ *and* hamm/contrib/.
Since Motif is not available for libc6 (glibc2) yet, all Motif packages,
even from unstable tree should be libc5- linked and therefore suitable
for Debian 1.3.1. You actually can try something like xacc, nice personal
accounting application (don't think it is available as Debian package).
Motif linkage of vim (text editor) makes it look much nicer in X, etc.
Some mail user agent programs for X use Motif.
Good luck.
Alex Y.
P.S. If you got Motif 1.2 (not 2.0), then you are even in better luck,
you could use dynamically linked Netscape.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: non-hub 10baseT connections
> Thomas Lakofski wrote:
> > You'd be surprised... I described a cross cable to a friend of mine, and
> > told him that he'd have to go and get one made up or get some tools. He
> > mailed me back 5 minutes later to tell me that he'd got it working. I
> > asked him how, he said he'd pried the cable apart, done the cross (he'd
> > never seen ethernet before, and yet he got it right), and then used duct
> > tape to 'secure' the cable back in the cable end. It worked, and it still
> > does.
>
> OK, then, which two wires need crossing?
Check out ETHERNET-HOWTO for very detailed instructions.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
> Support of 8-bit characters by default
>
> Some programs need special configuration options to work 8-bit
> clean. This is very important for a lot of non-English users who
> need to input umlauts, accented characters, etc. All Debian
> packages will be configured to be 8-bit clean by default.
Hi.
I would like to question the need for this requirement.
While this can be of importance to some users, it can be quite
annoying to others. What it means is saying "good-bye" to clean
ascii e-mail, etc. What is more important, *some* utilities,
"less" most notably, *shouldn't* be 8-bit clean.
I think we should put a little bit more thought into this decision.
Not *all* packages should be 8-bit clean in any case, and for some
others, I would still prefer to have some options.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
> > > Support of 8-bit characters by default
> > >
> > > Some programs need special configuration options to work 8-bit
> > > clean. This is very important for a lot of non-English users who
> > > need to input umlauts, accented characters, etc. All Debian
> > > packages will be configured to be 8-bit clean by default.
> >
> > Hi.
> >
> > I would like to question the need for this requirement.
> > While this can be of importance to some users, it can be quite
> > annoying to others. What it means is saying "good-bye" to clean
> > ascii e-mail, etc. What is more important, *some* utilities,
> > "less" most notably, *shouldn't* be 8-bit clean.
>
> I don't understand that. Could you explain that?
Sure.
it is nice property of "less" (as opposed to "more") that it filters
out all non-ascii charachters (changes them to some ^... printable
sequencies). As a result, it is not possible to trash the console by
doing "less " or, more important - if something
bad happened and you created a file(s) with some non-ascii charachters,
"ls" will trash the console while "ls | less" will show you everything
and let you delete it.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: Debian 2.0 release requirements
> Moin Alex!
>
> AY> I would like to question the need for this requirement.
>
> ???
Aren't you questioning my right to do that? :)
> AY> While this can be of importance to some users, it can be quite
> AY> annoying to others.
>
> ??? Please remember, a lot of languages need 8 bit clean programs. Non 8
> bit clean programs are very bad.
True. Many users need support for the language other than English.
Some of that users need 8-bit clean programs AND still some additional
customization. Some languages even have many optionas as to customization.
(Take Russian - several possible encodings AND keyboard layouts).
For some languages it is even not enough to have 8-bit clean programs.
You can't satisfy all users anyway. In addition, I would hate to be
able to switch to "russian" keyboard mode (by mistake) and enter some
letters which look just like English ones in the editor I use for
_programming_.
> AY> What it means is saying "good-bye" to clean
> AY> ascii e-mail, etc.
>
> ???
Yes. I don't like when I see 8-bit charachters. In my
"non-internationalized" configuration they look like ""
highlighted (or something like that). So?
(PLEASE, no flames for *this* - I also don't like very much PGP
signatures as MIME attachements)
> AY> What is more important, *some* utilities,
> AY> "less" most notably, *shouldn't* be 8-bit clean.
>
> Why? I would like to see German Umlaute.
Sure, but I would like to be able to do "less " safely.
("more" is not safe for this).
Finally, the only thing I am trying to tell is that it is probaly not
very wise to put as a requirement for *every* package to be 8-bit
clean. (Note my point with the editor used for programming). I would
suggest to use individual approach and have options for the user
to choose whenever possible.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
> > You can't satisfy all users anyway. In addition, I would hate to be
> > able to switch to "russian" keyboard mode (by mistake) and enter some
> > letters which look just like English ones in the editor I use for
> > _programming_.
>
> OTOH, many people'd be upset not to be able to insert comments using those
> russian letters. And they'd be right.
OK. Many people would be upset not to be able, many would be upset to be
able. Why do you think ignoring them should be in the policy?
Sure I can recompile my favorite editor myself. But what's the point in
having binary distribution then? What I'm saying is that ignoring the
preferences of many users should not be the policy. Providing
alternatively configured packages (where necessary) would be a solution.
> > Yes. I don't like when I see 8-bit charachters. In my
> > "non-internationalized" configuration they look like ""
> > highlighted (or something like that). So?
>
> So what you really don't like is non-8-bit-clean software. That's the one
> that displays "".
Yes, but if I sent you a message containing some russian leters you
wouldn't see them the way I see anyway. The same thing for every other
language. 8-bit clean e-mail message is not the one to send to
international mailing list. But this is off-topic.
> > Sure, but I would like to be able to do "less " safely.
> > ("more" is not safe for this).
>
> Guess what? I can see those umlauts in less, and I can also safely do less
> .
Great. I am already persuaded that I was wrong about "less".
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
> Alex, this is much simpler than you think.
>
> I will give you a simple example: My keyboard has a key for the \~n letter
> (using TeX notation) which is used in the Spanish language.
>
> When I press that key, I *expect* to produce such character.
> Not obtaining that letter but some other is completely annoying for me.
> It is as if I pressed "t" and obtained "y". Completely unnaceptable.
>
> Since you don't have such key in your keyboard, you have nothing to worry
> about, but even if you would have that key in your keyboard, and you
> don't want to produce such character, just don't press that key! Where
> is the problem? I don't see any problem at all!
> > Great. I am already persuaded that I was wrong about "less".
>
> Ok. Please, tell me another example of a program that should not allow
> 8-bit input (and output) by default.
Hi.
I already gave an example in my other posts - the text editor I use for
programming. When you press \~n (unintentionally I would suppose) while it
is 8-bit clean you will get an error from the compiler, interpreter, etc.
OR (depending on the implementation of the compiler) introduce a hidden
bug. Lucky you, you can easily visually distinguish plain 'n' and \~n
on the screen. I am not that lucky, since I am using cyrillic alphabet
where ALL letters use non-ascii codes but _most_ of them look exactly like
English ones. (Of course, I don't have special keys for them. I use some
key sequence to switch between ASCII and cyrillic modes - this sequence
can easily be pressed unintentionally). As a result I will be getting
VERY annoying mistakes, which could be simply avoided by having only
7-bit clean editor. The fact is that I would recompile the editor myself
to avoid what I just described.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions for maintaining several packages
>1) xteddy > > Xteddy is a cuddly teddy bear for your X Windows desktop. > It is more or less an excersise for package bundling and > maintaining. > In fact xteddy is a must have for any Linux distribution :-)) > you can get an xteddy debian package by anonymous ftp from caliban.lbl.gov in /pub/debian. i am happy to see this finally become part of the distribution. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for maintaining several packages
>OK, I've finished building an xteddy Debian Package and I'll take over >maintainance when finished the procedure to become an official Debian >maintainer. Did you plan to maintain XTeddy too or was your package only for >private uses. I'm not intended to catch your job ;-). good job. my xteddy package was intended for my private use only. i've been using it for many years and i couldn't imagine not having it on my linux desktop, so i made a package myself. i keep meaning to apply to become a maintainer, but i can never seem to find the time. i don't care who maintains it, and if you want to do it, that's fine with me. i think the last release was some three years ago, so it shouldn't be that much work to maintain. i don't know if you looked in my area, but there are some other packages i made for myself which people should feel free to use/adopt. some of them have become part of the distribution, some not. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
new packages
i finally got around to applying to become a debian developer. so i want to announce here my intention to package the following programs: f77reorder f77 compiler script calling f2c/gcc. Handles some fortran 77 extensions by calling f77reorder to change the code. vat The LBNL audio tool, vat, is a real-time, multi-party, multimedia application for audio conferencing over the Internet. Vat is based on the Draft Internet Standard Real-time Transport Protocol (RTP) developed by the IETF Audio/Video Transport working group. RTP is an application-level protocol implemented entirely within vat -- you need no special system enhancements to run RTP. Although vat can be run point-to-point using standard unicast IP addresses, it is primarily intended as a multiparty conferencing application. To make use of the conferencing capabilities, your system must support IP Multicast, and ideally, your network should be connected to the IP Multicast Backbone (MBone). . Vat provides only the audio portion of a multimedia conference; video, whiteboard, and session control tools are implemented as separate applications. Our video tool is called vic and our whiteboard tool wb, UCL developed the session directory tool sdr Other related applications include ISI's Multimedia Conference Control, mmcc, the Xerox PARC Network Video tool, nv and the INRIA Video-conferencing System, ivs. xmmix Xmmix is an audio mixer utility for the X window system using the Motif graphical user interface. It operates the input and output mixer section on many PC sound cards. xrn X11 USENET news reader, based on rn. nt NTE is a shared text editor designed for use on the Mbone. It is not a word processor (it is not clear that word processing is a useful task to share) and it is not a whiteboard - if you want a whiteboard, wb from LBL is a much better whiteboard. . Using NTE can be very interactive - unless you lock a block of text, anyone else in your session can edit that text or delete it. This is intentional. Many people can (if they wish) edit the same document simultaneously. Many people can even edit the same block of text simultaneously, but if more than one person tries to edit the same line at one time, a conflict will occur, which results in only one of the changes being preserved. and some of the packages which need an smotif/dmotif version and don't have a maintainer yet (xmg, ddd, etc). all these are already available by anonymous ftp from caliban.lbl.gov in /pub/debian. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPR piece on Linux
go to http://www.npr.org/programs/atc/archives/1998/current.html and listen to it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
linking problem
i've run into a really strange problem, and i can't seem to figure it out. i am attempting to link a program against Xpm and the linker tells me it can't find it. this is the command: g77 evtdsp_main.o xencode.o ../e815_analysis/dst/ftio.o getolevent.o \ getoesevent.o getofsevent.o sigonline.o ../e815_analysis/ipc.o \ store_view.o display_image.o util.o options.o evtdsp.o getbeam.o \ sind.o cosd.o -L/usr/cern/98/lib -lgeant -lgraflib -lgrafX11 \ -lpacklib -L/usr/X11R6/lib -lXm -lXp -lXt -lXext -lXpm -lX11 -lSM \ -lICE -o evtdsp_linux and the error: /usr/bin/ld: cannot open -lXpm: No such file or directory collect2: ld returned 1 exit status but the library exists: ls -l /usr/X11R6/lib/libXpm.so.4* 0 lrwxrwxrwx 1 root root 14 Apr 12 20:55 /usr/X11R6/lib/libXpm.so.4 -> libXpm.so.4.10 54 -rw-r--r-- 1 root root53408 Jan 25 09:33 /usr/X11R6/lib/libXpm.so.4.10 if i replace -lXpm by /usr/X11R6/lib/libXpm.so.4 the program links fine. does anybody have any idea what's going on here? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linking problem
> > if i replace -lXpm by /usr/X11R6/lib/libXpm.so.4 the program links
> > fine. does anybody have any idea what's going on here?
>
> "ld" only looks for libXpm.so, not for libXpm.so.version. In Debian,
> libfoo.so is part of the libfoo-dev package, not of the libfoo package, as
> you need the header files (which are in libfoo-dev) to compile programs
> using libfoo. So it looks like you don't have "xpm4g-dev" installed.
Ray,
I also had a very similar problem with -lXt, the only difference is that I
used altgcc for compilation. Btw, what is the prefered way to use it?
I installed xlib6g, xlib6g-dev, xlib6, altgcc, libc5-altdev packages and
put in Makefile the following
CC = /usr/i486-linuxlibc1/bin/gcc
LDFLAGS = -L/usr/lib/libc5-compat/
LIBS = -lXt -lXext -lX11
and the line:
$(CC) -o bla *.o $(LDFLAGS) $(LIBS)
gives me the same error: can't load -lXt library...
Thanks.
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Warnings when linking with gtk
> I use the minimal Makefile:
>
> CFLAGS=-O2 -g -I/usr/lib/glib/include/
> LDFLAGS=-L/usr/X11R6/lib -lX11 -lglib -lgdk -lgtk -lm
>
> and get an (apparently) working program but the warnings:
>
> ld: warning: libc.so.5, needed by /usr/lib/libc5-compat/libXi.so.6, may
> conflict with libc.so.6
> /lib/libc.so.5: the `Getwd' function is dangerous and should not be used.
> /lib/libc.so.5: the `Gets' function is dangerous and should not be used.
> /lib/libc.so.5: warning: `Siggetmask' is obsolete; `Sigprocmask' is best
Well, there are a couple of issues here.
First, your linker line is a bit messed up. Not all of the necessary
libraries are present and worst of all, not in correct order.
While compiling with GTK I would recommend using the following:
CFLAGS = `gtk-congig --cflags`
LDFLAGS= `gtk-config --libs`
(*) (In case you want to link with some other library, in addition to GTK,
like electric-fence or whatever.)
Also, check that libc5-compat entries are at the very end of
/etc/ld.so.conf file.
Good luck.
ALex Y
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
assorted bugs in 2.0 install
we got 4 new computers running debian (1.3.1) and in the process of upgrading them to 2.0 i found the following problems: (1) kernel-package doesn't know how to deal with spaces before the block devices in the /etc/fstab file. i know you would say that not many people would run into this situtation, but varesearch ships such an fstab file and the kernel-package was totally confused by it. it took me a while too to figure out what was happening. mount doesn't forbid spaces before the first field so i think kernel-package should be able to deal with it. (2) upgrading from xfree86 3.3.1 to 3.3.2 i ran into the strangest problem. /usr/X11R6/lib/X11/Cards didn't get updated. i just took a look at all the other computers i have (running 3.3.2, upgraded straight from 3.3.1) and none have the new Cards file even though it is part of the xbase package. the ones that run 3.3.2-3 and got upgraded first to 3.3.2-0.1, 3.3.2-1 and so on to -3 have the new version of this file. also, if you do a fresh install (or run purge before installing the new xbase) then the new version of Cards gets installed. can somebody explain to me why this is happening? (3) i screwed up one of the upgrades (one day i'll learn to be more patient) so i ended up doing a fresh install. the disk drive is scsi, but the cd drive is ide. the boot disk wouldn't let me make linux bootable from the hard drive claiming that i can install lilo only on the first drive and that /dev/hda wasn't writable. of course it wasn't, since it was the cd drive, but /dev/sda was. shoudn't the installation script also look for the first scsi drive? i think this is a bug. anyway, this is about it. i consider (1) and (3) real bugs (but probably the majority of people will never run into them). (2) is kind of weird and i don't have any explanation for it, but i can reproduce it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: assorted bugs in 2.0 install
> I have now fixed this in my sources. I would appreciate a bug > report on things like this, since it was mere happenstance that I > noticed this message. Expect an upgrade in a day or so. > i was going to do this eventually, i just first wanted to see what other people thought about this. i don't like to rush in and fill a bug report just in case i turn out to be wrong. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xpenguin (formerly known as xteddy)
i got bored so i replaced xteddy with the linux logo. voila! here comes the new xpenguin. i still like my xteddy better, but if anybody is interested, you can get xpenguin by anonymous ftp from caliban.lbl.gov (you'll also find xteddy there). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xpenguin (formerly known as xteddy)
>Why dont u make a debian PAckage out of it? You can do one PAckage >xteddy with an additonal command-line parameter to select the >personality shown. somebody else (Andreas Tille <[EMAIL PROTECTED]>) has already expressed interest in packaging xteddy. i can share the pixmaps with him though. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed Constitution
> I say everybody is too paranoid. Who cares what it looks like? Do ^ >it effectively and use the most common method, whoever's toes it steps on. >Don't be afraid to put "he" because somebody will surely slander you for >your nievety. then i guess we'll use 'they' (since nobody cares what it looks like). or even better, why don't we use 'she'? and maybe we'll throw in some spelling mistakes (to do what everybody else seems to be doing. btw, what is 'nievety'?) --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Add a project to debian
Hello, I am interested in adding a project into the Debian Project and wanted to ask a couple of questions on how to achieve this. After having read the documentations I understood that I needed to apply as a new maintainer (with the appropriate identification process, needing an "advocate" Debian developper) and then find a sponsor that would accept upload the packages for me. If these two steps are performed correctly, this means that my package will be available on the debian repositories (on unstable, until it is considered stable enough to "apply" for testing) ? If this is so, what is approximatively the time between the upload of my package by a sponsor and the actual "distribution" of my package through debian repositories ? Thanks in advance for your help. Alexis Papadopoulos _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Add a project to debian
Ok thanks for the quick reply. Another question though that I forgot before, if the sponsor uploads the packages is he automatically the maintainer of the package (because if this is the case, then it means that sponsoring is a very demanding process for him, and makes therefore sponsoring a quite difficult task for me). And by maintaining activally my package is it possible to become allegible for debian developper, being able therefore to upload my packages on my own ? Thanks for the help, any further, more technical-related questions will be posted on debian-mentors... Alexis Papadopoulos _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pdns-server testing
Hi, Saw your request for pdns-server testing... I took a copy of the package (pdns-server_2.9.17-13_i386.deb) from http://www.cacholong.nl/~matthijs/pdns Looking at the postinst you now ship /etc/powerdns/pdns.conf and /etc/default/pdns in /usr/share/pdns-server/ and use ucf to install them under /etc This seems ok as far as it goes but you still seem to ship /etc/powerdns/pdns.d/pdns.local as a conffile and then the function "splitconfig" seems to update that file without asking. Later (after the two ucf calls) you then edit /etc/powerdns/pdns.conf and /etc/default/pdns I'm not sure that editing these files in this manner is compliant with section 10.7 of policy... (http://www.uk.debian.org/doc/debian-policy/ch-files.html#s-config-files) Mind you I'm not a Debian Developer! Perhaps you could copy the /usr/share/pdns-server/ files to temporary files... do your fancy editing on those temporary files then use ucf to copy the temporary files into place? As I say I'm not a Debian Developer so feel free to ignore me if I'm poking my nose in wher it is not wanted! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#387385: ITP: shed -- Hex editor using ncurses, with a friendly pico-style interface
> No, a bug (or rather, doesn't meet a release goal): > | And these release goals currently: > | - pervasive LFS (large files) support > http://lists.debian.org/debian-devel-announce/2006/07/> msg5.html Okeydokey. will look into ading this. alex the shed author ___ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390725: ITP: vb2py -- convert existing visual basic applications into python
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> see below. * Package name: vb2py Version : 0.2.1 Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://vb2py.sourceforge.net * License : BSD Programming Lang: Python Description : convert existing visual basic applications into python (Include the long description here.) The vb2Py project is developing a suite of conversion tools to aid in translating existing Visual Basic projects into Python. * The conversion includes, * VB code modules translating to Python code modules * VB classes to Python classes * VB Forms to PythonCard forms * VB Projects to PythonCard projects The project is also aiming to support translation of VB Script, ASP and VBA code into Python equivalent code. If you have experience in ASP and are interesting in contributing, please get in touch. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#173879: i have a python-leo package, and wish to contribute to existing effort
Package: wnpp Followup-For: Bug #173879 Owner: alex bodnaru <[EMAIL PROTECTED]> -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
On Sun, Oct 08, 2006 at 10:16:51PM +0200, Hendrik Sattler wrote: > I propose another solution. Introduce init-common with wrappers: > * /sbin/init is a binary that > - reads a configuration file with the init system name and > - creates a file /var/run/inittype (or whereever is can be stored at that > time) with the same value and /var may be a seperate file system, unmounted at that stage of booting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392291: ITP: mooedit -- a useful programming and around-programming text editor
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: mooedit Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : a useful programming and around-programming text editor (Include the long description here.) mooedit is a text editor. Started originally as a simple built-in editor component in GGAP, it grew up to a real text editor. The intention now is to make it a useful programming and around-programming text editor. Features * Configurable syntax highlighting. * Configurable keyboard accelerators. * Multiplatform - works both on unix and windows. * Plugins: can be written in C or Python. * Configurable tools available from the main and context menus. They can be written in Python, or it can be a shell script, or in MooScript - simple builtin scripting lanugage. * Regular expression search/replace, grep and find frontends, builtin file selector and whatnot. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Tue, Oct 31, 2006 at 07:10:45PM +0100, martin f krafft wrote: > Since #350282 is still being discussed, I ended up doing > > cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem > > on systems that needed access to all of CACert's certificates. > > The recent ca-certificates upgrade overwrote this "configuration" > simply because my /bin/cat call actually changed a file in > /usr/share, where changes by the admin are not preserved. Yet, due > to the links in /etc/ssl/certs, the admin is given the impression > that these are configuration files and can thus be edited according > to Debian's holy conffile handling policy. The configuration being preserved is a set of symlinks, not the contents of their targets. Perhaps this will work better: ln -s cacert-class3.pem /etc/ssl/certs/cacert.pem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Tue, Oct 31, 2006 at 07:41:02PM +0100, martin f krafft wrote:
> I am fully aware of this. However, it's misleading, don't you think?
I cannot answer that from the average user perspective. However,
symlinks are quite handy and there is already an established base of
users who are familiar with symlinks-in-etc.
> It's just not very typical for symlinks in /etc to be considered
> configuration:
>
> Symlinks "leaving" /etc, including ca-certificates:
>
> piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec
> readlink -f {} \; | egrep -v '^/etc' | wc -l
> 210
>
> Targets of symlinks "leaving" /etc, excluding ca-certificates:
>
> piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec
> readlink -f {} \; | egrep -v '(^/etc|ca-certificates)'
>/var/lib/defoma/pango.d/pangox.aliases
> /lib/linux-sound-base/noOSS.modprobe.conf
> /lib/linux-sound-base/noOSS.modutils.conf
> /lib/linux-sound-base/noOSS.discover1.conf
> /usr/share/dict/web2
> /lib/linux-sound-base/noOSS.hotplug.blacklist
> /var/lib/defoma/fontconfig.d/fonts.conf
> /lib/linux-sound-base/ALSA.discover2.conf
> /usr/bin/Xorg
I'm surprised your report missed one of the most established
configuration symlinks of them all: /etc/localtime. I'm pointing that
out in particular because it has been around for as long as I can
remember, and serves its configuration function by pointing somewhere
under /usr/share.
All these symlinks allow programs to easily grab data and
configuration in one step. A program can open /etc/localtime and know
it is getting an up-to-date timezone file for the local timezone.
> I'd go as far as claiming that all these are bugs or design
> misdecisions.
Weakly disagree. That isn't to say that there is no problem: How can
we clear up the potential for confusion?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Tue, Oct 31, 2006 at 08:32:49PM +0100, martin f krafft wrote: > also sprach Stephen Frost <[EMAIL PROTECTED]> [2006.10.31.2016 +0100]: > > In all of these cases the files pointed to are not intended to be > > modified but what file is used can be configured. > > How are certificate files not intended to be modified? If they > expire? If they are incomplete? I see your point. ca-certificates may be a special case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/localtime (was: Re: ca-certificates symlinks out of /etc)
On Tue, Oct 31, 2006 at 05:22:27PM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 31 Oct 2006, Alex Pennace wrote: > > I'm surprised your report missed one of the most established > > configuration symlinks of them all: /etc/localtime. I'm pointing that > > out in particular because it has been around for as long as I can > > remember, and serves its configuration function by pointing somewhere > > under /usr/share. > > That symlink is a bug from the very depths of foul-smelling lands, which we > have fortunately squished for Sid and Etch. It is gone, and good riddance > to it. May the Grue feast on the innards of anyone trying to bring that bug > back to life. I failed to check an etch system when I wrote the referenced message. > > All these symlinks allow programs to easily grab data and > > configuration in one step. A program can open /etc/localtime and know > > it is getting an up-to-date timezone file for the local timezone. > > Yes, it is also shortsighted like all heck to symlink data out of / when you > need it available in early userspace initialization, period. I see that now. Local time is important. But 95% of the other configuration symlinks are useful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359824: ITP: mezogis -- a graphical interface to query and analyse spatial data from postgis
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: mezogis Version : 0.1.1 Upstream Author : [EMAIL PROTECTED] * URL : http://www.stambouliote.de/mezogis/ * License : GPL Description : a GUI to query and analyse spatial data from postgis mezoGIS is a GIS application, a graphical interface to query and analyse spatial data. mezoGIS does not store or compute data directly, but operates external PostGIS databases. The goal of mezoGIS is to provide a tool for geo-spatial analysis with PostGIS, through on-the-fly SQL queries as well as through larger, external plugin scripts. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg support for solaris-i386 architecture
Andrew Donnellan wrote: (d-l may give advice) So now that's sorted out really Nexenta needs an exemption from *every* copyright holder in dpkg, gcc, binutils, apt, coreutils, etc. (the GNU utils would be easier as there is _usually_ only one copyright holder: FSF) or OpenSolaris needs to relicense (impossible as Sun wouldn't like it). Needs an exemption? Hmm... Here're a few links and some info, but first: Disclaimer: This post *is not* an invitation for yet another GPL flamewar. GPLv3 is available at [1]. The draft removes ambiguities of GPLv2, and in particular, clarifies the old GPLv2 clause 3: "You may copy and distribute the Program ..." During the discussion [2], Eben Moglen, General Counsel for the Free Software Foundation, noted that he always believed that GPLv2 should be interpreted in the way GPLv3 now makes explicit. Quoting [3]: "Eben made it very clear indeed that he does not regard the issues that are being raised over Nexenta to be any kind of a problem even under GPL v2..." More on the same at [3] and [4] by Simon Phipps, Chief Open Source Officer at Sun. [1] http://gplv3.fsf.org/draft [2] http://www.ifso.ie/documents/gplv3-launch-2006-01-16.html [3] http://blogs.sun.com/roller/page/webmink?entry=gpl_v3_released [4] http://www.opensolaris.org/jive/thread.jspa?messageID=21134劎 OK, now back to the original post, the only purpose of which was to submit a patch. I guess, we'll try Debian BTS. Thanks! -- Alex www.gnusolaris.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366422: ITP: cyclone -- a C like language, with additional safety and features
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: cyclone Version : 1.0.0 Upstream Author : Cyclone is a joint project of AT&T Labs Research, Harvard, the University of Maryland, and the University of Washington. Much of the early work was done at Cornell University. * URL : http://cyclone.thelanguage.org/wiki/Download * License : GPL Programming Lang: C, C++ Description : a C like language, with additional safety and features Cyclone is like C: it has pointers and pointer arithmetic, structs, arrays, goto, manual memory management, and C's preprocessor and syntax. Cyclone adds features such as pattern matching, algebraic datatypes, exceptions, region-based memory management, and optional garbage collection. Cyclone is safe: pure Cyclone programs are not vulnerable to a wide class of bugs that plague C programs: buffer overflows, format string attacks, double free bugs, dangling pointer accesses, etc. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366483: ITP: oci-mpc -- The Makefile, Project and Workspace Creator
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: oci-mpc Version : 3.3.95 Upstream Author : Designed by Justin Michel ([EMAIL PROTECTED]) and Chad Elliott. Implemented by Chad Elliott ([EMAIL PROTECTED]). * URL : http://www.example.org/ * License : Close to BSD: Since MPC is open source and free of licensing fees, you are free to use, modify, and distribute the source code, as long as you include this copyright statement. In particular, you can use MPC to build proprietary software and are under no obligation to redistribute any of your source code that is built using MPC. Note, however, that you may not do anything to the MPC code, such as copyrighting it yourself or claiming authorship of the MPC code, that will prevent MPC from being distributed freely using an open source development model. Programming Lang: Perl Description : The Makefile, Project and Workspace Creator A single tool (MPC) can be used to generate tool specific input (i.e. Makefile, dsp, vcproj, etc). The generator takes platform and building tool generic files (mpc files) as input which describe basic information needed to generate a "project" file for various build tools. These tools include Make, NMake, Visual C++ 6, Visual C++ 7, etc. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366647: ITP: rp-l2tp -- a user-space implementation of L2TP (RFC 2661) for Linux
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: rp-l2tp Version : 0.4 Upstream Author : Copyright 2002 Roaring Penguin Software Inc * URL : http://sourceforge.net/projects/rp-l2tp/ * License : GPL Programming Lang: C Description : a user-space implementation of L2TP (RFC 2661) for Linux rp-l2tp provides a user-space L2TP daemon. L2TP is the Layer Two Tunneling Protocol described in RFC 2661. It allows you to tunnel PPP sessions over a network or transport protocol (in this case, UDP.) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367442: ITP: geotypes -- classes for working with geometric types in postgresql
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: geotypes Version : 0.4.0-0.5.0+SVN Upstream Author : Richard Taylor <[EMAIL PROTECTED]>, Frederic Back <[EMAIL PROTECTED]> * URL : http://www.initd.org/tracker/psycopg/wiki/GeoTypes http://initd.org/svn/psycopg/geotypes/trunk * License : LGPL Programming Lang: Python Description : classes for working with geometric types in postgresql/postgis A package of classes for working with geometric types in postgres. The package contains two collections of classes: * The first were designed for use with the geometric functions supported by Postgresql (http://www.postgresql.com) although they do not need Postgresql to be present for them to be used. The types implemented are those listed in the Postgresql documentation at http://www.postgresql.org/docs/7.3/static/datatype-geometric.html with the exception of 'line' which, as the documentation is says, is 'not fully implemented yet'. * The second were designed for use with the PostGIS/OpenGIS extensions to postgres. All these classes begin with "OG" so as to avoid name clashed with the standard postgres types. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: Better portability for package maintainers
The following is based on premises that portability is good and that POSIX is a standard. A proposal. Over the last couple months we've built about gazillion Ubuntu/Dapper packages. The process is heavily automated ([1], [2], [3]). And so, to lookup the result of the XYZ build (where XYZ is a source package in question), simply click on a link that looks like this: http://www.gnusolaris.org/cgi-bin/hackzone-web?pkgname=XYZ For instance, take two randomly selected packages: galeon [4] and fam [5]. The first line in [4] has "SUCCESS" in it, which means that there is no need to look any further. The fam's build log at [5] starts with "BUILD-FAIL", and for those who are interested, the exact failure reason is in there way down below. To find out package version search the corresponding build log for "source version". Fixing failed builds is also simple, in most cases. In the grand scheme of things the suggested quick check could be one incremental step to ultimately achieve a unified common-source OSS that *builds and runs on all Debian systems*. [1] http://www.gnusolaris.org [2] http://www.gnusolaris.org/archive/elatte-unstable/newpkg_main [3] http://www.gnusolaris.org/cgi-bin/hackzone-web [4] http://www.gnusolaris.org/cgi-bin/hackzone-web?pkgname=galeon [5] http://www.gnusolaris.org/cgi-bin/hackzone-web?pkgname=fam [6] http://www.gnusolaris.org/download Thanks! -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Better portability for package maintainers
Matt Zimmerman wrote: On Fri, May 19, 2006 at 01:15:44PM -0700, Alex Ross wrote: Matt Zimmerman wrote: On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote: The following is based on premises that portability is good and that POSIX is a standard. A proposal. I didn't see a concrete proposal in your email, only information about where to find gnusolaris build logs. Can you elaborate? Minimally, package maintainers and developers could take a look on our logs and see if there's anything wrong. If there is, in many cases the fix is obvious. Because Debian and Ubuntu developers may not have access to a similar build environment, it will be difficult for them to help you in this way. Even if the first error is fixed, they will need to wait for you to build the package again to see if it builds. I expect that most maintainers won't be interested in working this way. Ditto. It makes more sense for the Nexenta community to fix these problems and make the patches available to other distributions and upstream. If your intention is to invite the Debian and Ubuntu developer communities to participate in this way, perhaps a good step would be to offer them access to a porting machine where they can help you with this work if they are interested? ssh?.. We'll work on it, let you know. Ideally though, there'd be an augmented policy of package acceptance, reflecting the fact that the packages with "Architecture: any" should build and run on one of the Debian POSIX-compliant systems. NexentaOS is certainly one such system. To help implement this new policy we could "plug" our AutoBuilder [1] into the existing build environment. If we find that it is feasible to get the current packages in Debian to meet this standard, then we can consider extending policy to recommend or mandate it at some point in the future, but to do this before attempting the experiment would be premature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Better portability for package maintainers
Matt Zimmerman wrote: On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote: The following is based on premises that portability is good and that POSIX is a standard. A proposal. I didn't see a concrete proposal in your email, only information about where to find gnusolaris build logs. Can you elaborate? Minimally, package maintainers and developers could take a look on our logs and see if there's anything wrong. If there is, in many cases the fix is obvious. Ideally though, there'd be an augmented policy of package acceptance, reflecting the fact that the packages with "Architecture: any" should build and run on one of the Debian POSIX-compliant systems. NexentaOS is certainly one such system. To help implement this new policy we could "plug" our AutoBuilder [1] into the existing build environment. [1] http://www.gnusolaris.org/gswiki/AutoBuilder -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375263: ITP: rtf2xml -- rtf2xml: convert MS RTF to XML
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: rtf2xml Version : 1.32 Upstream Author : Paul Tremblay <[EMAIL PROTECTED]> * URL : http://rtf2xml.sourceforge.net * License : GPL Programming Lang: Python Description : rtf2xml: convert MS RTF to XML (Include the long description here.) The script rtf2xml faithfully converts Microsoft's RTF format to structured XML. Developers can make further transformations using standard XML tools, or use the stylsheets provided to convert to sdocbook or TEI. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375603: ITP: zope-pgstorage -- a ZODB backend that persists to a PostgreSQL database
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: zope-pgstorage Version : 0.1 Upstream Author : Shane Hathaway, Zope Corporation, <[EMAIL PROTECTED]> * URL : http://hathawaymix.org/Software/PGStorage * License : Zope Public License (ZPL) Version 2.1 Programming Lang: Python Description : a ZODB backend that persists to a PostgreSQL database PGStorage is a ZODB backend that persists to a PostgreSQL database. PGStorage stores simple pickles in the database, so it is compatible with most Zope applications and is much simpler than Ape. Undo and packing are supported. . PGStorage also takes the place of ZEO. Any number of Zope instances can connect to a single PostgreSQL database. Furthermore, the replication options available for PostgreSQL may take the place of ZRS (Zope Replication Services.) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375801: ITP: zope-cmfcompositepage -- visually combine page fragments into complete pages
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: zope-cmfcompositepage Version : 0.2 Upstream Author : Shane Hathaway, Zope Corporation, <[EMAIL PROTECTED]> * URL : http://hathawaymix.org/Software/CompositePage * License : Zope Public License (ZPL) Version 2.1 Programming Lang: Python Description : visually combine page fragments into complete pages (Include the long description here.) CompositePage is a new way to assemble pages for the World Wide Web. Through the use of Zope technology, browser-based drag and drop, and custom context menus, CompositePage makes it easy to visually combine page fragments into complete pages. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375797: ITP: zope-compositepack -- allows the Plone Manager to build composite pages
Package: wnpp Severity: wishlist Owner: alex bodnaru <[EMAIL PROTECTED]> * Package name: zope-compositepack Version : 1.0 Upstream Author : Godefroid Chapelle ([EMAIL PROTECTED]) * URL : http://plone.org/products/compositepack * License : Zope Public License (ZPL) Version 2.1 Programming Lang: Python Description : allows the Plone Manager to build composite pages (Include the long description here.) CompositePack is a product that allows the Plone Manager to build composite pages by manually aggregating archetype content from his site. . Composition of content is made through a pseudo WYSIWYG user interface: the design view. A composite page has a layout which defines its structure. Composite elements are displayed through viewlets. . Both layouts and viewlets are acquired from the skin, which implies they are customizable. . Layouts and viewlets are registered through the composite_tool in ZMI. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
Some of us have woody running on LVM1... well I have this with 2.4 Debian kernel and LVM1. For LVM1 to work with a kernel that has devfs compiled in (debian kernels for woody do) then /dev/ has to be a mounted devfs. For people such as myself sarge as it stands will provide a 2.4.27 kernel with devfs and LVM1... This will allow us to upgrade to sarge fairy painlessly. Debian-installer on the other hand will install sarge on LVM2 and that gives people in my position the hint that we need to migrate to LVM2 during the lifetime of sarge (and probably 2.6 kernels too). During the testing of etch (ie when etch is "testing") debian will hit this "removal of devfs" problem... this will not affect sarge (Assuming sarge _IS_ released by then). etch is the place to fix the problem. The fix will be in 4 parts... (1) the kernel package will have no devfs! (2) initrd-tools will be fixed to support the kernel packages. (3) udev can provide compatability links for devfs names if needed. (4) debian-installer will be ported to use udev rather than devfs People who wish to use non-debian stable kernels on sarge (when it is released) will have to backport these fixes from etch to sarge... much as I have had to from sarge to woody to get LVM1 to work on woody! Taking these in reverse... (4) from what I've seen of the d-i work the d-i folks know that a port from devfs to udev is on the post sarge todo list. (3) udev can alredy provide devfs style device nodes... can it do compatability links? (2) this thread has alerted initrd-tools people... I hope! (1) this thread has alerted kernel people... I hope! The only remaining question is are the devfs device names burned into the LVM2 metadata stored on disk somewhere??? I suspect not... I think that LVM2 uses somekind of UUID to identify devices that form part of an LVM2 VG. If this UUID business is the case then do we need (3) ??? Hopefully by the time etch arrives as stable there will be a sane upgrade for sarge-LVM2 people to become etch-LVM(n>1) people. I hope this is a usefull contribution and not just a brain dump! Alex Owen Debian User and SysAdmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: So, what's up with the XFree86 4.0 .debs?
[EMAIL PROTECTED] writes: > On Sun, Mar 12, 2000 at 01:16:55PM -0500, Branden Robinson wrote: > [snip] > > [1] The makedepend program gets stuck in an infinite loop when attempting > > to generate dependencies in xc/programs/xterm. One of Tom Dickey's > > patches, #130 or #131, is probably the culprit since I think these are the > > only two changes that happened to the xterm sources between 3.9.18 and 4.0. > > Hi, > > Just a little extra info - this is a mail I was composing before I read > your mail (obviously I realise that this is low priority till woody). > > I have two potato systems [Sys1 hasn't been updated for a while and > seems to have gone a little mouldy ;] > the problem is with curses.h in libncurses5-dev. it redefines ERR and as such it conflicts with the definition from the glibc headers. this was the same problem noticed in dpkg 1.6.10. i just commented out the redefinition of ERR in /usr/include/curses.h and then the X package compiled just fine. i am sure the proper solution is the one used in dpkg-1.6.11 though. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: So, what's up with the XFree86 4.0 .debs?
On Sun, Mar 12, 2000 at 10:47:51PM -0500, Branden Robinson wrote:
> > You are going to keep /usr/X11R6 for this release right? I guess that the
> > XFree86 people might get a bit irritated if you tried to drop it.
>
> Actually, I've evilly been toying with the idea of #defining ProjectRoot to
> /usr for 4.0. Upstream has already moved almost entirely to the way Debian
> currently does things as far as filesystem layout goes.
Branden,
_please_ don't do it. It will be utterely confusing to find everything in a
new place. As a person who does X development writing -I/usr/X11R6/include
is an idiom. So as for many people. /usr itself is cluttered more then enough.
X is a very complicated system and knowing what exactly is X and what is not
is a great benefit - and having everything under /usr/X11R6 gives everyone
that benefit. I already trained my fingers to go to /usr/X11R6/lib/X11 for
a keyboard codes, some server docs, etc. Commercical packages I use assume
existence of /usr/X11R6/lib/X11/app-defaults (not to mention
/usr/X11R6/include and /usr/X11R6/lib). Yes, symlinking would help, but why
I should go to /usr/X11R6/lib, do "ls" and instead of one-screen listing see
an enormous number of entries from /usr/lib??
I remember that me being against something actually serves to you as an
endorsements to do it, but I somehow I am still not up to the task of
using reverse psychology :)
Best,
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
Re: So, what's up with the XFree86 4.0 .debs?
On Tue, Mar 14, 2000 at 08:20:48AM +1100, Hamish Moffatt wrote:
> On Mon, Mar 13, 2000 at 09:59:20AM -0500, Alex Yukhimets wrote:
> > _please_ don't do it. It will be utterely confusing to find everything in a
> > new place. As a person who does X development writing -I/usr/X11R6/include
> > is an idiom. So as for many people. /usr itself is cluttered more then
> > enough.
>
> You can still write -I/usr/X11R6/include, it doesn't matter if it's not used.
> I say go for it. /usr/X11R6 sticks out like a sore thumb.
Yeah, I can write, but what is the effect of that?
I often find myself in the position when I use X libraries (Xt mostly)
built by myself with some changes to allow debugging of my Xt widgets.
I install new libs and headers in another directory and -I/this/new/dir
and -L/that/new/dir allows for compilation and linkage with new version.
If libs are in /usr/lib and headers in /usr/include (default locations)
then this would not work. I just don't understand why you should make
my life (of the programmer) more difficult with no benefits whatsoever?
(Well, some think that there is an aestetic benefit which I just can't see -
if you pile up everything in /usr/lib - what's so good about it?
It is like refusing to make subdirectories in your home dir and have a total
mess in it.)
X is a very important, I would even say unique package, - it deserves
different treatment after all. There is no other software package with
even close complexity and size.
Luck,
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
Re: realplayer installer and frozen
On Tue, Mar 14, 2000 at 07:09:31PM -0800, Joey Hess wrote:
> Lars Wirzenius wrote:
> > I agree with Branden: remove the installer from potato.
>
> The problem that I forgot to mention is that anyone who upgrades from slink
> to potato w/o upgrading realplayer, and had realplayer installed via the
> installer in slink, is going to find that the old realplayer they have
> installed realplayer no longer works. Library incompatabilities of some
> kind cause it to crash.
I would definitely put new realplayer installer package in potato.
At least this would be a big favor to our users.
Thanks,
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
Re: APT problem
Wichert Akkerman <[EMAIL PROTECTED]> writes: > It means the libc6 package you have installed has a different md5sum then > the package it finds on ftp.corel.com, and assumes that the version on > ftp.corel.com is a newer recompile. Strange logic, but that is how > libapt-pkg thinks. > this is something that has always bugged me about apt. i wish it would assume that my local copy is a newer recompile (which is, almost always, the case). sometimes i recompile packages to enable features which are not on by default and then i have to put the packages on hold because apt wants to get the remote ones. can we please, please reverse the behaviour, or at least make it configurable in /etc/apt/apt.conf, something like PreferLocal "yes". if there is such an option and i missed it, please point it out to me. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: APT problem
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On 30 Aug 2000, Alex Romosan wrote: > > > can we please, please reverse the behaviour, or at least make it > > configurable in /etc/apt/apt.conf, something like PreferLocal "yes". > > if there is such an option and i missed it, please point it out to me. > > Come up with a reasonable situation where you would want to have a > non-held package not be moved to the archive version of the same version > but be moved to the newer archive version :> > if a new version becomes available, i don't mind upgrading. i just don't want apt to "upgrade" to the archive package if the packages have the same version. i think the ability to set this as a configuration option is best. as for a reasonable situation... let's say i want to compile some packages with pentium optimizations on, but if there is a new version i would like to upgrade automatically. now dselect tells me there is a new version, but if i use apt-get upgrade i won't even know the new version exists. i don't know if you consider the above situation reasonable, but for me it is. this is why i would like to be able to change the current behaviour with an option in apt.conf. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: APT problem
Craig Sanders <[EMAIL PROTECTED]> writes: > On Wed, Aug 30, 2000 at 09:31:57PM -0600, Jason Gunthorpe wrote: > > [Alex Romosan wrote:] > > > which are not on by default and then i have to put the packages on > > > hold because apt wants to get the remote ones. > > > > You have to do this anyhow, otherwise the package will get upgraded > > and you will loose your changes. In all cases I can think of where > > a package is locally recompiled and has not been placed on hold you > > would indeed want the 'newer' archive package to be installed. The > > motivating factor here is local slink recompiles of potato packages. > > i may be missing something here, but why not change the debian revision > number when you recompile the package? takes a few seconds to edit the > changelog. that's what i do...it works for me. > i usually do that, but sometimes i forget and i find it annoying that apt assumes by default that the mirror packages are "newer" than my local packages. it just doesn't feel right. also, this doesn't work with 'apt-get source -b '. what's the point in having the ability to download the source and recompile it automatically if the next upgrade will wipe it out. if i choose to recompile a package, apt should leave it alone until a newer version comes along. to me, at least, this idea of always fetching the mirror package, feels too much like microsoft. also, before apt, dselect use to leave the packages alone, maybe that's when i got used to the idea that my local packages shouldn't be touched if they have the same version number. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nice features in a pre package manager
In addition to the previously-mentioned pipelining that installs packages as soon as they're downloaded, so their deb can be deleted, and has careful sequencing so that a package is not downloaded until its dependencies have _already_ been met, it would be nice ... to have the package requesting front end be pipelined and prioritized. I might have 300MB queued for download and install, but it would be _really_ nice to have package "xf86config" (for example) ready as soon as possible. Once that is running, I can find out which graphics card I need (while more downloading is happening in the background), and so I ask for "xserver-svga" to get top priority next (while I'm halfway through running xf86config). Once I've tweaked X the way I want, during which time (for example) GCC was downloading, I might ask for "utah-glx" to be prioritized. I then ask for the kernel source, because I need some features turning on, while bringing up the 3D support, etc etc etc. I reckon that being able to have an apt pipeline, with the capability to promote packages to the head of the list, will halve the time it takes me to bring up a workstation system. Configuring takes user time, downloading takes network time, unpacking takes disk drive time. None of them are really competing for resources, unless you've got <32MB of memory and dpkg is swiped the whole lot. These tasks should all happen in parallel. Suppose the feature is added as an "apt-get queue" to distinguish from "apt-get install", where the former gives the prompt back immediately and communicates with an existing apt-get (or starts a background task). The latter plays nice if there is already an apt-get running, gets the to-do list modified and then sleeps until the other process reports that it has completed the request (or is being killed).
Looking for a maintainer for pyslsk
I'm seeking for someone who'd be willing to maintain pyslsk package in debian. It's a p2p client for Soulseek filesharing network (which is great for finding obscure music), written in Python/wxPython. It was maintained by Josselin Mouette ([EMAIL PROTECTED]), but recently he replaced pyslsk with a dummy package that makes a switch to nicotine, a pyslsk sort-of fork, which has a gtk2 interface and a number of additional features. I believe both programs should be available, for these reasons: 1) choice is good 2) nicotine's UI is noticeably less responsive than pyslsk's UI 3) nicotine isn't as mature yet; many users are reporting freeze problems with the UI in particular pyslsk is currently in maintenance mode, which means that I'm only doing bugfixes and protocol compatibility fixes, so maintaining the package should not take a lot of time. If you're interested, drop me and Joss a note. Thanks! -- Alexander Homepage: http://www.sensi.org/~ak/
Re[4]: Приглашение - Английский Разговорный с п реподавателями из С Ш А Cadena
Hi! Весь английский для Вас! Приходите и узучайте разговорный английский. Большие скидки!!! В Москве наши телефоны следующие: один-ноль-пять 5186 238-33-86 Tsolakidis Moro Akpinar Atanasova Wannithikul Mauad Devine Holmgren Crespo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291562: i wish to package openev for debian
Package: wnpp Followup-For: Bug #291562 Owner: alex bodnaru <[EMAIL PROTECTED]> in the process of debianizing postgis, i wish to package openev for debian. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-686-smp-skas3-v7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
