You are not logged in.

#21 2017-08-19 03:11:35

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 12,560
Website

Re: Ship unattended-upgrades with BunsenLabs?

Thanks for your work on this!

tknomanzr wrote:

I would offer unattended-upgrades with configuration as an option in bl-welcome. Then implement a conky notification as a less intrusive option by default.

OK so that's options 1) + 2) smile Although I'm wondering if conky is necessarily the best output channel, depending on how the user uses their desktop. libnotify-bin is another option, and doesn't tint2 now allow notifications too? Another: a yad window, while more obtrusive, would require some user response - not a bad thing.

We could either go the route that S11 took and just list the number of available updates, or include the package list as I did. I could even implement an arg parser that would allow the user to choose just the number or the number plus the list when calling the script. This would allow for either barebones or a more informative output as desired without having to write another script.

Yes, maybe a choice of output formats, triggered by a cli option, and maybe some kind of "click here for more info"? Though that of course would be more work for you...

I would rewrite the script though, and call the apt update command prior to running apt list --upgradable. At the moment, I have pushed that off as a systemd timer and service.

Would that not then require the script to have root privileges?

note that backports have strange effects on apt list --upgradable, causing the count it returns to be off.

Maybe we could think about filtering for only the security upgrades?

I can speak from experience when I say that a failure in the middle of an update can wreak havoc on an install. Imagine a dist-upgrade involving a couple of hundred packages and your liquid cooler dies in the middle of the dist-upgrade. It was a huge mess...

I don't think unattended-upgrades would ever attempt to do a dist-upgrade. There are options in the config file to do things like break upgrades down into small bits to allow a shutdown in the middle, and the (changeable) default is only to install security upgrades, so usually it would only be a handful of packages. Even so, I'm now convinced we should not install and enable this package by default.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Offline

#22 2017-08-19 03:18:21

Sector11
Mod Squid Tpyo Knig
From: Upstairs
Registered: 2015-08-20
Posts: 8,011

Re: Ship unattended-upgrades with BunsenLabs?

Thank you for the clarification John ... got it now.


Debian 12 Beardog, SoxDog and still a Conky 1.9er

Offline

#23 2017-08-19 06:09:24

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 1,146

Re: Ship unattended-upgrades with BunsenLabs?

Here's me , just back to Bunsen for a break from Windows 10 and forced updates.. looking to be back in complete control, you guys are at the top of a slippery slope that leads to the forced reboots, lost work, and other borkage W10 has already caused me and many others.

The user should be in CONTROL, I don't mind an unobtrusive notification that there's something waiting to get updated, but that's the most anyone should want or need. Why turn into Windows ?

The whole philosophy of Linux is about choice, one of the greatest appeals of #! was being asked by the welcome script what I might or might not like set up.

Anyhow my two penneth, for what it's worth, "Windows Bunsen Update" needs to be asked about so I can say NO to anything beyond a simple notification, and probably to the whole idea.  Though it probably wouldn't matter if it uses systemd timers, I'm running Helium-Dev under sysv-init, so they's be borked anyway.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#24 2017-08-19 15:24:54

DeepDayze
Like sands through an hourglass...
From: In Linux Land
Registered: 2017-05-28
Posts: 1,897

Re: Ship unattended-upgrades with BunsenLabs?

Bearded_Blunder wrote:

Here's me , just back to Bunsen for a break from Windows 10 and forced updates.. looking to be back in complete control, you guys are at the top of a slippery slope that leads to the forced reboots, lost work, and other borkage W10 has already caused me and many others.

The user should be in CONTROL, I don't mind an unobtrusive notification that there's something waiting to get updated, but that's the most anyone should want or need. Why turn into Windows ?

The whole philosophy of Linux is about choice, one of the greatest appeals of #! was being asked by the welcome script what I might or might not like set up.

Anyhow my two penneth, for what it's worth, "Windows Bunsen Update" needs to be asked about so I can say NO to anything beyond a simple notification, and probably to the whole idea.  Though it probably wouldn't matter if it uses systemd timers, I'm running Helium-Dev under sysv-init, so they's be borked anyway.

