You are not logged in.
Seems devuan bugs MX doesnt accept mail without proper hostname (PTR). Maybe debian accepts mail from senders without proper hostname and devuan just copied the reportbug message without adjusting(?). i' suggest configuring smtp using msmtp or any other smtp, or just copy bug report to a regular email and send...
According to a village neighor who lived up to 101 (farmer tiil he died, never bedded), his secret was a glass of red wine each day.. so, who knows. Green tea, red wine, gin tonic... and who wants to live forever after all?
(apart from some super-rich narcisstic scum...)
browser is really heavy on ram.. if you try some other ram-hungry app you'll probably notice segfaults there too.
i would probably share the same 2 cents as @zapper..
been sticking with runit for the last year or so, because it feels so much faster to boot.
one of the cons, i think it's the different way it's implemented across distros.. not easy to get same results as devuan/debian, antix, artix, void, use it differently.. (even though i think antix lately resembled the artix way?). would prefer a similar set of files/scripts across distros, also in order to share missing scripts and make it more widely used, but..., anyway..
xinomilo wrote:p.s. in case anyone wonders, picture is from "Seitan Limania" beach.
I am a bit confused how this Japanese delight got to Greece. But then, I'm confused about a lot of things . . . LOL!
"Seitan Limania" is a name of turkish origin, but meaning and pronounciation will be a lot easier with a small rewrite : "Satan Limania".
freely translate's to "satan's harbours". (name probably had something to do with the strong sea currents in the area.... )
so, even though the island is in between 3 continents, and was a major commercial point once, this name (or any other in crete afaik) had nothing to do with Japan...
@hoas , each place has it's pros and cons.
----
and it goes without saying: if you're ever around, drop me an email.
maybe it was thunar removal that triggered this, not firefox.. (?)
This theme was inspired by the jewel-like waters of the Mediterranean sea where Daedalus was born on the island of Crete:
https://dev1galaxy.org/files/crete_sm.jpg
nice
not really into appearance/theme stuff, but mentioning the island where i live, caught my eye
p.s. in case anyone wonders, picture is from "Seitan Limania" beach.
software-properties-common is available in devuan repos.
users don't usually notice, deb.devuan.org/mirror does all the url rewriting to fetch from debian.
Yes. Your sources are wrong, somewhere (should be deb.devuan.org, not debian).
not really, unchanged debian packages are fetched from debian repo directly..so nothing wrong there. that package just doesn't exist, beowulf packages database was very old, needed an `apt update`.
apt-add-repository << current.repos.list
iirc, this (add-apt-repository) needs some extra package (software-properties-common) to work, doesn't get installed by default, so it's probably not-existent in most devuan systems. not sure if it works at all tbh, i think it's more ubuntu/ppa specific..
you need to do `apt update` to sync packages first. there's no such package in debian repos.
(if you know an opensource platform to share video, I'm all ears)
what do you mean by traffic flood?
tor daemon has to be connected to tor network and needs to keep connection with guard node(s) open, but is usually idling.... never observed anything close to "traffic flood" (if i understand correctly.).
what's the devuan/tor version?
maybe you have some /etc/tor/torrc custom options on? check your conf.
any info on tor/daemon log?
yes it does. it blocks many other tracking/spammy things too..
i find "ublock origin" absolutely necessary to browse modern-day web. and also use some dns-level filters.
don't know mch about policykit, but it can't be a systemd issue... buggy pkexec binary was present since it was introduced back in 2009. (long before systemd entered debian).. so i'd say nothing to do with systemd.
and devuan is already patched, just upgrade..: https://bugs.devuan.org/cgi/bugreport.cgi?bug=658
sd cards are usually /dev/mmcblk0. what's the /dev/sdd then? is it another adapter with a different sd card?
when you get device busy or similar, try restarting and redoing whatever you were trying. maybe better to add `sync` after any dd command also..
if you want to try another gui, gnome-disk-utility might come in handy.
and please provide dmesg and fdisk output as already requested.. probably crap cards/adapters/driver, but without logs, noone can tell for sure.
rolfie, not a miracle (who believes in miracles anyway?). if you read my previous comment, i had similar experience without windoze.
another kingston micro sd still works fine, so i just sent samsung one to recycle bin.. but yes, gparted/dd/utilities and/or sd card and/or adapter and/or driver is buggy. no miracle involved whatsover.
Last time I id this:
sudo dd if=/dev/zero of=/dev/sdc bs=1k count=2048000
that apparently worked, but still the files were visible on a Windows PC.
didn't really work. you only wrote 2G on sdc with that ("count=").
But this time using your version:
sudo dd if=/dev/zero of=/dev/sdc bs=4096 7892631552 bytes (7.9 GB, 7.4 GiB) copied, 364.007 s, 21.7 MB/s
this version correctly writes the whole disk (8G, till no space left...).
---
had similar trouble with a samsung micro sd + 2 different sd adapters (samsung/sandisk).
i could wipe/fix from another system (eg. mobian), and it would work on all systems. but if i tried that on devuan and partner's lmde, it would produce many dmesg errors (fs/io/disk/driver), and make the card unreadable/unrecognisable after a while. (note, all 3 OS's are debian based, so i'm not sure it's the utilities fault. maybe driver?). and it was never stable, had to format from other systems quite a few times.
a 2nd older kingston micro sd card, never had similar trouble.
so i'm not sure where's the issue. could be micro sd issue, could be adapter issue, could be desktop issue, could be kernel/driver issue...
not really an expert, just similar experience.
i gues it's `dpkg-reconfigure libelogind0:amd64` on a multiarch system. (?)
if you have proper beowulf repositories and your system is fully upgraded, you're always on the latest version.
resolver delay is usually caused by ISP nameservers (resolvers).
some routers support editing nameservers so maybe you have luck changing default(ISP) nameservers to other public resolvers, and have your whole lan/devices, resolving(+loading) web quicker..
within your/any OS you can change nameservers and use eg. opennic (as you did on /etc/resolv.conf) or by editing settings in network managers connection.( usually ip settings -> nameservers -> enter your own manually...
another way is to install a local resolver (like unbound), which can also cache domain queries and make them faster...(search around guides on how to set local resolvers like unbound, plenty available online. can also help if needed).
kind-of-a-disclaimer : you would probably get same results when using any other public resolver eg. google, cloudflare, etc. opennic is a volunteer project not tied to internet mafias (ICANN or MAFIA). so, privacy friendly for sure... but anyway, that was my personal suggestion, you can use whatever resolver you like instead.
alternative (since mplayer supports it...) :
sleep 300 ; mplayer -loop 0 loud-song.ogg
btw, i don't think running cinnamon-core "demands" network-manager.. some metapackage could, but you can run any DE without metapackages and keep it simpler / to your needs.
so, you can probably use another network manager (connman?) and purge anything network-manager related..
`sleep 300` means to delay running the following command (=mplayer...), for 300 seconds (= 5 mins.)
not suspend/hibernate the whole computer...
p.s. not using alarm clocks, so i don't have an alternative. still boil the water away occasionally
there's a MIRRORS.txt in repo. you might want to read it for instructions.. specifically :
Once your mirror is running, let us know with a message at libera.chat on the
#devuan-dev channel.
there's also the mirrors@ contact email, and a mailing list for mirror admins : https://mailinglists.dyne.org/cgi-bin/m … an-mirrors
this looks like an error with particular mirror repository. reproducible error here.
so, pick another mirror from the list, `apt update` and retry... works fine here using a different mirror.
it does sound like resolver issue.. you could try with a faster dns server instead of 192.168.1.1 (lan router), to see if that makes things go faster..
eg. pick one from https://opennic.org and add it in the top of /etc/resolv.conf and retry apt...
---
another guess, perhaps you have something like etckeeper or apt-listchanges installed?
packages like that hook into apt and could be slowing it.. (?) it's just a guess, but you could check/post what's in /etc/apt/apt.conf.d .
ls -la /etc/apt/apt.conf.d