The officially official Devuan Forum!

You are not logged in.

#76 Re: Other Issues » Boinc » 2017-10-05 23:33:51

I got to look at the einstein project directory.

There are two executables in that directory now, one is a statically linked 64 bit file (so ldd can't help on that).  The other is a dynamically linked 32 bit program.  Two of the libraries are not found.  I have tried downloading the packages for LibGL.so.1 and libX11.so.6 for i386, but there is a conflict at the moment for ascii/ceres that involves my choice of using LLVM-5.

#77 Re: Other Issues » Boinc » 2017-10-05 15:19:25

Hello gdagar.

Working on the farm, there are always things to keep me occupied.  I try to only work on computer problems when I don't want to be outside.  Since we've had a drought much of the summer, there have been few rainy days.

The computer with the dual core AMD64 and the HD5450 is running World Community Grid CPU jobs.  At the moment, there is 1 job running, 2 to report, and 4 tasks with computation error (I wonder what happened there?).  I will have to look into the GPU issues a little later.  I may put a RX550 in this, but the power supply is quite small.

---

I upgraded another computer from B24 dual core to 8 core FX-8320e, and put back the RX-460 I meant to run there over the last few days.  I installed Devuan/Jessie to a 40 GB partition on SSD from DVD (the install from the Jessie CD wouldn't work, something about network access).  A fairly minimal install.  I then upgraded that to Ascii/Ceres and a 4.12 kernel.  On the SSD I had the root, /boot, /usr and /var partitions of Debian/Jessie.  I removed almost everything that was OS (so mostly /etc left), and made a tarball of that.  All of those partitions were ext4.  I then redid the root partition as btrfs, and unrolled the tarball on the root partition.  I then pruned what was below /boot, /usr and /var.  After that, I mounted the 3 "Debian" partitions at the appropriate places, and copied (with archive switch set) all of the Devuan/Ascii-Ceres to this set of 4 partitions.  I adjusted the few files in /etc that needed adjusting.  Chrooting into the root partition and running update-grub was not sufficient to allow this to boot, I had to dpkg-reconfigure grub.  But it booted then.

I had partitions for swap, /tmp, /var/log and /usr/local on another disk, which were relisted in fstab.  And this "homeless" system booted fine.  Even seamonkey in /usr/local ran.

I then loaded in clang-5.0, llvm-5.0, mesa, opencl and boinc stuff.

Boincmgr ran fine the first time.  I removed the hold on new tasks for setiathome and einstein.  Nothing was downloading for quite a while.  I looked in the logs a bit, and I had been dumb.  The UID and GID for boinc had changed, so it couldn't write things.  Fix permissions, and jobs started appearing.  All of them failing (GPU and CPU jobs).

I started today by setting dpkg to allow for i386 libraries if it needs to, but haven't installed any yet.  I then entered the setiathome project directory with emacs in dired mode and shell in the other half window.  And I started running 'file' against files found there, to find out what they are (and to run ldd against the executables I find).

There is an ELF32 file there, with Oland in the name (so some kind of GPU file) of unknown architecture that is reported to have a corrupt program header size (according to file).  ldd says it is not a dynamic executable.  And another similar file of same properties.

And there are four different 8.22 ati OpenCL files, which are all x64 ELF executables with ldd reporting that all of them have the libraries they need to run.

I don't seem to find any executable files meant to run on the CPU (only).

I haven't yet looked through the einstein directory, to see if there is anything to find out there.  But BOINC seems to clean too much up after problems, so I probably need to visit the two projects in question to see if there are stdout or stderr outputs that have more information on the problems.

#78 Re: Other Issues » Boinc » 2017-08-25 00:39:21

Rebooting didn't fix things.

I deleted libcurl4-nss-dev and the binary library associated with it, and installed libcurl4-gnutls-dev and recompiled BOINC client from the Berkeley source.  Of course, make install overwrites a couple of things.  :-)  But, it connected to SETI@Home and downloaded some tasks and it is working.  Sort of, it doesn't seem to be doing any GPU work.  I think there are a bunch of 32bit libraries a person has to have installed, in order to do GPU work on an amd64.  But I'll work on that later.  I am trying to get that working via Mesa3d/Clover, instead of that deprecated binary junk from amd that was not really supported at the best of times from what I can tell.

#79 Re: Other Issues » Boinc » 2017-08-24 19:39:03

I updated anything SSL/NSS/GNUTLS related, and I ran update-ca-certificates.

Problem still exists.

Libraries cached in memory/swap, and I need a reboot to "fix" things?

#80 Re: Other Issues » Boinc » 2017-08-24 15:16:04

I was hoping that what I am now seeing, was what leloft had for a problem, but it is different.

I've tried connecting to Seti@Home, World Community Grid and Einstein and there is no connection.  I don't seem to have any firewall blocking things, but I suppose looking at what iptables is doing might be useful.

A Boinc or Seti forum suggested setting http_debug, http:xfer_debug and file_xfer_debug in cc_config.  I am manually typing in (edited) snippets of error messages, so there could be typos.

TCP_NODELAY set
Connected to Boinc port 443
Initialising NSS with certpath:none
WARNING: failed to load NSS PEM library.  Using OpenSSL PEM certificates will not work.
HTTP error: Problem with the SSL CA cert (path? access rights?)
...
Next it tries the SetiAtHome server at Berkeley, and this seems to handshake and everything.
Downloads some stuff.
Tries the same to SetiAtHome as Boinc, and we see the NSS PEM thing again.
Then it tries https to google.com, and same NSS PEM thing and gives up.

/var/lib/boinc-client/ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt

The ca-certificates.crt file is 261407 bytes, 644 permissions root.root ownership.

Not sure what else needed.

#81 Re: Other Issues » Boinc » 2017-08-24 03:05:43

The edited Debian/Jessie BOINC init.d and default files work to get things at least started.  The 'make install' of the Berkeley source tree seems to have installed its own init.d file, which is more involved than the Debian one is.

Starting the boinc client with the init.d script, showed no evidence of any GPU capabilities.  Editing the group (and gshadow) files, to add boinc to the video group, and to add the ordinary user to the boinc group resulted in BOINC recognizing the GPU on a restart of the boinc client.

But at this point, I have no BOINC stuff in /etc.  So, I need to move a copy of that from one of my Debian/Jessie setups.

#82 Re: Other Issues » Boinc » 2017-08-22 13:47:13

Nope, it wasn't tomorrow.  Actually more than 1 day later.

I have the compiled source tree for "client only" from BOINC installed in /usr/local.  I copied the startup script from a Debian/Jessie (/etc/init.d/boinc*) to this Devuan.  One edit of consequence so far, and that is to point at the binary in /usr/local/bin.  Just comments otherwise.

The Debian startup file sources /etc/default/boinc* (I am being lazy, the filename starts with boinc), and this Devuan machine still has a file in /etc/default of the appropriate name.  The Debian file has a blurb about ENABLE=1 in it, to show that it has been set up and BOINC should run.  The Devuan file has nothing like this.  Actually, the Devuan file has no active lines in it, it is all blank lines and commented out lines.  Is this how Debian/testing is set up now?  Or how did the Devuan file end up being so different?

There are a few assumptions in the init file which I will change, to see if this works.  Not sure if I will finish this today or not.

#83 Re: Other Issues » Boinc » 2017-08-14 03:19:12

ghaverla wrote:

Churn on things for a minute or ten.

Tonight, I compiled the client side of the BOINC source tree (from BOINC, not from Debian/Devuan).  And it is version 7.7.0 I believe.

Well, it is a different compile process than I have seen before.  And very little documentation as to what make targets are present, and what they are for.  I tried a make test, and there is no test target (maybe only CPAN has this typically?).  Looking in the Makefile, I tried a make dist, and that failed.  Make install should usually fail for ordinary users, as they shouldn't have write permission to /usr/local.  But changing to root and running make install, did install some stuff.

Boincmgr runs, it doesn't like that the BOINC core client isn't running.  Something for tomorrow.

----

In terms of what BOINC packages installs, at the present time dpkg -l | grep boinc reports boinc is not installed.  I do have "old" packages installed.  There are no *inst files related to boinc on the system.  All of the devuan packages show each package has debian-binary, control-tar.gz and data.tar.gz components.

----

In any event, tomorrow I will see if I can get the core client running even though there are no jobs.  It could be interesting as I need to specify where these are stored, and what I ran into on Devuan was this stuff was going in $HOME, and not in /var.  But maybe I will figure out what is going on.

#84 Re: Other Issues » Boinc » 2017-08-14 03:07:42

leloft wrote:

I am also experiencing Boinc problems after upgrading to ascii this morning.  It appears to be related to the kernel version:

[ snip ]

I am not the greatest sysadmin debugger in the world.  Do you have logs (from the /var/log or from $HOME/.xsession*)?  Are they showing anything?  Do you get any more information if you start the programs from a command line, instead of from a GUI?

#85 Re: Other Issues » Boinc » 2017-08-13 03:04:13

Churn on things for a minute or ten.

There were always two different problems with BOINC:
1. A user wants to run BOINC when they are logged in.
2. The system wants to run BOINC all the time (to use up cycles).

What I had on Debian, is solution 1, except that the data is kept in /var, which is a system thing.

It seems to me, that the "overview" package needs to be one, which will allow a system BOINC process to run, or allow whoever is logged in to X to run BOINC processes.  And then a person installs a boinc-system and/or boinc-user packages to handle the specifics.

Easy for me to say, I have never written something like this.  I think.  Maybe.  Sometimes.  Without enough beer.

Ideas?

#86 Re: Other Issues » Boinc » 2017-08-13 02:40:34

Hmmmm, no replies.  Aka - Gord, do more work.

Okay, we'll see what happens.  I've got a system move from an ATX to a mini-ITX, and a new system to go into the ATX tower.  All wanting to do BOINC.

Have a great day people!

#87 Other Issues » Boinc » 2017-07-14 14:36:12

ghaverla
Replies: 22

I had boinc running on the first (of 4) Debian/Jessie machines which got upgraded to Devuan/Jessie, and then got upgraded again to Ascii/Ceres.

It had been running fglrx (aka Catalyst) as it had a HD 5450 in it.

Before the upgrade, I changed settings in the manager so that it did not download new work.  And it was allowed to finish all the work it had, and upload it.

I upgrade systems seldom and how to properly upgrade boinc in such a situation is not fluid in my head.  I thought it would be enough to just let the existing jobs finish.

As doing OpenCL via open source has improved a lot via Mesa3D, LLVM and others, I was thinking of seeing if this HD 5450 could be made to work with the open source OpenCL system.

I downloaded the various boinc packages from Devuan and tried to set things up get it working again.  At one point it had downloaded some work.  But trying to get the manager to communicate with the client only worked that one time.  Starting the manager from the GUI menu had different effects than starting from the command line.  gui_rpg_auth.cnf was a problem.  The new (on Devuan) package seems to want to start a data store in the user's $HOME, which I had never seen before.

Some of this may be the difference from Debian/Jessie to Debian/Sid.  It could be something done in conversion to Devuan.  I spent the day fighting things and not getting anywhere.  At one point, I downloaded strace and collected a strace log of the boincmgr (23k lines).  I didn't finish wading through that.

Growing frustrated, I wondered what was available from upstream.  My other Debian systems are running a 7.6.x version of boinc.  The boinc site has a 7.2.x package available?  Sorry, I don't want to go that far backwards.  Okay, over to the git and clone it.  It is version 7.7, so newer than what I was working with.  A few hiccups in getting dependencies of the compile going, but I've compiled much of that now.  It wants to work with MySQL to be a boinc server (almost nobody needs that, that is for projects to distribute work units), and doing a quick search it doesn't look like anyone has converted to MariaDB.  I have to go get farm parts today, so it will be a few hours before I can look at the results of the compile to see if that works here.

Maybe the gremlins will diffuse out of the system, and re-installing boinc from scratch again (I did it 3 or 4 times yesterday) may then work.  Maybe someone with better boinc-fu than I, may happen on this note and realize what I did wrong (my old boinc /var/lib/boinc-client is still on the old hard disk if I need it) and point me to the error.

Thanks for any wisdom/comments.

--

As Red Green has been known to say, "Keep your stick on the ice.".

#88 Off-topic » FHS evolution » 2017-07-11 02:18:32

ghaverla
Replies: 1

A while ago (2 years?), I learned that people were moving towards putting all binaries in a single directory.  As I understand it, the driving force for this is the "need" to listen to music while the computer is booting.  That this makes booting slower is irrelevant.

I think there are perfectly good reasons for /bin and /sbin to reside on the root partition, and for /usr not needed to be mounted at boot time.  And there are parallels for /lib and /usr/lib.  There are lots of different programs residing in /bin and /sbin (not as many as /usr/bin).  I think a fair fraction (major? most?) are programs which a casual user will never knowingly invoke in their lifetime  unless prompted.  Reading an article on:
__ cat dog
__Can't cat dog
May get someone to run cat, but normally users don't run cat.  Another class of programs in /bin and /sbin are programs that no casual user has any business running.  They might run them in an attempt to screw around with the system.  But in general, they should not even know of the existence of those programs.

The biggest namespace problem for user programs I have ever run into, is to have Arc/Info on a UNIX machine.  The info/texinfo documentation system has a namespace clash with the Arc/Info program to access data (info).  But as I was the only person reading documentation, it was easy to find a way to let most people find the Arc/Info info program.

We need to keep a simple boot process (with text files controlling what happens, and text log files).  So that a simple editor like vi can be used to fix boot problems.  We may need to get systems to boot faster, so that users can get their music sooner.  But I think booting off a SATA SSD goes a long way towards that.  If things are still a problem, get them booting off a m.2 SSD.

I have a friend who unintentionally screws up his /etc too often.  So, maybe the time is here for me to look at etckeeper, as I think it may help with his issues.  But this falls back into the /usr problem.

We don't need to have configuration information about packages that are not installed in the root partition, in the root partition.  So, we really need a /usr/etc filesystem to store all the /usr package configuration.  But in terms of what happens when the machine has finished booting, that information should be in /etc.  So, we have a /etc/usr filesystem, which is probably a symlink to /usr/etc, and we stick all the /usr configuration information there.

This probably reduces how many configuration files and directories are on the root partition a lot.  Maybe to the point where a person might dream of a common config (text) file format for all of those files.  And rationalizing the files so that a particular piece of information is present once (or as few times as is possible, and if multiple occurrences are possible, they are documented).  And maybe someone writes the etcedit gui, to allow a single application to display or edit all the data in the root partition of /etc.  And that gui goes in /usr/sbin.

Someone else want the soapbox to stand on?  :-)

