Re: [DNG] KVM + QEMU on Devuan 1.0
Svante Signell writes: > On Fri, 2017-07-28 at 12:06 +0200, alberto.se...@tin.it wrote: >> Hello, >> >> everyone has tried installing and using kvm + qmeu on Devuan 1.0 ? > > Yes, several instances. No problem :) > > Download: > wget https://files.devuan.org/devuan_jessie/installer-iso/devuan_jessie > _1.0.0_amd64_NETINST.iso You may also be interested in the ready-to-use VMs. See https://devuan.org/os/documentation/install#virtual-machines There's a qcow2 image that, according to the README.txt, should be usable with QEMU. See: https://files.devuan.org/devuan_jessie/virtual/ I'm looking at using this on Devuan to play around with d1h when I get the time. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] VBScript Injection via GNOME Thumbnailer
Hi, Adam Borowski writes: > On Wed, Jul 19, 2017 at 08:28:25PM +0900, Olaf Meeuwissen wrote: >> Adam Borowski writes: >> > On Tue, Jul 18, 2017 at 10:07:35PM +0200, Adam Borowski wrote: >> >> Actually, imagemagick is one of worst offenders here. The version in >> >> Jessie >> >> is at deb8u9, and every security update tends to mention ~20 CVEs. >> > >> > ... nd, just hours later, here comes deb8u10: >> > >> > # Package: imagemagick >> > # CVE ID : CVE-2017-9439 CVE-2017-9440 CVE-2017-9500 CVE-2017-9501 >> > # CVE-2017-10928 CVE-2017-11141 CVE-2017-11170 >> > # CVE-2017-11360 CVE-2017-11188 >> > # Debian Bug : 863126 867367 867778 867721 864273 864274 867806 868264 >> > # 868184 867810 867808 867811 867812 867896 867798 867821 >> > # 867824 867825 867826 867893 867823 867894 867897 >> >> Totally untested, but you might try to replace imagemagick with >> graphicsmagick. It's at deb8u ;-) My bad, graphicsmagick is at deb8u2. Are the security conscious just picking on imagemagick or graphicsmagick is less susceptible? Dunno. > It's a fork, so it suffers from same vulnerabilities as imagemagick. It > might get better only after someone rewrites everything from scratch (in > which case there'll be a whole new set of bugs). Devuan is a fork of Debian. I think we both agree that the former suffers at least one problem less than the latter ;-) By the same or at least a very similar token, I would hope that perhaps graphicsmagick suffers from a few less vulnerabilities than imagemagick. True, I have no hard data to back that up. It was just a suggestion. I've used the CLI and library C/C++ APIs of both in the past, and through that have developed a better opinion of graphicsmagick. It was forked 15(!) years ago. ImageMagick has had a reputation of willy-nilly changing CLI and library APIs as well as image processing results between versions. GraphicsMagick has on the whole been a lot more stable in that respect so I would *guess* that its developers have been able to shake out most vulnerabilities over the years without introducing many new ones. Just a thought, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] VBScript Injection via GNOME Thumbnailer
Hi, Adam Borowski writes: > On Tue, Jul 18, 2017 at 10:07:35PM +0200, Adam Borowski wrote: >> Actually, imagemagick is one of worst offenders here. The version in Jessie >> is at deb8u9, and every security update tends to mention ~20 CVEs. > > ... nd, just hours later, here comes deb8u10: > > # Package: imagemagick > # CVE ID : CVE-2017-9439 CVE-2017-9440 CVE-2017-9500 CVE-2017-9501 > # CVE-2017-10928 CVE-2017-11141 CVE-2017-11170 > # CVE-2017-11360 CVE-2017-11188 > # Debian Bug : 863126 867367 867778 867721 864273 864274 867806 868264 > # 868184 867810 867808 867811 867812 867896 867798 867821 > # 867824 867825 867826 867893 867823 867894 867897 Totally untested, but you might try to replace imagemagick with graphicsmagick. It's at deb8u ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Hi, Evilham writes: > Hi there, > > Am 03/07/2017 um 16:08 schrieb dev: >> Sounds like a "won't fix", too: >> >> "So, yeah, I don't think there's anything to fix in systemd here." >>- Poettering >> >> Not sure what's more troubling here[1]; the lack of concern, the >> digression from POSIX, or the bug/backdoor itself. Maybe all three. >> >> useradd 0day works on Devuan. adduser 0day does not. Which is correct? > > I had this discussion yesterday, so here are my 2 cents :-). > > It is quite inconsistent what a "valid username" is, apparently it has > gotten better. Indeed and that's exactly why systemd shouldn't assume it's living in a Happy World of overly optimistic assumptions. > According to POSIX, a valid username may include: a-z, A-Z, 0-9, ., -, _ > Where "-" cannot appear at the beginning. There is no further > restriction on the other chars. > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_435 So if systemd were to adhere to POSIX (now I'm being overly optimistic, probably), systemd should check the user names in unit files for POSIX conformance and flatly refuse to do anything if they're not. If systemd were to just take any user name, then it should *still* check that whatever user name it gets actuall corresponds to an existing user (and that that user is a system user to boot) before going ahead and doing anything. Of course, all this checking negatively affect boot times so systemd simply assumes all's well ;-P > So, useradd works because it's lower level, adduser does not, because it > comes from shadow and they have more restrictions on what a valid name > is. IMHO that's a bug in shadow. > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c#L52 On an even lower level, any text editor + shell combination will let you add accounts with whatever whacky user name you can think of. As far as /etc/passwd (and /etc/shadow) are concerned, the ':' is just about the only character you cannot use file format wise. Whether login (or your display manager) will let you login with that is another matter but for systemd unit files the capability to login is not required. # UTF-8 user names anyone? ;-) > It is not possible, for example to execute: adduser name.lastname, which > is a valid POSIX username (but useradd name.lastname works fine). > > The biggest issue with that systemd bug is that it should refuse to run > the unit instead of overriding what the sysadmin wrote and running as root. The security conscious call that privilege escalation. Anyone capable of putting such a unit file on your system(d) will own your box as soon as the service runs. > But hey, that's why we are here on Devuan. Indeed. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Hi, Adam Borowski writes: > On Tue, Jul 04, 2017 at 08:14:40PM +0900, Olaf Meeuwissen wrote: >> Evilham writes: >> > Hi there, >> > >> > Am 03/07/2017 um 16:08 schrieb dev: >> >> "So, yeah, I don't think there's anything to fix in systemd here." >> >>- Poettering >> >> >> >> Not sure what's more troubling here[1]; the lack of concern, the >> >> digression from POSIX, or the bug/backdoor itself. Maybe all three. >> >> Indeed and that's exactly why systemd shouldn't assume it's living in a >> Happy World of overly optimistic assumptions. >> >> > According to POSIX, a valid username may include: a-z, A-Z, 0-9, ., -, _ >> > Where "-" cannot appear at the beginning. There is no further >> > restriction on the other chars. >> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_435 >> >> So if systemd were to adhere to POSIX (now I'm being overly optimistic, >> probably), systemd should check the user names in unit files for POSIX >> conformance and flatly refuse to do anything if they're not. > > POSIX requires any system to accept _at_least_ this set of usernames. > You are free to accept anything else. UTF-8 letters come to mind. I mentioned that in my post as well. Here's wondering whether Shift-JIS (unfortunately still prevalent in my neck of the woods) would fly. > [~]# useradd блядь > -- works ok. > > [~]# adduser блядь > adduser: To avoid problems, the username should consist only of > letters, digits, underscores, periods, at signs and dashes, and not start with > a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba > machine accounts $ is also supported at the end of the username > > -- it adds @ anywhere and $ at the end. > >> If systemd were to just take any user name, then it should *still* check >> that whatever user name it gets actuall corresponds to an existing user >> (and that that user is a system user to boot) before going ahead and >> doing anything. > > Why would running services be restricted to system users only? I added that parenthetical because I thought Lennart mentioned something about that in the GitHub issue. Thing is, if something is only supposed to be run by a system user, systemd needs to make sure of that. No idea whether systemd services run by non-system users makes sense but then again, lots of systemd probably doesn't make much sense. >> Of course, all this checking negatively affect boot times so systemd >> simply assumes all's well ;-P > > The fun thing is, sysvinit tends to win in boot times for quite a margin. Uhm, that was meant sarcastically. But you got that, right? >> > So, useradd works because it's lower level, adduser does not, because it >> > comes from shadow and they have more restrictions on what a valid name >> > is. IMHO that's a bug in shadow. >> > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c#L52 >> >> On an even lower level, any text editor + shell combination will let you >> add accounts with whatever whacky user name you can think of. As far as >> /etc/passwd (and /etc/shadow) are concerned, the ':' is just about the >> only character you cannot use file format wise. Whether login (or your >> display manager) will let you login with that is another matter but for >> systemd unit files the capability to login is not required. > > Well, and '\n'. But allowing '\n' in usernames would be about as bad an > idea as allowing them in file names. And no one would be insane enough to > do the latter, right? Right? I wouldn't, not on purpose at least ;-) It has happened to me courtesy of a bug in a script I wrote though. > Another consideration is compatibility with AD+Samba. I'd find it > repugnant to let a Windows machine provide security, but it's a quite > widespread setup, which also allows usernames to start with a digit. > > A more -- heck, most -- important concern is that my usual secondary > username is "1kb". Try to ban me and I'll bite. :þ > >> > It is not possible, for example to execute: adduser name.lastname, which >> > is a valid POSIX username (but useradd name.lastname works fine). > > Banning a naming scheme this widespread means someone needs to get his head > checked. +1, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd allows elevated access from unit files?
Hi Simon, Simon Hobson writes: > Olaf Meeuwissen <paddy-h...@member.fsf.org> wrote: > >> No idea whether systemd services run by non-system users makes sense but >> then again, lots of systemd probably doesn't make much sense. > > Do you mean "systemd service" as in "something that's part of > systemd"; or do you mean "something that's run by systemd" ? Assuming > the latter, doesn't lots of software run as non-system users - as a > basic part of good security practice ? You assumed correctly. Upon re-reading this myself, I agree I wasn't being very clear. Sorry. > I know some stuff (postfix, apache) starts as root and then drops > privileges for some/all of itself. Others just start as a > non-privileged user to start with (BIND) - is this actually done in > the script when using sysv, or does the daemon have to do it itself ? > I admit I only have a basic grasp of the details here. How this is done depends on the service. Some service actually need root privileges for a few things, e.g. binding to a port < 1024. The system users I was thinking of the ones created with adduser --system These aren't that different from "normal" users but typically have a UID in a certain range and are, by default, put in the nogroup. All these things *are* configurable btw and you can still force stuff (just open /etc/passwd et al. with your favourite text editor). So any kind of relying on certain "policies" being adhered to is winging it. > But thinking a bit more about the issue ... > Yes, this is a bug, and yes it shows the systemd people (especially > LP) up for the disdain they show for the basics of security, > good/defensive programming, etc. > But, sysv-init has much the same issue in that there's a shell script > run as root, I beg to differ. If you try to run a service as user '0day' from a sysv-init script, then you get the behaviour of implemented by - that service if it has provisions for running as a certain user - the wrapper that handles running something as a certain user, e.g. start-stop-daemon I don't know what that behaviour is but sure hope it won't decide to run as root if you try to run something with a "funny" name. > and if the user is able to manipulate that then he is able to do > things he shouldn't be able to. Playing devil's advocate, there's an > argument that the "complexity" of typical sysv scripts (at least as > shipped with distros like Debian) makes it a non-trivial task to spot > something slipped into the script. Perhaps the complexity came about as the result of trying to make one size fit all init systems or maybe over-engineering but, to be honest, I don't find the 65 /etc/init.d/* files (not counting README and skeleton) on my system to be too complex. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Full disk encryption (was Re: some ASCII issues)
Hi, Didier Kryn writes: > Le 28/06/2017 à 20:33, Rick Moen a écrit : >> Quoting Didier Kryn (k...@in2p3.fr): >> >>> I don't see any reason to encrypt /usr. You might like to >>> encrypt /etc because it contains user names and (already encrypted) >>> passwords. But definitely there is no reason to encrypt everything. >> /home would be where I keep anything that's sensitive. I'm unclear on >> why usernames in /etc are deemed sensitive, but I'm sure needs differ. >> >> Temporary files in /tmp are sometimes a little sensitive and sometimes >> greatly so. (It's usually a tmpfs on my systems.) Operational paranoia >> suggests keeping it at least cleaned up frequently, if you're going to >> bother to have /home as a dmcrypt filesystem. That's where tmpfs is >> actually helpful in the sense that erasure means a file from there is >> truly gone. > > Sure /home is the first place one thinks of encrypting and /tmp is > the second, together with possible other fancy dirs. The mail and print spool areas below /var/ spring to mind. Your log files might contain plain text password if users accidentally entered their password where they were supposed to enter their username. There are probably more "corner cases" we can think up. Considering that, encrypting the whole disk is just the most fool proof way to go about things. Made possible by libreboot, this "fool" has even /boot/ encrypted ;-) Hey, my hashed grub passwords are in there! > Encrypting passwd and the like would just add a little of > security-through-obscurity by even hiding the usernames; this is why I > considered /etc as a third (non-obvious) thing to encrypt; /etc also > contains every local configuration, and it might make sense to hide it > all. > > To simplify, all of /home and /tmp aren't really part of the OS. > The OS can boot without them. All the rest is the OS and is the same as > any other install of the same OS; and there isn't any reason to encrypt > something which is published and widespread. Hmm, /var/ is arguably not part of the rest of the OS. Ditto for /srv/, /opt/ and /usr/local/. But then again, who uses those. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A problem with a license
Hi, KatolaZ writes: > DR D1Rs, > > yesterday I was reviewing a new package made by Daniel Abrecht (DPA), > a little library that implements the sd_journal_* functions by > redirecting the calls to syslog. The project can be found here: > > https://git.devuan.org/DPA/sd_journal_shim > > This would allow to avoid to link against libsystemd0 if the program > wants just to use systemd logging facilities. > > I was about to move it under devuan-packages to build it for > experimental, but I noticed that the License (an almost regular > Expat/MIT license, for the rest) contained an additional clause: > > "This software shall not be used to encourage others to use the > systemd journal API, or any of it's sd_journal_* functions." > > so I immediately held my horses. My main complaint here is that this > clause makes the software non compliant with freedom 0 (the freedom to > use the software for whatever aim and task), so technically speaking > the package is not free-software, and cannot go in Devuan/main. Aside > from that, that clause makes the library GPL-incompatible, which would > undermine the good intentions of DPA. making the library practically > useless (unless the programs linking it are not GPL). As others have pointed out, send DPA a polite message pointing out that that clause makes it impossible for you to use his software in a distribution that created with the explicit aim to get rid of systemd. Politely ask if the license could be modified. You might find some people are actually sensible ;-) > In a word, I would not agree to include this package in Devuan/main, > unless that clause is removed. But just for the sake of clarity (and > because I think this can create a nasty precedent) I thought it was > good to ask here. If the clause remains, the library should stay out of Devuan/main no matter how badly you'd want to use it. Removing the offending clause or relicensing (dual licensing?) to a Free Software license is the only acceptable way to get this into Devuan/main. A MIT or BSD-3-clause license would probably be most widely compatible. > Please, please, please: let's avoid to tranform this in a flame. The > thing is that Devuan/main should include only free-software, and that > clause makes the package non-compliant with the basic freedom 0. We > would like suggestions as of whether the clause should be removed or > the package should go in Devuan/non-free (I can't see any other5B > alternative). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Scanner and sane-utils
Hi,
viverna writes:
> Hello folks,
> I'm a new Devuan user (from Debian) from few week.
> In Debian world I had a problem with my scanner, the script (run by
> user root) in /usr/local/bin/sanato solves the problem assigning group
> 'scanner' to device:
Your scanner should be assigned an appropriate group by the rules in
/lib/udev/rules.d/60-libsane.rules which run
/bin/setfacl -m g:scanner:rw $env{DEVNAME}
You can check whether this happened with the getfacl command.
What scanner are you using?
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] High level language primitives [ was Please keep 32-bits alive]
Hi, Didier Kryn writes: > In an ideal word, software would have > > - maximum performance > - minimum resource usage > - minimum of dangerous bugs In an ideal world, software would have *no* bugs ;-) > - easy maintainability > - fast development > - what else? Software would be Free as in freedom. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Scanner and sane-utils
Hi,
viverna writes:
> il devuanizzato Olaf Meeuwissen <paddy-h...@member.fsf.org> il 06/08/17 alle
> ore 03:06 ha scritto:
>> Hi,
>>
>> viverna writes:
>>
>> > Hello folks,
>> > I'm a new Devuan user (from Debian) from few week.
>> > In Debian world I had a problem with my scanner, the script (run by
>> > user root) in /usr/local/bin/sanato solves the problem assigning group
>> > 'scanner' to device:
>>
>> Your scanner should be assigned an appropriate group by the rules in
>> /lib/udev/rules.d/60-libsane.rules which run
>>
>> /bin/setfacl -m g:scanner:rw $env{DEVNAME}
>>
>> You can check whether this happened with the getfacl command.
>>
>> What scanner are you using?
>>
> Thanks,
> more correctly the scanner (Epson Stylus Office BX305F model 04b8 product
> 0863) is a multifunction printer (printer, scanner, fax) but i don't use
> the "printer" and "fax" part. Assigned group is "lp" and i want force in
> my system group "scanner" because xsane don't work if group is not
> "scanner".
>
> I solved with udev's rules:
> ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0863", GROUP="scanner"
This scanner was added in sane-backends-1.0.25. Devuan's jessie has
1.0.24.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] suggestion
Hi, Kees Schoenmakers writes: > When I installed Devuan first time on my (recently new) hardware, I > was initially left with some vague information provided by 'lspci'. > That hindered me by searching/selecting the right > drivers and X configuration. I discovered the 'update_pciids' utility > in /usr/sbin. > After running that everything got more clear for me. > > "RUN the 'update_pciids' utility as part of the installation process > on the target!" Ditto for update-usbids, modulo most of what has been mentioned in the rest of the thread up to this point. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to use golang-1.7?
Hi, Hendrik Boom writes: > On Fri, Aug 18, 2017 at 02:54:57PM +1000, Ozi Traveller wrote: >> I have it installed in windows at work. >> >> These might be useful to you. >> >> https://tecadmin.net/install-go-on-debian/ >> >> https://golang.org/dl/ >> >> ozi > > Yes, there are instructons for installation from source, and from > binaries, which I havven't tries yet. > > I had rather hoped to install from the regular Debian/Devuan packages > but it's starting to seem hopeless. Don't despair. It's not that I have looked at any golang packages but ... >> On Fri, Aug 18, 2017 at 10:46 AM, Hendrik Boom <hend...@topoi.pooq.com> >> wrote: >> >> > I installed golang-1.7 and could not find golang's main executable "go". >> > Did not know how to set the main envvironment variables "GOROOT" and >> > "GOPATH". ... have a look at the `dpkg -L golang-1.7` output. Especially anything that has /bin/ in it. That should give you a decent idea where the go binary is. Also, with versioned packages it is quite common to provide something like go-1.7 and symlink go with something suitable (or not as seems to be your case). Failing that, I'd head over to /usr/share/doc/golang-1.7/ for a more info like a README.Debian or README, whatever. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] sane-utils depends on libsystemd0
Hi, Just chiming in wearing my SANE project janitor hat. For the folks on sane-devel, Devuan is a Debian fork that is intent on getting completely rid of anything that smacks of systemd. Arnt Gulbrandsen writes: > Hendrik Boom writes: >> So... does sane need saned? Do the scanners have to initiate communication >> with the computer for which there always has to be a daemon running? > > That's not what sane does. Sane doesn't need saned to scan; I use devuan > and a scanner without even having saned installed. > > Saned is what you need if you want to connect a USB scanner to host A and > then run scanning software on host B. It makes A pretend to be a network > scanner that B can use, rather like how my scanner (a Brother MFC-8880) > offers its services to everyone on the net. That's the original use case scenario for which saned was developed but scanbd[1] now uses saned under the covers to enable device button push initiated actions. [1] https://sourceforge.net/projects/scanbd/ That said, saned does not require the systemd stuff. IIUC, the optional dependency only makes saned play nice in systemd setups. For Devuan there no need to play nice with something that isn't there, so passing --without-systemd to ./configure is perfectly fine and will skip any systemd checks. Not specifying the option will check for systemd but should disable the systemd support when not found. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Q] Devuan on HP Zbook Studio G3 Mobile Workstation
Hi Edward, Edward Bartolo writes: > Quoting Olaf Meeuwissen from preceding post: > "I didn't have to do any of the things mentioned in the forum post above." > > For the sake of clarity which disk format did you use: MBR or GPT? > That forum thread makes it clear that using GPT on that machine does > not work with legacy boot. GPT. The BIOS did have legacy support enabled but my USB stick with netinst ISO on it only showed up as an UEFI boot device. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Q] Devuan on HP Zbook Studio G3 Mobile Workstation
Hi, fsmithred writes: > On 05/19/2017 09:39 AM, Olaf Meeuwissen wrote: >> Hi all, >> >> Looking at the device mentioned in the subject for use at the office >> with Devuan. If anyone has any experience with this device, I'd like to >> know. Installation notes, brain dumps, everything welcome. > > If it has uefi, you may run into problems (and solution) like this: > https://dev1galaxy.org/viewtopic.php?id=15 It's a different HP, but thanks for the pointer. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [Q] Devuan on HP Zbook Studio G3 Mobile Workstation
Hi all, Looking at the device mentioned in the subject for use at the office with Devuan. If anyone has any experience with this device, I'd like to know. Installation notes, brain dumps, everything welcome. I've done some homework already and found notes on the ArchLinux wiki as well as elsewhere that seem to suggest installing any Linux is somewhat of an uphill battle. Some hardware may only be partially supported and getting external monitors to work might be non-trivial. I gather that a kernel version >= 4.5 is needed, so that would imply jessie-backports (has 4.9.0) which is fine with me. If need be, running with ascii would be acceptable (I've been using stretch for ages :-). Thanks in advance for any information you can provide, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] trash
Hi, Florian Zieboll writes: > On Sun, 28 May 2017 09:17:05 -0400 > Hendrik Boom <hend...@topoi.pooq.com> wrote: > >> The only one I have an idea what it's for is sane-utils. Presumably >> access to scanners. > > As mentioned on this list some days ago, sane-utils is not necessary to > run a local scanner. It provides saned to remotely access a local > scanner. I just had a look: it also includes the commands scanimage and > sane-find-scanner (which probably would work perfectly fine with a > broken libsystemd0 dependency). So the vast majority of users won't > need it. IIRC, a sane developer had replied to that thread and said > that also saned just checks for the existence of libsystemd0 but does > not need it at all. So the "dependency" is null and could be removed. You remember correctly ;-) It's not a "dependency", it's a compile-time option. To get rid of the Depends:, you will need to drop libsystemd-dev (and maybe dh-systemd) from the debian/control file and rebuild the package. That's all. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Security updates in Devuan
Hi John, John Franklin writes: > I’ve seen several security alerts from Debian, but no matching > updates in Devuan. For example, the “file" package has > CVE-2017-1000249, released yesterday. > >> For the stable distribution (stretch), this problem has been fixed in >> version 1:5.30-1+deb9u1. >> >> For the unstable distribution (sid), this problem has been fixed in >> version 1:5.32-1. > > But, on a Devuan Ascii VM: Uhm, Devuan ascii is testing. I'd think that doesn't get any security upgrades, just like Debian's testing (buster) doesn't get any. In addition, this particular DSA doesn't mention fixes for oldstable so I would not expect Devuan's jessie to get any security upgrade either. Looks like you'll have to wait until whatever hit unstable trickles down to testing. > [...] > > Maybe this one is too new, but the “apache2" package has > CVE-2017-9788 released July 18th, 2017. > >> For the oldstable distribution (jessie), this problem has been fixed >> in version 2.4.10-10+deb8u10. >> >> For the stable distribution (stretch), this problem has been fixed in >> version 2.4.25-3+deb9u2. >> >> For the unstable distribution (sid), this problem has been fixed in >> version 2.4.27-1. > > The latest apache2 in Ascii is 2.4.25-3+deb9u1. On my Devuan jessie I get this $ apt-cache policy apache2 apache2: Installed: (none) Candidate: 2.4.10-10+deb8u10 Version table: 2.4.10-10+deb8u10 0 500 http://auto.mirror.devuan.org/merged/ jessie-security/main amd64 Packages 2.4.10-10+deb8u9 0 500 http://auto.mirror.devuan.org/merged/ jessie/main amd64 Packages This matches what is available for Debian's jessie (oldstable). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Docker on Devuan?
Hi Ozi, Ozi Traveller writes: > Just wondering whether anyone has managed to get docker installed on Devuan? > > If so, how? And are you getting docker updates as well? Have a look at my blog post[1] on this topic ;-) [1]: https://paddy-hack.gitlab.io/posts/sandwiching-docker-with-devuan/ I basically just use the vendor provided package for Debian. Works fine so far. I've also put together a Devuan base image and have a few issues[2] that I plan to work on in the not too distant future. [2]: https://gitlab.com/paddy-hack/devuan/issues Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Docker on Devuan?
Hi, goli...@dyne.org writes: > On 2017-09-07 07:22, Olaf Meeuwissen wrote: >> Hi Ozi, >> >> Ozi Traveller writes: >> >>> Just wondering whether anyone has managed to get docker installed on >>> Devuan? >>> >>> If so, how? And are you getting docker updates as well? >> >> Have a look at my blog post[1] on this topic ;-) >> >> [1]: https://paddy-hack.gitlab.io/posts/sandwiching-docker-with-devuan/ >> >> I basically just use the vendor provided package for Debian. Works >> fine so far. >> >> I've also put together a Devuan base image and have a few issues[2] >> that I plan to work on in the not too distant future. >> >> [2]: https://gitlab.com/paddy-hack/devuan/issues >> >> Hope this helps, > > Would you consider moving that to git.devuan.org? Would make it easier > for devuan users to find. I have an account on git.devuan.org already, so, yes, I could move my Docker Devuan base image project there but I'm not quite sure how that would affect the CI/CD pipeline I use, i.e. my .gitlab-ci.yml, and what Docker registry I would be able to push the images to. There doesn't seem to be any Registry support yet on git.devuan.org :-( Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] docker images
Sorry for the late follow-up, been travelling. Enrico Weigelt, metux IT consult writes: > On 16.09.2017 21:11, goli...@dyne.org wrote: >> On 2017-09-16 14:03, Enrico Weigelt, metux IT consult wrote: >>> Hi folks, >>> >>> anyone of you already created docker images ? >>> >>> What do you think about publishing 'official' images into the >>> docker.io registry ? Maybe starting with very minimal - one per release >>> and arch ... >> >> Did you not see this thread started about a week ago? >> >> https://lists.dyne.org/lurker/message/20170906.214658.6fa81dd7.en.html @golinux> thanks for mentioning it. > must have missed that. > > by 'official' I mean something equivalent to the debian ones, > w/ 'devuan' username in the registry, so it clear to everybody, > it's coming from the devuan project itself, not just some > individual. # Technically it's the 'devuan' *image* that lives in the "official" # namespace of the special cased Docker Hub registry. BTW, that hub # has been renamed to the Docker Store ... To make it really clear it comes from the Devuan project itself, I'd prefer getting it from a Devuan hosted registry. > IMHO, this should be coming directly bootstrappe'd from devuan repos > and be very minimal. The devuan images available from my GitLab registry *are* directly bootstrapped from the devuan repos using devuan's debootstrap. All the bootstrapping is done on an intermediate devuan image that was created by migrating the debian base image to Devuan. > My *current* goal is setting up some builder image for ptxdist-based > applications - later on, I'd like to replace my manually built chroot > on my notebook via docker, add another one for skype jail, etc. > For that it would be cool to have a well-maintained minimal base. > (for now, I still have lots of stuff on ubuntu and debian, which > I'd like to replace in the future) If you have any suggestions for my images feel free to submit issues at https://gitlab.com/paddy-hack/devuan/issues Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..weird net outage, and aptitude showed me 611 untrusted packages, was: New behaviour under Devuan.
Don Wright writes: > Arnt Karlsen wrote: > >>On Fri, 22 Sep 2017 13:30:52 +0200, Arnt wrote in message >><20170922133052.30fab...@nb6.lan>: >> >> >>> ..weird net "outage", I had dns, icmp and _nothing_ else, >>> outside my isp's net. >> >>..another thing that caught my attention, is aptitude showed >>me "611 new untrusted packages" and that "-t experimental" >>"was incompatible" or somesuch error message, update dropped >>those messages and the "611 new untrusted packages" to 18 new >>trusted ones. >> >>..anyone else see this? > > It isn't new. I saw that few times under Debian when I couldn't download the > current trusted list for various reasons. Not having the new signing key > from the keyring package is one cause. A successful update always fixed it. Another is truncated or missing Packages files which result from botched `apt-get update` runs. If `apt-get update` downloads all files without error, you should not see any mention of untrusted packages. # Assuming of course, that all your sources are signed and you have all # needed keys on your APT keyring (see `man apt-key`). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd-free => Gnome-free? [Was: Re: Gnome?
goli...@dyne.org writes:
> On 2017-09-20 22:36, John Franklin wrote:
>>> On Sep 20, 2017, at 10:59 PM, goli...@dyne.org wrote:
>>>
>>> From a search for 'network-manager' in the botbot logs.
>>> https://botbot.me/freenode/devuan/search/?q=network-manager
>>> Was that so hard?
>>
>> Yes, it is. And condescending.
>>
>> Why would someone look at the IRC logs of a site that they've never
>> heard of to find out about something in the Jessie and Ascii
>> repositories?
>>
>> jf
>
> Because botbot logs the #devuan irc channel where a LOT of questions are
> answered and or solved. IMO every Devuan user should have it
> bookmarked. It is mentioned frequently on all Devuan communication
> channels - those references are pretty hard to miss - and it should be
> one of the first resources to tap. Think of it as a variation on "give
> a man a fish/teach a man to fish" . . . Of course, checking the
> repository as you did is the most logical place to look for a package.
In the "teach a man to fish" department, set up your apt sources.list to
track the Devuan releases you are willing to install from, e.g. jessie
and ascii, and then something like
sudo apt-get update
for release in jessie ascii; do
apt-get depends network-manager/$release | grep systemd
done
Much more authorative and up-to-date than IRC logs.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] epkowa backend for Perfection V100
Hi Ralph,
Ralph Ronnquist writes:
> leloft wrote on 14/11/17 21:13:
>> Hello to everyone,
>>
>> Please, has anybody out there had any experience with the
>> Epson-derived epkowa non-free backend for sane. I am trying to set up a
>> scanner (Epson V100) on a remote headless machine in the lab coupled to
>> an rsync script to transfer the scanned images to another machine with
>> a GUI for processing.
>>
>> I am getting permissions problems with libusb, so I have
>> (1) added sane, iscan, epkowa rules
>> to /etc/udev/rules.d, /lib/udev/rules.d
>> (2) changed permissions (to 666, 777, and back to 644) of the device
>> found by sane-find-scanner at /dev/bus/usb/002/003
>> (3) added the user to the scanner and saned groups
>> (4) turned the scanner off and on, rebooted the computer
>> (5) launching scanimage as root and as a normal user
>> (6) issuing $SANE_DEBUG_SANEI_USB=255 scanimage -v -v -v> test.pnm 2>
>> usb-verbose.log which gives the output
>> ...
>> [sanei_debug] Setting debug level of sanei_usb to 255.
>> [sanei_usb] sanei_usb_init: initializing libusb-1.0
>> [sanei_usb] sanei_usb_scan_devices: marking existing devices
>> [sanei_usb] libusb_scan_devices: Looking for libusb-1.0 devices
>> [sanei_usb] libusb_scan_devices: found libusb-1.0 device
>> (0x04b8/0x012d) interface 0 at libusb:002:003
>> [sanei_usb] store_device: add dn 0 with libusb:002:003
>> ...
>>
>> but none of this works: I am still getting those permissions issues
>>
>> $ scanimage -p > test.pnm
>> scanimage: open of device epkowa:usb:002:003 failed: Access to resource
>> has been denied
>>
>> Am I putting these rules in the right places and/or
>> what permissions should i assign (i thought 777 would do it...!)? The
>> machine is running ascii upgraded from jessie last week on a 4.9.61-gnu
>> linux-libre kernel. There were no reports of the epson software trying
>> to install any headers during installation. However, I am not sure if
>> the iscan software only works through a GUI.
>>
>> Any pointers would be greatly appreciated.
>
> The udev rules for scanners (in 60-libsane.rules) end up with a
> "setfacl" command, from the line:
> ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
>
> I'm not sure what happens there, but it suggests there are some "ACL"
> permissions being involved, separate from the normal file permissions.
Indeed. This is adding read/write permissions to the device for anyone
in the scanner group (regardless of the device's "primary" group). On
most distributions, the user needs to be a member of a scanner or sane
group in order to get read/write access to the device. The read/write
is needed to, doh!, communicate with the device.
I forgot why Julien Blache decided to use setfacl but we discussed it
for quite a bit IIRC. You might find this in the sane-devel archives.
Anyway, the upshot of this is that doing an `ls -l` on the device does
not tell the whole story. You'd need getfacl(1) for that.
> On the other hand, by your point (1) you might have seen this already.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rc.local removed from Debian 9, rly?
Hi Jaromil, list, Jaromil writes: > dear John and Olaf, > > Thanks for proving me wrong, this is exactly what I hoped for. > > In fact my mail was perhaps badly worded and contained already a rant, > but was really about asking this list for a critical analysis. For 2 > main reasons: 1) there are very knowledgeable people (like you both) > that often are capable of checking better than me 2) I am a lazy wolf > and prefer writing a mail than checking myself. Reading back the mail that started all of this, yes, that one was not that "alarmist". The follow-up got a bit more so. Those things happen as thread tend to drift. I'll try to make a habit of re-reading the initial post before "venting" a reply. > I also note as you point out that this behavior may be > counterproductive for the public perception of this project: a way or > another I also represent Devuan and maybe I should hold off this > attitude and post only things that I am sure of. This is difficult for > me, since I conceive spaces for debate as this and other mailinglists > as spaces where to share doubts, fears, needs and dreams even more > than findings and announcements, for which an article or a twit > @DevuanOrg may be better. > > anyway, point taken. I know well that I'm wrong sometimes, just like > now. So now I agree that considering this and the other discussion > about redis, there is no real "vandalism" happening in Debian. About > redis was just a maintainer fumbling around broken scripts through > releases, while the rc.local case its just that people don't care > about the regressions introduced by systemd. Glad you realize this and glad you say so on the list. We should all practice a bit of restraint, do some minimal research and include references before making "wild claims". As a Debian Care Taker, you should perhaps take care even more ;-) > [...] Thanks and keep up the good work, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rc.local removed from Debian 9, rly?
Hi all, I've read all the followup until 2017-11-22T10:21Z. I may follow up on selected posts, but I wanted to tackle this first. KatolaZ writes: > On Tue, Nov 21, 2017 at 04:05:47PM +0100, John Hughes wrote: >> On 21/11/17 15:53, KatolaZ wrote: >> >> >What matters is that we need to retain initscripts as "important". >> >> If you have sysvinit then it's a damn site more than "important", it's a >> dependency for sysvinit-core. > > I was not referring only to sysvinit. Since the expectation for any > "pluggable" init system is to not break anything that works (at least > in Devuan), this point must be taken into account by any candidate > alternative init system (at least in Devuan). Devuan has an `init` package that is Priority: required and Essential: yes (on Jessie) or Important:yes (on Ascii and Ceres). Trying to purge `init` will warn you sternly and require a magic incantation, something along the lines of WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! init [...] You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' The init package has a Pre-Depends: sysvinit-core | upstart. Both packages have a Depends: list that includes initscripts (without any alternatives for initscripts). Note that upstart is only available in Jessie (it's purely virtual on Ascii and Ceres). I have checked this on Jessie, Ascii and Ceres (using my Devuan Docker base images[1]). [1]: https://gitlab.com/paddy-hack/devuan/container_registry Given the above, I don't think there is not much need to make sure that the `initscripts` package is made Priority: important. On any of the Devuan versions it will be installed so /etc/rc.local will exist, be executable and run courtesy of sysvinit-core's or upstart's /sbin/init. Whether /etc/rc.local will be run (and on what run levels) is, IMHO, a matter for *your* init system to decide. If your init system wants to cater to a decades long tradition of running /etc/rc.local at system startup, it should declare a dependency on initscripts or provide an /etc/rc.local itself. If you want to use /etc/rc.local to tweak things, *you* should install an init system that runs it (and Devuan's `init` package should list it as a preferred alternative ;-) Any init systems that deviate from age old traditions, should, ideally, clearly document that. If they don't, cluebat their maintainers ;-) And for the masses that don't know what /etc/rc.local is all about? Well, they wouldn't know either way, so are pretty much unaffected by all of this anyway. Does that make sense? -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Busters latest kernel
Hi Dave, Dave Turner writes: > On 27/11/17 21:58, Rowland Penny wrote: >> Hi, a guy has just asked a question on the samba mailing list about >> apparmor and Samba, it seems that last week, apparmor became a >> dependency for the kernel on Buster, because of systemd. >> >> Can I take it this dependency will be removed in Beowulf ? > > What debian gets up to on 'testing' = Buster and 'unstable' = sid can be > interesting at times. > > If that dependency on apparmor is now in Buster I would expect it to be > in sid having proved itself as a 'good thing'. Not necessarily. Moving from unstable to testing merely means that nobody using unstable was annoyed enough by any breakage to file a sufficiently severe bug report against the package within the grace period (ten days for packages with urgency=low, IIRC). > Having just checked my sid install there are no signs of apparmor being > a dependency for the kernel or for Samba. As Adam mentioned, its a Recommends: of the kernel but you may be left with a non-booting machine unless you pass an `apparmor=0` to the kernel at boot time. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Busters latest kernel
Hi Dave, Cc:ing this to the list again, hope you don't mind. Dave Turner writes: > On 29/11/17 11:07, Olaf Meeuwissen wrote: >> Hi Dave, >> >> Dave Turner writes: >> >>> On 27/11/17 21:58, Rowland Penny wrote: >>>> Hi, a guy has just asked a question on the samba mailing list about >>>> apparmor and Samba, it seems that last week, apparmor became a >>>> dependency for the kernel on Buster, because of systemd. >>>> >>>> Can I take it this dependency will be removed in Beowulf ? >>> What debian gets up to on 'testing' = Buster and 'unstable' = sid can be >>> interesting at times. >>> >>> If that dependency on apparmor is now in Buster I would expect it to be >>> in sid having proved itself as a 'good thing'. >> Not necessarily. Moving from unstable to testing merely means that >> nobody using unstable was annoyed enough by any breakage to file a >> sufficiently severe bug report against the package within the grace >> period (ten days for packages with urgency=low, IIRC). >> >>> Having just checked my sid install there are no signs of apparmor being >>> a dependency for the kernel or for Samba. >> As Adam mentioned, its a Recommends: of the kernel but you may be left >> with a non-booting machine unless you pass an `apparmor=0` to the kernel >> at boot time. > Olaf, > > In which file would I find the line 'apparmor=0' ? > > I did a 'sudo grep -R apparmor' in /bin and /boot and /etc and /sbin. > apparmor is definitely in quite a few places but that line never showed up! That is exactly the problem. It is something *you* have to add if you decide to remove apparmor. You *can* add it interactively at the boot prompt every time you boot, but it would be much better for your sanity to add it in /etc/default/grub (to the GRUB_CMDLINE_LINUX variable) and run `sudo update-grub` to persist that in /boot/grub/grub.cfg. # In principle, the apparmor package's postrm could do this for you (but # it is probably not trivial to get right in all situations). > Interestingly 'sudo grep -R apparmor' run from / crashed my laptop! If you want to grep / recursively, there is no point in deferencing symlinks as you'll get to process where they point to anyway ;-) A -r should suffice. That said, you probably do *not* want to grep your virtual file systems, devices, sockets and all of memory. So you'd be better of doing something like sudo grep -r -D skip apparmor $(ls / | sed '/dev/d; /proc/d; /run/d; \ /sys/d; /tmp/d') Feel free to adjust the sed expression to your systems idiosyncracies but this should cover the most common cases. You might want to add /media and /mnt as these are normally used for temporary content. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Virtualbox?
Hi, I've read the thread until Gregory's message from 2017-12-02T00:10Z but figured my reply would fit in better here. Fulano Diego Perez writes: > Gregory Nowak: >> On Fri, Dec 01, 2017 at 12:36:51AM +1100, Fulano Diego Perez wrote: >>> Setting up virtualbox (4.3.36-dfsg-1+deb8u1) ... >>> [ ok ] Stopping VirtualBox kernel modules. >>> [FAIL] Starting VirtualBox kernel modules[] No suitable module for >>> running kernel found ... failed! >>> failed! >>> invoke-rc.d: initscript virtualbox, action "restart" failed. >> >> apt-get install virtualbox-dkms linux-headers-amd64 > > hmmm > > linux-headers-3.16.0-4-all > linux-headers-3.16.0-4-all-amd64 > linux-headers-amd64 > linux-source-3.16 > virtualbox-dkms - previously installed > > i dont get it Neither do I. All I needed was, if you put it in a single apt-get command, on a jessie *only* system sudo apt-get install linux-image-amd64 linux-headers-amd64 virtualbox I did not need a "headers all" or linux-source package. Everything else needed is pulled in via dependencies. Here's a few questions though, do you have other kernel images installed? Which kernel are you running when you try to install virtualbox? The following should help answering these dpkg-query -W | grep linux-image uname -a Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrading from jessie to ascii
Hi Nelson, Nelson H. F. Beebe writes: > I installed Devuan about 4 months ago in our test lab, which now > houses about 180 flavors of Unix-(like) systems. The starting point > was the devuan_jessie_1.0.0_amd64_DVD.iso file. > > After reading DNG list traffic for several weeks, and seeing frequent > mention of the ascii release, I followed recipes that I found in Web > searches after applying these changes: > > % grep -v '^#' /etc/apt/sources.list | egrep -v '^ *$|deb-src' > deb http://auto.mirror.devuan.org/merged ascii main > deb http://us.mirror.devuan.org/merged/ ascii-security main non-free > deb http://us.mirror.devuan.org/merged/ ascii-updates main non-free > deb http://packages.devuan.org/merged ascii main non-free > > I run updates frequently, and the last changes in /bin and /usr/bin > are all less than 8 days old. The puzzling thing is this: > > % cat /etc/devuan_version > jessie > > Do other folks who have upgraded to ascii still see that file > reporting jessie? If not, then can someone suggest what I've done > wrong in my upgrades? Looks like your base-files package was not upgraded for some reason. Did you `apt-get dist-upgrade`? > A check of my filesystem shows that some of those files were changed > just a week ago. Latest ascii base-files package is 9.2+devuan7 and that has been around for at least two weeks (but probably a good while longer). $ apt-cache policy base-files base-files: Installed: 9.2+devuan7 Candidate: 9.2+devuan7 Version table: *** 9.2+devuan7 500 500 http://packages.devuan.org/merged ascii/main amd64 Packages 100 /var/lib/dpkg/status $ cat /etc/devuan_version ascii/ceres Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] epkowa backend for Perfection V100
Hi, leloft writes: > Hello to everyone, > > Please, has anybody out there had any experience with the > Epson-derived epkowa non-free backend for sane. I worked on it for about a decade as an upstream developer, so, yes, sort of ;-) I'm assuming you're trying to use this on Devuan jessie or ascii. > I am trying to set up a scanner (Epson V100) That model requires a DFSG non-free binary-only plugin. You did install that, right? You absolutely *need* the iscan-plugin-gt-s600. BTW, the epkowa backend itself is free but allows the use of non-free plugins for those models that need them :-( > on a remote headless > machine in the lab coupled to an rsync script to transfer the scanned > images to another machine with a GUI for processing. > > I am getting permissions problems with libusb, so I have > (1) added sane, iscan, epkowa rules > to /etc/udev/rules.d, /lib/udev/rules.d How did you add iscan? What epkowa rules do you use? Any rules provided by iscan should go under /lib/udev/rules.d. Your own rules should go under /etc/udev/rules.d. Note that file names should end with a .rules suffix. IIRC, the binary package you can download from EPSON's site will take care of all these things (and should have been tested on one of Debian's jessie of wheezy releases). If you build from source, I'm no longer sure of what a `sudo make install` would do (it's been more than seven years since I saw the code). > (2) changed permissions (to 666, 777, and back to 644) of the device > found by sane-find-scanner at /dev/bus/usb/002/003 Please note that /dev/bus/usb/xxx/yyy *changes* everytime you power cycle or replug the device (or reboot your machine). > (3) added the user to the scanner and saned groups > (4) turned the scanner off and on, rebooted the computer > (5) launching scanimage as root and as a normal user > (6) issuing $SANE_DEBUG_SANEI_USB=255 scanimage -v -v -v> test.pnm 2> > usb-verbose.log which gives the output > ... > [sanei_debug] Setting debug level of sanei_usb to 255. > [sanei_usb] sanei_usb_init: initializing libusb-1.0 > [sanei_usb] sanei_usb_scan_devices: marking existing devices > [sanei_usb] libusb_scan_devices: Looking for libusb-1.0 devices > [sanei_usb] libusb_scan_devices: found libusb-1.0 device > (0x04b8/0x012d) interface 0 at libusb:002:003 > [sanei_usb] store_device: add dn 0 with libusb:002:003 > ... > > but none of this works: I am still getting those permissions issues > > $ scanimage -p > test.pnm > scanimage: open of device epkowa:usb:002:003 failed: Access to resource > has been denied Here's guessing that you haven't installed the plugin. > Am I putting these rules in the right places and/or > what permissions should i assign (i thought 777 would do it...!)? The > machine is running ascii upgraded from jessie last week on a 4.9.61-gnu > linux-libre kernel. There were no reports of the epson software trying > to install any headers during installation. However, I am not sure if > the iscan software only works through a GUI. The epkowa backend is, at least should be, usable with any SANE frontend, graphical or not. Matter of fact, during development I would often test with scanimage because that was easier to script ;-) > Any pointers would be greatly appreciated. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rc.local removed from Debian 9, rly?
Hi, Jaromil writes: > On 19 November 2017 21:14:26 CET, Didier Kryn <k...@in2p3.fr> wrote: > >>Conclusion: initscripts profides the infrastructure to invoke >>/etc/rc.local if it exists, but it doesn't provide an empty >>/etc/rc.local. > > Ok, this is what I hoped and it still makes sense. > > IMHO deprecation means vandalism may happen > in the future: some people should be vigilant and there > should be already a clear statement and discussion > about what this "deprecation" means. > > if it just means that /etc/rc.local is not created by default > but processed if found executable, then it would be fine: > some UNIX systems did that already in the past, > but I am afraid the word "deprecation" means something else. FYI, /etc/rc.local is created from initscripts.postinst on first install and when upgrading from versions before "2.86.ds1-16". Just because a file is not found by `dpkg -S` doesn't mean it is not provided. There are quite a number of files that are generated in postinstall scripts. Next time, before making rash accusations and dreaming up conspiracy theories, take a *good* look. Just a simple `grep -rl rc.local /var/lib/dpkg/info` is all that it took me to find this out on my Devuan Jessie. To cross check, I went over to package.debian.org to have a look at their initscripts package. stretch has 2.88dsf-59.9, buster and sid have 2.88dsf-50.10. Pulled the debian/ directory tarball and checked initscripts.postinst. Nothing changed and rc.local will still be created. Crying wolf like this time and again is not doing Devuan any good. FWIW, I just modified the /etc/rc.local on two of my Devuan ASCII machines to fix up ownership on an ext4 mount and that worked just fine. But then again, initscripts *is* devuanized ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rc.local removed from Debian 9, rly?
Hi Jaromil, list,
Jaromil writes:
> dear Olaf,
>
> On Mon, 20 Nov 2017, Olaf Meeuwissen wrote:
>
>> Crying wolf like this time and again is not doing Devuan any good.
>
> No, I am the wolf.
I do not mean this personally. I just recalled the mail that set off
the redis discussion and this one and noticed one thing in common: a
lack of backing up claims without proper investigation. If anyone wants
to make a claim about anyone else "sabotaging" non-systemd systems, just
show some cold, hard facts to back it up before pointing fingers one way
or another.
# FTR, I've been using Debian since 1998 and switched all my machines to
# Devuan in 2017 because, eh, I think systemd is getting in *my* way.
>> FWIW, I just modified the /etc/rc.local on two of my Devuan ASCII
>> machines to fix up ownership on an ext4 mount and that worked just
>> fine. But then again, initscripts *is* devuanized ;-)
>>
>> Hope this helps,
>
> It doesn't: you are bringing confusion.
Actually, with respect to the quoted paragraph, you're probably right.
I should have left that out. It detracts from the rest of what I wrote.
> You have checked Devuan. I'm talking about Debian 9 "Stretch"
In the same mail you replied to, I also wrote:
>> Just a simple `grep -rl rc.local /var/lib/dpkg/info` is all that it took
>> me to find this out on my Devuan Jessie. To cross check, I went over to
>> package.debian.org to have a look at their initscripts package. stretch
>> has 2.88dsf-59.9, buster and sid have 2.88dsf-50.10. Pulled the debian/
>> directory tarball and checked initscripts.postinst. Nothing changed and
>> rc.local will still be created.
So, yes, I *did* check Stretch and Buster and Sid. To make really sure,
I just eyeballed the initscripts.postinst files again and they *create*
an /etc/rc.local file 'on first install and when upgrading from versions
before "2.86.ds1-16"'. To make absolutely really sure, I checked the
Debian Docker images for Stretch and Buster. Neither has an initscripts
package installed and /etc/rc.local is missing. I installed initscripts
on both and in both cases an /etc/rc.local file was created.
# FTR, both the Debian Stretch and Buster Docker images come *without*
# systemd installed. This is due to the nature of containers as they
# are supposed to run just a task-specific, dedicated program as their
# PID1. For the Debian containers that is /bin/bash, BTW.
> Here the rumors I've heard from bitcoin core development: a CI script
> was broken for three reasons, of which the mandatory activation of
> rc.local via systemctl is just one.
> https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md
>
> also "rumors" of "deprecation" are all around the web with a search:
> https://stackoverflow.com/questions/44797694/where-is-rc-local-in-debian-9-debian-stretch
> http://www.itechlounge.net/2017/10/linux-how-to-add-rc-local-in-debian-9/
I cannot say I have really *read* these but I have at least skimmed them
and the problem seems to be that they assume /etc/rc.local is provided
by some package that is installed by default. Until Jessie, initscripts
was Priority: required so it was installed by default. As of Stretch,
it has become Priority: optional and will not be installed by default.
A quick check of the packages that would pull it in (as per massaged
`apt-cache rdepends`) on Stretch gives:
$ apt-cache rdepends initscripts | sed -n '/^ /p' | while read pkg; do \
echo $pkg ; apt-cache depends $pkg | grep initscripts; done \
| sed -n '/^[^ ]/{ H; N; /Depends/P }'
sysvinit-core
debian-edu-config
console-setup-linux
console-setup-freebsd
console-log
but note that there are a fair number of packages that declare a Breaks:
or Conflicts: which may warrant further investigation.
As for Devuan, it flags sysvinit-core as Priority: important and
therefore the initscripts package will be pulled in.
> there is no official mention on Debian about a "deprecation", which
> I'd consider vandalism. I am very happy of that and I'm asking if its
> real or not that is "deprecated" as others write and if anyone knows
> more about Debian's long term intention with rc.local, since its
> function has already changed:
>
> 1- it is not created by default
Please note the that the /etc/rc.local that is created by default is no
more than
#!/bin/sh -e
exit 0
once you remove the documentation. Anyone that knows about and needs an
rc.local can whip up something more meaningful in, what?, 10 seconds.
> 2- it is not executed in Debian Stretch (9) even if existing
Now, here is something I am not sure about but the content of the pages
in your last two links seem to suggests that it is *systemd* that no
longer honours a /etc/rc.loca
Re: [DNG] Virtualbox?
Hi, fsmithred writes: > On 10/25/2017 08:05 AM, Olaf Meeuwissen wrote: >> Using the virtualbox package from either jessie (4.3.36-dfsg-1+deb8u1) >> or jessie-backports (5.1.8-dfsg-6~bpo8+2) with a stock linux-image-amd64 >> (3.16+63) from jessie works fine. That is, it installs without errors >> and virtualbox images start fine (based on my provisioning Debian jessie >> images and ssh-ing into them). >> >> Using either virtualbox package with the stock linux-image-amd64 from >> jessie-backports (4.9+80~bpo8+1) however does *not* work. Installation >> fails with a compile error of the vboxdrv kernel module. It looks like >> the kernel API has changed (unsurprisingly when going from a major >> version of 3 to 4). Neither virtualbox package seems to deal with this, >> not even the one from backports. >> >> Next move is checking whether things work in ascii because my laptop at >> the office doesn't really work with a 3.16 kernel. > > Good luck with that. There is no virtualbox package in ascii/stretch. You > can get the packages from virtualbox.org, and those will work in ascii. > > OK, that's weird - there's one in ascii-backports but not in > stretch-backports. I don't know what that's about. A few minutes of > googling tells me what I already know - it's not in stretch. Maybe someone > else knows the right words to search to find out why that is. There is a virtualbox package in stretch-backports (and buster and sid). See https://packages.debian.org/search?keywords=virtualbox This is the package that is "merged" into ascii-backports. It installs without any problem against the ascii vanilla kernel (linux-image-amd64 in my case). I've been using it at the office and it seems to work (depending on your definition of "work"). I've used in combination with a Vagrant box that provides a debian/jessie64 based Docker capable Jenkins slave agent. The only issue I have at the moment is that the box' clock runs behind at the pace of 20 seconds to the minute! That's despite the fact that both the host OS and the Vagrant box have ntp/openntpd installed. The host OS' clock stays in sync. Both use the same set of NTP servers and can communicate with them. As to why virtualbox is not in stretch, that's detailed in BTS#794466. Long story short, it's because the Debian and Oracle policies for CVEs are at odds. Debian does not allow upstream version bumps for stable but Oracle only releases their security *and other* fixes via version bumps and it appears to be too difficult the separate the other fixes from the security ones. The stable-backports, testing and unstable suites don't have this version restriction so can use the upstream as is. From what I read in the BTS, I'd expect the same to happen for buster, i.e. virtualbox getting dropped from buster when that enters freeze and to resurface in buster-backports after a while. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Virtualbox?
Hi Gregory,
Gregory Nowak writes:
> On Sun, Nov 05, 2017 at 10:55:42AM +0900, Olaf Meeuwissen wrote:
>> The only issue I have at the moment is that the box' clock runs behind
>> at the pace of 20 seconds to the minute! That's despite the fact that
>> both the host OS and the Vagrant box have ntp/openntpd installed. The
>> host OS' clock stays in sync. Both use the same set of NTP servers and
>> can communicate with them.
>
> You do have guest additions installed, right?
Can't check right now, but I don't think so. If it's not installed,
I'll give it a try (on Wednesday probably, don't have time tomorrow)
and report back.
I do have one question though, what ascii/stretch package name(s) should
I pass to `apt-get install`? Here's what I get for APT sources that
only reference `ascii{,-security,-updates,-backports}`.
$ apt-cache search virtualbox-guest
virtualbox-guest-dkms - x86 virtualization solution - guest addition module
source for dkms
virtualbox-guest-source - x86 virtualization solution - guest addition module
source
virtualbox-guest-utils - x86 virtualization solution - non-X11 guest utilities
virtualbox-guest-x11 - x86 virtualization solution - X11 guest utilities
# There is no virtualbox-guest-additions-iso for ascii/stretch, only for
# jessie, buster and sid. The virtualbox-guest-additions package for
# wheezy just transitions to virtualbox-guest-additions-iso.
From what I read in the package descriptions, virtualbox-guest-utils and
virtualbox-guest-x11 provide "stuff" to install in the guest. How does
that jive with installing these on the host? Or should I install these
on the guest? Does that mean the guest also needs virtualbox-guest-dkms
(and the toolchain required to build)? That would suck pretty badly,
IMO.
# OK, so I had three more questions. Hope you don't mind.
Thanks for the possible cluebat.
Hope this help,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] / on lvm2 volume (was Re: WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable)
Hi Rick,
Rick Moen writes:
> Quoting Olaf Meeuwissen (paddy-h...@member.fsf.org):
>
>> I used to mount /usr read-only on my server machines but that quickly
>> becomes a bore when you need to install security upgrades every so
>> often.
>
> Suggestion: Make remounting an automatic part of package operations.
>
> /etc/apt/apt.conf:
>
> DPkg {
> // Auto re-mounting of a read-only /usr
> Pre-Invoke { "mount -o remount,rw /usr"; };
> Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro
> /usr || true"; };
> };
I don't know how long this has been available but had I been aware of
it, I would have used it way back when I used to mount /usr read-only.
That's been a while ... maybe 10 years or so ;-)
Actually, staring at this, I may have done something like that and was
not quite happy with how it worked (or not) and just stopped mounting
/usr read-only. Or maybe I just stopped putting /usr on a file system
of its own (when I started using LVM). I honestly cannot remember why
and what.
Thanks anyway,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Virtualbox?
Hi,
Following up on my own post.
Olaf Meeuwissen writes:
> Hi,
>
> Gregory Nowak writes:
>
>> On Mon, Nov 06, 2017 at 05:44:17PM -0500, zap wrote:
>
> # Actually, none of the quoted stuff was written by zap ;-)
>
>>> > I do have one question though, what ascii/stretch package name(s) should
>>> > I pass to `apt-get install`? Here's what I get for APT sources that
>>> > only reference `ascii{,-security,-updates,-backports}`.
>>> >
>>> > $ apt-cache search virtualbox-guest
>>> > virtualbox-guest-dkms - x86 virtualization solution - guest addition
>>> > module source for dkms
>>> > virtualbox-guest-source - x86 virtualization solution - guest addition
>>> > module source
>>> > virtualbox-guest-utils - x86 virtualization solution - non-X11 guest
>>> > utilities
>>> > virtualbox-guest-x11 - x86 virtualization solution - X11 guest utilities
>>
>> At the very least, you want virtualbox-guest-dkms, and
>> virtualbox-guest-utils.
>
> And linux-headers-amd64 if you use APT::Install-Recommends=false ;-)
>
>> If your guest has x installed, then you'll want virtualbox-guest-x11
>> as well.
>
> It's a headless server, no X.
>
>>> > # There is no virtualbox-guest-additions-iso for ascii/stretch, only for
>>> > # jessie, buster and sid. The virtualbox-guest-additions package for
>>> > # wheezy just transitions to virtualbox-guest-additions-iso.
>>
>> They way I see it, one advantage of not using the iso is that the
>> packages will automatically be pulled in when upgraded versions are
>> available. So no need to mount a new iso, and upgrade by hand.
>
> Not so sure after my experience today because vagrant was complaining
> about a version mismatch for the guest additions (4 point something in
> the VM) and the Virtualbox version on the host OS (5.1.something). I'm
> not sure this matters (the vagrant message claims that "usually" things
> are okay) but it *is* a major version mismatch.
I nuked the VM, reprovisioned it and manually installed a matching
version of the guest additions. Vagrant no longer complained on start
up but the clock issue did not go away.
I did notice, though, that checking the VM after it had been running for
a couple of hours (> 5), there was only an approximate two minute clock
skew. Somewhat later it had increased to about six minutes. That does
not jive with my earlier statements of loosing 20 seconds to the minute.
I'm not sure if this has anything to do with the version of the guest
additions (I doubt it) or whether it is just that I never noticed that
the same thing was happening before.
>>> > From what I read in the package descriptions, virtualbox-guest-utils and
>>> > virtualbox-guest-x11 provide "stuff" to install in the guest. How does
>>> > that jive with installing these on the host? Or should I install these
>>> > on the guest? Does that mean the guest also needs virtualbox-guest-dkms
>>> > (and the toolchain required to build)? That would suck pretty badly,
>>> > IMO.
>>
>> All of these are installed in the guest, not in the host. Yes, the
>> virtualbox-guest-dkms is the source part of the kernel modules that
>> would be built by using dkms. The toolchain parts aren't that big.
>
> The VM is a fairly minimized server (stripped of anything that is not
> explicitly depended on). The toolchain etc added about 20%, IIRC.
It went from 826MB to 985MB, after cleaning out /var/{cache,lib}/apt/.
BTW, it meant to be used as a Jenkins slave for builds from git. Hence
the "bloat".
>> If you have another system with a toolchain and an identical running
>> kernel, you should be able to install virtualbox-guest-dkms there,
>> build the modules, and copy them over into your guest's
>> lib/modules. The system the modules would be built on doesn't need to
>> be a virtualbox guest as far as I know.
>
> That'd be an option but only if really necessary. It'd become a bit
> cumbersome if you use guests with lots of different kernels.
>
> Now back to me trying to get the host and guest to agree (and keep
> agreeing) on what time it is, I tried installed the guest additions (in
> the guest as well as the host), restarted and reprovisioned the image
> but to no avail. I keep losing 20 seconds per minute on the guest.
>
> I'll have another look again tomorrow and will try a matching version of
> the additions (if available). Failing that, I guess I'll have to take a
> look at the various virtualbox settings and command-line options.
See above.
> I did see something men
[DNG] / on lvm2 volume (was Re: WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable)
Hi, John Hughes writes: > On 07/11/17 17:13, Klaus Ethgen wrote: >> [ separate / and /usr ] is the best way to keep your /usr flexible to >> further lvm grows for example. > > Personally I have a / on a lvm2 volume. Works OK for me, I see no loss > in flexibility. I recently did a fresh Devuan _Jessie_ install and mistakenly used guided partitioning on lvm2 putting everything in a single partition spanning the whole disk. Shrinking / is, eh, well, a bit of a pain in the behind ;-) > Like I say, SVR4.2 deprecated separate /usr in the 1990's. I haven't > used a machine without the root filesystem being on a LVM type system > (VXVM in fact) since around 1998. I used to mount /usr read-only on my server machines but that quickly becomes a bore when you need to install security upgrades every so often. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [ANNOUNCE] Devuan Docker Base Images available
Dear all, I have made mention of my Devuan Docker base images on the DNG list in the past[1,2,3]. At that time, there was only a single base image for jessie. Now, there are also images for ascii and ceres as well as a "devuan/slim" variant and "devuan/builder" and "devuan/helper" images that derive from "devuan/slim". [1]: https://lists.dyne.org/lurker/message/20170907.122245.a0ae75aa.en.html [2]: https://lists.dyne.org/lurker/message/20170909.041936.c0135033.en.html [3]: https://lists.dyne.org/lurker/message/20170926.115934.d1b6f1ba.en.html All versions of all images are on a monthly build schedule, so will be updated periodically. Especially for ceres that may be something you care about. Versions based on Beowulf will be made available sometime after it can be debootstrap'd. For details, please refer the the project's README[4]. Should you run into problems, have neat ideas for improvements and/or questions, please submit those as an issue[5]. If you like the images, you can say so by starring[6] the project. [4]: https://gitlab.com/paddy-hack/devuan/blob/master/README.md [5]: https://gitlab.com/paddy-hack/devuan/issues [6]: https://gitlab.com/paddy-hack/devuan/toggle_star Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit for Devuan: was Debian testing drop redis
Hi,
m712 writes:
> On October 28, 2017 11:22:49 AM GMT+03:00, Rick Moen <r...@linuxmafia.com>
> wrote:
>>(But sure, fixing the runit-init package
>>would be a nice-to-have.)
> I have a proposal for this. Basically, have an install script which does
> something like this (I'm not familiar with the Debian packaging scripts so
> assume it's sh):
Install scripts should not assume anything wrt the shell they're using
when OR explicitly state what shell they expect (and where necessary add
an appropriate Pre-Depends). In practice, it's easier to fix your
install script to be /bin/sh compatible.
On Debian/Devuan, /bin/sh defaults to dash.
> # if upgrading, this doesn't run
> if [ "$(pgrep runit -o)" != "1" ]; then
> mv -f /sbin/shutdown{,.old}
> mv -f /sbin/reboot{,.old}
Those are bashisms and won't work with dash
olaf@quark:~$ /bin/sh
$ mv test{,.new}
mv: missing destination file operand after ‘test{,.new}’
Try 'mv --help' for more information.
So, stop trying to be smart ;-) and just say
mv -f /sbin/shutdown /sbin/shutdown.old
mv -f /sbin/reboot /sbin/reboot.old
or
for f in /sbin/shutdown /sbin/reboot; do
mv -f $f $f.old
done
or something.
Moreover, I think something like this would be better handled using
Debian's alternatives mechanism. See `man update-alternatives` for
details.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ascii an waiting for dhcp on boot
Hi Svante, Svante Signell writes: > On Wed, 2017-12-06 at 20:08 +0900, Olaf Meeuwissen wrote: >> >> Downgrade to 0.8.13?From the changelog for 0.8.14: >> >> * Ignore link state when bringing up hotplug interfaces at boot. >> Closes: #814785, #834820 >> >> # Had a quick look and it *seems* udev is involved somehow ... > > Just an idea. Which version of udev are you using? Have you tried eudev? My comment was meant to indicate the udev may have been involved in the reason why these bugs were reported. The way to "solve" these bugs was to ignore the (non-)presence of a cable and just bring up anything in *ifupdown*. Changing udev to some other *dev will not change ifupdown's behaviour. Hope this clarifies, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ascii an waiting for dhcp on boot
Hi, Dr. Nikolaus Klepp writes: > Hi Ralph! > > Am Dienstag, 5. Dezember 2017 schrieb Ralph Ronnquist: >> Dr. Nikolaus Klepp wrote on 05/12/17 18:41: >> > Hi! >> > >> > On 2017-11-29 08:37, Dr. Nikolaus Klepp wrote: >> >> Hi! >> >> >> >> Am Mittwoch, 29. November 2017 schrieb Didier Kryn: >> >>> Le 29/11/2017 à 08:38, Dr. Nikolaus Klepp a écrit : >> >>>> Hi! >> >>>> >> >>>> When bootin ascii and eth0 is present and configured as dhcp and eth0 >> >>>> is not connected to a network, then the boot process is blocked at ~ 1 >> >>>> minute at the stage where eth0 is configured. This is quite anoying and >> >>>> did not happen on jessie. Is there an easy way to get the old behaviour >> >>>> (i.e. background dhcp request) back on ascii? >> >>>> >> >>> >> >>> Sorry to reply by this triviality: did you check >> >>> /etc/network/interfaces ? >> >>> >> >>> If you have 'auto eth0' , then it might explain the wait. >> >>> Normally, if the cable is meant to be unplugged/replugged, you >> >>> should have >> >>> 'allow-hotplug eth0' instead. >> >>> >> >>> Didier >> >> >> >> Well, this is exactly the problem: I have these lines in >> >> /etc/network/interfaces: >> >> >> >> allow-hotplug eth0 >> >> iface eth0 inet dhcp >> >> >> > >> > Maybe I did not make myself clear: >> > >> > No matter which line I put in /etc/network/interfaces, be it >> > "allow-hotplug eth0" or "auto eth0", booting is delayed when no network is >> > present and dhcp should be used. >> > >> > Could somebody else please check if this is behavior is reproducible? >> >> Both of those result in "ifup eth0" being run as part of the boot >> sequence, and a wait for that to succeed or give up. Neither scheme pays >> attention to the link state; it merely checks whether the interface is >> up or not, and if not, it brings it up bmo ifup. >> >> I believe that during some period in the past, the control scripts >> involved (nowadays /etc/init.d/networking or /lib/udev/net.agent) did >> pay attention to link state, and avoided the ifup command when the link >> wasn't there, which then avoided it waiting for dhcp to give up. But I >> might remember it wrong; in any case, progress has made it that today we >> wait, or bypass it by using some other networking solution. >> >> Ralph. > > Ok, then this is really stupid and a regression. Jessie did check if the > cable is plugged in and did only run dhcpcd when the cable was present. Acsii > does not check and so blocks on every system startup for ~ 1 minute. When > ascii becomes stable this will most likely make a bunch of people quit > unhappy :-/ I've been afflicted by the same :-( > Just seen in the manpage: > > (Interfaces marked "allow-hotplug" are brought up when udev detects them. > This can > either be during boot if the interface is already present, or at a later > time, > for example when plugging in a USB network card. Please note that this does > not > have anything to do with detecting a network cable being plugged in.) > > Hm ... what to do about it? Any idea? Downgrade to 0.8.13? From the changelog for 0.8.14: * Ignore link state when bringing up hotplug interfaces at boot. Closes: #814785, #834820 # Had a quick look and it *seems* udev is involved somehow ... Revert the change that "fixes" those two Debian bugs? Another option could be to muck around in /etc/init.d/networking to check whether *wired* "allow-hotplug" interfaces have a cable attached before trying to bring them up. No bright ideas for how you'd check for that though, but it probably involves poking around in /sys/class/net/$IFACE/. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Virtualbox?
Hi Ozi, list, Ozi Traveller writes: > Has anyone installed virtualbox from jessie-backports? There is a systemd > dependency, but not sure whether it's functional or just a stub. I don't see where the systemd dependency is. Here's what I get $ apt-cache -t jessie-backports depends virtualbox | grep systemd $ Yup, no hits at all so virtualbox does not have a *direct* dependency on systemd. BTW, this is for an APT cache that was last updated a couple of minutes ago. A for using virtualbox on jessie, I just had occasion to try that out at the office when using vagrant. Here's what I found for the linux-image and virtualbox combinations on jessie w/ and w/o backports. Using the virtualbox package from either jessie (4.3.36-dfsg-1+deb8u1) or jessie-backports (5.1.8-dfsg-6~bpo8+2) with a stock linux-image-amd64 (3.16+63) from jessie works fine. That is, it installs without errors and virtualbox images start fine (based on my provisioning Debian jessie images and ssh-ing into them). Using either virtualbox package with the stock linux-image-amd64 from jessie-backports (4.9+80~bpo8+1) however does *not* work. Installation fails with a compile error of the vboxdrv kernel module. It looks like the kernel API has changed (unsurprisingly when going from a major version of 3 to 4). Neither virtualbox package seems to deal with this, not even the one from backports. Next move is checking whether things work in ascii because my laptop at the office doesn't really work with a 3.16 kernel. # FTR, my test were done on old, decommissioned laptop where that 3.16 # kernel works like a charm :) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Error after upgrade debian wheezy to devuan jessie...
Hi, Thomas Besser writes: > [...] > As far as I understand, package libc-bin registers dpkg (?) triggers > scripts which are executed on every update of any package. > > How can I find out, which trigger script of libc-bin causes this error? > There must be a place, where dpkg stores this scripts. But where? The trigger definition for libc-bin is in /var/lib/dpkg/info/libc-bin.triggers On my machine it says $ cat /var/lib/dpkg/info/libc-bin.triggers interest ldconfig I am not sure what exactly this does, but I *guess* it triggers updating of /etc/ld.so.cache by running the ldconfig command in some way. IIRC, the error you posted earlier looked a lot like it came from a piece of Perl code but I have no idea where it would come from. My /sbin/ldconfig is a shell script wrapper that handles triggers via dpkg-trigger, an ELF binary, and passes the buck to /sbin/ldconfig.real, also an ELF binary. Both are unlikely to be directly responsible for the error message you posted. # Running Devuan jessie, BTW. I know it doesn't answer your question completely but hope this helps anyway, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
Hi, Arnt Gulbrandsen writes: > taii...@gmx.com writes: >> I found this seemingly cool product, a pci-e hardware RNG that >> produces a large stream of "truly random" "quantum" random >> numbers. > ... >> I am curious what the deal with this is, does it really work? >> what is the use case for this? does anyone here have one? > > I have a competitor, http://www.entropykey.co.uk / apt-get install ekeyd, > which I fear isn't being made any more. It's useful sometimes. "Arnt, > marketing just signed a deal fory x with y, and we need 5000 coupon codes, > they really should be impossible to guess". What these devices does is > basically keep /dev/random topped up, even if the host is a rackmounted > server and you need a half-megabyte of random bits in short order. I have used the `haveged` package to keep my /dev/urandom "topped up" when randomizing disks. Greatly shortened the time needed to fill my disks. No idea about the quality of randomness, though. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Amprolla3 is out for testing
Hi, Arnt Karlsen writes: > On Sat, 21 Oct 2017 20:37:35 +0100, KatolaZ wrote in message > <20171021193735.gg4...@katolaz.homeunix.net>: > >> On Sat, Oct 21, 2017 at 08:48:57PM +0200, Arnt Karlsen wrote: >> >> [cut] >> >> > > >> > > We have been testing amprolla3 for more than two months now, on >> > > dozens machines, and it has been working like a charm. >> > >> > ..ok, with jessie + jessie-* + experimental too? >> > >> >> Yes. You don't need to use both packages.devuan.org and >> pkgmaster.devuan.org. The former serves the packages merged by the >> original amprolla. The latter served the repos merged by amprolla3. So >> choose one of the two. > > ..done, 613 upgradeable, Obsolete & local dropped to 5 from 6k > and Installed rose by 6k to 7380, so I guess we're headed the > right way, I have e.g. pulseaudio wanting to upgrade from our > 5.0-13+devuan2 to I suspect Debian's systemd'ed 7.1.2~bpo8+1, > what else to look out for? I found the same. I'm on jessie with security, updates and backports enabled. It turned out that all my upgradable packages are from the backports suite. Slightly worrying is that a number of these are for devuan-ized packages. The 'pulseaudio' package you mentioned is one. Another that is probably trouble was 'reportbug'. The other (source) packages I found were bash-completions and cups. For non-devuan-ized packages, udev and rsyslog might be problematic. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Congratulations! and some migration questions
Hi, viverna writes: > il devuanizzato Didier Kryn <k...@in2p3.fr> il 10-05-18 17:49:42 ha scritto: >> does the job as it always did. In case you want your system to >> deconfigure/reconfigure Ethernet interfaces when you unplug/replug the >> cables, then 'apt-get install ifplugd'; it's potterware but it just works. > I prefer to use netplug: > apt-get install netplug > it is not potterware. Battled Network Manager Fought wicd Now I have peace! # At least for my wired interfaces Documentation is crisp clear. Functionality is simple. Thanks, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Congratulations! and some migration questions
Hi Didier, Didier Kryn writes: > [... purge Network Manager...] > > BTW, I'm not sure ifupdown and the interfaces file are installed by > default nowadays. I don't remember which package one must install to > have all this traditional infrastructure, though, if it's already > installed, it won't be removed when dist-upgrading. FYI, ifupdown is (still) installed by default but a simple `apt-get install ifupdown` will put it in place if necessary. # I have a habit of marking all installed automatic after the initial # installation and configure APT to purge any unnecessary packages, # occasionally even telling it to ignore Recommends: # If you do that ifupdown may get purged. > If you have a wifi interface, it is more complicated. Explained below. > > 'apt-get install wpa-supplicant wpa-gui', FTR, the package names are wpasupplicant and wpagui, without the - > then write the following two > lines into /etc/wpa_supplicant/wpa_supplicant.conf: > > ctrl_interface=DIR=/run/wpa_supplicant GROUP=dialout > update_config=1 > > Make yourself a member of group dialout. Then search the web for a > tutorial on wifi roaming with wpa_supplicant: it will explain you how to > write the wifi part of the interfaces file. To finish with, > 'dpkg-reconfigure ifplugd' to tell it to handle your wifi interface. Use > wpa_gui everytime you want to connect your laptop to a yet-unknown wifi hub. Thanks for the above. Made my take a look at what wicd was doing under the covers. Should have done so a lot earlier ;-) It puts snippets for your wireless interface(s) below /var/lib/wicd/configurations/ and uses those to run wpa_supplicant like so wpa_supplicant -B -i $if -c /var/lib/wicd/configurations/$mac where $if is the interface name, typically wlan0. The $mac is the MAC address of the wireless access point, lower-cased, no : separators. You can use the files in /var/lib/wicd/configurations/ to seed your /etc/wpa_supplicant/wpa_supplicaton.conf file. As for the group, the user that installed the system is a member of the netdev group by default, I think. Looks like a good default choice to me, unless wpa_supplicant has special requirements. Definitely more nowadaisy than dialout (or dip) :-) BTW, group "definitions" can be found in file://usr/share/doc/base-password/user-and-groups.txt.gz (outdated?) https://wiki.debian.org/SystemGroups I'm off now, reconfiguring my wireless setup. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Origin: field of *_InRelease files (was Re: npm and nodejs)
Hi, wirelessd...@gmail.com writes: > [... in follow-up to a nodejs related question ...] > > Unfortunately those instructions rely on lsb_release providing the > correct output. There is a bug with lsb-release in ascii where it > relies on parsing sources.list for detection. If “lsb_release -sc” > returns “ascii” then you’re all fine but if it returns “testing” > then you’ll just have to add the repo with the manual instructions. Which reminded me of a discussion that happened here on the list and led me to file http://bugs.devuan.org//cgi/bugreport.cgi?bug=199 against the "mirrors" pseudo-package. In my case, `lsb_release -cs` yields 'n/a'. There may or may not be an issue with lsb_release itself but there is definitely an issue with the *_InRelease files for some of the package repositories. Is anyone looking at this? Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan from scratch?
Hi Jaromil, Jaromil writes: > re all, > > today I've noticed this interesting experiment from the news of > Distrowatch: > > https://github.com/scottwilliambeasley/debian-from-scratch/blob/master/README.md > > it's interesting because it provides an alternative "new" way to > bootstrap a new apt based system in addition to the classical > debootstrap method. I also noticed the instructions have no mention of > systemd, wonder where that will sneak in later... > > however I believe this approach works flawlessly on Devuan too. > > what would be useful for? besides learning how the system is made.. After a quick scan of that README.md, I concur with Didier's observations: nothing much beyond learning how to put together a minimal Debian(-based) distribution. The debootstrap *shell script* already does that for you. Want to learn how it works? Use the Source, Luke. The nice part about the README.md is that it explains (some of) the *why* behind steps. That is arguably missing from the Source. BTW, that README.md follows a somewhat different road as debootstrap (building some bits from source for example) but it's not wildly different. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ASCII installation static IP problem
Hi Don, Don Wright writes: > [ ... ASCII using Expert (text) from devuan_ascii_2.0.0_amd64_dvd-1.iso ...] > > Upon successful boot into the system things looked good locally, until I > tried to SSH to the box. Not there! While /etc/network/interfaces has the > settings I expected, the GUI showed wicd had ignored them and called DHCP to > create all new and mostly wrong settings. > > #apt remove wicd soon cleaned that up, but who the systemd thought it was a > good idea to ignore! working! static! IP! settings! and install an unwelcome > network mangler in the first place? Take a purgative, get your heads out of > your ASCII, and stop your wicd ways from overriding traditional handcrafted, > all-natural, artisanal, text-based config files. The output of `apt-cache rdepends wicd` using various combinations of the --recurse and --no-* options indicate that just about any, if not all, of the task-*-desktop packages recommend it, either directly or indirectly. Some may even prefer network-manager ... putting you between a rock and a hard place. > The guilty parties should lose an inch of *nix beard each in penance. The guilty parties would mostly be the task-*-desktop packagers ;-) but if you are comfortable with the installer's Expert mode, why not forego the installation of a desktop and run apt install task-desktop wicd- after the initial system install? > [ Semi-humorous howls of rage aside: Does the installed system ignore static > IP by design? ] Not if you don't install a desktop ;-) # You mentioned installing on a Lenove Think*Server*. I *never* put a # desktop on my servers ... Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Creating .deb packages with jenkins-debian-glue
Hi Tom, Tom writes: > Hi, > > I'm trying to use dh_virtualenv and and jenkins-debian-glue to package > a python app into a .deb using jenkins. > > I followed all the instructions on https://jenkins-debian-glue.org, > updating the steps where required for differences in the latest > Jenkins release, but I see errors when running the > jenkins-debian-glue-binaries job. > > It looked like it was failing due to the output of 'lsb_release > --short --codename' returning "n/a" on Devuan Ascii, so I created > /etc/lsb-release with the relevant details. It's now showing a > different error. The "n/a" sounds like you've also been hit by http://bugs.devuan.org/cgi/bugreport.cgi?bug=199 Try using packages.devuan.org. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ascii installer netinstall iso UPDATE
Hi Stefan, Stefan Krusche writes: > Am Donnerstag 31 Mai 2018 schrieb Stefan Krusche: >> Good day everyone, >> >> while starting the devuan installer from >> devuan_ascii_2.0.0-rc_amd64_netinst.iso and initiating to continue with ssh >> remote install (in graphic expert install mode) the installer showed its >> fingerprint as SHA256:xxx, which was new to me. It used to be an RSA key >> fingerprint. >> >> Problem: when I try to connect from my other machine which is a devuan >> jessie system to the one I'm gonna set up: >> ssh installer@192.168.19.3 >> ssh still shows an RSA fingerprint from the installer, so I don't know how >> to verify it (which was easy with the jessie installer just by looking). >> >> Not that I don't trust my own computer here but I'd like to know if I need >> a more recent version of ssh or if there's a way to get a visual match or >> something. Found nothing about SHA256 host keys in man ssh. >> >> Can anyone clarify about this to me, please? >> > > So, I just found this: > https://superuser.com/questions/929566/sha256-ssh-fingerprint-given-by-the-client-but-only-md5-fingerprint-known-for-se#929567 > according to which fingerprint of the sshd server defaults to SHA256 from some > version on and I'd expect it to be sent as such to the client. > > My older version can't seem to process option "-o FingerprintHash=sha" as > suggested in the posting on superuser.com to get the SHA256 key fingerprint > which is shown on the screen of the installer. My understanding is that on your remote client you should specify md5, not sha. That is, "-o FingerprintHash=md5". > Now, I don't know if the RSA key fingerprint of the sshd server of the > installer, which my ssh client shows, is sent that way from the server (should > be so, right?) or my ssh client is to old and with a newer one it would show > the SHA256 key fingerprint like on the installer screen. Maybe, the installer > has to be configured to send SHA256 key fingerprint and it isn't? If things don't work on the remote client side and you can execute a shell on the machine you're installing on, you can get the MD5 hash with ssh-keygen -l -E md5 -f $file where $file is one of the SSH server's keyfiles in the installation target. IIRC, these should be below /target/etc/ssh/. There is an option to execute a shell in the installer itself or you can switch virtual terminals with one of the Alt-Fn key combos. Don't quite remember for which value of n, but in the F1 through F4 range. Hmm, or was that Ctrl-Alt-Fn? Anyway, just try a couple of combinations ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] "Origin:" now set to "Devuan"
Hi Katolaz, KatolaZ writes: > Dear D1rs, > > as of yesterday, the "Origin:" field in the Release and InRelease > files on pkgmaster.devuan.org and deb.devuan.org has been set to > "Devuan" (it was empty before). Thanks! > This should most probably solve several issues related to incomplete > or wrong information retrieved (openly or silently) by > lsb_release. This includes also a few cases in which Devuan is not > correctly "recognised" as a host system. I've also closed the bug report I filed about this. http://bugs.devuan.org/cgi/bugreport.cgi?bug=199 Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Creating .deb packages with jenkins-debian-glue
Hi KatolaZ, KatolaZ writes: > On Thu, May 31, 2018 at 03:29:30PM +0200, KatolaZ wrote: >> On Thu, May 31, 2018 at 09:16:27PM +0900, Olaf Meeuwissen wrote: >> > >> > The "n/a" sounds like you've also been hit by >> > >> > http://bugs.devuan.org/cgi/bugreport.cgi?bug=199 >> > >> > Try using packages.devuan.org. >> >> Please hold on on that. We are working to solve it. Thanks! > Thanks to parazyd who has just fixed it. If you are using > pkgmaster.devuan.org, please `apt-get update` and then lsb_release > will work correctly: > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Devuan > Description:Devuan GNU/Linux 2.0 (ascii) > Release:2.0 > Codename: ascii > $ Works for me, closed the bug report mentioned above. > If you are on deb.devuan.org it might take up to one hour to > propagate. Please report any undesired behaviour. I'm using deb.devuan.org, so things appear to have propagated just fine. My ascii InRelease files were timestamped 2018-06-02 01:02 JST when I tested. That works out to 2018-06-01 16:02 UTC, if I got my arithmetic right ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] installer woe
Hi Hendrik, Hendrik Boom writes: > I used dd to copy the installer iso to a USB stck on my old laptop: > > dd bs=4M if=devuan_ascii_2.0.0_amd64_netinst.iso of=/dev/sdb status=progress > && sync Looks fine to me. Apart from the status= bit an using bs=1M, I did the same two days ago and installed an old desktop machine just fine. > Then I moved the USB stick to my new Purism laptop, powered it up, > pressed esacpe to get a boot menu, and the USB stick was not recognised > as a boot device. As Didier mentioned in another reply, you may have to play around with settings in the BIOS. I know I had to. In my case, I had to make the USB stick the first hard disk in the hard disk device list even though none of the other hard disks had any OS on them. The BIOS only ever tried to boot from the first hard disk and if that failed went on to the CD drive. You mentioned that Purism ISOs boot fine for you. Could it be that your BIOS has Trusted Boot or Secure Boot or similar enabled? Guess you oughta ask the Purism people about that (after you check their documentation of course). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: Announce: docker-buildpackage
Hi Enrico, Enrico Weigelt, metux IT consult writes: > I've written a tool for isolated deb builds in docker containers. > It's a little bit like pbuilder, but using docker for isolation. > > https://github.com/metux/docker-buildpackage > > Everything written in shellscript, simple config as sh includes. > Not debianized yet, as it might require some local customizations. > (planned for future releases) In the README, I noticed: * automatically debootstrap a build container base image I haven't checked how that is achieved, but why don't you just docker pull registry.gitlab.com/paddy-hack/devuan/builder This will pull an image for the latest official release, i.e. jessie as of writing. There are images for ascii and ceres as well. Just append the codename as the docker image's version. Images are updated monthly. See https://gitlab.com/paddy-hack/devuan for details. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade to ascii
Hi, Hendrik Boom writes: > So is this what I should have in my /etc/apt/sources.list to upgrade > from jessie to ascii? > > deb http://pkgmaster.devuan.org/merged ascii main > deb http://pkgmaster.devuan.org/merged ascii-updates main > deb http://pkgmaster.devuan.org/merged ascii-security main > deb http://pkgmaster.devuan.org/merged ascii-backports main > > and nothing else? That should work just fine. Backports is optional. I just upgraded myself using (almost) the same without any problems and blogged about it here https://paddy-hack.gitlab.io/posts/upgrading-devuan-from-jessie-to-ascii/ Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Should I, or should I not, make a Devuan VimOutliner package?
Hi, Steve Litt writes: > Hi all, > > BACKSTORY... > > I'm the *originator* of VimOutliner, an outline processor that uses the > Vim engine. VimOutliner's top priority was authoring speed. That > priority drove most VimOutliner keyboard commands to begin with a > double comma (,,), which is both extremely easy to hit from typing home > position, and very unlikely to happen within written text. I published > VimOutliner 0.13 June 1 2001. > > Several other people used it, liked it, and improved it far beyond my > capabilities. Several Linux distros acquired VimOutliner packages. > Unfortunately, the Debian VimOutliner package manager insisted on using > double backslash (//) instead of double comma (,,) as the first two You mean double slash, right? Double backslash would be \\ (and way too Windows for my taste ;-). On my Japanese keyboard these are right next to one another, two places to the right of the comma. Of the three, the comma would be easier to type. What's the Debian maintainer's rationale for changing the command prefix? > characters of commands. The double backslash is slower, and more > important, it's a key that appears in different places on different > keyboards. Use of the double backslash represents a degradation of > VimOutliner's top priority: Authoring speed. > > I'm thinking of making the Devuan VimOutliner package use double comma. > I'd take the Debian package and replace all appropriate double > backslashes with double commas. Just a thought, but would it be possible to make the command prefix configurable upstream? Then anyone could set it in a system-wide and/or per user config file and everyone could use whatever is most convenient for them. Upstream can use ,, as the hard-coded default and the Debian maintainer can simply plonk a system-wide configuration file in place. Since everyone seems to be donating ;-) that was my two yen. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade to ascii
Hi, KatolaZ writes: > On Mon, Jan 01, 2018 at 01:59:23PM +0900, Olaf Meeuwissen wrote: >> Hi, >> >> [...] I just upgraded >> myself using (almost) the same without any problems and blogged about >> it here >> >> https://paddy-hack.gitlab.io/posts/upgrading-devuan-from-jessie-to-ascii/ > > very nice report, indeed. Thanks. Glad you liked it. I cleaned up the log for readability and added a bit on cleaning up *.dpkg* files. I've also written a separate post on some of the "issues" I ran into. https://paddy-hack.gitlab.io/posts/a-fortnight-with-ascii/ Happy to see that the theme issues (the ones I noticed at least) are all fixed in clearlooks-phenix-darkpurpy. @golinux: Thanks! Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan ASCII 2.0.0 Beta released
Hi, Fungal-net writes: > Please don''t let the Grouch break up your valentine party but would > anyone care to elaborate on the following scenario? > > We have Joe, Jill, Jack, and Mindy. > Joe is running Wheezy and converts to Ascii > Jill is running Devuan 1 Jessie and converts to ascii > Jack is running Stretch and converts to Ascii > and finally Mindy just installs Ascii-beta-2.0 > > Don't ask me, I have been running ascii for a quite a while now and my > experience with Jessie has been from first boot to the second. And I > have run OpenRC and eudev ever since they appeared in experimental. > > All four of the above have same packages installed in the versions > that they exist in those 4 situations. > > 1 Is the end product different? > 2 Should the end product be different. > 3 The packages that are available and keep upgrading in the debian > branch of merged, do they appear to all four of them as they do in > the debian repository? In other words If you add debian stretch > to the repositories the versions "in merged ascii" and in stretch > should be the same. right? Live at any given minute? That is > what amprolla3 is doing, right? Are they? > > Because as per a couple of hours ago it seems as I have been exposed > to this amprolla3 for 4-5 months now, without knowing, and although I > run about the same stuff on a test debian isntallations, pkgs there > rain down to the level of about 20-30/day, while ascii has been pretty > inactive in terms of upgrades. So what exactly is merged with devuan? IIUC, you say you are seeing 20-30 upgradable packages on a "test" Debian installation. If this is a Debian repositories only system, that number is way too high for either of Debian's Jessie and Stretch. There have been quite a number of security upgrades, 2-3 a day in the last week or so, but nothing near 20-30. Could it be that your Debian "test" system is set up to track Debian's *testing*, i.e. Buster as of writing, as opposed to *stable* (Stretch) or *oldstable* (Jessie)? # See https://www.debian.org/releases/ If that is the case, 20-30 upgradable packages a day seems reasonable and the reason you're not seeing that in Devuan is because ASCII is targetting Debian's Stretch, *not* Buster. Buster will be for Devuan's Beowulf and work on that is unlikely to begin before ASCII becomes the "stable" Devuan release. So if your Debian "test" system is tracking *testing* you're are, in effect, comparing apples and oranges ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev missing dependency
Hi, J. Fahrner writes: > Am 2017-12-27 16:28, schrieb Svante Signell: >> I'm not so sure we should add that dependency, > > Can you explain why? > When udevd calls mtp-probe in it's default configuration, then it must > be assured that mtp-probe is present. Anything else is a bug. Indeed but udev was designed to run any of the scripts it finds in /lib/udev. If libmtp-runtime installs /lib/udev/mtp-probe, *that* is the package that should make sure mtp-probe can be executed. I've tried to find an mtp-probe but the only thing that turned up was /lib/udev/mtp-probe itself. This makes me believe that the message is actually not saying that mtp-probe cannot be found but that it can not (or no longer) find /sys/devices/pci:00/:00:14.0/usb3/3-4 for some reason. BTW, on my system libmtp-runtime appears to have been pulled in by vlc. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ASCII installation static IP problem
Hi Don, Don Wright writes: > Olaf Meeuwissen wrote: > >>Installing a desktop, by default, pulls in wicd (or network-manager). >>You can prevent this by using apt-get's --no-install-recommend option. > > Not an option within the de??an installer - which was the context of the > original post. I understand your point. Yet, you stated in your original post >>> Installed ASCII using Expert (text) from devuan_ascii_2.0.0_amd64_dvd-1.iso. >>> I'm very familiar with the Debian Installer interface from years of using >>> it. Considering that, I think this is an option, even though it is not necessarily an easy one. After you've configured the mirror and proxy settings for APT, execute a shell, chroot into the installer's target directory, from memory that's /target, and run the command. >>Whether either package blatantly ignores your static IP configuration >>from when you installed, I cannot tell for sure (zapped wicd) but I >>vaguely remember that you can tell wicd to leave certain interfaces >>unmolested. That may even be its default behaviour for interfaces that >>are configured in /etc/network/interfaces. >> > [Steve Litt] >>>I would sure find this behavior surprising. >> >>If wicd breaks static IP address configurations out-of-the-box I'd be >>surprised too. I've mainly used it in DHCP settings. On my server's >>wicd was never installed so any static IP configurations just worked as >>intended. > > However surprising to any of you, this is my testimony. A statically > configured interface present in /etc/network/interfaces was ignored **as > installed by Devuan ASCII.iso**. Removing wicd fixed the problem. What other > conclusion can reasonably be drawn but that wicd is the one doing the > ignoring? My use of 'surprised' meant to imply that I consider it a bug (in the 'WTF' category). Understatement didn't make it through :-(( and in hindsight I should have been clearer. Sorry. >># Veteran Unix Administrator's are free to cobble together their own >># solution and `apt purge wicd` goes a long ways towards that end ;-P > > But that's only an option after the fault, which only shows up after > restarting. If the device is not within easy reach, how will you get a > command line at the random assigned IP address in the first place? Although I haven't found myself in that situation, I'd say one of: - not :-( - with a lot of effort - by using the hostname (assuming that your DHCP server's register their leases with your DNS servers) > Background: My situation, which you so deride, I did not mean to deride your situation. Apologies if my follow-up sounded that way. > is a test install of a server with changing products *and management > tools* which is where the desktop comes in. When a configuration is > finally settled upon, the server will be wiped and reinstalled in a > production configuration without desktop as all my other servers have > been, and the management tools installed on a management > workstation. Until then the churn will be limited to this one system. May I suggest you do your test install in a setup that more closely resembles your production configuration. That is, test installs for both the server and the management workstation. You could do either or both on a suitable VM that runs someplace you have physical access. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ASCII installation static IP problem
Hi Steve, Steve Litt writes: > On Thu, 14 Jun 2018 19:54:11 +0900 > Olaf Meeuwissen wrote: > >> Hi Don, >> >> Don Wright writes: >> >> > [ ... ASCII using Expert (text) from >> > devuan_ascii_2.0.0_amd64_dvd-1.iso ...] >> > >> > Upon successful boot into the system things looked good locally, >> > until I tried to SSH to the box. Not there! >> > While /etc/network/interfaces has the settings I expected, the GUI >> > showed wicd had ignored them and called DHCP to create all new and >> > mostly wrong settings. >> > >> > #apt remove wicd soon cleaned that up, but who the systemd thought >> > it was a good idea to ignore! working! static! IP! settings! and >> > install an unwelcome network mangler in the first place? Take a >> > purgative, get your heads out of your ASCII, and stop your wicd >> > ways from overriding traditional handcrafted, all-natural, >> > artisanal, text-based config files. >> >> The output of `apt-cache rdepends wicd` using various combinations of >> the --recurse and --no-* options indicate that just about any, if not >> all, of the task-*-desktop packages recommend it, either directly or >> indirectly. Some may even prefer network-manager ... putting you >> between a rock and a hard place. >> >> > The guilty parties should lose an inch of *nix beard each in >> > penance. >> >> The guilty parties would mostly be the task-*-desktop packagers ;-) >> but if you are comfortable with the installer's Expert mode, why not >> forego the installation of a desktop and run >> >> apt install task-desktop wicd- >> >> after the initial system install? >> >> > [ Semi-humorous howls of rage aside: Does the installed system >> > ignore static IP by design? ] >> >> Not if you don't install a desktop ;-) >> # You mentioned installing on a Lenove Think*Server*. I *never* put a >> # desktop on my servers ... >> >> Hope this helps, > > If I understand this correctly, installing any desktop (does this > include window managers like openbox?) brings in wicd in a mode that > breaks hard coded IP addresses. I only tried to answer the question why wicd was installed and point out a way to have one's static IP configuration at install time honoured. These are separate issues. Installing a desktop, by default, pulls in wicd (or network-manager). You can prevent this by using apt-get's --no-install-recommend option. Whether either package blatantly ignores your static IP configuration from when you installed, I cannot tell for sure (zapped wicd) but I vaguely remember that you can tell wicd to leave certain interfaces unmolested. That may even be its default behaviour for interfaces that are configured in /etc/network/interfaces. > I would sure find this behavior surprising. If wicd breaks static IP address configurations out-of-the-box I'd be surprised too. I've mainly used it in DHCP settings. On my server's wicd was never installed so any static IP configurations just worked as intended. > Is there a way Devuan can eliminate the "recommends" for wicd and > networkmanager with "desktops"? By making it a "suggests". But I do not recommend that as I suspect the majority of desktop users will be using DHCP. The other option is replacing the wicd (or network-manager) recommends with a good alternative. Here "good" means it handles both static and dynamic IP configurations for wired *and* wireless connections in such a way that the majority of desktop users doesn't even notice it's there and at the same time respects the system administrator's hand crafted configuration. # Veteran Unix Administrator's are free to cobble together their own # solution and `apt purge wicd` goes a long ways towards that end ;-P Hope this clarifies, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] One week into Devuan 2.0 ASCII -- Some stats
Hi Arnt, Arnt Karlsen writes: > On Mon, 18 Jun 2018 13:27:35 +0100, Simon wrote in message > <71def11e-d133-4358-b824-46f00dda6...@thehobsons.co.uk>: > >> And as it happens, I had literally just been looking on Distrowatch >> where Devuan is up to rank 11 (with 582 hits/day) over the last 7 >> days vs Debian at rank 6 with 1002 hpd. OK, it’s “just for fun” and >> not really a measure of installed systems, but it shows that there’s >> been steady progress up the charts. >> >> Well done to everyone who proved the naysayers wrong :-) > > ..but why is https://distrowatch.com/table.php?distribution=devuan > saying ceres and testing has systemd??? Don't know, but I just noticed that the Contents-amd64.gz for beowulf contains files that originate from admin/systemd ... As in curl http://deb.devuan.org/merged/dists/beowulf/main/Contents-amd64.gz \ | zegrep admin/systemd$ spits out tons of hits. Maybe that's why? -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] util-linux needs an upgrade on ceres
My monthly Devuan Docker image rebuild bombed today on ceres[1]. The base images for jessie, ascii and beowulf(!) built just fine. Looking into this, I found this in the debootstrap.log dpkg: dependency problems prevent configuration of util-linux: login (1:4.5-1.1) breaks util-linux (<< 2.32-0.2~) and is installed. Version of util-linux to be configured is 2.27.1-1+devuan0.1. Looks like util-linux needs a bit of tender loving care on ceres. [1]: https://gitlab.com/paddy-hack/devuan/pipelines/27093166 Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)
Hi, Arnt Karlsen writes: > On Thu, 26 Jul 2018 22:00:06 +0900, Olaf wrote in message > <87va92gnjd@member.fsf.org>: > >> Hi, >> >> Minor correction in-lined below. >> >> Olaf Meeuwissen writes: >> >> > Hi, >> > >> > KatolaZ writes: >> > >> >> The medium-term plan is to replace libsystemd0 with a libnosystemd >> >> which Provides: libsystemd0 and noops everything, with the >> >> possibility of shelling-out some actions, if the admin wants so. >> >> We will get there. >> > >> > +1, although I'd prefer a more original and playful name ;-) >> > >> > # Not that I have any bright ideas right now :-( >> > >> > d-systemized ... perhaps >> > >> > For the library stubs and the [dpkg.cfg hack][1] I posted just a >> > minute or so ago? Dang! Should have retitled that post :-( >> > >> > [1]: >> > https://lists.dyne.org/lurker/message/20180726.123546.eacb6518.en.html >> > >> > Anyway, most of this is just cosmetic surgery as long as systemd >> > itself stays out of the system. And systemd-boot, nee gummiboot, >> > out of the installer as well. BTW, the cosmetic surgery angle >> > might be a nice avenue to explore for package names! >> > >> > # init-freedom-botox ... :-\ >> > # Maybe just plain init-freedom? >> >> I just realized that true init-freedom should be systemd-inclusive, so >> don't put that dpkg-cfg hack in any kind of "init-freedom" package, >> please. > > ..I respectfully disagree, keep or put in that dpkg-cfg hack. I did not mean to drop the hack. I only meant to not make it part of a package with a name that associates with init-freedom. Keep the hack and put it in a differently named package. Maybe something like rabid-foaming-at-the-mouth-systemd-reference-removal-zealot ;-P -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Hi, Joel Roth writes: > Katolaz wrote on March 2, 2018: > >> leloft wrote: > >> >> I issued $locate systemd >> and got 200 lines of output, including >> /etc/systemd/system/* (23 files) >> /lib/systemd/system/* (60 files) >> /lib/x86_64-linux-gnu/libsystemd.so.0 (and 0.17.0) >> /usr/lib/systemd (25 files) >> /usr/bin/deb-systemd-helper ((and deb-systemd-invoke) >> /var/lib/systemd/deb-systemd-helper-enabled/* (68 files) >> /var/lib/dpkg/info/libsystemd):amd64* (5 files) >> >> This seems a lot to me. Please could you confirm that an ascii >> installation should contain 200 systemd files as part of a normal >> ascii installation. Sorry to trouble you if these are trivial >> questions, but they feel far from that. >> Many thanks >> leloft > > Most of those "alarming" files are just systemd units files, put there > by daemons/packages/utilities who "also" support systemd in a way or > another. So they are not alarming but just *totally* *harmless* if you > don't have a running systemd as PID 1, since only systemd understands > and can run them. It would be *totally* *useless* (and utterly > *stupid* IMHO) to fork, rebuild, and maintain a few more hundred > packages only because they happen to provide a systemd unit file for > those systems where systemd is used. Actually, you can keep these files off your systems fairly easily without the need to fork, rebuild and maintain piles of packages. The idea is to exploit the power of dpkg's --path-exclude option. Please note that the dpkg(1) manual page says Warning: take into account that depending on the excluded paths you might completely break your system, use with caution. So if you try this and stuff breaks you get to keep the pieces ;-/ You can add a /etc/dpkg/dpkg.cfg.d/systemd-razor file that contains path-exclude globs for all the systemd files you want to get rid of like so path-exclude=*systemd* path-include=/etc/dpkg/dpkg.cfg.d/systemd-razor although you might just want to be a bit more subtle ;-) # See dpkg.cfg(5) for (scant) details. The above prevents installation of any new "offending" files (while keeping the systemd-razor file installed, doh). To get rid of files already installed, you can retro-actively apply the above on what's installed already like so-ish find / -name '*systemd*' ! -name systemd-razor -delete with appropriate privileges, i.e. as root. Please adjust if you used a more (set of) exclude patterns. People that want to do so can do this themselves rightaway and Devuan *could* add this dpkg.cfg.d file to a suitable package (and the find invocation in that package's postinst). The latter only after a good deal of testing of course. Disclaimer: None of the above has been tested (although I do use this approach to clean out /usr/share/doc in my devuan/slim Docker images, see https://gitlab.com/paddy-hack/devuan). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)
Hi, KatolaZ writes: > The medium-term plan is to replace libsystemd0 with a libnosystemd > which Provides: libsystemd0 and noops everything, with the possibility > of shelling-out some actions, if the admin wants so. We will get > there. +1, although I'd prefer a more original and playful name ;-) # Not that I have any bright ideas right now :-( d-systemized ... perhaps For the library stubs and the [dpkg.cfg hack][1] I posted just a minute or so ago? Dang! Should have retitled that post :-( [1]: https://lists.dyne.org/lurker/message/20180726.123546.eacb6518.en.html Anyway, most of this is just cosmetic surgery as long as systemd itself stays out of the system. And systemd-boot, nee gummiboot, out of the installer as well. BTW, the cosmetic surgery angle might be a nice avenue to explore for package names! # init-freedom-botox ... :-\ # Maybe just plain init-freedom? Remember, coming up with a neat name is half the fun of an open source software project ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Hi, KatolaZ writes: > On Thu, Jul 26, 2018 at 12:45:53PM +0200, info at smallinnovations dot nl > wrote: >> On 26-07-18 12:15, KatolaZ wrote: >> > >> > The libsystemd API does not provide any way to check *which* init >> > system is running (ehm...for "obvious" reasons, right?). But we could >> > put in place a mechanism that allows to shell out the calls to >> > libsystemd functions to a set of scripts with pre-defined names. Then, >> > the system administrator or the packagers can put whatever they want >> > in those scripts, or even remove them altogether. >> > >> > This would in principle allow people to "catch" systemd-related events >> > and "translate" them to events for any other init system, using a >> > simple mechanism. Or just plainly ignore them, if they like... >> > >> Of course does the libsystemd API not provide it, but we can. First call >> to libsystemd API == systemd installed? If no, call to libnosystemd API >> which init system == installed? Or something like that. But put in place >> a mechanism that allows to shell out the calls to libsystemd functions >> to a set of scripts with pre-defined names would make libnosystemd far >> more useful imo. Especially for developers. >> > But that would entail forking and patching all the packages which use > libsystemd to force them to check if systemd is available... which is > exactly what we are trying to avoid by nooping libsystemd0... :P Exactly. Any package that Provides: libsystemd0 is *not* at liberty to change that library's documented API. No matter how much you may dislike that API and whatever it stands for, you either provides an API compliant replacement OR you end up forking every package that depends on libsystemd0. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)
Hi, Minor correction in-lined below. Olaf Meeuwissen writes: > Hi, > > KatolaZ writes: > >> The medium-term plan is to replace libsystemd0 with a libnosystemd >> which Provides: libsystemd0 and noops everything, with the possibility >> of shelling-out some actions, if the admin wants so. We will get >> there. > > +1, although I'd prefer a more original and playful name ;-) > > # Not that I have any bright ideas right now :-( > > d-systemized ... perhaps > > For the library stubs and the [dpkg.cfg hack][1] I posted just a minute > or so ago? Dang! Should have retitled that post :-( > > [1]: https://lists.dyne.org/lurker/message/20180726.123546.eacb6518.en.html > > Anyway, most of this is just cosmetic surgery as long as systemd itself > stays out of the system. And systemd-boot, nee gummiboot, out of the > installer as well. BTW, the cosmetic surgery angle might be a nice > avenue to explore for package names! > > # init-freedom-botox ... :-\ > # Maybe just plain init-freedom? I just realized that true init-freedom should be systemd-inclusive, so don't put that dpkg-cfg hack in any kind of "init-freedom" package, please. > Remember, coming up with a neat name is half the fun of an open source > software project ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UFW - ERROR: problem running ufw-init
Hi Ozi, Ozi Traveller writes: > Hi > > I seem to be getting a mismatch with ufw and inux-image-4.9.0-7-amd64 > Has anyone else noticed this? No but I don't use ufw ;-) > http://deb.devuan.org/merged ascii/main amd64 linux-image-4.9.0-7-amd64 > http://deb.devuan.org/merged ascii/main amd64 ufw all 0.35-4 > > I: Enable ufw > I: ufw reject incoming > ERROR: problem running ufw-init > modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not > open moddep file '/lib/modules/4.9.0-6-amd64/modules.dep.bin' Looks like something is telling someone to look in the *wrong* modules directory. Should be 4.9.0-7-amd64 if you ask me. Any chance you (or some add-on package) have made configuration changes that use a hard-coded kernel version? The ufw package files don't mention 4.9 anywheren nor do they use uname anywhere. The latter might have been used to embed a hard-coded kernel version. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rsync variant
Hi, Hendrik Boom writes: > On Sun, Aug 26, 2018 at 06:05:39PM +0900, Olaf Meeuwissen wrote: >> Hendrik Boom writes: >> >> > On Sat, Aug 25, 2018 at 12:39:11PM -1000, Joel Roth wrote: >> >> Is there a reason not to use `rsync -n` ? >> > >> > Ahhh... That's what -n is for. I missed it looking through the man page. >> >> And if you want to see the differences, you may be interested in rdiff. >> Haven't used it myself but sound (and looks) like it fits your bill. > > That's just what I thought... but the man page I have for rdiff says nothing > about how to compare files between systems... Could it be that the man page > s defective? At the very least not particularly helpful. Just spent five minutes trying to get it do something halfway useful. No such luck. The -h output is not much better than the manual page :-( Sorry for wasting your time. > Or should I lodge a bug report against the man page? That might help, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rsync variant
Hendrik Boom writes: > On Sat, Aug 25, 2018 at 12:39:11PM -1000, Joel Roth wrote: >> Is there a reason not to use `rsync -n` ? > > Ahhh... That's what -n is for. I missed it looking through the man page. And if you want to see the differences, you may be interested in rdiff. Haven't used it myself but sound (and looks) like it fits your bill. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] util-linux needs an upgrade on ceres
Hi Dan, On 2018-08-04 Daniel Reurich wrote: > I'll endeavor to get that sorted in the next couple of days... I know you've been and probably are still busy running around doing other stuff for Devuan, but the issue below is still present. The builds bombed again yesterday ... > On 04/08/18 01:42, Olaf Meeuwissen wrote: >> My monthly Devuan Docker image rebuild bombed today on ceres[1]. The >> base images for jessie, ascii and beowulf(!) built just fine. >> >> Looking into this, I found this in the debootstrap.log >> >> dpkg: dependency problems prevent configuration of util-linux: >>login (1:4.5-1.1) breaks util-linux (<< 2.32-0.2~) and is installed. >> Version of util-linux to be configured is 2.27.1-1+devuan0.1. >> >> Looks like util-linux needs a bit of tender loving care on ceres. >> >> [1]: https://gitlab.com/paddy-hack/devuan/pipelines/27093166 >> >> Hope this helps, >> -- >> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 >> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 >> Support Free Softwarehttps://my.fsf.org/donate >> Join the Free Software Foundation https://my.fsf.org/join >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please, provide a means to remove the default wallpapers.
Hi Jochen, J. Fahrner writes: > Am 2018-03-11 02:09, schrieb Olaf Meeuwissen: >> The problem is that desktop-base has an explicit Depends: on >> clearlooks-phenix-darkpurpy-theme where alternatives could be provided >> or a meta-package to pull in a theme so that admins can control the >> system-wide default more easily. > > I do not know a distribution that offers a selection of themes during > the installation. Why should Devuan put work here? If you do not like > the theme, you can customize it yourself or choose a different > distribution. Hey, I said I like the theme! Cut me some slack ;-) I just tried to point out why things happen the way they do and suggest how that could be improved. If someone want to do the legwork and feed that back to Devuan, fine. If not, you won't hear me complain. If something like I suggested does get in, it may be one more reason to choose Devuan because it allows you to opt out of its default theme ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Xfce clock visibility with darkpurpy (was Re: Please, provide a means to remove the default wallpapers.)
Hi, goli...@dyne.org writes: > On 2018-03-11 00:29, Olaf Meeuwissen wrote: >> Hi again, >> [...] >> Apart from getting the clock in the Xfce systemtray to display in a >> colour that contrasts with the darkpurpy theme rather than the dark >> shade of grey that is used now. > > Remove the default clock from the panel and install the Orage clock from > the repos instead. It has nice config options that allow for foreground > and background color choice. As far as making that the default option . > . . let me talk to Centurion_Dan about that. It's not really a priority > in the grand scheme of things but the suggestion could at least be > included in some release notes for the final release. All I want/need is the time to display in the system tray so I don't have to go find a wall clock. Why would I need a full-blown calendar application to do so? # That's a rhetorical question, btw. I do my agenda and task scheduling with Org-mode so have no real need for Orage. The only reason I still have it installed is because I've been too lazy to get serious about APT::Install-Recommends=false and ditch the task-xfce-desktop and xfce4 meta-packages :-P # Guess I should tell emacs to display the time in its mode line ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xfce clock visibility with darkpurpy (was Re: Please, provide a means to remove the default wallpapers.)
Hi, KatolaZ writes: > On Sun, Mar 11, 2018 at 09:43:40PM +0900, Olaf Meeuwissen wrote: > > [cut] > >> >> I do my agenda and task scheduling with Org-mode so have no real need >> for Orage. The only reason I still have it installed is because I've >> been too lazy to get serious about APT::Install-Recommends=false and >> ditch the task-xfce-desktop and xfce4 meta-packages :-P >> > > Man, if you are using org-mode, why on Earth do you need to leave your > eyes from emacs just to look at the clock?!?!? o_O > > :D Because I don't live all of my hacking hours in Emacs ;-P >> # Guess I should tell emacs to display the time in its mode line ;-) > > E...you mean you don't have it enabled? o_O There's only so much that fits ... > > (setq display-time-day-and-date t > display-time-24hr-format nil) > (setq display-time-default-load-average nil) > (display-time) > Thanks. Also for the dzen2 suggestion. Florian's suggestion would work nice in a terminal too, but having a clock in the terminal, as well as the emacs mode-line and somewhere on the screen feels like overkill. Just a single clock in a fixed location that's visible no matter what application you happen to be using, that's what I want. Anyway, thanks for all the feedback. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xfce clock visibility with darkpurpy (was Re: Please, provide a means to remove the default wallpapers.)
Hi, goli...@dyne.org writes: > On 2018-03-11 07:43, Olaf Meeuwissen wrote: >> Hi, >> >> goli...@dyne.org writes: >> >>> On 2018-03-11 00:29, Olaf Meeuwissen wrote: >>>> Hi again, >>>> [...] >>>> Apart from getting the clock in the Xfce systemtray to display in a >>>> colour that contrasts with the darkpurpy theme rather than the dark >>>> shade of grey that is used now. >>> >>> Remove the default clock from the panel and install the Orage clock >>> from >>> the repos instead. It has nice config options that allow for >>> foreground >>> and background color choice. As far as making that the default option >>> . >>> . . let me talk to Centurion_Dan about that. It's not really a >>> priority >>> in the grand scheme of things but the suggestion could at least be >>> included in some release notes for the final release. >> >> All I want/need is the time to display in the system tray so I don't >> have to go find a wall clock. Why would I need a full-blown calendar >> application to do so? >> > > I never realized that Orage is a "full-blown" calendar app because I > have no need for one. I can live with a bit of useless bloat to solve a $ apt-cache show xfce4-datetime-plugin orage | grep ^Installed Installed-Size: 261 Installed-Size: 5573 You call that "a bit of useless bloat"? ;-) # Me once again makes a mental note to purge unused packages ... but at # the same time wonders when I actually get around to doing so ... > cosmetic problem but the choice is of course yours. That's what it's is > all about . . . "Software freedom your way". Everyone has different > preferences and ways to solve them. Diversity is a good thing. :) ACK, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xfce clock visibility with darkpurpy (was Re: Please, provide a means to remove the default wallpapers.)
Hi, goli...@dyne.org writes: > On 2018-03-11 07:43, Olaf Meeuwissen wrote: >> Hi, >> >> goli...@dyne.org writes: >> >>> On 2018-03-11 00:29, Olaf Meeuwissen wrote: >>>> Hi again, >>>> [...] >>>> Apart from getting the clock in the Xfce systemtray to display in a >>>> colour that contrasts with the darkpurpy theme rather than the dark >>>> shade of grey that is used now. >>> >>> Remove the default clock from the panel and install the Orage clock >>> from >>> the repos instead. It has nice config options that allow for >>> foreground >>> and background color choice. As far as making that the default option >>> . >>> . . let me talk to Centurion_Dan about that. It's not really a >>> priority >>> in the grand scheme of things but the suggestion could at least be >>> included in some release notes for the final release. >> > > I was a little slow to realize something . . . the default Xfce panel > background color is #EDECEB (off-white) so the darker font color works > on that. The problem only arises when the user has chosen a darker > color for the panel background (which I do). So it will be up to the > user to sort this out. I might post something on the forum about this. > > Apologies for the confusion. This made me realize something. I've set my panels to be transparent so the clock displays "directly" on the background ... doh! Guess my issue is of my own making but on purpy things were clearly visible. On darkpurpy you can see it only if you know where to look and look real hard. Anyway, thanks for the feedback, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Hi, Joel Roth writes: > Cups was sponsored by Apple, [...] Correction, Apple bought CUPS in February 2007 after they adopted it for inclusion in MacOS X in March 2002[1]. [1]: https://en.wikipedia.org/wiki/CUPS#History Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [j...@debian.org: [SECURITY] [DSA 4139-1] firefox-esr security update]
Hi KatolaZ, KatolaZ writes: > As many of us, I keep receiving DSAs. And as usual, we should be > covered on these ones. If you think it might be useful, I might > forward DSAs here. Or maybe somebody here would like to take care of > putting together a summary of DSAs once a forthnight or so? That might > be useful. I'm one of those many and not just because I still have an odd Debian machine running. I also keep getting them because I know that Devuan will get most of its security upgrades straight from Debian anyway. However, using a simple web search (using Duck Duck Go, if that matters) I cannot seem to easily find anything on a Devuan website that clearly spells this out. Perhaps that is something that can be improved? The landing page lists deb http://auto.mirror.devuan.org/merged jessie-security main in the Packages section but there's no mention of how Devuan handles security issues. A link to https://devuan.org/os/security/ on the landing page as well as a blurb on that security page explaining how things work would go a long way? Personally, I have no problem with *not* getting duplicates of Debian's DSAs. Then again, I also have no real problem with getting them ;-) # Already get "duplicates" from Ubuntu as well :-/ What I'd definitely do like to see is Devuan Security Announcements for the *forked* packages. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Hi Didier, Didier Kryn writes: > Le 16/03/2018 à 09:19, Olaf Meeuwissen a écrit: >>> This is getting off the topic in the subject line, [...] >> Indeed;-) >> >>> In PostScript, I don't readily find any built-in operators that could >>> give a result that differs on every run, so you probably have to >>> inject suitable arguments for srand from outside sources. PostScript >>> can read data from files, so you could have a large file of seeds, and >>> read a new seed for each simulation. >> If it can read data from files, have it read from /dev/urandom! After >> all, in Unix everything's a file:-) > > Not sure I understand everything here: PS is meant to be processed > by the cpu of the printer. Not sure it is running any *nix OS. Don't > even know how it can read a file. My bad! If the PS is processed on the printer then all bets are off. If it is processed on host to convert it to something a non-PS printer groks, it ought to work (modulo being able to read partial files). But then again, you were all talking about PS printers, IIRC. Sorry, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please, provide a means to remove the default wallpapers.
Hi, goli...@dyne.org writes: > This is the best answer of all. > > Yes, just remove desktop-base to eliminate all styling you find > objectionable and recreate it as you wish. Seems a bit drastic just to get rid of the default theme. On my system this wants to remove 438 packages covering most if not all of Xfce, the only desktop I have installed. The problem is that desktop-base has an explicit Depends: on clearlooks-phenix-darkpurpy-theme where alternatives could be provided or a meta-package to pull in a theme so that admins can control the system-wide default more easily. That said, I like darkpurpy so have no intent to improve the current situation. > On 2018-03-10 07:14, Chillfan wrote: >> One way to remove it all would be: >> >> apt-get purge desktop-base >> >> Or don't install it to begin with. >> >> Try the xfce gradient wallpaper, which is blue. Or.. >> >> apt-get install gimp >> >> ‐‐‐ Original Message ‐‐‐ >> >> On March 9, 2018 8:34 AM, Edward Bartolo edb...@gmail.com wrote: >> >>> Dear All, >>> >>> I would like to ask the Devuan Distribution to provide a means to >>> permanently remove the purple wallpapers (golinux's creation). I would >>> like to have either wallpapers that users can individually choose or >>> some light blue/green gradient wallpapers. >>> >>> Thank you all. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please, provide a means to remove the default wallpapers.
Hi again, Olaf Meeuwissen writes: > Hi, > > goli...@dyne.org writes: > >> This is the best answer of all. >> >> Yes, just remove desktop-base to eliminate all styling you find >> objectionable and recreate it as you wish. > > Seems a bit drastic just to get rid of the default theme. On my system > this wants to remove 438 packages covering most if not all of Xfce, the > only desktop I have installed. Sorry, I have set APT::Get::AutomaticRemove to true, hence the large number of packages to be removed. When set to false, the default, it's only three. desktop-base task-desktop task-xfce-desktop > The problem is that desktop-base has an explicit Depends: on > clearlooks-phenix-darkpurpy-theme where alternatives could be provided > or a meta-package to pull in a theme so that admins can control the > system-wide default more easily. > > That said, I like darkpurpy so have no intent to improve the current > situation. Apart from getting the clock in the Xfce systemtray to display in a colour that contrasts with the darkpurpy theme rather than the dark shade of grey that is used now. >> On 2018-03-10 07:14, Chillfan wrote: >>> One way to remove it all would be: >>> >>> apt-get purge desktop-base >>> >>> Or don't install it to begin with. >>> >>> Try the xfce gradient wallpaper, which is blue. Or.. >>> >>> apt-get install gimp >>> >>> ‐‐‐ Original Message ‐‐‐ >>> >>> On March 9, 2018 8:34 AM, Edward Bartolo edb...@gmail.com wrote: >>> >>>> Dear All, >>>> >>>> I would like to ask the Devuan Distribution to provide a means to >>>> permanently remove the purple wallpapers (golinux's creation). I would >>>> like to have either wallpapers that users can individually choose or >>>> some light blue/green gradient wallpapers. >>>> >>>> Thank you all. > > Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] golang and emacs
Hi Hendrik, Hendrik Boom writes: > Anyone know the proper thing to make emacs edit go language code properly? > > i.e, use proper indentation and so forth? There's a go-mode package on melpa-stable. See https://github.com/dominikh/go-mode.el Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] DSA openssl openssl1.0
Hi leloft,
leloft writes:
> Hi devs,
>
> I am having difficulties finding the security update for the openssl1.0
> package (Debian Security Advisory DSA-4158-1 addressing CVE-2018-0739)
>
> There is no problem with openssl:
> Debian package openssl: stretch (libs): 1.1.0f-3+deb9u2
>
> Issuing
> # apt-cache policy openssl | grep -B 1 ascii
> returns
>
> 1.1.0f-3+deb9u2 500
> 500 http://pkgmaster.devuan.org/merged ascii-security/main
> amd64 Packages
> 100 http://pkgmaster.devuan.org/merged
> ascii-proposed-updates/main amd64 Packages
> 1.1.0f-3+deb9u1 500
> 500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
>
>
> But when I do the same for openssl1.0, I am getting confusing results
Eh , there does not appear to be an openssl1.0 binary package, only a
source package. From what I recall seeing on the list, you have added
deb-src lines to your "CVE checking setup", but are you sure apt-cache
policy pays any attention to the Sources files that get downloaded?
I don't think it does, for if it did, I would have expected output for
openssl with a "Sources" at the end of the line, just like you have the
"Packages" at the end of line above.
Try searching for libssl1.*, as in
apt-cache policy libssl1.*
That will probably give you the info you're looking for.
FWIW, on my pure ascii system (without deb-sources lines) I get
$ apt-cache policy libssl1.*
libssl1.0-dev:
Installed: (none)
Candidate: 1.0.2l-2+deb9u3
Version table:
1.0.2l-2+deb9u3 500
500 http://deb.devuan.org/merged ascii-security/main amd64 Packages
1.0.2l-2+deb9u2 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
libssl1.1:
Installed: 1.1.0f-3+deb9u2
Candidate: 1.1.0f-3+deb9u2
Version table:
*** 1.1.0f-3+deb9u2 500
500 http://deb.devuan.org/merged ascii-security/main amd64 Packages
100 /var/lib/dpkg/status
1.1.0f-3+deb9u1 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
libssl1.0.0:
Installed: 1.0.1t-1+deb8u7
Candidate: 1.0.1t-1+deb8u7
Version table:
*** 1.0.1t-1+deb8u7 100
100 /var/lib/dpkg/status
libssl1.0.2:
Installed: 1.0.2l-2+deb9u3
Candidate: 1.0.2l-2+deb9u3
Version table:
*** 1.0.2l-2+deb9u3 500
500 http://deb.devuan.org/merged ascii-security/main amd64 Packages
100 /var/lib/dpkg/status
1.0.2l-2+deb9u2 500
500 http://deb.devuan.org/merged ascii/main amd64 Packages
> [...]
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] lsb_release on ascii
Hi, wirelessd...@gmail.com writes: >> On 17 Apr 2018, at 06:34, aitor_czr <aitor_...@gnuinos.org> wrote: >> >> The output of 'lsb_release -a' is defined in the 'base-files' package. So, >> for the same version of the package, you should get the same output. The >> command needs the 'lsb-base' package to work, i think. > > I just checked and both machines have both packages installed at the same > version. > > base-files: 9.9+devuan2.3 > lsb-base: 4.1+devuan2 > > I noticed this problem was occurring when I added Devuan support to the > official nodejs installer script which relies on output of “lsb_release -c > -s”. > > Running that command on the devuan2 machine will return “ascii” while running > it on devuan1 returns “n/a”. I get the same 'n/a' with the same versions of base-files and lsb-base. FTR, lsb-release has the same version as lsb-base. I've been poking around in the Python source code for the lsb_release command and noticed a code path that sources the output of apt-cache policy and looks for entries that have a label of Devuan, component of main and origin of Devuan (or an alternative that mentions packages.devuan.org and Devuan Ports). My `apt-cache policy` output does not match any of that so I *think* that's why I get an 'n/a' for the codename. # The code is a bit hard to follow which is why I am not sure :-/ Any chance the `apt-cache policy` output on your machines is different in a way that would explain the behaviour you see? Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] lsb_release on ascii
Hi Tom, Looks like we're on to something! Tom writes: > On 17 April 2018 at 22:17, Olaf Meeuwissen <paddy-h...@member.fsf.org> wrote: > >> I get the same 'n/a' with the same versions of base-files and lsb-base. >> FTR, lsb-release has the same version as lsb-base. >> >> I've been poking around in the Python source code for the lsb_release >> command and noticed a code path that sources the output of >> >> apt-cache policy >> >> and looks for entries that have a label of Devuan, component of main and >> origin of Devuan (or an alternative that mentions packages.devuan.org >> and Devuan Ports). >> >> My `apt-cache policy` output does not match any of that so I *think* >> that's why I get an 'n/a' for the codename. >> >> # The code is a bit hard to follow which is why I am not sure :-/ >> >> Any chance the `apt-cache policy` output on your machines is different >> in a way that would explain the behaviour you see? >> >> Hope this helps, > > On the machine that returns "n/a" for "lsb-release -c -s", it has the > following apt policy: > > # apt-cache policy > Package files: > 100 /var/lib/dpkg/status > release a=now > 500 http://deb.devuan.org/merged ascii-updates/main amd64 Packages > release v=2.0.0,a=testing-updates,n=ascii-updates,l=Devuan,c=main,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii-security/non-free amd64 Packages > release > v=2.0,a=testing-security,n=ascii-security,l=Devuan-Security,c=non-free,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii-security/main amd64 Packages > release > v=2.0,a=testing-security,n=ascii-security,l=Devuan-Security,c=main,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii/main amd64 Packages > release v=2.0,a=testing,n=ascii,l=Devuan,c=main,b=amd64 > origin deb.devuan.org > Pinned packages: This is pretty much the same as what I see. Note the absence of an `o=...` entry in this output. > On the other machine that returns "ascii" for "lsb-release -c -s", it > seems to have included packages.devuan.org in there: > > # apt-cache policy > Package files: > 100 /var/lib/dpkg/status > release a=now > 500 http://packages.devuan.org/merged ascii/non-free amd64 Packages > release v=2.0,o=Devuan,a=testing,n=ascii,l=Devuan,c=non-free,b=amd64 > origin packages.devuan.org > 500 http://packages.devuan.org/merged ascii/main amd64 Packages > release v=2.0,o=Devuan,a=testing,n=ascii,l=Devuan,c=main,b=amd64 > origin packages.devuan.org Note the *presence* of an `o=Devuan` entry for the ones above and the *absence* or such an entry for the ones below! > 500 http://deb.devuan.org/merged ascii-updates/main amd64 Packages > release v=2.0.0,a=testing-updates,n=ascii-updates,l=Devuan,c=main,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii-security/non-free amd64 Packages > release > v=2.0,a=testing-security,n=ascii-security,l=Devuan-Security,c=non-free,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii-security/main amd64 Packages > release > v=2.0,a=testing-security,n=ascii-security,l=Devuan-Security,c=main,b=amd64 > origin deb.devuan.org > 500 http://deb.devuan.org/merged ascii/main amd64 Packages > release v=2.0,a=testing,n=ascii,l=Devuan,c=main,b=amd64 > origin deb.devuan.org > Pinned packages: > If I comment out the lines in /etc/apt/sources.list for > packages.devuan.org and then run "lsb-release -c -s", then it shows > "n/a". Uncommenting those lines again shows "ascii" for "lsb-release > -c -s". So the output of lsb_release may depend on one's APT sources rather than what is installed. Ouch! # Currently, it appears to depend on what is in the Origin field of the # *_InRelease files for one's sources. The one for deb.devuan.org does # not have that field. It should just use what the base-files package installed, unless the sysadmin (or some other package?) overrides it in an /etc/lsb-release file. It should *not* depend on the APT sources du jour as they have no direct bearing on what is installed when one runs lsb_release. Hoping this gets fixed sooner rather than later, I Cc:d the maintainer of the lsb-release package which provides the lsb_release command. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Unbootable system due to cryptsetup depending to two libs in /usr
Hi, fsmithred writes: > On 04/01/2018 10:29 AM, Klaus Ethgen wrote: >> Hi, >> >> Am So den 1. Apr 2018 um 15:14 schrieb fsmithred: >>>> In fact, debian did intentional break libpopt as the version in ascii >>>> installs to /lib but the version in ceres installs to /usr. >> [...] >>> Nothing installs to /lib anymore, because it's just a symlink to /usr/lib. >>> You can get this on ascii with a debootstrap install. >> >> Well, that is only true if you have the pöttering usrmerge package >> installed. If you do a minimal ascii bootstrap, you don't get infected >> by that package. >> >> The pöttering followers invented that to break all installations with >> separate /usr. In fact, that package damages your whole system >> sustainably. >> >> Regards >>Klaus >> -- > > The usrmerge package is not installed here. I can't find it mentioned in > apt history or bootstrap.log. It's only in buster/beowulf and sid/ceres. > Guess I'll have to do another debootstrap of ascii and see if it's still > happening. FTR, debootstrap has --merged-usr and --no-merged-usr options, with the latter documented[1] as the default, since jessie-backports (which has debootstrap-1.0.89). [1]: https://manpages.debian.org/debootstrap Not one to overly rely on default for "stuff that matters", my Devuan Docker image build scripts explicitly specify it in their debootstrap invocation[2]. Please note that these runs in a Debian jessie container that has been migrated to Devuan and uses debootstrap-1.0.87 which also has these options. [2]: https://gitlab.com/paddy-hack/devuan/blob/master/bootstrap.sh#L18 Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Error when updating ascii 32 bit
Hi, Saw the same on ascii amd64 yesterday, trying to upgrade eudev from 3.2.2-11 to 3.2.2-12. KatolaZ writes: > On Sat, Mar 17, 2018 at 02:56:03PM -0400, Ismael L. Donis Garcia wrote: >> When updating my system I get the following error of which I have not the >> slightest idea how to solve: >> >> Configurando eudev (3.2.2-12) ... >> insserv: script eudev: service udev already provided! >> [ ok ] Stopping the hotplug events dispatcher: udevd. >> [ ok ] Starting the hotplug events dispatcher: udevd. >> >> *** >> Warning: eudev will default to the older network >> interface names, such as eth0 or wlan0. If you use >> the new names, such as enp0s3, you will need to add >> the following to the boot command: >>net.ifnames=1 >> >> >> update-initramfs: deferring update (trigger activated) >> insserv: script eudev: service udev already provided! >> insserv: exiting now! >> update-rc.d: error: insserv rejected the script header >> dpkg: error al procesar el paquete eudev (--configure): >> el subproceso instalado el script post-installation devolvió el código de > > You have a previous version of "udev" in /etc/init.d/, or a link to > eudev named "udev" in there. That was a required fix for a previous > problem that has been solved, Just remove the udev file (or link) and > > apt-get upgrade > > again. I found /etc/init.d/udev and /etc/init.d/udev-finis files, not links. According to `dpkg -S etc/init.d/udev` they belong to the udev package (1:3.2.2+devuan2.10) so I purged that. This didn't remove any other packages because eudev provides udev. This also did *not* remove the files in /etc/init.d. During the `apt-get purge udev`, I saw: dpkg: udev: dependency problems, but removing anyway as you requested: bluez depends on udev (>= 170-1); however: Package udev is to be removed. Package eudev which provides udev is not configured yet. [...] (Reading database ... 129383 files and directories currently installed.) Removing udev (1:3.2.2+devuan2.10) ... Setting up eudev (3.2.2-12) ... insserv: script eudev: service udev already provided! [ ok ] Stopping the hotplug events dispatcher: udevd. [ ok ] Starting the hotplug events dispatcher: udevd. *** Warning: eudev will default to the older network interface names, such as eth0 or wlan0. If you use the new names, such as enp0s3, you will need to add the following to the boot command: net.ifnames=1 update-initramfs: deferring update (trigger activated) insserv: script eudev: service udev already provided! insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing package eudev (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: eudev After the purge, I still had a /var/lib/dpgk/info/udev.list that contained: /etc/modprobe.d/fbdev-blacklist.conf /etc/init/udev.conf /etc/init/udev-finish.conf /etc/init/udevtrigger.conf /etc/init/udevmonitor.conf /etc/init/udev-fallback-graphics.conf /etc/init.d/udev /etc/init.d/udev-finish and all of these files still existed on my system. I ran for f in `cat /var/lib/dpkg/info/udev.list`; do sudo rm $f; done sudo rm /var/lib/dpkg/info/udev.list sudo dpkg --configure eudev and that allowed eudev to configure itself without error. I realize that ascii is not quite ready for release yet, but I do believe that the (e)udev installation scripts should provide users with a *smooth* upgrade. Hope this helps and keep up the good work, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Solved with Jessie netinst, but not Ascii. [Was: Re: Does devuan install from USB really need a CDROM?
Hi, Erik Christiansen writes: > On 20.03.18 15:26, Florian Zieboll wrote: >> >> On Tue, 20 Mar 2018 19:58:08 +1100 >> Erik Christiansen <dva...@internode.on.net> wrote: >> >> > "isolinux.bin missing or corrupt. >> > DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER" >> >> That looks like you used some 3rd-party tool like unetbootin to create >> the boot-stick. The easiest way, as stated by Didier Kryn earlier in >> this thread, would be to simply 'dd' the iso to the raw device. > > I first thought "Ah goody, mistakes are fine so long as I learn from > them.", but then I did a ^r on the commandline to check, and found: > > (reverse-i-search)`dd': dd > if=~/Downloads/devuan_ascii_2.0.0-beta_i386_NETINST.iso of=/dev/sdb1 > bs=512k Shouldn't that be of=/dev/sdb, without the 1? But last time I copied an installer ISO to a stick, I simply used the cp command. See https://www.debian.org/releases/stable/amd64/ch04s03.html.en > There had been debian 9 on that stick, placed with unetbootin, but I'd > expected the dd to fully overwrite it. I might try doing it all again, > after I overcome a more immediate problem. > > The dd of Jessie netinst did copy OK, and install, but there's a boot > problem with it, and I'll start another subthread to keep things > coherent. Boot problem, you say? Well it might be just that you've put the image in the first partition of the stick rather than on the stick itself. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Command to permanently prevent sysvinit from starting daemon
Hi, Bruce Ferrell writes: > [...] > > If I understand the original question "how to I get sysV init to not > start a process present in the init system", There is a command, > chkconfig: Make that: "there *was* a command, chkconfig:" It's no longer present in Debian stable (stretch) and later. You can still find it in oldstable (jessie) though. See https://packages.debian.org/search?arch=any=contents=chkconfig # Searching in unstable (sid) lists the command for a small subset of # architectures but a chkconfig package does not seem to exist ... Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan + remote desktop of Ubuntu = how?
Arnt Karlsen writes: > On Sun, 21 Oct 2018 00:05:55 +1100, wirelessd...@gmail.com wrote in > message <6ec111c6-d733-4e15-a944-e2419b63c...@gmail.com>: > >> > >> > For Ubuntu there is Remina or like (if I recall the proper name) >> > but duno what needs for Devuan. >> > >> > Misko >> >> Remains is also available from ascii-backports. > > ..you mean remmina? https://en.wikipedia.org/wiki/Remmina > https://packages.debian.org/search?keywords=remmina > https://manpages.debian.org/stretch-backports/remmina/remmina.1.en.html FYI, I use remmina occasionally on Devuan Ascii machines running the default Xfce desktop. Accessing a Windows VM over RDP at the office works without a hitch. For access to other Linux boxen you may have to convince their sshd to do X11 forwarding (probably enabled by default) but once that's working you should have no problem showing their desktop on your Devuan machine using Remmina over SSH. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Speak now, or forever hold your peace
Hi, Jimmy Johnson writes: > On 10/23/18 3:58 PM, Steve Litt wrote: >> using logger to capture stdout and stderr > > Steve, I found this: > > https://unix.stackexchange.com/questions/124455/linux-how-to-redirect-stdout-stderr-to-logger > > What software do I need to install to follow you? Package 'logger' is a > bit obscure. On a Devuan system, none. The bsdutils package which includes the logger command as well as bash and dash are essential packages. These are always installed no matter how minimal your Devuan install is unless you go out of your way to remove them forcibly. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Everyone OK for using the logger program for runit logging?
Hi, KatolaZ writes: > On Tue, Oct 23, 2018 at 12:32:54PM -0400, Steve Litt wrote: > > [cut] > >> Ahh, the preceding explains why G. Pape says runit level logs are >> required on *some* daemons, but not others. If the daemon already >> performs meaningful syslog() calls, there's no reason for further >> logging. The logger program is needed only for those daemons not >> already doing syslog() calls. The set of programs not doing syslog >> calls includes all my home-grown daemons: Being a longtime daemontools >> guy, I just write warnings and errors to stderr and know >> daemontools/runit/s6/perp will get them into the logs. > > That's was exactly the aim of my previous question :) > >> So Didier: I amend my question to this: Is logger the best log >> mechanism to get stderr into the logs, for daemons not doing their own >> syslog() calls? >> >> [...] > > The fact that some daemons do not use a custom log does not mean that > they are not logging to syslog (notable examples include cron, > dhclient, sshd, and many other). > > If a daemon is not doing its syslog proper calls, redirecting the > stdout and stderr to logger could make sense (but a deamon is normally > expected to close stdout and stderr as soon as it is spawned, and use > syslog() calls for logging...). Redirecting to logger is probably the most portable solution as it does not make any assumptions as to which system-log-daemon is used. On my system I get $ apt-cache search system-log-daemon busybox-syslogd - Provides syslogd and klogd using busybox inetutils-syslogd - system logging daemon rsyslog - reliable system and kernel logging daemon syslog-ng-core - Enhanced system logging daemon (core) Of these, rsyslog is installed by default, at least on ascii. If you could assume rsyslog is always installed, binding the daemon's stdout and stderr to /dev/log would work fine too. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Command to permanently prevent sysvinit from starting daemon
Hi, Stephan Seitz writes: > On Di, Okt 23, 2018 at 08:16:51 -0400, Hendrik Boom wrote: >>On Tue, Oct 23, 2018 at 08:27:25PM +0900, Olaf Meeuwissen wrote: >>> Make that: "there *was* a command, chkconfig:" >>> >>> It's no longer present in Debian stable (stretch) and later. You can >>> still find it in oldstable (jessie) though. See >>> >>> >>> https://packages.debian.org/search?arch=any=contents=chkconfig >>> >>> # Searching in unstable (sid) lists the command for a small subset of >>> # architectures but a chkconfig package does not seem to exist ... >> >>Why would this have been removed? Is it no longer wanted for systemd >>users? Or is there some other, perhaps legitimately technical, reason >>for its removal? > > As far as I know chkconfig was never a Debian tool. I only know it from > RPM distros. I had the same impression. So much so actually, that I was going to reply that chkconfig was an RPM distro-only tool until I fact checked. > Maybe someone tried to include chkconfig in Debian, but gave > up later. Or it never really worked. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to get CERES
Hi Didier, Didier Kryn writes: > Le 28/10/2018 à 06:24, Olaf Meeuwissen a écrit: >>sed -i 's/ascii/ceres/' /etc/apt/source.list >>apt update >>apt upgrade > > Hi Olaf. > > Do you for sure mean 'apt upgrade' ? Because I would have thought > of 'apt dist-upgrade'. Whichever of the two does what you want it to :-P I was thinking of doing the above after a minimal install, i.e. a netinst without any desktop stuff. IIUC, Steve is looking for a setup to work on runit scripts so that would really be all that he'd need. Although I have not tried, I would think `apt upgrade` would do the job for that. # Looking at Steve's follow-up, maybe `apt upgrade` didn't do the whole # job after all ... :-( BTW, you can always do the `apt dist-upgrade` after that if you feel a need to do so. Personally, I prefer running `apt upgrade` first and deal with any packages that were not upgraded during that afterward, either via `apt dist-upgrade` or by specifying my own preferences to solve the issues (if I don't like what `apt dist-upgrade` wants to do). That said, I can't really remember the last time I used dist-upgrade. Hope this clarifies. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] XFCE : can't open xsession-errors anymore (invalid UTF-8)
Hi Hendrik, Hendrik Boom writes: > On Sun, Oct 28, 2018 at 11:31:56AM +0900, Olaf Meeuwissen wrote: >> >> # I never understand why folks use an editor to just look at a file. > > Maybe because muscle memory know the editor commands for finding things in it. I'll give you that but when folks are using GUI text editors I'm afraid that muscle memory is a click on a menu ;-P -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
