Steve Youngs | 28 Jun 12:52 2016
X-Face
Face
Gravatar

Our Packages Repo

Hey Folks!

Our packages repo is up!  It's not really ready for general consumption,
but you can take a look...

        git clone http://git.sxemacs.org/packages

It's a little broken at the moment and it probably won't build properly
yet.  Don't panic, I'm working on it.  Expect quite a few updates over
the coming days.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
issue-tracking | 14 Jun 09:18 2016

[Bug 183] New: `eval-after-load' doesn't trigger for already loaded files.

Bug ID Summary Product Version Hardware OS Status Severity Priority Component Assignee Reporter QA Contact
183
`eval-after-load' doesn't trigger for already loaded files.
SXEmacs
22.1.16
PC
Linux
NEW
normal
P5
Core Lisp
steve <at> sxemacs.org
acm <at> muc.de
sxemacs-devel <at> sxemacs.org

Enter this into *scratch*: (eval-after-load "font-lock" '(message "Loaded font-lock")) , and evaluate it with C-x C-e. What happens: The echo area reports the result of evaluating the `eval-after-load' form. What should happen: Since font-lock.elc is pre-loaded, `message' should be run instantly, writing the message to the echo area. C-h l confirms that this has not occurred. Discussion: In CC Mode there is a similar form which aims to load cc-fonts.el dynamically like this. It fails, leaving CC Mode's font locking non-functional.
You are receiving this mail because:
  • You are the QA Contact for the bug.
issue-tracking | 14 Jun 02:18 2016

[Bug 182] New: Paypal redirect goes to 404

Bug ID Summary Product Version Hardware OS Status Severity Priority Component Assignee Reporter QA Contact
182
Paypal redirect goes to 404
Web Site
unspecified
PC
Linux
NEW
normal
P5
General
steve <at> sxemacs.org
njsf <at> sxemacs.org
sxemacs-devel <at> sxemacs.org

After a Paypal donation one gets redirected to http://www.sxemacs.org/thanks.html which gives out 404
You are receiving this mail because:
  • You are the QA Contact for the bug.
Nelson Ferreira | 13 Jun 22:26 2016
Picon
Gravatar

Fwd: [RFC] SXEmacs Packaging -- The next steps


---------- Forwarded message ---------
From: Nelson Ferreira <nelson.ferreira <at> ieee.org>
Date: Mon, Jun 13, 2016 at 4:22 PM
Subject: Re: [RFC] SXEmacs Packaging -- The next steps
To: <belanger <at> sxemacs.org>


I will try tonight to abuse the github mercurial importer to see if it fares any better

On Mon, Jun 13, 2016 at 4:20 PM Jay Belanger <jay.p.belanger <at> gmail.com> wrote:

Steve Youngs <steve <at> sxemacs.org> writes:
...
> In a nutshell: nuke all the hg infrastructure (find and rm are my best
> buddies), and then do a 'git init' on it.

Sounds like a reasonable idea.  I can't imagine that I would ever want
to see the old changes.  But will there still be a separate copy of the
old hg stuff in case somebody does?


Steve Youngs | 5 Jun 15:53 2016
X-Face
Face
Gravatar

SXEmacs FTP is open for business

Hey Folks!

I mentioned earlier today that ftp.sxemacs.org was now live.  Yep, it
is.  And now it even has stuffs you can download, like SXEmacs tarballs,
and loadsa XE packages.

Basically, everything that is available for download via our website and
http://downloads.sxemacs.org/ is available from our FTP site now.  I
think the only thing I didn't copy over to ftp.sxemacs.org was a 21.4
and 21.5 XEmacs tarball, but I can easily add those too if anyone thinks
I should.

Am I ready and willing to have other folks mirror our stuff?
Absolutely!  And to that end I intend to write up a bit of a blurb
someplace (SPPM, website, here).  It'll cover the what, where, how, and
stuff.  In the meantime, here are a couple of rsync[1] commands for the
impatient... 

Get Everything:
  rsync -qaz --delete-after \
    ftp.sxemacs.org:ftp.sxemacs.org/pub/* /your/local/dir

Get Packages:
  rsync -qaz --delete-after \
    ftp.sxemacs.org:ftp.sxemacs.org/pub/packages/* /your/local/dir

Get Snapshots:
  rsync -qaz --delete-after \
    ftp.sxemacs.org:ftp.sxemacs.org/pub/snapshots/* /your/local/dir

Get SXEmacs Releases
  rsync -qaz --delete-after \
    ftp.sxemacs.org:ftp.sxemacs.org/pub/releases/* /your/local/dir

The reason for the `--delete-after' option is because files do disappear
every now and then (yes, on purpose), especially in snapshots and in
packages. 

Drop the `-q' if you're a stdout junkie with nothing better to do than
watch shit scroll up your screen. :-)

Footnotes: 
[1]  No, I'm not running rsync server, but that doesn't mean you can't
use rsync to leech the goodies.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 31 May 03:30 2016
X-Face
Face
Gravatar

Where should user emods go?

Hey hey!

This is something I've wondered about for quite a while.

,----[ C-h v module-load-path RET ]
| `module-load-path' is a simple built-in variable.
|   -- loaded from "/usr/src/sxemacs/sxemacs/src/emodules-ng.c"
| 
| Value: ("/usr/lib/sxemacs-22.1.16/core2-unknown-linux-gnu/modules/")
| 
| Documentation:
| *List of directories to search for dynamic modules to load.
| Each element is a string (directory name) or nil (try default directory).
| 
| Note that elements of this list *may not* begin with "~", so you must
| call `expand-file-name' on them before adding them to this list.
| 
| Initialized based on EMACSMODULEPATH environment variable, if any, otherwise
| to default specified the file `paths.h' when SXEmacs was built.  If there
| were no paths specified in `paths.h', then SXEmacs chooses a default
| value for this variable by looking around in the file-system near the
| directory in which the SXEmacs executable resides.
| 
| Due to the nature of dynamic modules, the path names should almost always
| refer to architecture-dependent directories.  It is unwise to attempt to
| store dynamic modules in a heterogenous environment.  Some environments
| are similar enough to each other that SXEmacs will be unable to determine
| the correctness of a dynamic module, which can have unpredictable results
| when a dynamic module is loaded.
| 								
| 
`----

By default, my user emod directory would be...

        '~/.config/sxemacs/core2-unknown-linux-gnu/modules'

Is that the right place?  It seems wrong to me, especially now that
we've moved user packages out of the init directory.  As you know, user
packages should be under `${XDG_DATA_HOME}/sxemacs', but I'm not sure
that's the right home for user emods either.

$XDG_DATA_HOME is normally `~/.local/share' but emods are more of a
lib thing, than a share thing, hence why we install the system emods
into $PREFIX/lib.

There's nothing in the XDG specs or the FHS specs about user libexec
directories.  So, whatever directory we choose, at least we won't be
wrong. :-)