#89 Re: Desktop and Multimedia » Guayadeque-0.4.5 on Ascii/Ceres » 2017-07-10 18:06:06

golinux wrote:
ghaverla wrote:

I had never run across this d1h (dlh?) program before.  New tool to build packages?

Yes and posted on this forum in Documentation: https://dev1galaxy.org/viewtopic.php?id=549

I've no idea what distribution I might package this for.  For the moment, I think I will just stick to (a copy of) the original source tree, to see if I can de-dbus it.  Then I can look into getting a git account and so on.  I did like the next comment in that thread (go get a beer).  :-)  Adventinus (Schneider and Sons) is one of my favorites.

Oh well, time to go do some farming.  Cool and somewhat windy today.

#90 Re: Desktop and Multimedia » Guayadeque-0.4.5 on Ascii/Ceres » 2017-07-10 16:07:51

The CMakeList... file gets it from some cmake file in /usr/share (GNUInstallDirs.cmake), but I gather setting that environment variable is the thing to do.  But I would have thought that installing into /usr/local (or /opt) would be the default place to install to.

If we go to the trouble of removing dbus (or systemd, or ...) from some package, what is the preferred way to pass on this knowledge?  A diff of the two source trees?  A unified diff?  Merge the new package into an old deb source tree and try to make that compile just like real source debs?