Hey just  relax. This is just an idea and might not be implemented.


Real Men Use Linux

Offline

#25 2017-08-19 18:33:31

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

Notifications are kind of transient in that they won't have the desired effect unless directly sitting at the computer. Tint2 would offer the best option if we want clicky clicky stuff as I really don't want to muck about with lua in conky. So here is my thinking:

1.) Simple option that just lists number of updates in a conky. This could be the list, the count or both. This is the system that I have used for nearly the life of Jessie but o9000 has offered us some really nice options in tint2 in the interim.

2.) Slightly less simple option that might offer clicky functionality in tint2 which would allow us to pull up a terminal and execute the update/upgrade commands. The more I think about this option, the more attractive it looks. I have a bash script as a nice jumping off point and I believe a little time with the tint2 wiki will allow me to implement something.

I have the kids back in school and have free time at the computer currently so I think I will rework the script for Option 1 and implement the changes already discussed, then will work on Option 2 as the aesthetics of that option really appeal to me. For me, these things always boil down to 4 things: simplicity, choice, aesthetics and sometimes just simple curiosity.

First and foremost, though, my Linux philosophy is a philosophy of choice and will do my best to design this stuff where using it or not will be as simple as  commenting/uncommenting tint2 and/or conky configs.

** Last thing is: I think a yad dialog would probably be a bit too intrusive and annoying, though I could certainly work one up.

Last edited by tknomanzr (2017-08-19 18:37:52)

Offline

#26 2017-08-19 18:55:30

Sector11
Mod Squid Tpyo Knig
From: Upstairs
Registered: 2015-08-20
Posts: 8,011

Re: Ship unattended-upgrades with BunsenLabs?

I'll be here to beta test option 1 for you, I don't use tint2, it interferes with my conkys along the edges of my monitor.


Debian 12 Beardog, SoxDog and still a Conky 1.9er

Offline

#27 2017-08-20 01:24:20

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 1,146

Re: Ship unattended-upgrades with BunsenLabs?

I'm relaxed enough, but been with Windows since 3.1, and seen the mission creep since then all the way through to 10, it's a slippery slope from "users should know and care enough about updates to go find them" (3.1) to "ALL YOUR COMPUTER/DATA BELONG TO US!" (Win 10) We'll update and reboot it regardless what long process you've left running.. if you lose a day's work because we rebooted without even ASKING if you had stuff open you wanted to save TOUGH !!! and i'll resist any automation beyond telling me there's updates I can fetch WHEN IT SUITS ME to my last breath.

I LIKE Bunsen, but there's already enough stuff in it I have to uninstall or disable.

Debian as a whole has lost the plot regarding chioce.. you WILL be assimilated by systemd... resistance is FUTILE.. (though just about still possible), you will be assimilated, or we'll put you through endless borkage till you give up.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#28 2017-08-21 21:52:47

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Ship unattended-upgrades with BunsenLabs?

Just pitching in.

To show notifications in tint2, you could use a systray icon or an executor (but be careful that there's support for the features you use in the stock packaged version). Feel free to ask me if you hit any problems with either.

Conky sounds interesting too.

Automatic updates is something that I have a love/hate relationship with. I do it through cron on all my systems, I've been generally happy with the result, but I don't like how they consume bw on a slow wifi link, or get stuck for minutes when I move my laptop around and there's no connectivity, then the package db is locked so you can't do anything else. All these problems need manual fixing. My vote is: not on by default.

Update notifications is something I hate. With a lot of software installed, they will pop up every day or even more than once per day. That's distracting. They're also annoying when the GUI is clunky, for instance if they require your password every time; or if they take long to load, then ask you for various confirmations, then again take long to run, then ask you for your password, then ask you about restarting or logging out... Personally, I might use them if they were unobtrusive, if they didn't require a password, and informed me if I needed to relog or reboot.

Also keep in mind that even just notifications consume bandwidth. Some may want them completely off.

Last edited by o9000 (2017-08-21 21:55:18)

Offline

#29 2017-08-21 22:03:55

damo
....moderator....
Registered: 2015-08-20
Posts: 6,734

Re: Ship unattended-upgrades with BunsenLabs?

^ Although on a Stable system there won't be many updates generally.


Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#30 2017-08-22 03:30:13

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 12,560
Website

Re: Ship unattended-upgrades with BunsenLabs?

Automation  is a two-edged sword. When all the stars are aligned nicely it saves a lot of boring busy-work so the time can be used on more interesting things. In unforseen corner-cases it can cause major pile-ups that take forever to clean up.

So, if it's used at all it should incorporate checks for all the odd situations the dev can think of, and minimize the damage caused by things (s)he didn't think of. Sometimes getting a balance between constantly pestering the user for confirmation and destroying the system can be impossible.

Back to topic:
1) unattended-upgrades
It looks as if we're agreed NOT to enable u-a OOTB.
Maybe offer to install/configure it in bl-welcome, or maybe just leave it to a forum HowTo?

2) Upgradable notifications
Daily auto runs of 'apt-get update' sound harmless enough, but it's possible to imagine situations when a user might want to put a brake even on that. (eg repo problems, rewriting sources.list...) So, if a script was shipped, it also would have to be enabled explicitly by the user, and we should think of some way (s)he can easily temporarily switch it off.
If we do ship an update notification script, maybe opt for the least intrusive version? ie not like this:

o9000 wrote:

...They're also annoying when the GUI is clunky, for instance if they require your password every time; or if they take long to load, then ask you for various confirmations, then again take long to run, then ask you for your password, then ask you about restarting or logging out...

Although some of that seems to be referring to upgrades not plain updates.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Offline

#31 2017-08-22 03:37:07

damo
....moderator....
Registered: 2015-08-20
Posts: 6,734

Re: Ship unattended-upgrades with BunsenLabs?

How about having it as an item in the Preferences menu?

Preferences -> Updates -> {Install, Enable/Disable}


Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#32 2017-08-22 04:19:39

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

I have re-written the list-updates script to accept arguments on the command line which allows me to split the output for the package count from the actual list. This allowed me to push the formatting back into conky where it belongs (ie the scripts output raw text).

I have also managed to get an executor running in tint2 using the same script that displays the package count as the text, then has a left-click command that pulls up a terminal, outputs the list, informs the user to hit any key, then closes the terminal. It's still a rough first draft and I did end up compiling the latest tint2 to build it. I have not yet tested it on a Stretch machine, although the versioning listed in the tint2 wiki for executors seems to suggest that Stretch's version should be able to handle it.

I am imagining the left click command should be a script that semi-automates the sudo apt update & sudo apt upgrade commands from the terminal, along with apt list --upgradable. This should not be too difficult to implement as I believe @johnraff likely has most of the code written in bl-welcome already. One of the things that attracts me to this approach is that it would make it really easy to integrate backup scripts in this particular script and take backups prior to upgrading. I was using something similar to this with btrfs, btrfs-snapper and apt-btrfs-snapper but didn't quit have everything accounted for with the backup scripts at the time. Backups are  personal to each particular user's use case and storage architecture, so I would not presume to try to implement a backup script for a base BL install, but I would definitely modify a script like this to suit my needs

I have pushed all current changes to My Github but would like to get this one last script built, likely tomorrow prior to posting a bunch of code and configs here.

Give me another day or two and I will have some code and screenshots to peep at.

Last edited by tknomanzr (2017-08-22 04:28:32)

Offline

#33 2017-08-22 05:03:49

Sector11
Mod Squid Tpyo Knig
From: Upstairs
Registered: 2015-08-20
Posts: 8,011

Re: Ship unattended-upgrades with BunsenLabs?

johnraff wrote:

Back to topic:
1) unattended-upgrades
It looks as if we're agreed NOT to enable u-a OOTB.
Maybe offer to install/configure it in bl-welcome, or maybe just leave it to a forum HowTo?

Bold Italics mine. <<-- that's where I think we should go with this.  This is messing with something under the hood that the user should be 100% responsible for.

It's also why we have "hold" and "unhold" commands.

I for one, after reading and following this idea for a while, will turn it off and probably remove "u_a"

I like the idea of a "notice" (as it sits in my conky at the moment - 0 or a number - thanks to tknomanzr)

Having said that we are all use to doing an update|upgrade and the odd times it doesn't go 100% smooth as silk that automation would be a reminder of the infamous "BSOD" - OK, that's extreme, but I would prefer not having to try and find the log file that shows the OOPS! of the automated update that went OOPS! and have to undo it.


Debian 12 Beardog, SoxDog and still a Conky 1.9er

Offline

#34 2017-08-23 14:51:27

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

Update Service

So I have a couple of different ideas worked up. I have a systemd update service built along with a completely reorganized conky script and another script built up that is for a tint2 executor. I have reorganized my github to break this into three separate units. I would prefer to deal with them one at a time.

This service  is simply an update service that ensures that apt update gets run periodically. It would be possible to build this as a cron job but I chose to build it as a systemd timer and service.

Installation

I do not yet have an automated way to install this service at the moment, so it is necessary to install the files by hand.
https://github.com/tknomanzr/scripts/tr … te-service shows three files. We will need all three of these files to build our updates service.
First, we need to copy the files debupdates.service and debupdates.timer into /etc/systemd/system.
Next, copy the file debupdates to /usr/local/bin.
Finally, enable the service with sudo systemctl enable debupdates.timer

cd ~
mkdir updates-service
git clone https://github.com/tknomanzr/scripts/tree/master/update-service
cd updates-service
sudo cp debupdates.service /etc/systemd/system
sudo cp debupdates.timer /etc/systemd/system
sudo cp debupdates /usr/local/bin
sudo systemctl enable debupdates.timer
sudo systemctl start debupdates.timer

Remember, only start the timer in systemctl. The timer will call the service when it needs it and the service will call the shell script debupdates in /usr/local/bin.

Now for sources:

debupdates.timer

[Unit]
Description=Checking for Debian Updates.....

[Timer]
OnBootSec=15s
OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

debupdates.service

[Unit]
Description=Service file to run Debian Updates
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/debupdates

Please not that debupdates.service has no install section in it. If you try to enable this service, it will throw an error telling you it lacks an install section. Enable the timer instead.

Finally, the last file is a shell script called debupdates. I chose to put it in /usr/local/bin. It is likely best to keep it in a directory owned by root, because if you copy it into $HOME, your permissions and ownership will likely change.

/usr/local/bin/debupdates

#!/bin/bash
systemd-cat sudo apt update
exit 0;

The main thing to note about this script is the systemd-cat command. This will redirect all of apt update's command output into journald, so that it can be viewed via journalctl. This is a good way to keep tabs on the service and ensure it is running properly.

The next two notification systems I will post will depend on this service.

Offline

#35 2017-08-23 15:44:49

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

Conky Notifier

My next solution involves conky and is perhaps the most passive of the update notifications that I have written. It depends on having the debupdates.service being installed and running, so please refer to the above walk-through if you have not already done so. In short, I re-wrote the list-updates script to allow for either a count of pending updates, the list, or even both. It implements an arg parser to accomplish this. Also, I have removed all conky formatting variables from it's output. It now only outputs raw text. It is up to the conky meister to handle their own conky formatting.

This setup involves two parts: the first is list-updates which you should place in ~/bin and the second is a slightly modified Bunsenlabs default .conkyrc which can be found in ~/.conkyrc. I am assuming the user has some familiarity with our conky management system in this walk-through.

Install
So the needed files can be found at https://github.com/tknomanzr/scripts/tr … ky-updates

cd ~
git clone https://github.com/tknomanzr/scripts/tree/master/conky-updates
cd conky-updates
cp list-updates ~/bin
cp .conkyrc ~

Useage

Executed with no arguments produces no output. I should probably figure out how to implement some sort of sensible default for the script when run without arguments.

list-updates --count

