Sorry for the trouble, everyone!

I've uploaded source packages (version emacs28_28.1~1.git5a223c7f2e-kk2) that disable native compilation. In my local testing, they do not have this issue. Please give them a try once they're available on Launchpad.

We still need to investigate and see if we can figure out how to enable the feature without causing trouble. Let me know if you have any thoughts!

Yes, I think that you are running into this problem. I'm exploring building the packages without native compilation in order to temporarily resolve the problem.

Sorry for all of the trouble, and thank thank you for sharing feedback here. We'll figure this out!

Like /u/g_tb mentioned in a comment thread below, these packages are currently having the trouble described in this issue.

I'm investigating, but it might be a good idea to hold off on the *-kk1* packages for Emacs 28.1 if you haven't already tried to install them.

Emacs 28.1 available in kelleyk/emacs PPA
Emacs 28.1 available in kelleyk/emacs PPA

Hello, everyone!

I've uploaded packages for Emacs 28.1 to my PPA. Thank you very much to everyone who's filed issues against the GitHub repository (or reached out via email). It's wonderful to know that folks appreciate this effort, and I love being able to give something back to the community.

Now: on to the good stuff!

Packages are available for 18.04 LTS ("bionic"), 20.04 LTS ("focal"), 21.10 ("impish"), and 22.04 LTS ("jammy").

Emacs 28 deprecates Xft and encourages using Cairo/HarfBuzz for font rendering; this build configuration is the one that my Emacs 27 packages were already using, so there should not be any changes there.

The big new feature in Emacs 28 is native compilation, and as you might expect, these packages enable that feature. The only exceptions are the packages for 18.04 LTS ("bionic"); libgccjit packages aren't available for the version of GCC that ships with 18.04 LTS.

The only packaging-related update I have to share is that the master branch of the packaging repository now has a README with release notes. I'm going to try to move more notes about the packaging process there over time.

Enjoy, and please let me know if you have any trouble.

3
0
2.1y
Emacs 28.1 available in kelleyk/emacs PPA

Hello, everyone!

I've uploaded packages for Emacs 28.1 to my PPA. Thank you very much to everyone who's filed issues against the GitHub repository (or reached out via email). It's wonderful to know that folks appreciate this effort, and I love being able to give something back to the community.

Now: on to the good stuff!

Packages are available for 18.04 LTS ("bionic"), 20.04 LTS ("focal"), 21.10 ("impish"), and 22.04 LTS ("jammy").

Emacs 28 deprecates Xft and encourages using Cairo/HarfBuzz for font rendering; this build configuration is the one that my Emacs 27 packages were already using, so there should not be any changes there.

The big new feature in Emacs 28 is native compilation, and as you might expect, these packages enable that feature. The only exceptions are the packages for 18.04 LTS ("bionic"); libgccjit packages aren't available for the version of GCC that ships with 18.04 LTS.

The only packaging-related update I have to share is that the master branch of the packaging repository now has a README with release notes. I'm going to try to move more notes about the packaging process there over time.

Enjoy, and please let me know if you have any trouble.

86
12
2.1y

When you discuss something adorable on the internet, you owe tax on it.

This tax, which is a vital part of participating in modern society, is customarily paid in pictures/videos.

TL;DR: /u/Spider-Jenn wants pictures of the kittens!

Just FYI, OP's comment here  points out that this isn't a multiagent system (where the agents act independently); there is a single planner that sends "motion commands" to each robot.

I was only including that because it was the other possibly-damage-reducing effect that I had in that build. I noticed that I was no longer being one-shot when I added Sniper Damage Resistance. Some of my fireteam-mates were using Solar Damage Resistance and also liked what that was doing for them.

My point was that there are fairly accessible/easy things that you can do to prevent being one-shot by the Hobgoblins.

At 1335, the Hobgoblins won't one-shot you if you put on a Sniper Damage Resistance mod. I was also running a simple Charged With Light build (Taking Charge & Protective Light) which may have been active.

He mentions that at about 5 minutes into the video, if you're curious. He says that pilots are trained not to make turns over the dead engine for aerodynamic reasons; for example, it can be difficult to stop the turn.

Emacs 27.1 available in kelleyk/emacs PPA
Emacs 27.1 available in kelleyk/emacs PPA