The choices as I see it are...

  1) user-init-directory/$triple/modules (where they are now)

  2) user-packages-topdir/$triple/modules (alongside user elisp
     packages) 

  3) ~/.local/lib/sxemacs/$triple/modules (XDG-ish libexec)

  4) someplace _you_ think is better ;-)

I'm so undecided on this that I couldn't even tell you which of those is
my preference.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 31 May 02:11 2016
X-Face
Face
Gravatar

Setting up ftp.sxemacs.org

Hey Folks!

I'm in the process of setting up FTP access at sxemacs.org for packages
and stuff.  However, I've hit a hurdle... my hosting provider wants to
charge me $USD60/yr[1] for a unique IP for it.  I'm not sure why they
insist on a unique IP for anonymous FTP, but there you go.

A few seconds ago I sent off an email to them asking for a better deal.
When I say "better deal", I've asked them to waive the fee entirely.
Too bold?  Too cheeky?  I don't know, but if you don't ask... :-)

I'll let you know how it turns out.

Footnotes: 
[1]  With current exchange rates, that's almost $AUD90.00 and that hurts
my pocket more than I'm comfortable with.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 30 May 01:12 2016
X-Face
Face
Gravatar

ffi-curl has some new tricks

Hey Peeps!

As a by-product of making PUI support HTTP sites our ffi-curl has
learned a few new tricks.  Some of which may even be useful. :-)

