Re: [DNG] Adjusting LCD backlight in XFCE4
On Wed, May 17, 2017 at 11:26 AM, Lars Noodén wrote: > On 05/17/2017 06:08 PM, Rob Owens wrote: > > On Wed, May 17, 2017 at 8:48 AM, Lars Noodén > wrote: > > > >> On 05/04/2017 03:42 PM, Lars Noodén wrote: > >>> I'm having trouble adjusting the backlight on my LCD screen in RC 1 > with > >>> XFCE4. No matter what I've tried so far, it stays where it is. With > >>> Ubuntu 16.04, things are pre-configured and it is just a matter of > >>> pressing the right function buttons. However, with Devuan Jessie RC 1 > >>> the right commands are hard to figure out. > >>> > >>> Here is what I've tried so far to change the backlight intensity. None > >>> have any effect: > >>> > >>> $ xrandr --output default --brightness 0 > >>> xrandr: Gamma size is 0. > >> > > > > I did this just yesterday on a laptop running Funtoo with Fluxbox, where > > the built-in function keys for dimming did not work. But I specified a > > decimal, like this: > > > > xrandr --output default --brightness .7 > > > > That worked for me. Maybe the problem is that you specified zero for the > > brightness. > > Thanks for the reply. It seems that I cannot get anywhere with xrandr > on my system: > > $ xrandr --output default --brightness .7 > xrandr: Gamma size is 0. > $ xrandr --output default --brightness .1 > xrandr: Gamma size is 0. > $ xrandr --output default --brightness .9 > xrandr: Gamma size is 0. > $ xrandr --output default --brightness 1.9 > xrandr: Gamma size is 0. > $ xrandr --output default --brightness 2 > xrandr: Gamma size is 0. > $ xrandr --current > xrandr: Failed to get size of gamma for output default > Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080 > default connected 1920x1080+0+0 0mm x 0mm >1920x1080 77.00* > > Are there any preparations that need to be made first? > I didn't need to do anything except run that command, making sure to specify the correct video device. I ran 'xrandr' with no arguments to get a list of the devices on my laptop. I believe one of them said "connected" after it, so that's the one I used. Again, this was on a Funtoo system. Unfortunately I do not have a Devuan system available to test right now. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Adjusting LCD backlight in XFCE4
On Wed, May 17, 2017 at 8:48 AM, Lars Noodén wrote: > On 05/04/2017 03:42 PM, Lars Noodén wrote: > > I'm having trouble adjusting the backlight on my LCD screen in RC 1 with > > XFCE4. No matter what I've tried so far, it stays where it is. With > > Ubuntu 16.04, things are pre-configured and it is just a matter of > > pressing the right function buttons. However, with Devuan Jessie RC 1 > > the right commands are hard to figure out. > > > > Here is what I've tried so far to change the backlight intensity. None > > have any effect: > > > > $ xrandr --output default --brightness 0 > > xrandr: Gamma size is 0. > I did this just yesterday on a laptop running Funtoo with Fluxbox, where the built-in function keys for dimming did not work. But I specified a decimal, like this: xrandr --output default --brightness .7 That worked for me. Maybe the problem is that you specified zero for the brightness. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
I left Debian for Funtoo and Devuan. The reason was systemd. Debian paid lip service to the alternate init systems, but in reality systemd was slowly but surely becoming required. I left because it was clear they were going in a different direction than I wanted to follow. You can include me in your list if you want. But I think for a Debian user who is currently questioning the need for systemd, knowing his alternatives is much more useful than knowing that I (some guy they don't know) stopped using Debian. -Rob On Tue, Mar 14, 2017 at 9:37 PM, Steve Litt wrote: > Hi all, > > There's yet another systemd thread on Debian-User, started by a guy who > wrote an intelligent question about why there's no choice of init at > install time: > > https://lists.debian.org/debian-user/2017/03/msg00472.html > > After a little back and forth, a guy who claims to have used Linux for > 20 years without knowing there's more than one init system, and because > of his personal anecdote he thinks there shouldn't be a choice and says > "Please end this Diskussion and get on with important things." > > https://lists.debian.org/debian-user/2017/03/msg00514.html > > A few posts later, a guy basically says "put up or shut up" to the > proposition that the reason there's so little request for sans-systemd > in Debian is because those who don't like systemd moved on: > > https://lists.debian.org/debian-user/2017/03/msg00540.html > > Can somebody please make a list, that we can put our names on, of > people who left Debian because of systemd? And put the name Steve Litt > on it please. > > We have our quiet sans-systemd corners, and right now they're > comfortable, but remember that the Freedesktop/Redhat/SystemdCabal > consortium has the goal of eliminating systemd as a choice, and they > still have the power to take our init systems away from us, as a > practical matter, so we still need to tell the truth to bullshit like > that on the Debian-User list right now. Obviously there's a technical > component to software choice, but forget at your peril that there's > also a political component. > > Thanks, > > SteveT > > Steve Litt > March 2017 featured book: Troubleshooting: Why Bother? > http://www.troubleshooters.com/twb > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev status
On Thu, Dec 22, 2016 at 10:56:58AM -0500, Haines Brown wrote: > I installed jessie-beta on a disk some time ago, and off hand it boots > and runs just fine. However I didn't migrate it to from my current Debian > Wheezy because I was waiting for the eudev/vdev/udev issue to be > resolved, figuring that migrating up from present udev to one of the > others could well be traumatic. I didn't want to do it on a system > on which I relied for work. > > Two questions, if I may: > > Is eudev being actively worked on, and is it likely to be in > the upcoming non-beta Jessie Devuan? vdev was/is being developed by a Devuan user specifically with Devuan in mind. eudev, as others have already stated, is a Gentoo project. I'm not sure the status of vdev. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan-discuss is not useful, quite the opposite
A solution might be to: 1) rename this list if deemed necessary 2) route all devuan-discuss emails to dng This will combine the two lists without requiring users to make any changes. If the name change is deemed necessary, the new name can be promoted on the website, but the old email addresses will continue to work. At worst, existing users may need to update email filters to look for a "from address" of new_n...@devuan.org instead of dng@lists.dyne.org. On Tue, Nov 8, 2016 at 2:55 PM, Jaromil wrote: > > One thing I learned from Permaculture design principles, which somehow > deal very much with community and on many levels: never touch unless > you have a reason to. A single "I don't like" is too subjective and > won't ever become an executive reason nor decision. you can blow *me* > away if I'll ever do that, just by being one of the many stewards > having access to some servers. > > in order to leave space for our community to act organically, we'll > follow this principle and change as less as possible. back to dng: its > is an address we won't change just because one of us don't like it. > > meanwhile, the suggestion to notice devuan-discuss is good, lets do > that. thanks hellekin for carefully updating the website! > I also very much appreciate the talk.devuan.org documentation platform > and it is true that's better communicated as such, rather than a forum > > at last, just like with the friendsofdevuan wiki and other platforms, > if someone feels like volunteering time and gear to run a phpbb forum > in a reliable way, we surely won't overlook it, but include it in the > available options to get in touch and support it as we can. It can be > a fun adventure, but beware it may become very big > > > ciao > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] sans-dbus: was Mass bug filing: use and misuse of dbus-launch (dbus-x11)
On Mon, Sep 19, 2016 at 3:53 AM, Rick Moen wrote: > Quoting Joel Roth (jo...@pobox.com): > > On my system, > > > > apt-get -s remove dbus > > > > The following packages will be REMOVED: > > And what actually breaks if you use equivs to lie and say it's still > present? > I haven't tested on Devuan but on my Funtoo system, LightDM does not work unless dbus is started. Note that this is not a package dependency issue. Dbus is installed, but if it is not running prior to starting LightDM, LightDM will give me a black screen with a blinking cursor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openrc
On Fri, Sep 16, 2016 at 12:32 PM, Steve Litt wrote: > > Does OpenRC do the conditional starts? Yes, it does. See "The depend function" here: http://www.funtoo.org/Package:OpenRC ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: true read-only disk
On Thu, Aug 18, 2016 at 10:59 AM, Simon Hobson wrote: > OT, but there seem to be a few people who understand such in-depth stuff > here ;-) > > I'm in the process of recovering (with ddrescue) files of a failing drive > - no backups as "it's only TV" recordings and I can't afford the disk space > anyway. It's going better than I expected with most of the files (typically > anything between 1G and 4G in size) reading without any errors - retries on > the disk, but no actual read errors. > Tedious because when the drive warms up, it "goes titsup*" (producing lots > of DID_BAD_TARGET errors) and I have to unplug it and let it cool down > before restarting the recovery process. > I don't know the answer to your read-only question. But having done some data recovery in the past, I've found that attaching the drive via USB and sitting the drive in the freezer during recovery can help in situations like this. Also, besides ddrescue you can also take a look at photorec (part of the testdisk package). Good luck! -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - udev is a dead end
On Mon, Aug 15, 2016 at 8:34 AM, Simon Hobson wrote: > There was one other thing that came to mind earlier ... > If ${company} decided to do that, and they had previously distributed > binaries ... doesn't the GPL mean they are required to provide the sources > to anyone they've distributed the binaries to ? So removing the sources > from public repositories would actually be a breach of the GPL (given some > limitations regarding timing). > And that raises an interesting problem for other people distributing > binaries. If (say) I were distributing binaries for ${foo} and relying on > (say) a git repository for providing the source - where would that leave me > if those git sources suddenly disappear ? > Certainly something for anyone building systems to bear in mind. I know > lots of people who take the attitude - don't keep it, you can download it > again. > My understanding is that the source must be made available for 3 years after the last binary was made available. See Section 6: https://www.gnu.org/licenses/gpl.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On Tue, Jul 26, 2016 at 12:00 AM, Simon Walter wrote: > On 07/26/2016 12:28 PM, Brad Campbell wrote: > >> On 26/07/16 10:27, Simon Walter wrote: >> >> Is that really the case? Did the Debian leadership do a poll to find out >>> what their users wanted and who were their typical users? >>> Desktop/personal vs. server/professional? >>> >> > yes/no? > > I would have to say no. I was on debian-user, and saw no poll. There was a lot of discussion, and the anti-systemd folks were largely ignored or told "go away, you're bothering us". I subscribed to debian-devel to monitor and discuss the situation, but my impression there was that the opinions of non-developers were largely ignored. There were a couple people who I heard arguing for systemd because of some particular useful feature. But most of the arguments that I heard from developers in favor of systemd was that it would be too hard not to adopt systemd as default. We all know that systemd's plan all along has been to make resistance futile, so I won't get into that. But when somebody tries to tie my hands, I try to stop it. Unfortunately most of the Debian developers (at least the vocal ones) did not share my view. It was very disheartening to see, and it really changed my opinion of the project as a whole. For the record, I ran (past tense) Debian on desktops, laptops, and servers. The obvious attempt by systemd to make itself a requirement was the first thing that made me suspicious about the project. I've since become more informed on the issue of init systems and now have many technical reasons to dislike it as well. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Open-RC on devuan - some questions
On Mon, Jul 18, 2016 at 1:12 PM, wrote: > Hi! > > On the road to a viable jwm desktop in devuan, i am using/trying > open-rc. In advance, my excuses if what follows is not sufficiently > technical. > > To the point: From Manjaro-OpenRC i knew openrc as a clean and logical > system to manage daemons & processes. By far, from a user point of > view, superior to sysvinit. Now, the transition from sysvinit to openrc > in devuan is mostly painless. BUT: I'm under the impression in > devuan/debian openrc works only as a kind of wrapper around sysvinit. > > An example: I installed a zram script (still when i had sysvinit as > init manager). Now, this script is configured to openrc in this way: > > "rc-update add zram boot" (which adds the zram daemon to the boot level > to have it ready early; could be added also to default). Now, when i > remove it by "rc-update del zram boot" it is not even more present for > openrc - but nevertheless, it is still started at any reboot. For me, > that means, openrc is *NOT* the real init manager - at least in its > debian implementation. > You got me interested and I just installed OpenRC on Devuan Jessie. I got the following message: ** *** WARNING: if you are replacing sysv-rc by OpenRC, then you must *** *** reboot immediately using the following command:*** for file in /etc/rc0.d/K*; do s=`basename $(readlink "$file")` ; /etc/init.d/$s stop; done *** once rebooted, you could safely backup and remove /etc/rc?.d *** ** Did you follow those instructions? I found that before I removed /etc/rc?.d, I was still running sysv init (but most/all services did not start -- ssh for example). After a subsequent reboot, I was running OpenRC. I'm still testing it, though... > > It would be nice to have openrc implemented as it is in gentoo or > manjaro: with the to essential directories: > > /etc/conf.d (where all the scripts for openrc are configured) > /etc/init.d (where the scripts that are configured in /etc/conf.d sit) > I see I have no /etc/conf.d. To me this means I really do not have OpenRC, as conf.d is one of the key benefits of OpenRC in my opinion. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] F1 and special usernames on the login screen
On Mon, Jul 18, 2016 at 10:53 PM, Adam Borowski wrote: > Nowadays to find a regular person who doesn't own multiple computers, you > need to go to Africa or rural India. > > I'd say it's safe to assume that a person authorized to login on the > console > (either text or graphical) is supposed to be at least an operator, if not > the owner, of the machine. For weird setups like a kiosk you need to > configure access anyway. All that talk about multiseat being important > or even relevant today is IMO bullshit. > I can say with authority that multiseat doesn't have any value *for me*. I looked into it a long time ago and decided that LTSP was more straightforward. These days, prices of hardware have come down enough that other people replace their computers after only a few years and I get their hand-me-downs. This has made even LTSP not worth my while. But I have no idea what the situation is like for people in other parts of the world, or for people in my part of the world with fewer financial resources. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC
- Original Message - > From: emnin...@riseup.net > Is there a link to an instruction how to use (and setup) openrc > together with sysvinit? > > I'd like to use openrc as a tool to administrate daemons and services > since i find it a lot more "logical" (easy?). One question for example > is, if can be used the (needed) openrc scripts from other distros (like > Gentoo or Manjaro)? To form them on my one, i think that's far away > from my capabilities ... Here is a good link which explains OpenRC on Funtoo. I'm not sure how a Devuan implementation would differ. http://www.funtoo.org/Package:OpenRC One section that I think is very interesting: - The magic of conf.d Most init scripts need default values. It would be fragile to explicitly source some arbitrary files. By convention runscript will source the matching file in /etc/conf.d/ for any script in /etc/init.d/ So you can set random startup-related things easily. Example: conf.d/foo: START_OPTS="--extraparameter sausage" init.d/foo: start() { /usr/sbin/foo-daemon ${STARTOPTS} } The big advantage of this split is that most of the time editing of the init script can be avoided. - This says to me that the scripts in /etc/init.d could/should be standardized across distributions. Customization happens in the /etc/conf.d directory. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Signature verification
- Original Message - > From: "Paweł Cholewiński" > Hi List, > how to verify that SHA256SUMS file > (https://files.devuan.org/devuan_jessie_beta/) is not changed (how to > check its signature). In the directory which contains both the downloaded iso and the SHA256SUMS file, run this command: sha256sum --check SHA256SUMS That will output a check for each checksum in that file, so you will get a lot of "file not found" messages. Look for the one for your downloaded iso, which will hopefully say "OK". -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] booting old system on a different partition
- Original Message - > From: "Peter Olson" > So, I installed the Devuan beta a few days ago and it is great, rather it > almost > mostly works. I probably need an audio driver installed. I want to see what > the old system had installed. > > So I cleared out another partition and moved the backup of my Debian 8.3 onto > it. Ran update-grub, which found the backup in its new location. > > But, when I try to boot it grub is confused and is pinned to the old UUID of > the > root filesystem. (I have already updated /etc/fstab in the restored backup, > but > it is not even getting that far.) It just dumps me into busybox saying it > can't > find the root fs. Gotta love grub, which is useful only when nothing is wrong > :-) > > Any advice about how to proceed? > If the other advice you got does not work, download super grub2 disk and boot from that. It will find all your bootable OS's. http://www.supergrubdisk.org/super-grub2-disk/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "Steve Litt" > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > Rob Owens wrote: > >> I agree with putting each init in its own directory, but sysvinit >> should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit >> and by default /etc/init.d should be a link to /etc/sysvinit/init.d. >> The reason is that other init systems may expect to own /etc/init.d. >> For instance, openrc puts all its scripts in /etc/init.d (at least on >> Funtoo it does). > > I don't remember any other init wanting to use /etc/init.d, EXCEPT > OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and > the only one I know that wants to do that is systemd. > > I wouldn't change sysvinit's expected files one little bit. Everyone > assumes that /etc/init.d belongs exclusively to sysvinit. Any change to > sysvinit would require lots of testing, and who needs that headache? > Then you would be designing under the assumption that sysvinit is the "one true way" and that all others must be modified to work around sysvinit -- an init system that you/we are actively attempting to make obsolete (eventually) by way of providing all these alternatives. This doesn't make a lick of sense. >> Even though sysvinit is our default init system these days, we should >> not design Devuan such that it is difficult to change that in the >> future. So put sysvinit stuff in its own directory just like all the >> other inits. > > If you leave sysvinit's directories exactly as they exist now, > switching back and forth between sysvinit and runit is trivial. Same is > true of s6 and Epoch. > It is also trivial to do with a symlink. > Because OpenRC has seen fit to intermix their init scripts > with sysvinit's in /etc/init.d, I'd suggest that any files needed by > OpenRC be kept somewhere besides /etc/init.d. > I have only used openrc on Funtoo, but there is no intermixing with sysvinit there. It is exclusively openrc in /etc/init.d. Are you using a distro where /etc/init.d contains both openrc scripts and sysvinit scripts? -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "Didier Kryn" > Le 03/05/2016 19:10, Rob Owens a écrit : >> Yes, but then when an openrc user wants to start/stop a service, he >> cannot do '/etc/init.d/myservice start' like he could do on any other >> OS using openrc. He'd have to do '/etc/openrc/myservice start'. Not a >> really big deal, but I think it's undesirable to make Devuan's openrc >> procedures different (especially when it could be addressed with a >> simple symlink). > Normally the admin invokes the service command, > > sudo service ssh restart > sudo service nginx status > > etc. > > service could probably be modified to talk to the init system in > charge. Normally *this* admin never uses the service command because: 1) it is not available on all distros or may not be installed 2) tab completion doesn't always work with the service command (depending on the distro, I suppose) 3) tab completion always works when you specify the path to the script and you are running a bash shell Is the service called 'smb' or 'samba'? Is it 'network' or 'networking'? That's why tab completion is important to me. I'm surprised that I seem to be the only one who thinks this way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "parazyd" > On Tue, 03 May 2016, Rob Owens wrote: > >> - Original Message - >> > From: "KatolaZ" >> >> > But do we really need all that complication? Couldn't we just leave >> > the initscript of each init system in a different directory and *tell >> > the init system* where they are to be found? This will allow a much >> > easier coexistence of different confs. >> > >> > Basically, everything related to sysvinit, stays in /etc/init.d, and >> > sysvinit knows it has to look there. OpenRC stuff stays in >> > /etc/openrc, and openrc knows it has to look there for its scripts. >> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look >> > there for its stuff. We add the next-init-system, it will have its >> > scripts in /etc/. >> >> I agree with putting each init in its own directory, but sysvinit >> should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit >> and by default /etc/init.d should be a link to /etc/sysvinit/init.d. >> The reason is that other init systems may expect to own /etc/init.d. >> For instance, openrc puts all its scripts in /etc/init.d (at least on >> Funtoo it does). >> >> Even though sysvinit is our default init system these days, we should >> not design Devuan such that it is difficult to change that in the >> future. So put sysvinit stuff in its own directory just like all the >> other inits. >> > > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and > set it to /etc/openrc. Then all will be found inside, and the system > will already know what to do, without symlinking. Yes, but then when an openrc user wants to start/stop a service, he cannot do '/etc/init.d/myservice start' like he could do on any other OS using openrc. He'd have to do '/etc/openrc/myservice start'. Not a really big deal, but I think it's undesirable to make Devuan's openrc procedures different (especially when it could be addressed with a simple symlink). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "KatolaZ" > But do we really need all that complication? Couldn't we just leave > the initscript of each init system in a different directory and *tell > the init system* where they are to be found? This will allow a much > easier coexistence of different confs. > > Basically, everything related to sysvinit, stays in /etc/init.d, and > sysvinit knows it has to look there. OpenRC stuff stays in > /etc/openrc, and openrc knows it has to look there for its scripts. > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > there for its stuff. We add the next-init-system, it will have its > scripts in /etc/. I agree with putting each init in its own directory, but sysvinit should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit and by default /etc/init.d should be a link to /etc/sysvinit/init.d. The reason is that other init systems may expect to own /etc/init.d. For instance, openrc puts all its scripts in /etc/init.d (at least on Funtoo it does). Even though sysvinit is our default init system these days, we should not design Devuan such that it is difficult to change that in the future. So put sysvinit stuff in its own directory just like all the other inits. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Blackbox: was: For all you automounter programmers
- Original Message - > From: "Steve Litt" > Does Blackbox allow you to designate a tiny strip of the screen to be > desktop-only so you can click on it? Also, does Blackbox enable you to > hotkey not only blackbox functions, but also random programs on your > hard disk? Third, does Blackbox offer some sort of list of all windows, > sorted by the workspace they're in, and the ability to click one program > to get to that workspace and have focus on that program? > > The preceding paragraph ennumerates the three reasons I use Openbox, > and if Blackbox or Fluxbox also has those three assets, I'll explore > them. I can answer for Fluxbox: 1) I accomplish this by putting the following line in ~/.fluxbox/init: session.screen0.toolbar.widthPercent: 99 That makes the toolbar take up almost the whole width of the screen, but it leaves a little space at each end so you can click on the desktop. 1a) But I hotkey the menu anyway, so I rarely use those corners of the desktop. ~/.fluxbox/keys: Control Mod1 slash :RootMenu 2) You can hotkey random programs in the ~/.fluxbox/keys file like this: Control Mod1 x :Exec /usr/bin/xterm 3) Not sure about this one. You can set the toolbar to show all windows on all desktops. In that case I believe clicking one will bring you to that desktop. But I prefer to have the toolbar show only the windows on the current desktop. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] For all you automounter programmers
- Original Message - > From: "Matthew Melton" > A brief aside. > Although not an automounter I remember using bbsmount on blackbox. I can't > remember how to configure it but it sat in the blackbox dock and if I > remember > and showed icons for all the drives you wanted to show. A click would mount > the > drive and another click would unmount it. I used it for ages , after > abandoning > gnome, as an alternative to automounting. I believe it works with other > window > managers too, Judging from the man page here > https://manned.org/bbsmount/d797faf8 > > I believe it was a blackbox add-on http://blackboxwm.sourceforge.net/ but the > add on page is currently showing a 503 service unavailable so can't check. > The code, if it can be obtained, might prove useful as an alternative or > optional addition to a slimline CLI automounter. The idea of which I like the > sound of a lot. pcmanfm does this as well, though it relies on udisks2 and that now requires systemd (on Debian, anyway). I believe Thunar had very similar functionality. spacefm, as some have mentioned here, also has this functionality but it allows the use of different backends for performing the mounts. As I recall, the choices were pmount, udevil, udisks, udisks2, and possibly others. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] For all you automounter programmers
- Original Message - > From: "Steve Litt" > Do you happen to know a corresponding utility to read/write the label > on an ext4 formatted thumb drive partition? > e2label /dev/sdXY my_label ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Speaking of Window Managers
I use hotkeys extensively in Fluxbox. Fluxbox allows you to set each hotkey individually, so you could have Ctrl-Alt-a perform one action and Control-Shift-a perform another. I would like the configuration to allow variables and multiple hotkeys. This should be a valid configuration: HOTKEY=ctrl-alt HOTKEY2=ctrl-alt-shift $HOTKEY-a :Exec /usr/bin/a $HOTKEY-b :Exec /usr/bin/b $HOTKEY2-c :Exec /usr/bin/c ctrl-shift-d :Exec /usr/bin/d This would allow users to more easily change which keys enable the hotkey action, in order to eliminate conflicts with any particular software they use. Note that I don't use the Win/Meta key because I have several keyboards which do not have that key. Fluxbox also allows combos like Ctrl-Alt-a Ctrl-Alt-b :Exec /usr/bin/e, and that is useful for when you assign a hotkey for almost every application you use, like I do. The hotkeys I can no longer do without are: Move window 1 pixel: Ctrl-Alt-Shift-{arrow key} Move window 10 pixels: Ctrl-Alt-{arrow key} Resize window 1 pixel: Ctrl-Alt-Shift-{Home/End/PgUp/PgDown} Resize window 10 pixels: Ctrl-Alt-{Home/End/PgUp/PgDown} -Rob - Original Message - > From: "Steve Litt" > To: dng@lists.dyne.org > Sent: Saturday, February 27, 2016 12:05:50 AM > Subject: [DNG] Speaking of Window Managers > Hi all, > > Here's info on dmenu: > > https://wiki.archlinux.org/index.php/dmenu > > http://linux.die.net/man/1/dmenu > > http://troubleshooters.com/lpm/201406/201406.htm#use_faster_tools_dmenu > > Just for fun, I'd like some opinions. If a Window Manager were > integrated with Dmenu (which is trivially easy usually), what hotkeys > would you recommend, given that keys can be alt, ctrl, shift, alt-ctrl, > alt-shift, ctrl-shift, and even alt-ctrl-shift? > > Hotkey to bring up Dmenu? > > Hotkey to bring up window list sorted by workspace? > > Hotkey to bring up window manager menu? > > Hotkey to toggle laptop mousepad on and off? > > Hotkey to close a window (Alt+F4 sucks in my opinion) > > Thanks, > > SteveT > > Steve Litt > February 2016 featured book: The Key to Everyday Excellence > http://www.troubleshooters.com/key > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] what is sssd?
- Original Message - > From: "Rowland Penny" > On 22/01/16 16:02, Rob Owens wrote: >> One thing it can be used for is offline authentication for LDAP users. I am >> currently using sssd on a Funtoo laptop for this purpose. When I have no >> network access (no access to the LDAP server), my users can still log in. >> > > As I said, I cannot think of anything that sssd can do that winbind > doesn't, or to put it it another way, you can do that with winbind. See > here: https://wiki.samba.org/index.php/PAM_Offline_Authentication > It looks like I'd need to have a Windows domain (could be via Samba) to make that work. Is that correct? I've got Linux-only LDAP authentication, so I'm not using a domain. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] what is sssd?
One thing it can be used for is offline authentication for LDAP users. I am currently using sssd on a Funtoo laptop for this purpose. When I have no network access (no access to the LDAP server), my users can still log in. Previously I had used pam-ccreds for this. Both pam-ccreds and sssd require changes to the pam.d files in order to work for offline authentication. I am not a PAM wizard, so I had a lot of trouble getting this done. I never really got it working right with pam-ccreds, but I managed to stumble upon a working configuration with sssd. That is not an endorsement of sssd, necessarily -- I think if I was more knowledgeable about PAM I could probably get either one working. I would prefer to use pam-ccreds only because it has a much more limited scope than sssd seems to have. If I recall correctly, pam-ccreds needs to be used in combination with nslcd for offline LDAP authentication. -Rob - Original Message - > From: "Dr. Nikolaus Klepp" > To: dng@lists.dyne.org > Sent: Friday, January 22, 2016 8:23:46 AM > Subject: [DNG] what is sssd? > Does anybody know what sssd is good for? I was a bit surprised to see a whole > bunch of these sssd-something packages in debian, while I was searching for > sss. It's homepage says: > > "SSSD is a system daemon. Its primary function is to provide access to > identity > and authentication remote resource through a common framework that can provide > caching and offline support to the system. It provides PAM and NSS modules, > and > in the future will D-BUS based interfaces for extended user information. It > provides also a better database to store local users as well as extended user > data. > > Documentation on configuring SSSD in Fedora or Red Hat Enterprise Linux is > available from the RHEL deployment guide. We also have a dedicated > Documentation section [...]" > > Any idea? > > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FW: support for merged /usr in Debian
- Original Message - > From: "richard lucassen" > On Tue, 5 Jan 2016 09:51:22 -0500 (EST) > Rob Owens wrote: > > [too much typing] > >> An experienced sysadmin who has to do this type of thing several >> times a day would have designed this syntax for ease of use. The >> systemd developers did not do this, presumably because they do not >> have to type these commands several times a day. > > I think they have a so-called "mouse" to do that. Google for > computer mouse images to see what the thing looks like :) Ha! Yes, I'm sure that is how they do it. Probably VNC'ing from their Macbooks. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FW: support for merged /usr in Debian
- Original Message - > From: "Didier Kryn" > Le 05/01/2016 15:59, Rob Owens a écrit : >> I have customers who use a shared /usr among several zLinux >> systems, and the reason is cost savings. > For my information: They don't share rootfs? How do they manage > package upgrade? I just spoke to some coworkers and I have to revise my story a bit. The short answer is I don't know if these particular customers share the entire rootfs, just /usr, or some subset of /usr. There are mainframes that are used to host thousands of zLinux systems. For example, they may provide web servers to customers. In this scenario, they will attempt to share as much disk as possible between systems. The shared disk will typically be read-only on all systems except for one (perhaps a management system which is used to perform updates). Each system of course needs some read-write space, but the more shared disk it can utilize, the better (because that is cheaper and easier to manage). So are they sharing /usr and owning individual root filesystems? I'm not sure what these particular customers are doing. I can imagine scenarios where having that ability would be beneficial, but I'm not sure if these customers are actually doing it. I do know that they make heavy use of read-only disk sharing, and that taking two separate directories and dumping them into one will reduce granularity, which can make it more difficult to optimize disk sharing. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FW: support for merged /usr in Debian
- Original Message - > From: "Roger Leigh" > Regarding the comments people made about having separate / and /usr > filesystems. While it was common historically, there is little or no > practical benefit to doing so in 2016. Storage sizes make it > unnecessary for pretty much all practical scenarios. The two are > managed by dpkg as a coherent whole; they are logically inseparable. > They serve the same purpose. Do reconsider whether it's actually > necessary for you to do this, or whether it's merely habit. Some > historical practices continue to have value; others, including this one, > do not. This is not true for zLinux (Linux on an IBM mainframe). Disk space on a mainframe is quite expensive compared to what we are used to on Intel hardware. I have customers who use a shared /usr among several zLinux systems, and the reason is cost savings. I don't blame anybody on this list for not knowing about this, but I find it amazing that Red Hat doesn't know better. They are a major supplier of Linux for mainframes. (FYI, that's the s390 and s390x architecture that you see available from a handful of distros). -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FW: support for merged /usr in Debian
- Original Message - > From: "Didier Kryn" > Le 02/01/2016 03:44, Stephanie Daugherty a écrit : >> Regardless of who proposed it, merged /usr is still a reckless change > that >> needlessly complicates things. > > The simple fact of splitting executables between two different > directories *is* a complication; merging them back would be a > *simplification* :-). I've read, from a guy who followed the story, that > it was originally split because the first disk was too small. Wether it > has become later a usefull complication can be discussed of course :-) > I have also read that the split was done because they ran out of disk space. However, many great inventions over the years were created/discovered by accident. I wouldn't classify a separate /usr as a "great invention", but it certainly has proved itself to be useful over the years. The problem is that the people behind this merge are inexperienced as system admins. Being a good programmer does not by itself qualify a person to decide on the types of changes they are proposing. You need to be an experienced system admin if you are going to make smart changes to the underlying layers of an operating system. This applies to what they are doing with systemd as well. And I can give a simple example that illustrates the inexperience of the systemd architect(s): If I want to stop a service, then do some operation (edit a config file, perhaps), then start that service, I need to run the following commands: systemctl stop someservice vi someservice.cfg systemctl start someservice The systemctl syntax are in nice English language order. It sounds like a sentence. But it is backwards if you consider the steps a sysadmin would take to type them: systemctl stop someservice start Or just re-type the whole line -- it's probably quicker. If they had done it right: systemctl someservice stop start An experienced sysadmin who has to do this type of thing several times a day would have designed this syntax for ease of use. The systemd developers did not do this, presumably because they do not have to type these commands several times a day. Same goes for the /usr merge. They do not understand the usefulness of this "historical mistake" because they are inexperienced. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] laptop beeps
You could 'rmmod pcspkr' -- that'll fix it! - Original Message - > From: "Hendrik Boom" > To: dng@lists.dyne.org > Sent: Thursday, November 5, 2015 2:55:37 PM > Subject: [DNG] laptop beeps > Every now and then my laptop beeps. It happens approximately once a > minute, although it is not at all regular, and sometimes the time > between beeps is as little as ten seconds. Sometimes it's quiet for > longer stretches of time, then it starts again. > > It stopped when I logged out, and started again when I logged in. > > > Then twice today it has spent a minute or so emitting regular (several > times a second) beeps that are much quieter than the above beeps, so > quiet that I had to get my wife (who is not slowly going deaf) to make > sure that it *was* my laptop beeping. > > I'm running alpha2 devuan with xfce4. ps -l tells me, among other > things, that I have dbus-launch, dbus-daemon, pulseaudio. dbus-daemon > (yes, another one), and start-pulseaudi running. I don't know if any of > that is relevant. > > Any ideas how I should track this down? > > -- hendrik > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
- Original Message - > From: "Rainer Weikusat" > Didier Kryn writes: >> Ethernet interfaces are maybe the only issue, which explains why >> distros have implemented a solution by the means of udev rules. The >> way it is implemented is secure: every new ethernet device is given a >> new device name (ethX) and no entry is created in >> /etc/network/interfaces; therefore the interface isn't connected >> without an action of the admin. If it is a replacement, then the admin >> should just edit the MAC address in >> /etc/udev/rules.d/70-persistent-net.rules. Not a big deal, compared to >> replacing the hardware. > > As I already wrote: A file > > /etc/udev/rules.d/75-persistent-net-generator.rules > > can be created (on Debian up to wheezy at least) to avoid this "install > the system to new hardware and get a whole bunch of new ethN instead of > the onese which aren't available anymore" mess altogether. And if you forgot to create /etc/udev/rules.d/75-persistent-net-generator.rules and have rebooted with your new network card installed, you may have another option. If you only have a single network card, just delete /etc/udev/rules.d/70-persistent-net.rules and reboot. It will be re-created with your single network card defined as eth0. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC: was s6-rc, a s6-based service manager for Unix systems
- Original Message - > From: "Steve Litt" > > Am I the only person who doesn't like OpenRC? It can't respawn > (supervise, whatever you call it). Its init scripts are every bit as > complicated as those of sysvinit, but must be written in a special > language that's confusingly almost but not quite /bin/sh. To be > complete, therefore, it must spawn daemontools-encore or s6 to > supervise things like dhcpd and wpa_supplicant. One thing that I think is smart about OpenRC is the way variables are set in a file other than the init script itself. If you want to make some customizations, you don't edit the init script. You edit the corresponding file in /etc/conf.d. It seems like this could make maintaining scripts easier, and make them usable on a wider variety of distros. One thing I like about OpenRC and sysvinit is that they are shell scripts. Shell script is a language that many sysadmins already know. If they don't, they certainly wouldn't be wasting their time by learning it. It is useful way beyond init systems. If I wanted to automatically respawn something (and I might try this on my MythTV backend which crashes every few months), I could create this script: #!/bin/sh while true; do /start/my/daemon "$@" done My init system could call that script to start my daemon. Then to stop the daemon it would have to kill both the script and the daemon. Some would call that an ugly hack, but it's also known as flexibility. And it's one of the things I like about shell-script-based init systems. I didn't even know how to do this until 5 minutes ago, but I was able to search "linux automatically respawn process". And I was handed a shell script. Not a systemd script. Not an upstart script or a daemontools script or a runit script. My point is that shell script may be primitive by comparison to the methods used by some other inits, but its power is in its ubiquitousness. By the way, I'm fairly new to OpenRC so I can't really recommend it over other inits. I only intended to point out some things that I consider strong points. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] report: upgrade Debian Wheezy to Devuan Jessie
If you're still having this problem, please post your /etc/apt/sources.list - Original Message - > From: "Udo Hennig" > Hi all, > > I try out the step's below, but the first > > 'apt-get upgrade' > > will not work. I get many "500 Invalid Header" errors. One for each package. > I started from an new Debian 7.1 Netinst (Wheezy) minimal installation. > > Any ideas ? > > > Udo Hennig > > > Am 16.09.2015 um 16:30 schrieb Rob Owens: >> This test is on a non-gui system. >> >> 'apt-get update' >> >> 'apt-get upgrade' >> >> 'apt-get remove libsystemd-login0' # Not sure why this was installed >> on my Wheezy system. This operation also removed dbus. >> >> 'wget >> http://packages.devuan.org/devuan/pool/main/d/devuan-baseconf/devuan-baseconf_0.6.4+devuan3_all.deb' >> >> 'dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb' >> >> enter 'jessie' in place of the default value of 'ceres' >> >> remove debian sources from /etc/apt/sources.list (if this is a >> required step, why not have the devuan-baseconf deb comment out >> these sources?) >> >> 'apt-get update' >> >> 'apt-get install devuan-keyring' >> >> 'apt-get update' >> >> 'apt-get upgrade' >> >> 'apt-get update' -- just to be sure >> >> 'apt-get dist-upgrade' # db5.1-util is kept back. Many new >> packages are installed, including dbus, samba, and qemu-kvm. >> >> 'aptitude search ~i | grep systemd' shows libsystemd0 is >> installed, which was not present on my Wheezy system. I >> understand this is relatively benign, but I'm reporting it >> to be complete. >> >> The machine boots without errors, and 'lsb_release -a' shows >> that I am running Devuan. >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
- Original Message - > From: "Rainer Weikusat" > Laurent Bercot writes: >> I'm talking normal use cases here, i.e. situations where the services >> *will* succeed. In those situations, it is better to start everything >> according to the dependency graph, because then you do *not* trigger >> failure paths, which is nicer. > > Or you do trigger 'failure paths' which may not be nice at all. Eg, > according to a Solaris depenency specification I saw at some time in the > past, sending local mails on a Solaris system won't be allowed before > LDAP has been started. But there's really no way to predict this because > 'starting program A before program B' does not mean 'program A will be > ready to serve program B by the time program wants to use its services'. Here is a real-world scenario that has caused me trouble over the years. I have a system that connects wirelessly to my local network. The system uses wicd to manage the network connections, and wicd starts at boot. This system is supposed to mount several NFS shares on boot, but it always fails -- even when using openrc (which is dependency-based) on Funtoo. The problem is that even though wicd has started, it takes several seconds (sometimes up to 30 seconds) to acquire an ip address. In the meantime, NFS mounts are attempted and fail. I have "solved" this so far in a couple ways. One way is to issue a sleep statement before mounting the NFS shares. Another way, which can be seen at the following link, is to create a 'pingtest' service and make my NFS mounting script wait for that to succeed. https://bugs.funtoo.org/browse/FL-2644 I appreciate the assertion that NFS should handle this situation better. Note that the "bg" option seems like it should handle this situation, but my experience says it does not. I also appreciate the assertion that this can be addressed by the init system. In any case, I'm mentioning it here so that anybody looking to make a better init can consider this use case. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] report: upgrade Debian Wheezy to Devuan Jessie
This test is on a non-gui system. 'apt-get update' 'apt-get upgrade' 'apt-get remove libsystemd-login0' # Not sure why this was installed on my Wheezy system. This operation also removed dbus. 'wget http://packages.devuan.org/devuan/pool/main/d/devuan-baseconf/devuan-baseconf_0.6.4+devuan3_all.deb' 'dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb' enter 'jessie' in place of the default value of 'ceres' remove debian sources from /etc/apt/sources.list (if this is a required step, why not have the devuan-baseconf deb comment out these sources?) 'apt-get update' 'apt-get install devuan-keyring' 'apt-get update' 'apt-get upgrade' 'apt-get update' -- just to be sure 'apt-get dist-upgrade' # db5.1-util is kept back. Many new packages are installed, including dbus, samba, and qemu-kvm. 'aptitude search ~i | grep systemd' shows libsystemd0 is installed, which was not present on my Wheezy system. I understand this is relatively benign, but I'm reporting it to be complete. The machine boots without errors, and 'lsb_release -a' shows that I am running Devuan. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
- Original Message - > From: "Didier Kryn" > Le 14/09/2015 21:48, Rob Owens a écrit : >> I only chose ceres because that was the default when I installed >> devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? >> Should I have chosen ascii? > Up to now, Debian has never supported skipping one or two versions > in dist-upgrade. The version just after Wheezy is Jessie; therefore you > should probably dist-upgrade to Devuan Jessie. The planets come after that. Thanks for the input, everyone. My upgrade was better this time. 1) 'wget http://packages.devuan.org/devuan/pool/main/d/devuan-baseconf/devuan-baseconf_0.6.4+devuan3_all.deb' 2) 'dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb' 3) enter 'jessie' in place of the default value of 'ceres' 4) remove debian sources from /etc/apt/sources.list 5) 'apt-get update' 6) 'apt-get upgrade' 7) 'apt-get update' -- just to be sure 8) 'apt-get dist-upgrade' No warnings or errors. Samba and various qemu packages get installed, even though they were not installed on my Wheezy system. Package db5.1-util has been kept back. Upgrading it wanted to remove python 2.6, so instead I removed db5.1-util and the system boots fine without it. I haven't done much testing beyond that. 'aptitude search ~i | grep systemd' shows libsystemd-login0 and libsystemd0 installed. 'apt-cache policy' for both packages shows version 215-17+deb8u2 installed from http://packages.devuan.org/merged jessie/main libsystemd-login0 is listed as deprecated in the output of 'aptitude search...' and in fact, it was installed prior to my upgrade. After a reboot libsystemd-login0 is not installed -- I may have done a 'apt-get autoremove' in the meantime. I am going to have to re-test. But overall, the upgrade was successful. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
- Original Message - > On Mon, Sep 14, 2015 at 07:35:34PM +0100, KatolaZ wrote: >> On Mon, Sep 14, 2015 at 02:26:10PM -0400, Rob Owens wrote: >> > Another 'apt-get update' still produces the 'ignoring provides line' >> > warnings. >> > >> > 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be >> > installed. Additionally, for some reason samba is going to be installed >> > (nothing against samba, but I don't need it on this system). Various qemu >> > packages are also going to be installed for some reason. >> > >> > If somebody wants to try fixing these issues, I can re-test. >> > >> >> Hi Rob, >> >> I don't know if it is related, and maybe my comment is just silly, but >> in order to upgrade from Wheezy I believe you should give an "apt-get >> dist-upgrade" and not a simple "apt-get upgrade". >> That should have read 'apt-get dist-upgrade'. I have corrected my original email. >> Sorry if the comment is too stupid or irrelevant, but this little >> detail might make a difference. Also, I don't know if direct upgrading >> from Wheezy to Ceres (which is equivalent to an upgrade from an >> "old-stable" to an "unstable", in Debian words) is actually supported, >> but Devuan developers will certainly be able to clarify this point >> better. I only chose ceres because that was the default when I installed devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? Should I have chosen ascii? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to ceres -- warnings, errors, and oddities
I correct a mistake near the end of my original email. 'apt-get dist-upgrade' is what causes systemd, samba, and qemu to get installed. And just to be clear, I did 'apt-get upgrade' first, then 'apt-get dist-upgrade' later in the process. This is how I am accustomed to doing Debian upgrades. - Original Message - > From: "rowens" > If there's a better place to report this, let me know. > > On a fully updated Wheezy system, I installed > debuan-baseconf-0.6.4+devuan3_all.deb. That sets up the Devuan repositories > and then puts some instructions on the screen. When you select OK, those > instructions disappear. It would be nice if they remained on the screen. > > Anyway, I removed the Debian sources and then ran 'apt-get update'. I got > normal output plus several lines like 'ignoring provides line with > depcompareop > for package php-psr-http-message-implementation'. 'apt-get update' did not > correct this, as the on-screen messages suggested it might. > > I then ran 'apt-get upgrade' and after some upgrades it stopped with errors > about 'bsdmainutils is not configured yet'. 'apt-get install bsdmainutils' > got > me past that, but that's something that probably should be addressed. > > Another 'apt-get update' still produces the 'ignoring provides line' warnings. > edit: 'apt-get dist-upgrade' tells me that systemd and systemd-sysv are going to be > installed. Additionally, for some reason samba is going to be installed > (nothing against samba, but I don't need it on this system). Various qemu > packages are also going to be installed for some reason. > > If somebody wants to try fixing these issues, I can re-test. > > -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] upgrade wheezy to ceres -- warnings, errors, and oddities
If there's a better place to report this, let me know. On a fully updated Wheezy system, I installed debuan-baseconf-0.6.4+devuan3_all.deb. That sets up the Devuan repositories and then puts some instructions on the screen. When you select OK, those instructions disappear. It would be nice if they remained on the screen. Anyway, I removed the Debian sources and then ran 'apt-get update'. I got normal output plus several lines like 'ignoring provides line with depcompareop for package php-psr-http-message-implementation'. 'apt-get update' did not correct this, as the on-screen messages suggested it might. I then ran 'apt-get upgrade' and after some upgrades it stopped with errors about 'bsdmainutils is not configured yet'. 'apt-get install bsdmainutils' got me past that, but that's something that probably should be addressed. Another 'apt-get update' still produces the 'ignoring provides line' warnings. 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be installed. Additionally, for some reason samba is going to be installed (nothing against samba, but I don't need it on this system). Various qemu packages are also going to be installed for some reason. If somebody wants to try fixing these issues, I can re-test. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan compared to AntiX
- Original Message - > From: "Steve Litt" > Rob is right about the difficulty of installing Funtoo. As a matter of > fact, I'd say he's understated it. > > I'd go so far as to say Funtoo is only for technically proficient > people, and unlike *buntu, Debian, Devuan, OpenSuSE and Manjaro > (systemd or OpenRC), cannot be used by the guy whose entire > relationship with a computer is running programs. In my opinion, Funtoo > installation requires a soul-deep understanding of the concept of > chroot installation and configuration: Not only the Hows, but the Whys. > > Funtoo's for a guy like me, not a guy like the typical *buntu user. > > If you choose to install Funtoo, I'd *very* highly recommend you do it > two or three times on a Qemu virtual machine, because it goes fairly > quickly (8 hours) there. On metal it might take a day or a weekend, > depending on the metal. Make sure the VM has at least 28GB of disk > space, you need 14 just for kernel compilation alone. Steve, you no longer have to compile the kernel to install Funtoo. That removes quite a bit of the disk space and time requirements to install. But you are correct, it is not for beginners and it requires familiarity with (or willingness to learn) advanced concepts. However, using it is easy. So if the OP's friends would be relying on him to install the OS and take care of upgrades, then only the OP needs to put in the extra work -- not his friends. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan compared to AntiX
- Original Message - > From: "Robert Storey" > Other suggestions for non-systemd software are welcome. The main criteria is > that it actually has to be something useful, something that I might install > and > use daily. Thus, far-out stuff like Minix is not a consideration, even if it's > fun to play with. I'd suggest Funtoo, if you haven't reviewed it already. Start here: http://www.funtoo.org/Install Many reviews I read form their opinion of a distro based on how easy the install process is. If that is your plan, don't bother. The install takes a while, and you probably won't really appreciate the distro until you have used it for a while. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] non-systemd Linux for newbies with good migration tool?
- Original Message - > From: "Steve Litt" > Isaac Dunham wrote: >> -binary based > You just ruled out Funtoo. FYI, Funtoo (and Gentoo, as I understand it) can be set to automatically create packages when software is compiled. So you can have a single machine do all the compiling, and all the other machines get packages from that first machine. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
- Original Message - > From: "Rainer Weikusat" > Miles Fidelman writes: >> Worse, if "refuse to support multiple init systems" means that the >> Debian packagers start stripping out the init scripts from Debian >> packages, those, those packages become useless in Devuan. > > This is actually such an absurd idea that I have some trouble > considering it a serious concern (no disrespect intended --- I'm a > developer and this seems 'a trifle' to me but maybe not to everybody > else). I get that an init script is very minor compared to the software it starts/stops. The problem, though, is one of scale. If the handful of people who work on Devuan suddenly have to create init scripts for hundreds or thousands of packages, that job will take a long time. Even if it's just a matter of finding an old init script and verifying that it works. That said, I am doubtful that this scenario will happen. But even if it did, it would not be an insurmountable problem. It would be a big pain in the neck, though. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
- Original Message - > From: "Isaac Dunham" > I'm not sure where in the discussion this fits, but I thought I'd mention > it here: > Permitting all mount invocations via sudo does have a potential security > hole if your mount implementation supports FUSE, as you can run an arbitrary > command by specifying the mount type. > I don't think that sudo does the necessary steps to block this. > > If you use a wrapper script, you can make it automatically determine the > type and run ntfs-3g if appropriate, then allow sudo to run that. > If you use a C wrapper, you can do that and make it suid. > Another reason not to give users wholesale access to the mount command is that they could then 'mount -o remount,rw' any filesystem that the administrator has mounted read-only. To protect against this, I think you probably need something a bit more complicated than just sudo. Of course, for a single user system, this is not a problem. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
- Original Message - > From: "kpb" > Rob Owens wrote: >> >> Before I stopped using Jessie, I had USB mounting working >> with the spacefm file manager and either udevil or pmount to >> handle the removable devices. Let me know if anybody wants >> instruction on that. >> >> -Rob > > Hello Rob > > I'd appreciate an outline of the way you got pmount to talk to your file > manager > if you have your notes written up already and it is not too onerous. I'm not on a Jessie system now, but I have access to its config files. So some of this is from memory: Spacefm has the ability to use several different methods to mount removable media. If you install either pmount or udevil, it can use them. By default, I believe it automatically chooses which method it wants to use, based on what you have installed. If you want to force it to use pmount, go to Spacefm's Devices menu, Settings, Device Handlers. Click on the Default device handler, and uncomment the pmount lines in the Mount and Unmount sections. pmount and udevil have their own differing conventions for where to mount the removable media. For udevil, at least, that can be configured (allowed_media_dirs in udevil.conf). On Jessie, I have noticed that some applications don't properly detect the mounted removable media if it's mounted this way. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774871 By the way, I just discovered there is something called pmount-gui, which is not available in Debian. It provides a very basic gui for pmount. In my quick testing, I was able to mount a usb stick, but I see no option to unmount. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] automount, mount, and USB sticks
- Original Message - > From: "Hendrik Boom" > Over the years the state of mounting USB drives has steadily > deteriorated on my Debian Jessie laptop. > As far as I can tell, that was caused by the introduction of systemd as a requirement for mounting removable media (at least the "standard" way of mounting removable media). Before I stopped using Jessie, I had USB mounting working with the spacefm file manager and either udevil or pmount to handle the removable devices. Let me know if anybody wants instruction on that. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nano for beginners
- Original Message - > From: "Anto" > In vi I use 10yy and then p to copy and paste 10 lines. And I use 10dd > to delete 10 lines and press u to undo that if I mistakenly deleted the > wrong lines. What are the equivalent commands for that in nano? I have no idea. My nano usage is limited to doing what is required to get vim installed. And for that I will re-type lines by hand if I need to. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] vi for beginners
I noted some people saying they were confused by vi. Here are basic instructions to get you far enough that you can install your editor of choice. I am deliberately leaving out things like cutting and pasting. If your goal is just to get a different editor installed, these instructions should suffice. Note that many distros symlink /bin/vi to some other vi-like editor (vim-tiny, for instance). I am attempting to give instructions for the most basic vi. 1) To edit a file, type: vi /etc/apt/sources.list Note: vi starts in "command mode". You cannot insert text in this mode. 2) Use cursor keys to navigate. If they don't work in your version of vi, use the keys h, j, k, and l to navigate. 3) The "x" key is used to delete. 4) Hit "i" to go into insert mode. The Insert key may also work. Typing at this point inserts text. The delete and backspace keys may not work (depends on the version of vi). 5) Hit Escape to leave insert mode and enter command mode. 6) Type the following, followed by hitting , in order to save and quit: :wq The colon indicates that you are entering a command. "w" is short for "write", and "q" is short for "quit". 7) To save without quitting, use this command: :w 8) To save as a different filename, use this command: :w /path/to/myfile 9) To quit without saving, use this command: :q! The exclamation point indicates that you know you have unsaved changes, but you want to quit anyway. Without it, vi will refuse to quit if there are unsaved changes. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] nano for beginners
I noted some people saying they were confused by nano. Here are basic instructions to get you far enough that you can install your editor of choice. I am deliberately leaving out things like cutting and pasting. If your goal is just to get a different editor installed, these instructions should suffice. 1) To edit a file, type: nano /etc/apt/sources.list 2) Use cursor keys to navigate. 3) Typing inserts text. The delete and backspace keys work as expected. 4) Ctrl-O saves the file. Nano's menu at the bottom of the screen calls this "Write Out". You will have the option to change the name of the file. On my system, there is no blinking cursor. But the cursor is in fact at the end of the filename. Use your cursor keys or the backspace key and you will see it. 5) Ctrl-X exits. If there are unsaved changes, it will prompt you to save by asking "Save modified buffer?". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposed defaults changes
- Original Message - > From: "Hendrik Boom" > On Wed, Jul 15, 2015 at 09:04:03PM +0200, Micky Del Favero wrote: >> I vote to put vi as default editor in devuan because vi is the default >> editor in every unix since ever and every unix user has to know how to >> use vi! > > NO. Not every Unix user. Only the ones that use Unix variants that > force vi on them. Only those have to use vi. Hendrik, Just curious -- do any distros come with emacs as the default editor? I don't use emacs, and have never tried running it from a default install of any distro I've ever used. > nano is, as far as I can see, nobody's favorite editor. But it's also > nobody's anathema. It will give you enough breathing room to choose > the editor you really want. Agreed. Even though I am always annoyed when I run 'visudo' on a new system and get nano. But I know how to change it so it's no big deal. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd in wheezy, was: Re: bummer
- Original Message - > From: "Steve Litt" > On Mon, 13 Jul 2015 18:45:19 +0200 > Didier Kryn wrote: > > >> That said, I fully agree with you that udev is the major weapon >> the systemd team is using to lock themselves in the place, and >> breaking udev monopoly with vdev is the answer. >> >> Didier > > > I did a lot of work with Gentoo over the weekend, and from my > perspective, although Gentoo inits with OpenRC, it seems to default to > udev, not eudev, and there's way to much systemd type stuff for my > taste. They even have those wonderful "Predictable Network Interface > Names" > (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/). > Silly me, I thought eth0 was predictable. > > I know I can get back eth0 with a kernel argument, but I'm just > illustrating how var Gentoo has gone down the systemd path. Steve, If you're interested, give Funtoo a try. I've been using it lately and I like it. It uses OpenRC and eudev. The maintainers have a fairly anti-systemd stance. I am of the belief that sysvinit isn't all that bad, and I'd rather use it than learn something new. But I've found OpenRC relatively easy to understand and work with. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposed defaults changes
- Original Message - > From: "Franco Lanza" > On Wed, Jul 15, 2015 at 09:35:03AM -0400, Rob Owens wrote: >> Which is Devuan intended to be? >> >> 1) Debian without systemd >> 2) A Debian-like distro >> > > Nor 1 or 2. > Devuan is intended to be a debian that respect: > 1- freedom of choice > 2- UNIX philosophy > 3- KISS philosophy > > Of course first of all those 3 points make systemd unacceptable. But > saying that devuan is just "debian withous systemd" is riductive. > > traditionally UNIX has vi, this is why i'm suggesting it. No packages > needs to be changed at all for this eventual switch, and anyway, > as devuan respect the users, this choice isn't an imposition from "the > hight", but it's a question to the whole ml userbase to listen pro/cons. In that case, my next question would be "Do we want to cater to those who are new to Linux/Unix?" If yes, then nano is a good choice. If no, then vi is a good choice. I don't like using nano, and always install vim, followed by 'update-alternatives'. But I remember as a new user being frustrated that I couldn't follow a simple how-to because I didn't know how to use vi. When I discovered nano, it was a huge relief. I don't mind defaulting to nano for the sake of new users, even if nano isn't what I want to use. I know how to change the defaults. A new user does not. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposed defaults changes
- Original Message - > From: "Franco Lanza" > More than the already know switch from gnome to xcfe4 as the default > desktop and the oblovious change to sysvinit instead of systemd, i would > to propose some other default changes in the standard install: > > nano -> vim > exim -> postfix > Which is Devuan intended to be? 1) Debian without systemd or 2) A Debian-like distro If the answer is 1, then changes should be limited to only what is required to operate systemd-free. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] automounting in a window manager
- Original Message - > From: "shraptor" > On 2015-06-01 16:22, Rob Owens wrote: > > - Original Message - > >> From: "Robert Storey" > >> > >> First, thanks to all who replied. > >> > >> To me, the ideal solution would be if this was a user-configurable > >> option. > >> Would be great if you could, for example, just stick something into > >> .bashrc > >> for any user to allow automounting of USB devices, no matter which DE > >> or > >> window manager was being used. But I know it doesn't work that way. > >> Just > >> saying, it would make sense. > >> > >> pmount - yes, thanks for reminding me. I've used it eons ago. But all > >> it does > >> is allow one to mount a device without needing sudo. Still not really > >> automounting. > >> > >> No one mentioned udevil. I just found it. Also not the same as > >> automounting, > >> but check out the interesting git home page: > >> > >> https://ignorantguru.github.io/udevil/ > >> > > That guy also wrote spacefm. It's a file manager which allows you to > > either > > manually or automatically mount USB devices. It can be configured to > > use > > udevil, pmount, udisks1, or udisks2 to perform that function. > > > > Spacefm is currently unsupported by the developer. > > > > > checking github > https://github.com/IgnorantGuru/spacefm/commits/next > > it seems spacefm is very much alive > Awesome! Thanks for the update. Last I had read, ignorantguru was on haitus (announced April 28, 2014). But it looks like as of this February, he's back. https://igurublog.wordpress.com/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] automounting in a window manager
- Original Message - > From: "Robert Storey" > > First, thanks to all who replied. > > To me, the ideal solution would be if this was a user-configurable option. > Would be great if you could, for example, just stick something into .bashrc > for any user to allow automounting of USB devices, no matter which DE or > window manager was being used. But I know it doesn't work that way. Just > saying, it would make sense. > > pmount - yes, thanks for reminding me. I've used it eons ago. But all it does > is allow one to mount a device without needing sudo. Still not really > automounting. > > No one mentioned udevil. I just found it. Also not the same as automounting, > but check out the interesting git home page: > > https://ignorantguru.github.io/udevil/ > That guy also wrote spacefm. It's a file manager which allows you to either manually or automatically mount USB devices. It can be configured to use udevil, pmount, udisks1, or udisks2 to perform that function. Spacefm is currently unsupported by the developer. In the past I've used pcmanfm to perform this function, but on Jessie, it seems to require systemd stuff in order to handle mounting. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] KDE systemd lock-in
- Original Message - > From: "T.J. Duchene" > > Gnome already depends on systemd, but the apps do not. Not exactly true. My eyes were open to the systemd problem when I installed brasero on Jessie and it wanted to change my init system. Brasero depends on gvfs to detect removable media, and that in turn, through a chain of dependencies, depends on libpam-systemd. That depends on systemd-sysv | systemd-shim. After some debate, that last dependency was changed to systemd-shim | systemd-sysv. That it required any debate at all makes me wonder where some of the Debian devs' heads are at. So note that without the existence of the 3rd party systemd-shim, Many gnome apps do in fact depend on systemd as init. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] About Devuan's audience
- Original Message - > From: "Didier Kryn" > Considering Devuan is a major lifeboat of free Linux-based OS, I'm > anxious about its destiny and therefore trying to figure out who is > onboard, I mean the audience. For me, the line between desktop and server is very blurred. I use Debian in a home environment for myself and family members. I am responsible for the maintenance of 11 Debian machines. LXDE is the desktop of choice for most, since Gnome 3 was introduced on Wheezy and the long-term existence of Gnome Classic (or Gnome Fallback) is questionable. Myself, I use Fluxbox. Some of my machines are CLI only. Security is a top priority. I also appreciate the large number of packages that Debian provides. I followed the systemd debates carefully on debian-user and debian-devel. I now am of the opinion that a large number of Debian developers are not paranoid enough to be my OS provider. High-value software to me, in no particular order, includes: Libreoffice Firefox LXDE [2] Fluxbox Openbox Ardour Jack easytag flac pcmanfm xterm xcalc VLC mplayer MythTV (from deb-multimedia.org) Handbrake (from deb-multimedia.org) ssh nfs ldap iptables music player [1] 1: I like Rhythmbox, but the interface is getting worse and the transcode feature seems finicky. I have been mostly using Guayadeque recently. I have need for both a basic player, and for something to transcode flac files to ogg vorbis or mp3 when music is copied to a portable player or usb stick. On Jessie without systemd, it can no longer detect removable media, so its days on my system may be numbered. See my so-far unanswered bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774871 2: Personally, I don't care if Devuan includes Gnome or not. I think Gnome is so committed to 1) not being optimized for desktops and 2) using systemd, that it would be fair to simply write it off as unusable in Devuan. As long as I have alternatives, I am fine with that. Their vision for their product does not impress me. I think the only reason they have survived the past several years is because they have been the default on so many distros for so long. But today I think there are better choices for default desktop. LXDE and XFCE seem good. But I honestly think most people would be well-served with something basic like Fluxbox or Openbox with a customized startup script which runs wicd, and maybe adding something like fbpanel. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Towards systemd-free packages
On Fri, Feb 06, 2015 at 12:05:35AM +, Nuno Magalhães wrote: > Hi, > > On Tue, Feb 3, 2015 at 3:47 AM, Jude Nelson wrote: > > Considering the dependencies on libsystemd0, libpam-systemd, libudev0, and > > libudev1, I get: > > I don't see eudev or mdev in Debian's repos, are there any viable > alternatives? > Debian does have udevil. I'm not sure if it's a complete replacement for udev, but it allowed me to do USB automounting on Jessie without systemd. Udevil is unmaintained upstream, as far as I know. -Rob signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng