Right. Guys in the trenches. These days most folks think lazy, dirty hick.
Just to stir the conversation up.
Ah! The southern connection.
This is probably bogus for everyone. Definitely if you are not running some applications like emacs.
Bug is for libglib2.0-0 which is not actually in a default install and most people probably don't have it at all.
There is an older bug for this from 4-3-18 that was closed because it couldn't be reproduced.
The new bug from yesterday is posted by some guy claiming to be running Debian testing with kernel 4.4.1.
Stable may be running that kernel but testing surely is not.
tom@stoned:~$ uname -a Linux stoned.lizard 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 GNU/Linux
Stoned Lizard has had the package upgrade installed and works fine.
Looking at bug #894763 which the current bug seems to be a duplicate of
should give you confidence to install the package upgrade.
Current bug is #896019
For people not familiar with it you can look up any bug easily from the bug number which is listed by the package "apt-listbugs" (if you get bug reports from your system that is installed) at
Just copy/paste the bug number to the first search box on that page and hit enter. Handy bugger.
Any bug filed against a package is reported by apt-listbugs. Some, not a lot, are simply bogus like this one. Many are for architectures that you are not running however. That is usually in the apt-list bugs output and you can then safely choose to install the upgrade. Most people are going to be running amd64 (intel or amd 64 bit systems) and so if the bug has a list of architectures and that isn't included it is not likely to be a problem. If no architectures are listed then you should assume it effects all architectures.
You can "hold" a package at the current version by running
# apt-mark hold <package name>
using the package name of the buggy version. To unhold that version you run
# apt-mark unhold
To see what is on hold run
# apt-mark showhold
I use these regularly and find typing them silly (bad typist). So I have
alias hold='apt-mark hold' alias unhold='apt-mark unhold' alias sold='apt-mark showhold'
And folks using distros based on Debian Testing
Got kernel 4.15.0-3 in Sid. Seems to be running well got it about 24 hours ago on my most used install. Should be seeing it in testing in around 10 days (19th or 20th).
Distros based on testing but using their own repos or who configure apt to go for sid kernels may see it sooner. I know that Ubuntu used to get the new testing kernels installed pretty fast when they showed up in Debian Sid but this is 4th month of an even numbered year so 18.04 is due out on the 26th so I don't know if they installed that or not as I am not sure what their rules for new packages are now or if they granted an exception for this kernel or want to wait until the new release settles in for a bit.
Kernels that are in Sid are extensively tested in Debian Testing, by devs primarily, even before being released in Sid so kernels are generally pretty solid before Debian releases them.
Good news is that Gimp 2.10 which I have been awaiting with bated breath has landed in Sid.
Kind of. Actually the package upgrade should be avoided as Gimp ends up being removed due to the lack, currently, of the appropriate gimp-data package to go with it.
I ran the package upgrade to see what happened. Sid is the secondary OS on this drive so not a big deal with me. I am using testing as the primary OS.
I find it strange that gimp and gimp-data have never shown up in an 'apt-cache policy gimp' (or gimp-data) query output. Gimp-data doesn't now either.
If it were there I would install it over on the Sid install. Would have a while ago actually.
Hopefully this means that the Debian crew thinks it is all good and just need to get their act together and get the .debs done and in the repo.
2.10 is supposed to feature non destructive editing which is really the only real disadvantage to using Gimp. It is not a disadvantage to most users but is pretty important to people that really like to do post processing of digital photos for more than just touching them up, cropping and scaling for screen or internet viewing.
I will post further developments on this in this thread.
This sort of thing is more common in Sid than testing but the only real difference between Sid and testing is the 'rule' that RC bugs in packages should not be released to the testing repos. RC bugs being defined as packages that will prevent the OS from booting to the desktop. But this is not that sort of bug at all. It merely removes Gimp. There is no rule that prevents that sort of thing in either sid or testing.
It does make me look at the list of packages to be removed in both sid and testing pretty closely. Have had 2 x11 upgrades this testing cycle (Debian10) in Sid that definitely would have prevented booting to a desktop. Just removed most, or all of, x11 packages and the stuff like any DE that depends on that stuff.
Learned to watch out for that stuff really closely in Ubuntu-testing. They always blamed it on "upstream" (Debian). I always believed that until I installed Debian testing along with the Ubuntu-testing things. Did that, at first, just to get a heads up on the crap Debian was sending to poor Canonical. Then discovered that there were no such problems with Debian testing in about 85 to 95% of the cases where there was a problem in Ubuntu-testing.
This turns out to be caused by Ubuntu not using Debian testing, or even Sid, packages but just grabbing them from the Debian experimental repo. I Debian the testing dev team actually uses those packages in testing to detect bugs and this is why, if using apt-listbugs, there are bugs filed against package that are new to Sid most times. This makes Sid actually more stable than Ubuntu-testing way too often for comfort.
Also goes a long ways in explaining the number of serious bugs that turn up in about every new release of new "stable" Ubuntu versions. This is particularly true of the "regular" Ubuntu versions which are nominally based on Sid but also the LTS versions nominally based on Debian testing. They pull in a LOT of packages straight from the Debian experimental repo for both.
I expect this to not effect Debian testing but I will be watching any Gimp package upgrades VERY carefully in testing until this switch to Gimp2.10 is complete. I have, as a precaution, put the package Gimp on hold in testing.
# apt-mark hold Gimp
I am on the internal drive now doing the update/upgrade chores. No bug filed on the Gimp package and package upgrade installed smoothly tonight on 2 Sid installs in chroot.
I have not tried it yet and am working in Stoned Lizard which is a testing install. Will be booting to my external again when done and will log in to the Xfce Sid install, install Gimp and see how that goes, try it out and see if it works.
Installation went fine. This is definitely still a work in progress though.
~/.gimp-2.8 is still the user land config file not gimp-2.10.
There is a bug relating to the package libmypaint that is associated with gimp. It allows for the use of My Paint brushes to be used in Gimp. Apparently this doesn't work well (if at all). Doesn't bother me as I am not sure what My Paint even is or what platform it is for (I assume Win but it could, I suppose be for Mac). Probably be fixed soon.
People that like dark themes should be pleased. Gimp, since at least 2.6 when I first used it, has had 2 themes. Default and Small.
Now has Dark, Gray, Light(?), and the option of using the system theme. I abhor dark themes. But Dark appears to be the default and when it came up it really wasn't, to me, bad at all. I changed it to the lighter Gray theme and actually used it some there as having the image window part of the tool darker has some real advantages. But changed to using my system theme because when tabbing through the Scaling tool it quit highlighting the box it was on after the second (lowest) pixel count box so I couldn't tell when it was on the Save button but works fine using my system theme.
I do quite a bit of image cutting and then reassembly for mirror images. You have to get the pixels placed exactly right at the outer edges of the "new" image you are laying the segments on. The size of the images in the image pane are slightly different so I will need to experiment to get that sorted out. That is not a big deal, have to do it with every different sized monitor used anyway.
One irritation that I think I am filing a bug on when more coherent is that the images are saved to the file manager display rotated 90 degrees. Open in either Gimp or an image viewer they come up right so it is simply an irritation bug.
Splash screen is new and quite different. Nice. Changed some of the tool box icons. No biggy but it will take me some time to get used to it.
Over all, like the upgrade from 2.6 to 2.8, this looks like a good upgrade.
I am not at all familiar with PhotoShop but folks insist it is better at photo editing. Could be for all I know. All I know is that I am still just learning to do things I used to do in the darkroom. Gimp is a much better photo editor than I am. A better one would be wasted on me. In Gimp 95% of editing is a lot easier than doing it in a darkroom. Over/under exposure is actually easier to deal with than it is in Gimp. Not sure this could be any easier in PS. Really need something like Darktable for that and I haven't figured that application out yet.
They always are trying to tweak things from release to release. Each release team leader has their own agendas and so do all the release sub team leaders.
But this was interesting to look at today.
Definitely getting into the serious stuff.
The "Freeze" period starts in January. First part of that (Transition) is cut from down time wise in half compared to the few I have been playing with. Last time it did seem to drag on way too long with little actually seeming to happen. There was a big surge of stuff leading up to it as people rammed things in so as to get that crap out of the way.
The final - Full-Freeze - is open ended because it is defined as ending when there are no Release Critical bugs and really is down to the opinion of the release team leader. So probably does point to sometime in June of 19.
And - really planning important stuff ahead -
During the Release Team sprint in Cambridge, it was decided that Debian 12 will be codenamed "bookworm".
Debian 12 should be out sometime in 2023 so it is damned important to get this kind of thing nailed down now.
For those yearning for details of such momentous decisions in the past
Version Code name Release date Toy Story character
1.1 Buzz 1996-06-17 Buzz Lightyear
1.2 Rex 1996-12-12 Rex (the T-Rex)
1.3 Bo 1997-06-05 Bo Peep
2.0 Hamm 1998-07-24 Hamm (the pig)
2.1 Slink 1999-03-09 Slinky Dog
2.2 Potato 2000-08-15 Mr Potato Head
3.0 Woody 2002-07-19 Woody the cowboy
3.1 Sarge 2005-06-06 Sarge from the Bucket O' Soldiers
4.0 Etch 2007-04-08 Etch, the Etch-A-Sketch
5.0 Lenny 2009-02-14 Lenny, the binoculars
6.0 Squeeze 2011-02-06 Squeeze toy aliens
7 Wheezy 2013-05-04 Wheezy the penguin
8 Jessie 2015-04-26 Jessie the cowgirl
9 Stretch 2017-06-17 Rubber octopus from Toy Story 3
10 Buster not yet released Andy's pet dog
11 Bullseye Not yet released Woody's horse
Sid "unstable" The next door neighbour
Hope that Devuan works out for you. Elementary?
Actually an Ubuntu based distro which uses the E17 (or what ever the number is now) DE. Can't stand it myself but a lot of people like it.