Hello, everyone!

I've uploaded packages for Emacs 27.1 to my PPA. Since I've gotten a few questions via email about when they would be available, I thought that I would let everyone know to take a look. I apologize for the delay; I've been dealing with personal-life stuff.

As usual, I've tried to enable support for all of the new bells and whistles in the release. As compared to my emacs26 packages, these add native support for JSON (so JSON operations should be much faster), support for ACLs (which was left out for no good reason), support for libgmp, and support for enhanced text rendering through Cairo and HarfBuzz. Like the NEWS file mentions, this may cause trouble for anyone using bitmap fonts. This release also removes ImageMagick support.

If you're still on 16.04 LTS (xenial), xwidgets support has been removed. The upstream project updated the implementation of this feature in a way that isn't compatible with the library versions available in 16.04 LTS; sorry!

If either of those feature removals cause serious trouble for folks, we could chat about adding extra package variants. Also, if I've missed anything in the release notes or you have suggestions about improving our compile-time configuration, let me know!

In addition to the update to Emacs itself, there have two significant changes to the packaging, which should make the packages play more nicely with the rest of Ubuntu.

First,load-path now includes directories containing the major and minor version number, just like the Ubuntu packages (e.g. /usr/local/share/emacs/27.1/site-lisp, /usr/share/emacs/27.1/site-lisp, /usr/share/emacs/27.1/lisp), which should resolve some common trouble.

Second, each package now provides additional packages; for example, emacs27 provides emacs and emacs-gtk. This should prevent problems when another Ubuntu package requires one of those virtual packages.

Enjoy, and please let me know if you have any trouble.

2
0
3.7y
Emacs 27.1 available in kelleyk/emacs PPA

Hello, everyone!

I've uploaded packages for Emacs 27.1 to my PPA. Since I've gotten a few questions via email about when they would be available, I thought that I would let everyone know to take a look. I apologize for the delay; I've been dealing with personal-life stuff.

As usual, I've tried to enable support for all of the new bells and whistles in the release. As compared to my emacs26 packages, these add native support for JSON (so JSON operations should be much faster), support for ACLs (which was left out for no good reason), support for libgmp, and support for enhanced text rendering through Cairo and HarfBuzz. Like the NEWS file mentions, this may cause trouble for anyone using bitmap fonts. This release also removes ImageMagick support.

If you're still on 16.04 LTS (xenial), xwidgets support has been removed. The upstream project updated the implementation of this feature in a way that isn't compatible with the library versions available in 16.04 LTS; sorry!

If either of those feature removals cause serious trouble for folks, we could chat about adding extra package variants. Also, if I've missed anything in the release notes or you have suggestions about improving our compile-time configuration, let me know!

In addition to the update to Emacs itself, there have two significant changes to the packaging, which should make the packages play more nicely with the rest of Ubuntu.

First,load-path now includes directories containing the major and minor version number, just like the Ubuntu packages (e.g. /usr/local/share/emacs/27.1/site-lisp, /usr/share/emacs/27.1/site-lisp, /usr/share/emacs/27.1/lisp), which should resolve some common trouble.

Second, each package now provides additional packages; for example, emacs27 provides emacs and emacs-gtk. This should prevent problems when another Ubuntu package requires one of those virtual packages.

Enjoy, and please let me know if you have any trouble.

70
13
3.7y

If you would prefer the stable release, it's now available in my PPA as well!

The key is one of OEOEO or EOEOE, not both; sorry if that was unclear. I was trying to describe the way I'd come up with the bitting without being specific about what it was.

The padlocks are new, but the Schlage B-series hardware on the doors is clearly not. I'm using new Schlage-branded nickel silver pins, yes.