Are we supposed to follow your thread about slim?  I had never run across this d1h (dlh?) program before.  New tool to build packages?

#91 Re: Other Issues » upgrading all machines on a LAN, and apt-cacher-ng » 2017-07-10 15:45:58

PeteGozz wrote:

I have no idea how well it would work as a standalone NTP server.
Your ISP does not do this ?
Or is this a copper wire thing ?

So you would broadcast NTP on wireless ?
Sweet.

I had run across an article about using a Odroid-C2 with NTP and gpsd.  You need to find some way to generate the 1PPS signal (some GPS hardware has this, some doesn't).  After getting the 1PPS, the next step up for a good NTP server, seems to be keeping the temperature constant, so this typically means building an "oven" of some kind, that you can heat to a temperature a little above room temperature.  Then I found what seemed like a good price on a GPS chip, which in older versions of the firmware, allowed access to real time kinematic data (but missed out on the Chinese (Baidu?) and Galileo GPS constellations).  So, there was the possibility of setting up a GPS base station (with real time kinematic), a rover (RTK as well, and probably XBee or similar to push the data at 900 MHz), and setting up a NTP/gpsd time server (to donate to my local ISP).  Looking at locations of time servers in "Canada", they all seem to huddle along the Canada/USA border.  I think the only north one was Fairbanks/Alaska.  It probably would be nice to have a NTP server in the Peace Region (where I live), if for no other reason that it is hard to get good time service if you only talk to a single NTP server.

In any event, the Odroid NTP server I read about, was serving 20k replies per second in testing (per minute?).  A relatively large number.  Even if everybody in Dawson Creek was sending a single request per second (normally you send about 1 request per 4 hours or slower), that is still less than 20k/s.

I hadn't thought about putting it on wireless, probably worthwhile.  It would probably be useful to do something with that data band that seems to be associated with (each) FM radio station.

#92 Re: Desktop and Multimedia » Guayadeque-0.4.5 on Ascii/Ceres » 2017-07-10 14:05:57

Running ldd against the binary, there is a link to both libgio and libdbus-1.  So I think I will have to go dig into the code and see where dbus comes into things.  Practice for trying to get a bunch of GPU/OpenCL stuff to run in the near future.

#93 Desktop and Multimedia » Guayadeque-0.4.5 on Ascii/Ceres » 2017-07-10 13:46:11

ghaverla
Replies: 5

I've grown used to using guayadeque for some music playing/recording needs, but this long stable (0.3.7) has had a couple of quirks.  There is a beta in the project git, so I decided to try that.  There hadn't seemed to be any tie in to systemd, there was published a dependency on dbus that I was going to attempt to get around.

I downloaded the zipball from the git.  The README lists the following dependencies:

taglib, sqlite3, libcurl, gstreamer1.0, WxWidgets3.0, libdbus-1, libgio, libwxsqllite3.

Guayadeque is built by cmake, so it is a dependency as well.  Maybe.

I was not sure what taglib might be in Debian (I initially tried taglib-cil-dev, which wasn't correct), there are 3 different versions of libcurl (I chose the nss version of libcurl4), WxWidgets it seems is wxgtk and I never tried to find libgio.  Libdbus-1 I ignored.

apt-get install libsqlite3-dev libcurl4-nss-dev gstreamer1.0-dev libwxgtk3.0-dev libwxsqlite3-3.0-dev cmake OTHERS

Running cmake, I ran into something missing, so I added libgstreamer-plugins-base1.0-dev.  Running cmake still has a problem, and libtag1-dev might be the taglib that is missing.

One more missing dependency was libgdk-pixbuf2.0-dev.

So OTHERS can be libgstreamer-plugins-base1.0-dev libtag1-dev libgdk-pixbuf2.0-dev

Now the cmake goes to completion.  There was a warning about libindicate, which is how dbus gets pulled in.  Apparently, cmake is willing to ignore this dbus connection.  I've no idea on libgio, there may have been a message, I ignored it.

From the README, the next step is make install.  Okay, I did that.  For me, guayadeque is being naughty, it installs into /usr, not into /usr/local.

But, it runs straight away.

#94 Re: DIY » Environment to port Debian (or other) to Devuan » 2017-07-08 13:57:27

Pete, imagine seeing you again.  :-)  I hope all is well in your part of the world.

I have little knowledge or experience when it comes to VMs.  I would much rather spend my time on numerical methods.  But, when you are the only programming savvy person on projects, you often have to dabble in other things.  Long ago when I first started with Debian, I had to port token ring drivers so that my Linux boxen could talk to all the NT computers everyone else had.

Well, I have chores outside to do.  Thanks for the options.  Next time we have some weather moving in, I will explore some more.

#95 Re: DIY » Environment to port Debian (or other) to Devuan » 2017-07-08 03:05:34

Most of my computers are still on Debian, the one that is Devuan has little excess disk space.

Yes, I did know that Devuan has a vagrant image (Jessie).  I was hoping to be lazy and find a Ceres image.

But, going back to a Debian machine which had excess disk space, the 4.7 kernel which could do virtualbox is broken, and the upgrade to 4.9 kernels breaks the virtualbox that is available to jessie or jessie-backports.

Pitty, we have thunderstorms moving through the area, which came knock out networking.  I was hoping to work on guayadeque for a bit.

Bah humbug!  :-)

