Re: loss of synaptic due to wayland
On Tuesday 09 July 2019 10:01:44 Luke Kenneth Casson Leighton wrote:
> (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 7:20 PM Gene Heskett <gheskett@shentel.net>
wrote:
> > On Monday 08 July 2019 08:37:14 Luke Kenneth Casson Leighton wrote:
> > > On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett
> > > <gheskett@shentel.net>
> >
> > wrote:
> > > > 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
> > a "make" and in about a minute, am getting a missing openssl/bio.h
> > exit:
> >
> > pi@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ make
> > 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"
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:
pi@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?
>
> 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.
>
> 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.
>
> > My /e/a/sources.list:
> >
> > 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!
> >
> :)
>
> on-list is better (other people benefit too). these are what i use:
We are in violent agreement there.
> for source stuff:
> * apt-get source {package} - gets the *source code* of a package
doesn't exist, this stuff is tar.gz's straight from kernel.org
> * 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.
>
> 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.
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>
Reply to: