Discussion:
loss of synaptic due to wayland
(too old to reply)
Gene Heskett
2019-07-08 10:50:02 UTC
Permalink
Greetings all;

So, synaptic is gone. What do or can we use for a replacement?

Thanks.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Tixy
2019-07-08 11:20:01 UTC
Permalink
Post by Gene Heskett
So, synaptic is gone. What do or can we use for a replacement?
Wasn't that discussed at length in april...?
https://lists.debian.org/debian-user/2019/04/threads.html#00103

Anyway, synaptic isn't gone, it may be not usable on your Raspian
system if the people that put that image together used wayland rather
than X (if my memory of that discussion is correct).

Personally, I've always used aptitude for package management with a
visual UI, being text console based it also works over ssh or other
remote terminal connections. You'd have to get use to using a keyboard
rather than a mouse though.
--
Tixy
Gene Heskett
2019-07-08 11:50:01 UTC
Permalink
Post by Tixy
Post by Gene Heskett
So, synaptic is gone. What do or can we use for a replacement?
Wasn't that discussed at length in april...?
https://lists.debian.org/debian-user/2019/04/threads.html#00103
Anyway, synaptic isn't gone, it may be not usable on your Raspian
system if the people that put that image together used wayland rather
than X (if my memory of that discussion is correct).
Personally, I've always used aptitude for package management with a
visual UI, being text console based it also works over ssh or other
remote terminal connections. You'd have to get use to using a keyboard
rather than a mouse though.
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear a
working system down to doing a reinstall to recover, 3 times now. It may
be capable, but imnsho its also dangerous. Having it do anything but
quit instantly when you hit the quit key q, hit because you're lost is
unforgivable.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Luke Kenneth Casson Leighton
2019-07-08 13:00:01 UTC
Permalink
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.

never had *any* problems - at all - that weren't caused by doing
something incredibly stupid such as "ctrl-c" in the middle of an
installation (at the point where dpkg is being called), and even then,
apt-get -f install in almost 100% of cases fixed the "problem that i
had myself caused".

really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.

l.
Luke Kenneth Casson Leighton
2019-07-09 14:10:01 UTC
Permalink
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did, if
so, whoops...)
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or
directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error 1
make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h except in
some obvious biology related programs. unrelated to openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in the
repo's?
there's a file search "thing" somewhere, for apt... it's a plugin (i
think)... although i suspect you simply have the wrong version of
openssl installed.

ok so i do have /usr/include/openssl/bio.h (makes it easier if
someone else has it....) and so i can find it with:

$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl

and that gives:

/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h

shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js

ok so you'll need to do "apt-get install libssl-dev" and that *should*
get you the missing openssl/bio.h file.

if you run into any other difficulties with missing packages, try this:

"apt-get build-dep linux-image-4.something.something"

that will install *all* build dependencies for a *debian* kernel build
process... which (warning) may be a little bit more than you bargained
for, you'll have to review what it recommends to install before
proceeding, ok?

basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.

problems come when debian sets different options from the default, and
you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
Post by Luke Kenneth Casson Leighton
never had *any* problems - at all - that weren't caused by doing
something incredibly stupid such as "ctrl-c" in the middle of an
installation (at the point where dpkg is being called), and even then,
apt-get -f install in almost 100% of cases fixed the "problem that i
had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.
What the gui is good for is showing you the exact package name to install
or purge. Nothing else, however capable it might be, can really replace
the look and feel of a good gui. But I've been corrected before. Teach
me!
:)

on-list is better (other people benefit too). these are what i use:

for source stuff:
* apt-get source {package} - gets the *source code* of a package
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)

those are typically best done in a chroot, for safety.