#96 Re: Other Issues » upgrading all machines on a LAN, and apt-cacher-ng » 2017-07-05 02:58:02

Grrr, I hate typing stuff into a box, and then having it all disappear.

Pete, you keep popping up.  I commend you for it.  I gather you live in the Adelaide general region.

[ And it probably never gets cold there.  :-) ]

I didn't bother adjusting things to use apt-cacher-ng for this first install.  I'm slow enough, and I suspect there is a point upgrade on the Debian side, that it probably wouldn't save anything.  I have 2 more "desktops" to update (but the one desktop is intended to live in my truck, to do GIS work while I am travelling) before I get to my server.  Which is intended to have 2 different SATA paths to disks, and 2 different kinds of disks to make up a RAID-10 for /home (on btrfs).

The RPis I have in my immediate future are ODRIOD and Orange Pi.

The ODROID is intended to become a NTP server for my local ISP: except it maybe running in a climate controlled box and other stuff to reduce variance/jitter.

The "Peace Region" of Alberta and BC (Canada) is about the size of Germany, with about 150,000 people living there.  If I can build this NTP server well enough, maybe it will be a useful timesource to the north.  But it hadn't occured to me that maybe my cache of Debian/Devuan packages would be useful locally.  Very few people have heard of Linux, let alone Debian or Devuan.

