[conspire] upgrade and grub

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> You suggested other HTML editors, none of them are official Debian
> packages either.  My only choice is to find a tarball to download.  

1.  Are there indeed no Debian packages?  I'll double-check.
2.  When you say 'my only choice is', have you verified that none of 
    the several halfway measures is possible?

I mentioned KompoZer and Nvu mostly to mention that they arose, in years
gone by, as standalone HTML editors derived from Netscape Composer /
Mozilla Composer -- but added that they are both orphaned upstream.

Frankly, the presentation order and contents, in my posting, mostly
reflected my writing it stream-of-consciousness style as I was
researching that information in real time.  'Researching' is a bit of an
overstatement:  All I did was some _very_ basic use of a search engine to
find HTML editing programs for Linux.

My point, here, is that you or anyone else can do exactly likewise.  I
came to that task with roughly zero expertise in the subject, and just
did totally obvious things with a search engine.

The third, still actively maintained Mozilla Composer-derivative I
mentioned was BlueGriffon (WYSIWYG HTML editor based on Firefox's Gecko
rendering engine), which makes it a hugely complex program comparable 
to Adobe (ne Macromedia) Dreamweaver.  I also mentioned in passing
Bluefish and Quanta (which I now remember having been called 'Quanta
Plus' in the 1990s.

Today, I also see mention of something called Aloha Editor, a
JavaScript-based WYSIWYG HTML5 editor[1] (relying on nodejs aka node.js,
ugh, but at least it's GPLv2) that allows users to edit content in the
same layout that readers view it.  

And there's an old-school option I'd forgot about, W3C's (the World-Wide
Web Consortium's) Amaya, last updated in 2012 and supporting HTML
versions through 4.01.  https://www.w3.org/Amaya/


I am _now_ doing the exact same thing as yesterday, making totally basic
use of a search engine.  


About BlueGriffon:

https://www.linuxquestions.org/questions/linux-newbie-8/why-bluegriffon-does-not-install-in-debian-8-a-4175543902/
is a Web-forum discussion from 2015 about why a user was unable to then
install BlueGriffon from package operations in Debian 8 'Jessie'.  So,
the user punted and went for a binary upstream tarball version.

https://pkgs.org/download/bluegriffon (upstream maintaners?) as packages
for sundry x86_64 distros including .debs for Ubuntu releases, plus
tarballs, but nothing for Debian releases.  A binary .deb for Ubuntu may 
be OK on Debian, or might not.  There are significant binary-API and
libs differences between the two distributions, that can matter.
If you wish to give the .debs for x86_64 a try,  Sadly, upstream does
not operate a proper apt repository for Ubuntu, but you can just
directly fetch the .deb from
http://bluegriffon.org/freshmeat/3.0.1/bluegriffon-3.0.1.Ubuntu16.04-x86_64.deb
and then do a one-off installation using apt-get or dpkg.

http://bluegriffon.org/#download also makes clear why it is packaged
neither by Ubuntu nor Debian:  The proprietary licensing does not so
permit.

https://github.com/mtelleria provides Debianised _source code_ and glue
said to be sufficient to compile a binary .deb using git-buildpackage 
-- which would be sufficient to solve your problem and IMO is much
better than resorting to an upstream tarball, but might be more work
than you are willing to take on.



About Aloha Editor

I'm getting just a bit fatigued from both this task and from other,
unrelated things I've gone through today, so I'm not working very hard
on this one, and will just point you to the upstream page where they 
handwave about installing _both_ nodejs and npm from _their_ respective
upstream tarballs (probably bad advice where you could do better by
looking for packaged alternatives) and then build a special-snowflake
locally-created, non-packaged copy.
http://www.alohaeditor.org/guides/develop_aloha.html#debian-linux-mac-os-x


About Amaya:

Amaya's a really old program (started in 1996), so I'm astonished that
it's still reasonably viable.  (It would be better if it were full
HTML5-native, but being current to HTML 4.01 is respectable.)  Also,
it's claimed that this hasn't been developed since 2012 (orphaned).  

Again, there is no proper third-party apt repo, but there's an i386
binary .deb that can be directly fetched and used:
https://www.w3.org/Amaya/Distribution/amaya_11.4.7-1_i386.deb

I see no sign that there was ever an Amaya package in the Debian
collections, which is surprising.  I'm unclear on why.


About Aptana Studio:

It's an IDE (integrated development environment) for the Web based on
Eclipse (ugh) but also supposedly available to run standalone, coded in
Java and JavaScript (ugh, ugh).

I greatly doubt there's a Debian package.  In searching around, I see
claims that it cannot run without the Oracle/Sun JDK, that OpenJDK,
which is now standard in Linux, does not suffice.   There are a number
of receipes, including
https://technotes.tt4living.com/category/aptana-studio .


About Arachnophilia:

Another Java thing for editing Web content, successor to an earlier
program caleld WebThing.  Basically, all you do is fetch the developer's
.jar file and do 'java -jar Arachnophilia.jar'.

No sign of any effort to package.



About Bluefish:

Very reasonable, modern graphical Web-editor or light IDE (depending on
your perspective, written in C using the gtk+ graphics toolkit, actively
maintained.
https://packages.debian.org/stretch/bluefish



About Brackets (Adobe, http://brackets.io/):

HTML/Web editor written in HTML, CSS, and JavaScript.
Again, they offer no proper deb repo, but they do offer Debian/Ubuntu 
packages.  https://github.com/adobe/brackets/releases


About Hallo Editor:

I's a thing (http://hallojs.org/) using jQuery UI and the HTML5
contentEditable functionality to edit Web content.  Rather cool, 
actuall.



About LibreOffice and ex-Oracle OpenOffice.org:

As you might remember, the OpenOffice.org community split.  Most
mindshare split off to and remained with LibreOffice, and Oracle
retained the OpenOffice.org name and codebase, then donated them to the
Apache project.  So, there are two competing & closely related programs,
of which LibreOffice is the healthier.  

The 'Writer' module has a mode called Writer/Web that is reasonably well
regarded.
https://documentation.libreoffice.org/assets/Uploads/Documentation/en/GS5.1/HTML/GS5112-CreatingWebPages.html#__RefHeading___Toc14722_999364991


About Maqetta (unmaintained since 2013), cloud-based operation:

Written in Javascript and HTML.  Has a downloadable server component
(requires Java 1.6 or higher) that can run on a remote server or on the
same computer as the client software (the Web browser).  
Some of the stuff about that is here:
https://github.com/maqetta/maqetta/wiki/Server-Installation-and-Setup
To find the rest, start at the Wikipedia comparison page below, as I'm
running short on time to chase these things down.


About openElement:

Although this looks like a Redmondian .NET Framework thing, there is
talk about Linux support.  See:
https://en.wikipedia.org/wiki/OpenElement


About Quanta Gold / Quanta Plus / KDevelop:

I think this (Quanta) originated as a Qt/kdelibs thing (KDE-oriented)
but lived on for a long while and has fairly recently ceased to be
maintained, but they say that much of the code was merged to a sibling
kDE-ish project, the KDevelop IDE, which might merit a look.
https://en.wikipedia.org/wiki/KDevelop
https://packages.debian.org/stretch/kdevelop



About others:  There are at least a half-dozen other options for Linux 
that I've omitted because they're proprietary, but you can find many 
at https://en.wikipedia.org/wiki/Comparison_of_HTML_editors


To be honestly I didn't try really hard, in part because I _personally_ 
find the notion of a graphical Web editor pretty silly, and find 
just a text editor combined with reloading the page in a Web browser
to be functionally superior.  (I'm not arguing with your wish to use
what you like, of course.)



> Yes, programs are generally added to the menus.  LXMED allows me to
> re-arrange things, or rename "Firefox ESR" to plain Firefox.

Alternatives, if you want to avoid Java monstrosities, include PCManFM 
and the GNOME/gtk menu editor Alacarte.

https://wiki.lxde.org/en/PCManFM 
https://packages.debian.org/stretch/pcmanfm
(PCmanFM is mostly a file manager, but in recent versions includes menu
editing.)

https://en.wikipedia.org/wiki/Alacarte
https://launchpad.net/alacarte
https://packages.debian.org/stretch/alacarte



> Now I have an instance of a program that doesn't consistently install:
> openscad.  

Again, I am obliged to repeat what I've said several times:  Why is
the current problem with the Debian package on the _testing_ track
relevant to you?  You are on the stable track.  Aren't you?

Am I missing something?  Didn't you go to some considerable pains to
re-converge onto Stable, and get off Testing?

If you could please address what I'm saying, we could perhaps have more
productive discussions.


I've already explained, after protracted checking, the origin of the
breakage on testing:  There was a compile problem on one of Debian's 
more obscure non-X86 platforms, and a TrueType font it has historically 
relied on became unavailable upstream.  _If_ the package maintainer
pays attention to these problems (most recent maintainer submission was
in 2016), I'd guesstimate that they wouldn't be a big deal.



Their web-site suggested creating a file under sources.list.d.  
> 
> $ cat sources.list.d/openscad.list 
> deb http://download.opensuse.org/repositories/home:/t-paul/Debian_Testing_standard/ ./
> 
> On one computer, apt-get install worked and the program runs.
> On a different computer, I get errors about two lib files "but it is not installable"   libcgal12 and libqt5scintilla2
> 
> Back to the first computer, those lib files don't seem to be installed.   
> 
> Apparently the experts know something because openscad is a package in
> stable, but not testing.  Maybe a library problem that has not be
> properly fixed.


You describe these as two 'computers', but say nothing about what's
different between them.  Obviously, under those conditions, it's going
to be difficult or impossible for anyone to help you with diagnosis.

Generically, the 'foo was requested but it is not installable' is
exactly the sort of thing I would expect to see on _for example_ a 
machine upgraded to track Debian-testing and you are now trying to 
install a Desktop Environment or a huge package with many library
dependencies, where the necessary version of library package $FOO has
not cleared the Debian-testing package quarantine, but requested
application package $BAR has.  

I described this pitfall upthread.

Perhaps the 'first computer' is the one that was converged to
Debian-Testing but then you have been attempting to reconverge it onto
Debian-Stable?  If so, I already warned you, several times, that you can
have subsquent problems because some installed packages have ended up
being later than the ones for Stable, resulting in subsequent problems
with those packages' dependencies.  Remember my detailing that?  Well,
this is what that looks like.

You could try to further fix such a machine but working to downgrade,
which as I warned isn't really supported on Debian and always requires
some work.  _If_ the 'first computer' is the one that used to be on
Debian-testing, you could work away at that, e.g., try removing the
currently installed libcgal12 and libqt5scintilla2 packages.  Then, try
reinstalling them (hoping that you now have the -Stable versions).  
Then, try reinstalling openscad.

Warning:  You are messing around with sources.list, adding third-party
repos to it.  This is perilous, and, as I and Michael have stressed, 
is the quick way to break a Debian or other deb-based system unless
you're really sure of what you're doing.  The mere fact that 'their Web
site suggested' a thing doesn't necessarily mean it's a good idea.

The upstream developers typically _do not understand_ Linux distribution 
issues.  Their advice may be bad.  Their advice may even be
catastrophically bad over the long term.  (Or, it could work out.)