You are not logged in.
Looks like systemd-nspawn is a wrapper around the kernel namespaces feature.
Linux namespaces do NOT require systemd to use.
However, today *none* of the files contain '3040s', which is why in the abbreviated results (there are *far* more records after the last one above) I used 'amazon' as the search term.
Ok, so you've not determined those files are related to the search results HTML response, and they may well be other things - scripts, styles, images, etc.
Unless the files are encrypted, a failure to find "3040s" probably means they have since expired and been removed (especially if it was returning results earlier).
Have you looked at any of the files to determine contents?
Try replacing the ls command for file (perhaps with -z), and then grep the results for "HTML" or "text"?
Ok, well if those are search results that does surprise me.
What's the current blocker? Have you grepped those files for 3040s and 1100 ?
I probably won't do another Libre-antiX respin with them for the time being, or unless I can contact the original artist and clarify the status.
If Mattahan is the original artist, there's an email address on their DeviantArt About page...?
I'm interested in neither the History (which I can obtain with a simple Ctrl-H) nor the Bookmarks, so fail to understand the point of installing that. I want to be able to view the historic pages in a browser, not the History.
Browsers do not store "historic pages" - in certain situations they store the single most recently requested version of a resource in a cache - this is performed at the point when a response is received, so if you requested the same URL yesterday as on the 18th then any previous cached version was already overwritten at that point.
However, I'd suggest it's very unlikely that Amazon caches search results for a week, so if you don't have a copy of the cache data made before it expired, it has likely already been cleaned up by a periodic cache expiry process.
It is generally helpful to identify the command being run - is it apt?
However, I think I'm seeing the same/similar - a ping/traceroute/curl to deb.devuan.org all have a ~60 second delay before responding, which to me suggests a DNS timeout.
Running dig deb.devuan.org returns immediately, and reveals a CNAME to deb.rr.devuan.org (which has multiple A records), but deb.rr.devuan.org itself is responding to ping/traceroute/curl without delay.
If I force IPv4 (e.g. ping -4 deb.devuan.org) then I get an immediate response, whilst forcing IPv6 is eventually timing out with a "Could not resolve host" error.
So, the issue would seem to be that there's no IPv6 AAAA records at deb.rr.devuan.org, and something doesn't like that.
I assume enabling Apt's Acquire::ForceIPv4 option will get around this, i.e. via /etc/apt/apt.conf.d or using apt -o Acquire::ForceIPv4=true update.
Why is it not in the Debian repository?
No idea ...
A (partial) answer to that can be obtained by searching https://wnpp.debian.net - where WNPP is "Work-Needing and Prospective Packages" - more information at https://www.debian.org/devel/wnpp
Searching reveals LibreWolf is one of 3250 requested packages; initially there wasn't a deb package for it, and since the November 2022 comment that there now is one, a maintainer has yet to step forward and adopt it.
I don't know if there is a specific place/process for asking maintainers if any of them want to do so, or if it's left for maintainers to monitor the lists for packages that interest them.
The search page claims 329 installs - not sure where that number comes from; if it's PopCon/similar then that suggests significantly higher actual numbers, given the target audience of LibreWolf.
So it seems the reason it exists in user dir is "because someone asked for it and at that time nobody objected", and the reason it doesn't exist in root dir (or system-wide) is "because when others asked for that, there was disagreement on which program should do it".
I would have expected "login" do it, but since "man login" relinquishes responsibility for session clean up to getty, it seems sensible that that's where clearing the screen should be done.
The bug resolution has a note that console_clear acts on scrollback buffer, which has since been removed from the kernel, so I wonder if that was the reason it was originally needed, and thus appears to be redundant.
There's a comment in the relevant function for agetty suggesting this might be the case:
static void termio_clear(int fd)
{
/*
* Do not write a full reset (ESC c) because this destroys
* the unicode mode again if the terminal was in unicode
* mode. Also it clears the CONSOLE_MAGIC features which
* are required for some languages/console-fonts.
* Just put the cursor to the home position (ESC [ H),
* erase everything below the cursor (ESC [ J), and set the
* scrolling region to the full window (ESC [ r)
*/
write_all(fd, "\033[r\033[H\033[J", 9);
}
Reads like excuses for not fixing bugs. :/
When setting up Devuan, Bash created /home/user/.bash_logout from /etc/skel/.bash_logout which ultimately seems to come from //bazaar.launchpad.net/~doko/+junk/pkg-bash-debian/view/head:/skel.bash_logout:
# ~/.bash_logout: executed by bash(1) when login shell exits.
# when leaving the console clear the screen to increase privacy
if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
It only created this file for regular user (uid=1000), not the root user - I presume that's because root user existed before /etc/skel was populated, whilst regular user was added afterwards.
Seems to me that - if there's a privacy issue - it would apply to all users, so the logic belongs in a system-wide /etc/bash.bash.logout (mentioned in man bash, but doesn't exist on my system.)
However, when logging out of a TTY the screen clears for both root and regular user, even after renaming .bash_logout to disable it.
Anyhow know if there is some situation where this file is relevant, or is it a relic of ancient times that no longer applies?
Well after a week I think I've only hit the new limit on a couple of occasions - both times it was with 2 seconds remaining.
Definitely an improvement on before, when it felt I was constantly hitting the previous limit, and had to wait for ages before reloading.
Thanks.
This...
W: Download is performed unsandboxed as root as file INSERT_PROBLEM_HERE couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
...is a permission issue.
The specified file could not be read by user "_apt" so Apt elevated itself to root user - as it's a warning not an error (W: not E:), it means the action (install) probably still succeeded, but there's a reason Apt runs as its own user, so possibly there are security implications.
The fix depends on which file/directory is causing the complaint - i.e. why can't _apt access it.
In some instances, the solution can be to fix ownership, e.g. chown --changes --recursive _apt:root TARGET
In other instances, it may involve granting read permissions, e.g. chmod --changes --recursive a+r TARGET
And sometimes the above have no effect because the filesystem was mounted with an over-restrictive umask - in which case remount it with, e.g. mount -o umask=022 DEVICE MOUNTPOINT
Alternatively, for the Synaptic-related errors here, see if Synaptic can be configured to put temporary files in a better location (i.e. not inside root user's home dir).
What makes me like (even realy ugly looking) sed code one liners over awk or shell loops is resource considerations.
This code is run once at shutdown. To me it is unlikely that parts of the code are somewhere cached in the CPU caches.
sed has an extremely small footprint (in memory and CPU usage).
Have you actually profiled the different versions to compare resource usage?
Sed itself may have a small footprint, but that means little with a regex pattern which backtracks several times.
The pattern can be fixed, but given the other overheads involved (subshell, scanning and parsing), is it worth it? I don't know, but I would suspect if list pipe loop to be more efficient than if subshell scan pipe parse if loop, and certainly I find it clearer and more readable.
*shrug* This may all be redundant...
Looking at man vgchange the VG name is an optional filter, so not sure why it is necessary to look them up and run the command once for each, when it can simply be run once without the filter for all:
[ -x /sbin/lvm ] && /sbin/lvm vgchange -a n >/dev/null 2>&1
?
I included that follow-up question to try and communicate that the no-systemd aspect is less relevant to what I'm asking.
(i.e any repository could choose to have a no-systemd rule irrespective of whether it was Devuan-specific or not.)
My questions were trying to understand specifically what angle MrReplikant is coming from.
I see multiple potential motivations/possibilities, and didn't want to go off down one track only for it to be irrelevant/wrong due to being on different pages...
On reflection, no need for Awk either, the whole change can potentially be simplified to:
[ -x /sbin/lvm ] && /sbin/lvm vgscan | while IFS=\" read -r _ vg _
do
[ -n "$vg" ] && /sbin/lvm vgchange -a n "$vg" >/dev/null 2>&1
done
Or:
[ -x /sbin/lvm ] && /sbin/lvm vgs --options vg_name --noheadings | while read -r vg
do
/sbin/lvm vgchange -a n "$vg" >/dev/null 2>&1
done
I don't know what this is about, but this line doesn't seem right...
+ vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
Is there a reason this isn't just using vgs --options vg_name --noheadings ?
If so, that sed script is eugh. How about awk -F\" '/"/{print $2}' instead?
Can't be bothered reading it all though
I regret reading it all. :/
There's not much meaningful discussion - just unanswered questions and disillusionment.
Trying to find the answer to the above, seems the deprecation may have been reversed in January?
metadata.ftp-master.debian.org/changelogs/main/d/debianutils/testing_changelog
But anyway this is rendered moot by the new gnu-which package.
So why is the default crappy "which" being deprecated instead of just being replaced with GNU's superior version?
Or is the latter what will be happening but the NewInBookworm page hasn't been updated yet?
2021-09-16 01:44:08 ... GregWooledge which(1) deprecated
[2022-03-28] gnu-which 2.21+dfsg-2 MIGRATED to testing (Debian testing watch)
[2022-03-22] Accepted gnu-which 2.21+dfsg-2 (source) into unstable (Boyuan Yang)
alias which=type
Problem solved?
As tailscale does not seem to be in the Devuan repositories, I don't think there's a workaround.
Tailscale seems to be a WireGuard wrapper, and Devuan does have WireGuard in the repos, so one workaround might involve figuring out the config and using WireGuard directly.
Also, given the "it doesn't appear to be running" message, it's also possible it just uses systemd for running a service - if so the relevant service file can be converted to one compatible with [insert whatever kapqa's Devuan install is using for services].
In any case, Tailscale is a commercial service: so ask their support team and see what they say.
What is this about?
Sorry, I was wrongly assuming it was a commonly known about thing.
It's a feature forum software has for preventing excess server load - on busy forums, complex searching has potential to slow things down, so there's usually a configurable time-limit. I'm pretty certain the 30 seconds here is an over-conservative default of FluxBB.
If I was tasked with setting a value for an unknown/arbitrary forum, in the absence of any data to say otherwise, I'd probably start with 0-3 seconds for registered users, maybe 10-15 seconds for guests, and adjust accordingly if server monitoring suggested searches were causing excess slowdown.
Any chance of getting this time reduced/removed for logged-in users?
At least 30 seconds have to pass between searches.
Full Disclosure: I act alone in this, this is not put on by the Devuan team themselves.
I would like to know who all here has software they have or would like to package for Devuan, but can't due to the limitations on Devuan's official resources. This is following up on the end of the discussion in "My crappy radio player". This is intended to get a better idea of how much "community" software would be out there for Devuan, and whether or not it's enough to make a dedicated community repository worthwhile.
What would be the benefit of a Devuan-specific community repository, as opposed to a Debian-wide one?
Unless you're not intending it to be Devuan-specific, in which case I amend the above to: what would you consider to be the benefits of a Debian-wide community repository?
Is there anywhere I can find info on the Daedalus release?
The information is surely at https://www.devuan.org/os/releases:
testing is where the next stable suite is developed. Software is usually more up-to-date but there may still be issues. testing becomes stable “when it is ready”.
Devuan releases cannot occur before the corresponding Debian release, and nobody knows yet when Debian 12 will be ready, so the same applies to Devuan 5.
What we can do is look at the fact that Devuan 4 (Chimaera) was released October 2021, two months after the August 2021 release of Debian 11 (Bullseye), and note that the projected soft/hard/full freeze dates for Bookworm correlate with Bullseye's dates, so if Debian 12 is released in August 2023, then "some point in Q4" would seem a reasonable estimate, assuming no major surprises.
If Curl needs the --insecure option then it's a certificate issue, otherwise that's probably fine.
If you repeat the Curl command but force HTTP/1.1 with --http1.1 does it make any difference? (I doubt it, but worth ruling out.)
Have you tested non-GitHub URLs, e.g. from git.kernel.org - there's lots of sizable repos there, but https://git.kernel.org/pub/scm/docs/man-pages/website.git/ is only 0.5MB
If that works, I would guess you may have something configured that makes GitHub want to login, e.g. check git config --list | grep github
If it doesn't... is testing with a newer Git from backports an option?