This is getting a tad bit annoying, so I'm going to go ahead and request for the server to be moved to a happier home. (Faster server in my VPS provider)
Downtime may result from this, so please use IRC when it goes down!
I currently host OmnomIRC, and I'm sorry for the downtime! My VPS provider is having some issues on their side, so my VPS node is currently down, therefore making my VPS (and OmnomIRC) down. Rest assured - this isn't a hit-and-run VPS provider, and this issue should hopefully be fixed soon!
Maybe they're trying to get you to switch to Windows or Mac hosting?
Also I had no problem accessing Omnom at all. Maybe it only affected people who cleared their cache or that it was due to CloudFlare not updating in my region for a while?
Psh... Mac hosting doesn't exactly exist. For good reasons.
This is pretty awesome! And, will these packages also be added to the arch repro?
No, I'm just a Debian packager, and will probably stay that way for the foreseeable future. AFAIK, Jonimus manages the Arch (AUR) packages. Eeems also manages an AUR repo on my server, though he does not package libti*, TiLP, GFM, or TilEm. Bug them about it!
It's quite late - I was going to call this a Christmas present, but it's 4 days after Christmas, so I'll call this an early New Year's gift.
For quite a while, Debian and Ubuntu users have been depending on the install_tilp.sh script from the TiLP SVN repository to build packages... which meant installing a lot of development packages, compilers, etc. that one might not want or need. This was due to the lack of updates from both the Debian and Ubuntu sides, mainly Debian.
That said, I recently took over package maintainership (though I'm an "intern", so I don't have full upload rights yet). However, due to the closing of the repositories in preparation for the Debian 7 release, you won't see anything until next year.
At the same time, I also decided to package the new TilEm Z80 emulator, so expect to see that soon!
However, rather than wait for people to get their hands on some Debian packages, I've went and built them myself, and placed them into an APT repository for you guys to use.
Installation
Debian:
Spoiler For Instructions to add the Debian repository:
You're done! If you have previously installed TiLP and friends, you should now be asked to upgrade. If you haven't, just install packages normally - tilp2, gfm, and tilem.
Ubuntu: Ubuntu users must wait for about a week or two. Packages for Ubuntu will be hosted on the Omnimaga PPA. However, due to some complications, some packages had to removed, which takes about 1-2 weeks. This post will be bumped and updated when those packages are ready.
Acknowledgments Simply the best for the last.
Really, really big thanks to Lionel Debroux and Benjamin Moody for helping out with the packaging! Most maintainers don't get much help from the original program developer, but you guys are exceptions! We fixed a lot of problems with both TiLP and TilEm together, and of course the original packages themselves!
Another big thanks to jacobly, who gratefully donated his time to helping out with the debian/copyright work (and even developed a script to create the file automagically!). No Debian Developer would have accepted any packages without your help! (After a while, he threw up his hands in the air and gave up - well, not really, but he definitely paused his work out of understandable boredom. )
Also thanks to #debian-mentors(at OFTC, irc.oftc.net) for the constant help with my packaging! (Particularly paultag, daemonkeeper, and my mentor, algernon!) My constant questions probably seemed endless and stupid, but you guys answered them anyway, even when I should have RTFM...
Additional thanks to Catherine(on #cemetech, also previously known as _player) and jacobly (again) for the extensive Bash scripting expertise. Those questions weren't random - they were all part of this project!
Finally, another BIG thanks (heck, all of these were BIG) to Sorunome, who generously lent me his server for 64-bit package building. His server may be small, but it certainly can (and will continue to for the foreseeable future) build 64-bit Debian packages!
Spoiler For FAQ:
Frequently Asked/Anticipated Questions: General Questions:
I love your packages! OR - Something didn't install correctly/broke! Who should I praise/complain to? I maintain all packages, so you can either send me adorations or whine/complain to me. This topic is a good place to report problems. Depending on how busy I am, I may get back to you within the day, or within a month.
I want to help! Who should I contact? What do I need to know? I currently maintain the package with another co-maintainer, jacobly. It's best to contact me, though you can also contact him and he can get you started. You should be able to read and follow specs, and know some basic Bash scripting. Knowledge of sed and awk is a big plus.
Could you package for Fedora, Arch, [distro goes here]? No, I'm just a Debian packager, and will probably stay that way for the foreseeable future. AFAIK, TC01 manages the Fedora packages, and Jonimus manages the Arch (AUR) packages. If you want to get packages for another distro... try doing them yourself!
Is the packaging work open source? Yes - you can (technically) build these packages yourself! (Of course, you need to install the needed dependencies.) The project can be found here: https://code.google.com/p/tilp-debian/
Note that it has not been updated with the latest changes, so things may not work perfectly yet.
Can I upload a package to your repo? Yes - this is technically a community repo, so you can contribute to it! You may upload packages to apt.withg.org under two conditions: 1) it is useful to the community (and obviously not harmful), 2) the package is properly formatted according to the Debian packaging guidelines.
General Packaging Questions:
Do you build for 64-bit systems? Yes, I do - the amd64 variant, that is. (If you don't know what amd64 is, don't worry about it - just know that it's 64-bit!
Will you package the latest Git/SVN version of TiLP? Maybe - if I can figure out how to do it. (I'm sure it's possible, because there are package versions tagged with "git20101104" and the like.) I'll let you guys know if I do release such a package - though you may have to add a different repo channel (i.e. apt.withg.org wheezy-git main), as the versions will conflict with the existing packages.
How often will these packages be updated? I'll try to make an update within 1-2 months of a new release, but no guarantees. The next release is expected to have a LOT more dependencies (which I need to package, as they don't exist in Debian yet), so expect some delays.
When the Debian/Ubuntu package arrives for TiLP, libti*, GFM, and TilEm, do I have to remove the PPA/3rd party repo? No - the versioning of the package (the "~DISTRO" suffix/tag) makes the package inferior to a package without it, aka the official repository ones. When the time comes, you can simply update to your distro's version of the package.
Why are ROM dumpers disabled in TiLP? To be more precise, it's disabled in the libticalcs library. If you notice the versioning of the libticalcs package, it's tagged as "+dsfg", or "Debian Free Software Guidelines." This is due to the Debian philosophy:
"If you are on a desert island, magically with a computer, a Debian CD, and the Debian repository servers connected to some extraterrestrial power source, you must be able to rebuild a package in its entirety from source."**
libticalcs has assembled ROM dumpers that can not be built with tools in the Debian repository, so they are considered "non-free" (which is "taboo" in Debian). Rather than place libticalcs in non-free (and screw up all the other packages), they are simply disabled, causing the package to get the +dsfg tag. This will be fixed in the next release, since the new assemblers (written by Ben Moody) can be assembled by FOSS tools that I can package. (Some of the old ones required TASM, which is closed-source.)
(In reality, despite the inclusion of a patch to notify people about the problems with the packaging, I don't think the ROM dumpers are actually removed. You might just have the ROM dumpers built in after all!)
Ubuntu Specific Questions:
Why are the Ubuntu packages delayed? Better yet, why can't you build them yourself? Ubuntu packages are delayed because we use Launchpad's PPA to host and build packages, and the system isn't exactly stellar. Deleting packages are "requests", and they can take up to 1-2 weeks to process. Uploading a higher version would also do the trick, but the old packages would still remain, which may cause significant problems in the future.
As for personally building the packages myself - I could. (In fact, my repo scripts have support for building Ubuntu packages, just needing a few tweaks here and there to make things work.) The problem is that Ubuntu (or rather, Canonical) recently decided to remove a good majority of their old repositories, making package building for old Ubuntu distros impossible. As of now, the only way to build for old versions of Ubuntu (like maverick 10.10) is via Launchpad. It's pretty stupid, considering that Debian has its own archive] packages, and Jonimus manages the Arch (AUR) packages. If you want to get packages for another distro... try doing them yourself!
General Packaging Questions:
Do you build for 64-bit systems? Yes, I do - the amd64 variant, that is. (If you don't know what amd64 is, don't worry about it - just know that it's 64-bit!
Will you package the latest Git/SVN version of TiLP? Maybe - if I can figure out how to do it. (I'm sure it's possible, because there are package versions tagged with "git20101104" and the like.) I'll let you guys know if I do release such a package - though you may have to add a different repo channel (i.e. apt.withg.org wheezy-git main), as the versions will conflict with the existing packages.
How often will these packages be updated? I'll try to make an update within 1-2 months of a new release, but no guarantees. The next release is expected to have a LOT more dependencies (which I need to package, as they don't exist in Debian yet), so expect some delays.
When the Debian/Ubuntu package arrives for TiLP, libti*, GFM, and TilEm, do I have to remove the PPA/3rd party repo? No - the versioning of the package (the "~DISTRO" suffix/tag) makes the package inferior to a package without it, aka the official repository ones. When the time comes, you can simply update to your distro's version of the package.
Why are ROM dumpers disabled in TiLP? To be more precise, it's disabled in the libticalcs library. If you notice the versioning of the libticalcs package, it's tagged as "+dsfg", or "Debian Free Software Guidelines." This is due to the Debian philosophy:
"If you are on a desert island, magically with a computer, a Debian CD, and the Debian repository servers connected to some extraterrestrial power source, you must be able to rebuild a package in its entirety from source."**
libticalcs has assembled ROM dumpers that can not be built with tools in the Debian repository, so they are considered "non-free" (which is "taboo" in Debian). Rather than place libticalcs in non-free (and screw up all the other packages), they are simply disabled, causing the package to get the +dsfg tag. This will be fixed in the next release, since the new assemblers (written by Ben Moody) can be assembled by FOSS tools that I can package. (Some of the old ones required TASM, which is closed-source.)
(In reality, despite the inclusion of a patch to notify people about the problems with the packaging, I don't think the ROM dumpers are actually removed. You might just have the ROM dumpers built in after all!)
Ubuntu Specific Questions:
Why are the Ubuntu packages delayed? Better yet, why can't you build them yourself? Ubuntu packages are delayed because we use Launchpad's PPA to host and build packages, and the system isn't exactly stellar. Deleting packages are "requests", and they can take up to 1-2 weeks to process. Uploading a higher version would also do the trick, but the old packages would still remain, which may cause significant problems in the future.
As for personally building the packages myself - I could. (In fact, my repo scripts have support for building Ubuntu packages, just needing a few tweaks here and there to make things work.) The problem is that Ubuntu (or rather, Canonical) recently decided to remove a good majority of their old repositories, making package building for old Ubuntu distros impossible. As of now, the only way to build for old versions of Ubuntu (like maverick 10.10) is via Launchpad. It's pretty stupid, considering that Debian has its own archive of old distros. Not sure whether it's cost related (Launchpad is pretty wasteful, IMO, so why not save there?) or some sort of plot to get money (i.e. make people dependent on the Launchpad service to build packages).
Ubuntu now has TiLP 1.16. Should I add the PPA? I highly recommend doing so. The reason is that the Ubuntu devs were silly enough to just update TiLP, and not any of its libraries. (See: LP#1010222) That means TiLP will look prettier, but still fail to work and crash. If you add the PPA, you'll get the newer libraries, and TiLP will (hopefully) start working again! Worse case scenario: TiLP doesn't run anymore from the new libraries (unlikely, but possible). You can easily open Synaptic, select the tilp2 package, and change the version (Force Version) to the PPA's version, and everything should work.
** I wasn't kidding - see here. I might have bent the scenario just a bit, but the gist is pretty much the same.
Sorry. My backup daemon decided to sulk in a corner and cry after I disabled backups for it, and while doing so eat up all of my server's memory. (I disabled backups and removed them for the OmnomIRC server, since I've already made my own backups.) Lesson learned: JungleDisk is sloppy/apathetic with Linux stuff, they SUCK, and switch to another backup provider ASAP.
OmnomIRC should now be restored. You may need to refresh to see the chat again.
The companies most likely sold e-mail lists to other companies.
Ehh, probably not a legitimate university. I don't think they would bend that low.
More likely the email address is public somewhere (university directory), and either a bot was able to read it out or an individual just looked up a random EDU email. Also, if you've published any papers, your educational email address will likely be exposed as well.
Oh... wait, I thought my response wasn't trickery? Just that she can see someone with blue eyes, and when that person realizes it's him/her, logically deduces that it is him/her that has blue eyes and leaves the island.
Spoiler For This might be right... so final warning!:
Is it that because the leader made eye contact with someone, and said, "I can see someone who has blue eyes," that a person with blue eyes leaves the island? As for the night, it would be the night on the day she said her sentence.
If no eye contact is made, it is assumed that the "who, me?" effect applies - the crowd turns towards the direction of her gaze, landing on a person that realizes that his/her eye color was revealed, and leaves that night.
Show Posts
(Faster server in my VPS provider)
