^yes, so default for BunsenLabs by, er, default.
Of course users can change that if they want.
It looks as if a call to org.freedesktop.login1 would require systemd anyway: http://www.freedesktop.org/wiki/Softwar … md/logind/
Well... cb-welcome is looking at ~/.config/crunchbang, ie the directory in the user config after it's been installed to the user's home directory.
In #! there's a script in cb-slim which copies the content of /etc/skel into ~/, triggered by an entry in /etc/slim.conf, and which sets another flag in ~/.config/crunchbang so it only runs once.
In Wally, a similar script is in tb-user-setup and it's triggered by a line in /etc/lightdm/lightdm.conf.
In BunsenLabs, bunsen-user-setup will probably do the same job, but there's no reason why it couldn't copy the user config files from /usr/share/bunsen instead of /etc/skel if that was a better place.
These utilities - some of them are very small, but I guess it depends on how much extra space they're going to take up compared with how much extra functionality they provide for how many users...
If we're pushing right at the edge of CD-size then some stuff is going to have to be left to a post-install script, or just the user's own initiative...
Still, moving big GUI stuff like Gimp, for example, to bunsen-welcome should give us a bit of breathing space?
@dbvolvox thanks for the feedback. (Added a note to the cheatsheet about not entering the root password.)
Yes, I had a quick look at the #! cb-welcome script and tweaked it slightly but obviously not enough...
A better version will go into bunsen-welcome with any luck.
Would smbnetfs be a candidate for adding to the default BunsenLabs install?
Files in /etc are supposed to be modifiable by the system admin - which of course means the user in the case of a private computer. However, agreed, there's no reason to modify /etc/skel.
I was referring to the marking of all files in /etc as conffiles during the building of the .deb file. This seems to add complications which we could perhaps avoid by putting the user config files in /usr/share/bunsen or /usr/lib/bunsen...
The goal, as I have already said, is to support various D-Bus session interfaces alongside simple on-click command execution, including mixing the different interfaces: You will be able to just run 'pkill openbox' but also call out to org.freedesktop.login1 for suspend, hibernate, poweroff and resume.
Just out of curiosity - why not systemctl for those last four?
The idea here is to come up with a few portions that at least look good with nothing but commands that will work on all machine (running Bunsen Labs or #!)
That's where the misunderstanding about keyboard shortcuts came from. I thought that's what you meant by "commands".
The Waldorf grey look is certainly very easy on the eye, and would reassure nervous ex-crunchbangers that they're close to home. OTOH, a slight change would show that Bunsen isn't just a Waldorf clone...
I'm personally very happy to leave this stuff in your hands, graphics-aware people - everything that's been posted recently looks great!
Is /etc/skel the right place to put default user config files?
In fact, Debian rather deprecate having a lot of files in /etc/skel. We don't rely on the system to transfer them to new users' home directories because there's a script triggered by LightDM to do that, which could pick the files up from anywhere.
Maybe it would be better to keep them in /usr/lib/bunsenlabs ?
Another point is that any files that are installed in /etc get registered as config files, and protected from updating. That could cause complications that would be avoided by putting our user files somewhere else, maybe?
Anyone who'd like to contribute to the project, what you can do right away:
*) Post your work right here in the forums - graphics, scripts, improved config files...
*) Fork any of the BunsenLabs repositories on GitHub that attract your interest, make some improvements and send a pull request.
*) Join in the discussions here in the forums, especially the "development" sub-forum, where often tricky issues come up that need input.
On Waldorf, with many extra apps already installed:
The following NEW packages will be installed: cli-common libgdiplus libglib2.0-cil libgtk2.0-cil libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-cairo4.0-cil libmono-corlib4.0-cil libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil libmono-security4.0-cil libmono-sharpzip4.84-cil libmono-system-configuration4.0-cil libmono-system-core4.0-cil libmono-system-drawing4.0-cil libmono-system-security4.0-cil libmono-system-xml4.0-cil libmono-system4.0-cil mono-4.0-gac mono-gac mono-runtime pinta 0 upgraded, 23 newly installed, 0 to remove and 0 not upgraded. Need to get 761 kB/7,200 kB of archives. After this operation, 19.9 MB of additional disk space will be used. Do you want to continue [Y/n]? n
So I guess the dependencies thing depends on whether you already have Mono or not.
.bashrc is only invoked by bash, though.
Anyone whose shell is anything else won't get those PATH entries.
FWIW, my understanding:
.bashrc for bash-specific settings, invoked in both console and X sessions.
(I don't think there's any need to source it in any other dotfile.)
.profile for environment variables etc in console logins
.xsessionrc for the same in X sessions
Does that sound right?
twoion, as a relative beginner here I hesitate to bring this up, but your line 73:
readonly pkgversion=$(head -n1 -- debian/changelog | cut -d' ' -f2 | tr -d '()' | cut -d- -f1)
Is cutting off everything after the first hyphen in the version number, right?
According to this, the upstream_version is allowed to contain hyphens, so shouldn't we be cutting off only the debian_revision, ie the part after the last hyphen? Like this, perhaps:
readonly pkgversion=$(sed -rn "s/^.*\(([^)]+)\).*$/\1/;s/-[^-]+$//p;q" debian/changelog)
Or am I misunderstanding something as usual?
Yes, likewise. (Trying to wrap my rusty old brain round the byzantine intricacies of debian packaging atm )
I don't consider myself qualified to say much beyond "I don't know anything about graphics design but I know what I like" type stuff. fwiw I've got so used to the standard #! conky that it does have a certain comfort-zone appeal. In your first post I liked the right-hand conky in the left-hand image of the two at the top the best. The middle one looks nice, but is harder to read.
The conky colours/shades are going to have to be adjusted to match the final choice of default wallpaper I'd say. Many users will just leave it like that. Maybe alternative conkyrc files could be included somewhere in ~/ to match the other provided wallpapers? Even a little script to switch conkyrc's when a different wallpaper is chosen??