zsh looks very useful, but maybe relative newcomers who chose that option in bl-welcome would get a bit confused?
Users who want zsh should already know how to make the change themselves (or at least follow HoaS's tutorial), or they're unlikely to benefit all that much...
OTOH I think later on perhaps we could do with a list of post-install tweaks and post-install annoyance fixes (one list or two) with links to forum threads like http://crunchbang.org/forums/viewtopic.php?id=39330 and http://crunchbang.org/forums/viewtopic.php?id=39712
About a bunsen-desktop metapackage, for sure the process of getting one accepted into the Debian repos is very long. We'll do our best to make everything as standards-compliant as we can but this is a case of how many years, not weeks or months. Meanwhile, a BunsenLabs Debian-style repository hosted elsewhere is a possibility and once users had added it to their sources.list then installation would still be pretty easy. As long as it only holds config files, scripts etc then maintainance should not be too hard.
Head_on_a_Stick wrote:damo wrote:
You also need to edit autostart if you want to start a saved Tint2 session instead of the default.
I was meaning to comment on this -- it is not immediately obvious that changes to the autostart file need to be made for both this and the "Conky Chooser" -- would it not be better to have these run as default (using the stock configurations)?
I agree. Yet another tweak to do before everything is finalised
Yes another one for the bunsen-configs todo list. Actually, there are a few already.
Damo, "...before everything is finalised" sounds a bit optimistic to me. There's probably quite a lot of stuff to do yet. Locales for multi-users is something that raised a greenscaled head the other day (bug with lightdm). Some unknown unknowns in the pipeline for sure...
Thank you for this feedback.
The false error message issue is known and has already been fixed in other parts of the script. "Extracting templates from packages: 100%" is not an error, but for some reason apt sends it to STDERR so the script takes it as so. That string will be ignored in future versions of bunsen-welcome.
I don't use pbuilder, but the last time I installed it, it did take a very long time to build the environment. 5 minutes does not necessarily mean it is hanging.
Had no idea Ubuntu had "net installs" back then, in fact I had no idea that they even existed.
Xubuntu, not Ubuntu. I don't think there were netinstalls for Ubuntu. The wiki said to do a "server" install (cli only, basically) off the Ubuntu CD, then the netinstall type stuff to get Xubuntu on top of that. I think it would have been possible to netinstall ubuntu-desktop at that point, but since you've got the whole CD in your hands, not so meaningful, unless you wanted to start off with the freshest packages.
PS The changes in 1) are now in the "test" branch here: https://github.com/BunsenLabs/bunsen-ne … e/test.zip
I have to close up now so can't test it till tomorrow, but if anyone else feels like trying it...
Pandoc's OK too but a bit bigger than the other three.
That's a very good point about Dillo's appearance - it uses FLTK so doesn't take on any GTK theming.
A small nice-looking GTK browser with no features is what we would need to go the html route.
Arora might do it. I remember it didn't work with this and that, but just to display a bit of static html that should be no problem, and it was pretty fast.
...Just tested and it brought in 100MB of QT stuff. >_<
And isn't fast - much slower than dillo.
The search goes on...
@ghorvath thank you again.
1) I see what you mean. The sourced file github_install adds the local source at line 15, after creating the directory but before adding the debs and generating Packages.gz.
I'll try moving that block of code (lines 12~16) down to after line 30.
Copying the deb files individually into the repo could be possible too, just moving the command inside the loop.
I'll try those two changes and check if it breaks anything.
2) Keeping the downloaded tarballs is theoretically possible, but it would mean some rewriting. At the moment the whole process of downloading and building is done (by the git2deb-bl script) in a temporary diectory which is deleted. So we'd need to further hack that script and also add version checking so that if the repo had been upgraded at GitHub a new one would be fetched. I understand the problems of people with poor connections, but I wonder how much longer it will be before we have a real repository online and that whole part of the script will be redundant?
3) Sorry I don't understand this at all.
4) I think a possible way out of this is for bl-welcome to set its locale to C.UTF-8 at the start, so the content of all the message strings is known. Since the script itself is only in English, having apt's error messages in English too should not be too much extra hardship for our non-native English speakers.
Amazed at the lack of response to this, so I'm posting it again, here.
What is there to comment? He needs butter on his bread.
Of course. He said nothing about work in that blog post, but it could easily have been a factor I guess.
Lack of any reason to comment doesn't usually stop the comments...
Thank you twoion.
People who have already installed via the netinstall script can add bunsen-os-release like this:
~/.bunsen-netinstall-logs/upgrade-bunsen-pkgs --add bunsen-os-release sudo apt-get install bunsen-os-release
But be aware that at the moment it breaks software-properties-gtk, should you happen to have installed that.
Can a script like this be added in the debian repository? Signed and all that jazz? So one would debian netinstall, then apt-get install a bunsen-desktop metapackage?
Yes, that's roughly what I'm dreaming of too. Just install the bunsen metapackage and everything will be done. No need for a script at all in fact.
Maybe we could use a markdown>html converter and feed the result to a quick browser? Pretty much any of the lightweight browsers would work for this job (I like dillo but no-one else seems to). Any suggestions for an absolutely simple fast no-frills no-flash no-js no-css browser?
Found these 3 possible converters:
using lua, perl and python respectively, all of which are in BL by default.
@spacex I undestand your point about recommends. In fact there has been a lot of discussion on that very topic, and there are pros and cons both ways. Finally we decided to stay with the Debian default of installing recommends because it allowed future BunsenLabs meta-packages to be more flexible. Users can uninstall one package recommended by a meta without breaking the whole metapackage, which would result in apt offering to uninstall their whole system because the packages had become orphaned.
If package maintainers are more careful of what they recommend and use "Suggests" a bit more often, the situation will improve.
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together with this one in all but unusual installations.
This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.
So the network-manager packager seems to think it would be pretty weird not to install modemmanager too...
For an app that needs a string for the text you could also do 'command "$(<file)" ' or if the app wants something on stdin of course 'command <file' is enough. (Before anyone gets into cat or echo... )
@HoaS Thanks for the groff idea, I tried it with BROWSER=dillo for the speed and it came up fast enough, though the images didn't look too good. OTOH Iceweasel didn't display the images at all - just the filenames. On the whole the pdf version using ps2pdf that Sector11 posted looked nicer and came up just as fast.
Ah, yes, I was looking in bunsen-netinstall-master/bunsen-netinstall-logs, instead of .bunsen-netinstall-logs. I indeed have a nonempty install.log here. (I think it is confusing to have a nonhidden log directory if it is not used.)
Agreed. But the empty log file is in the installer directory. It is copied from there to ~/.bunsen-netinstall-logs before filling it with messages. The idea is that the user will probably delete bunsen-netinstall-master once the install is finished. Also, the location of bunsen-netinstall-master is not guaranteed, the user might have put it in ~/downloads for example, and run it there. It works wherever it is run, as long as the user cd's inside it before running ./install.
I guess in the future I should rewrite that section so instead of copying in empty files from the installer directory it will make the files and directories in .bunsen-netinstall-logs.
As for 2), I rerun the bl-welcome again, but it did nothing, because everything was installed already. But I am about 80% sure that the message indeed was Extracting templates from packages: 100%. It definitely was only one line, containing 100% and had a similar meaning as this sentence (it was in Hungarian, though, sorry).
Ah - now I see the problem. The script looks for certain messages to ignore in English. If the message is in Hungarian it won't match the "ignore" test and the script will assume it's an error. Just ignore it if it looks harmless and continue. I'm not sure if there's any way of fixing that without going for complete internationalization, which is somewhat complex...
Sorry userx-bw, but as we said the script is only meant to install from a new netinstall Debian Jessie. It's for testing BunsenLabs, it's not meant as a tool for users at this point. That will probably come later.
A script to upgrade from CrunchBang Waldorf to BunsenLabs Hydrogen is an interesting idea which might also come later, when BunsenLabs itself is finished.