#97 DIY » Environment to port Debian (or other) to Devuan » 2017-07-05 02:27:42

ghaverla
Replies: 5

I had a message prepared, it timed out.  Bummer.

Different approach.  I don't know that Vagrant is the preferred approach to virtual machines on Devuan, I suspect it is.  I know I would shy away from Docker based on systemd.

To compile a source package on Debian, there is magic to install all the necessary packages to successfully compile the package.  Devuan has packages that are of lesser interest, and so a person wants to install all the packages except some list.  Systemd and dbus seem to be the front runners, there may be others.

Is there a tool (or something) which will populate a VM with packages, except for some?

If a person builds a package for Devuan (with constraints) and it works, is there a way to save this knowledge to Devuan?

Documentation on how to find dependent code to remove, to help in this?

#98 Re: Other Issues » reportbug » 2017-07-04 20:33:48

I proceeded to install tinyproxy, and reran:
  HTTP_PROXY=http://127.0.0.1:8888/ reportbug slim

Well, it seems likely that the HTTP_PROXY is there to help in downloading the search for bugs against the package, and not to submit the bug.  Whether or not the proxy is defined, it cannot communicate with Devuan BTS.

[ Question: does it really mean Devuan BTS, or Debian BTS? ]

Okay, get past that.  I want to continue.

