Re: Debian bugs #800000 and #1000000 contest
An obscure french DD. Wow, what a way to describe a person. Did that person kill your pet squirrel or something? :-) On Sat, Feb 9, 2013 at 4:54 AM, Christian PERRIER bubu...@debian.orgwrote: As the bug #70 mark was turned on February 7th 2013, Debian developers and contributors need yet another new challenge. So, for the fourth time, a small contest has been set up. It is very simple: please place a bet (one per person) about the day bugs #80 and #100 will be reported. The winner(s) will be the person(s) placing her|his|their bet as close as possible to the real moment bug #80 and #100 are reported. There is nothing to win but the pride of being the person who predicted our bug report rate for the next months|years, just what René Mayorga won twice for bugs #50 and #60 and an obscure french DD won for bug #70. The bet page is a wiki page: http://wiki.debian.org/80thBugContest It will be closed on April 30th 2013 (if I remember doing so!). Bets will be kept statically until bug #80 is reported. Please note that bets for bug #100 placed back in 2008 and 2010 are kept on this page. Do not modify that section but record your bet in Bets for bug #100, placed after bug #70, in 2013. --
Re: Debian bugs #800000 and #1000000 contest
LOL. No, I did not. And I also didn't realize I did a reply-all :-D Sorry guys and gals. On Sat, Feb 9, 2013 at 8:58 AM, Albin Tonnerre lu...@debian.org wrote: On Sat, Feb 9, 2013 at 5:23 PM, Tyler MacDonald ty...@macdonald.name wrote: An obscure french DD. Wow, what a way to describe a person. Did that person kill your pet squirrel or something? :-) You know Christian was talking about himself, right? :) -- Albin
Re: Standardizing use of kernel hook scripts
Darren Salt li...@youmustbejoking.demon.co.uk wrote: On Wed, Apr 01 2009, Frans Pop wrote: [make-kpkg] But is anyone still using it? Is there any current reason to support it Well, there's still some kernel options that are immutable and multiple choice. And there's always people that want to optimize. Out of laziness (or maybe having better things to do? g) my current setups aren't make-kpkg'ed, but it would depress me if, after using make-kpkg for years and years, I wanted to use it again one day and found that it didn't work anymore. Cheers, Tyler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
First, I'm a perl programmer so TMTOWTDI is pretty ingrained into my culture. I use mydns -- yi.org is based off of it, and I also use it as an easy way to set up dynamic virtual hosts for automated builds on another project, in conjunction with libapache2-mod-macro and mod_proxy on the frontend, and m4 to dynamically rewrite the port numbers of daemons in cdebootstrap-based chroot environments on the backend (the way this project is set up, whenever there is a new checkin into a subversion branch, we end up with a pristine debian environment running the software...) All these technologies are redundant -- why do we still have both debootstrap and cdebootstrap anyway? -- why do we still have squid if there's a mod_proxy? Why do we have libapache2-mod-macro if mod_perl or m4 can do all of that? Why do we even have PowerDNS *or* MyDNS now that BIND-DLZ is part of the mainline? Personally, I'm abandoning MyDNS in the mid-term as well, but if somebody wants to keep packaging it up for debian, please don't discourage them. Thanks, Tyler Russell Coker russ...@coker.com.au wrote: Having different programs to perform a task will decrease the portion of the user-base that runs a given program and if a bug is found it will give some degree of herd immunity. But the down-side is that more programs means more potential security flaws and spreading the time of people who want to fix security problems (including the security team) across more targets. The range of software that is available also adds to the work that I have to do in writing SE Linux policy. I am not complaining, merely noting a fact about the development work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#445866: ITP: perforce -- closed source revision control system
Sam Clegg [EMAIL PROTECTED] wrote: Perforce is an absolutely *excellent* VCS with the unfortunate distinction of being proprietary. SubVersion can do most (but not all) of what it does, albeit 10 times slower. Still, I've migrated all of my stuff over to subversion, because, well, subversion is free. Perforce is free (as in free beer) for open source developers, if you want more than 2 users on one VCS server, you have to sign a contract, get a license, give the perforce people full access to your repo, sign a new contract whenever you server's IP address changes, and renew each year Slightly off topic, but you don't need to give the perforce people access to you repo (unless you really want them to come in a fix something) and you don't need to renew each year (unless you want support from them). You don't need to go through all of that if you buy the product. If you get a free open source developmnet license, they want you to renew every year, and they want an account on your server so they can make sure you've only got open source code on there. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#445866: ITP: perforce -- closed source revision control system
Florian Weimer [EMAIL PROTECTED] wrote: Seems to me that this depends on Perforce. D'oh. (I don't know anything about Perforce. Perhaps it's really dangerous software. But perhaps it's just non-free.) Perforce is an absolutely *excellent* VCS with the unfortunate distinction of being proprietary. SubVersion can do most (but not all) of what it does, albeit 10 times slower. Still, I've migrated all of my stuff over to subversion, because, well, subversion is free. Perforce is free (as in free beer) for open source developers, if you want more than 2 users on one VCS server, you have to sign a contract, get a license, give the perforce people full access to your repo, sign a new contract whenever you server's IP address changes, and renew each year - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Mike Hommey [EMAIL PROTECTED] wrote: chroot without any admin intervention. If it's not appropriate to run inside a chroot, then the init script should IMHO detect that and not start/restart/stop the service. The fact is, not all chroot are buildd chroots, and many chroots actually do run services... Yep... but I still find it a bit annoying that I have to override binaries like start-stop-daemon or invoke-rc.d when building a chroot. I wish there was a way to just set a flag that means dpkg, don't start/stop any services!... instead I end up doing stuff like: invoke=/usr/sbin/invoke-rc.d cdebootstrap -f standard $SUITE $TARGET $MIRROR mount -t proc proc $TARGET/proc $chroot $TARGET $aptitude update || throw $chroot $TARGET /usr/sbin/dpkg-divert \ --add --rename --divert $invoke.orig $invoke || throw ln -sf /bin/true $TARGET/$invoke [bootstrap code...] /bin/rm -f $TARGET/$invoke $chroot $TARGET /usr/sbin/dpkg-divert \ --remove --rename --divert $invoke.orig $invoke || throw umount $TARGET/proc - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Steve Langasek [EMAIL PROTECTED] wrote: granted there are things like this, but reproducible builds would be fantastic and well worth the effort. If you're talking about byte-for-byte identical builds, then no, that would be a tremendous amount of effort for no practical gain. There's no reason to consider it a bug for packages to not be byte-for-byte identical between two builds, so why should anyone waste time trying to fix it? We should expect that given the same source, headers, and libraries, we would get the same bytes out of a build every time. Any deviation from this would indicate something different, or erratic. If it doesn't cause problems, fine, but I'd raise an eyebrow over it anyway. I guess it depends on how anal and pedantic you want to get. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Lars Wirzenius [EMAIL PROTECTED] wrote: printf(This program was compiled on __DATE__ \n); An example like the above has already been given. Build dates and other variable information gets put into a lot of output files from compilations. Sorry, I was speaking from an overly selfish point of view, or at least from the point of view of understanding (or wanting to understand) the code that you're building. I don't do stuff like that in my code, so if my code compiled differently twice in a row, I'd raise an eyebrow over that... - Tyler
I *love* goodbye-microsoft.com
... so I thought I'd take the liberty of registering goodbye-apple.com and goodbye-osx.com in order to protect the namespace. I'll gladly transfer them over to the first DD to code up something similar for that platform(s). :-) Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408315: ITP: mysql-workbench -- Official MySQL database schema designer / editor
Package: wnpp Severity: wishlist Owner: Tyler MacDonald [EMAIL PROTECTED] * Package name: mysql-workbench Version : x.y.z Upstream Author : MySQL AB * URL : http://dev.mysql.com/downloads/gui-tools/5.0.html * License : GPL Programming Lang: C Description : Official MySQL database schema designer / editor MySQL Workbench is a graphical tool for designing databases. It allows database administrators to design database schemas visually, and existing MySQL schemas can also be imported, edited in the graphical interface, then re-exported to a MySQL database server. This product is still in alpha, but appears to work well, and it already has a lot of useful functionality. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Roger Leigh [EMAIL PROTECTED] wrote: The majority of the Debian (and GNU/Linux systems in general) I see tend to not use NFS at all. Do we have any usage statistics for the NFS client? There is this: http://qa.debian.org/developer.php?popcon=nfs-utils But I don't know how accurate the old count is, since everyone with it installed has it at least run it's init.d script on boot... - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I rebuild alternative symlinks?
I found a way to do it, but I think the solution was less than ideal:
Install Debarnacle from CPAN (isn't even in debian...)
Run this command:
perl -MDebian::Debarnacle::Alternatives -e 'my $i =
Debian::Debarnacle::Alternatives-get_list; while(my($l,$r) = splice(@$i,0,2))
{ symlink($l,$r); print $l $r\n; }'
Now I have all my symlinks back... but I have a few questions still:
1) is there a way to do this with just dpkg?
2) if not, should there be? (update-alternatives --reinstall-all?)
3) is it a bug or feature that keeps update-alternatives from installing
the symlinks in usr/bin and elsewhere if the ones in /etc/alternatives
already exist?
Thanks,
Tyler
Tyler MacDonald [EMAIL PROTECTED] wrote:
I just moved a debian installation from one system to another by mirroring
/opt, etc, /home, /var, and /usr/local -- and then using dpkg
--set-selections to get all the same packages installed on the new box.
Everything's gone great except for the alternatives system. For some reason,
none of the symbolic links in /usr/bin (and i'm guessing anywhere) were
reinstalled when I reinstalled the packages that provide them.
I see that there's a lot of state data in /var/lib/dpkg/alternatives -- is
there any way to tell dpkg or update-alternatives to read that state data
and make everything the way it should be, or am I going to have to
reconfigure each alternative manually?
Thanks,
Tyler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Charles Plessy [EMAIL PROTECTED] wrote: Maybe the debian website would deserve a section in which Debian communicates on those issues. After all, I think that they are similar in concept (but not in gravity) to recalls seen in the industry: a broken material was released, so special communication could help to contact the users, explain the problem, and help them to fix it. Hmm, like a top bugs section on the front page of debian.org? That would be interesting. Specific bugs could be added to the list (and fall off, say, a week after they are closed), and bugs that are seeing a lot of activity could step in blanks when there's not enough manual bugs to fill the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tpkg-debarch should support arm-linux-gnu target (was Re: small quirks setting up a cross-compile toolchain)
Package: toolchain-source Severity: grave Tags: patch toolchain-source as it stands is currently unusable for building ARM cross-compiler targets. It appears that you must specify arm-linux-gnu to several of the builds in order to get the install to work correctly. However, this target is not supported by tpkg-debarch. The attached patch is not a complete solution, but it at least makes it *possible* to build for arm again (so long as you use the magic arm-linux-gnu incantation). Nathanael Nerode [EMAIL PROTECTED] wrote: See, there's your problem. Try: tpkg-make arm-linux-gnu TPKG_SERVER=ftp.yi.org tpkg-install-libc arm-linux-gnu And you should end up with only arm-linux-gnu. For obscure reasons (which I would like to get rid of), some parts of the cross-tools structure care about exactly what form of the system name you give to the tools, while others use the canonical name. If you still end up with two different things come back and complain to whoever's generating arm-linux. Okay, so when I did that, I would get this message every so often: Hmph - dunno the arm-linux-gnu arch ... and then eventually: http://ftp.yi.org/debian/dists/testing/main/binary-none/Packages.gz = /tmp/tpkg-install-libc.CMosC11963/packageset.gz' Resolving ftp.yi.org... 209.172.55.241 Connecting to ftp.yi.org|209.172.55.241|:80... connected. HTTP request sent, awaiting response... 404 Not Found 09:49:26 ERROR 404: Not Found. binary-none, eh? So I added arm-linux-gnu to tpkg-debarch, and that made it work!!! --- /usr/bin/tpkg-debarch 2005-01-06 08:26:04.0 -0800 +++ /usr/bin/tpkg-debarch.new 2006-07-28 10:10:29.0 -0700 @@ -4,7 +4,7 @@ alpha-linux) debarch=alpha ;; -arm-linux|arm) +arm-linux|arm-linux-gnu|arm) debarch=arm ;; hppa-linux|hppa)
Re: Why does Ubuntu have all the ideas?
Matthew Garrett [EMAIL PROTECTED] wrote: Personally, I have no problem with this. But if Debian is unwilling to fill these (not terribly niche) requirements itself, it's not reasonable to complain when people build on Debian in order to provide a more complete solution for a more narrow use case. Isn't the Task: package header (and maybe the Tag: header as well) and the corresponding menu options in the debian-installer supposed to make debian magically morph into whatever you want it to be? A few messages ago there was a message about update-notifier, and how it wouldn't be installed and/or enabled by default due to administrative access issues, etc... if someone specifically says that they are installing a debian desktop system, would it then make more sense to auto-install, config, and enable update-notifier? If not for the entire users group, then at least for the user that's created on system install, that gets added to cdrom, floppy, audio, and video groups already? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
small quirks setting up a cross-compile toolchain
Hello, I've been following the directions here: http://www.mobilab.unina.it/Resources/crosscompilerHOWTO.html attempting to set up a cross-compiler toolchain for my ipod. So far, I've run into a small quirk; half of the files get installed to /usr/arm-linux, the other half to /usr/arm-linux-gnu. So far I've had to symlink /usr/arm-linux-gnu/include and /usr/arm-linux-gnu/lib/* into /usr/arm-linux in order to get gcc to compile. Has anybody else run into this? Is there something I can do that's cleaner and closer to The Debian Way than manually making symlinks? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: small quirks setting up a cross-compile toolchain
Aaron M. Ucko [EMAIL PROTECTED] wrote: Tyler MacDonald [EMAIL PROTECTED] writes: Has anybody else run into this? Is there something I can do that's cleaner and closer to The Debian Way than manually making symlinks? Install the Debian toolchain-source package and go from there. That's exactly what I did: apt-get install -y \ autoconf2.13 \ toolchain-source toolchain-source-gdb \ toolchain-source-newlib \ dpkg-cross dejagnu expect gperf dpatch gobjc cdbs quilt \ expectk patchutils equivs fakeroot cd /usr/src tpkg-make arm-linux cd binutils-arm-linux-* debuild --no-tgz-check -uc -us debi TPKG_SERVER=ftp.yi.org tpkg-install-libc arm-linux I end up with a /usr/arm-linux and /usr/arm-linux-gnu :-/ - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
header sanity check?
I just created a /usr/local/include/hi_there.h , #include'd it from a header
file, and built a -dev debian package containing that header file without
any sort of warnings or errors.
So it's really easy to package a -dev package with a header file, that
#include's a header file in a package that it doesn't depend on.
Going through Developer's Corner I don't see anything that helps define how
to catch this or if there are any requirements. pbuilder won't even catch it
if the Build-Depends for the source package contains all the -dev packages
needed.
Is there anything like dh_headerdeps or guidelines on how -dev packages
should depend on eachother?
My gut feeling is that:
1. If you #include a header directly, you have to depend on that
package.
2. If you #include a header of a package that #includes a header
whose definitions you use (eg; #including httpd.h and then using apr_
stuff), and stick to stuff that is part of the former header's published
interface (eg; using apr_status_t), you're okay if you just depend on the
former -dev package.
3. If you do the above but use part of the latter's header that
*isn't* part of the former's public interface (eg; APR_HAS_UNICODE_FS), then
you're not only dealing with (or being) a lazy C programmer, you also have
to depend on the latter -dev package as well.
4. If you #include a header that doesn't belong to *any* package
(including the source package you're currently building), that's just
outright evil.
I also think that #1 and #4 would be easy (trivial, even) to catch in some
automated way, and that would make an excellent addition to lintian and/or
linda... #2 and #3 might be more tricky. At least determining #1, and
providing a ${headers:Depends} value would be a valuable tool to
maintainers and should be possible in most cases.
Is it worth doing? Has it been done or hashed out already?
Thanks,
Tyler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #195752: Can somebody mark this bug as grave or critical?
Stephen Gran [EMAIL PROTECTED] wrote: Have you looked at the package description that this bug is about? This is quite a bit more than DHCP client. While I would be unhappy about having machines I need access to have their addresses assigned by DHCP, it is trivial to configure the server side for static IP assignments, and it's also a decades old, robust technology. This is someone hanging their 'server' off of a tin can and string and being surprised it fell off the network. No, it isn't. That wasn't my server, it is a laptop. My pbuilder dist on there is sid, and I was just doing a dselect-upgrade before I did a test build, in case that fixed the recent tar problems. laptop-net says that it will do stuff when the cable is plugged in or unplugged, *not* when it's upgraded, started up, or shut down. Any application screwing with your network interfaces during an upgrade better at least ask you first. It's the sort of thing that can kill a dselect-upgrade halfway through with no ability to get back in, just like installing a fresh kernel with the same version as the kernel being installed, or upgrading libc, which is why those packages have prompts for upgrading to make sure you're really ready. When you upgrade dhclient, it doesn't take your network interface offline and start from scratch. When I am in front of the keyboard, unplugging and plugging in connections, it's great that laptop-net does it's thing. But when I am connecting remotely and a debian upgrade just happens to cut me off of the internet, I get pissed off. I've removed the software from my laptop until this bug is fixed. I think that this behaviour is dangerous enough that it should not be allowed in any sort of software update without a huge fat warning, whether that's a debian update or any other distro/OS. The maintainer of the package has said he is going to try and fix this, so this problem should be moot soon. :) - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
These new diffs are great, but...
Is it at all useful/better for apt-get to use the .pdiff files when dealing with a local (file://) debian repo? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
#195752: Can somebody mark this bug as grave or critical?
I just did an upgrade, and laptop-net caused my network interface to disappear. This is documented here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195752 laptop-net restarts network interfaces when it is upgraded. This is *nasty*. If you are upgrading over a network, this causes your controlling terminal to disappear, leaving dpkg hung. If other packages are being upgraded at the same time, this can leave the entire system in an unusable state. Furthermore, if the network restart fails for some reason, the entire box is essentially killed: $ ssh [EMAIL PROTECTED] ssh: connect to host fliplid port 22: No route to host I'm *FURIOUS* that this bug has caused me to lose access to my laptop, and incredulous that THIS HAS BEEN A BUG FOR THREE YEARS!!! ... especially because it's configured to just leave the network interface alone when it's working. It's only supposed to drop/raise connections when the cable is unplugged/plugged in. *sigh* Looking at the bug's history it seems like they've tried to fix it a few times and failed. I guess I'm going to purge this package and just do an ifdown/ifup manually when I need to from now on. But yeah, I'm not in an official position to say, but if this isn't considered a critical or at least grave bug, then I don't know what is. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote: Not really. pdiff's mainly reduce download size for low bandwidth connections. file:// is pretty high bandwidth, you won't notice the difference. I usually notice the difference -- the other way. aptitude update on a machine that hasn't been updated in a while suddenly takes minutes instead of seconds... Yes, this is what I'm getting at. :-) Should this be considered a bug in apt-get (file:// urls should never use diffs)? - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Henning Makholm [EMAIL PROTECTED] wrote: Well, in fact also design a mechanism to share knowledge about which source packages may break if given a -j due to insufficiently specified dependencies. So perhaps using $(DEB_MAKE_J_OPTION) on the $(MAKE) all line in debian/rules is a better choice after all. I would like to suggest that we use $(CONCURRENCY_LEVEL) instead, because there is is prior debian art (kernel-package) that does this already. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Lars Wirzenius [EMAIL PROTECTED] wrote: It has come to my attention that the gem package is currently built using 'make -j 4', to have four compiler processes running at the same time. This is a bit troublesome for the poor m68k buildd, which is now suffering under High Load And Constant Swapping (HLACS). As far as I can see, using make's -j option is only useful if you have multiple processors. Packages should not make such assumptions of the build environment. If package maintainer wants to build it faster on their own machine, I would imagine that checking for an environment variable (DEB_MAKE_OPTS or something, perhaps?) and using that would be the way to go. By default, build with a single processor. kernel-package uses the CONCURRENCY_LEVEL envrionment variable for this. And if I do a CONCURRENCY_LEVEL=4 on my single-CPU system, it does actually go quite a bit faster. :) - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375014: ITP: libtap -- Unit test building library for the Test Anything Protocol
Package: wnpp Severity: wishlist Owner: Tyler MacDonald [EMAIL PROTECTED] * Package name: libtap Version : 0.0.0 Upstream Author : Nik Clayton [EMAIL PROTECTED] * URL : http://jc.ngo.org.uk/svnweb/jc/browse/nik/libtap/trunk/ * License : MIT-like Programming Lang: C Description : Unit test building library for the Test Anything Protocol libtap is a C library that provides simple functions to assist in writing unit tests that conform to the Test Anything Protocol (TAP). . TAP is a simple text output of unit test results that can easily be parsed by utilities such as prove(1) and complex QA applications such as Smolder (http://sourceforge.net/projects/smolder/). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
message/rfc822
Is there any (console|gui) package in debian that can easily be used to open a message/rfc822 attachment and browse it like a regular email? You may think this is a poor question to ask debian-devel, but the reason I am asking is because debian BTS doesn't expand rfc822 inlines (so when you click on one from BTS in debian firefox it asks you if you want to download an EML file), and while that'd be a nice feature for BTS, it'd be an even nicer feature for debian as a whole. My favourite MTA is mutt, but it expects a proper mbox, not just one message, so I may consider contributing this to that project as well, but if there's something in debian that can fix this already, I'd be really interested in helping close that link. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unstable? nah. :-)
http://www.crackerjack.net/adserton3.png That production server has been running debian/unstable since it's inception in january of 2004, with dselect updates happening every couple of days. It was running apache, postfix, mysql, mydns. Despite being unstable, there was never a problem that resulted in more than a couple of minutes' downtime during updates. It was finally retired today, after 875 days of uptime, not because there was a problem with it, just because there was a price problem with the hosting provider it's colocated at. For an unstable distribution, it gave me the most stable server experience I've ever had. Go debian! - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable? nah. :-)
Sebastian Harl [EMAIL PROTECTED] wrote: http://www.crackerjack.net/adserton3.png On that picture it says the box is up for 378 days. How does that go with 875 days idle time? Due to a bug with w, or the kernel, or whatever, which nobody seems to want to fix, the system uptime wraps around to 0 days after 400-and-someodd days. That's why I circled the login/idle time on the screenshot. :-) Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable? nah. :-)
Ron Johnson [EMAIL PROTECTED] wrote: That production server has been running debian/unstable since it's inception in january of 2004, with dselect updates happening every couple of days. It was running apache, postfix, mysql, mydns. Despite being unstable, there was never a problem that resulted in more than a couple of minutes' downtime during updates. Go debian! That rocks. What did the machine do? (I want to forward this email to a Windows admin friend of mine.) It was the primary webserver for http://www.yi.org/ , a free dyanamic DNS provider and domain registration service. It also hosted several of my friend's websites, running phpbb and movable type. As of a few weeks ago, the last few straggling websites have been ported over to the new server (libertas.crackerjack.net) in montral, which incidentally also now hosts a debian mirror, a CPAN mirror, and http://cpants.perl.org/ . I moved the server because wedohosting.com's bandwidth fees were getting prohibitive (i'm with iweb.ca now).. otherwise I would have been happy to have it continue running for another few thousand days. :-) Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable? nah. :-)
Steinar H. Gunderson [EMAIL PROTECTED] wrote: It was finally retired today, after 875 days of uptime, not because there was a problem with it, just because there was a price problem with the hosting provider it's colocated at. For an unstable distribution, it gave me the most stable server experience I've ever had. Do you ever security update your kernel...? I didn't on that server. Honestly, I'm more worried about a system that's locked in a server room a ferry or plane ride away from me not coming back up after a reboot. ;-) I have access to a web powerbar for my new server, and there's some level of 24 hour support, so I'm able to risk the occasional reboot now... - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unstable? nah. :-)
Anthony Towns aj@azure.humbug.org.au wrote: No it wouldn't; it'd just require you to have two extra ints, and something that ran every so often (and as part of any syscall that tells userspace the uptime), that does: static unsigned last_uptime = 0; static unsigned wraps = 0; if (uptime last_uptime) wraps++; last_uptime = uptime; You could probably even do it in userspace, really, with some care. This is the most sensible answer I've heard about this (and I've bitched about the limitation a lot). Maybe it's time for me to delve into the kernel source for the first time in 10 years. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Roger Leigh [EMAIL PROTECTED] wrote: IMO dotfiles are a historical artifact which we are stuck with. If we were just starting today, I'm sure we would be using ~/etc/bashrc rather than ~/.bashrc so the user's files match the standard locations. It's logical, simple, and would make many things easier. While historical reasons are acceptable for users' dotfiles, I remain to be convinced that there is a logical rationale for them in any system location, or even anywhere under $HOME except the root. For most cases I agree, there's little point to it, but I don't think they pose a real security risk either. I mean, find will reveal them by default, and for the really security-concious, it's easy to alias ls to ls -a. And I can see a use for them in global directories, for files that you should not modify unless you *really* know what you are doing. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
spam on debian-* lists
Question: Is SpamAssassin or greylisting used on lists.debian.org? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red team attacks vs. cracking
Javier Fern?ndez-Sanguino Pe?a [EMAIL PROTECTED] wrote: Is this really a bad thing? He proved that KSP are bad for the web of trust. A legitimate attacker could abuse the KSP just as easilly as Martin, but would result in actual damage, and would most likely not have been caught. Ask yourself: is it a good thing to covertly attack X? Is it good to then publish of the results [1] claiming^Wboasting that you have broken X? Do you really need to be proven that X can be broken? Now change X to KSP or Web server of company Y or (your country's) national security servers. What are your answers? I have no opinion that I wish to state in this *particular* case, but in general, I support it. I like this page: http://www.dataloss.net/papers/how.defaced.apache.org.txt From the bottom of the page: We would like to compliment the Apache admin team on their swift response when they found out about the deface, and also on their approach, even calling us 'white hats' (we were at the most 'grey hats' here, if you ask us). I'm not saying everybody should be as accommodating as the ASF when their security gets compromised, but if somebody *does* hack you, then tells you how they did it, and they doesn't invade your privacy or do any harm to your stuff, then they have done you a service. [1] I will call it publish even if it was done in a rather obscure way. Not all developers are required to read Martin's blog, they are only required to read d-devel-announce If Martin didn't tell the debian team right away after he illegally crossed the fence, then that was irresponsible, but I still have no opinion as to what should be done with him. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Steve Langasek [EMAIL PROTECTED] wrote: - When the API becomes incompatible (which would implicitly make the ABI incompatible), both the -dev and library package should increment their numbers. - When the ABI becomes incompatible without affecting the API, only the library package should increment it's number. Is that right? With changing the package name on API changes being optional as well, since API changes generally affect build-dependencies only, not dependencies, are thus largely invisible to users, and in the general case don't tend to happen in a way that justifies updates to all packages that would build-depend on it. Makes sense... But if you think you'll be making sufficient backwards-incompatible changes to the library API to warrant such package name changes, yes, the above is the right way to go about it. I do. I can easily see thread safety and abstracting database interaction causing API changes in the future. Thanks! - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposal for a more efficient download process
Goswin von Brederlow [EMAIL PROTECTED] wrote: That is quite unacceptable. We have debs in debian up to 160Mb (packed) and 580Mb unpacked. That would require 2.7 Gb and nearly 10Gb ram respectively. Seems to be quite useless for patching full debs. One would have to limit it to a file-by-file approach. True.. It'd probably only be efficient if the deltas were based on the contents of the .deb's before they're packed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Mike Hommey [EMAIL PROTECTED] wrote: Ondrej, The source package is named mod-bt. It produces the following .deb's: libbttracker0-dev_0.0.16-1_i386.deb libbtutil0-dev_0.0.16-1_i386.deb There's no reason to have the so version in the -dev package name. Odd, because my package depends on libapr0-dev (probably going to be libapr0-dev | libapr1-dev soon), and an apt-cache search for 0-dev on my system turns this up: guile-gnome0-dev - Guile GObject binding support library, development files libabz0-dev - Development files for the abz library libadasockets0-dev - bindings for socket services in Ada libannodex0-dev - annotated and indexed media library (develoment files) libapr0-dev - development headers for libapr libapr1.0-dev - The Apache Portable Runtime Library - Development Headers libaprutil1.0-dev - The Apache Portable Runtime Utility Library - Development Headers libaqbanking0-dev - library for online banking applications libart-2.0-dev - Library of functions for 2D graphics - development files libartsc0-dev - development files for the aRts sound system C support library libassa3.4-0-dev - object-oriented C++ networking library libatk1.0-dev - Development files for the ATK accessibility toolkit libbelpic0-dev - belgian eID PKCS11 library, development files libber0-dev - Development files for the BER library libcairomm-1.0-dev - C++ wrappers for Cairo (development files) libcamelbones0-dev - the development files for the CamelBones framework libcapi20-dev - libraries for CAPI support libcdparanoia0-dev - Shared libraries for cdparanoia (development files) libcharles0-dev - Data structure library for Ada95 modelled on the C++ STL libcherokee-base0-dev - extremely fast and flexible web server - development files libcherokee-client0-dev - extremely fast and flexible web server - development files libcherokee-server0-dev - extremely fast and flexible web server - development files libclutils0-dev - Development files needed to compile programs that use clutils. libcoin20-dev - high-level 3D graphics kit - development libcoin40-dev - high-level 3D graphics devkit with Open Inventor and VRML97 support libconfig0-dev - Development files for the config library libcteco5000-dev - Orga Eco 5000 smartcard reader CT-API development files libdancer-xml0-dev - simplistic and non-comformant xml parser library libdbaudiolib0-dev - Communicate to the DBMix audio system (development files) libdbh1.0-dev - Development files for libdbh1.0 libdbi0-dev - Database Independent Abstraction Layer for C (dev files) libdc0-dev - Development libraries for Valknut libdebug0-dev - Development files for the debug library libdisplaymigration0-dev - display migration support for GTK [development] libdlisp0-dev - Simplistic lisp type file parser (development) libdm0-dev - Data Management API static libraries and headers libdmsocket-0.32.5-0-dev - socket utility library -- development files. libdnas-application-0.32.5-0-dev - DNAS application libs -- development files. libdnas-core-0.32.5-0-dev - DNAS core networking library -- development files. libdvdplay0-dev - development files for libdvdplay0 libeid0-dev - library to read identity information from the Belgian eID card - development files libelfg0-dev - an ELF object file access library: development files libelfsh0-dev - The ELF shell library libelk0-dev - development files for libelk0 libesd0-dev - Enlightened Sound Daemon - Development files libfoundation1.0-dev - Development files for libfoundation libg2c0-dev - GNU Fortran 77 library development libgenders0-dev - development files for parsing and querying a genders database libgfortran0-dev - GNU Fortran library development libggigcp0-dev - GGI Color and Palette Manager extension development package libggiwmh0-dev - GGI Window Manager Hints extension development package libgii0-dev - General Input Interface development package libgimp2.0-dev - Headers and other files for compiling plugins for The GIMP libgksuui1.0-dev - a graphical fronted to su library (development files) libglade-bonobo0-dev - Development files for libglade (Bonobo controls support) libglade-gnome0-dev - Development files for libglade (Gnome widgets support) libglade0-dev - Development files for libglade libglib2.0-dev - Development files for the GLib library libgnetwork1.0-dev - networking wrapper library using Glib/GObject (development files) libgnomecups1.0-dev - GNOME library for CUPS interaction (headers) libgnomecupsui1.0-dev - UI extensions to libgnomecups (headers) libgnuift0-dev - libgnuift development files libgnuradio-core0-dev - Software Defined Radio libgnustep-gui0.10-dev - GNUstep Gui header files and static libraries libgpepimc0-dev - category management for GPE applications [development] libgpevtype0-dev - data interchange library for GPE applications [development] libgpib0-dev - C bindings for GPIB (IEEE 488) kernel driver -- headers libgsl0-dev - GNU Scientific Library (GSL) -- development package
Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Sune Vuorela [EMAIL PROTECTED] wrote: Odd, because my package depends on libapr0-dev (probably going to be libapr0-dev | libapr1-dev soon), and an apt-cache search for 0-dev on my The versionings is when stuff change to incompatible APIs, so probably depending on (libfoo0-dev | libfoo1-dev) should not be possible. If there is no change in APIs, there is no need for versioning of the -dev package. You can alwayls add a versioning number on api-change. In APR's case, there are some small incompatibilities in the APIs between version 0 and version 1, but many packages can still compile successfully against either. And yeah, in libbttracker, etc.'s case, I don't plan on changing the soname until there's an incompatibility. Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Steve Langasek [EMAIL PROTECTED] wrote: You're missing the point that sonames track *ABI* changes, and -dev package names should track *API* changes. Typically, upstreams make API changes on new major releases; ABI changes can happen much more often than this. Tracking sonames in your -dev package names is therefore wrong and (inevitably, eventually) causes gratuitous churn for any packages build-depending on yours. OK, so it sounds like this is what you are saying: Since this is the first public API *and* ABI, both counters should start at zero. - When the API becomes incompatible (which would implicitly make the ABI incompatible), both the -dev and library package should increment their numbers. - When the ABI becomes incompatible without affecting the API, only the library package should increment it's number. Is that right? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Package: wnpp Severity: wishlist Owner: Tyler MacDonald [EMAIL PROTECTED] * Package name: mod-bt Version : 0.0.16 Upstream Author : Tyler MacDonald [EMAIL PROTECTED] * URL : http://www.crackerjack.net/mod_bt/ * License : Apache 2.0 Programming Lang: C, language bindings in PHP and Perl Description : BitTorrent tracker for the Apache2 web server mod_bt is a BitTorrent tracker for the Apache Web server. It is written in C and runs as an Apache 2.x module. It is possible for mod_perl or PHP to directly access the tracker's information; no need to download and bdecode scrape URLs. The tracker is fully configured from within Apache's own configuration file. The goal of mod_bt is to seamlessly integrate Bram Cohen's BitTorrent protocol with Apache so that any Webmaster who serves up large files can shift the burden of bandwidth onto its clients with as little hassle as possible. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.6 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: Please revoke your signatures from Martin Kraff's keys
Paul Johnson [EMAIL PROTECTED] wrote: On Thursday 25 May 2006 08:30, Manoj Srivastava wrote: Given time, one can pay more attention to each document (I require at least two photo ID's issued by the government). WTF? In Oregon, if you have a driver's license, you cannot get an ID card. If you have an ID card, you have to surrender it to get a driver's license. You're only legally allowed one ID. Weird! You can still keep your birth certificate and social security card though, right? It's always bugged me the most legal, verifiable photo IDs require you to have your home address on them. These are the same things that people use to verify their age when getting into night clubs or buying cigarettes. Whose to say a cashier or a bouncer isn't some creepy stalker who is going to follow you home? - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368985: ITP: mod-bt -- BitTorrent tracker for the Apache2 web server
Ondrej Sury [EMAIL PROTECTED] wrote: On Fri, 2006-05-26 at 08:07 -0700, Tyler MacDonald wrote: * Package name: mod-bt I suggest to name your package (you can name just binary package, but it since you are building just one binary package, it's easier to rename source package as well) as libapache-mod-bt to follow common practice when packaging apache modules. Ondrej, The source package is named mod-bt. It produces the following .deb's: libapache2-mod-bt-dev_0.0.16-1_i386.deb libapache2-mod-bt_0.0.16-1_i386.deb libapache2-modbt-perl_0.0.16-1_i386.deb libbttracker-utils_0.0.16-1_i386.deb libbttracker0-dev_0.0.16-1_i386.deb libbttracker0_0.0.16-1_i386.deb libbtutil-utils_0.0.16-1_i386.deb libbtutil0-dev_0.0.16-1_i386.deb libbtutil0_0.0.16-1_i386.deb libnet-bittorrent-libbt-tracker-perl_0.0.16-1_i386.deb php5-apache2-mod-bt_0.0.16-1_i386.deb Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposal for a more efficient download process
I. the reason why i suggest a patch-oriented download process +1. We've been using bsdiff (http://www.daemonology.net/bsdiff/) at work for some internal stuff and it's great. Furthermore, since unstable has gone to using diffs for the Packages files, my dselect updates have been *way* faster. Having the actual downloads go faster as well would be awesome. Some work will have to go into the math to determine when it's actually more efficient to download the latest archive, etc just a fleeting mental note, the threshold should not be 100% of the full archives size, it should be 90 or 80% due to the CPU/RAM overhead of patching and the bandwidth/latency overhead of requesting multiple patch files vs. one stream of data. Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no libldap-dev from openldap2.2 package?
Russ Allbery [EMAIL PROTECTED] wrote: You can't right now because GnuTLS support is only available for 2.1. 2.2 and later will need substantial reworking of that support, and without it, the OpenSSL licensing issues cause too many licensing conflicts in Debian for it to be safe to provide a -dev package that people can use widely. I'm pretty sure that we can get funding to do the GnuTLS support for OpenLDAP properly. It's just taking a really long time to work through that process. Speaking of GnuTLS, postgresql developers are on the verge of being able to support it as an alternative to OpenSSL, primarily to allow GPLed code to link against libpq in Debian. Here's some history: postgresql-general: http://marc.theaimsgroup.com/?t=11443445523r=2w=2 openssl-users: http://marc.theaimsgroup.com/?t=11446062722r=2w=2 freeradius-users: http://marc.theaimsgroup.com/?t=1187812r=1w=2 Martijn van Oosterhout says he has begin working on this: http://marc.theaimsgroup.com/?l=postgresql-generalm=114570109002832w=2 But it hasn't been without caveats: http://marc.theaimsgroup.com/?l=postgresql-generalm=114571510900274w=2 http://marc.theaimsgroup.com/?l=postgresql-generalm=114572079501988w=2 It would take me awhile to get my head inside either codebase, but I'm sure the help of a seasoned pg and/or gnutls debian developer would be extremely helpful to get a lot of postgres-backed GPL apps into debian. Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-minimal
Steve Langasek [EMAIL PROTECTED] wrote: No, that's not what I said. The python-minimal package is designed to be used *as* an Essential package, not *by* Essential packages. Nothing, essential or not, should depend on it in Debian, whether or not python-minimal itself gets marked as Essential: yes. (As long as python-minimal is not essential, you don't depend on it because it shouldn't be installed without python; if python-minimal *is* essential, you don't depend on it because you don't declare dependencies on essential packages.) I'm playing paranoid here, but why don't you want to declare dependencies on essential packages? If the package ceases to be Essential at some point in the future, some non-essential packages may still need it's functionality, but without this relationship being tracked, the package could easily disappear. Wouldn't it be better for the package database to have as much information as possible on what uses what, essential or not? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
Brian Eaton [EMAIL PROTECTED] wrote: http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html Has anyone ever done some log file analysis to figure out how much bandwidth would be saved by transferring package deltas instead of entire new packages? Slightly off-topic, but I never realised until I read that article, how similar rsync and bittorrent are! The whole storing checksum files on an HTTP server sounds exactly like what BitTorrent is already doing. :-) Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
Goswin von Brederlow [EMAIL PROTECTED] wrote: Bittorrent has a per chunk hash so it can validate each chunk when it recieves it instead of waiting for the full file. It won't see if a chunk is present at some other position in the file, not even if that position is also on chunk boundaries. Rsync has a per chunk Alder-32 and md4 checksum. Those chunk checksums are compared to a chunk at every byte position in the file. The Adler-32 checksum is fairly weak but it can be updated from one position to the next with minimal work. Only when it matches does rsync compute the expensive md4 checksum for the block. The only thing that is simmilar is the per block when generating the checksum, which is basicaly nothing. Actually it's quite a bit of similarity... but you're right, they still are very different. From the article, it sounds like the author is suggesting storing these checksum values for quick retrieval, which gets closer to what BitTorrent is doing. If an rsync daemon were to spit out IP's of clients that were mirroring the exact same thing (which is technically feasable, given that an rsync client could easily send it's relevant command-line arguments upstream), then rsync clients could talk to eachother, which would lower the bandwidth requirements of top-level debian mirrors significantly. MfG ? Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
