You are not logged in.
I've also ended up booting to console all thanks to auto remove
.
You should have paid more attention to what was about to be removed then
Read the link I provided in my first post in this thread, it explains this problem and how to fix it.
Sharing $HOME between different distributions can cause problems if the software versions are different and the configuration file format has changed, this will make the files in XDG_CONFIG_HOME (~/.config) non-compatible.
adding /sbin to the path would be ideal, anyone know how to go about this?
Edit ~/.profile and add this line:
export PATH="/sbin:${PATH}"
Then log out & back in again.
FWIW, /sbin should already be included in root's PATH but you have to use
sudo -i
or
su -
If you use plain su (without the dash) then PATH will be set to whatever it was for your normal user.
This change is because beowulf now uses the su command from the util-linux package rather than the version from the login package that ascii uses.
Try
# cp /usr/share/doc/nftables/examples/sysvinit/nftables.init /etc/init.d
# update-rc.d nftables defaults
Then reboot.
I'm trying to install wine-staging
I don't think it's a good idea to add the MX Linux repositories.
AFAIUI the .msi files should be installed automagically by WINE itself, you shouldn't have to do anything. But I may be wrong.
What does this say
aptitude why-not wine-staging-amd64
You may have to install the aptitude package to use that command and I don't think the staging version will behave any differently but anyway...
I download the .msi and I don't know what to do from there.
OK, I don't use WINE so I can only quote from my provided link:
In most cases, the file(s) should be placed in /usr/share/wine/gecko.
how would I go about getting gecko and mono in the repo's?
Doesn't look like WINE is in ascii-backports, ironically
Perhaps try wine-development and see https://wiki.winehq.org/Gecko
There is also mono-complete, does that help?
root@kitsuneon:/home/kairo# sudo apt-get upgrade -Sy
Is that a joke?
FWIW you shouldn't use -Sy, partial upgrades can break Arch systems:
https://wiki.archlinux.org/index.php/Sy … nsupported
See also https://wiki.archlinux.org/index.php/Pacman/Rosetta & https://backports.debian.org/Instructions/
EDIT: try
sudo apt-get dist-upgrade
Replace <release codename> with ascii in /etc/apt/sources.list then update again.
Your sources should look like this:
# /etc/apt/sources.list
deb http://deb.devuan.org/merged ascii main
deb http://deb.devuan.org/merged ascii-updates main
deb http://deb.devuan.org/merged ascii-security main
deb http://deb.devuan.org/merged ascii-backports main
EDIT: you don't need the deb-src lines unless you want to download the source packages.
No.
Try
deb http://deb.devuan.org/merged ascii-backports main
And I disagree with the advice in that link about only enabling backports to install packages — it is "safe" to leave backports enabled (because they are pinned to 100) and doing so allows the packages installed from there to be updated, which can be critical for stuff like the kernel packages.
I had a similar argument about this over at the MX Linux forums, interestingly.
with persons like you in leadership
For the second time: I am not involved with Devuan at all, in any way.
I really think you have an attitude problem.
+1
I don't like your tone and I'm not here to be involved on your personal flame wars.
It's outrageous that you are blaming an absent person, that can't defend himself.
Good luck with your project!
Just in case there is any confusion here: I have absolutely nothing to do with Devuan and my opinions are mine alone and do not reflect those of dev1galaxy.org in any way.
I have no "project" ongoing.
Yes, the OP is trapped in the Big G's filter bubble and should use a different engine.
Also, the interweb is broken. But we knew that.
Dear Head, you realizing that you're posting at Devuan's forum and not the Ubuntu's one?
How many chances you give, finding a novice or even an average Linux user here?
1 in 1, apparently:
https://dev1galaxy.org/viewtopic.php?id=2879
But don't worry, jitterssnowpaw seems to have moved on to MX Linux now and he's pestering their forum instead
It uninstalled libmspack0 that neither installed by playonlinux, nor was previously detected by "apt autoremove".
E485:~$ aptitude why libmspack0
i yudit-common Suggests yudit (= 2.9.6-8)
p yudit Suggests ttf-mscorefonts-installer
p ttf-mscorefonts-installer Depends cabextract
p cabextract Depends libmspack0 (>= 0.4)
E485:~$
So that was because cabextract was removed then, I presume.
It failed to detect the python-wxgtk3.0 and python-wxversion packages
E485:~$ aptitude why python-wx{gtk3.0,version}
p python-wxgtk3.0 Depends python-wxversion
E485:~$
Looks like a circular dependency to me, APT isn't infallible.
The aptitude command auto-autoremoves so it must be "trustworthy", whether the user is also "trustworthy" is another question entirely...
Read this: http://forums.debian.net/viewtopic.php?f=16&t=104157
Reading what little is on the mailing list, it seemed less likely I'd interact with dyne - concerning
anything Devuan.
I think you're being way too harsh, free speech is important in open software development and miscommunications in plain-text media are very common.
Okay, I've worked on the package, and this is the only warning that I'm getting...
W: miyo-update-notifier: binary-without-manpage usr/bin/show-updates
So, my question is...
Is this detrimental to whether the package can be trusted by people who may want to use it?
I don't think so, no. Man pages are nice but hardly essential for a script which has no options.
For scripts that do have options you can use the help2man package to generate a simple man page without having to actually write one yourself.
I would test your package but I use unattended-upgrades and I don't run the notification daemon, sorry.
It looks like it should work though, FWIW.
EDIT: if you wanted to add a man page then include it at (for example) debian/show-updates.1 and then add a file at debian/miyo-update-notifier.manpages with a line listing the location of the man page:
debian/show-updates.1
The page will then be placed correctly by dpkg-buildpackage.
That command should be listed under section 1 of the man pages, man man gives an overview of these in the DESCRIPTIONS section:
The table below shows the section numbers of the manual followed by the types of pages they
contain.1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]
Lintian has some comments about your .deb package:
E485:~$ lintian --no-tag-display-limit miyo-update-notifier_1.0_all.deb
E: miyo-update-notifier: changelog-file-missing-in-native-package
E: miyo-update-notifier: file-in-etc-not-marked-as-conffile etc/cron.d/update_notifier
E: miyo-update-notifier: file-in-etc-not-marked-as-conffile etc/xdg/autostart/update-notifier.desktop
E: miyo-update-notifier: no-copyright-file
W: miyo-update-notifier: description-synopsis-starts-with-article
W: miyo-update-notifier: description-too-long
E: miyo-update-notifier: extended-description-is-empty
E: miyo-update-notifier: maintainer-address-missing MiyoLinux
W: miyo-update-notifier: essential-no-not-needed
W: miyo-update-notifier: no-section-field
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/cron.d/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/cron.d/update_notifier 1000/1002
E: miyo-update-notifier: bad-permissions-for-etc-cron.d-script etc/cron.d/update_notifier 0755 != 0644
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/xdg/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/xdg/autostart/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid etc/xdg/autostart/update-notifier.desktop 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/bin/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/bin/show-updates 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/share/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/share/update-notifier/ 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/share/update-notifier/update-notifier.py 1000/1002
E: miyo-update-notifier: wrong-file-owner-uid-or-gid usr/share/update-notifier/updates.svg 1000/1002
W: miyo-update-notifier: binary-without-manpage usr/bin/show-updates
E: miyo-update-notifier: python-script-but-no-python-dep usr/share/update-notifier/update-notifier.py #!python
W: miyo-update-notifier: executable-not-elf-or-script etc/xdg/autostart/update-notifier.desktop
W: miyo-update-notifier: executable-not-elf-or-script etc/cron.d/update_notifier
W: miyo-update-notifier: executable-not-elf-or-script usr/share/update-notifier/updates.svg
E485:~1$
So I think you need to correct the ownership & permissions for the various files, make the desktop file & .svg non-executable, add a debian/copyright file (GPL ftw!) and debian/conffiles[1] listing the cron & autostart entries.
For the description try this in debian/control:
Description: basic update notifier
A basic update notifier that checks for updates every four hours.
.
When updates are available, a notification and icon will appear in the system
tray and on the desktop. Clicking the icon in the system tray will present a
notification on the desktop that tells what updates are available.
.
The user will still need to upgrade their system via the terminal or Synaptic.
HTH
EDIT: corrected typo in the description.
Why this error message?
Because you used a capital X in the geometry specification, try it again with a lower case x instead.
Isn't backports already pinned in ascii?
Yes.
The Release file has
NotAutomatic: yes
ButAutomaticUpgrades: yes
http://deb.devuan.org/merged/dists/asci … ts/Release
This equates to a pin value of 100 which means that the --target option is need for APT to install packages from there but they will be updated automatically from that repository once installed.
So no preferences file is needed.
plz halp
Looks fine to me.
If you want to use KVM then enable the virtualisation options for your CPU from the firmware ("BIOS") menus.
Does your machine have a Trusted Platform Module? If so and you want to use it then check the firmware menu for the relevant option.
I'm getting stuff like "kvm disabled by BIOS" and "TMP" errors. How do I get to the log to show you
Check /var/log/syslog
I think you mean TPM, which is the Trusted Platform Module.
Do you use KVM? If you don't virtualise then leaving it disabled is probably sensible.
I've tried some commands but those 3 packages are simply being held and nothing seems to make them go away or upgrade them.
ways to get the desktop background image in openbox
Some more alternatives:
Example usage:
hsetroot -cover /usr/share/images/desktop-base/desktop-background
Once a background is set with feh a script is placed at ~/.fehbg and this can be run from the openbox autostart file so that the last chosen wallpaper is kept updated:
sh ~/.fehbg
And here's an automatic wallpaper changer using images in ~/Pictures/wallpapers:
while sleep 600; do feh --bg-scale --randomize ~/Pictures/wallpapers; done &
As an aside, commands in the openbox autostart file shouldn't be backgrounded unless they need to be: test for this by running the command in a terminal, if the prompt is returned then do not add an ampersand — we noticed problems with race conditions in BunsenLabs if ampersands were added unnecessarily.
For example, the nitrogen line does not need an ampersand at the end.