~/bin/list-updates --count

produces the following output:

tknomanzr@wtfbox:~/bin$ ./list-updates --count
2 updates
tknomanzr@wtfbox:~/bin$ 

It is also possible to get the list of updates from the script.

list-updates --list

~/bin/list-updates --list
libxml2/stable 2.9.4+dfsg1-2.2+deb9u1 amd64 [upgradable from: 2.9.4+dfsg1-2.2]
libxml2-utils/stable 2.9.4+dfsg1-2.2+deb9u1 amd64 [upgradable from: 2.9.4+dfsg1-2.2]
tknomanzr@wtfbox:~$ 

There is a --number option which is supposed to help limit output. At the moment, it remains untested as Stable is not likely to produce enough updated packages to need to limit the list. I will need to setup a Sid install in order to test it, most likely. Also, short options in getopt are not presently working correctly, so I am not actually parsing them. I was having difficulty accessing the argument after -n for processing so I disabled it for the time being.

list-updates --help

tknomanzr@wtfbox:~$ ~/bin/list-updates --help
--count will print the number of updates to stdout.
--list will print the list of updates to stdout.
--number the number of lines in the list of updates to ouput.
defaults to 20.
--help is this help.

Implemented in a conky

So we can post this output into conky like this:

${execpi 3600 ~/bin/list-updates --count}
${execpi 3600 ~/bin/list-updates --list}

The below image is one of my personal conky's showing the notifiers in action.
Click to see the whole image
conky_screenshot_list-updatescf4cb.th.png
The last few lines of this conky shows the update notifiers in action. First, I have the count, then below that, I print the list. Notice that there is a bunch more flexibility for the formatting now since I separated the text from its formatting.

Offline

#36 2017-08-23 16:58:47

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

Tint2 Notification System

The final solution I worked up involves the use of a tint2 executor. These have been available since 0.12.4 and I believe apt-cache policy tint2 produced 0.12.12 for Stretch, so this should work for Stretch. However, I built it using a compiled tint2 current branch which is 0.14something, so I need testing for this one.

As before, this program depends on debupdates.service to be installed and running. It also sources /usr/lib/bunsen/common/bl-include.cfg for connectiontest, safeUpdate and safeUpgrade functions. We shall see why in the Useage section. It also uses list-updates --count for its label so it is necessary to ensure that list-updates is located in ~/bin.

Installation
Ensure you are running at least Stretch. I need to know if this will work in Stretch. I know for sure it will not work in Jessie.
There are three files from https://github.com/tknomanzr/scripts/tr … t2-updates. Put bl-updates into ~/bin. Also, place list-updates into ~/bin. Modify ~/.config/tint2/tintrc with the following executor. I also chose to box it with a couple of separators. You need a separate separator instance per separator you want to use on the panel:

#-------------------------------------
# Separator 1
separator = new
separator_background_id = 0
separator_color = #777777 87
separator_style = dots
separator_size = 3
separator_padding = 1 0

#-------------------------------------
# Separator 2
separator = new
separator_background_id = 0
separator_color = #777777 87
separator_style = dots
separator_size = 3
separator_padding = 1 0

#-------------------------------------
# Executor 1
execp = new
execp_command = ~/bin/list-updates --count
execp_interval = 60
execp_has_icon = 0
execp_cache_icon = 0
execp_continuous = 0
execp_markup = 0
execp_tooltip = Left click opens a terminal that will update/upgrade your system. Click to proceed.
execp_lclick_command = x-terminal-emulator -e ~/bin/bl-updates; exit
execp_rclick_command = 
execp_mclick_command = 
execp_uwheel_command = 
execp_dwheel_command = 
execp_font = Sans 10
execp_font_color = #ff0000 100
execp_padding = 2 2
execp_background_id = 8
execp_centered = 1
execp_icon_w = 0
execp_icon_h = 0

We also need to modify the panel_items code to look like so:

panel_items = LT:E:SC

I chose two separators to visually separate the update notifier from the system tray icons. The important work however , is the execp_command which is going to use the same list-updates program as for the conky notifier to get an update count and use it as the executor's label.

