~$ sudo apt install arora Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5printsupport5 libqt5qml5 libqt5quick5 libqt5script5 libqt5sql5 libqt5sql5-sqlite libqt5webkit5 libqt5widgets5 libxcb-icccm4 libxcb-image0 libxcb-render-util0 libxcb-xkb1 libxkbcommon-x11-0 qttranslations5-l10n Suggested packages: libvisual-0.4-plugins gstreamer-codec-install gnome-codec-install gstreamer0.10-tools gstreamer0.10-plugins-base The following NEW packages will be installed: arora libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5printsupport5 libqt5qml5 libqt5quick5 libqt5script5 libqt5sql5 libqt5sql5-sqlite libqt5webkit5 libqt5widgets5 libxcb-icccm4 libxcb-image0 libxcb-render-util0 libxcb-xkb1 libxkbcommon-x11-0 qttranslations5-l10n 0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded. Need to get 24.2 MB of archives. After this operation, 96.0 MB of additional disk space will be used. Do you want to continue? [Y/n]
Sure, why not? Quite a few extra Qt libs, but I got room.
Get:1 http://ftp.debian.org/debian/ jessie/main libgstreamer0.10-0 amd64 0.10.36-1.5 [1,400 kB] Get:2 http://ftp.debian.org/debian/ jessie/main libgstreamer-plugins-base0.10-0 amd64 0.10.36-2 [1,030 kB] Get:3 http://ftp.debian.org/debian/ jessie/main libqt5core5a amd64 5.3.2+dfsg-4+b1 [1,977 kB] Get:4 http://ftp.debian.org/debian/ jessie/main libqt5dbus5 amd64 5.3.2+dfsg-4+b1 [191 kB] Get:5 http://ftp.debian.org/debian/ jessie/main libxcb-icccm4 amd64 0.4.1-1 [27.0 kB] Get:6 http://ftp.debian.org/debian/ jessie/main libxcb-image0 amd64 0.4.0-1 [24.3 kB] Get:7 http://ftp.debian.org/debian/ jessie/main libxcb-render-util0 amd64 0.3.9-1 [18.0 kB] Get:8 http://ftp.debian.org/debian/ jessie/main libxcb-xkb1 amd64 1.10-3+b1 [37.0 kB] Get:9 http://ftp.debian.org/debian/ jessie/main libxkbcommon-x11-0 amd64 0.4.3-2 [38.5 kB] Get:10 http://ftp.debian.org/debian/ jessie/main libqt5gui5 amd64 5.3.2+dfsg-4+b1 [2,195 kB] Get:11 http://ftp.debian.org/debian/ jessie/main libqt5network5 amd64 5.3.2+dfsg-4+b1 [544 kB] Get:12 http://ftp.debian.org/debian/ jessie/main libqt5widgets5 amd64 5.3.2+dfsg-4+b1 [2,283 kB] Get:13 http://ftp.debian.org/debian/ jessie/main libqt5opengl5 amd64 5.3.2+dfsg-4+b1 [141 kB] Get:14 http://ftp.debian.org/debian/ jessie/main libqt5printsupport5 amd64 5.3.2+dfsg-4+b1 [185 kB] Get:15 http://ftp.debian.org/debian/ jessie/main libqt5qml5 amd64 5.3.2-4 [1,245 kB] Get:16 http://ftp.debian.org/debian/ jessie/main libqt5quick5 amd64 5.3.2-4 [1,051 kB] Get:17 http://ftp.debian.org/debian/ jessie/main libqt5script5 amd64 5.3.2+dfsg-2 [710 kB] Get:18 http://ftp.debian.org/debian/ jessie/main libqt5sql5 amd64 5.3.2+dfsg-4+b1 [115 kB] Get:19 http://ftp.debian.org/debian/ jessie/main libqt5sql5-sqlite amd64 5.3.2+dfsg-4+b1 [41.6 kB] Get:20 http://ftp.debian.org/debian/ jessie/main libqt5webkit5 amd64 5.3.2+dfsg-3 [9,106 kB] Get:21 http://ftp.debian.org/debian/ jessie/main qttranslations5-l10n all 5.3.2-2 [1,077 kB] Get:22 http://ftp.debian.org/debian/ jessie/main arora amd64 0.11.0+qt5+git2014-04-06-1 [790 kB] Fetched 24.2 MB in 16s (1,507 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done grave bugs of libqt5webkit5 (→ 5.3.2+dfsg-3) <Forwarded> b1 - #781194 - libqt5webkit5: Reproducibly crashes with segfault due to missing checks for `HTMLUnknownElement` Summary: libqt5webkit5(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...]
Typically I only say "Orly?" to listbugs when I see "grave". I must admit it looks a lot better than the other lightweight alternatives though.
OH OH! I was testing in Waldorf and I guess I had something else here that hauled in all that stuff as all it got when I got it to test as "arora". There were no bugs here.
Since my wally-jr is a Debian jessie for testing ... I installed arora grave bug and all - YUP ... started:;
it started ... was loading and BUNSEN!! BURN!! OK, time to delete a few things.
30 Mar 15 | 16:20:45 ~ $ saremv arora alias saremv sudo apt-get autoremove --purge --simulate [sudo] password for sector11: Sorry, try again. [sudo] password for sector11: Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: arora* libqt5opengl5* libqt5printsupport5* libqt5qml5* libqt5quick5* libqt5script5* libqt5sql5* libqt5webkit5* 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. Purg arora [0.11.0+qt5+git2014-04-06-1] Purg libqt5webkit5 [5.3.2+dfsg-3] Purg libqt5opengl5 [5.3.2+dfsg-4+b1] Purg libqt5printsupport5 [5.3.2+dfsg-4+b1] Purg libqt5quick5 [5.3.2-4] Purg libqt5qml5 [5.3.2-4] Purg libqt5script5 [5.3.2+dfsg-2] Purg libqt5sql5 [5.3.2+dfsg-4+b1] 30 Mar 15 | 16:21:10 ~ $ aremv arora alias aremv = sudo apt-get autoremove --purge Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: arora* libqt5opengl5* libqt5printsupport5* libqt5qml5* libqt5quick5* libqt5script5* libqt5sql5* libqt5webkit5* 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. After this operation, 56.1 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 90750 files and directories currently installed.) Removing arora (0.11.0+qt5+git2014-04-06-1) ... Purging configuration files for arora (0.11.0+qt5+git2014-04-06-1) ... Removing libqt5webkit5:amd64 (5.3.2+dfsg-3) ... Purging configuration files for libqt5webkit5:amd64 (5.3.2+dfsg-3) ... Removing libqt5opengl5:amd64 (5.3.2+dfsg-4+b1) ... Purging configuration files for libqt5opengl5:amd64 (5.3.2+dfsg-4+b1) ... Removing libqt5printsupport5:amd64 (5.3.2+dfsg-4+b1) ... Purging configuration files for libqt5printsupport5:amd64 (5.3.2+dfsg-4+b1) ... Removing libqt5quick5:amd64 (5.3.2-4) ... Purging configuration files for libqt5quick5:amd64 (5.3.2-4) ... Removing libqt5qml5:amd64 (5.3.2-4) ... Purging configuration files for libqt5qml5:amd64 (5.3.2-4) ... Removing libqt5script5:amd64 (5.3.2+dfsg-2) ... Purging configuration files for libqt5script5:amd64 (5.3.2+dfsg-2) ... Removing libqt5sql5:amd64 (5.3.2+dfsg-4+b1) ... Purging configuration files for libqt5sql5:amd64 (5.3.2+dfsg-4+b1) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (220.127.116.11-5) ... Processing triggers for hicolor-icon-theme (0.13-1) ... Processing triggers for desktop-file-utils (0.22-1) ... Processing triggers for mime-support (3.58) ... Processing triggers for libc-bin (2.19-15) ... 30 Mar 15 | 16:21:33 ~ $
Midori? - not in repos
Netsurf is looking promising - fairly lightweight, yet proper layout handling. I seem to remember being unimpressed with it in Wheezy, but it's definitely usable out-of-the-box in Jessie; if we must have something lighter than Iceweasel, Netsurf looks good.
EDIT: Forget Netsurf. Just tried highlighting some text to copy-paste and it went all cray-cray - no idea what would have ended up on my clipboard.
Last edited by pvsage (2015-03-31 15:25:19)
I've been using Netsurf for a while, it's promising and being developed quickly... but it crashes on many websites without even opening anything, just like that. And not even randomly: there are a few sites that you can never open, ever. You type in the address, hit the Enter key and say bye-bye to shiny Netsurf window with all the shiny open tabs.
Last edited by boromeus (2015-04-01 02:48:00)
^ That's been my experience with Midori and Kazehakase as well; I didn't know how to look up bug tracking when Kazehakase disappeared, but I'd bet its crashing played a major role in its removal from all Debian channels.
Oh dear, all this browser stuff...
I should never have mentioned dillo. 8.(
Maybe I should never have raised the idea of a "bunsen-base" package list at all. I'm really not so sure who would want it now. I thought there might be something to be said for just having the desktop tools and appearance set up and let the user do the rest, but perhaps only a "bunsen-standard" setup would be the better way to go? Have a set of decently-behaved default apps installed, something like CrunchBang in fact, but with Gimp and some of the more peripheral stuff left out, some to be put in the "welcome" script?
Hey, it makes for good chit-chat. I'll be honest, Iceweasel as in Waldorf is fine by me ... other may not like it but I'm thinking od "First Impressions" with a user checking the "Live" aspect of things.
IF - and that's a BIG IF Iceweasel can be present in "Live Mode" but not installed in the "Install Bunsen" function and then show up in the bl-welcome script with some other browser options that would be cool. But I think that would be asking a bit much.
IF - and that's a BIG IF Iceweasel can be present in "Live Mode" but not installed in the "Install Bunsen" function and then show up in the bl-welcome script with some other browser options that would be cool...
Would be cool. We'll have to ask TheSage. I haven't a clue about all that live stuff.
BTW this is the "BunsenLabs Development Team and current status" thread.
Maybe we shouldn't go overboard with chit-chat on what's supposed to be for important announcements...
On the minimal-browser issue: I don't think we should encourage users to use them for the simple reason that most of them are based on libraries and toolkit bindings (webkitgtk, ...) which do not receive nearly the same attention as the Big Ones (Firefox/Iceweasel, Chromium) in terms of development activity and security concern (well, ironically the Big Ones is what the evil people are going for, oh dear).
I haven't checked them all (dwb still seems to be under active development), but IDK that luakit or uzbl are dead (no guearantee though). On teh internetz, they are a liability.
Last edited by twoion (2015-04-02 18:41:10)
Have a set of decently-behaved default apps installed, something like CrunchBang in fact, but with Gimp and some of the more peripheral stuff left out, some to be put in the "welcome" script?
+1, users wanting minimal should just go with a netinst.iso.
bunsenlabs 8) forum mod squad
+1, users wanting minimal should just go with a netinst.iso.
Ref the post-install script: Big GUI apps which aren't included in the install are in the pipemenus eg GIMP, LO, browsers, etc.
They don't need to be in 2 places. The bl-welcome script could just have the more complicated things like printer support, LAMP, dev tools, and text in the welcome screen telling new users that many options can be installed from the menu.
Agreed, basically. Both welcome and pipemenus have come up as ways of getting big stuff out of the standard install. What should go in bl-welcome, what in pipemenus, and if anything could be allowed to be in both places (like #! Libreoffice) needs a bit of thought.
Once done, it's out of the way. Users aren't bothered by things they arent interested in on a daily basis. (ie a pipemenu entry)
Installed apps automatically get their place in the menu.
btw still toying with the idea of an "applications" pipemenu - obamenu is a little python script (just one file) that does no caching or anything in the background, just runs - quickly - when called and puts up a menu of installed apps. If configured not to use icons it fits right into an openbox menu. It doesn't replace the usual openbox menu, just adds a sub-menu like any pipemenu. Purists can comment it out, no harm.
Last edited by johnraff (2015-04-03 03:38:59)
Something else to keep in mind: What first impression do we want to have for a new user have in the "Live" mode?
Loading #! Live got me hooked. I was tired of Ubuntu and wasn't thrilled with Mint, or whatever. Arch looked rad but hard. I didn't see the point in Fedora or suse. Once on #!, just seeing all the dark grey and black with a bunch of numbers and junk (conky) on the right made my mind up to install. Within seconds of operating my new distro I already had a terminal up and script running with cb-welcome!? Loved it. It was badass AND accessible, an aesthetic I hope Bunsen continues.
With that said, a cli browser would have been a bridge too far. A new user is going to be on that more than anything so its worth whatever space it takes. Ubuntu continues to make this mistake with their terribad Software Center, a tool a new user absolutely relies until you figure out apt-get.
Once on #!, just seeing all the dark grey and black with a bunch of numbers and junk (conky) on the right made my mind up to install.
The plan is to keep that for the default look, with a matching dark theme and a couple with *gasp* some color in the default install...
^There is a dark gtk+ theme available in the second post of that second link.
Other colors and styles of themes, wallpapers and icons will be available as "themes-extra", "wallpapers-extra" and "icons-extra" packages and, of course, via forum members and these forums.
Last edited by hhh (2015-04-03 11:45:54)
bunsenlabs 8) forum mod squad
pvsage, I don't think you are getting my pm's or perhaps you are just forgetting to check your pm's regularly (no notifications). Please check your pm and contact me back on my email whenever you have a chance.
My take on how things are moving/likely to move in the context of getting the stuff out. Other devs feel free to add things I've forgotten or got wrong.
Ultimate Goal: an iso file that runs live and also allows installation. Along with this, a Debian-style repository holding the bunsen-specific .deb files, so that they can be updated if necessary/desirable, and upgraded into users' systems.
A "netinstall" install should also be possible, installing a base Debian Jessie system and installing a metapackage from the BL repository that will pull in all the other necessary packages and perform necessary configuration. By that time any install script needed should be very simple.
*) The Live Iso. This is under pvsage's direction, and will allow a live experience of the BunsenLabs setup with the option of installation. Since the iso has to hold a complete system it can only be finalised when the contents of BunsenLabs is, but development is already going forward.
What I've been more involved in lately is the Github Stuff. The rest of this post is about how I think people will be able to use that. Each of the repositories up there will be the source files needed to build a standard Debian .deb file. Most of them are already in that state in fact. Storing in the "source" format means that the content can be changed fairly easily without having to redo the packaging each time.
Stage 1) Using twoion's git2deb script, you can build a deb file from a repo and install it on a test system (eg a virtual machine). This point has been reached already for most repos, though the content is changing daily, and there is no guarantee any will work!
Stage 2) Using an install script, build all the repos in their current state, put them into a local repository and install them from there on top of a Debian netinstall. This script is currently being checked out and should be available for wider testing quite soon. Of course the system it installs will be very unstable, quite likely not to work at all and only intended for people who want to play around with what's going on. A sub-alpha sort of install. It will also be necessary to install megabytes of dev-type packages that wouldn't be needed on a normal system.
Stage 3) When the content has settled down a bit, we can build normal .deb files at this end and put them on GitHub for download. This would simplify install a bit, though upgrades would still need to be done manually.
Stage 4) Set up a Debian-style repository with built .deb files in it. Users will be able to upgrade their systems through apt-get.
Stage 5) Build metapackages and incorporate any necessary postinstall scripts in them, so that the whole netinstall (as opposed to an iso install) could be done by installing one package.
Stage 5.5) By then the iso files should also be ready.
Stage 2) has nearly been reached, stage 3) might not be too long, but the others will be ready when they're ready afaik.
(I'll edit this post to incorporate any corrections/expansions.)
johnraff, i suppose this has been discussed at length, but i didn't follow - anyhow, would e.g. step 1) work on debian stable, or require testing?
I'm anticipating Stage 4 - the first repository so I can easily load multiple machines and thrash the beta/rc packages. A repository requires hosting which implies recurring monthly expenses. I'd like to make a donation but don't see a system in place to do that. Is there a way to make a donation?
programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)
@ohnonot although most of the bunsen packages are pretty much system-independent, nothing has been tested on Wheezy, and some things will definitely not work. Anyway, as step 1) says, this is just for testing purposes on a virtual install of Debian Jessie. Getting a working system out of it would be complicated, and, as the content of the repos is changing all the time, something would probably break. I'd wait till 2) at least if you want to play with a sub-alpha BunsenLabs and help us with bug-fixing.
@cpoakes your wishes are greatly appreciated by everyone involved with this I'm sure, but I'm afraid at the moment no mechanism for handling donations has been put in place. That, and setting up hosting, will have to be dealt with before long but right now everyone is wrapped up in getting the new BunsenLabs system into shape.
What's the anticipated date that stage 5 will be finished? After your fine Wally tutorial, I'm sold on netinstalls.
My question raises another question. How hard would it be to convert an existing Wally setup to a BunsenLabs setup?
One other question...are there plans to put out a rolling version of BunsenLabs? I remember talk about it here in the forums, but I don't remember anything official being stated.
Last edited by KrunchTime (2015-04-13 19:35:55)
Linux User #586672
Come and Die -- Kyle Idleman
Aim for a "Live ISO" release with a nice feel to it, if it's more then a CD size so be it. Once that up and running, then think of another "light" version with a fatter bl-welcome script.
Linux User #586672
Come and Die -- Kyle Idleman
What's the anticipated date that stage 5 will be finished?
Sorry, it's the usual "when it's ready". Anyway ASAP.
another question. How hard would it be to convert an existing Wally setup to a BunsenLabs setup?
Quite hard I'd say, or at least quite messy. That's why Wally isn't presented as a pre-release BunsenLabs, but as a development tool. It will probably be easier to backup what you want to keep and do a fresh install of BunsenLabs (when it's ready ).
I don't think that's going to happen. It would have to be based on Debian Sid, which a number of people here on the forums use and like but requires a certain level of experience to deal with the breakages that occur sometimes. Of course it is possible to upgrade a Debian Jessie system to Sid if you want to.