(file-exists-p "http://www.sxemacs.org/index.html")
 => t

(file-readable-p "http://www.sxemacs.org/index.html")
 => t

Dirty little secret... calling #'file-readable-p on a URI actually does
#'file-exists-p because if it wasn't readable, curl wouldn't even be
able to find it in the first place.

(copy-file "http://www.sxemacs.org/index.html" "/some/local/file")

w00t! new file in /some/local/file

(copy-file "/some/local/file" "http://www.sxemacs.org/index.html")
 => Invalid argument: "http://www.sxemacs.org/index.html", "Destination
 cannot be a URI" 

(file-name-directory "http://www.sxemacs.org/some/path/to/a/file")
 => "http://www.sxemacs.org/some/path/to/a/"

(file-name-nondirectory "http://www.sxemacs.org/some/path/to/a/file")
 => "file"

(insert-file-contents-literally "http://www.sxemacs.org/index.html")
  I'm not gonna paste the contents of that here, trust me, it works. :-)

(expand-file-name "http://www.sxemacs.org/index.html")
 => "http://www.sxemacs.org/index.html"
 Don't use that, it's not useful for anything, it exists to satisfy
 something else.

All this comes to you via the magic of `find-file-name-handler'.  They
only work on URIs that include a filename, and only for http(s) and
(s)ftp.  And if you try something that hasn't been implemented you get a
nice (hopefully informative) error...

(delete-file "http://www.sxemacs.org/index.html")
 => Feature not yet implemented: "curl:delete-file"

It's not complete, I've only added what was needed to get it working with
PUI.  Check ffi-curl.el if you want to add any more, it's really easy.  I
would ask that you keep the naming convention though: `curl:name'.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 24 May 16:44 2016
X-Face
Face
Gravatar

Oops

So, it turns out that I broke PUI.  Sorry 'bout that.  I'll fix it in
the next day or two.

Work-around in the meantime: (setq package-get-have-curl nil)

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 23 May 07:07 2016
X-Face
Face
Gravatar

[RFC] SXEmacs Packaging -- The next steps

Hey Gang!

In this message I'm going to be talking about a bunch of different
XEmacs packages but I don't want this to go on forever so I'm only going
to mention them by name and not describe what they do.  If I mention a
package that you're not familiar with you can...

        M-x package-get-info RET PKGNAME RET description RET

...and that will give you a brief description of the package.  For
example: 

        M-x package-get-info RET gnus RET description RET
         => The Gnus Newsreader and Mailreader.

OK, now that SXEmacs can leach and install packages via HTTP I think we
should begin distributing our own (built with SXEmacs) packages[1].  I
already have a mirror of the XEmacs packages at
http://downloads.sxemacs.org/xemacs-pkgs/packages which is updated daily
via rsync.  The source for those packages originates in XEmacs'
mercurial repo and have been built on XEmacs 21.4 by Norbert Koch.  My
immediate plan is to turn off the daily rsync at downloads.sxemacs.org.
And then build those exact same packages here with SXEmacs, and then
replace all the packages at downloads.sxemacs.org with SXEmacs built
ones.

My first question:

Should we "go it alone" with packages?  By that, what I mean is
should we drop the XEmacs package mirrors and only use SXEmacs
package mirrors/sites[2]?  I think this is something we should
consider because I want progress happening in "package-land".

Second question:

Considering that one no longer needs to jump through hoops and fight GCC
builds to get libffi anymore, can we please please please make libffi a
non-optional requirement for building SXEmacs?

Assuming positive responses to those two questions I'd like to propose
the following changes to the list of packages distributed:

Dropped Packages
----------------
These are the packages that I think we should drop from the list right
now.  None of these are set in stone so if you have reasons for keeping
any just speak up.  I just don't see the point in distributing packages
that nobody is ever going to want or have a need for.

