Advice regarding splitting package 'hitop'
I was wondering about doing this for some time, but events have forced my hand. hitop build-depends against libpgsql-dev which has become main/non-US. The situation as it stands is that 'hitop', a HTML preprocessor with pretentions to be an web-based application server, is one package. It is built in a modular fashion, whereby the 'plugins' (.so files) are dynamically linked when required at run-time. These plugins extend the functionality of core hitop, providing, for example, database connectivity. One such database plugin is for Postgresql. As most hitop users won't want to use the Postgresql plugin, I made the package Suggest libpgsql, since it merely provides additional features (makes plugin postgres.so work). My question is: would it be sensible to separate the plugins which have additional dependencies into separate packages (one for Postgres, another for MySQL, etc.)? If I did this, would I still have to move the hitop packages into non-US (since it would still build-depend upon libpgsql-dev which is now non-US)? Is there any way around this? Should I even care which part of the archive it goes in? -- Andrew Stribblehill [EMAIL PROTECTED] Systems programmer, IT Service, University of Durham, England -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [users] Re: Where's lame
On Thu, May 10, 2001 at 12:33:19AM +0200, Robert Bihlmeyer wrote: Paul Martin [EMAIL PROTECTED] writes: The RSA patent was only valid in the USA, an oversight on RSA's part. That's the difference. But surely a sizable chunk the Debian usersbase lives in the US, there were official CDs sold in the US containing the software, etc. So the difference is only gradual: more potentail users, and more mirrors (if mere distribution is really illegal) would be affected. What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [users] Re: Where's lame
On Fri, May 11, 2001 at 11:00:01AM +0200, Sven LUTHER wrote: What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? I'm in India. I'm not sure about the official state of things here, though from what I figure, there shouldn't be a problem with patents here. I have not heard of a patent infringement case being filed here myself.. If people are interested, I could try to find out whats the scene here on patents like ? The fact is that there is a non-us is bad enough. I could probably even arrange for a non-patent archive here, but thats not the way we should be solving the problem. Freenet is another solution I can think of. However I just posted a mail on why lame can't be distributed, and I await replies to that one. There have been no concrete reasons given anywhere for that. I have also cc'd it to debian-legal. viral -- Live for today, gone tomorrow, that's me, HaHaHaa! PGP signature
Seeking an advocate
Hello, First of all I apologise if this is considered OT, but I am interested in becoming a Debian maintainer, and currently stuck in the process waiting for an advocate. I am moderately familiar with Debian's package management system, have run various releases of Debian from 2.0 to Sid snapshots - currently running Progeny with recompiled Sid packages. Recently I have started packaging on my own, the first package being gtk-engines-crux (currently unreleased, planning to put it up on a website soon). If any maintainer is interested in helping out it will be much appreciated :) Thanks Michel Salim Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My First Package. Wheee.
On Thu, May 10, 2001 at 12:56:49PM -0500, Michael Janssen (CS/MATH stud.) wrote: In Warren Anthony Stramiello's email, 10-05-2001: It's XDrawChem, a linux version of ChemDraw, a fairly necessary app for chemistry folks (at least so my girlfriend tells me, and she's a chemistry major here at Tech). Congratulations! If only it had been around when I was writing my thesis.. ;) I read through the docs and such (NMU docs, packaging-manual, and so forth), and I was wondering how I should handle: a) inclusion in the testing distribution, if still possible b) inclusion in the unstable distribution, if still possible To give a bit more detail from Tog's reply: you upload to unstable (this means you need to be running unstable yourself, unless you know how to do one of those chroot thingies). After a standard period of time (10 days for normal packages I think), the package gets copied (symlink) to testing if the following conditions are met: - binaries are available for main architectures (i386, alpha, sparc, but the others are lagging behind, so they won't hold up the package from testing) - no serious errors (normal errors don't hold it up) - the packages it depends on are also in testing The third one can be the tricky one to follow, since there might dependencies on dependencies and they have to be fulfilled all the way down. c) uploading using dupload and scp I think someone mentioned the New Maintainer's guide. Section 6.3 (I copy and paste from there, hence I don't know about dput either ;) ) Ohh.. cool - I've been looking for a software program to do something like this for a while for our labs.. If you need 3-D modelling, I've recently uploaded viewmol (lets you edit new molecules as well as view them). And something else was uploaded even more recently still (I forget the name). Chemistry in Debian is having it's day... ;) Section Science was recently opened on the Debian website (it had been forgotten), maybe that's attracting all these chem packages? Regards, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Where to find woody...
Hi, I'm just wondering if I should install woody on my machine to compile a package, or I can use one of Deban machines. The problem is - there is no x86 machine running woody on the machines.cgi list. So the question is - is the list wrong, not full, or I have to get woody locally to maintain a package prepared for woody? honey -- http://7thGuard.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perl modules - building debs
On Thu, May 10, 2001 at 11:45:16PM -0400, Derek Evan Mart wrote: After several hours attempting to build debian packages for perl modules and twenty minutes searching google for helpful documentation, I have come to the conclusion that I have no frelling idea what I am doing. =) I read that there is a perl module that would build a package from any module on cpan. I also read something about dh_make_perl, although I can not find anything like that on my system. apt-get install dh-make-perl The program itself is also called dh-make-perl. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to locally sign a package that has been built on another machine?
On Thu, May 10, 2001 at 08:58:26AM +0200, Marc Haber wrote: On Mon, 7 May 2001 21:49:12 +0200, Filip Van Raemdonck [EMAIL PROTECTED] wrote: The tools available for automatic changes signing seem to do this for you. Yes, they do. Judging from the debsign source, this is a gpg issue. However, debsign fails for me because gpg returns some strange error codes: |haber@paola[23/523]:~/tmp$ ( cat run_0.9.2-6.dsc ; echo ) | gpg |--local-user Marc Haber [EMAIL PROTECTED] |--clearsign --armor --textmode --output - - run_0.9.2-6.dsc.asc |gpg: /usr/lib/gnupg/rsa: error loading extension: /usr/lib/gnupg/rsa: |cannot open shared object file: No such file or directory | |You need a passphrase to unlock the secret key for |user: Marc Haber [EMAIL PROTECTED] |1024-bit DSA key, ID 6BBA3C84, created 2000-02-15 | |passphrase is overwritten after pressing enter |haber@paola[24/524]:~/tmp$ echo $? |2 Is the return code 2 the result of rsa missing? Recent versions of debsign gives the following message in this situation (since version 2.5.13, December 2000): /usr/bin/debsign: GPG error occurred! If you are using gpg version = 1.0.3-2 and saw a gpg error message: error loading extension: /usr/lib/gnupg/rsa(ref) above, please remove the load-extension rsa or load-extension rsaref line in your ~/.gnupg/options file to ensure the correct functioning of this (and possibly other) programs. Aborting Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perl modules - building debs
* Derek Evan Mart ([EMAIL PROTECTED]) [010510 23:45]:
What is the best way to approach this issue? Are there any FAQs/HOWTOs
which explain this process? Any informative replies will be appreciated,
rtfms will be tolerated. =)
OK, perhaps someone can answer this question. I looked at an existing
module package and tried to make my mangled mess look the same.
The build halts and I get the following message every time:
dpkg-gencontrol: warning: unknown substitution variable ${perl:Depends}
When I replace perl:Depends with perl5, it completes the process,
however, everything is in the package accept for the module itself.
I respectfully request tutoring from someone with perl module experience. =)
--
Derek E. Mart Marticus - Systems Programmer II
U of L - Electrical Computer Engineering
The Marticus Project - http://www.marticus.org/
1514 3659 D057 D10C 6BE6 3E68 15BE B181 2F1F 510B
PGP signature
Re: perl modules - building debs
On Fri, May 11, 2001 at 10:22:16AM -0400, Derek E Mart wrote:
* Derek Evan Mart ([EMAIL PROTECTED]) [010510 23:45]:
What is the best way to approach this issue? Are there any FAQs/HOWTOs
which explain this process? Any informative replies will be appreciated,
rtfms will be tolerated. =)
OK, perhaps someone can answer this question. I looked at an existing
module package and tried to make my mangled mess look the same.
The build halts and I get the following message every time:
dpkg-gencontrol: warning: unknown substitution variable ${perl:Depends}
When I replace perl:Depends with perl5, it completes the process,
however, everything is in the package accept for the module itself.
I respectfully request tutoring from someone with perl module experience. =)
Make sure you debian/rules file has a call to dh_perl at the appropriate
time to generate the perl:Depends substitution.
Gordon Sadler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Advice regarding splitting package 'hitop'
If I did this, would I still have to move the hitop packages into non-US (since it would still build-depend upon libpgsql-dev which is now non-US)? Is there any way around this? Should I even care which part of the archive it goes in? anything in non-us does not appear on the default Debian cd. Whether or not you care about this is another matter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating man pages (upstream does not have one)
Othmar Pasteka [EMAIL PROTECTED] cum veritate scripsit: Hmm... anyone going to package manedit ? I tried it. It was rather fun to play with. It edits in roff. Should I upload it ? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d+ s:- a-- C+ UL P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perl modules - building debs
On Fri, May 11, 2001 at 10:22:16AM -0400, Derek E Mart wrote:
OK, perhaps someone can answer this question. I looked at an existing
module package and tried to make my mangled mess look the same.
The build halts and I get the following message every time:
dpkg-gencontrol: warning: unknown substitution variable ${perl:Depends}
When I replace perl:Depends with perl5, it completes the process,
however, everything is in the package accept for the module itself.
But this is incorrect. See the Perl Policy (now included in the
debian-policy package), it explains how to do it.
If you are using debhelper, make sure you Build-Depends(-Indep) on
debhelper (= 3.0.18) and include a call to dh_perl in your
debian/rules file. See /usr/share/doc/debhelper/examples/rules for
where to put it.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice regarding splitting package 'hitop'
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote: If I did this, would I still have to move the hitop packages into non-US (since it would still build-depend upon libpgsql-dev which is now non-US)? Is there any way around this? Should I even care which part of the archive it goes in? anything in non-us does not appear on the default Debian cd. Whether or not you care about this is another matter. That's a bit misleading. There are TWO versions of Debian CD 1, and *both* are official. One version is for folks in the US who wish to sell it to a customer outside the US. The other version is for everyone else. The poorly-named non_US is omitted from the first version of CD 1. -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lame (again!)
Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. -- Marcelo | Mustrum Ridcully did a lot for rare species. For one [EMAIL PROTECTED] | thing, he kept them rare. | -- (Terry Pratchett, Lords and Ladies) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lame (again!)
Brian Ristuccia [EMAIL PROTECTED] writes: On Fri, May 11, 2001 at 10:14:22PM +0200, Marcelo E. Magallon wrote: Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. Lame is already included in the Debian archives in libmp3lame_audioenc.so.0 in libavifile in debian/main. It's in shared library form, but appears to be a fully functional mpeg-1 layer 3 encoder and not just a wrapper that invokes a lame binary the user already has on their system. That's a bug then... (which I've just filed). -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lame (again!)
Hi all, I would like clarify the reason for lame not being included in the debian archives, not even non-US. Firstly, the lame license is LGPL as of version 3.88. The psycho-acoustic model used in LAME is also GPLed (or LGPLed). I believe its not the same as the one patented by the Fraunhofer Institute. I could be wrong here, and correct me. This is what I understand from the lame homepage and changelogs. I don't see any restriction on lame being allowed to be distributed only in binary form, because of the LGPL license. As of version 3.81beta, all ISO code was removed. lame has already been debianised, and the debian/ subirectory for making the deb is included with the distribution now. However, this is immaterial, if it can't be packaged and made available through the official archives. So, what restricts us from making lame available ? Please cc me replies, as I don't read debian-legal. Thanks again, for allowing a rehash of an old thread. viral -- Live for today, gone tomorrow, that's me, HaHaHaa! PGP signature
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 01:51:54AM -0400, Brian Ristuccia wrote: 1) I live in the US. Therefore, do I have to send a BXA notification to the government (I believe license exception TSU is applicable - correct me if I'm wrong)? You may. Since it's easy, you probablys hould. Really? I am not doing any static linking with libssl, only dynamic, so I don't believe that I am including any crypto. This fact, which I realized after I sent my original message (otherwise I would have mentioned it), makes me still unsure whether a BXA notification is needed. Although I would like to know whether it is in fact required, if I am not persuaded that it is not, I will notify the BXA, because it's easy and it's a good idea to be safe, as you said. Also, do I have to do their thing that they mention on their website about sending a message to the ENC Classification Review Coordinator (or, something like that) in addition to [EMAIL PROTECTED], and if so, how do I do that? I think the email to [EMAIL PROTECTED] is sufficient. Thanks. Also, is a BXA notification form sufficient to export binary .debs linked with libssl? Yes. Thanks again. Would anyone be able to export them, including other US mirror sites, so long as I provide an export of the same stuff that I notify the BXA about? Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. Thus Debian's requirement that export restricted software get uploaded to non-us doesn't apply. Indeed, this is how Netscape with strong crypto got uploaded to non-free instead of non-us/non-free. There's currently an inquiry going on that will determine if Debian's policy can be updated to clearly reflect the new regulations. I would tend to agree, though of course IANAL; I am surprised Debian's policy hasn't been updated yet. 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. OK, I understand that this is a quirk of Debian policy, and not US law. What about the Debian source files? Same. I guess this makes sense, since there would need to be a Build-Depends on libssl-dev. (Am I right about that?) If I make additional non-ssl .debs from the same source, would they be in non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. Well, I don't intend to redistribute libssl, in my source or binary .debs, just dynamically link to them at compile and then run time. So do the non-ssl .debs go in the non-US/main or main? Good luck :) Thank you! I may also download the source of some package that comes in ssl and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking of lynx, myself. - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 08:28:12PM -0400, Jimmy Kaplowitz wrote: 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. OK, I understand that this is a quirk of Debian policy, and not US law. It wouldn't make sense for .deb's to go in a place different than their source code. Otherwise, you wouldn't be able to rebuild from source without specifying additional places to get source tarballs and diffs from. What about the Debian source files? Same. I guess this makes sense, since there would need to be a Build-Depends on libssl-dev. (Am I right about that?) Yes. If I make additional non-ssl .debs from the same source, would they be in non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. Well, I don't intend to redistribute libssl, in my source or binary .debs, just dynamically link to them at compile and then run time. So do the non-ssl .debs go in the non-US/main or main? There are legitimate reasons why non-crypto .deb's might need to go in non-US/main. For example if the source and diffs must go in non-us, you can't put the .deb's built from them anywhere else. In this case, it's probably silly to even bother distributing them since anyone who was using non-US could just use the ssl versions. Good luck :) Thank you! I may also download the source of some package that comes in ssl and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking of lynx, myself. lynx has seperate and distinct sources for the crypto and non-crypto versions. Based on size alone, I suspect the non-ssl version has all the crypto stuff ripped out (or the ssl version has it patched in). -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating man pages (upstream does not have one)
On Sat, May 12, 2001 at 01:27:04AM +0900, Junichi Uekawa wrote: Othmar Pasteka [EMAIL PROTECTED] cum veritate scripsit: Hmm... anyone going to package manedit ? I tried it. It was rather fun to play with. It edits in roff. Should I upload it ? IIRC, [EMAIL PROTECTED] is maintainer for that package. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, 11 May 2001, Jimmy Kaplowitz wrote: On Fri, May 11, 2001 at 09:03:48PM -0400, Brian Ristuccia wrote: some simple fileutils magic in debian/rules. BTW can anyone on -mentors explain how I set up a debian/rules file that generates multiple binary packages? You'll need to generate two source packages. See fetchmail/fetchmail-ssl for a dirty hack to do so automatically. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 11:29:00PM -0300, Henrique de Moraes Holschuh wrote: On Fri, 11 May 2001, Jimmy Kaplowitz wrote: some simple fileutils magic in debian/rules. BTW can anyone on -mentors explain how I set up a debian/rules file that generates multiple binary packages? You'll need to generate two source packages. See fetchmail/fetchmail-ssl for a dirty hack to do so automatically. I will look at that, though I haven't yet. Why is it not sufficient to do something like the following pseudo-code in debian/rules: #--- # Makefile is set up by default to include SSL support generate the .deb with SSL support cp Makefile Makefile.with-ssl some sed commands to change the Makefile to disable SSL support generate the .deb without SSL support mv Makefile.with-ssl Makefile #--- I think that would work fine, though it might not, because I haven't thought it through at all. - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, 11 May 2001, Jimmy Kaplowitz wrote: btw side note, why do all the ssl-enabled packages I've seen the source for, i.e. yours and lynx-ssl, depend on the obsolete package libssl096-dev instead of the current replacement package libssl-dev? Eh, because I hadn't noticed the problem yet? :) Fixed in CVS. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 09:03:48PM -0400, Brian Ristuccia wrote: 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. OK, I understand that this is a quirk of Debian policy, and not US law. It wouldn't make sense for .deb's to go in a place different than their source code. Otherwise, you wouldn't be able to rebuild from source without specifying additional places to get source tarballs and diffs from. I don't understand this (but am willing to believe it). Please elaborate, if you would. There are legitimate reasons why non-crypto .deb's might need to go in non-US/main. For example if the source and diffs must go in non-us, you can't put the .deb's built from them anywhere else. In this case, it's probably silly to even bother distributing them since anyone who was using non-US could just use the ssl versions. What if they are living in France, where private use of cryptography is illegal? They might be using non-US to get things that are excluded from the US mirrors due to patent rather than cryptography reasons, and so they might still find use for a non-crypto version of my package, which they would be able to get from non-US/main rather than main (for the reason stated in your quoted bit above) if I distribute such a thing. Good luck :) Thank you! I may also download the source of some package that comes in ssl and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking of lynx, myself. lynx has seperate and distinct sources for the crypto and non-crypto versions. Based on size alone, I suspect the non-ssl version has all the crypto stuff ripped out (or the ssl version has it patched in). Since the only difference here is a few lines in the makefile, I could easily generate a crypto and a non-crypto version from the same source packge with some simple fileutils magic in debian/rules. BTW can anyone on -mentors explain how I set up a debian/rules file that generates multiple binary packages? Also, this makes me realize, the following entry was listed in the SourceForge release notes for version 0.4.3 (an old release) of my package: -- This version adds a bit of security. Rather than storeing the user's password in plain text in a world readable config file, it saves it scrambled (though easily decryptable with the algorithm included in the source) in a file which is not world readable. -- This doesn't seem like real strong cryptography, and it may not qualify as any cryptography at all, just simple encoding (as opposed to encrypting). Is this legal to use in countries such as France? Also, is France's prohibition on cryptography limited to strong cryptography or not? If this would count as crypto then even the non-ssl version would have crypto. (There is no apparent way to disable compilation of this feature without hacking of the source - which could be done with sufficient justification, I guess.) - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 09:53:04PM -0400, [EMAIL PROTECTED] wrote: I'm not sure that that matters. The BXA refers to Open Cryptographic Interfaces. My understanding was that any software which contained hooks to call other software which actually performed encryption was regulated as if it contained the encryption itself, since it contains an implementation of a cryptographic interface. Ah, that's very interesting. I will do the BXA notification before I distribute my current package. Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. That's not true. See here: http://www.bxa.doc.gov/Encryption/lechart1.html Under the category 'Unrestricted source code (open source)' it contains an additional restriction 'may not knowingly export to the T-7'. T-7 is defined as: Cuba, Iran, Iraq, Libya, North Korea, Syria, and Sudan. Also very interesting. Our FTP servers do not block these countries, so I don't know if we would still be considered compliant under these rules. I think it's safer to leave everything in non-US. I probably agree, but what about this sentence from section 2.1.5 of Debian Policy: A package containing a program with an interface to a cryptographic program or a program that's dynamically linked against a cryptographic library should not be distributed via the non-US server if it is capable of running without the cryptographic library or program. I am really not sure if this applies or not; if the program is linked against the ssl library, I doubt it can run without it, but if it isn't, which is doable with different Makefile settings, of course it doesn't require that library. I do see and agree with your point regarding the FTP servers. Would it be sufficient to add a README to the servers mentioning the restrictions, since they apply to so many different packages, and disclaiming responsibility for violations? Or maybe this wouldn't be legally valid, because people who use apt don't see that kind of thing. This is written shortly before I go to bed, so excuse me if anything doesn't make sense. - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [users] Re: Where's lame
Eric == Eric Van Buggenhaut [EMAIL PROTECTED] writes: Eric : it can't be included in debian, since it can't be legally Eric redistributed in binary form. Eric First part of the sentence might be correct, but not for *that* reason. Any package that cannot be distributed in the binary form, or any that otherwise fails to meet the DFSG, cannot be a part of Debian. Refer to the social contract for details. manoj -- By night an atheist half believes a God. -- Edward Young Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: USA crypto rules and libssl-dependent packages
On Thu, May 10, 2001 at 07:27:44PM -0400, Jimmy Kaplowitz wrote: Hi. I am a novice Debian package maintainer, in the queue for becoming an official developer. I am maintaining a package called althea, which is an IMAP email client for GTK+. They have recently added support for SSL through linking to libssl (from OpenSSL). This is configurable based on the values of a couple variables in the Makefile. I have a couple of questions: 1) I live in the US. Therefore, do I have to send a BXA notification to the government (I believe license exception TSU is applicable - correct me if I'm wrong)? You may. Since it's easy, you probablys hould. Also, do I have to do their thing that they mention on their website about sending a message to the ENC Classification Review Coordinator (or, something like that) in addition to [EMAIL PROTECTED], and if so, how do I do that? I think the email to [EMAIL PROTECTED] is sufficient. Also, is a BXA notification form sufficient to export binary .debs linked with libssl? Yes. Would anyone be able to export them, including other US mirror sites, so long as I provide an export of the same stuff that I notify the BXA about? Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. Thus Debian's requirement that export restricted software get uploaded to non-us doesn't apply. Indeed, this is how Netscape with strong crypto got uploaded to non-free instead of non-us/non-free. There's currently an inquiry going on that will determine if Debian's policy can be updated to clearly reflect the new regulations. 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. What about the Debian source files? Same. If I make additional non-ssl .debs from the same source, would they be in non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. [other stuff omitted] Good luck :) -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] pgppX4U1CXDUq.pgp Description: PGP signature
Advice regarding splitting package 'hitop'
I was wondering about doing this for some time, but events have forced my hand. hitop build-depends against libpgsql-dev which has become main/non-US. The situation as it stands is that 'hitop', a HTML preprocessor with pretentions to be an web-based application server, is one package. It is built in a modular fashion, whereby the 'plugins' (.so files) are dynamically linked when required at run-time. These plugins extend the functionality of core hitop, providing, for example, database connectivity. One such database plugin is for Postgresql. As most hitop users won't want to use the Postgresql plugin, I made the package Suggest libpgsql, since it merely provides additional features (makes plugin postgres.so work). My question is: would it be sensible to separate the plugins which have additional dependencies into separate packages (one for Postgres, another for MySQL, etc.)? If I did this, would I still have to move the hitop packages into non-US (since it would still build-depend upon libpgsql-dev which is now non-US)? Is there any way around this? Should I even care which part of the archive it goes in? -- Andrew Stribblehill [EMAIL PROTECTED] Systems programmer, IT Service, University of Durham, England
Re: [users] Re: Where's lame
On Thu, May 10, 2001 at 12:33:19AM +0200, Robert Bihlmeyer wrote: Paul Martin [EMAIL PROTECTED] writes: The RSA patent was only valid in the USA, an oversight on RSA's part. That's the difference. But surely a sizable chunk the Debian usersbase lives in the US, there were official CDs sold in the US containing the software, etc. So the difference is only gradual: more potentail users, and more mirrors (if mere distribution is really illegal) would be affected. What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? Friendly, Sven Luther
lame (again!)
Hi all, I would like clarify the reason for lame not being included in the debian archives, not even non-US. Firstly, the lame license is LGPL as of version 3.88. The psycho-acoustic model used in LAME is also GPLed (or LGPLed). I believe its not the same as the one patented by the Fraunhofer Institute. I could be wrong here, and correct me. This is what I understand from the lame homepage and changelogs. I don't see any restriction on lame being allowed to be distributed only in binary form, because of the LGPL license. As of version 3.81beta, all ISO code was removed. lame has already been debianised, and the debian/ subirectory for making the deb is included with the distribution now. However, this is immaterial, if it can't be packaged and made available through the official archives. So, what restricts us from making lame available ? Please cc me replies, as I don't read debian-legal. Thanks again, for allowing a rehash of an old thread. viral -- Live for today, gone tomorrow, that's me, HaHaHaa! pgpm4bMN7nCuB.pgp Description: PGP signature
Re: [users] Re: Where's lame
On Fri, May 11, 2001 at 11:00:01AM +0200, Sven LUTHER wrote: What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? I'm in India. I'm not sure about the official state of things here, though from what I figure, there shouldn't be a problem with patents here. I have not heard of a patent infringement case being filed here myself.. If people are interested, I could try to find out whats the scene here on patents like ? The fact is that there is a non-us is bad enough. I could probably even arrange for a non-patent archive here, but thats not the way we should be solving the problem. Freenet is another solution I can think of. However I just posted a mail on why lame can't be distributed, and I await replies to that one. There have been no concrete reasons given anywhere for that. I have also cc'd it to debian-legal. viral -- Live for today, gone tomorrow, that's me, HaHaHaa! pgpb6OETNZOyn.pgp Description: PGP signature
Seeking an advocate
Hello, First of all I apologise if this is considered OT, but I am interested in becoming a Debian maintainer, and currently stuck in the process waiting for an advocate. I am moderately familiar with Debian's package management system, have run various releases of Debian from 2.0 to Sid snapshots - currently running Progeny with recompiled Sid packages. Recently I have started packaging on my own, the first package being gtk-engines-crux (currently unreleased, planning to put it up on a website soon). If any maintainer is interested in helping out it will be much appreciated :) Thanks Michel Salim Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: My First Package. Wheee.
On Thu, May 10, 2001 at 12:56:49PM -0500, Michael Janssen (CS/MATH stud.) wrote: In Warren Anthony Stramiello's email, 10-05-2001: It's XDrawChem, a linux version of ChemDraw, a fairly necessary app for chemistry folks (at least so my girlfriend tells me, and she's a chemistry major here at Tech). Congratulations! If only it had been around when I was writing my thesis.. ;) I read through the docs and such (NMU docs, packaging-manual, and so forth), and I was wondering how I should handle: a) inclusion in the testing distribution, if still possible b) inclusion in the unstable distribution, if still possible To give a bit more detail from Tog's reply: you upload to unstable (this means you need to be running unstable yourself, unless you know how to do one of those chroot thingies). After a standard period of time (10 days for normal packages I think), the package gets copied (symlink) to testing if the following conditions are met: - binaries are available for main architectures (i386, alpha, sparc, but the others are lagging behind, so they won't hold up the package from testing) - no serious errors (normal errors don't hold it up) - the packages it depends on are also in testing The third one can be the tricky one to follow, since there might dependencies on dependencies and they have to be fulfilled all the way down. c) uploading using dupload and scp I think someone mentioned the New Maintainer's guide. Section 6.3 (I copy and paste from there, hence I don't know about dput either ;) ) Ohh.. cool - I've been looking for a software program to do something like this for a while for our labs.. If you need 3-D modelling, I've recently uploaded viewmol (lets you edit new molecules as well as view them). And something else was uploaded even more recently still (I forget the name). Chemistry in Debian is having it's day... ;) Section Science was recently opened on the Debian website (it had been forgotten), maybe that's attracting all these chem packages? Regards, Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: My First Package. Wheee.
To give a bit more detail from Tog's reply: you upload to unstable (this means you need to be running unstable yourself, unless you know how to do one of those chroot thingies). After a standard period of time (10 days for normal packages I think), the package gets copied (symlink) to testing if the following conditions are met: - binaries are available for main architectures (i386, alpha, sparc, but the others are lagging behind, so they won't hold up the package from testing) - no serious errors (normal errors don't hold it up) - the packages it depends on are also in testing Do the autobuilders build packages for all the architectures, or is the maintainer supposed to do that ? viral -- Live for today, gone tomorrow, that's me, HaHaHaa!
Re: My First Package. Wheee.
On Fri, May 11, 2001 at 07:06:05PM +0530, Viral wrote: Do the autobuilders build packages for all the architectures, or is the maintainer supposed to do that ? The autobuilders do that. You only compile on your own system, generally. I was even surprised to find that viewmol managed to get itself compiled on ia64 :) I must tell the upstream author, he'd be pleased to know... Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: perl modules - building debs
On Thu, May 10, 2001 at 11:45:16PM -0400, Derek Evan Mart wrote: After several hours attempting to build debian packages for perl modules and twenty minutes searching google for helpful documentation, I have come to the conclusion that I have no frelling idea what I am doing. =) I read that there is a perl module that would build a package from any module on cpan. I also read something about dh_make_perl, although I can not find anything like that on my system. apt-get install dh-make-perl The program itself is also called dh-make-perl. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Where to find woody...
Hi, I'm just wondering if I should install woody on my machine to compile a package, or I can use one of Deban machines. The problem is - there is no x86 machine running woody on the machines.cgi list. So the question is - is the list wrong, not full, or I have to get woody locally to maintain a package prepared for woody? honey -- http://7thGuard.net/
Re: How to locally sign a package that has been built on another machine?
On Thu, May 10, 2001 at 08:58:26AM +0200, Marc Haber wrote: On Mon, 7 May 2001 21:49:12 +0200, Filip Van Raemdonck [EMAIL PROTECTED] wrote: The tools available for automatic changes signing seem to do this for you. Yes, they do. Judging from the debsign source, this is a gpg issue. However, debsign fails for me because gpg returns some strange error codes: |[EMAIL PROTECTED]/523]:~/tmp$ ( cat run_0.9.2-6.dsc ; echo ) | gpg |--local-user Marc Haber [EMAIL PROTECTED] |--clearsign --armor --textmode --output - - run_0.9.2-6.dsc.asc |gpg: /usr/lib/gnupg/rsa: error loading extension: /usr/lib/gnupg/rsa: |cannot open shared object file: No such file or directory | |You need a passphrase to unlock the secret key for |user: Marc Haber [EMAIL PROTECTED] |1024-bit DSA key, ID 6BBA3C84, created 2000-02-15 | |passphrase is overwritten after pressing enter |[EMAIL PROTECTED]/524]:~/tmp$ echo $? |2 Is the return code 2 the result of rsa missing? Recent versions of debsign gives the following message in this situation (since version 2.5.13, December 2000): /usr/bin/debsign: GPG error occurred! If you are using gpg version = 1.0.3-2 and saw a gpg error message: error loading extension: /usr/lib/gnupg/rsa(ref) above, please remove the load-extension rsa or load-extension rsaref line in your ~/.gnupg/options file to ensure the correct functioning of this (and possibly other) programs. Aborting Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: perl modules - building debs
* Derek Evan Mart ([EMAIL PROTECTED]) [010510 23:45]:
What is the best way to approach this issue? Are there any FAQs/HOWTOs
which explain this process? Any informative replies will be appreciated,
rtfms will be tolerated. =)
OK, perhaps someone can answer this question. I looked at an existing
module package and tried to make my mangled mess look the same.
The build halts and I get the following message every time:
dpkg-gencontrol: warning: unknown substitution variable ${perl:Depends}
When I replace perl:Depends with perl5, it completes the process,
however, everything is in the package accept for the module itself.
I respectfully request tutoring from someone with perl module experience. =)
--
Derek E. Mart Marticus - Systems Programmer II
U of L - Electrical Computer Engineering
The Marticus Project - http://www.marticus.org/
1514 3659 D057 D10C 6BE6 3E68 15BE B181 2F1F 510B
pgpoHPE6aFqze.pgp
Description: PGP signature
Re: Creating man pages (upstream does not have one)
Othmar Pasteka [EMAIL PROTECTED] cum veritate scripsit: Hmm... anyone going to package manedit ? I tried it. It was rather fun to play with. It edits in roff. Should I upload it ? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d+ s:- a-- C+ UL P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ --END GEEK CODE BLOCK--
Re: perl modules - building debs
On Fri, May 11, 2001 at 10:22:16AM -0400, Derek E Mart wrote:
OK, perhaps someone can answer this question. I looked at an existing
module package and tried to make my mangled mess look the same.
The build halts and I get the following message every time:
dpkg-gencontrol: warning: unknown substitution variable ${perl:Depends}
When I replace perl:Depends with perl5, it completes the process,
however, everything is in the package accept for the module itself.
But this is incorrect. See the Perl Policy (now included in the
debian-policy package), it explains how to do it.
If you are using debhelper, make sure you Build-Depends(-Indep) on
debhelper (= 3.0.18) and include a call to dh_perl in your
debian/rules file. See /usr/share/doc/debhelper/examples/rules for
where to put it.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Advice regarding splitting package 'hitop'
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote: If I did this, would I still have to move the hitop packages into non-US (since it would still build-depend upon libpgsql-dev which is now non-US)? Is there any way around this? Should I even care which part of the archive it goes in? anything in non-us does not appear on the default Debian cd. Whether or not you care about this is another matter. That's a bit misleading. There are TWO versions of Debian CD 1, and *both* are official. One version is for folks in the US who wish to sell it to a customer outside the US. The other version is for everyone else. The poorly-named non_US is omitted from the first version of CD 1. -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: lame (again!)
Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. -- Marcelo | Mustrum Ridcully did a lot for rare species. For one [EMAIL PROTECTED] | thing, he kept them rare. | -- (Terry Pratchett, Lords and Ladies)
Re: lame (again!)
On Fri, May 11, 2001 at 10:14:22PM +0200, Marcelo E. Magallon wrote: Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. Lame is already included in the Debian archives in libmp3lame_audioenc.so.0 in libavifile in debian/main. It's in shared library form, but appears to be a fully functional mpeg-1 layer 3 encoder and not just a wrapper that invokes a lame binary the user already has on their system. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: lame (again!)
Brian Ristuccia [EMAIL PROTECTED] writes: On Fri, May 11, 2001 at 10:14:22PM +0200, Marcelo E. Magallon wrote: Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. Lame is already included in the Debian archives in libmp3lame_audioenc.so.0 in libavifile in debian/main. It's in shared library form, but appears to be a fully functional mpeg-1 layer 3 encoder and not just a wrapper that invokes a lame binary the user already has on their system. That's a bug then... (which I've just filed). -- James
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 01:51:54AM -0400, Brian Ristuccia wrote: 1) I live in the US. Therefore, do I have to send a BXA notification to the government (I believe license exception TSU is applicable - correct me if I'm wrong)? You may. Since it's easy, you probablys hould. Really? I am not doing any static linking with libssl, only dynamic, so I don't believe that I am including any crypto. This fact, which I realized after I sent my original message (otherwise I would have mentioned it), makes me still unsure whether a BXA notification is needed. Although I would like to know whether it is in fact required, if I am not persuaded that it is not, I will notify the BXA, because it's easy and it's a good idea to be safe, as you said. Also, do I have to do their thing that they mention on their website about sending a message to the ENC Classification Review Coordinator (or, something like that) in addition to [EMAIL PROTECTED], and if so, how do I do that? I think the email to [EMAIL PROTECTED] is sufficient. Thanks. Also, is a BXA notification form sufficient to export binary .debs linked with libssl? Yes. Thanks again. Would anyone be able to export them, including other US mirror sites, so long as I provide an export of the same stuff that I notify the BXA about? Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. Thus Debian's requirement that export restricted software get uploaded to non-us doesn't apply. Indeed, this is how Netscape with strong crypto got uploaded to non-free instead of non-us/non-free. There's currently an inquiry going on that will determine if Debian's policy can be updated to clearly reflect the new regulations. I would tend to agree, though of course IANAL; I am surprised Debian's policy hasn't been updated yet. 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. OK, I understand that this is a quirk of Debian policy, and not US law. What about the Debian source files? Same. I guess this makes sense, since there would need to be a Build-Depends on libssl-dev. (Am I right about that?) If I make additional non-ssl .debs from the same source, would they be in non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. Well, I don't intend to redistribute libssl, in my source or binary .debs, just dynamically link to them at compile and then run time. So do the non-ssl .debs go in the non-US/main or main? Good luck :) Thank you! I may also download the source of some package that comes in ssl and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking of lynx, myself. - Jimmy Kaplowitz [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, 11 May 2001, Jimmy Kaplowitz wrote: btw side note, why do all the ssl-enabled packages I've seen the source for, i.e. yours and lynx-ssl, depend on the obsolete package libssl096-dev instead of the current replacement package libssl-dev? Eh, because I hadn't noticed the problem yet? :) Fixed in CVS. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