to find out which package has a file installed:
* grep filename /var/lib/dpkg/info/*.list

general package installing process:
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.

these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and onto
the mouse. i even use fvwm2 with "mouse-over equals window-focus"
very deliberately to minimise clicks. this all because i have
recurring bouts of RSI...

hth.

l.
Alan Corey
2019-07-09 15:40:01 UTC
Permalink
I thought it was possible to have both X and Wayland installed and
just start the one you want to use. Pretty sure I did that when I was
playing with Buster.

I can do
apt search
but then I have apt installed. There are several package management
tools. What I like Synaptic for besides the obvious is finding and
fixing broken packages. You can get in there and take out what's
causing the problem, if it doesn't do it from the menu. The package
tools work differently in that situation. I seem to get broken
packages a lot. apt isn't apt-get or aptitude or synaptic or wajig or
apt-cache or dpkg, but they probably all use the APT library.
Post by Luke Kenneth Casson Leighton
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did, if
so, whoops...)
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or
directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error 1
make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h except in
some obvious biology related programs. unrelated to openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in the
repo's?
there's a file search "thing" somewhere, for apt... it's a plugin (i
think)... although i suspect you simply have the wrong version of
openssl installed.
ok so i do have /usr/include/openssl/bio.h (makes it easier if
$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js
ok so you'll need to do "apt-get install libssl-dev" and that *should*
get you the missing openssl/bio.h file.
"apt-get build-dep linux-image-4.something.something"
that will install *all* build dependencies for a *debian* kernel build
process... which (warning) may be a little bit more than you bargained
for, you'll have to review what it recommends to install before
proceeding, ok?
basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.
problems come when debian sets different options from the default, and
you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
Post by Luke Kenneth Casson Leighton
never had *any* problems - at all - that weren't caused by doing
something incredibly stupid such as "ctrl-c" in the middle of an
installation (at the point where dpkg is being called), and even then,
apt-get -f install in almost 100% of cases fixed the "problem that i
had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.
What the gui is good for is showing you the exact package name to install
or purge. Nothing else, however capable it might be, can really replace
the look and feel of a good gui. But I've been corrected before. Teach
me!
:)
* apt-get source {package} - gets the *source code* of a package
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)
those are typically best done in a chroot, for safety.
* grep filename /var/lib/dpkg/info/*.list
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.
these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and onto
the mouse. i even use fvwm2 with "mouse-over equals window-focus"
very deliberately to minimise clicks. this all because i have
recurring bouts of RSI...
hth.
l.
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Gene Heskett
2019-07-10 01:20:02 UTC
Permalink
Post by Alan Corey
I thought it was possible to have both X and Wayland installed and
just start the one you want to use. Pretty sure I did that when I was
playing with Buster.
I've no clue what they did, but after the update that tipped the nitrous
can way high for video speeds, synaptic is running on buster, but only
on the pi's own screen.
Post by Alan Corey
I can do
apt search
but then I have apt installed. There are several package management
tools. What I like Synaptic for besides the obvious is finding and
fixing broken packages. You can get in there and take out what's
causing the problem, if it doesn't do it from the menu. The package
tools work differently in that situation. I seem to get broken
packages a lot. apt isn't apt-get or aptitude or synaptic or wajig or
apt-cache or dpkg, but they probably all use the APT library.
Post by Luke Kenneth Casson Leighton
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did,
if so, whoops...)
On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And
no, aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such
file or directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error
1 make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h
except in some obvious biology related programs. unrelated to
openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in
the repo's?
there's a file search "thing" somewhere, for apt... it's a plugin
(i think)... although i suspect you simply have the wrong version of
openssl installed.
ok so i do have /usr/include/openssl/bio.h (makes it easier if
$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js
ok so you'll need to do "apt-get install libssl-dev" and that
*should* get you the missing openssl/bio.h file.
Nope.
Post by Alan Corey
Post by Luke Kenneth Casson Leighton
"apt-get build-dep linux-image-4.something.something"
that will install *all* build dependencies for a *debian* kernel
build process... which (warning) may be a little bit more than you
bargained for, you'll have to review what it recommends to install
before proceeding, ok?
basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.
problems come when debian sets different options from the default,
and you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get
source' deb-src http://raspbian.raspberrypi.org/raspbian/ buster
main contrib non-free rpi
never had *any* problems - at all - that weren't caused by
doing something incredibly stupid such as "ctrl-c" in the middle
of an installation (at the point where dpkg is being called), and
even then, apt-get -f install in almost 100% of cases fixed the
"problem that i had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.
What the gui is good for is showing you the exact package name to
install or purge. Nothing else, however capable it might be, can
really replace the look and feel of a good gui. But I've been
corrected before. Teach me!
:)
* apt-get source {package} - gets the *source code* of a package
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)
those are typically best done in a chroot, for safety.
* grep filename /var/lib/dpkg/info/*.list
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.
these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and
onto the mouse. i even use fvwm2 with "mouse-over equals
window-focus" very deliberately to minimise clicks. this all because
i have recurring bouts of RSI...
hth.
l.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Alan Corey
2019-07-10 03:50:01 UTC
Permalink
So? You don't need it that often. I don't get why you can't start up
X and run Synaptic, then switch to something under Wayland. There's
also some compatibility thing where you can run an X program in a
window under Wayland, don't remember what it's called.

I just ordered an Odroid N2, instead of a Pi 4.
Post by Gene Heskett
Post by Alan Corey
I thought it was possible to have both X and Wayland installed and
just start the one you want to use. Pretty sure I did that when I was
playing with Buster.
I've no clue what they did, but after the update that tipped the nitrous
can way high for video speeds, synaptic is running on buster, but only
on the pi's own screen.
Post by Alan Corey
I can do
apt search
but then I have apt installed. There are several package management
tools. What I like Synaptic for besides the obvious is finding and
fixing broken packages. You can get in there and take out what's
causing the problem, if it doesn't do it from the menu. The package
tools work differently in that situation. I seem to get broken
packages a lot. apt isn't apt-get or aptitude or synaptic or wajig or
apt-cache or dpkg, but they probably all use the APT library.
Post by Luke Kenneth Casson Leighton
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did,
if so, whoops...)
On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And
no, aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such
file or directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error
1 make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h
except in some obvious biology related programs. unrelated to
openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in
the repo's?
there's a file search "thing" somewhere, for apt... it's a plugin
(i think)... although i suspect you simply have the wrong version of
openssl installed.
ok so i do have /usr/include/openssl/bio.h (makes it easier if
$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js
ok so you'll need to do "apt-get install libssl-dev" and that
*should* get you the missing openssl/bio.h file.
Nope.
Post by Alan Corey
Post by Luke Kenneth Casson Leighton
"apt-get build-dep linux-image-4.something.something"
that will install *all* build dependencies for a *debian* kernel
build process... which (warning) may be a little bit more than you
bargained for, you'll have to review what it recommends to install
before proceeding, ok?
basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.
problems come when debian sets different options from the default,
and you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get
source' deb-src http://raspbian.raspberrypi.org/raspbian/ buster
main contrib non-free rpi
never had *any* problems - at all - that weren't caused by
doing something incredibly stupid such as "ctrl-c" in the middle
of an installation (at the point where dpkg is being called), and
even then, apt-get -f install in almost 100% of cases fixed the
"problem that i had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.
What the gui is good for is showing you the exact package name to
install or purge. Nothing else, however capable it might be, can
really replace the look and feel of a good gui. But I've been
corrected before. Teach me!
:)
* apt-get source {package} - gets the *source code* of a package
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)
those are typically best done in a chroot, for safety.
* grep filename /var/lib/dpkg/info/*.list
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.
these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and
onto the mouse. i even use fvwm2 with "mouse-over equals
window-focus" very deliberately to minimise clicks. this all because
i have recurring bouts of RSI...
hth.
l.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Gene Heskett
2019-07-10 01:20:01 UTC
Permalink
Post by Luke Kenneth Casson Leighton
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did, if
so, whoops...)
On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And
no, aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such
file or directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error
1 make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h
except in some obvious biology related programs. unrelated to
openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in
the repo's?
there's a file search "thing" somewhere, for apt... it's a plugin (i
think)... although i suspect you simply have the wrong version of
openssl installed.
ok so i do have /usr/include/openssl/bio.h (makes it easier if
$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js
ok so you'll need to do "apt-get install libssl-dev" and that *should*
get you the missing openssl/bio.h file.
"apt-get build-dep linux-image-4.something.something"
What I am trying to build is not available as a deb src. Its a tarball
of linux-5.1.14. So that cmdline errors:
***@picnc:/media/pi/workpi120/buildbot $ sudo apt-get build-dep
linux-5.1.14
Reading package lists... Done
E: Unable to find a source package for linux-5.1.14

I built it once, getting a result that grub could boot, but a pi is a
u-boot, takes a completely different deb to install a new kernel.

I have u-boot-tools installed but still cannot find the magic invocation.
Theoreticly installing mkimage, then invoking "make u-image" ought to
work, but that needs a debian/control file thats apparently made out of
pure unobtainium.

If, in the built tree, top level, I do this:
bash -x scripts/mkuboot.sh

I get this:
Error: Missing output filename
Usage: /usr/bin/mkimage -l image
-l ==> list image header information
/usr/bin/mkimage [-x] -A arch -O os -T type -C comp -a addr -e
ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
-x ==> set XIP (execute in place)
/usr/bin/mkimage [-D dtc_options] [-f fit-image.its|-f auto|-F]
[-b <dtb> [-b <dtb>]] [-i <ramdisk.cpio.gz>] fit-image
<dtb> file is used with -f auto, it may occur multiple times.
-D => set all options for device tree compiler
-f => input filename for FIT source
-i => input filename for ramdisk file
Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)
/usr/bin/mkimage -V ==> print version information and exit
Use -T to see a list of available image types

And I haven't a clue what to tell it for all those options. It seems
like it ought to be a bit more "automatic" based on the host its running
on. This build, all of it, is being done natively on the pi it will be
running on.

So I try to build the pdfdocs, sphinx-build on missing list and apt can't
find sphinx. So whats a guy to do?
Post by Luke Kenneth Casson Leighton
that will install *all* build dependencies for a *debian* kernel build
process... which (warning) may be a little bit more than you bargained
for, you'll have to review what it recommends to install before
proceeding, ok?
I have a 64GB sd card, so I can waste space without to much worry.
Post by Luke Kenneth Casson Leighton
basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.
problems come when debian sets different options from the default, and
you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get
source' deb-src http://raspbian.raspberrypi.org/raspbian/ buster
main contrib non-free rpi
never had *any* problems - at all - that weren't caused by doing
something incredibly stupid such as "ctrl-c" in the middle of an
installation (at the point where dpkg is being called), and even
then, apt-get -f install in almost 100% of cases fixed the
"problem that i had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for
trouble.
What the gui is good for is showing you the exact package name to
install or purge. Nothing else, however capable it might be, can
really replace the look and feel of a good gui. But I've been
corrected before. Teach me!
:)
We are in violent agreement there.
Post by Luke Kenneth Casson Leighton
* apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
Post by Luke Kenneth Casson Leighton
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)
those are typically best done in a chroot, for safety.
Not a chroot, but as the user pi, on a 120GB ssd plugged into a usb2 port
on the pi itself.
Post by Luke Kenneth Casson Leighton
* grep filename /var/lib/dpkg/info/*.list
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.
these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and onto
the mouse. i even use fvwm2 with "mouse-over equals window-focus"
very deliberately to minimise clicks. this all because i have
recurring bouts of RSI...
hth.
l.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Luke Kenneth Casson Leighton
2019-07-10 07:20:01 UTC
Permalink
Post by Gene Heskett
Post by Luke Kenneth Casson Leighton
* apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
doesn't matter: pick the nearest package, that's why i said
"similar". if that's 4.1something.something it will [should] not
matter. if the build dependencies are that drastically different from
kernel to kernel it's an alarm bell.

l.
Gene Heskett
2019-07-10 13:40:02 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
Post by Luke Kenneth Casson Leighton
* apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
doesn't matter: pick the nearest package, that's why i said
"similar". if that's 4.1something.something it will [should] not
matter. if the build dependencies are that drastically different from
kernel to kernel it's an alarm bell.
l.
you are missing the point Luke. Raspberrypi has released new drivers for
the rpi's video, which while not quite as bad as watch paint dry, were
still very noticeable slow, as much as a full second behind the motions
of the machine being controlled. The initial buster-rc2 release on 06-20
gave a glxgears speed if pulled out to full screen of about 1.6 frames a
second. With the new video drivers in place, glxgears pulled out to full
screen runs at 19 fps.

I personally think thats one hell of an improvement, but it takes a
fairly recent kernel to become aware of the updated video libraries to
make use of that. In the raspian case I believe that was accomplished
by backporting those patches to the 4.19.50 kernel. And I also have
doubts that debian with its proscription against proprietary blobs that
probably involves, so debian will be forever stuck with the framebuffer
video, severely limiting the video speed of the armhf releases forever.

So you'll have to pardon, or ignore me while I continue to try to
assemble a u-bootable image that will exploit this new found video
speed, but in a rt-preempt environment.

And yes, I've built several bootable images with rt-preemptable kernels,
all based on the jurrasic 4.14.y kernel, and on boot, none of them have
been able to find the usb wireless stuff, like the extremely common
logitech stuff. And you'll have to admit that no os can do anything
without its own keyboard/mouse.

I rest my case, and since by definition, all progress is made by the
unreasonable man, I will quite likely continue to be that unreasonable
man. And I will make progress if I can figure out the tools.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Luke Kenneth Casson Leighton
2019-07-10 16:00:02 UTC
Permalink
Post by Gene Heskett
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
Post by Luke Kenneth Casson Leighton
* apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
doesn't matter: pick the nearest package, that's why i said
"similar". if that's 4.1something.something it will [should] not
matter. if the build dependencies are that drastically different from
kernel to kernel it's an alarm bell.
l.
you are missing the point Luke.
no, i'm not: you're misunderstanding. allow me to emphasis it by
spelling it out, explicitly.

step 1: use apt-get build-dep
linux-image-4.whatever-is-the-largest-highest-available-debian-image
step 2: COMPILE THE 5.0 UPSTREAM SOURCE CODE.

step 1 installs the prerequisite build dependencies
step 2 gets you what you want.

note that i did ****NOT**** say:

step 1: use apt-get build-dep linux-image-4.whatever
step 2: use apt-get source {the-exact-same-package-name}

now. if you're missing some of the drivers (as you have in the past),
it means that you've not correctly selected the exact same Kconfig
options that would get you the loadable dynamic modules that support
that hardware.

therefore, the easiest way to correct that: you need to track down
what the debian config is which _does_ enable the required hardware.
i haven't done that in a while, so can't recall off the top of my head
the exact process: i'd suggest starting with "apt-get-source
linux-image-4.whatever-is-greatest-that-you-can-find".

again, to reiterate, that is NOT for the purposes or to imply IN ANY
WAY that you should stop trying to do what you are doing and go with
the 4.whatever kernel. you should use the debian 4.whatever Kconfig
AS THE BASIS for what you are trying to do [with the 5.0-or-whatever
kernel].

you may find that some Kconfig options are missing, or their names
changed: this is just how it goes with every revision of the linux
kernel. you'll have to apply some experimentation and thought.

l.
Gene Heskett
2019-07-10 21:00:02 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
On Wed, Jul 10, 2019 at 2:11 AM Gene Heskett
Post by Gene Heskett
Post by Luke Kenneth Casson Leighton
* apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
doesn't matter: pick the nearest package, that's why i said
"similar". if that's 4.1something.something it will [should] not
matter. if the build dependencies are that drastically different
from kernel to kernel it's an alarm bell.
l.
you are missing the point Luke.
no, i'm not: you're misunderstanding. allow me to emphasis it by
spelling it out, explicitly.
step 1: use apt-get build-dep
linux-image-4.whatever-is-the-largest-highest-available-debian-image
step 2: COMPILE THE 5.0 UPSTREAM SOURCE CODE.
step 1 installs the prerequisite build dependencies
step 2 gets you what you want.
step 1: use apt-get build-dep linux-image-4.whatever
The pi is running 4.19.50-v7+ right now, so this should be the correct
translation:
***@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ sudo apt-get
build-dep linux-image-4.19.50-v7+
Reading package lists... Done
E: Unable to find a source package for linux-image-4.19.50-v7+

For every step fwd, 2 back...
Post by Luke Kenneth Casson Leighton
step 2: use apt-get source {the-exact-same-package-name}
now. if you're missing some of the drivers (as you have in the past),
it means that you've not correctly selected the exact same Kconfig
options that would get you the loadable dynamic modules that support
that hardware.
therefore, the easiest way to correct that: you need to track down
what the debian config is which _does_ enable the required hardware.
i haven't done that in a while, so can't recall off the top of my head
the exact process: i'd suggest starting with "apt-get-source
linux-image-4.whatever-is-greatest-that-you-can-find".
again, to reiterate, that is NOT for the purposes or to imply IN ANY
WAY that you should stop trying to do what you are doing and go with
the 4.whatever kernel. you should use the debian 4.whatever Kconfig
AS THE BASIS for what you are trying to do [with the 5.0-or-whatever
kernel].
you may find that some Kconfig options are missing, or their names
changed: this is just how it goes with every revision of the linux
kernel. you'll have to apply some experimentation and thought.
l.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Robert Nelson
2019-07-10 23:20:01 UTC
Permalink
Post by Gene Heskett
The pi is running 4.19.50-v7+ right now, so this should be the correct
build-dep linux-image-4.19.50-v7+
Reading package lists... Done
E: Unable to find a source package for linux-image-4.19.50-v7+
For every step fwd, 2 back...
Hi Gene,

This is a "Raspbian" problem, not a "debian" problem..

I bet if you contact Raspbian developers directly you wouldn't be
spinning your wheels as much..

https://www.raspbian.org/RaspbianForums

Regards,
--
Robert Nelson
https://rcn-ee.com/
Gene Heskett
2019-07-11 01:20:01 UTC
Permalink
On Wednesday 10 July 2019 19:16:27 Robert Nelson wrote:
This is more than likely TL;DR, but you did suggest
Post by Robert Nelson
Post by Gene Heskett
The pi is running 4.19.50-v7+ right now, so this should be the
build-dep linux-image-4.19.50-v7+
Reading package lists... Done
E: Unable to find a source package for linux-image-4.19.50-v7+
For every step fwd, 2 back...
Hi Gene,
This is a "Raspbian" problem, not a "debian" problem..
I bet if you contact Raspbian developers directly you wouldn't be
spinning your wheels as much..
https://www.raspbian.org/RaspbianForums
I'm treated as an outsider. Post's that don't follow the approved recipe
are ignored. You run the supplied code even it it doesn't work. I've
explicitly asked on at least 5 occasions how to do something that's
involved with u-boot, got a link once to some code written in 2001 and
never updated since, that hadn't a single thing to do with u-boot. Zero
response the other 4 times.

Whats really disgusting is that I have watched apt update the pi kernel 2
times now, but it does not leave the deb that did it
in /var/cache/apt/archives. So I've never had an opportunity to take one
of those deb's apart to see if I could figure out how they take a std
kernel build apart and reassemble it into something that works for a
u-boot system. The kernel has a script directory that looks interesting:

***@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ ls scripts
adjust_autoksyms.sh cleanpatch extract_xc3028.pl
headers_install.sh Makefile.gcc-plugins namespace.pl
spdxcheck.py
asn1_compiler coccicheck faddr2line
headers.sh Makefile.headersinst objdiff
spdxcheck-test.sh
asn1_compiler.c coccinelle file-size.sh
insert-sys-cert.c Makefile.host package
spelling.txt
atomic config find-unused-docs.sh
kallsyms Makefile.kasan parse-maintainers.pl
sphinx-pre-install
basic conmakehash gcc-goto.sh
kallsyms.c Makefile.kcov patch-kernel
split-man.pl
bin2c conmakehash.c gcc-ld
Kbuild.include Makefile.lib pnmtologo
stackdelta
bin2c.c const_structs.checkpatch gcc-plugins
kconfig Makefile.modbuiltin pnmtologo.c
stackusage
bloat-o-meter decodecode gcc-plugin.sh
Kconfig.include Makefile.modinst profile2linkerlist.pl
subarch.include
bootgraph.pl decode_stacktrace.sh gcc-version.sh
kernel-doc Makefile.modpost prune-kernel
tags.sh
bpf_helpers_doc.py depmod.sh
gcc-x86_32-has-stack-protector.sh ksymoops
Makefile.modsign recordmcount tracing
cc-can-link.sh diffconfig
gcc-x86_64-has-stack-protector.sh ld-version.sh Makefile.ubsan
recordmcount.c unifdef.c
check_extable.sh documentation-file-ref-check gdb
leaking_addresses.pl makelst recordmcount.h
ver_linux
checkincludes.pl dtc
gen_compile_commands.py Lindent markup_oops.pl
recordmcount.pl xen-hypercalls.sh
checkkconfigsymbols.py export_report.pl gen_ksymdeps.sh
link-vmlinux.sh mkcompile_h selinux
xz_wrap.sh
checkpatch.pl extract-cert genksyms
Makefile mkmakefile setlocalversion
checkstack.pl extract-cert.c get_dvb_firmware
Makefile.asm-generic mksysmap show_delta
checksyscalls.sh extract-ikconfig get_maintainer.pl
Makefile.build mkuboot.sh sign-file.c
checkversion.pl extract-module-sig.pl gfp-translate
Makefile.clean mod sortextable
clang-version.sh extract-sys-certs.pl headerdep.pl
Makefile.dtbinst module-common.lds sortextable.c
cleanfile extract-vmlinux headers_check.pl
Makefile.extrawarn modules.order sortextable.h

mkuboot.sh for instance, but it needs at least 10 arguments:
***@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ sudo bash -x
scripts/mkuboot.sh

++ type -path mkimage
+ MKIMAGE=/usr/bin/mkimage
+ '[' -z /usr/bin/mkimage ']'
+ /usr/bin/mkimage
Error: Missing output filename
Usage: /usr/bin/mkimage -l image
-l ==> list image header information
/usr/bin/mkimage [-x] -A arch -O os -T type -C comp -a addr -e
ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
-x ==> set XIP (execute in place)
/usr/bin/mkimage [-D dtc_options] [-f fit-image.its|-f auto|-F]
[-b <dtb> [-b <dtb>]] [-i <ramdisk.cpio.gz>] fit-image
<dtb> file is used with -f auto, it may occur multiple times.
-D => set all options for device tree compiler
-f => input filename for FIT source
-i => input filename for ramdisk file
Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)
/usr/bin/mkimage -V ==> print version information and exit
Use -T to see a list of available image types

Oh, and the -T? Doesn't change a thing.

But with no docs, what the hell do you do with it?

Hell, I can't even build the pdfdocs, sphinx has been removed from
buster, so all that info is locked away in the minds of a select group
of raspian developers. And I think they want it that way.
Post by Robert Nelson
Regards,
Regards to you too, Robert Nelson. Take care now.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reco
2019-07-11 07:00:01 UTC
Permalink
Hi.
Post by Gene Heskett
The pi is running 4.19.50-v7+ right now, so this should be the correct
build-dep linux-image-4.19.50-v7+
Reading package lists... Done
E: Unable to find a source package for linux-image-4.19.50-v7+
sudo apt-get build-dep raspberrypi-kernel

And before you ask - it won't do you any good.
They cheat and put already-built kernel in there.
Post by Gene Heskett
For every step fwd, 2 back...
Post by Luke Kenneth Casson Leighton
step 2: use apt-get source {the-exact-same-package-name}
sudo apt-get source raspberrypi-firmware

As others said, this maillist is unsuitable place for Raspian-specific
question.

Reco
Gene Heskett
2019-07-11 07:40:02 UTC
Permalink
Post by Reco
Hi.
Post by Gene Heskett
The pi is running 4.19.50-v7+ right now, so this should be the
build-dep linux-image-4.19.50-v7+
Reading package lists... Done
E: Unable to find a source package for linux-image-4.19.50-v7+
sudo apt-get build-dep raspberrypi-kernel
Which auto-subbed raspberrypi-firmware, and did not install anything.
Reading package lists... Done
Picking 'raspberrypi-firmware' as source package instead
of 'raspberrypi-kernel'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Post by Reco
And before you ask - it won't do you any good.
They cheat and put already-built kernel in there.
Post by Gene Heskett
For every step fwd, 2 back...
Post by Luke Kenneth Casson Leighton
step 2: use apt-get source {the-exact-same-package-name}
sudo apt-get source raspberrypi-firmware
This is pulling 193 megs of source, but I've no clue what its going to do
with it.
NOTICE: 'raspberrypi-firmware' packaging is maintained in the 'Git'
version control system at:
***@github.com:RPi-Distro/firmware.git
Please use:
git clone ***@github.com:RPi-Distro/firmware.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 193 MB of source archives.
Get:1 http://archive.raspberrypi.org/debian buster/main
raspberrypi-firmware 1.20190620+1-1 (dsc) [1,581 B]
Get:2 http://archive.raspberrypi.org/debian buster/main
raspberrypi-firmware 1.20190620+1-1 (tar) [193 MB]
Get:3 http://archive.raspberrypi.org/debian buster/main
raspberrypi-firmware 1.20190620+1-1 (diff) [14.6 kB]
Fetched 193 MB in 2min 29s (1,292 kB/s)
dpkg-source: info: extracting raspberrypi-firmware in
raspberrypi-firmware-1.20190620+1
dpkg-source: info: unpacking
raspberrypi-firmware_1.20190620+1.orig.tar.gz
dpkg-source: info: unpacking
raspberrypi-firmware_1.20190620+1-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Add-vmcs.conf-file-to-be-installed.patch
dpkg-source: info: applying
0002-Add-udev-rule-for-dev-vchiq-permissions.patch
dpkg-source: info: applying
0003-Fix-udev-rule-for-dev-vcio-and-vc-sm-permissions.patch
dpkg-source: info: applying kernel_conffile.patch
W: Download is performed unsandboxed as root as
file 'raspberrypi-firmware_1.20190620+1-1.dsc' couldn't be accessed by
user '_apt'. - pkgAcquire::Run (13: Permission denied)
Post by Reco
As others said, this maillist is unsuitable place for Raspian-specific
question.
But at least I got an informative answer, which may be usefull and which
beats their forums like a white mouthed mule.

Thank you very much Reco.
Post by Reco
Reco
Now, to go find where it put it.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Tobias Frost
2019-07-12 15:50:02 UTC
Permalink
Can you please move this discussion to another channel, please!

This ist 1) a Debian mailing list, and raspian ist Not debian 2) Not a User Support list
Philip Hands
2019-07-10 12:50:01 UTC
Permalink
Post by Luke Kenneth Casson Leighton
(hi gene, hope you don't mind, i'm cc'ing the list back again, i
assume you accidentally didn't hit "reply-to-all?" or that i did, if
so, whoops...)
Post by Luke Kenneth Casson Leighton
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement.
used it once or twice, wasn't impressed, returned to apt-get and
apt-cache search, which work extremely well, and have done since
debian began.
What I am trying to do is build a much newer, rt-preempt kernel for
buster on an armhf, aka a pi3b. After having configured it, I try
HOSTCC scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or
directory
#include <openssl/bio.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error 1
make: *** [Makefile:1065: scripts] Error 2
not at all fam with apt-cache search, I have not found a bio.h except in
some obvious biology related programs. unrelated to openssl IOW.
The man page is so long I quickly lose track of all the options.
So how would I state the search that will find it if it exists in the
repo's?
% apt-file find openssl/bio.h
android-libboringssl-dev: /usr/include/android/openssl/bio.h
libssl-dev: /usr/include/openssl/bio.h
libwolfssl-dev: /usr/include/cyassl/openssl/bio.h
libwolfssl-dev: /usr/include/wolfssl/openssl/bio.h
Post by Luke Kenneth Casson Leighton
there's a file search "thing" somewhere, for apt... it's a plugin (i
think)... although i suspect you simply have the wrong version of
openssl installed.
ok so i do have /usr/include/openssl/bio.h (makes it easier if
$ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
/var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
/var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
shriieeeek wtf am i doiiing with nodejs installed, dieee nodejs,
dieeeee sorry about that, adverse reaction to node.js
ok so you'll need to do "apt-get install libssl-dev" and that *should*
get you the missing openssl/bio.h file.
"apt-get build-dep linux-image-4.something.something"
that will install *all* build dependencies for a *debian* kernel build
process... which (warning) may be a little bit more than you bargained
for, you'll have to review what it recommends to install before
proceeding, ok?
basically when doing a build of a package that's similar (or
identical) to an existing debian one, the trick of installing
*debian's* build dependencies for the same name uuusuuually does the
trick of getting you everything you'll need to build that "vanilla"
upstream {whatever}.
problems come when debian sets different options from the default, and
you can always inspect the debian/rules file for what they are.
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib
non-free rpi
Post by Luke Kenneth Casson Leighton
never had *any* problems - at all - that weren't caused by doing
something incredibly stupid such as "ctrl-c" in the middle of an
installation (at the point where dpkg is being called), and even then,
apt-get -f install in almost 100% of cases fixed the "problem that i
had myself caused".
really: if you ask me, relying on GUIs for something as
mission-critical as installation of packages is asking for trouble.
What the gui is good for is showing you the exact package name to install
or purge. Nothing else, however capable it might be, can really replace
the look and feel of a good gui. But I've been corrected before. Teach
me!
:)
* apt-get source {package} - gets the *source code* of a package
* apt-get build-dep {package} - gets you the (full) build
dependencies required to *make* a source package (with
"dpkg-buildpackage)
those are typically best done in a chroot, for safety.
* grep filename /var/lib/dpkg/info/*.list
or:
dpkg -S $filename

I find this rather useful too:
dpkg -L $package
Post by Luke Kenneth Casson Leighton
* apt-cache search "keyword(s)"
* apt-cache show {package} - usually pipe this into more (or less)
* apt-get install {package} - just one.
* apt-get --purge remove {package} - just one.
all four of those functions are available via the apt command these days.
Post by Luke Kenneth Casson Leighton
these are [almost certainly] the commands that synaptics runs,
behind-the-scenes. for me, GUIs just irritate me beyond belief,
because they typically require moving hands off the keyboard and onto
the mouse. i even use fvwm2 with "mouse-over equals window-focus"
very deliberately to minimise clicks. this all because i have
recurring bouts of RSI...
That's OK if you happen to have gone to the effort of learning what you
need to type to get what you want done, but even then you still need to
put some effort into keeping up to date if you want to get hold of new
features.

For instance, I know there's a better search thing for finding packages
than 'apt search ...' because I've seen it done, but I can never remember
it -- you get that sort of improvement for free if it gets added to
whatever UI you were using anyway.

Sadly, I don't have suggestions for better GUI apt-things, as I too
favour the CLI -- I'd guess that KDE has something competent.

There's 'goplay' for finding games and the like (it has other flavours,
such as 'gonet' for things tagged as networky rather than gamey, in the
package), but it's not general purpose, or featureful.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Andrei POPESCU
2019-07-08 13:10:02 UTC
Permalink
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear a
working system down to doing a reinstall to recover, 3 times now.
I used to be a heavy aptitude user in the past, on unstable (i.e. almost
daily package upgrades). It does have it quirks. It also shows very
clearly what it is about to do before you press the final 'g'.
Post by Gene Heskett
It may be capable, but imnsho its also dangerous. Having it do
anything but quit instantly when you hit the quit key q, hit because
you're lost is unforgivable.
Thanks, but no thanks. Having it exit immediately in the middle of a
complex upgrade just because I hit 'q' by mistake is not nice and might
leave your system in a very bad state.

Once an action has been started it might be possible to interrupt it
with Ctrl+C. Please do so at your own risk.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Luke Kenneth Casson Leighton
2019-07-08 14:30:02 UTC
Permalink
Post by Andrei POPESCU
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear a
working system down to doing a reinstall to recover, 3 times now.
I used to be a heavy aptitude user in the past, on unstable (i.e. almost
daily package upgrades). It does have it quirks. It also shows very
clearly what it is about to do before you press the final 'g'.
indeed, as does apt-get (which i much prefer). ultimately, if you
are... how can i put this diplomatically... a GUI gives you the "nice
warm feeling" on presenting you with a nice warm cozy dialog box, "Are
You Sure You Wanna Do This".

apt and aptitude it is assumed that you are... well... hum.... no
other way to say it really..... it is assumed that you are... um...
capable of reading?

sorry if that sounds like it's terribly insulting, there's really not
a way to say it without implying so, because if you don't actually
read the warning - no matter that it's in words that are not
bold-faced and surrounded by a big dialog box - you basically get to
learn *why* the warning is there.
Post by Andrei POPESCU
Post by Gene Heskett
It may be capable, but imnsho its also dangerous. Having it do
anything but quit instantly when you hit the quit key q, hit because
you're lost is unforgivable.
Thanks, but no thanks. Having it exit immediately in the middle of a
complex upgrade just because I hit 'q' by mistake is not nice and might
leave your system in a very bad state.
Once an action has been started it might be possible to interrupt it
with Ctrl+C. Please do so at your own risk.
synaptics i presume actively prevents and prohibits such termination.

recovery of a system that's been terminated in the middle of an
install can actually damage the dpkg database. apt and aptitude exec
dpkg to install individual packages, and, as anyone knows who has
tried to manually install a .dpkg, you interrupt that process, as
andrei says, at your own risk.

of course, it is perfectly possible to f*** up with synaptics as
well: "killall -9 synaptics" whilst it's in the middle of an install
will achieve the exact same level of system-f****g-up-ness.

if you really _really_ get into such a mess, the first action to take
is "apt-get -f install". this uuuusually recovers things back to a
known stable state, and you can re-run apt-get {whatever}

sometimes i've had to do a dpkg -i --force-all {insert package that
failed.deb}, particularly on systems where there's been file conflicts
(very old packages still installed, where new ones have the same
file).

ultimately, though, there is absolutely *NO* excuse for quotes
reinstalling quotes. any debian system is ENTIRELY RECOVERABLE
without resorting to the stupidity of the windows mindset "if it's
broke duhhh reinstall". in really *really* broken conditions (a
kernel upgrade interrupted, a grub replacement gone wrong), you can
run recovery live USB boot media, and repair the damage by chrooting
in to the root filesystem.

in one hilarious incident involving "cpio" i managed to write ARM
files onto an x86 filesystem (in /lib, /usr/lib, /bin and /sbin) *and
still recovered the system* by live-booting a recovery USB stick,
manually downloading the relevant dpkgs, unpacking them and
hand-copying the accidentally-replaced files.

bottom line: if you're relying heavily on synaptics, be worried and
concerned that you're turning into a windows user :)

l.
Gene Heskett
2019-07-08 23:30:01 UTC
Permalink
On Mon, Jul 8, 2019 at 2:01 PM Andrei POPESCU
Post by Andrei POPESCU
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear
a working system down to doing a reinstall to recover, 3 times
now.
I used to be a heavy aptitude user in the past, on unstable (i.e.
almost daily package upgrades). It does have it quirks. It also
shows very clearly what it is about to do before you press the final
'g'.
indeed, as does apt-get (which i much prefer). ultimately, if you
are... how can i put this diplomatically... a GUI gives you the "nice
warm feeling" on presenting you with a nice warm cozy dialog box, "Are
You Sure You Wanna Do This".
apt and aptitude it is assumed that you are... well... hum.... no
other way to say it really..... it is assumed that you are... um...
capable of reading?
I am not as fast as I was once tested at 350 a minute with 95%
comprehension 70+ years ago, one does not become one of the 1% or 2%
that survive a pulmonary embolism without some thinker damage.
sorry if that sounds like it's terribly insulting, there's really not
a way to say it without implying so, because if you don't actually
read the warning - no matter that it's in words that are not
bold-faced and surrounded by a big dialog box - you basically get to
learn *why* the warning is there.
Absolutely, the worst effect that I am rather painfully aware of is a
noticeably poorer short term memory.
Post by Andrei POPESCU
Post by Gene Heskett
It may be capable, but imnsho its also dangerous. Having it do
anything but quit instantly when you hit the quit key q, hit
because you're lost is unforgivable.
I should have qualified that with "and it was doing nothing until I hit
the q." I didn't get the "are you sure" popup whose default is no, it
just started hammering on the drive.
Post by Andrei POPESCU
Thanks, but no thanks. Having it exit immediately in the middle of a
complex upgrade just because I hit 'q' by mistake is not nice and
might leave your system in a very bad state.
Once an action has been started it might be possible to interrupt it
with Ctrl+C. Please do so at your own risk.
synaptics i presume actively prevents and prohibits such termination.
recovery of a system that's been terminated in the middle of an
install can actually damage the dpkg database. apt and aptitude exec
dpkg to install individual packages, and, as anyone knows who has
tried to manually install a .dpkg, you interrupt that process, as
andrei says, at your own risk.
of course, it is perfectly possible to f*** up with synaptics as
well: "killall -9 synaptics" whilst it's in the middle of an install
will achieve the exact same level of system-f****g-up-ness.
if you really _really_ get into such a mess, the first action to take
is "apt-get -f install". this uuuusually recovers things back to a
known stable state, and you can re-run apt-get {whatever}
sometimes i've had to do a dpkg -i --force-all {insert package that
failed.deb}, particularly on systems where there's been file conflicts
(very old packages still installed, where new ones have the same
file).
ultimately, though, there is absolutely *NO* excuse for quotes
reinstalling quotes. any debian system is ENTIRELY RECOVERABLE
without resorting to the stupidity of the windows mindset "if it's
broke duhhh reinstall". in really *really* broken conditions (a
kernel upgrade interrupted, a grub replacement gone wrong), you can
run recovery live USB boot media, and repair the damage by chrooting
in to the root filesystem.
in one hilarious incident involving "cpio" i managed to write ARM
files onto an x86 filesystem (in /lib, /usr/lib, /bin and /sbin) *and
still recovered the system* by live-booting a recovery USB stick,
manually downloading the relevant dpkgs, unpacking them and
hand-copying the accidentally-replaced files.
bottom line: if you're relying heavily on synaptics, be worried and
concerned that you're turning into a windows user :)
Heaven forbid, the end is near! And until about 6 weeks back, the
longest any winders install that came on a machine has lived is about 2
weeks. This is a linux only house.

But I've had to recently buy a windows machine to use as a display for a
redpitaya, a piece of rf test equipment. They promised linux drivers but
they don't work. One of its functions is drawing smith charts of an
antenna. All by a couple boxes that can fit in your T's shirt pocket.
And at a hair less than $800 delivered in 3 days from Slovenia, plus the
winders box for a display ($350) and printer driver for a $100 printer.
It can do in 2 to 5 minutes, what it took a General Radio RF bridge all
night to take measurements that the engineer wrote down and spent the
next day turning into a chart that if he was smart enough to read, tells
him which direction to tune a capacitor, or move a clip on a big coil in
the right direction to improve the match. Only intuition will tell you
how far to move or turn things. But this thing can cut the iteration
time by 95% by running a continuous update as the adjustments are being
made. So most can be made to work well in just a few hours unless the
station owner has loaded the tower so much junk in the last 30 years to
put it out of range of the available tuning adjustments.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Vagrant Cascadian
2019-07-09 00:00:01 UTC
Permalink
Several people have asked in the past including myself, and at least one
other person has asked on this and maybe other recent threads...

Could you please keep on topic for debian-arm?

Simply running debian on an arm system doesn't really give free license
to talk about anything and everything about that system, or other
arbitrary topics entirely unrelated to it. I recognize it's not a black
and white issue, but please make (more of) an effort to stay on topic.

This is expressly listed in:

https://www.debian.org/MailingLists/#codeofconduct

In particular:

"Make sure that you are using the proper list. In particular, don't
send user-related questions to developer-related mailing lists."


Thanks for considering.


live well,
vagrant
Post by Gene Heskett
On Mon, Jul 8, 2019 at 2:01 PM Andrei POPESCU
Post by Andrei POPESCU
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear
a working system down to doing a reinstall to recover, 3 times
now.
I used to be a heavy aptitude user in the past, on unstable (i.e.
almost daily package upgrades). It does have it quirks. It also
shows very clearly what it is about to do before you press the final
'g'.
indeed, as does apt-get (which i much prefer). ultimately, if you
are... how can i put this diplomatically... a GUI gives you the "nice
warm feeling" on presenting you with a nice warm cozy dialog box, "Are
You Sure You Wanna Do This".
apt and aptitude it is assumed that you are... well... hum.... no
other way to say it really..... it is assumed that you are... um...
capable of reading?
I am not as fast as I was once tested at 350 a minute with 95%
comprehension 70+ years ago, one does not become one of the 1% or 2%
that survive a pulmonary embolism without some thinker damage.
sorry if that sounds like it's terribly insulting, there's really not
a way to say it without implying so, because if you don't actually
read the warning - no matter that it's in words that are not
bold-faced and surrounded by a big dialog box - you basically get to
learn *why* the warning is there.
Absolutely, the worst effect that I am rather painfully aware of is a
noticeably poorer short term memory.
Post by Andrei POPESCU
Post by Gene Heskett
It may be capable, but imnsho its also dangerous. Having it do
anything but quit instantly when you hit the quit key q, hit
because you're lost is unforgivable.
I should have qualified that with "and it was doing nothing until I hit
the q." I didn't get the "are you sure" popup whose default is no, it
just started hammering on the drive.
Post by Andrei POPESCU
Thanks, but no thanks. Having it exit immediately in the middle of a
complex upgrade just because I hit 'q' by mistake is not nice and
might leave your system in a very bad state.
Once an action has been started it might be possible to interrupt it
with Ctrl+C. Please do so at your own risk.
synaptics i presume actively prevents and prohibits such termination.
recovery of a system that's been terminated in the middle of an
install can actually damage the dpkg database. apt and aptitude exec
dpkg to install individual packages, and, as anyone knows who has
tried to manually install a .dpkg, you interrupt that process, as
andrei says, at your own risk.
of course, it is perfectly possible to f*** up with synaptics as
well: "killall -9 synaptics" whilst it's in the middle of an install
will achieve the exact same level of system-f****g-up-ness.
if you really _really_ get into such a mess, the first action to take
is "apt-get -f install". this uuuusually recovers things back to a
known stable state, and you can re-run apt-get {whatever}
sometimes i've had to do a dpkg -i --force-all {insert package that
failed.deb}, particularly on systems where there's been file conflicts
(very old packages still installed, where new ones have the same
file).
ultimately, though, there is absolutely *NO* excuse for quotes
reinstalling quotes. any debian system is ENTIRELY RECOVERABLE
without resorting to the stupidity of the windows mindset "if it's
broke duhhh reinstall". in really *really* broken conditions (a
kernel upgrade interrupted, a grub replacement gone wrong), you can
run recovery live USB boot media, and repair the damage by chrooting
in to the root filesystem.
in one hilarious incident involving "cpio" i managed to write ARM
files onto an x86 filesystem (in /lib, /usr/lib, /bin and /sbin) *and
still recovered the system* by live-booting a recovery USB stick,
manually downloading the relevant dpkgs, unpacking them and
hand-copying the accidentally-replaced files.
bottom line: if you're relying heavily on synaptics, be worried and
concerned that you're turning into a windows user :)
Heaven forbid, the end is near! And until about 6 weeks back, the
longest any winders install that came on a machine has lived is about 2
weeks. This is a linux only house.
But I've had to recently buy a windows machine to use as a display for a
redpitaya, a piece of rf test equipment. They promised linux drivers but
they don't work. One of its functions is drawing smith charts of an
antenna. All by a couple boxes that can fit in your T's shirt pocket.
And at a hair less than $800 delivered in 3 days from Slovenia, plus the
winders box for a display ($350) and printer driver for a $100 printer.
It can do in 2 to 5 minutes, what it took a General Radio RF bridge all
night to take measurements that the engineer wrote down and spent the
next day turning into a chart that if he was smart enough to read, tells
him which direction to tune a capacitor, or move a clip on a big coil in
the right direction to improve the match. Only intuition will tell you
how far to move or turn things. But this thing can cut the iteration
time by 95% by running a continuous update as the adjustments are being
made. So most can be made to work well in just a few hours unless the
station owner has loaded the tower so much junk in the last 30 years to
put it out of range of the available tuning adjustments.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Gene Heskett
2019-07-08 22:30:01 UTC
Permalink
Post by Andrei POPESCU
Post by Gene Heskett
yes it was, and no solution was offered that I read about. And no,
aptitude is not a replacement. I've hit q for quit and had it tear a
working system down to doing a reinstall to recover, 3 times now.
I used to be a heavy aptitude user in the past, on unstable (i.e.
almost daily package upgrades). It does have it quirks. It also shows
very clearly what it is about to do before you press the final 'g'.
Post by Gene Heskett
It may be capable, but imnsho its also dangerous. Having it do
anything but quit instantly when you hit the quit key q, hit because
you're lost is unforgivable.
Thanks, but no thanks. Having it exit immediately in the middle of a
complex upgrade just because I hit 'q' by mistake is not nice and
might leave your system in a very bad state.
in all 3 cases, i had not marked anything, and it was sitting there
showing me a list of stuff I had no clue where I was as the highlighted
line would not return to the top of the screen with the usual up arrow
key, so I hit the q to quit. it preceded to remove hundreds of packages,
leaving me with perhaps 5 megabytes of data on the disk. That was
probably a decade ago while running an earlier ubuntu, but I haven't
trusted it since. All I could was dig thru the tool drawer and pull out
the install cd. By then I had been running amanda every night, so I was
able to recover the important stuff. I still am, but I'd not added the
amanda stuff to do a backup to this install until an hour or so ago.
Post by Andrei POPESCU
Once an action has been started it might be possible to interrupt it
with Ctrl+C. Please do so at your own risk.
Obviously.
Post by Andrei POPESCU
Kind regards,
Andrei
Take care Andrei

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Gene Heskett
2019-07-08 12:30:02 UTC
Permalink
Post by Gene Heskett
So, synaptic is gone.
synaptic | 0.81.2 | oldoldstable | source, amd64, armel,
armhf, i386 synaptic | 0.84.2 | oldstable | source,
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el,
s390x
synaptic | 0.84.6 | stable | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | testing | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | unstable | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | unstable-debug | source
What are we supposed to do when the default install uses wayland?

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
John Paul Adrian Glaubitz
2019-07-08 12:40:02 UTC
Permalink
Post by Gene Heskett
What are we supposed to do when the default install uses wayland?
Could this non-ARM-specific discussion be moved to debian-user?

Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Paul Wise
2019-07-08 12:40:03 UTC
Permalink
Post by Gene Heskett
What are we supposed to do when the default install uses wayland?
The XWayland folks plan to allow X11 apps to run as root, which will
make synaptic work when run under X11. Also, synaptic needs to be
split up into user and root components for it to work under Wayland
proper or current XWayland. Until either one of these happens, you can
login using Xorg instead of Wayland. The gdm login manager has an
option for this and other ones should too.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Gene Heskett
2019-07-08 16:00:02 UTC
Permalink
Post by Paul Wise
Post by Gene Heskett
What are we supposed to do when the default install uses wayland?
The XWayland folks plan to allow X11 apps to run as root, which will
make synaptic work when run under X11. Also, synaptic needs to be
split up into user and root components for it to work under Wayland
proper or current XWayland. Until either one of these happens, you can
login using Xorg instead of Wayland. The gdm login manager has an
option for this and other ones should too.
Unforch, this is an automatic login of the user pi, so I never see the
gdm login. So how do I cancel that and return to a normal login?

But that exposes another problem. That login is before x is started, so
No ssh until I do get to its own keyboard and login.

Thanks Paul.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Paul Wise
2019-07-09 03:10:01 UTC
Permalink
Post by Gene Heskett
Unforch, this is an automatic login of the user pi, so I never see the
gdm login. So how do I cancel that and return to a normal login?
Logout and login manually, or disable automatic logins.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Stefan Monnier
2019-07-10 14:30:02 UTC
Permalink
Post by Paul Wise
Logout and login manually, or disable automatic logins.
Why not just switch to another user (and hence login a second time on
another virtual console)?


Stefan
Paul Wise
2019-07-08 12:30:02 UTC
Permalink
Post by Gene Heskett
So, synaptic is gone.
synaptic is still available in all suites on ARM:

synaptic | 0.81.2 | oldoldstable | source, amd64, armel, armhf, i386
synaptic | 0.84.2 | oldstable | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | stable | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | testing | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | unstable | source, amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
synaptic | 0.84.6 | unstable-debug | source
--
bye,
pabs

https://wiki.debian.org/PaulWise
Loading...