So, I can compile a bug report after all.  Do my typing practice, and try to submit.  So here we are, some random site on the Internet trying to connect to the SMTP port at bugs.devuan.org, and we get 550 - relay not permitted.

Which is kind of what I thought would happen.

I now have a file sitting in /tmp on a machine not configured to send email.  And if I reboot the computer, I probably find that file has disappeared (cleanup in boot process).  So, if I want to submit the report, I need to transfer that file to a machine which is configured to send email.  (Properly.) 

Earlier today, I happened across a transcript of an "IRC chat" (?) between a few people at Debian, back in 2010 I believe.  About problems with reportbug.  I didn't read the entire transcript, but by and large the problems listed are still problems today.  And things like the man pages being opaque to novice users  is part of this.  The transcript sort of had a target of setting up a web based bug submission process.

Let's say we have a PC with a new install of Devuan on it, and reportbug is configured to send reports somewhere.  If it cannot send SMTP (because it is some random site on the Internet, and not a real MTA or SMTP that the receiving site can trust), is there some way to still submit the report?

In my situation, I have an account here at Devuan (I was registered in a now defunct mailing list at one time as well).  What if we have a daemon on the devuan.org side, which can accept bug reports?  Reportbug on our end connects to the daemon, and sends a user string that is registered at Devuan.  The user string and password are concatenated, and used to encrypt the message from reportbug.  (At the moment, I don't happen to have my password, I let the darned web browser memorize it.  But there is a mechanism in place for me to relearn my password, possibly by resetting it.)  If the daemon looks up the password on its end (or something like that) and the beginning of the decoded message starts with:

Devuan Bug Report Submission

then perhaps it could be treated as a bug submission?

Maybe the daemon generates a 2048 bit random key, and sends it back in the handshake once that decode is finished.  The reportbug on my end would then use this 2048 bit key to encrypt further bug reports made by this process.

But, I haven't spent my life thinking about the whys and wherefores of security, so this might not be sufficient.

#99 Other Issues » reportbug » 2017-07-04 14:49:18

ghaverla
Replies: 1

It was suggested that I file a bug against slim.  Okay.

This is an install of Devuan/Jessie from the DVD, that was upgraded to Ascii.  All the old Debian/Jessie /home have not been moved yet, the only account really is "root".

Reportbug had not been configured (obviously).  Tried the generic dpkg-reconfigure -plow, which did nothing, so I read the man page.  I then ran reportbug --configure

It plays 20 questions with me (fewer than 20 in this instance).  It sort of suggests that if I don't have an already established way to send email, that it will make use of a Debian SMTP to do so.  I then try to send a bug report on slim.  Reportbug complains about NoNetwork.  Hmm, I thought the network is up.  Apt-get update works.  querybts slim retrieves all the bugs listed against slim at Debian.org.  So I am guessing that NoNetwork means that the configuration of reportbug has not listed a SMTP to use in sending the report.  Which means how I interpretted the lack of an SMTP on this machine is wrong.

---

I have 3 "desktop" machines, a router (OpenWRT), a "modem" (Ubiquity PTP) and 1 "server"  on the LAN at the moment, in the not too distant future there will be 2 or 3 RPi type things as well.  The server does have a configured exim (and claws) which can send email via a SMTP on the Internet.  (Or, I think exim is configured to do so, may not be tested adequately.)  All of the other desktop computers on the LAN at the moment are Debian, and if this is to be Devuan specific there would be a problem anyway.

But, it would be nice if I have to provide the path to send email to the bug system (is it at Debian, or at Devuan?), that it could be sent via my "server".

---

In the spirit of that sending bugs for a LAN by a LAN server comment, having a "server" has other contexts.

For example, I like to run gkrellm.  This program can query an external site for the weather.  If I have 4 desktops all with gkrellm querying the weather every 10 minutes, that is on average 4 queries every 10 minutes.  Really, the server should be the one doing the query to the external site.

#100 Re: Desktop and Multimedia » New (ascii from jessie) install, mouse not working » 2017-07-03 17:29:45

There shouldn't have been any Debian/Jessie or Debian/Wheezy hanging around, this was a Devuan/Jessie install upgraded to Ascii.  I guess I didn't introduce that well enough.  At some point, I will move over the contents of /home (which was Debian/Jessie).

I will try to get back to this later today, to see what else I can learn.

It is height of summer here.  I am considerably further away from the equator than you are (I am at 56N - Dawson Creek, BC, Canada, where the Alaska Highway begins), and I see Adelaide is at 34S.  So you are somewhere in the 30's S latitude.  I live about 5 miles downwind of a wind farm (130 MW?), and today is windy as well.

Thanks for the help.

Board footer

Forum Software