[DNG] Shutdown/halt versus WiFi and NFS
My desktop is running Chimaera, and I saw this with Beowulf, but didn't spend much time on it then. My network connection is via WiFi, and I have permanent NFS mounts in place. I run SysV init. During halt or shutdown via init scripts, NetworkManager is terminated before the NFS unmount, which brings down the active NIC, and usually the unmount hangs forever, so I have to do a hard reset or power-off. After futzing with it for a while, trying to find a more elegant solution, I ended up just renaming K01network-manager and K02sendsigs in rc0.d and rc6.d. Now shutdown and reboot run reliably. Before that, I tried renaming K01network-manager to K06network-manager, to place it after the NFS unmount, but it ran earlier anyway. I also tried shielding NetworkManager from sendsigs, and I think it would have worked if I could make K0.network-manager run later, but that was about the point I gave up and took a virtual hammer to the issue. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] raspberry pi build - missing lines in /proc/cpuinfo
> On Sat, 14 Dec 2019 02:01:57 +0100 > Wojtek Sawaściuk wrote: > Not quite, I have some other ARM boards, everywhere - I can see more. > Those one below have nothing in common with RBPI nor Devuan. > tbh, cpuinfo without these lines on ARM board is something very new for > me, so thats why my confusion :/ > Also, more confusion - what is relation to information provided by > /proc/cpuinfo (strictly from kernel) with OS version (32/64 bits) ? I was refering the fact that, you called that information, very valuable and reliable to use some functionalities.. :) And I showed that cpuinfo, for ARM devices, is not so reliable. I showed the case were you were with a cpu and it reports another one( the LibreElec case, running a cortex a53 and it reporting a armv6 cpu.. ).. Today cpuinfo for ARM is better, But still far from let's say x86..due to not be so reliable after all( even ARM annouced that some action would be needed to turn it more reliable ).. So we can say that today its a improoving situation from the madness of the past.. For me, the Most valuable information is: CPU implementer : 0x41 CPU part: 0xc07 CPU implementer : 0x41 In this case the Implementer is ARM Itself( so.. its a ARM stock design.. ), even tough that the chip has its own name and company that produced it.. the design is a ARM stock one( 0x41 is the ARM code ). CPU part: 0xc07 which tells me that its a Cortex-A7 design.. -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Fw: Re: What about the boost c++ libraries?
>Date: Sat, 14 Dec 2019 12:56:13 +0100 >From: Aitor > > Only *boost-iostream* and *boost-filesystem* are required in > simple-netaid so far, even though I could do the same job using only > the stardard c++11, of course. > I say this because once somebody said (here, in the mailing list) "no > more wraps, please", but maybe referring to dbus or something similar [*]. > What do you think of? > > Cheers, > > Aitor. > > [*] git-buildpackage is a wrap for dpkg-buildpackage and it's cool. > >I must add that I disagree with the overuse of smart pointers and some >design patterns. >I was rather surprised to see that all the gtkmm forms of >mysql-workbench are singleton! > My Personal Opinion is that libboost, is something very viral in nature.. And libboost itself, is a monster in size.. I would pay attention, to dependencies :) -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] raspberry pi build - missing lines in /proc/cpuinfo
>On Wed, 11 Dec 2019 03:47:56 +0100 >Arnt Karlsen wrote: >> On Tue, 10 Dec 2019 22:32:29 +, s@po wrote in message >> <20191210223229.13b34daeb0ce03b64f74d...@sapo.pt>: >> >> > Even tough that the Userspace is Armel, the Kernel is armhf.. > > ...which was raspberrypi.org's big messy goof, calling their > debian armel architecture fork "armhf", rather than calling > their first product e.g. "raspberrypi" or some such original > name for their first original armel_6_+7ish_hard_float arch. > ARM is the one to blame.. They initially told people that armv6 with vfp will be included in aarch32.. But then, When they created aarch32( the real one...armv7...it has a vfpv3 at least I believe, vector extensions were droped in favour of SIMD NEON 1.0.. ), that idea was droped.. So armv6 could not be in aarch32.. because aarch32 or armv7, is a new architecture.. So compilers for Hardfloat target armv7 only, And not armv6( for which some processors have vfp.. ) So you end with armel for armv6 with vfp( that's why I compiled kernel with hardfloat support, but the userspace is Devuan, so armel.. ). Also, Armel targets ARMv5T, ARMv6( unfortunatly even processors armv6 with vfp, are in that group of arm32 != aarch32 ) -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Fw: Re: raspberry pi build - missing lines in /proc/cpuinfo
>>On Tue, 10 Dec 2019 22:56:06 +0100 >>Wojtek Sawaściuk via Dng wrote: >> >> LibreELEC:~ # cat /proc/cpuinfo | tail -13 >> processor : 3 >> model name : ARMv7 Processor rev 4 (v7l) >> BogoMIPS: 38.00 >> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 >> idiva idivt vfpd32 lpae evtstrm crc32 >> CPU implementer : 0x41 >> CPU architecture: 7 >> CPU variant : 0x0 >> CPU part: 0xd03 >> CPU revision: 4 >> >> Hardware: BCM2835 >> Revision: a02082 >> Serial : 21b04d8e >> LibreELEC:~ # uname -a >> Linux LibreELEC 4.19.36 #1 SMP Sat May 4 17:23:44 CEST 2019 armv7l GNU/Linux >> >> >> complains I had from https://github.com/WiringPi >> Library couldn't detect correctly hw. >> While I can understand missing info about serial number, maybe hw >> revision - moved somewhere else, but missing *part* of CPU features and >> model name ??? that's completely incomprehensible. >> > >I believe it is not showing you reliable information.. >BCM2835, is armv6, more precisely 'arm1176jzf-s'. >And that processor doesn't have vfpv4, and I believe also doesn have vfpv3, it >as vfp. > >So, you should be in 'BCM2836' or in 'BCM2837'( running in compatibility mode >aarch32.. ), >Maybe it could be a variant, but at least 'BCM2836'.. PS: My Database says me that you are running a quad-core aarch64 'BCM2837', in a 32 bits OS! So.. can you Imagine how that information is wrong in 'LibreELEC'? Just for testing get this image: https://dev1galaxy.org/viewtopic.php?id=3183 I have not played too much attention to that details, but run a cpuinfo there :) -- Best Regards, tux -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] raspberry pi build - missing lines in /proc/cpuinfo
>On Tue, 10 Dec 2019 22:56:06 +0100 >Wojtek Sawaściuk via Dng wrote: > > LibreELEC:~ # cat /proc/cpuinfo | tail -13 > processor : 3 > model name : ARMv7 Processor rev 4 (v7l) > BogoMIPS: 38.00 > Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 > idiva idivt vfpd32 lpae evtstrm crc32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part: 0xd03 > CPU revision: 4 > > Hardware: BCM2835 > Revision: a02082 > Serial : 21b04d8e > LibreELEC:~ # uname -a > Linux LibreELEC 4.19.36 #1 SMP Sat May 4 17:23:44 CEST 2019 armv7l GNU/Linux > > > complains I had from https://github.com/WiringPi > Library couldn't detect correctly hw. > While I can understand missing info about serial number, maybe hw > revision - moved somewhere else, but missing *part* of CPU features and > model name ??? that's completely incomprehensible. > I believe it is not showing you reliable information.. BCM2835, is armv6, more precisely 'arm1176jzf-s'. And that processor doesn't have vfpv4, and I believe also doesn have vfpv3, it as vfp. So, you should be in 'BCM2836' or in 'BCM2837'( running in compatibility mode aarch32.. ), Maybe it could be a variant, but at least 'BCM2836'.. -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] raspberry pi build - missing lines in /proc/cpuinfo
hello, That lines( "Hardware" , "Revision" and "Serial" ) are not usual in cpuinfo.. But they come in RaspberryPi.. >On 09.12.2019 22:55, Wojtek Sawaściuk wrote: >> Hello fellow Devuaners ! >> Any particular reason why on raspberry PI build, in /proc/cpuinfo there >> are missing information about "model name" , bigger half of "Features" >> line, "Hardware" , "Revision" and "Serial". >> It breaks compliance and create issues. >> A bug, a regression? or some inheritance? >> > >I think I'v found it - >https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1823151 >looks like devuan raspberry pi kernel is bring up from ubuntu ? I don't know were the kernel from Oficial Image came from, probably compiled for it..?? If you feel that those lines are important to you, You can try the Community Armel Image: cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS: 697.95 Features: half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xb76 CPU revision: 7 Hardware: BCM2835 Revision: Serial : b5a8d596 Even tough that the Userspace is Armel, the Kernel is armhf.. -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ armel ] - Migration from Ascii -> Beowulf
>On Fri, 6 Dec 2019 19:22:12 + >Mike Tubby wrote: > > Seems a bit complicated? On big iron I just did: > > point '/etc/apt/sources.list' to beowulf > > apt-get update > apt-get dist-upgrade > reboot > Yes no big Iron, you can do that.. But I have Ram constraints, and disk space :) So baby steps, if not you will stop at half of migration ;) -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [ armel ] - Migration from Ascii -> Beowulf
Hello all, I have done a migration from Ascii to Beowulf, on RaspBerry Pi1 B v1.0[ armel ] point '/etc/apt/sources.list' to beowulf apt-get update apt-get upgrade reboot apt-get update apt-get upgrade apt-get dist-upgrade # lsb-release was not installed.. apt-get install lsb-release And I'm on beowulf.. a 'walk in the park process..', easy! Til now I have not see any problem, but still haven't done a profound analisys.. Yet, ntp,dhcp,bind9,saned,xinet services installed and running! Thanks a lot for the good work! -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script for maintainers
Hello all,
>Date: Mon, 2 Dec 2019 10:13:01 +0100
>From: Edward Bartolo via Dng
>Dear All,
>
>Inits need to understand unit files, give them that functionality.
>That is far more efficient compared to what you are doing.
>
>Pseudo Code:
>1) check for the presence of a unit file
>2) if it exists
>a) branch to function to read unit file and run daemon
>b) if NOT execute shell script to run daemon
>
>Programming allows to create a configuration text file which tells an
>init to be aware of the existence of unit files. This can be used to
>minimize the incidence of bugs for cases where no unit files are used.
>The extra functionality can be debugged in separate functions.
I believe you are talking about Situation 1)( Give SysVInit the Knowledge about
SystemD unitFiles.. )?
Indeed it seems more eficient, at Same time, it could be more dificult, than
what we think of..
I think it will have to "be the future..", at uncertain time.. Or Debian
Understands the mistake they are doing..
But there are there good reasoning responses to this thread..to name a few,
Massimo Coppola, Denis Roio,Hendrik Boom..
There are also( as a short time response.. ) , a option to maintain a colection
of Scripts in the repos, by Arnt Karlsen, and Dimitris..
Taking Massimo Coppola, Dimitris Observations, and others by new order of
priority,
1) Maintain a copy of all init Files in theDevuan repos, just in Case.. asked
by Arnt Karlsen, and Dimitris..
2) Develop a Translation of UnitFiles from SystemD to SysvInit( This proces is
already Ongoing by viverna ? ), and generally accepted by all, including me..
Test it, optimize it, and understand deep, the pros and cons, of porting,
and translating of unit files..
When process working like we like, step into 3).. Generally supported by
Massimo Coppola, Denis Roio, Hendrik Boom, and myself, maybe more even..?
3) Depending of the knowledge acquired in 2),
Implement that into SysVinit, the translation, or Interpretation, of the
UnitFiles..
Turn SysVInit capable to launch SystemD daemons, control them..
Associate each "Runlevel type, etc" of SystemD, and translate them to
{0..6..1} of SysVInit( So that Devuan could be resilient to InitChanges.. ).
-> Add: At Same time, when this infraestructure will be created into
SysVInit,
**Make it Generic**, and capable to accept more Init Systems,let's
say Abstract, or Generic..
Intermediate Language( IR ) ?
Like LSB Scripts Headers( proposed by William (Bill) Moss ), or a
refinement of it.. ?
In This process, at least, I would need to go into references made by Denis
Roio, quoting bellow,
a) a DSL parser for the conversion of unitfiles to shell scripts
say "systemd2sysv".
b) an easy way to test the shell scripts generated, which is also
crucial to the task: the quality of the testing environment.
c) optionally, a way to repackage and test semi-automatically an
existing deb package undergoing this conversion.
I have experience writing DSL parsers and recommend using either:
d) stb_c_lexer by Sean Barrett, part of the STB C lib collection
e) libhammer by Meredith Patterson, part of langsec.org
more complex, but way more secure, not sure if this level of
security is needed however
I don't know if this is the correct order or priority..
Some of them could even be developed at the same time( in parallel ),
At least at some extent, then 3) needs to wait feedback from 2) ( observed by
Massimo Coppola ).
--
Best Regards,
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LSB script headers
On Fri, 29 Nov 2019 13:33:34 -0500 "bill.m.moss--- via Dng" wrote: > I have been following the thread on using systemd unit files as a source > for traditional init scripts. I write BSD headers for my freeBSD system, > /etc/rc.d scripts and used to write LSB headers for /etc/init.d Linux > scripts. What ever happened to the LSB format for scripts. If it still > exists, would that not be a standard to follow? > -- Indeed, is was a good proposition, with a lot of definitions on it.. -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Fri, 29 Nov 2019 12:15:29 +0100 Didier Kryn wrote: > Le 29/11/2019 à 02:08, s@po a écrit : > > freedesktop.org, should adress the situation, > > I don't trust Freedesktop to produce a good quality standard. I > don't know who are the people behind Freedesktop, beyond Gnome and KDE, > but they have produced Dbus and also the practice to automatically > create unwanted directories in your home, unless you disable them > explicitely. > > If "unit" files are something which can be retained (after all, > there might be one non-negative outcome of Systemd), they can be used to > produce init scripts for various init systems, or these init systems > could be made able to, optionnaly, read their configuration from "unit > files". > I don't trust them neither.. But, they should have addressed this problem after all they were waving the flag of standards.. They seems to forgot a Standard Init API mechanism.. shame.. I spoke about that because I took 5 minutes to look at last development of SysVInit, and indeed you find there some stuff about systemd and dbus integration.. I understand the dbus integration as a way, so that SysVinit daemons could coexist with Dbus controlled daemons.. The Idea arrived.. Why not have an Interpreter, for the UnitFiles, that then internally do things as SysVInit does? In this way we could preserve SysVinit daemons functionality, and when impossible( or a "unscallable wall arrive".. ), SysVinit will continue to control, the usual daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port daemons at the speed we can.. ). So this idea is some sort of a patched SysVinit, to have half of the 'Script Injector' idea( the interpreter of unit files part ), and some logic to do it like sysVInit does.. But that would also means.. that we had to have in /etc/init.d/, all the s*tty systemD service files.. which is a bit crazy.. Best Regards, tux -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
Hello All, On Thu, 28 Nov 2019 16:30:41 -0500 Steve Litt wrote: > On Wed, 27 Nov 2019 12:18:55 -0600 > goli...@devuan.org wrote: > > > More fiddling while Rome burns . . . sigh . . . > > > > I'm in a bit of a mood because I thought that a script to convert > > systemd units to init style shell scripts would be worthy of at least > > some discussion. > > > > golinux > > I have good news, bad news, and better news. > > Good news. The latest script at http://www.trek.eu.org/devel/sysd2v/ > appears to make good sysvinit init scripts from a unit file. > > Bad news: That script is just for sysvinit, and in my 1/2 hour look at > it I couldn't find an easy way to pick off info necessary to make > facilities for s6, runit or Epoch. > > Better news: Systemd Unit Files are a pretty good specification of what > any process supervisor should do with a daemon, so converters for s6, > runit and Epoch should be pretty easy to make. Because declaratory Unit > Files are by necessity a superset of script based systems, some human > intervention will be necessary, but not a whole lot. > > Better news: There's an already made collection of runit run scripts, > for the usual suspects, at http://smarden.org/runit/runscripts.html . > I've put out a query for a similar collection of s6 scripts. > > SteveT We have a problem that is already a hipotsis of been solved converting the Service Units, to SysVinit daemons.. Since the Unit Files in SystemD, are "unit...", could we theoretically implement the Stub Interface for the Unit Files in SysVInit, and them threat the cases has we want to??? Because the problem with inits, in Unix Like Systems is that is there NO Standars today.. freedesktop.org, should adress the situation, like they have done in the past with other things.. Nowadays Desktop is more or less standardized.. filesystem more or less... For Init Systems.. theres is no public Standard... So or freedesktop.org adress the case or it will be like a jungle( it is now.. ).. We can also have 2 fronts... 1) Convert the unit.files from SystemD to SysVInit daemons 2) Adapt an API like, only for the unit. files that describe the Services, like a stub, an adaptor, and add it to sysVInit In the 2nd case we parse the unit.files and work the meaning as we want to( but without creating SysVinit files, since we already have what is needed to launch the service.. , **The problem is to control this pseudo service after is running**.. ) ofcourse its a lot easier to talk than do it.. but that would give us plenty of time to recreate the SysVInit script we want to, after that.. But that also means that the Unit.Files language used to describe SystemD services will be "more closer to a standard".. Could be a situation were SysVInit can support the traditional SysVInit daemons, usual runlevels, and such, and interprete the unit files of SystemD, but atribute them to this runlevels?? What do you think? I just want to add my 2 cents,. because I think that any one of this 2 cases is a valid case.. -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan sparc port
> On Fri, Oct 25, 2019 at 09:02:13AM -0700, Fred wrote: > > Hello, > > > > Will there ever be a sparc64 port of Devuan? > > Very very likely no. The focus of this distribution is fixing systemd > caused regression, not porting. And reviving the arch would require a lot > of effort: > Oracle doesn't have a very well defined future for Sparc( the dead line was somewhat defined to 2021 or 2022 iirc ), the next range of devices roadmap, is undefined, but they have put great effort in trying to sell their Oracle Linux distro with Oracle databases as a package( after the amount of bugs found in x86 and others.. ). They have been optimizing Sparc on Linux for Oracle databases, for years.. And they have found a jump in sales.. wether it will be suficient to maintain Sparc Alive, I really don't know.. IMHO, first I think we need ecosystem & stability, later a choose can, eventually, be made on what archs to add.. -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to fix rng-tools hang
Hello All, > Hello all, > I got a strange message from serial console, debugging a image that I am > building.. > The system hangs on startup.. > > [ ok ] Starting enhanced syslogd: rsyslogd. > Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device inode not > found) > /etc/init.d/rng-tools: Cannot find a hardware RNG device to use. > [ ok ] Starting system message bus: dbus. > [FAIL] startpar: service(s) returned failure: rng-tools ... failed! > > Just to clarify, Recent kernels use a Hardware RNG.. so in systems that doesn't have one, you need a Kconfig opion RANDOM_TRUST_CPU Best Regards, -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hello,
On Sat, 26 Oct 2019 11:03:11 -0400
fsmithred wrote:
> On 10/26/19 9:54 AM, s@po wrote:
>
> >>> Where does 'apt-cache policy' get the version number? Oh, maybe it reads
> >>> it from the repo. I see that we have:
>
> >> It could be..
> >> Another place, I searched for and makes sense to me:
> >> http://pkgmaster.devuan.org/merged/dists/ascii/Release
> >>
>
> > So I think it comes from :
> > root@desktop0:~# wget -qO-
> > http://pkgmaster.devuan.org/merged/dists/{ascii,ascii-backports,ascii-security,ascii-updates}/Release|grep
> > Version --color
> > Version: 2.0
> > Version: 2.0.0
> > Version: 2.0
> > Version: 2.0.0
> >
> > Best Regards,
> >
>
> Yes, thank you. I got confirmation from another source that it's in the
> Release file. I'll find someone to make the changes.
>
You welcome,
I also want to take the oportunity to thank you, for the work you have been
doing! :)
Best Regards,
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hello,
On Sat, 26 Oct 2019 14:32:55 +0100
s@po wrote:
> Hello fsmithred,
>
> On Sat, 26 Oct 2019 07:51:21 -0400
> fsmithred via Dng wrote:
>
> > On 10/26/19 1:49 AM, Pontus Goffe via Dng wrote:
> > > Hi,
> > >
> > > On 2019-10-26 02:27, s@po wrote:
> > >> You see here the '2.0' String, and it comes from the funtion
> > >> guess_release_from_apt().. like you can see above..
> > >> The guess_release_from_apt() function:
> > >> 228 def guess_release_from_apt(origin='Devuan', component='main',
> > >> 229 ignoresuites=('experimental'),
> > >> 230 label='Devuan',
> > >> 231 alternate_olabels={'Devuan
> > >> Ports':'packages.devuan.org'}):
> > >> 232 releases = parse_apt_policy()
> > >> 233
> > >> 234 if not releases:
> > >> 235 return None
> > >> 236
> > >> 237 # We only care about the specified origin, component, and
> > >> label
> > >> 238 releases = [x for x in releases if (
> > >> 239 x[1].get('origin', '') == origin and
> > >> 240 x[1].get('component', '') == component and
> > >> 241 x[1].get('label', '') == label) or (
> > >> 242 x[1].get('origin', '') in alternate_olabels and
> > >> 243 x[1].get('label', '') ==
> > >> alternate_olabels.get(x[1].get('origin', '')))]
> > >> 244
> > >> 245 # Check again to make sure we didn't wipe out all of the
> > >> releases
> > >> 246 if not releases:
> > >> 247 return None
> > >> 248
> > >> 249 releases.sort(key=lambda tuple: tuple[0],reverse=True)
> > >> 250
> > >> 251 # We've sorted the list by descending priority, so the
> > >> first entry should
> > >> 252 # be the "main" release in use on the system
> > >> 253
> > >> 254 max_priority = releases[0][0]
> > >> 255 releases = [x for x in releases if x[0] == max_priority]
> > >> 256 releases.sort(key=release_index)
> > >> 257
> > >> 258 return releases[0][1]
> > >>
> > >> I am afraid that this info, you already know..
> > >> I am not a python guy( I love the Lua simplicity way :) ), I can't
> > >> help.. :(
> > >>
> > >> Best Regards,
> > >> tux
> > >
> > > Who is a python guy?
> > >
> > > parse_apt_policy executes 'apt-cache policy' and parses
> > > (parse_policy_line) the output for lines beginning with release matching
> > > o=Devuan and c=main
> > >
> > > longnames = {'v' : 'version', 'o': 'origin', 'a': 'suite', 'c' :
> > > 'component', 'l': 'label'}
> > >
> > > In my case that is
> > >
> > > 500 http://se.deb.devuan.org/merged ascii/main amd64 Packages
> > > release v=2.0,o=Devuan,a=stable,n=ascii,l=Devuan,c=main,b=amd64
> > > origin se.deb.devuan.org
> > > //PG
> > >
> >
> >
> > Where does 'apt-cache policy' get the version number? Oh, maybe it reads
> > it from the repo. I see that we have:
> >
> > pkgmaster.devuan.org/merged/dists/1.0
> > pkgmaster.devuan.org/merged/dists/2.0
> > pkgmaster.devuan.org/merged/dists/3.0
> >
> > and debian has:
> >
> > debian/dists/Debian8.11
> > debian/dists/Debian9.11
> > debian/dists/Debian10.1
> >
> > Maybe those directory names are supposed to be changed when there's a
> > point release.
> >
>
> It could be..
> Another place, I searched for and makes sense to me:
> http://pkgmaster.devuan.org/merged/dists/ascii/Release
>
After some digging I believe it comes from:
root@desktop0:~# apt-cache policy lsb-release
lsb-release:
Installed: 4.1+devuan2
Candidate: 4.1+devuan2
Version table:
*** 4.1+devuan2 500
500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
100 /var/lib/dpkg/status
root@desktop0:~# apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
100 http://pkgmaster.devuan.org/merged ascii-backports/main amd64 Packages
release v=2.0.0,o=Devuan
Backports,a=stable-backports,n=ascii-backports,l=Devuan Backports,c=main,b=amd64
origin pkgmaster.devuan.org
500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
release v=2.0,o=Devuan,a=stable,n=ascii,l=Devuan,c=main,b=amd64
origin pkgmaster.devuan.org
So I think it comes from :
root@desktop0:~# wget -qO-
http://pkgmaster.devuan.org/merged/dists/{ascii,ascii-backports,ascii-security,ascii-updates}/Release|grep
Version --color
Version: 2.0
Version: 2.0.0
Version: 2.0
Version: 2.0.0
Best Regards,
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hello fsmithred,
On Sat, 26 Oct 2019 07:51:21 -0400
fsmithred via Dng wrote:
> On 10/26/19 1:49 AM, Pontus Goffe via Dng wrote:
> > Hi,
> >
> > On 2019-10-26 02:27, s@po wrote:
> >> You see here the '2.0' String, and it comes from the funtion
> >> guess_release_from_apt().. like you can see above..
> >> The guess_release_from_apt() function:
> >> 228 def guess_release_from_apt(origin='Devuan', component='main',
> >> 229 ignoresuites=('experimental'),
> >> 230 label='Devuan',
> >> 231 alternate_olabels={'Devuan
> >> Ports':'packages.devuan.org'}):
> >> 232 releases = parse_apt_policy()
> >> 233
> >> 234 if not releases:
> >> 235 return None
> >> 236
> >> 237 # We only care about the specified origin, component, and
> >> label
> >> 238 releases = [x for x in releases if (
> >> 239 x[1].get('origin', '') == origin and
> >> 240 x[1].get('component', '') == component and
> >> 241 x[1].get('label', '') == label) or (
> >> 242 x[1].get('origin', '') in alternate_olabels and
> >> 243 x[1].get('label', '') ==
> >> alternate_olabels.get(x[1].get('origin', '')))]
> >> 244
> >> 245 # Check again to make sure we didn't wipe out all of the
> >> releases
> >> 246 if not releases:
> >> 247 return None
> >> 248
> >> 249 releases.sort(key=lambda tuple: tuple[0],reverse=True)
> >> 250
> >> 251 # We've sorted the list by descending priority, so the
> >> first entry should
> >> 252 # be the "main" release in use on the system
> >> 253
> >> 254 max_priority = releases[0][0]
> >> 255 releases = [x for x in releases if x[0] == max_priority]
> >> 256 releases.sort(key=release_index)
> >> 257
> >> 258 return releases[0][1]
> >>
> >> I am afraid that this info, you already know..
> >> I am not a python guy( I love the Lua simplicity way :) ), I can't
> >> help.. :(
> >>
> >> Best Regards,
> >> tux
> >
> > Who is a python guy?
> >
> > parse_apt_policy executes 'apt-cache policy' and parses
> > (parse_policy_line) the output for lines beginning with release matching
> > o=Devuan and c=main
> >
> > longnames = {'v' : 'version', 'o': 'origin', 'a': 'suite', 'c' :
> > 'component', 'l': 'label'}
> >
> > In my case that is
> >
> > 500 http://se.deb.devuan.org/merged ascii/main amd64 Packages
> > release v=2.0,o=Devuan,a=stable,n=ascii,l=Devuan,c=main,b=amd64
> > origin se.deb.devuan.org
> > //PG
> >
>
>
> Where does 'apt-cache policy' get the version number? Oh, maybe it reads
> it from the repo. I see that we have:
>
> pkgmaster.devuan.org/merged/dists/1.0
> pkgmaster.devuan.org/merged/dists/2.0
> pkgmaster.devuan.org/merged/dists/3.0
>
> and debian has:
>
> debian/dists/Debian8.11
> debian/dists/Debian9.11
> debian/dists/Debian10.1
>
> Maybe those directory names are supposed to be changed when there's a
> point release.
>
It could be..
Another place, I searched for and makes sense to me:
http://pkgmaster.devuan.org/merged/dists/ascii/Release
Best Regards,
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hi Pontus Goffe,
> Hi,
>
> On 2019-10-26 02:27, s@po wrote:
> > You see here the '2.0' String, and it comes from the funtion
> > guess_release_from_apt().. like you can see above..
> > The guess_release_from_apt() function:
> > 228 def guess_release_from_apt(origin='Devuan', component='main',
> > 229ignoresuites=('experimental'),
> > 230label='Devuan',
> > 231alternate_olabels={'Devuan
> > Ports':'packages.devuan.org'}):
> > 232 releases = parse_apt_policy()
> > 233
> > 234 if not releases:
> > 235 return None
> > 236
> > 237 # We only care about the specified origin, component, and label
> > 238 releases = [x for x in releases if (
> > 239 x[1].get('origin', '') == origin and
> > 240 x[1].get('component', '') == component and
> > 241 x[1].get('label', '') == label) or (
> > 242 x[1].get('origin', '') in alternate_olabels and
> > 243 x[1].get('label', '') ==
> > alternate_olabels.get(x[1].get('origin', '')))]
> > 244
> > 245 # Check again to make sure we didn't wipe out all of the
> > releases
> > 246 if not releases:
> > 247 return None
> > 248
> > 249 releases.sort(key=lambda tuple: tuple[0],reverse=True)
> > 250
> > 251 # We've sorted the list by descending priority, so the first
> > entry should
> > 252 # be the "main" release in use on the system
> > 253
> > 254 max_priority = releases[0][0]
> > 255 releases = [x for x in releases if x[0] == max_priority]
> > 256 releases.sort(key=release_index)
> > 257
> > 258 return releases[0][1]
> >
> > I am afraid that this info, you already know..
> > I am not a python guy( I love the Lua simplicity way :) ), I can't help.. :(
> >
> > Best Regards,
> > tux
>
> Who is a python guy?
This LSB scripts were made in python2.7 and adapted for python3( for what it
seems.. )
I assume they are in pretty much any distro out there..
I agree with fsmithred, they are, some sort of... a "black-magic" art
I don't know who is a "python guy",
I just stated that I am not a Python Programmer, and can't help further :(
Long Story Short:
I stated that I couldn't help, because I am not a Python programmer..
>
> parse_apt_policy executes 'apt-cache policy' and parses
> (parse_policy_line) the output for lines beginning with release matching
> o=Devuan and c=main
>
> longnames = {'v' : 'version', 'o': 'origin', 'a': 'suite', 'c' :
> 'component', 'l': 'label'}
>
> In my case that is
>
> 500 http://se.deb.devuan.org/merged ascii/main amd64 Packages
> release v=2.0,o=Devuan,a=stable,n=ascii,l=Devuan,c=main,b=amd64
> origin se.deb.devuan.org
> //PG
>
Thanks for clarifying that..
Best Regards,
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hello fsmithred,
>
> On Fri, 25 Oct 2019 18:06:06 -0400
> fsmithred via Dng wrote:
> >
> > I don't know exactly where the 2.0 is coming from. It's not in
> > /etc/os-release, /etc/devuan_version or /etc/issue, and there is no
> > /etc/lsb-release file.
> >
> > man lsb_release says
> >"Detection of systems using a mix of packages from various
> > distributions or releases is something of a black art; the current
> > heuristic tends to assume that the installation is of the earliest
> > distribution which is still being used by apt but that heuristic is
> > subject to error."
> >
> > It can't hurt to file a bug report. If you know how to fix it, let us know
> > and we can correct that in the future.
> >
> > fsmithred
>
> That information come from python2.7 'lsb_release' module..
>
> root@desktop0:~# python2.7
> Python 2.7.13 (default, Sep 26 2018, 18:42:22)
> [GCC 6.3.0 20170516] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import lsb_release
> >>> distinfo = lsb_release.get_distro_information()
> >>> print(distinfo.get('RELEASE', 'n/a'))
> 2.0
>
>
> I will try to trace it, to its origin..
>
I think that I now understand the "black-magic part", also the
"/etc/lsb-release" :)
in: /usr/lib/python2.7/dist-packages/lsb_release.py
this doesn't help :
32 RELEASE_CODENAME_LOOKUP = {
33 '1' : 'jessie',
34 #'2' : 'ascii',
35 '2.1' : 'ascii',
36 # '1.3' : 'bo',
37 # '2.0' : 'hamm',
38 # '2.1' : 'slink',
39 # '2.2' : 'potato',
40 # '3.0' : 'woody',
41 # '3.1' : 'sarge',
42 # '4.0' : 'etch',
43 # '5.0' : 'lenny',
44 # '6.0' : 'squeeze',
45 # '7' : 'wheezy',
46 # '8' : 'jessie',
47 }
Initial function:
371 def get_distro_information():
372 lsbinfo = get_lsb_information()
373 # OS is only used inside guess_devuan_release anyway
374 for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
375 if key not in lsbinfo:
376 distinfo = guess_devuan_release()
377 distinfo.update(lsbinfo)
378 return distinfo
379 else:
380 return lsbinfo
I think Its guessed: :)
root@desktop0:~# python2.7
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lsb_release
>>> distinfo = lsb_release.get_distro_information()
>>> print(distinfo.get('RELEASE', 'n/a'))
2.0
>>> lsb_release.guess_release_from_apt()
{'origin': u'Devuan', 'suite': u'stable', 'version': u'2.0', 'component':
u'main', 'label': u'Devuan'}
You see here the '2.0' String, and it comes from the funtion
guess_release_from_apt().. like you can see above..
The guess_release_from_apt() function:
228 def guess_release_from_apt(origin='Devuan', component='main',
229ignoresuites=('experimental'),
230label='Devuan',
231alternate_olabels={'Devuan
Ports':'packages.devuan.org'}):
232 releases = parse_apt_policy()
233
234 if not releases:
235 return None
236
237 # We only care about the specified origin, component, and label
238 releases = [x for x in releases if (
239 x[1].get('origin', '') == origin and
240 x[1].get('component', '') == component and
241 x[1].get('label', '') == label) or (
242 x[1].get('origin', '') in alternate_olabels and
243 x[1].get('label', '') ==
alternate_olabels.get(x[1].get('origin', '')))]
244
245 # Check again to make sure we didn't wipe out all of the releases
246 if not releases:
247 return None
248
249 releases.sort(key=lambda tuple: tuple[0],reverse=True)
250
251 # We've sorted the list by descending priority, so the first entry
should
252 # be the "main" release in use on the system
253
254 max_priority = releases[0][0]
255 releases = [x for x in releases if x[0] == max_priority]
256 releases.sort(key=release_index)
257
258 return releases[0][1]
I am afraid that this info, you already know..
I am not a python guy( I love the Lua simplicity way :) ), I can't help.. :(
Best Regards,
tux
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII point release
Hello fsmithred,
On Fri, 25 Oct 2019 18:06:06 -0400
fsmithred via Dng wrote:
>
> I don't know exactly where the 2.0 is coming from. It's not in
> /etc/os-release, /etc/devuan_version or /etc/issue, and there is no
> /etc/lsb-release file.
>
> man lsb_release says
>"Detection of systems using a mix of packages from various
> distributions or releases is something of a black art; the current
> heuristic tends to assume that the installation is of the earliest
> distribution which is still being used by apt but that heuristic is
> subject to error."
>
> It can't hurt to file a bug report. If you know how to fix it, let us know
> and we can correct that in the future.
>
> fsmithred
That information come from python2.7 'lsb_release' module..
root@desktop0:~# python2.7
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lsb_release
>>> distinfo = lsb_release.get_distro_information()
>>> print(distinfo.get('RELEASE', 'n/a'))
2.0
I will try to trace it, to its origin..
Best Regards,
tux
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to investigate constant outgoing ARP traffic - TX: ~7K/s
Hi mett, > > Hi, > > if this is really outgoing arp request, > maybe ur default route is not properly > configured. > Like u have no next-hop address, > only an outgoing interface as a default > route: > > ip route default dev en0 > > instead of > > ip route default via 91.sm.th.ing dev en0 > > In that case, ur host think every hosts is attached to it, and therefore arp > for each > host. > > I said if bc what u showed didn t seem > coming from ur host. > > Can u verify that all the arp requests > are from ur host? > ie. the outgoing interface, en0 if i > understood properly > (the interface with a public ip address). > > hth Exactly, it could be indeed a routing problem, since he own 2 networks, he need to route the dns trafic via public interface 'en0'.. But the thing is, he will need 2 default gateways.. one for the public network '91.65.138.0/??'( what you designated as default gateway.. ), And 1 for the internal private network '192.168.19.0/24'( delivering dhcp, and the dns cache queries, he cache on that machine.. ) He can acomplish that in debian, You need to do it using 'policy routing'( redhat permited to bound a routing table directly to a interface.. I think I already saw that in debian too, but its not the same thing.. do this solution isa bit more dificult.. ) For that, see 'https://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System' or 'https://unix.stackexchange.com/questions/35713/adding-two-default-gateways-in-debian-interfaces-file/35822' You should see after creating a new routing table, and assign routing rules, that you have 2 default gateways, one for public trafic and one for private.. But...IF he doesn't own, or contact that machine( 'ip5b418c91.dynamic.kabel-deutschland.de - 91.65.140.145' ), why is it trying to know its mac address?? It could even be that the master dns server is down, or unreachable and he needs to contact the slave server.. don'ty know But, I think that this was is first question.. Best Regards -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to investigate constant outgoing ARP traffic - TX: ~7K/s
Hi Stefan, > > first of all, your machine seems to be the dns server, or you have > > static ips assigned? > > Yes, unbound DNS resolver is running on this machine. No static IPs. > You have a public dynamic IP, I assume. So you are in the domain: 'dynamic.kabel-deutschland.de' but by what I see, that domain is a /24 or not?? you: FQDN: ip5b418cfe.dynamic.kabel-deutschland.de IP: 91.65.138.120/24 Someone else: FQDN: ip5b418c91.dynamic.kabel-deutschland.de IP: 91.65.140.145 /24?? something strange, you have 2 diferent *public* networks in the same domain? Another things.. Are you trying to have 2 machines conected with a foreign dynamic dns service, ex: like 'https://www.noip.com/free' ? > $ sudo tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on net0, link-type EN10MB (Ethernet), capture size 262144 > bytes > 09:25:00.272473 ARP, Request who-has > ip5b418c91.dynamic.kabel-deutschland.de tell > ip5b418cfe.dynamic.kabel-deutschland.de, length 46 > who is 'ip5b418c91.dynamic.kabel-deutschland.de' ?? its other machine of yours? do a : arping 91.65.140.145 check the mac address, compare with any one of yours.. > $ nslookup ip5b418c91.dynamic.kabel-deutschland.de > Address: 91.65.140.145 its a diferent network than yours but they have exactly the same domain..weird ?? what is the dns server that responds to that request? should be: '83.169.184.33' > AIUI I have a ARP cache with one entry for the standard gateway of my > ISP. See my original post. Is this normal or should there be more > entries? > any ip address of your network should be there( 192.168.19.2,192.168.19.3 ?? ), but if none contacted then its ok.. > Are you saying running a local DNS resolver daemon like unbound is a > security risk? And that the seemingly increased ARP traffic could be > a symptom of this machine being hacked? > No, I don't even know what is 'unbound'.. But if you are using a external service, depending of the type of external dynamic dns services, yes, I already was some 15 years ago, using 'https://www.noip.com/free', I already saw tons of cases like mine, out there( they don't offer you a dynamic dns service for free... free for them, means your information is selled in the black market...they need to make money.. no one offers free services.. ).. But doesn't mean you are the case here..( I don't even know what is the domain 'dynamic.kabel-deutschland.de'.. ) Your machine is acting as a DNS cache server for the network 192.168.19.0/24, for what it seems.. -- Best Regards, tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to investigate constant outgoing ARP traffic - TX: ~7K/s
Hi Stefan,
> Yes, good guess! Tcpdump show lots of these messages:
>
> 16:47:40.633536 ARP, Request who-has ip5b418d68.dynamic.kabel-deutschland.de
> tell ip5b418dfe.dynamic.kabel-deutschland.de, length 46
> 16:47:40.821784 ARP, Request who-has ip5b418b24.dynamic.kabel-deutschland.de
> tell ip5b418bfe.dynamic.kabel-deutschland.de, length 46
> 16:47:41.006438 ARP, Request who-has ip5b418a98.dynamic.kabel-deutschland.de
> tell ip5b418afe.dynamic.kabel-deutschland.de, length 46
>
> But what does that mean? The addresses asked for all seem to
> be from the pool of the IP addresses/domains which this ISP
> gives out.
>
> $ nslookup ip5b418d68.dynamic.kabel-deutschland.de
> Server: 127.0.0.1
> Address:127.0.0.1#53
>
> Non-authoritative answer:
> Name: ip5b418d68.dynamic.kabel-deutschland.de
> Address: 91.65.141.104
>
> $ nslookup ip5b418b24.dynamic.kabel-deutschland.de
> Server: 127.0.0.1
> Address:127.0.0.1#53
>
> Non-authoritative answer:
> Name: ip5b418b24.dynamic.kabel-deutschland.de
> Address: 91.65.139.36
>
> $ nslookup ip5b418a98.dynamic.kabel-deutschland.de
> Server: 127.0.0.1
> Address:127.0.0.1#53
>
> Non-authoritative answer:
> Name: ip5b418a98.dynamic.kabel-deutschland.de
> Address: 91.65.138.152
>
> $ whois 91.65.141.104 # output cut
> […]
> inetnum:91.65.0.0 - 91.65.255.255
> netname:KABEL-DEUTSCHLAND-CUSTOMER-SERVICES-14
> […]
>
> Why would my machine send these requests?
>
first of all, your machine seems to be the dns server, or you have static ips
assigned?
# cat /etc/{hosts,resolv.conf,nsswitch.conf,network/interfaces}
# ifconfig -a
Then, find the processes that are running with open sockets..
Check which ones are running, and verify why..
# lsof -nP -i4tcp@{91.65.141.104,91.65.139.36,91.65.138.152}
If that is a desktop machine, you should have a dns server somewere in the
network..
It could be that you have no arp cache, and it his requesting everytime..
Having dynamic dns services also doesn't help much to your security, since they
are one of the major risks braking into computers..
And you seems to have configured some dynamic dns services..
Which it helps,
Best Regards,
Tux
--
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New Tilda documentation
Hi Steve, On Sun, 18 Aug 2019 01:20:53 -0400 Steve Litt wrote: > > > What I still miss in tilda is a session manager, do > > administrate remove servers, without been all the time typing.. > I was talking about, Administering Remote Servers, based in a Session Manager( with all of your park described in it.. ). Imagine that you have at your responsabilities Thousands of Servers.. And when you want to enter them by SSH( or any other way, but specially ssh, with x11-Forwarding if needed.. ), So, if that would be posible, imagine with a mouse click, in a tree, chose the server you want by name and them, double-click it, and it only asks for your Password.. You don't have to type all command to ssh, IP's and so on( Because they are distributed in hundreds of diferents networks..and such ). I think I still missed to describe you what would make Tilda a real top-notch Conection Manager.. Here are some applications, that have at some extent that capability, but fail in a lot of other things: - https://sites.google.com/site/davidtv/ - http://kuthulu.com/gcm/screenshots.html - https://remmina.org - https://mobaxterm.mobatek.net - https://www.nomachine.com Best of all of them: - https://www.vandyke.com/products/securecrt/index.html 2nd Best, but no X11-Forwarding :( - https://remmina.org Regards, -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New Tilda documentation
Hi all, Thanks steve for the Documentation.. I use tilda for some large years, and the last versions, are very nice.. What I still miss in tilda is a session manager, do administrate remove servers, without been all the time typing.. > Hi all, > > I know of three dropdown terminals: Guake, Tilda and Deepin Terminal. > Guake is getting more wedded to Gnome3 every day, so I decided to try > Tilda. It's very nice. > > Like most FOSS, it's underdocumented, so I wrote the following > documentation for it: > > http://troubleshooters.com/linux/tilda.htm Best Regards, -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New Tilda documentation
Hello, thanks for another option :) On Sat, 17 Aug 2019 20:24:28 +0200 Florian Zieboll wrote: > > > There is also yeahconsole, a wrapper for xterm/rxvt: No falderal, only a > dozen specific configuration items (xresources), tiny footprint (installed > size 35,8kB). > Does anybody knows a better way, to get xterm to use the standard X11 clipboard selection( for copy and past, intead of cut buffers.. ) I know that running it like : xterm -xrm 'XTerm*selectToClipboard: true' or echo 'XTerm*selectToClipboard: true' >> ~/.Xresources && xrdb -merge ~/.Xresources, then restart xterm.. it will use the standard X11 clipboard selection, intead of the cut buffers.. But could exist out there a better solution for it( forgetting the mouse scroll key.. :) )? Thanks in Advance, Regards -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The real nessecity to have a Independent Distribution - PRIVACY
Hello, thanks for sharing, On Sat, 10 Aug 2019 17:58:27 -0500 goli...@devuan.org wrote: > On 2019-08-10 17:19, s@po wrote: > > Hello to all Galaxy Devuaners out there, > > > > Found an article, I want to share with you( If you don't mind.. ). > > I think every single Person should read it.. to understand the > > importance of Privacy. > > It has some years,( which by that means that in today reality the case > > is a lot worse.. ). > > > > The Context: Privacy - Why is so urgently important to maintain a > > distribution, outside, of what I Consider "Criminal Activities"( Lack > > of Privacy ), > >Or by Other terms, away from "dark > > contractors", and so on.. > > > > Here is the URL: > > http://techrights.org/2014/01/17/rhel-security/ > > > > > > The problem we are facing is MUCH bigger than that. This eye-opener > from Eben Moglen: > > https://19.re-publica.com/en/session/why-freedom-thought-requires-attention > > For those of you who don't recognize this name: > > https://en.wikipedia.org/wiki/Eben_Moglen > > golinux A very good, and also true refrection session, great work from Eben! Regards, -- Let the force be with you tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] The real nessecity to have a Independent Distribution - PRIVACY
Hello to all Galaxy Devuaners out there, Found an article, I want to share with you( If you don't mind.. ). I think every single Person should read it.. to understand the importance of Privacy. It has some years,( which by that means that in today reality the case is a lot worse.. ). The Context: Privacy - Why is so urgently important to maintain a distribution, outside, of what I Consider "Criminal Activities"( Lack of Privacy ), Or by Other terms, away from "dark contractors", and so on.. Here is the URL: http://techrights.org/2014/01/17/rhel-security/ -- Which you all the best. Stay Safe and Strong tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] EmbDevuan - Cross-Building ..
Hello all, I am trying my Embedded Cross-Building System( for quite some time now.. ) After 3 rewrites I understand now, why buildroot seems so complex to me.. :D But this email is about Devuan package Building.. Is there any simple way to package: . linux-image, . linux-headers, . linux-firmware I noticed that: . linux-image- Contains the Linux Kernel Image + Kernel Modules . linux-headers - Contains only the header files, why are them in /usr/src( I saw a package data.tar.xz ), shouldn't them be in /usr/include ? . linux-firmware - Maybe I will use it for, the graphics drivers blobs + /boot/vendor_name/device-tree-binarie files? In this way I will end with several Linux Firmware packages: . linux-firmware-allwinner.. . linux-firmware-rockchip . linux-firmware-nxp . linux-firmware-nexel . and so on.. I noticed here that exists some were a 'dev1h' or 'dev1helper', something like that, maybe here in the mailing list.. But I can't find it, or an example.. I would be gratefull to hear from you, any precedures for building some packages, majority will be: Kernel + Modules Header files, so that any one can develop a Kernel driver, as an example.. Nota: The lack on sbc boards of recent kernels, lack of kernel header files( some have adapted android kernels, and so on..), made me feel the need to develop a building system, to solve that problem..or at least try.. Thanks in Advance, for your time. Best Regards, -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
Hello, I think you own a RaspberryPi 1st version( or a derivative.. ).. The 'bcm2835' could be found in: . Raspberry Pi Model A, . Raspberry Pi Model B, B+ . The Compute Module . Raspberry Pi Zero At least the frequency Scheduler reports a fixed value of 700Mhz, Your BogoMIPS report is also inline with 'bcm2835'( Single core, 32bit ARMv11@700Mhz ).. I think you should try with: https://mirror.leaseweb.com/devuan/devuan_ascii/embedded/devuan_ascii_2.0.0_armel_raspi1.img.xz If you had already tried, The best Option, would be to try to fix sdcard frequency to start with a fix *Default* speed and then try to Boot-Up.. This value bellow is the default( its what I have in my Board since the beguining... I am an Early Owner :) ) In /boot/config.txt # First try with initial emmc clock of 50Mhz... ( should be the default .. but still, try to force it..you could have a diferent sdcard.. ) init_emmc_clock (5000) After that, if can't boot, please give us some bootup data like previously :) Good Luck, Regards -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
Hello Again.. " [0.912573] sdhost-bcm2835 20202000.mmc: could not get clk, deferring probe " Does you have any problems with your sdcard? Shutdown and clean the contacts, then insert it again boot, and wait some time, to check if it will resize disk partition to mazx size.. Or if mmc clock is lower, it will take a lot more time to load.. > Hello, > Were is your > > > Hi, > > I'm trying to boot a Raspberry PI B+ on devuan_ascii_2.0.0_armhf_raspi2.img > > > > I'm getting a boot loop with this output: https://pastebin.com/ALTzdJxW > > Any thoughts? > > > > Should I be using the raspi1 image instead? > > What is your RaspberryPi version? > > In the logs I see: > " > [2.014566] Waiting for root device /dev/mmcblk0p2... > " > > Does you waited enough time? > I don' know that image, > But some do a resize of /dev/mmcblk0p2( and that could take some time.. ) > > -- > s@po -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
Hello, Were is your > Hi, > I'm trying to boot a Raspberry PI B+ on devuan_ascii_2.0.0_armhf_raspi2.img > > I'm getting a boot loop with this output: https://pastebin.com/ALTzdJxW > Any thoughts? > > Should I be using the raspi1 image instead? What is your RaspberryPi version? In the logs I see: " [2.014566] Waiting for root device /dev/mmcblk0p2... " Does you waited enough time? I don' know that image, But some do a resize of /dev/mmcblk0p2( and that could take some time.. ) -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
On Thu, 13 Jun 2019 08:31:48 +0200 aitor wrote: > En 13 de junio de 2019 7:45:48 Didier Kryn escribió: > > > Le 12/06/2019 à 19:12, s@po a écrit : > >> First of all, I think that this subject derailed to a diferent subject. > >> > >> > >> > >> > >> I Apologise for give my opinion on a concrete subject, because, I never > >> felt it would turn out "to be almost personal.." > > > > Never saw anything personal here and the discussion triggered a > > usefull clarification, beyond the style question :~) > > > > Didier > > > > Yes..., technical discussions are funny :) > > > > Aitor. Ups, Seems that I missunderstood it.. My Apologies for that( ... tux is hiden now, under a BIG Rock.. ).. :) -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
Hello guys, First of all, I think that this subject derailed to a diferent subject. I Apologise for give my opinion on a concrete subject, because, I never felt it would turn out "to be almost personal.." My Opinion is based on the Idea that we should not create extra complications, When we are ourselfs, defining a fixed size of something kown has a multiple of the minimum size alocable in memory.. In the Case, **only focusing only in the case**.. We had a Array used has a buffer with 512 bytes of fixed size.. So it was a pointer for something multiple of minimum size that could be alocated.. So in this situation sizeof or sizeof '*array', by the way( since sizeof is **not** a function but a unary operator.. ), Doesn't make any sense at all .. Why should we be calculating the size of a buffer, if we ourselfs dictated the fixed size and its a multiple of 'char' type, and also a multiple of 2^n?? Why are we calculating its size in all aplication were it is used, at compile time? You can simply use a MACRO instead.. # define BUFFER_SIZE 512 In the pré-conpilation process, Macro will be substituted in text, And no need to calculate nothing in the code, anny way a lot of pre-processing will occur, wether you want or not.. This was the motiff why I gave my sincere opinion, and nothing more than that, only to try to help @aitor.. Off course, if you have to allocate memory for structs/unions, things could be dynamic a bit.. or at least they were in the past.. To be honest, I don't recall if sizeof '*truct', does padding, or if it suppress bytes by itself right now( I do it by myself in the struct section declaration, since I don't allow the compiler to take "his opinions" has mines.., ... I am the one doing the code.. ), But that is another thing, and not related with the code in cause.. Like @Didier noticed before, In **this concrete case**, it has more to do with Code Style, than anything else!! The code Generated will be similar, But with a Macro seems to me, to be better.. Like I said, you don't be all the time in the code, asking compiler to find the size of something that you, **yourself**, created with fixed size, and a multiple of 2^n bytes, ... you know the size... for sure!! That been Said, I only gave my honest/sincere opinion about the 'sizeof' vs 'Macro', for the **concrete** situation( I don't even read all code..only took a shot at it.. ). I apologize to all of you, ... for the buzz, I afterall, created around this.. Best Regards, -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Mon, 10 Jun 2019 17:58:35 +0200
Didier Kryn wrote:
> Le 10/06/2019 à 16:01, s@po a écrit :
> > On Mon, 10 Jun 2019 13:34:54 +0100 (BST)
> > Jim Jackson wrote:
> >
> >> sizeof() is calculated by the compiler, not at run time. The code
> >> generated would be the same.
> > Hello Jim,
> > Indeed it his, my point was only a observation, that if size is fixed, no
> > need to calculate it at compile time, the preprocessor can solve that with
> > a macro..
> > The code generated will be indeed the same.
> > Only was a observation ;)
> >
> \begin{pedantic}
> The size used by the layout of the data (sizeof()) has not the same
> meaning as the number of elements. AFAIK, the C language does not
> specify (at least not completely) the data layout and leaves it to the
> implementation.
> All modern hardware lay out data as bit octets and compilers use
> one octet of bits to represent an ASCII character (note 7 would suffice
> for ASCII). All compilers layout strings in contiguous successive octets.
> Therefore there is little chance that the confusion between size
> and number of elements be harmfull. Yet there is a subtle difference :~)
> \end{pedantic}
>
Indeed,
One harmfull situation is when you pass an array[n] to a function has an
argument, for example..
Usign 'sizeof' inside, will return the size of the pointer and not the size of
elements on the array..
unsigned char funtion test( unsigned char *array ){
/* This will not return the size of array,
but instead, the size of the Pointer..,
because at compile time, compiler doesn't know what size array[n] will
have */
return sizeof( array )
}
Regards,
--
tux
s@po
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Mon, 10 Jun 2019 13:34:54 +0100 (BST) Jim Jackson wrote: > > sizeof() is calculated by the compiler, not at run time. The code > generated would be the same. Hello Jim, Indeed it his, my point was only a observation, that if size is fixed, no need to calculate it at compile time, the preprocessor can solve that with a macro.. The code generated will be indeed the same. Only was a observation ;) Best Regards, -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Sat, 1 Jun 2019 08:31:49 + aitor_czr wrote: Hello aitor, > > Look at the "netstat.c" file again. I'm using > > status = fgets ( buffer, sizeof(buffer), fp ); > > instead :) > > Aitor. > > I understood that, from the beguining.. :) You don't need the 'sizeof *buffer', since you have a fixed array size of 512 bytes.. And a byte, is a byte in 32 bits or 64 bits systems ;) Becasue of that, I suggested changing it to: #define BUFFER_SIZE 512 and then: status = fgets ( buffer, BUFFER_SIZE, fp ); It was only a sugestion ;) Its not wrong, to use it( even tough you are heavilly relying on that unary operator.. for a fixed array size, of n bytes.. ) Best Regards -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ocornut/imgui] Release v1.70 - v1.70
Hello, First of All, Thankyou for the great work you whave been done, on the 'dear imgui' Graphical Toolkit. Its an example of Beauty and Simplicity combined, with very few dependencies..lean! On Mon, 06 May 2019 06:04:49 -0700 omar wrote: > Hello! > > In spite of the greaaat looking version number, this is a general release > following 1.69, keeping with the rythm of having more frequent, smaller > releases. Reading the full changelog is a good way to keep up to date with > the things dear imgui has to offer, and maybe will give you ideas of features > that you've been ignoring until now! > > > > See https://github.com/ocornut/imgui for the project homepage. > See https://github.com/ocornut/imgui/releases for earlier release notes. > See https://github.com/ocornut/imgui/wiki for language/framework bindings, > links, 3rd parties helpers/extensions. > Issues and support: https://github.com/ocornut/imgui/issues > Technical support for _new users_: https://discourse.dearimgui.org (also > search in GitHub Issues) > I'm keeping an eye on it, for several months now.. :) Mabe I will use it for the Graphical Environment of a project, related with porting Devuan to ARM/MIPS32r5 SBCs .. Its yet in an early stage but when stable, and I found time for it, I will for sure consider this magnificient Toolkit!! ThankYou for your work, very nice project! -- Tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Sun, 19 May 2019 11:38:52 +0200 Hello aitor, aitor_czr wrote: > Have a look at the server side: > > https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/server.c char buffer[512]; (...) You are using in some places 'sizeof(buffer)' in 'fgets()' and such.. Your buffer has a fixed size.. /* Somewere else, probably in the header file..*/ #define BUFFER_SIZE 512; (...) char buffer[ BUFFER_SIZE ]; (...) status = fgets ( buffer, BUFFER_SIZE, fp ); its my 2 cents :) Regards, -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [RFC] User services
Hello All, On Sat, 11 May 2019 11:26:12 +0200 Martin Steigerwald wrote: > Hi. > > Now that the proof of concept is out, I am thinking about extending it a > little bit. > > - make is a package > - make "install-or-update.sh" into "/usr/bin/userservices" with the > following actions: > - install: Sets up userservices for the user > - update: Updates it > - remove: Removes i > - make "userservice" alias into "/usr/bin/userservice" > - that way the user would not have to setup an alias anymore. > > So with these changes using user services would be like: > > As root: > > apt install user-services > > As user: > > userservices install > > userservice enable redshift > > [x] done :) > > > If user-services packaged gets updated, the user can decide to update > her installation with: > > userservices update > > Ideally it would take into account when the user changed some services. > > > What do you think about that? > > It would be some work, but I for me this sounds like a good idea. > > > In anyway: This is still in proof of concept stage, so I may change > everything :). If you are using this, you are brave alpha tester :) > In the past Debian Wheezy had a tool for that, called 'chkconfig', it was a lot used in the Datacenter.. # Adding a Service 'atsd': chkconfig --add atsd; # Enable the service in several Runlevels: chkconfig --level 12345 atss on; # Start the Service: /etc/init.d/atsd start; # Stop the Service: /etc/init.d/atsd stop; # Disable the service in requested runlevels: chkconfig --level 12345 atsd off; # Remove the Service: chkconfig --del atsd; And other funcionalities, like listing the services and so on.. It was a very helpfull tool. In the absence of it( I don't know why it was removed .. ), your tool seems to come to replace it, BUT for users only? :) I think it would be nice to call it like 'uservice', instead of 'u[ser]service[s]', which is a lot bigger name, or a alias called 'uservice', since 'service' is also another tool, to deal with.. services. This are my thoughts, but I like the idea.. :) Best Regards, tux -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Systemd Shims
It seems to me that it's good to have shim programs that satisfy dependencies of apps on systemd, each shim performing some systemd function. Here's why: Suppose there are 10,000 application programs (apps) for Linux, and their developers foolishly insert dependencies on systemd. If Devuan developers write 50 simple shims to fulfill those dependencies, then Devuan users can run those 10,000 apps as they are, directly from the Debian repos. And when the apps are updated, they will still run. The Devuan devs don't have to deal with those 10,000 updates at all. And the shim programs only have to be updated when the systemd API that they are emulating changes. Now suppose that systemd shims are not used. That means that all 10,000 apps have to be patched by Devuan developers so they don't depend on systemd. And all the 10,000 patched apps have to sit in a Devuan repo that has to be maintained. And every time one of those 10,000 apps is updated, the Devuan devs have to repatch it to remove the systemd dependencies and recompile it. The Devuan devs can request the app devs to remove the systemd dependencies, but that has a low probability of success, because the app devs have lemming-consciousness rather than Unix-consciousness, and think that systemd is fine because the major distros have adopted it. So using a relatively small number of shim programs in Devuan will save an enormous amount of work for the Devuan developers, which will allow them to use their time for more productive purposes -- making Devuan more generally useful and attractive, thereby gaining far more users. Now I realize that the idea of having those shim programs is going to make some Devuan people scream, Unclean! Unclean!. But the shim programs will be under our control and will save us a huge amount of constantly ongoing work of updating apps. And Devuan will succeed with only 25 developers and administrators instead of needing 500. So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