The keys were cut for me, to bittings that I provided. Like I mentioned in another comment, this turned out to be the problem: the cuts were way off! I had another locksmith cut keys to the same bittings (and verified that they're within spec with a key gauge and calipers)... and they work flawlessly.

Thank you for the time/comment!

Thank you for the advice! Tightening the cap all the way and then backing it off two or three notches makes everything work perfectly.

This was the problem! The keys were newly cut, and were not to spec; according to my key gauge, most of them are at least half a depth off... which explains their behavior. I had another locksmith come out and cut new keys with the same bitting, and those work perfectly!

Thank you for the pointer in the right direction!

Thanks! I picked it and rekeyed it that way. Very helpful to know exactly which lock I had; I appreciate that.

Rekeying Schlage single-cylinder knob that I don't have the key for

I recently bought a house that has an interior closet with a Schlage "key-in-knob" lock on it, but the previous owners didn't have a key. The door was not locked, so I've been able to remove the knob from the door, but I'm curious if there are any tricks for repinning the lock short of picking it. There are two small holes that I think are for the catches you'd normally use to disassemble the knob, but it doesn't look like there's anything to press (which makes sense, since the lock is locked).

Is there a way to get the knob apart, or do I need to either pick or replace it?

Thanks in advance for your help!

Schlage B-series deadbolts don't turn smoothly after rekeying

I recently bought a home whose locks use the usual 5-pin Schlage C keyway, and I am trying to rekey the locks. I decided to experiment with master keying at the same time; the house has some lockable storage areas, some under-house areas, etc. and it seemed like it would be useful to be able to use a single key for them myself while also limiting access for folks like contractors. Also, hey, an opportunity to learn about locks!

I designed the bitting for the keys to follow a set of best practices for master keying that I found online. The top master follows an OEOEO/EOEOE pattern, and then there are three change keys. Each is 2 lower in a single pin, so that the change keys can't be filed down into a master. All of the keys are within the MACS of 7.

I have taken apart two of the deadbolts (which I believe are B-series, based on some numbers stamped on the parts) and repinned them the same, so the top master and one of the change keys can open both locks. However, I've noticed that the master key "sticks" in the position where the top and bottom pins are lined up. If I apply some inward force while twisting, I can get the cylinder to turn, but it isn't smooth until the cylinder gets out of that position. The change key (where the master pin is in the cylinder instead of up top) doesn't do this nearly as much: you can feel the "zero degree" position where the top and bottom pins line up, but it turns fairly easily from there.

I have a pair of ABUS 83AL/45 padlocks, keyed to the top master and a different change key, that work beautifully.

Does anyone know what I might be doing wrong?

There are a few other things I haven't figured out yet that could be related to the problem:

  • I have the Schlage 40-133 keying kit. The cylinder springs (C 503-113) in that kit seem significantly longer than the ones that are in the locks I have. I couldn't tell if that was just because the existing springs had been compressed over time, but when I changed them out, the lock didn't work at all (so both locks are back to their original springs). I suppose it makes sense that the springs for compressible F-series cylinders would be different from those for the B-series cylinders.

  • When I am reassembling the lock, how tight should the cylinder cap be? If I tighten it until it is snug, the cylinder won't turn at all (and I can't remove the key if there's one in the lock). This feels like it might be related to how I need to push the master key inwards in order to get it to turn the cylinder. I don't really understand what the purpose of the retaining pin and spring are, either.

Thank you all in advance for your help!

lunarsunrise
5Edited
4.1yLink

It sounds like you've overwritten only the public key file (id_rsa.pub) and not the private key file (id_rsa). Fortunately, the private key file actually contains both the public and private keys (both halves of the keypair). There are two files so that you can set permissions to restrict who/what can read id_rsa while leaving id_rsa.pub more widely readable.

Try ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub; that should extract the public half of your keypair and write it to the public key file, making them match again.

If you had a comment associated with your key (for example, I usually have one that describes the date that the key was generated and the machine that it was generated on) that will be lost; you can add it to the end of the line in id_rsa.pub again if you like.

You might also look in ~/.ssh/authorized_keys. Assuming that you're using the same key for SSH access to the machine (and not using OpenSSH certificates, LDAP, or some other more involved mechanism) you'll see a line containing the public half of the keypair; you can just copy that line into id_rsa.pub.

In order to get some of the benefits of type-checking, you can also do something like

type Slope uint

const (
    SlopeUnknown Slope = iota
    SlopePositive
    SlopeZero
    SlopeNegative
)

(assuming that you want everything exported).

Also, in general, I tend to prefer having the zero-value (SlopeUnknown) be something outside of the normal range of values; otherwise it can be unclear whether you meant for something to be SlopePositive or whether it's just been initialized to that value by default.