You are not logged in.
Introduction
The purpose of this walkthrough is to give the very basics of converting Debian packages to Devuan. This means making sure that there is no hard dependency on systemd in packages. The good news is that it's much easier to package for Devuan right now than it is to learn packaging from scratch, so this is the best time to jump in if you want to maintain packages for Devuan.
It's important to point out that this is not a manual, there is no intention to document everything about Debian packaging in this one page. Rather this guide just shows you how to remove systemd from a package and make sure it is usable for Devuan. You really do not need to be amongst Debian's elite to help out with Devuan packaging, and everything here will be explained as clearly as possible.
@millpond: I posted your question on irc and here's the response. Centurion_Dan is doing most of the packaging for Devuan:
<Centurion_Dan> golinux: it's not scripts, rather changes usually in the debian/rules to disable the reliance on systemd api's
You might also find dev1fanboy's Maintainer walkthrough useful.
IIRC amprolla2 will tag Debian packages that rely on systemd and quarantine them until they can be repackaged sans systemd.
rrq has put a new and effective spam deterrent in place so signatures have been re-enabled.
@pedropt . . . Could you please use quote instead of code tags when appropriate as in above post. Thanks.
@bobemoe @iamwhatiam . . . The best thing I can think of would be to call @CenturionDan in a response to that issue. I doubt he has time to trawl through git to find issues and that would bring it to his attention. I have just done that for both those issues. As to tags/labels . . . you need permissions to create them and actually, I haven't found them that effective.
@katzenmuzak . . . Thanks for compiling that list. Those issues would have to be posted in git.devuan.org to get any attention. The best place I can think of is here but you might be able to dig out more targeted projects also. In addition I would post the list to dng where it might catch someone's attention (but will get 'lost' rather quickly).
The spam situation has been resolved. Spammers are being filtered at the door. But we can't get a break. Now our host's reverse DNS is down so some registration confirmation emails are not being delivered and we're having to manually enable them.
Which is more helpful for Devuan for me to run, Ascii or Jessie? There are a lot of rough edges and thus potentially a lot of bug reports to file. So where do the developers want us to focus attention?
You might want to check what's in jessie-proposed. Those packages may get into RC1 if the feedback is positive and bug-free. Beware that the xfce4-settings package there was broken - I had to downgrade to stable version. Don't know if it's been fixed yet. After RC1 the focus will be more on ascii.
EDIT: This just posted on irc:
<Centurion_Dan> Attention should be on jessie - particularly installation testing and desktop useability issues.
Have you thought about using captcha - http://captcha.net/
Chanku says it requires JS and wants to avoid that..
@Pick2 . . . bots are much more sophisticated now than they were back in '04. I have not noticed any 'groups of spammers'. It's a steady flow. Some domains are more prominent than others but I see no pattern that would ever allow 'account activation' to be disabled. Even if we could get a script to nuke them based on the SFS db, some would still get through. It would however, simplify the process of activating legitimate accounts. The only solution I can see that would be 100% effective is to 'jail' the bots at the door with account activation.
Maybe https://www.stopforumspam.com could be of some use?
We've been using SFS since we went online. The spam domains are well-known to us and we can delete them with confidence. But it is CONSTANT manual labor and some are getting through before we can get to them. This approach is not sustainable. We have not yet found a way to automate deleting those registrations against the SFS database.
The question asked here is whether forum members have any thoughts about or objections to requiring activation of new accounts via admin intervention.
UPDATE: The mod requiring answers to questions worked for a while but now the bots are finding us again.
The best solution I can think of to deal with the bots is to require account activation. A new group with no posting privileges would contain all new registrations. An admin could then delete the bot accounts and move 'legitimate' accounts to the members group. This is distasteful because it is a type of censorship. But it's something I can live with and as the primary 'unverified' bot hunter, would be grateful for.
Chanku and I would appreciate feedback from all of you before we consider implementing this change. So please share your thoughts why you think this is or is not a good solution. Perhaps some of you can come up with some better ideas.
golinux
I can't remember if the root terminal icons weren't in sync between the menu and the panel when I set up my desktop but they are now. I might have changed it in the panel preferences, certainly never via command in the terminal. I change icons all the time in the panel by clicking on properties > edit > icon (just browse to the one you want to use). Done.
I just posted a quick how-to on the sleep button fix over in the Documentation section. If you get a chance to look at it, please et me know if you think it needs anything...
Very nice! Thanks for taking the time to write it up.
I will write it up soon and post in Documentation. If nothing else, you can have endless fun making the 'special buttons' do whatever you want...
Well, I won't be doing that but there are others who might want to. ![]()
Yes, I'd be interested in learning something about all that systemd junk...
Here are the first few nibbles. Probably more to come as I pinged jaromil, nextime and Centurion_Dan . . .
<KatolaZ> golinux: those should be systemd-related scripts installed by other packages
<muep> it is usually harmless for a package to ship a config file for something that is not installed
<golinux> muep: If a package is not installed, why would related config files be sucked in for a non-existent purpose?
<muep> golinux: because packages include those files for the cases where they are installed alongside the thing that does not happen to be present
<muep> and because devuan is using debian packages as-is where they are suitable
<KatolaZ> golinux: and because we should not make the same mistake that all the distros have done
<KatolaZ> i.e., making it impossible to use anything else
<KatolaZ> if a package has scripts for runit or openrc or systemd, why should we remove them?
<KatolaZ> those script will never be executed if runit, openrc, or systemd is not installed
The conversation continues here on botbot.
I was able to whip up a simple acpi event catcher and script to have the sleep button work.
Perhaps you could share your fix in Documentation?
I did notice, in my poking around, that there is a lot of systemd stuff in /etc/systemd/system, /lib/systemd, and /var/lib/systemd. What's that all about? Or did it get sucked in by something I installed maybe?
I also have these components installed and found it 'disturbing'. That question has been asked before - maybe by me - but I can't remember the answer. LOL! I'll throw it up on #devuan and see who bites . . .
Do you have upower installed? That used to be the solution but may not be going forward. There is history in the botbot logs.
Does suspend work from the logout menu?
Is there an easy way for me to have the (beta2) XFCE desktop icon labels text in black?
Just a vanilla installation with everything default.
You'll need to create a .gtkrc-2.0 file in your user directory. Here's an example. Pick and choose the parts you want:
style "xfdesktop-icon-view" {
XfdesktopIconVIew::cell-spacing = 6
XfdesktopIconView::cell-padding = 6
XfdesktopIconView::cell-text-width-proportion = 2.5
XfdesktopIconView::label-alpha = 0
XfdesktopIconView::selected-label-alpha = 0
base[NORMAL] = "#626D31"
base[SELECTED] = "#A0A985"
base[ACTIVE] = "#A0A985"
fg[NORMAL] = "#ffffff"
fg[SELECTED] = "#DDDFD3"
fg[ACTIVE] = "#DDDFD3"
}
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view"There is some additional Xfce Desktop related info in this post.
(and I think whoever made the "white" kernel colour be gray should have a separate talking-to)
I have no idea what your talking about . . . I didn't know a kernel had a color!! LOL!
. . . they said there was to be no other init system, but they saw people leaving, & so capitulated, to 'allow' other init systems . . .
I predict that other init systems won't be 'allowed' for much longer . . .
Thank you fanderal and welcome! It's a little quiet here. Maybe because happy Devuan users ether don't have problems or know how to fix them on their own. Those of us who have gathered here prefer a simple and understandable format. In your words . . . no need to "reinvent the forum wheel". Exactly!!
Here are some tips about how to deal with the humongous tooltips that popup on the xfce 4.10 desktop icons. They are incredibly annoying and distracting. There used to be an option in Settings > Desktop > Icons to toggle "Show icon tooltips" on/off but it has disappeared from xfce 4.10. I was told that option is returning in xfce 4.12.
If you want to disable ALL tooltips add this line to ~/.gtkrc-2.0. Note: Users have noted some problems with this method:
gtk-enable-tooltips = 0If you want to keep tooltips functional, here's how to at least reduce the footprint of the desktop icon tooltips by eliminating the image in the tooltip. This also goes in ~/.gtkrc-2.0. No side effect here but YMMV:
style "xfdesktop-icon-view" {
XfdesktopIconView::tooltip-size = 0
}
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view"Note that if you are using the Clearlooks-Phenix-Purpy theme, this fix to match the purpy wallpaper is already included there:
style "xfdesktop-icon-view" {
XfdesktopIconView::label-alpha = 0
XfdesktopIconView::selected-label-alpha = 0
XfdesktopIconView::tooltip-size = 0
base[NORMAL] = "#000000"
base[SELECTED] = "#94928d"
base[ACTIVE] = "#b5b3ac"
fg[NORMAL] = "#ffffff"
fg[SELECTED] = "#ffffff"
fg[ACTIVE] = "#ffffff" }
# xfce4 stuff
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view"This is a revised 'reprint' of this post to the dng list:
https://lists.dyne.org/lurker/message/2 … 84.en.html
Spammers have started to find us again.
To make this forum less desirable, signatures have been disabled.
If there was a question there, I missed it!
Editing to provide this context from #devuan yesterday:
<Fervi> we need to create virtual package "dbus-session-bus" i think
<Centurion_Dan> Fervi: no we don't. Use dbus-x11
<Fervi> but xfconf require dbus-session-bus, that require dbus-x11. We should add dbus-session-bus or change dependency in xfconf to directly use dbus-x11
<Centurion_Dan> Fervi: ok. I'll fix the dbus package in the next couple of days.
Welcome, norb! And thanks for the report on your successful Devuan upgrade and the kind words. See you 'round!