Sun     lol, wut?
build   ok, this one _is_ set in stone, it's incompatible with SXEmacs.
calc    Don't freak out, read further down and all will become clear.
forms   even XE says it's obsolete
gnats   the rest of the world moved on to things like bugzilla
pgg     easypg is a gazillion times better
tm      nothing uses this
tooltalk see 'Sun'
vc-cc   non-free and there's a 'clearcase' package anyway
xetla   nobody, absolutely nobody, uses tla anymore

What others should we get rid of while we're at it?

New SXEmacs Packages
--------------------
These are some new packages that will only run in SXEmacs

Calc    See, I told you not to freak out.  This will be Jay's calc that uses
        lots of SXEmacs ENT goodness. :-)
EMchat  My IM client, well technically just an ICQ client, but still
        with hopes and plans of multi-protocol.
howm    "Write fragmentarily and read collectively" According to
        the website.  I use it, I like it, it's cool. :-)  It's probably
        not really a "SXEmacs-only" package.

What others would you want to add?  How about magit? org-mode?  If you
get itchy, start scratching.

XEmacs Packages Updates
-----------------------
These are the packages that are in my sights for immediate updates.

easypg  update to author's git
gnus    update to the last version that had support for XEmacs
riece   update to author's git

I haven't yet decided what to do about package source repos, I'll leave
that for another day.

That's where I'm at right now with SXEmacs and packaging.  What say you?

Footnotes: 
[1]  Unless stated otherwise, whenever I mention "packages" I'm talking
about the pre-built "binary" packages that PUI deals with, not source
only packages.

[2]  Currently a grand total of one site, but I'm optimistic for the
future. :-)

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|
Steve Youngs | 11 May 02:28 2016
X-Face
Face
Gravatar

SXEmacs OpenSSL and naughty ciphers

Howdy!

Alrighty, yesterday, as you may have noticed, I committed a patch to fix
those "Unexpected Errors" in the OpenSSL tests.  The problem was that
certain ciphers were not passing the checks in Fossl_encrypt(),
Fossl_decrypt(). [1] (see openssl.c:1249,1256,1266)  All I did with the
test suite was to ensure that none of the ciphers that cause problems
were used in any of the tests.

Yes I know that is not a real fix, so here is what I'd like to do to
get closer to something resembling one.  I want to add a "cipher
blacklist", just a simple list of symbols (cipher names) that gets
consulted every time our code asks OpenSSL for a cipher.  If the
cipher is on the blacklist, we don't even bother trying to load it,
we just error.

I think the blacklist should be a DEFVAR_LISP in case a user has reason to
want/need to use any of the problem ciphers, or if an update of OpenSSL
not requiring a SXEmacs rebuild would need the blacklist altered.

Does that sound like a decent enough idea?  If it isn't, please speak up
and let me know, especially if you have a better one. :-)

The list would contain the following ciphers:

id-smime-alg-CMS3DESwrap id-aes128-wrap id-aes192-wrap id-aes256-wrap
id-aes128-GCM id-aes128-CCM id-aes192-GCM id-aes192-CCM id-aes256-GCM
id-aes256-CCM AES-128-XTS AES-256-XTS 

Plus these that Sebastian was already leaving out of the tests:

CAMELLIA-256-CFB8 CAMELLIA-192-CFB8 CAMELLIA-128-CFB8 CAMELLIA-256-CFB1
CAMELLIA-192-CFB1 CAMELLIA-128-CFB1 DES-EDE3-CFB8 DES-EDE3-CFB1 DES-CFB8
DES-CFB1 AES-256-CFB8 AES-192-CFB8 AES-128-CFB8 AES-256-CFB1
AES-192-CFB1 AES-128-CFB1 

So all up, 28 ciphers.  At least for me, there could be others that
should be on the list that I don't have in my OpenSSL.  28 might seem
like a lot, but when you consider...

(length (ossl-available-ciphers))
 => 93

...it's not so bad. :-)

Footnotes: 
[1]  I didn't check the file equiv of those functions
(Fossl_encrypt_file()), but I'd be willing to bet they'd fall over there
as well.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|

Gmane