Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11 2023 at 05:59:37 AM, Tom Browder wrote: > Anyone using that system? It looks interesting to me. > I prefer healthchecks.io, mainly because cron job monitoring was all I was looking for, and the software is open source. There is a comparison with cronitor at https://healthchecks.io/docs/healthchecks_cronitor_comparison/. That page only talks about cron job monitoring, though, and cronitor has other functionality as well. Source for healthchecks.io is at https://github.com/healthchecks/healthchecks, so you could potentially host it somewhere yourself. I like having that possibility, but at the moment, I'm just using the instances at healthchecks.io. -- regards, kushal
Re: video issue following latest bullseye update
D. R. Evans composed on 2023-05-22 14:39 (UTC-0600): > Do you really mean "DDX", not "DIX"? < > I made the edit according to your instructions (i.e., "DDX") but I'm not > certain that your e-mail didn't contain a typo. My first thread post did have a bad one: sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf was supposed to read sudo sed -i 's/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: X: how to *really* switch from nouveau to modesetting?
You did it. You made the switch. But see below. (There are multiple components to GPU support in Linux.) (There is no "the" nouveau "driver". Graphics support is in the hands of multiple software components, several of which incorporate the string "nouveau" in naming.) D. R. Evans composed on 2023-09-11 11:47 (UTC-0600): > Graphics: >Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau Above shows your kernel DEVICE driver is nouveau. It ships specifically for each kernel with each kernel. For NVidia GPUs there is no other FOSS device driver option for normal use with KMS enabled, which maximum possible FOSS performance unconditionally requires. With KMS disabled, there is a crude generic option with limited resolutions available that no one ever would use purposely unless too naive to understand the opportunity loss. It's for fallback and troubleshooting when normal is unavailable. > v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) > arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 > speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1 > bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300 >Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: > loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Above shows your loaded X DISPLAY driver is modesetting, the one & only competent FOSS alternative to the nouveau that ships in xserver-xorg-video-nouveau. The DRI driver is another nouveau, another piece of the graphics support puzzle, another only option for competent FOSS NVidia GPU support. # dpkg-query -W | grep nouveau libdrm-nouveau2:amd64 2.4.114-1+b1amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime # https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure > My xorg.conf file currently looks like this: You should have no /etc/X11/xorg.conf file. Proprietary NVidia drivers and configurators normally make one. It's just something they do. For FOSS drivers, /etc/X11/xorg.conf is an anachronism that remains occasionally useful. Any such file created by NVidia installation or reconfiguration must be removed, or severely edited, in order to revert from proprietary NVidia driver use to FOSS-only use. > And the file that Felix suggested I install, > /etc/X11/xorg.conf.d/50-device.conf, looks like this: > Section "Device" >Identifier "DDX" > Driver "modesetting" > # Driver "nouveau" > EndSection That's a valid available option for overriding the selection Xorg would make on its automagic own. Its existence overrides any conflicting equivalent in any existing /etc/X11/xorg.conf. By having it it is normally not necessary to keep xserver-xorg-video-nouveau uninstalled to keep X keeping the modesetting DIX loaded instead of the nouveau DDX. DIX: Device Independent X display driver (works with most GPUs regarless of brand) DDX: Device Dependent X display driver (specific to one brand of GPU) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Boot issue
On Sun, Aug 27, 2023 at 22:51 David Wright wrote: > On Sun 27 Aug 2023 at 14:27:09 (-0500), Tom Browder wrote: > > On Sun, Aug 27, 2023 at 13:27 Greg Wooledge wrote: > > > > > On Sun, Aug 27, 2023 at 08:19:35PM +0200, Hans wrote: > > > > When I boot the system, then the drives are not mounted as set in > > > /etc/fstab. > > > > For example, the SDD should mounted to /space, and the unencrypted > HDD > > > > ... > > > > > Use UUIDs or Labels instead. These won't change, while the device > names > > > *will* change. > > > > > > Please remind me of when they might change. > > As and when the kernel discovers them, ie at boot for those fitted, > and when you plug them is for any others. > > > I'm pretty sure on my latest > > host the debian installer used /dev/sda (and partions 1 and 2) instead > of a > > label or UUID. > > It might be possible to mistakenly read /etc/fstab as showing that, > because of the comment line above the active line: > > # > # / was on /dev/sda4 during installation > UUID=a1b2c3d4-e5f6-1234-dcba-a1b2c3d4e5f6 / ext4 > errors=remount-ro 0 1 > /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 > > BTW I've not seen the d-i use LABELs, I presume because it can't be > certain that they're always going to be unique. > > > Of course I do want to add drives eventually, so maybe I do need to > change > > to do that safely. > > Some computers can give the user a rude awakening when the kernel > unexpectedly discovers a plugged-in device before the internal drive. Ah, it's been awhile. Yes, I see the comments in /etc/fstab. Thank you for reminding me. Usually I just do "df" and that always shows me the /dev/sdaX so I forget about looking closer. Cheers! -Tom
[outrageously off-topic] All those Thomas [was: cronitor.io for monitoring cron jobs]
On Mon, Sep 11, 2023 at 05:08:04PM +, Andrew M.A. Cater wrote: > On Mon, Sep 11, 2023 at 06:49:00PM +0200, to...@tuxteam.de wrote: > > On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > > > Hi, > > > > > > to...@tuxteam.de wrote: > > > > and we're all twins [1] ;-) > > > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > > > > > But paradoxly less than half of all twins bear this very cool name. > > > > Which is a pity, ain't it ;-) > > > > Imagine the clerk at the civil registration office: > > > > Q: "But... but both your kids are called Thomas?" > > A: "Well, yes. They are twins!" > > > > Everyone's called Thomas? I doubt it ... > https://en.wikipedia.org/wiki/Doubting_Thomas ;-) > [In Wales, Thomas is quite a common family name - there are probably *lots* > of sets of twins surnamed Thomas :) ] In Germany, this isn't unheard of either. Interestingly, in Spain I haven't met any. Go figure. Cheers -- t signature.asc Description: PGP signature
X: how to *really* switch from nouveau to modesetting?
This is a follow-on to the thread that started with: https://lists.debian.org/debian-user/2023/05/msg00657.html Following the upgrade to bookworm that I recently performed, I was hoping that the problem described in the first post in that thread would magically go away. It didn't :-( Felix suggested removing the nouveau driver and using "modesetting" as the driver. I have removed the nouveau driver -- or at least I thought I did -- by executing: apt-get remove xserver-xorg-video-nouveau which moved the packages: xserver-xorg-video-nouveau xserver-xorg-video-all Upon rebooting into bookworm, though, I still see the original problem, as described in the original post. If I look to see what driver is being used: [ZB:~] inxi -SGaz System: Kernel: 6.1.0-12-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-6.1.0-12-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity info: kicker wm: Twin vt: 7 dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm) Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1 bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x317mm (20.00x12.48") s-diag: 599mm (23.57") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: VGA TO HDMI built: 2013 res: 1920x1080 hz: 60 dpi: 96 gamma: 1.2 size: 509x286mm (20.04x11.26") diag: 584mm (23") ratio: 16:9 modes: max: 1920x1080 min: 640x480 API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NVC1 direct-render: Yes [ZB:~] So the nouveau driver still seems to be available and in use, despite being removed. My xorg.conf file currently looks like this: [ZB:~] cat /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection [54/136] Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "VideoKey" # #Option "WrappedFB" # [] #Option "GLXVBlank" # [] #Option "ZaphodHeads" # #Option "PageFlip" # [] #Option "SwapLimit" # #Option "AsyncUTSDFS" # [] #Option "AccelMethod" # #Option "DRI" # Identifier "Card0" # Driver "nouveau" Driver "modesetting" BusID "PCI:4:0:0" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "SWcursor" # [] #Option "kmsdev"# #Option "ShadowFB" # [] #Option "AccelMethod" #
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 06:49:00PM +0200, to...@tuxteam.de wrote: > On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > > Hi, > > > > to...@tuxteam.de wrote: > > > and we're all twins [1] ;-) > > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > > > But paradoxly less than half of all twins bear this very cool name. > > Which is a pity, ain't it ;-) > > Imagine the clerk at the civil registration office: > > Q: "But... but both your kids are called Thomas?" > A: "Well, yes. They are twins!" > Everyone's called Thomas? I doubt it ... https://en.wikipedia.org/wiki/Doubting_Thomas [In Wales, Thomas is quite a common family name - there are probably *lots* of sets of twins surnamed Thomas :) ] Andy > Cheers > -- > t
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > Hi, > > to...@tuxteam.de wrote: > > and we're all twins [1] ;-) > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > But paradoxly less than half of all twins bear this very cool name. Which is a pity, ain't it ;-) Imagine the clerk at the civil registration office: Q: "But... but both your kids are called Thomas?" A: "Well, yes. They are twins!" Cheers -- t signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
Hi, to...@tuxteam.de wrote: > and we're all twins [1] ;-) > [1] https://en.wikipedia.org/wiki/Thomas_(name) But paradoxly less than half of all twins bear this very cool name. Have a nice day :) Thomas
Re: usrmerge on root NFS will not be run automatically
Hello, El dom., 10 sept. 2023 21:55, Marco escribió: > On Fri, 8 Sep 2023 12:26:38 -0400 > Dan Ritter wrote: > > > > That is quite an involved task. I didn't expect such fiddling for a > > > simple OS update. I'm a bit worried that the permissions and owners > > > go haywire when I copy stuff directly off the server onto a VM and > > > back onto the server. Is there a recommended procedure or > > > documentation available? > > > > Can you start a temporary VM directly on the server? > > I might actually. I'll have to check the following days. > > > If so, you can > > * stop your remote Debian machine > > * run a Debian rescue image in the VM on the NFS server > > * have the VM mount the filesystem directly > > * chroot, run usrmerge > > * unmount > > Ok, that's also quite a task, but it seems less error-prone than > copying a bunch of system files across the network and hope for the > best. I'll try. > > Marco > Maybe you can open a new bug asking for a better documentation or what should be done in this case. Maybe dpkg -L with both files can help to clarify what should be done Regards >
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 07:46:35AM -0500, Tom Browder wrote: [...] > > "Apt search monitor" and subsequent filtering with "web" yields half > > a dozen other interesting hits. > > > Thanks, Tomas, I was not savy enough to think of that! Glad to help :) > P.S. We share a good, Biblical name, don't we? and we're all twins [1] ;-) Cheers [1] https://en.wikipedia.org/wiki/Thomas_(name) -- t signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 07:25 wrote: > On Mon, Sep 11, 2023 at 06:46:43AM -0500, Tom Browder wrote: > > On Mon, Sep 11, 2023 at 06:22 wrote: > > > > > On Mon, Sep 11, 2023 at 05:59:37AM -0500, Tom Browder wrote: > > > > Anyone using that system? It looks interesting to me. > > > > > > Gah. My eyes hurt now after having looked at the web site. > > > > > > Do you recommend any other prebuilt system to automate such monitoring > and > > gathering of data and presenting it on a website? (Other than building > from > > scratch., yuk.) > > Not much experience myself, but icinga (packaged with Debian) comes > to mind (it can do much more, though). > > "Apt search monitor" and subsequent filtering with "web" yields half > a dozen other interesting hits. Thanks, Tomas, I was not savy enough to think of that! -Thomas P.S. We share a good, Biblical name, don't we?
Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords
* On 2023 14 Aug 21:29 -0500, Max Nikulin wrote: > On 14/08/2023 07:30, Nate Bargmann wrote: > > Now, while typing this email all keyring PIDs have vanished! > > It may be a way to minimize RAM usage. I don't think so. It has been persistent in the past in Buster and Bullseye with GNOME and is persistent on the laptop which is also running Bookworm and GNOME. On this desktop it will rather reliably shutdown/crash about exactly an hour after logging in with no other desktop activity, i.e. not opening browsers or other apps. > The agent may be a socket-activated > process. > > systemctl --user list-sockets The lists are virtually identical between the laptop: $ systemctl --user list-sockets LISTEN UNITACTIVATES /run/user/1000/bus dbus.socket dbus.service /run/user/1000/gcr/ssh gcr-ssh-agent.socket gcr-ssh-agent.service /run/user/1000/gnupg/S.dirmngr dirmngr.socket dirmngr.service /run/user/1000/gnupg/S.gpg-agent gpg-agent.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.browser gpg-agent-browser.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.extra gpg-agent-extra.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket gpg-agent.service /run/user/1000/keyring/control gnome-keyring-daemon.socket gnome-keyring-daemon.service /run/user/1000/pipewire-0pipewire.socket pipewire.service /run/user/1000/pk-debconf-socket pk-debconf-helper.socket pk-debconf-helper.service /run/user/1000/pulse/native pipewire-pulse.socket pipewire-pulse.service 11 sockets listed. Pass --all to see loaded but inactive sockets, too. and the desktop: $ systemctl --user list-sockets LISTENUNITACTIVATES /run/user/1000/busdbus.socket dbus.service /run/user/1000/gcr/sshgcr-ssh-agent.socket gcr-ssh-agent.service /run/user/1000/gnupg/S.dirmngrdirmngr.socket dirmngr.service /run/user/1000/gnupg/S.gpg-agent gpg-agent.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.browser gpg-agent-browser.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.extragpg-agent-extra.socket gpg-agent.service /run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket gpg-agent.service /run/user/1000/keyring/controlgnome-keyring-daemon.socket gnome-keyring-daemon.service /run/user/1000/pipewire-0 pipewire.socket pipewire.service /run/user/1000/pk-debconf-socket pk-debconf-helper.socket pk-debconf-helper.service /run/user/1000/pulse/native pipewire-pulse.socket pipewire-pulse.service /run/user/1000/snapd-session-agent.socket snapd.session-agent.socket snapd.session-agent.service 12 sockets listed. Pass --all to see loaded but inactive sockets, too. On the desktop gnome-keyring-daemon has not been running for several hours. > Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue what > is really happening in your case. On both systems that environment variable is: $ echo $SSH_AUTH_SOCK /run/user/1000/keyring/ssh > I suggest you to add "f" option to "ps" to see process tree. It may help to > find details concerning starting of particular agent. At this point I know the agent will be working normally when I first log into gnome-shell. This has been a reliable way to get it started. I posted to the GNOME discourse about this and was advised to open separate issues in the keyring Gitlab repository. They are: https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/135 "gnome-keyring-daemon shutting down on Debian 12 shortly after logging into GNOME Shell " https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/136 "gnome-keyring-daemon fails to restart properly on Debian 12 " Last night I did some testing with gdb and put my results in issue #135. In this case the daemon crashed when I logged out of another system, well short of the hour it will run if left idle. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 05:59:37AM -0500, Tom Browder wrote: > Anyone using that system? It looks interesting to me. Gah. My eyes hurt now after having looked at the web site. Besides, it looks a bit like a bait-and-switch SaSS. No, I wouldn't use it. Cheers -- t signature.asc Description: PGP signature
cronitor.io for monitoring cron jobs
Anyone using that system? It looks interesting to me. -Tom
Re: Since vmlinuz-6.1.0-12-amd64 my dvb-s2 card don't work anymore
Sep 11 12:23:44 kernel: dvbdev: DVB: registering new adapter (SMI_DVB) Sep 11 12:23:44 kernel: failing symbol_get of non-GPLONLY symbol m88ds3103_attach. Sep 11 12:23:44 kernel: DVB: Unable to find symbol m88ds3103_attach() Am 11.09.2023 um 12:31 schrieb groemich: Hello, maybe someone knows more than me. If i boot the new kernel vmlinuz-6.1.0-12-amd64 my dvb-s2 card is not detected. if i boot vmlinuz-6.1.0-11-amd64 everything works as usual. greetings
Since vmlinuz-6.1.0-12-amd64 my dvb-s2 card don't work anymore
Hello, maybe someone knows more than me. If i boot the new kernel vmlinuz-6.1.0-12-amd64 my dvb-s2 card is not detected. if i boot vmlinuz-6.1.0-11-amd64 everything works as usual. Error with vmlinuz-6.1.0-12-amd64: Sep 11 12:23:44 kernel: dvbdev: DVB: registering new adapter (SMI_DVB) Sep 11 12:23:44 kernel: failing symbol_get of non-GPLONLY symbol m88ds3103_attach. Sep 11 12:23:44 kernel: DVB: Unable to find symbol m88ds3103_attach() greetings
Since vmlinuz-6.1.0-12-amd64 my dvb-s2 card don't work anymore
Hello, maybe someone knows more than me. If i boot the new kernel vmlinuz-6.1.0-12-amd64 my dvb-s2 card is not detected. if i boot vmlinuz-6.1.0-11-amd64 everything works as usual. greetings
Re: xclip - how to use without a graphics display for testing on Github workflows
On Sun, Sep 10, 2023 at 11:49 Max Nikulin wrote: > On 10/09/2023 16:44, Tom Browder wrote: > > On Sat, Sep 9, 2023 at 21:06 Max Nikulin wrote: > > > >> You can create a mock-up and use it instead of real xclip binary. > > > > Sounds interesting, Max, can you show the code? > > Unless you need to test subtle issues like > >https://github.com/astrand/xclip/issues/20 >"Not closing stdout when setting clipboard from stdin" > > faced by e.g. tmux users, something simple should be enough: > > #!/bin/sh -eu > : "${XCLIP_MOCK_FILE:=$HOME/.xclip-mock}" > > while [ $# -gt 0 ]; do > case "$1" in > -i|-in) > ;; > -o|--out) exec cat -- "$XCLIP_MOCK_FILE" > ;; > -selection|-target) shift > ;; > *) # FIXME xclip treats all unknown options at any > position as files > break > ;; > esac > shift > done > exec cat -- "$@" >"$XCLIP_MOCK_FILE" Thank, Max! I'll pass it on to the guy who needs it. He slings Wolfram language code for a living. Best regards, -Tom
Re: How to remove GNOME from a headless virtual Sid
Hi. On Mon, Sep 11, 2023 at 09:28:15AM +0200, Thomas Schmitt wrote: > how to get rid of voluminous desktop stuff without colateral damage ? I'd start with: apt purge libgtk-3-0 libqt* Possibly followed by: apt autoremove --purge It's assumed that you read through the list of packages to be removed before you actually do it :) Reco
Re: How to remove GNOME from a headless virtual Sid
On 9/11/23 09:28, Thomas Schmitt wrote: Hi, how to get rid of voluminous desktop stuff without colateral damage ? Does somebody here have experience to share about de-GNOME-ing a virtual Sid system ? Reason why i ask: A dist-upgrade of my virtual Sid lasted nearly 2 hours and used up 4.5 GiB of its virtual disk. (About half of this was in /var/cache/apt/archives and could be deleted afterwards.) I begin to fear that the future growth of Debian will make dist-upgrades impossible on the 32 GiB virtual disk. Package names matching "gir*" and "*gnome*" support my feeble memories that the system began its life as Debian 8 installation with GNOME desktop. It is only used for preparing and testing Debian packages of upstream software. I log in via SSH, work the way down my cheat sheet, and commit the new preparations to g...@salsa.debian.org. No desktop jobs at all. Reinstall it from scratch without a DE! ;^) You could use 'tasksel' and/or 'apt-get --autoremove purge '. HTH. -- John Doe
How to remove GNOME from a headless virtual Sid
Hi, how to get rid of voluminous desktop stuff without colateral damage ? Does somebody here have experience to share about de-GNOME-ing a virtual Sid system ? Reason why i ask: A dist-upgrade of my virtual Sid lasted nearly 2 hours and used up 4.5 GiB of its virtual disk. (About half of this was in /var/cache/apt/archives and could be deleted afterwards.) I begin to fear that the future growth of Debian will make dist-upgrades impossible on the 32 GiB virtual disk. Package names matching "gir*" and "*gnome*" support my feeble memories that the system began its life as Debian 8 installation with GNOME desktop. It is only used for preparing and testing Debian packages of upstream software. I log in via SSH, work the way down my cheat sheet, and commit the new preparations to g...@salsa.debian.org. No desktop jobs at all. Have a nice day :) Thomas