[11:05] <bluesabre> knome: Should this bug forever hang around as "Confirmed"?
[11:05] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1314153
[11:06] <brainwash> it's not even an actual bug, or?
[11:10] <knome> bluesabre, it shouldn't, we should fix it
[11:10] <bluesabre> not sure I understand the problem... this is how all ubuntu release upgrades work
[11:11] <bluesabre> or am I mistaken?
[11:11] <knome> ok, so:
[11:11] <knome> 1) user installs xubuntu
[11:12] <knome> 2) user purges abiword, which in turn removes xubuntu-desktop
[11:12] <knome> 3) user upgrades, abiword is installed
[11:12] <knome> that *is* a bug
[11:12] <knome> iirc abiword and gnumeric were the things that this concerned
[11:13] <knome> there is no way to keep the xubuntu default settings packge (and get all the nice branding) but not install abiword on every upgrade
[11:14] <bluesabre> xubuntu-default-settings doesn't depend on xubuntu-desktop or abiword
[11:14] <knome> i can set up a testing environment at some point
[11:15] <knome> all you have to do to test this is install, remove abiword, and upgrade
[11:16] <knome> actually, since i seem to have trusty images, let me try this
[11:16] <ali1234> that's always been a bug
[11:17] <brainwash> xubuntu-desktop only recommends abiword, so I guess that the upgrade process just reinstalls all the recommended packages
[11:17] <knome> bluesabre, but the user doesn't have xubuntu-desktop if they removed abiword.
[11:17] <knome> brainwash, ^
[11:17] <ali1234> it's the reason why you can install ubuntu -> apt-get xubuntu-desktop -> do-release-upgrade, and then sudden your install has turned into xubuntu
[11:18] <knome> but this is not about having xubuntu-desktop
[11:18] <bluesabre> its not about xubuntu-default-settings either, this is a bug in ubuntu-release-upgrader
[11:18] <knome> so how does ubuntu-release-upgrader figure out that it wants to install me xubuntu-dekstop stuff?
[11:19] <bluesabre> dunno, looking into it now
[11:19] <knome> ta
[11:19] <knome> if you need testing, tell me
[11:19] <knome> i'll boot a trusty vm up soon to try this as well
[11:19] <knome> and do an upgrade test while i'm on it
[11:19] <knome> it's just that i need to zsync half of the trusty image :P
[11:25] <bluesabre> :)
[11:25] <bluesabre> also, "Acid pink" https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1374533
[11:25] <bluesabre> :D
[11:25] <knome> yess
[11:26] <elfy> hippies
[11:26] <knome> ;)
[11:26] <elfy> :)
[11:26] <knome> elfy, soon doing an upgrade test with amd64, woohoo ;)
[11:26] <elfy> I saw
[11:26] <knome> only a tad late. ;)
[11:27] <elfy> don't worry too much - I've decided to care as much about testing as everyone else
[11:27] <knome> that's probably a good attitude for this cycle
[11:27] <elfy> mmm
[11:27] <knome> hmm
[11:27] <bluesabre> knome: for the upgrade bug, I see that it was originally set for ubuntu-release-upgrader, but you changed it to xubuntu-default-settings?
[11:27] <elfy> shame that much of team had the same attitude last cycle
[11:28] <knome> did trusty have the black bg bug previously too?
[11:28] <knome> elfy, that is
[11:28] <elfy> knome: at one point yes - xnox was in here talking about it iirc
[11:28] <knome> bluesabre, apparently so ;)
[11:28] <knome> ok, since i have it with the daily
[11:28] <elfy> yea
[11:29] <elfy> there is a bug report for it knome 
[11:29] <knome> i know
[11:29] <knome> just digging it up
[11:29] <brainwash> I remember bugging xnox with this background bug
[11:29] <elfy> aaah - nvm - iirc wrongly
[11:30] <elfy> last time we had a debian background 
[11:30] <knome> yes
[11:30] <elfy> but it does go wrong during every cycle I've had anything to do with testing wise
[11:31] <knome> elfy, that's sad thing to happen
[11:31] <knome> we even changed our wallpaper to be a symlink
[11:31] <knome> to avoid having to change paths in various packages
[11:31] <knome> but now it seems to have some other issue
[11:31] <elfy> I remember that conversation
[11:32] <elfy> so - something is still up with it then - if we've not changed then I guess it's something to do with making everything ok for some phone somewhere
[11:32] <knome> heh
[11:33] <knome> now that we've landed that and seen some bug reports coming in, do we still think it's fine to edit existing installations to have the pink highlight?
[11:33] <knome> it's far more obvious that it's a release-specific thing when you install 14.10, but it can be a bit weird to upgrade to such
[11:34] <elfy> well given that people read release notes as much as topics/stickies - I say change it - perhaps they will read next time ;)
[11:35] <knome> heh
[11:35] <knome> i don't think that helps,
[11:35] <knome> two people have already taken the time to file a bug instead of reading the release announcement ;)
[11:36] <elfy> you're not surprised surely? 
[11:36] <knome> the installation should probably wipe out all their data until they learned to read the release notes, but implementing THAT would be a bit too brutal
[11:36] <knome> of course i'm not surprised
[11:37] <elfy> it does do that if they choose the wrong option ;)
[11:37] <knome> lol
[11:37] <knome> true
[11:38] <elfy> bug 1265192 :)
[11:38] <knome> yep, seen that
[11:39] <elfy> imo unless the installer comes with an autopilot like Airplane then people will always read what they *think* it says 
[11:40] <knome> hehe
[11:40] <knome> yep...
[11:40] <knome> great, done zsyncing utopic amd64
[11:41] <knome> ...aaaand i386
[11:48] <knome> bluesabre, confirming:
[11:49] <knome> 1) clean install, purge abiword, gnumeric and xubuntu-desktop
[11:49] <knome> 2) start upgrade: proposes to install abiword, gnumeric and xubuntu-desktop
[11:49] <knome> what's pulling these in?
[11:50] <bluesabre> Pretty sure its the release upgrader.  Otherwise removing a single app from anything would mean never getting any more new/replaced packages on upgrade.
[11:51] <bluesabre> considering Ubuntu knows how you installed it, this doesn't seem so unlikely
[11:51] <bluesabre> "InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140416.2)"
[11:51] <knome> sure.
[11:51] <knome> but still, i fail to see the logic why it wants to force those packages on me
[11:52] <bluesabre> I'll check out the source code, 430 open bugs is a bit much to wade through
[11:52] <knome> doing another test.
[11:54] <bluesabre> env variables...
[11:54] <bluesabre> RELEASE_UPGRADE_NO_FORCE_OVERWRITE:
[11:54] <bluesabre> - if that is set, no --force-overwrite is used
[11:54] <bluesabre> could be useful
[11:55] <knome> hmm
[12:01] <bluesabre> Yeah, I think it auto-detects based on dependencies... https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/ubuntu-release-upgrader/utopic/view/head:/data/DistUpgrade.cfg#L63
[12:02] <bluesabre> still digging around
[12:02] <bluesabre> this thing is huge
[12:04] <brainwash> ubuntu-release-upgrader is not just a normal upgrade tool, it's actually "smart" :)
[12:05] <bluesabre> I think it makes sense though... Are you running xubuntu 14.04 if you removed xubuntu desktop in 6.06 and then upgraded your way without picking up any of our new packages?
[12:05] <bluesabre> you'd still be listening to music with listen
[12:07] <bluesabre> I wouldn't want to support that upgrade
[12:07] <brainwash> yeah, not a bug after all, the upgrade process is intended to work this way
[12:07] <bluesabre> knome: thoughts?
[12:07] <brainwash> moreover, it's not xubuntu specific
[12:07] <bluesabre> right
[12:09] <bluesabre> maybe the program could be extended with a new KeepRemovedPackages
[12:09] <bluesabre> but I can imagine that being kludgey
[12:22] <knome> bluesabre, did you try what NO_FORCE_OVERWRITE actually does?
[12:22] <bluesabre> I did not
[12:22] <knome> bluesabre, well, users can install listen even if it wasn't pulled in
[12:22] <bluesabre> I know
[12:23] <knome> i mean, it really isn't much different from supporting any system with random packages the user needs
[12:23] <bluesabre> so if somebody removes abiword in 13.10, they should not get light-locker in 14.04?
[12:23] <knome> bluesabre, no, they should not get abiword in 13.10
[12:23] <knome> err, in 14.04..
[12:24] <knome> tiger
[12:24] <knome> hmm
[12:24] <knome> there you go, my testing password
[12:24] <elfy> longer than test
[12:24] <knome> yes, and much more imagination-requiring! :P
[12:24] <bluesabre> but yeah, not a bug in xubuntu-default-settings, a bug in ubuntu-release-upgrader
[12:24] <knome> and harder to type
[12:25] <elfy> :)
[12:26] <bluesabre> because ultimately we're dealing with apt, so the upgrader would need to be extended to diff a base install, see whats missing, and remove that after upgrade
[12:26] <knome> bluesabre, or simply just not install removed packages
[12:26]  * bluesabre is not volunteering
[12:26] <knome> that are recommended
[12:28] <knome> yes, doing "export RELEASE_UPGRADE_NO_FORCE_OVERWRITE=true" gives me the expected results (from my pov)
[12:28] <knome> of course it's a problem if we need new packages to be installed
[12:29] <knome> but IMO it's also a problem if the user is forced to install software they removed
[12:29] <knome> d
[12:29] <elfy> not really sure it's that much of a problem 
[12:30] <knome> to me, it is a problem
[12:30] <knome> if i purge abiword and gnumeric, that means i do not want them
[12:30] <knome> ever.
[12:30] <elfy> I want xchat - always ;)
[12:30] <knome> and it's stupid that i'm forced to get those back on every upgrade, and use my time and bandwidth
[12:34] <knome> ok, another problem
[12:34] <bluesabre> lol
[12:34] <knome> now i can't revert the env var, even if i unset
[12:34] <knome> bluesabre, what are you lolling at? :P
[12:35] <bluesabre> knome: you're complaining a lot about this app to folks that don't develop this app ;)
[12:35] <knome> bluesabre, stuff happens... and really, i'm just laying out my own thoughts, and want feedback from you
[12:35] <knome> and want to know if you consider it as a problem
[12:36] <knome> or if it's best for me to shut down
[12:36] <bluesabre> I don't consider it such a problem. Sure, you're getting things back that you removed, which is a pain
[12:36] <knome> bluesabre, fwiw, even with the no force overwrite bit, i'm getting new packages
[12:37] <knome> like greybird-gtk-theme
[12:37] <bluesabre> But, if the user removes a lot of things, they probably don't really want xubuntu
[12:37] <knome> so it's not like i'm falling behing because i don't have xubuntu-desktop
[12:37] <bluesabre> shimmer-themes broke out into the individual themes for 14.10
[12:37] <knome> yes
[12:37] <knome> which is what i'm saying...
[12:38] <bluesabre> shimmer-themes is an empty file now, you're going to get replacements
[12:38] <knome> i still get that update
[12:38] <knome> even if i don't have xubuntu-desktop
[12:38] <bluesabre> right
[12:38] <knome> what else new packages do we have?
[12:38] <knome> i get inxi too.
[12:39] <knome> for some reason, build-essential is installed for me, but whatever, that's a minor issue.
[12:39] <knome> (this is a clean trusty update, with abiword/gnumeric/xubuntu-desktop purged)
[12:39] <bluesabre> yup
[12:39] <knome> err, trusty install .P
[12:39] <bluesabre> its still an upgrade
[12:39] <bluesabre> so you're getting xubuntu 14.10
[12:39] <knome> exactly
[12:39] <knome> without the packages i don't want
[12:39] <bluesabre> not ubuntu + xfce 14.10
[12:39] <knome> so once i've upgraded,
[12:39] <knome> i'm still using xubuntu
[12:40] <knome> not an anomaly of a system we don't want to support, as you implied before ;)
[12:40] <knome> i'm not saying we should *encourage* people to use this method
[12:40] <knome> but i think it's fair to have it
[12:40] <knome> i guess another possibility is...
[12:40] <bluesabre> so you get everything except abiword/gnumeric in this case?
[12:40] <knome> is there a way to pin a package in a way that it never gets installed?
[12:40] <knome> i believe so
[12:41] <knome> it's hard to compare the lists since i can't revert the var :P
[12:41] <knome> which is one argument against it
[12:41] <knome> let me do a quickish reinstall...
[12:42] <knome> http://paste.ubuntu.com/8447482/
[12:42] <knome> that's the list with the bit set
[12:43] <bluesabre> cool
[12:43] <knome> so again, it's not like that's a broken system after that
[12:43] <knome> not sure how that would work out if one did many many upgrades
[12:55] <knome> ok, let's see what the list looks like without the bit
[12:55] <knome> dun dun dun dun dun
[12:56] <knome> http://paste.ubuntu.com/8447565/
[12:57] <bluesabre> neat
[12:58] <bluesabre> want to add a comment to that bug report then?
[12:58] <knome> not yet
[12:58] <knome> i'll need to check something else as well
[12:58] <knome> and i'm not sure if i want to mention that on a bug report with no disclaimers
[12:59] <knome> actually, i think i know a much better variant
[12:59] <knome> pin the package name with priority -1, and even the upgrader won't install it
[12:59] <knome> now, sure, people can break their systems BADLY with this
[13:00] <knome> but at least there's an easy fix... remove pins and upgrade
[13:02] <knome> the thing that scares me about the bit you mentioned is that it's hardly documented all (try googling with the name!) and all references seem to be really old
[14:00] <bluesabre> its in the README
[14:00] <bluesabre> :)
[14:01] <bluesabre> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/ubuntu-release-upgrader/utopic/view/head:/DistUpgrade/README
[14:19] <knome> bluesabre, right, then that just didn't pop up in the search results (or i missed it)
[16:32]  * vertz pokes brainwash 
[16:38] <brainwash> hi vertz 
[16:40] <vertz> hey
[18:30] <vertz> why is synclient set to VertEdgeScroll = 1 when you have two finger scroll enable?
[18:30] <vertz> and also 
[18:31] <vertz> ~/.config/xfce4/xfconf/xfce-perchannel-xml/pointers.xml has some odd values
[18:31] <vertz> which make you accidently paste whatever you have on clipboard all over the place
[18:31] <vertz> this goes for laptops of course
[18:33] <vertz> synaptics_tap_action array should be set to [0,0,0,0,0,0,0]
[21:08] <vertz> hehe
[21:24] <knome> hmm?
[23:08] <Unit193> Shiny, es is almost there.