Re: [DNG] New Debian project leader
On Wed, 29 Apr 2020 13:43:45 +1000 wirelessduck--- via Dng wrote: > Looks like debian has voted for their next project leader for the > upcoming year. > > https://lwn.net/Articles/816158/ > > https://www.phoronix.com/scan.php?page=news_item=Debian-New-DPL I'm not impressed. His platform was entirely rah-rah Debian, Debian's the best, we don't even have to worry what others think. He called for unity, which in my mind is telling the remaining anti-systemd factions to just shut up. I'll say this though: Judging from his self-nomination [1], he's a person who thinks, and I think an idealist who one day could be persuaded to understand the value of the user controlling the computer rather than the other way around, or at least not removing such ability. He impresses me as a much more thoughtful human being than Lennart Poettering or Paul Tagliamonte [2]. This is important and on-topic because a hostile Debian management could build in enough booby traps to make Devuanization too difficult for practicality. [1] https://lwn.net/ml/debian-vote/fbd58e7c-7898-1b67-2668-49c4370c5...@debian.org/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 (warning: Huge page, slow load) SteveT Steve Litt March 2020 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] Boewulf: at XFCE4 start, mouse ptr freezes for ~2mins.
Hi Everyone, On Boewult when XFCE4 starts, the mouse pointer remains unresponsive for about 2 minutes. This is a touchpad mouse on HP Probook 4540s. The only module that seems to be related that is loaded is psmouse. This is from dmesg: # dmesg | grep mouse [2.51] mousedev: PS/2 mouse device common for all mice [3.559859] psmouse serio4: synaptics: queried max coordinates: x [..5756], y [..4876] [3.599714] psmouse serio4: synaptics: queried min coordinates: x [1212..], y [996..] [3.672070] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xf00473/0x64/0xa2400/0x0, board id: 1397, fw id: 958907 Thanks. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] waagent
On 29/04/2020 15:28, Peter Duffy wrote: > (Apologies if I've posted this to the wrong list - shall I repost it to > the devuan-dev list?) > > On Wed, 2020-04-29 at 15:21 +0100, Peter Duffy wrote: >> I'm currently setting up a virtualbox image based on Devuan ASCII, for >> eventual upload to azure as a base image for creating VMs. >> >> I've hit some problems with the waagent package in the Devuan >> repositories - basically they boil down to: >> >> 1) the python function platform.linux_distribution() returns "debian" >> instead of "devuan" Annoying, but a necessary fudge if my memory is correct... But even this fudge does not work in all cases. $lsb_release -a Distributor ID: Debian Description:Devuan GNU/Linux 3 (beowulf) Release:3 Codename: beowulf Can cause problems for any software parsing 'Debian' which then goes on to parse the 'Release' and expects 8.0 or 9.0 >> >> 2) waagent loads an instance of the class osutil which contain a set of >> method overrides specific to a particular distro/release. However, it >> doesn't have one for Devuan, so this, combined with (1) causes it to >> load an osutil instance for debian, and this means that it expects >> systemd functionality to be present. This is the real bug. It should not assume SystemD for Debian or any other Distro by name, it should explicitly check the init system in use. After all, Debian Devs have stated that Debian is 'other init system friendly' so they have no grounds for rejecting a patch on that score. >> >> I've fixed (2) on my local sandbox (created an osutil instance for >> Devuan) and I'm preparing to do a fork/pull from github to get the >> changes reviewed and hopefully integrated. >> >> (1) is a bit of a problem. I can work around it by defining a >> file /etc/lsb-release, which is seen and used by >> platform.linux_distribution() - but I'm worried about making a >> system-wide change to fix an application-specific problem: it could >> break other things which rely on the python function returning "debian". >> So I'm going to try to identify Devuan directly from within waagent, >> rather than relying on python. >> >> Any thoughts re. python identifying Devuan as "debian" would be welcome >> - should this be flagged up as a bug, or is it necessary? >> >> >> ___ >> 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] waagent
(Apologies if I've posted this to the wrong list - shall I repost it to the devuan-dev list?) On Wed, 2020-04-29 at 15:21 +0100, Peter Duffy wrote: > I'm currently setting up a virtualbox image based on Devuan ASCII, for > eventual upload to azure as a base image for creating VMs. > > I've hit some problems with the waagent package in the Devuan > repositories - basically they boil down to: > > 1) the python function platform.linux_distribution() returns "debian" > instead of "devuan" > > 2) waagent loads an instance of the class osutil which contain a set of > method overrides specific to a particular distro/release. However, it > doesn't have one for Devuan, so this, combined with (1) causes it to > load an osutil instance for debian, and this means that it expects > systemd functionality to be present. > > I've fixed (2) on my local sandbox (created an osutil instance for > Devuan) and I'm preparing to do a fork/pull from github to get the > changes reviewed and hopefully integrated. > > (1) is a bit of a problem. I can work around it by defining a > file /etc/lsb-release, which is seen and used by > platform.linux_distribution() - but I'm worried about making a > system-wide change to fix an application-specific problem: it could > break other things which rely on the python function returning "debian". > So I'm going to try to identify Devuan directly from within waagent, > rather than relying on python. > > Any thoughts re. python identifying Devuan as "debian" would be welcome > - should this be flagged up as a bug, or is it necessary? > > > ___ > 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] waagent
I'm currently setting up a virtualbox image based on Devuan ASCII, for eventual upload to azure as a base image for creating VMs. I've hit some problems with the waagent package in the Devuan repositories - basically they boil down to: 1) the python function platform.linux_distribution() returns "debian" instead of "devuan" 2) waagent loads an instance of the class osutil which contain a set of method overrides specific to a particular distro/release. However, it doesn't have one for Devuan, so this, combined with (1) causes it to load an osutil instance for debian, and this means that it expects systemd functionality to be present. I've fixed (2) on my local sandbox (created an osutil instance for Devuan) and I'm preparing to do a fork/pull from github to get the changes reviewed and hopefully integrated. (1) is a bit of a problem. I can work around it by defining a file /etc/lsb-release, which is seen and used by platform.linux_distribution() - but I'm worried about making a system-wide change to fix an application-specific problem: it could break other things which rely on the python function returning "debian". So I'm going to try to identify Devuan directly from within waagent, rather than relying on python. Any thoughts re. python identifying Devuan as "debian" would be welcome - should this be flagged up as a bug, or is it necessary? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