Also, note the execp_lclick_command = x-terminal-emulator -e ~/bin/bl-updates; exit.  The exit at the end of that command is important as it allows tint2 to dispose of the terminal that comes up when you click. So let's discuss useage

Useage
When tint2 loads, it will display an update count based on output from ~/bin/list-updates --count. This label is clickable. When you click on the label a terminal instance is opened and the script ~/bin/bl-upgrades. This script uses previous Bunsenlabs work to do a safeUpdate, safeUpgrade, checkconnection.  It will ask for confirmation at each stage, i.e. update and upgrade. Exiting the program should dispose of the terminal.

Screenshots
Tint2 running Update Notifier
Screenshot_2017-08-23_11-30-44.th.png
First screen on click
tint2-update-screen1.th.png

from there a connection test,  apt update,  and apt upgrade will commence. These are all using functions sourced form bl-includes.cfg. At the end of the process, the user should get a prompt to press a key to close the terminal. Once pressed, the terminal will be disposed of. Keep in mind, having When the command exits, hold the terminal open option set in terminator will likely override my exit commands and create potential problems.

bl-updates source

#!/bin/bash
# A script that will allow the user to semi-automatically run 
# sudo apt-get upate
# sudo apt-get upgrade
# This script can be used as is but was more designed
# to work with the executor in tint2
# Large parts of this script have already been produced by the
# BunsenLabs development team.
#
# Author: William Bradley
# Email: webradley9929@gmail.com
# Git Location: https://github.com/tknomanzr/scripts/tree/master/list-updates
# Date: 8/22/2017
#----------------------------------------------------------------------------

BL_COMMON_LIBDIR='/usr/lib/bunsen/common'
if ! . "$BL_COMMON_LIBDIR/bl-include.cfg" 2> /dev/null; then
    echo $"Error: Failed to locate bl-include.cfg in $BL_COMMON_LIBDIR" >&2
    exit 1
fi
clear
echo "Bunsenlabs Update|Upgrade script"
echo "---------------------------------------------------------------------------"
echo "This script can be run standalone or via an executor in tint2"
echo "This script will update/upgrade your Bunsenlabs system."
echo
read -rsn1 -p"Would you like to proceed with this update/upgrade of your system? [Y|n] " $REPLY;echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
	# Test for vaild internet and do the update
	connectiontest 1
	safeUpdate
else
	echo "You still have pending package upgrades." 
	echo "Rerun this script to upgrade your system asap."
	exit 0
fi
# Get the list of updates
readarray -t updates <<< "$(apt list --upgradable 2>/dev/null)"

# Get the number of updates
numupdates=$((${#updates[*]}-1))

echo "You have $numupdates pending updates"
safeUpgrade
# Wait for input to close terminal
read -p"Press any key to close this terminal."
exit 0

Offline

#37 2017-08-23 17:51:44

damo
....moderator....
Registered: 2015-08-20
Posts: 6,734

Re: Ship unattended-upgrades with BunsenLabs?

^ BL has Tint2 v0.14.6 in our jessie-backports repo. The debs are here: https://eu.pkg.bunsenlabs.org/debian/pool/main/t/tint2/


Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#38 2017-08-23 18:00:59

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: Ship unattended-upgrades with BunsenLabs?

That is great news. So worst case scenario, it works with a backported tint2.

Offline

#39 2017-08-23 18:05:30

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 2,741

Re: Ship unattended-upgrades with BunsenLabs?

How is this for a short one.

Last edited by brontosaurusrex (2017-08-23 20:46:59)

Offline

#40 2017-08-23 18:23:15

damo
....moderator....
Registered: 2015-08-20
Posts: 6,734

Re: Ship unattended-upgrades with BunsenLabs?

tknomanzr wrote:

That is great news. So worst case scenario, it works with a backported tint2.

@nobody is pretty quick at upgrading the package after new Tint2 releases, so we are never far behind the bleeding edge smile


Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

Board footer

Powered by FluxBB