[20:01] <cariboo> I see most of us are here, are we ready to start the meeting?
[20:01] <oldos2er> ready if you are, cariboo
[20:01] <cariboo> or should we wait a few minutes for the laggards
[20:04] <slickymaster> I'm here
[20:06] <cariboo> #startmeeting
[20:06] <meetingology> Meeting started Sun Mar 19 20:06:29 2017 UTC.  The chair is cariboo. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:06] <meetingology> Available commands: action commands idea info link nick
[20:07] <cariboo> #chair slickymaster oldos2er howefield cariboo
[20:07] <meetingology> Current chairs: cariboo howefield oldos2er slickymaster
[20:08] <cariboo> Do we have anything that needs dissuasion here, such as our twoo missing forum staff?
[20:09] <oldos2er> We know why one's gone. Not sure abt the other
[20:11] <cariboo> MAFoElffen is gone because of school and work commitments, but we left things open in case he found the time for the Forum
[20:11] <oldos2er> Ah, I misunderstood, sorry
[20:11] <howefield> both genuine RL commitments, as I undersand.
[20:11] <cariboo> I guess this should be a topic
[20:12] <cariboo> #topic
[20:12] <cariboo> missing forum staff members
[20:12] <cariboo> oops that should be
[20:12] <cariboo> #topic missing staff members
[20:14] <oldos2er> Has anyone tried to email MAFoElffen?
[20:14] <howefield> I'd suggest moving to former staff and rolling out the welcome mat for both as and when/if they are able to return.
[20:15] <cariboo> that was my thought
[20:16] <slickymaster> +1 from me to that
[20:17] <oldos2er> fine by me
[20:17] <cariboo> Do we need to vote on the matter?
[20:18] <howefield> it was left to MAFoElffen to keep us in the loop
[20:18] <oldos2er> I see
[20:18] <howefield> as to how things were going for him, but no, for my part I haven't emailed.
[20:18] <slickymaster> we can vote cariboo
[20:18] <cariboo> #vote
[20:18] <meetingology> Please vote on:
[20:18] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[20:19] <oldos2er> I'll try to do that in the near future
[20:19] <oldos2er> +1
[20:19] <slickymaster> +1
[20:19] <cariboo> +1
[20:19] <slickymaster> you forget to add what we are voting on, cariboo
[20:19] <cariboo> I see that, I try again
[20:20] <cariboo> #endvote
[20:20] <meetingology> No vote in progress
[20:20] <cariboo> #vote to move the two missing members to former staff
[20:20] <meetingology> Please vote on: to move the two missing members to former staff
[20:20] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[20:20] <howefield> +1
[20:20] <meetingology> +1 received from howefield
[20:20] <slickymaster> +1
[20:20] <meetingology> +1 received from slickymaster
[20:20] <cariboo> +1
[20:20] <meetingology> +1 received from cariboo
[20:20] <oldos2er> +1
[20:20] <meetingology> +1 received from oldos2er
[20:21] <cariboo> #endvote
[20:21] <meetingology> Voting ended on: to move the two missing members to former staff
[20:21] <meetingology> Votes for:4 Votes against:0 Abstentions:0
[20:21] <meetingology> Motion carried
[20:21] <cariboo> Anything else?
[20:21] <slickymaster> baps?
[20:22] <oldos2er> Same action?
[20:22] <cariboo> Much as I hate to do it yes.
[20:23] <oldos2er> Agree with your sentiment, but I think it's something we can't ignore.
[20:23] <slickymaster> exactly
[20:24] <cariboo> #vote move bapoumba to former staff
[20:24] <meetingology> Please vote on: move bapoumba to former staff
[20:24] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[20:24] <cariboo> +1
[20:24] <meetingology> +1 received from cariboo
[20:24] <slickymaster> +1
[20:24] <meetingology> +1 received from slickymaster
[20:24] <oldos2er> +1
[20:24] <meetingology> +1 received from oldos2er
[20:24] <howefield> +1
[20:24] <meetingology> +1 received from howefield
[20:24] <cariboo> #endvote
[20:24] <meetingology> Voting ended on: move bapoumba to former staff
[20:24] <meetingology> Votes for:4 Votes against:0 Abstentions:0
[20:24] <meetingology> Motion carried
[20:25] <slickymaster> I think one of us should mail her in the name of the FC explaining it to her
[20:26] <cariboo> I emailed her about 6 months ago, and never got an answer
[20:26] <oldos2er> Nevertheless, we should. I will if need be.
[20:26] <slickymaster> thanks oldos2er
[20:26] <oldos2er> Sure
[20:27] <cariboo> Thanks oldos2er
[20:27] <oldos2er> No problem
[20:28] <slickymaster> think that's pretty much what we had to discuss
[20:29] <cariboo> The only other thin I've got is that QIII has to buy the doughnuts, as he missed his FC meeting as an FC member :)
[20:29] <oldos2er> lol
[20:29] <oldos2er> And coffeecat can bring, obviously, the coffee
[20:30] <oldos2er> Any other concerns?
[20:30] <slickymaster> no here
[20:30] <slickymaster> s/no/not
[20:30] <oldos2er> ok
[20:31] <cariboo> So if that's it, I'm going to end the meeting.
[20:31] <oldos2er> Someone just made an appearance
[20:31] <slickymaster> cooffecat just arrived
[20:32] <coffeecat> sorry about that - something unavoidable came up
[20:32] <cariboo> no problem, I was just about to end the meeting
[20:33] <cariboo> we can bring you up to date in the other channel.
[20:34] <cariboo> #endmeeting
[20:34] <meetingology> Meeting ended Sun Mar 19 20:34:04 2017 UTC.
[20:34] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-03-19-20.06.moin.txt


 Tests are mostly green, except for pinentry, which I submitted https://code.launchpad.net/~mitya57/britney/hints-ubuntu-update-pinentry/+merge/382109 for.
 Great. Did a retry of flaky tests this morning, so good they worked!
 Thanks, I guessed that someone already retried them :)
 xdg-desktop-portal-kde/riscv64 unsatisfiable Depends: xdg-desktop-portal
 hope that is not blocking. other ones like say they are being ignored
 https://launchpad.net/ubuntu/+source/xdg-desktop-portal-kde/<IP_ADDRESS>-0ubuntu1/+build/19126111 was just build, so in the next britney run the same situation would be in -release. Hopefully it will see that it's not a regression.
 Hm, no, it was built on April 7th, but for some reason "pending publication"
 I'm sure it can get hinted through some way, even if so :)
 Right
 @mitya57 [Tests are mostly green, except for pinentry, which I submitted https://code.laun …], hint updated
 Great!
 no migration on that run
 @mitya57 would you normally delete the ppa at this point? nothing is being considered due to the ppa grouping
 I usually wait until Bileto automatically deletes it.
 But if you think it should be deleted, please go ahead and push the button :)
 @mitya57 [I usually wait until Bileto automatically deletes it.], well, that happens when you finalise the ticket. guess that is what I mean
 which also would do no harm
 Do you want to delete it or to keep it?
 @RikMills [well, that happens when you finalise the ticket. guess that is what I mean], I think Bileto automatically finalizes ticket when all packages land in -release.
 @mitya57 [I think Bileto automatically finalizes ticket when all packages land in -release …], Not for landings I have ever done
 That is definitely the case with merge proposal based tickets. Maybe it doesn't happen when there are manually uploaded packages, I don't remember.
 Doing it anyway, as it will do harm, and does sometimes seem to break the grouping policy. Won't make it migrate, but will make it show more clearly the blockers
 Ok, please do then. Thanks.
 Also sometimes uploading a new version of one of the grouped packages seems to break the grouping policy. will save that for later if this does not help
 I have had to fight this grouping thing with kde stuff
 Oh, libreoffice autopkgtest failed for qtx11extras
 Retried, but it will take 4 hours (or more if it times out again)
 Oh cr@p
 Somehow I didn't notice it earlier, sorry
 Let's hope it migrates during the night
 indeed. or if not, hopefully britney will be clear on what needs a hint
 Right.
 Good night


[00:00] <tzero> OHH bzr is like git and the bzr bd is just some convenience thing so you have to type bzr more?
[00:01] <infinity> "so you have to type bzr more"... I like that.
[00:01] <tzero> `bzr status` = ... unknown: the missing files -.- hahaha
[00:01] <infinity> That belongs in the docs.
[00:02] <infinity> tzero: bzr is a revision control system, yes, and "bzr bd" is essentially just shorthand for "bzr export $location && cd $location && dpkg-buildpackage"
[00:03] <tzero> oh man, totally burned. That makes more sense now. Thanks a zillion, I was just cruising through the guide and didn't realize it
[02:24] <psusi> can anyone tell me where the ubuntu mesa sources are?  the bzr repo on lp is out of date and the Vcs-Git: header points to the debian repo
[03:38] <lamont> who do we know who knows gtk, dbus, and network interfaces to some degre?
[03:38] <lamont> https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1377963 annoys me
[04:19] <pitti> Good morning
[04:33] <pitti> Mirv, tvoss: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_trust-store_1.1.0+14.10.20141007.4-0ubuntu1.diff
[04:34] <pitti> tvoss: ordinarily *.mo files must *not* go into libraries, as the files would conflict on the next soname bump
[04:34] <tvoss> pitti, ah, where do I put them?
[04:34] <pitti> tzero: so this is only they should normally go into some arch: all -common package, or perhaps trusty-store-bin or so
[04:34] <tvoss> -bin?
[04:34] <pitti> tvoss: this only works because we strip translations for main packages and for X-Ubuntu-Use-Langpack: yes pacakges
[04:35] <Mirv> pitti: shouldn't the same probably be for usr/share/core/trust/mir?
[04:35] <pitti> so this landing only works if this is true
[04:35] <Mirv> they are already there in the lib* packages, but sounds wrong
[04:35] <pitti> Mirv: location-service works fine
[04:35] <tvoss> pitti, I will move the translations to the -bin package
[04:36] <pitti> Mirv: correct; any file in a libfooN package must be versioned (in dir or file name)
[04:36] <pitti> otherwise different sonames aren't co-installable
[04:36] <tvoss> pitti, Mirv I can fix that, too
[04:36] <Mirv> tvoss: yeah, /usr/share/core/trust/mir/prompt_main.qml can't be there. thanks.
[04:37] <pitti> Mirv, tvoss: anyway, landing that now would be ok provided that you add a X-Ubuntu-Use-Langpack: yes marker to debian/control's Source:
[04:37] <pitti> as otherwise the translations won't be stripped and go to langpacks, but the package would ship them by itself
[04:40] <tvoss> okay, preparing breakfast real quick, on it after that
[04:41] <pitti> tvoss: and please while you are at it, can you add the "use langpack" marker?
[04:41] <tvoss> pitti, sure
[04:41] <pitti> unless the sources are in main
[04:59] <Mirv> pitti: they are in main
[05:00] <pitti> Mirv: aah, ok (and good!)
[05:00] <pitti> Mirv: right, that explains why they get stripped
[05:00] <Mirv> I was surprised too, they sounded like "probably not MIR:d" :)
[05:00] <pitti> yeah
[05:06] <tvoss> pitti, Mirv pushed the marker for location-service
[05:07] <pitti> tvoss: wb
[05:07] <tvoss> pitti, Mirv will tackle trust-store after breakfast
[05:07] <pitti> tvoss: no worries, sorry about the marker
[05:07] <tvoss> pitti, all good
[05:07] <pitti> tvoss: you don't need it, the packages are in main (quite surprisingly)
[05:07] <tvoss> pitti, Mirv the silo needs manual ack'ing, so no one can accidently land as is
[05:07] <pitti> tvoss: all main packages use langpacks by default
[05:07] <tvoss> pitti, oh :)
[05:07] <Mirv> tvoss: I also marked the silo back to "not tested"
[05:07] <tvoss> Mirv, great, thank you
[05:07] <pitti> tvoss: I'm not quite sure whether that was actually MIRed, or just wrongly NEWed
[05:08] <tvoss> pitti, nope, on purpose, both are in main
[05:08] <tvoss> including MIRs
[05:08] <pitti> nice
[08:07] <tvoss> Mirv, pitti https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092 has got the changes to .install files
[08:07] <tvoss> Mirv, pitti would appreciate a quick review
[08:23] <Mirv> it would help of course if tvoss would stay online :)
[08:34] <pitti> heh, he's got a tendency to drop off, yeah ;)
[08:34] <pitti> looking (was in a HO)
[08:35] <pitti> Mirv: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
[08:36] <pitti> /summon tvoss
[08:36]  * Mirv HO now
[08:36] <Mirv> pitti: so LGTM without changes and Langpack: yes to be removed for next release?
[08:36] <seb128> pitti, why does the X-Ubuntu-Use-Langpack use needs to be dropped?
[08:37] <pitti> seb128: well, not *need*, but it's not necessary
[08:37] <pitti> seb128: I falsely assumed that these packages were in universe, like so many others
[08:37] <seb128> oh, that's in main
[08:37] <seb128> yeah, me too, just looked at it
[08:37] <pitti> one package to get it right! :-)
[08:37] <Mirv> "we've a relatively recent touch package that is in main o_O"
[08:38] <pitti> ok, I need to run for some errands, back in ~ 45 mins
[08:38] <pitti> Mirv: if tvoss comes back, would you mind relaying the above to him?
[08:38] <Mirv> let's wait for tvoss to be back, anyhow
[08:38] <Mirv> sure
[08:38] <seb128> technically the update doesn't need to be rejected on that
[08:38] <pitti> cheers
[08:38] <seb128> could be fixed in the next landing
[08:38] <pitti> seb128: no, it doesn't
[08:38] <pitti> seb128: but it's already not yet proposed, so it might just as well get cleaned up while he's at it
[08:39] <seb128> right
[09:02] <pitti> tvoss: wb
[09:02] <tvoss> pitti, hey there
[09:02] <pitti> tvoss: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
[09:03] <tvoss> pitti, ack, will remove the marker again
[09:03] <pitti> tvoss: sorry about the confusion
[09:03] <tvoss> pitti, no worries, all good
[09:05] <tvoss> pitti, pushed both location-service and trust-store
[09:05] <tvoss> pitti, could you approve both MPs once you are happy?
[09:07] <pitti> tvoss: ack'ed https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092/+merge/235299
[09:11] <pitti> tvoss: what's the other MP?
[09:13] <tvoss> pitti, https://code.launchpad.net/~thomas-voss/location-service/fix-1354092/+merge/235225
[09:15] <pitti> tvoss: erledigt
[09:15] <tvoss> pitti, \o/
[09:16] <tvoss> pitti, Mirv kicked silo rebuild
[09:18] <Mirv> tvoss: thanks! and good that you asked for the approvals since that means we'll be able to ack the packaging changes even though it's in main.
[10:07] <sil2100> @pilot in
[10:08] <cjwatson> YokoZar: I see infinity fixed wine1.6 for you; I fixed it a bit harder so that nobody should have to manually bump that version again.
[11:32] <doko> Sweetshark, any update on https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 ?
[11:41] <doko> Laney, pitti: you signed paramiko, now in dep-wait
[11:42] <doko> jamespage, swift ftbfs
[11:42] <pitti> doko: oh argh, sorry about that; so we either need to sync python-alabaster (FFE) or just remove the new paramiko from -proposed (also fine, it's not that important)
[11:42] <pitti> doko, Laney ^ and as paramiko is in main, I tend to the latter, given where we are in the release cycle; ok?
[11:43] <doko> well, it's a sphinx theme, I have no problem with that. just write a MIR then
[11:43] <pitti> can do that too (we'll need it in V anyway)
[11:45] <doko> synced
[11:45] <jamespage> doko, hmm
[11:45] <pitti> doko: thanks, will review package and write MIR shortly
[11:46] <jamespage> doko, OK looking - I did not see that locally
[11:51] <sil2100> @pilot out
[11:51]  * sil2100 lunch o/
[12:13] <doko> barry, could you take care of the python-eventlet ftbfs? you seem to be involved upstream already, see https://github.com/eventlet/eventlet/issues/135
[12:20] <Sweetshark> doko: whops, that slipped by under the radar in post-conference-mail-avalanche -- will look into it,
[12:22] <doko> Sweetshark, thanks, and please have a look at the two dict-* ftbfs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
[12:23] <Sweetshark> doko: willdo
[12:32] <doko> apw, could you have a look at the arm64 crash ftbfs http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html ?
[12:33] <apw> doko, hmmm that is needs building ... so there is no log
[12:34] <rbasak> doko: while you're looking at ftbfs from the test rebuild, I was planning on tackling some of the server ones this week.
[12:34] <rbasak> doko: is there anything you're working on from that list right now?
[12:34] <doko> apw, ahh, I just gave it back
[12:34] <apw> doko, ack, i'll wait on it exploding again
[12:34] <doko> rbasak, no, just pinging people
[12:35] <rbasak> I need some help with the libecap one. It's a mismatched symbols file. I have a fix, but how do I verify that it's safe?
[12:35] <rbasak> Marking some more symbols optional fixes it: http://paste.ubuntu.com/8520625/
[12:35] <rbasak> Is it safe just on the basis that the source hasn't changed?
[12:39] <doko> I've never seen issues removing the destructor symbols
[12:40] <doko> great packaging, two year old source ....
[12:40] <rbasak> How do I know what type of symbols they are?
[12:41] <rbasak> (I understand that C++ mangles the names; I don't know how to match them up to their prototypes)
[12:41] <rbasak> So I have no idea what _ZN7libecap7MessageD0Ev might mean for example.
[12:43] <mlankhorst> run it through c++filt
[12:43] <mlankhorst> ~$ echo _ZN7libecap7MessageD0Ev | c++filt
[12:43] <mlankhorst> libecap::Message::~Message()
[12:43] <rbasak> Oooh
[12:43] <doko> $ c++filt _ZTVNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EEE
[12:43] <doko> vtable for std::tr1::_Sp_counted_base_impl<libecap::adapter::Service*, std::tr1::_Sp_deleter<libecap::adapter::Service>, (__gnu_cxx::_Lock_policy)2>
[12:43] <rbasak> I didn't know about that
[12:44] <sergiusens> cjwatson: is there any wiki talking about switching your sources list to devel?
[12:51] <cjwatson> sergiusens: no, haven't advertised it much because there are still a few problems I haven't had a chance to fix up
[12:52] <sergiusens> cjwatson: right, that was my followup question, advertising :-) thanks
[12:53] <rbasak> doko: sorry, I'm still not comfortable with this. I don't really follow the bigger picture of how to determine that these symbols really aren't needed.
[12:53] <cjwatson> I have regrettably forgotten the details, would have to try it again for a while to remember them ...
[12:53] <rbasak> The package includes all the headers, which makes it awkward.
[12:54] <rbasak> doko: if you're happy with my diff, then I guess I can upload that.
[12:54] <rbasak> Or else, I don't really see the point of having the symbols file in the first place if we just change it to accomodate when needed.
[13:02] <barry> doko: yeah.  unfortunately, i'm not sure what the upstream fix really is.  it's probably not simple.  if i have time
[13:20] <doko> rbasak, agreed for c++ symbols files, but c symbol files should be fine
[13:20] <doko> go ahead with the upload
[13:20] <doko> my libabigail upload is still stuck in NEW
[13:22] <rbasak> doko: OK - you mean an upload to drop this c++ symbols file entirely, or just to mark the disappearing symbols as optional as in my diff?
[13:23] <doko> well, optional shouldn't hurt from my point of view
[13:23] <rbasak> OK
[13:23] <pitti> doko: I reviewed the alabaster source package and filed bug 1378830 FYI
[13:23] <rbasak> Thanks
[13:24] <doko> pitti, looking
[13:28] <doko> pitti, promoted
[13:29] <pitti> doko: danke
[13:30]  * pitti accepts the gazillion langpacks in unapproved
[13:33] <Laney> doko: not the version I synced
[13:33] <smoser> slangasek, i just posted some debug info at bug 1377005.  looks like 'startpar' is at least involved.
[13:33] <smoser> so your comments woudl be appreciated.
[13:34] <smoser> hm.. but reading what startpar is, maybe thats not that helpkful. maybe you see other info in that ubg
[13:34] <smoser> bug
[14:19] <geser> smoser: hmm, could you check if a "pre-up sleep 5" in your inet6 stance makes a difference (without a ipv4 stance)
[14:20] <geser> if it's really a race condition
[14:20] <smoser> geser, thats a good suggestion. will try.
[14:30] <smoser> geser, does'nt seem to make a difference. still failed. when the ipv4 stanza was below the ipv6, but ipv6 had 'sleep 5'
[14:31] <geser> hmm
[15:03] <doko> barry: http://launchpadlibrarian.net/186832595/python-eventlet_0.13.0-1ubuntu2_0.13.0-1ubuntu3.diff.gz
[15:03] <pitti> smoser: hey, how are you?
[15:04] <pitti> smoser: what's the recommended way to enable restricted/multiverse with cloud-init? do I need to parse the existing sources.list to make some guesswork what the primary mirror is, or can I use some $mirror variable/macro in "apt_sources:"?
[15:04] <pitti> smoser: i. e. I need to refer to the default of "apt_mirror" in apt_sources
[15:14] <barry> doko: ah, just skip the tests.  okay cool, i'll apply
[15:15] <barry> (or did you already?)
[15:21] <doko> barry, no, just the one patch, fixed the sslwrap
[15:22] <barry> doko: ack. i'll forward that upstream.  thanks
[15:31] <smoser> pitti, you shoudl be able to use a boothook to write/edit/re-write /etc/cloud/templates/sources.list.ubuntu.tmpl
[15:32] <smoser> and if you l ook at that file, it should be obvious to you.
[15:32] <doko> rbasak, can't we just sync blas?
[15:34] <rbasak> doko: the previous revision seemed to have some more major changes to me.
[15:34] <rbasak> doko: we could sync it if the release team is happy with that.
[15:34] <doko> ok, I'll take it as it is
[15:34] <rbasak> OK thanks
[15:59] <doko> Saviq, Mirv: qtdeclarative-opensource-src, any reason why this is still built using gcc-4.8? what kind of symbol changes were this?
[16:01] <Saviq> doko, IIRC building it with 4.9 resulted in ABI breakage, which is tricky with apps in the store
[16:02] <Saviq> but don't quote me on that...
[16:02] <Saviq> tsdgeos, do you remember ↑?
[16:02] <doko> Saviq, how do you want to cope with that in the future?
[16:02] <doko> because we won't keep 4.8 forever
[16:03] <Saviq> doko, yeah of course, I'm not sure what the plan on that is... the problem is that we try to maintain backwards compatibility, which in this case would mean keeping multiple binaries
[16:04] <Saviq> or we'd have to break backwards comp
[16:04] <Saviq> but I'm totally out of the loop on those things, cjwatson can you comment on that ↑?
[16:05] <doko> well, then I don't understand why you didn't start freshly with 4.9. but maybe this is too late now
[16:05] <tsdgeos> Saviq: i think you or someone mentioned some c++11 thing
[16:05] <tsdgeos> which is probably not used in qt
[16:05] <pitti> smoser: cheers
[16:05] <Saviq> doko, yeah, we were well past that, and of course didn't foresee such an issue
[16:12] <Mirv> Saviq: doko: we already landed 4.9 qtdeclarative to rtm (just today) and didn't encounter any problems, so I expect any future ubuntu release to drop that 4.8 usage too
[16:12] <cjwatson> Saviq: I don't know about that
[16:13] <Saviq> Mirv, ok then, I must've remembered wrong
[16:13] <doko> Mirv, hmm, but why not to utopic then?
[16:13] <Mirv> doko: it's a new feature that landed
[16:14] <doko> Mirv, maybe I misunderstand, but what is the new feature?
[16:14] <Mirv> doko: precompiling qml magic
[16:14] <Mirv> from ricmm
[16:14] <doko> Mirv, but this is not in the Ubutu package, correct?
[16:14] <Mirv> doko: yes
[16:15] <Mirv> so certainly ubuntu package could diverge and now build without that feature but also dropping the 4.8 usage
[16:15] <doko> Mirv, so no reason not to switch to 4.9 for the utopic release
[16:15] <Mirv> doko: no particular reason, it would just need a round of building and symbol updates
[16:15] <doko> Mirv, would you have time for that this week?
[16:16] <Mirv> doko: possibly yes. I'll add a landing line for that so I don't forget. and the diverged packages need to be tracked a bit, plus I've a third packaging branch for 5.3.2 (for v-series)...
[16:16] <doko> cool, thanks
[16:18] <doko> Mirv, ohh, and please see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html  the qt* ftbfs. can you address this for utopic too, or somebody else?
[16:22] <infinity> Mirv: Erm, aren't RTM changes meant to be in utopic before (or in parallel to) the RTM landings?
[16:22] <infinity> Mirv: If qtdeclarative has moved to 4.9 in RTM, I sure hope this is also heading to utopic yesterday. :P
[16:24] <Mirv> infinity: not really, many landings are currently made rtm first. plus this can't land as is to utopic, and the gcc 4.9 switch was made as a sidetrack of the actual landing.
[16:24] <Mirv> at some point I assume landings to rtm will continue while ubuntu sides waits for v-series to open
[16:25] <infinity> Mirv: Okay, let me rephrase.  It was a matter of policy that things that were meant to happen in both happen in both at the same time, or the distro first.  Why are we breaking that policy?
[16:25] <infinity> Mirv: RTM-specific hacks are a different story, but this doesn't fall into that.
[16:25] <seb128> because utopic is more frozen than rtm
[16:25] <seb128> and rtm work can't stop on that
[16:25] <infinity> seb128: BS. It could be sitting in the queue.
[16:25] <seb128> we need to open v-serie and land there
[16:26] <seb128> sit and never been accepted
[16:26] <seb128> what's the point?
[16:27] <Mirv> infinity: in general, to get rtm bugs fixed faster it's now often the other way around, landing utopic (queue) secondarily. in this specific case, I wasn't sure if a change like this is wanted to utopic or not, but apparently the answer is yes
[16:27] <infinity> seb128: The queue has 5 items, only one of which is older than 7 hours, 3 are an hour old.  So, while I get the point you're trying to make, it's not actually valid.
[16:27] <seb128> I was not speaking about delays in the queue review
[16:27] <Mirv> and rtm first so that QA can start their work as early as possible
[16:27] <cjwatson> it doesn't strictly have to be actually in utopic; it just has to be queued somehow somewhere in such a way that it will definitely not get lost
[16:27] <seb128> but about features that are not ok for utopic
[16:28] <seb128> those should go in v
[16:28] <seb128> but that's not open for uploads yet
[16:28] <cjwatson> (in a way that's a bit better than "honestly yes I promise")
[16:28] <seb128> or is it?
[16:28] <cjwatson> seb128: not possible at present
[16:28] <seb128> k, but does it make sense to upload features that are not ok for utopic to utopic queue?
[16:28] <cjwatson> (also the singular of series is series)
[16:28] <seb128> those are just going to be rejected since they shouldn't go in that serie
[16:28] <infinity> cjwatson: Yeah, I'm fine with that too, of course, but I'm assuming this "it's only in RTM" thing usually means "only in RTM, and might get lost if people forget to merge back".
[16:29] <infinity> seb128: No, if it's obviously not okay for U, it shouldn't be uploaded to U, as Colin says, but a distro branch where it's committed and won't get lost should also definitely happen.
[16:29] <seb128> right
[16:29] <seb128> nobody said that didn't happen
[16:29] <seb128> and it's different from "need to get in utopic first"
[16:30] <infinity> Anyhow, this 4.9 change is a bit of a unique snowflake, as we've been pushing for that to be completed throughout the whole cycle.
[16:30] <infinity> If it can get done, it should get done, so we don't have to deal with the potential pain between U and V being incompatible somehow.
[16:32] <Mirv> I'll get that in the queue in the morning
[16:33] <infinity> Mirv: <3
[16:35] <smoser> barry, you just want to fix bug 1295833 for me ?
[16:35] <smoser> it looks like someone just has to do it. per the last comment there.
[16:43] <barry> smoser: i'll take a look
[16:54] <slangasek> smoser: sorry, I can't tell in your logs on bug #1377005 what the differences are between good and bad wrt networking
[16:55] <slangasek> smoser: and nothing startpar-related jumps out at me
[17:04] <doko> seb128, Laney: please could you have a look at the glibmm2.4 ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
[17:05] <seb128> doko, k
[17:06] <seb128> Laney, we should probably update that to 2.42 to match glib, wdyt?
[17:07] <Laney> I guess
[17:07] <doko> who is the proper person to ask for the unity-* ftbfs?
[17:07] <seb128> doko, depending of the package
[17:08] <doko> same for ido
[17:08] <seb128> the lens/scope probably thostr's team
[17:08] <seb128> the webapp one, dbarth
[17:08] <seb128> ido, bregma
[17:08] <seb128> or ted
[17:08] <Laney> https://code.launchpad.net/~laney/unity-lens-music/notify-notification/+merge/235434
[17:09] <doko> seb128, which ones of ido, unity-lens-music, unity-scope-manpages, unity-webapps-qml do you want to look at?
[17:09] <doko> bregma, ^^^
[17:10] <seb128> Laney, let me ack/do a landing for that one
[17:10] <Laney> k, cool
[17:10] <Laney> I forgot about it to be honest, but seems that nobody is watching those merge proposals
[17:11] <smoser> slangasek, i cna't tell either.
[17:11] <smoser> you have any thoughts on where to go ? i collected /var/log/upstart/* also, and
[17:12] <smoser>  http://paste.ubuntu.com/8522008/
[17:12] <smoser> ie, no hints there either.
[17:12] <seb128> Laney, yeah, music lens didn't move for like a year, I guess that's deprecated/not maintained
[17:12] <Laney> desktop eh
[17:13] <seb128> it's also that the people who worked on those components left (e.g mhr3)
[17:15] <doko> barry, could you have a look at https://launchpadlibrarian.net/184782940/buildlog_ubuntu-utopic-i386.dirspec_13.10-0ubuntu2_FAILEDTOBUILD.txt.gz ?
[17:21] <slangasek> smoser: ok, but you said "startpar is involved", and I wasn't sure what you meant by that... startpar is always running at boot, but I don't see anything going wrong with it
[17:23] <smoser> slangasek, right. the one thing that was different in the  logs
[17:23] <smoser> was the location of startpar
[17:23] <slangasek> ok
[17:23] <smoser> which i think was actually related to the location of mounted proc
[17:23] <smoser> not sure though
[17:26] <slangasek> smoser: so do you have a /var/log/upstart/network-interface-$iface.log?
[17:26] <smoser> nothign there.
[17:26] <smoser> which means it didn't have output
[17:26] <slangasek> yes
[17:26] <smoser> so i know its probably red-herring
[17:26] <smoser> but
[17:27] <smoser> these 3 things happen before 'EXT4-fs (vda1): re-mounted. Opts: (null)' in bad case , and after in good case
[17:27] <smoser> init: startpar-bridge (mounted-proc--stopped) state changed from post-stop to waiting^M
[17:27] <smoser> init: Handling stopping event^M
[17:27] <smoser> init: startpar-bridge (mounted-dev--stopped) state changed from stopping to killed^
[17:28] <smoser> although i'm not certain order between event and message written to /dev/console is guarnateed (ie, if upstarts writing to /dev/console is intermixed with kernels in a determinable order)
[17:29] <slangasek> yes, it's not guaranteed, and I don't see anything there that looks suspicious
[17:32] <smoser> any wild guesses or thoughts are appreciated.
[17:42] <slangasek> smoser: so in the failure case, what does /run/network/ifstate show after boot, and what's the output of 'sudo initctl list | grep network-interface'?
[18:17] <doko> pitti, postgresql-9.4 autopkg test failure, blocks python3.4
[19:06] <ScottK> mitya57: Why is it too late on sphinx-issuetracker?
[19:30] <kenvandine> doko, did you mean to drop  Multi-Arch: allowed in gdb?
[19:32] <cjwatson> (^- I investigated, it's not mentioned in the changelog and might be a merge accident)
[19:32] <kenvandine> doko, ubuntu-system-settings has a build dep on gdb:any, so we have a FTBFS
[19:51] <YokoZar> cjwatson: Thanks for the fix to britney :)
[19:52] <smoser> slangasek,
[19:52] <smoser> $ cat /run/network/ifstate
[19:52] <smoser> eth0=eth0
[19:52] <smoser> lo=lo
[19:52] <slangasek> smoser: and eth0 is your test ipv6-only interface?
[19:52] <smoser> http://paste.ubuntu.com/8522838/
[19:53] <smoser> right.
[19:53] <smoser> if youre interesetd in re-creating
[19:53] <smoser> i just pushed instructions to https://code.launchpad.net/~smoser/+junk/lp-1377005
[19:53] <slangasek> curious/annoying
[19:53] <smoser> recreates with just downloading an image, modifying it a bit
[19:53] <smoser> and running in kvm (even with user networking)
[19:54] <slangasek> not going to have time to try to reproduce it right now
[19:54] <smoser> yeah, well if you ahve time (and i'd much appreciate it, or anyone else),
[19:54] <smoser> http://bazaar.launchpad.net/~smoser/+junk/lp-1377005/view/head:/README
[19:54] <smoser> is honestly how much effort it takes.
[20:00] <cjwatson> YokoZar: np
[20:31] <cjwatson> Which Ubuntu flavours still use consolekit (if any)?
[20:32] <cjwatson> Trying to work out whether the proper fix to bug 1334916 is to actually put effort and thought into it, or drop the patch ... I suspect the latter is the right answer eventually but maybe not yet
[20:34] <Unit193> mate-power-manager and lxsession-logout (Mate Ubuntu, Lubuntu) dep on it.
[20:43] <cjwatson> Unit193: Right, I was trying to work out the extent to which the dependencies were real/interesting - the point of the consolekit patch is so that you can interact with things like policykit over ssh, but if it's just a few things that realistically you would only ever manipulate from a logged-in desktop, then that's less concerning
[20:43] <infinity> cjwatson: From the package names, it sure sounds like it's the latter.
[20:43] <smoser> slangasek, well, heres some more info. http://paste.ubuntu.com/8523098/ <-- output of 'ifup --verbose' in both cases with attached commentary.
[20:44] <Unit193> Alright, pardon me.
[20:45] <cjwatson> Unit193: no, don't apologise, I wasn't very clear and it's useful information ...
[20:46] <cjwatson> I guess maybe I should be trying to figure out whether policykit might ever care
[20:46] <slangasek> smoser: um?  '$ sudo ifup --verbose
[20:46] <slangasek> ifup: Use --help for help
[20:46] <slangasek> '
[20:46] <slangasek> smoser: oh, ifup --verbose --allow-auto, ok
[20:47] <smoser> well. yeah.
[20:47] <smoser>  's,ifup --allow auto,ifup --verbose --allow auto,'
[20:49] <smoser> well, there goes my ethtool theory. i 'chmod -x /sbin/ethtool' without it makign a difference.
[20:49] <infinity> smoser: Those logs are identical...
[20:49] <smoser> well, order is important.
[20:49] <infinity> smoser: cut and paste fail, or were they really identical?
[20:50] <smoser> oh shoot.
[20:50] <smoser> yeah.
[20:50] <smoser> fail.
[20:51] <smoser> re-attaching corrected
[20:51] <geser> and I was wondering why I didn't see any difference between GOOD and BAD
[20:51] <smoser> reload
[20:51] <smoser> and ihave to go now.
[20:51] <infinity> geser: I thought I was maybe just failing to parse, so fed them both to diff, which lies less often than my eyes.
[20:51] <smoser> later.
[20:51] <infinity> smoser: "reload"?  It's a pastebin.
[20:51] <smoser> oh.
[20:51] <smoser> see bug
[20:52] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1377005
[20:52] <smoser> sorry for confusion
[20:52] <smoser> i have to run
[20:52] <infinity> Ahh.
[20:52] <infinity> Toodles.
[20:53] <cjwatson> pitti: BTW thank you for all your effort making adt-virt-qemu etc. work well.  This is so much less unfun than uploading-and-praying, or hoping that the schroot runner is a good enough approximation.
[21:51] <slangasek> smoser: so the ordering should only matter if something happens during the ipv4 bring-up that undoes the ipv6 bring-up.  But what about the case where there's *only* ipv6?
[23:53] <smoser> slangasek, i can get that. but i think that something in the ipv4 bringup is just providing time in some way preparing system for ipv6 to come up.  ie, if the 'modprobe net-pf-10' not blocking. anyway, yeah, i can get that though.
[23:54] <smoser> but actually, the "just ipv6" is not going to be differen tthan ipv6 then ipv4 in that its busted. and clearly wasn't ready at ipv6 bringup time.
[23:57] <smoser> so, yeah, i dont think ipv4 "un-does" ipv6, i think it provides something (possibly just time) to make system ready for ipv6.


[07:01] <lordievader> Good morning
[10:01] <Blueskaj> 'Morning folks
[10:53] <proctrap> hi, under nvidia KMail & Okular are getting pixelated font scaling, any ideas ?
[10:54] <proctrap> Kmail for example: he menu for Folders & the email list works fine, but the mail content window, including the header is completely pixelated ( as if zooming into a jpg text )
[10:54] <proctrap> on my integrated intel graphics, I don't have this problem
[10:55] <proctrap> (using nvidia driver 390.25 )
[10:58] <BluesKaj> ahh Optimus hybrid gpu system I bet
[10:59] <BluesKaj> proctrap, ^
[11:01] <BluesKaj> assume you have nvidia-prime installed, proctrap
[11:03] <proctrap> BluesKaj: yes
[11:04] <proctrap> ( although sadly the graphics performance under nvidia isn't that good -.- at least full opengl / cuda support)
[11:04] <proctrap> in firefox & every other application it looks okay, but in kmail I can't get it to non pixeling
[11:05] <proctrap> and ocular pixelates when you're zooming a little bit, which is totally fine under intel
[11:05] <proctrap> [ Force Fonts DPI 112 | Display Scale 1.2 ]
[11:10] <BluesKaj> dpi 112 , isn't that a little high for a laptop ?
[11:12] <BluesKaj> default is usually 96 dpi ...best to set the resolutiuon or your fonts a bit higher instead
[11:21] <proctrap> where can I increase the font resolution ?
[11:21] <proctrap> I'm using a high dpi setting to force bigger fonts, otherwise the scaling goes awkward
[11:21] <hateball> proctrap: alt+space, search fonts
[11:21] <BluesKaj> systemsettings fonts
[11:22] <proctrap> so, just increase the size of all of them ?
[11:22] <proctrap> that's messy and I've tried that once
[11:23] <proctrap> as I don't see a "resolution" option, just size
[11:23] <BluesKaj> proctrap, correction: system settings>appearance>fonts
[11:24] <proctrap> yes
[11:24] <proctrap> but there is no "resolution" option
[11:24] <BluesKaj> proctrap, which Kubuntu OS are you running?
[11:24] <proctrap> all I can do, is to manuall increase every font size by at least 2
[11:24] <proctrap> KUbuntu 17.10
[11:24] <BluesKaj> resolution is in system settings>monitor and display
[11:25] <proctrap> I'm not sure I get you
[11:25] <proctrap> I can increase the display scaling
[11:25] <proctrap> but then all my fonts are still as tiny as I started with
[11:25] <proctrap> so I can't read anything
[11:26] <proctrap> display resolution is on max, as per default full HD
[11:27] <BluesKaj> did you try to increase the fonts in system settings>fonts
[11:27] <BluesKaj> ?
[11:27] <proctrap> so you mean increasing all font sizes ?
[11:27] <BluesKaj> yes
[11:27] <proctrap> I'
[11:27] <proctrap> ve tried that once, but it was really messy to override verything manually
[11:28] <proctrap> gonna reboot
[11:29] <BluesKaj> no need to reboot
[11:29] <proctrap> it seems like konversation is using the biggest font ?! looks like a headline now
[11:29] <BluesKaj> just konversations fonts can be set with in the app itself
[11:30] <BluesKaj> think this guy isn't too familiar with kde/plasma
[11:31] <proctrap> ok so this was kind of getting the same result as with a higher DPI scaling seting
[11:31] <proctrap> now everything looks like when I started this conversation
[11:31] <proctrap> but KMail  message window is still a pixelated thing
[11:31] <BluesKaj>  konversations fonts can be set with in the app itself
[11:33] <proctrap> https://s14.postimg.org/jrsidgupt/Screenshot_20180309_123246.png
[11:33] <proctrap> no zooming
[11:33] <BluesKaj> look in settings>configure konversation>fonts
[11:33] <proctrap> so the issue is still here, kmail/okular have messed up fonts for content
[11:34] <proctrap> BluesKaj: after a reboot konversation is fine now
[11:34] <proctrap> but the initial problem: KMail & Okular having messed up font scaling under Nvidia is still there
[11:34] <proctrap> see my screenshot
[11:35] <proctrap> the ui (to the left) is completely fine, but the message window (see header & message) is pixelated
[11:35] <proctrap> and this is only happening under nvidia
[11:35] <BluesKaj> well dunno much about kmail since i don't use it
[11:35] <BluesKaj> but your screenshot doesn't show in that url
[11:36] <proctrap> https://postimg.org/image/7px4jblh9/
[11:36] <proctrap> works in private mode here also
[11:36] <BluesKaj> ok I see it now
[11:37] <proctrap> same thing with okular, text rendering is off
[11:38] <BluesKaj> which nvidia gpu ?
[11:45] <proctrap> BluesKaj: GTX 965M
[11:49] <BluesKaj> ok, that uses the 390 alright
[11:53] <proctrap> ? some specification
[11:56] <proctrap> argh now I've to increase the font for other programs, seems like the DPI switch was a fast although apparently messy trick
[11:56] <BluesKaj> it's the general driver for most non legacy nvidias atm
[11:57] <hateball> proctrap: are you using any form of hinting for your fonts?
[11:57] <hateball> using full hinting I've had some weird rendering issues
[11:59] <proctrap> hateball: not that I would know about, and I can't find that under fonts
[11:59] <proctrap> it's not just fonts
[12:00] <proctrap> it's like everything that seems to be "direct" rendered or something like that
[12:00] <proctrap> the logout/shutdown  screen for example is also pixelated
[12:00] <proctrap> from the logos to the fonts
[12:00] <proctrap> or the display scaling option
[12:01] <proctrap> https://postimg.org/image/rr1gmcril/
[12:02] <proctrap> https://postimg.org/image/wpoz0y871/
[12:02] <proctrap> [ click on view image for non scaled view ]
[12:04] <proctrap> I don't know the architecture exactly but that looks like some stuff is rendered differently (prob. X11 vs KWin ?! )
[12:04] <proctrap> and for example X11 is messing up scaling
[12:04] <BluesKaj> kwin uses X11
[12:05] <proctrap> yes but does stuff on it's own IIRC
[12:20] <scanning_please> loving my kubuntu .. hating its relationship to my hp printer scanner
[12:20] <scanning_please> i got my printer to print using the generic (en) drivers and giving it an ip on the local network
[12:21] <scanning_please> now i am trying to get scanlite or simple scan to  see the scanner
[12:21] <scanning_please> scanlite throws and error before i get a chance to add and settings to it
[12:22] <scanning_please> opening the selected scanner faild
[12:26] <BluesKaj> yeah i have thr HP envy 4500 all-in-one printer/scanner ...haven't found any app yet that works in scan mode , even the hplip-3.17.11.run driver doesn't do anything except print
[12:28] <proctrap> BluesKaj: found the culprit
[12:29] <proctrap> display scaling is completely broken for nvidia
[12:29] <proctrap> without it everythign works
[12:29] <proctrap> but I'll get back to font DPI enforcement, as some java applications are just too tiny without it
[12:31] <scanning_please> when i go to the hp site for my printer they send me into a linux black hole that says its all in hplip unless it isnt and then screw you
[12:32] <scanning_please> guess i should have verified the device with linux before i bought it
[12:32] <scanning_please> laser jet pro mfp m125nw
[12:32] <BluesKaj> not here, I downloaded the driver from sourceforge link which is provided by HP
[13:45] <proctrap> another question: I want to run a script as root on login
[13:45] <proctrap> there are countless answers, my problem: the solution with /etc/pam.d/login does not work under Kubuntu
[13:46] <proctrap> (it does not work with the KDE login to be precise, virtual terminal works fine)
[13:52] <proctrap> I am still figuring out if I can achieve the same with systemd, but afaik systemd doesn't know anything about user logins
[13:52] <proctrap> (graphical)
[14:22] <proctrap> ok so I managed to use ~/.config/autostart-scripts but what I need is "/shutdown-scripts"
[14:55] <proctrap> ok found it, all these legacy folders from which various programs read stuff are a mess
[15:06] <IrcsomeBot2> WossMan was added by: WossMan
[20:18] <yuriy> hello. i moved yesterday config file with "mv" command, but i thought i made "cp" and did ovverride my important server config...
[20:18] <yuriy> i tried extundelete, but it doesnt help
[22:13] <valorie> yuriy: cp it back?


[01:25] <studio-user252> Hi; Studio 16.04 , changed pauvcontrol from working but incorrect setting to 2.1 analog out and stereo in. Now pauvcontrol blinks and plays nothing and I cant change anything.
[01:26] <studio-user252> Any hints out there? I saw something about Nvidia but I'm still on the default nouvoue driver.
[01:27] <OvenWerks> I don't think the video driver would affect that unless the output you are using is part of the video card.
[01:28] <studio-user252> Nope, me neither. Using an older audigy value card
[01:30] <OvenWerks> I have not had trouble with pa that way. Normally, the easy way to start over is pulseaudio -k
[01:30] <studio-user252> Any command to reset the pulseaudio back to what it was set at or change the profile to the other stable but incorrect one?
[01:30] <OvenWerks> you may need to start pavucontrol again after that and it will restart pa
[01:31] <OvenWerks> I don't know where pa stores it's config. Let me see if I can find it.
[01:31] <studio-user252> john@john-Dimension-2400:~$ sudo pulseaudio -k [sudo] password for john:  E: [pulseaudio] core-util.c: Home directory not accessible: Permission denied E: [pulseaudio] main.c: Failed to kill daemon: No such file or directory john@john-Dimension-2400:~$
[01:32] <OvenWerks> you should not need (or want) to run pulseaudio as root
[01:32] <studio-user252> Funny, made this mistake in 14 LTS and it let me correct the profile no prob. In 16 seems to be very oicky
[01:32] <OvenWerks>  just pulseaudio -k should be fine
[01:33] <OvenWerks> you can try rm -r ~/.config/pulse
[01:34] <OvenWerks> but I think PA needs to be stopped while you do that
[01:34] <studio-user252> Tried -K now, no response from the system and pauv restarted is still blinking.
[01:35] <OvenWerks> pusleaudio -k just stops pulse. As soon as the system figures out pulse is stopped it respawns.
[01:35] <studio-user252> Pauv was not running when the command was issued, just did it agian to be sure, no change
[01:35] <OvenWerks>  restarting pavucontrol after killing pulse will restart it too.
[01:38] <OvenWerks> You may have to turn off pulse's respawn before you remove the .config/pulse directory or pulse may just recreate it the same way.
[01:39] <OvenWerks>  I use pulseaudio in an unconventional way, so it is harder for me try things.
[01:40] <OvenWerks> In my case pulse does not see any audio devices and only sends audio to jack.
[01:40] <studio-user252> Whoo Hoo! Got it going now! -K command and then RM -R etc.  Did it!
[01:40] <OvenWerks> Cool
[01:40] <OvenWerks> sounds great
[01:41] <studio-user252> No kidding! It does sound nice now.
[01:41] <studio-user252> Bowie "Heroes" to celebrate
[01:41] <studio-user252> Thanks so much!
[01:42] <OvenWerks> no problem.
[01:42] <studio-user252> Over and out, got another PC that I did that to.
[01:42] <studio-user252> Whee, practice makes perfect
[03:10] <studio-user409> Hi all!  Is there any easy way to uninstall one install of 16.04 and leave the other (which is running grub) alone?
[03:11] <studio-user409> The second one I want to delete has got this crazy ticking sound once a second a second and the other is perfect
[03:12] <studio-user409> So I want to leave the perfect one alone and get rid of the other.
[03:16] <krytarik> studio-user409: So just 1.) format the partition the second one is on, and 2.) run "sudo update-grub" from the other.
[03:24] <studio-user409> Ok, stupid here.  Looking at gparted, how do I tell which is which?
[03:26] <studio-user409> It looks like there may be more then one partition involed or is that my ignorance showing?
[03:27] <studio-user409> Doesn't Studio grab muliple partitions by default?
[03:28] <studio-user409> I've a nice multi OS going; MS XP, Vista, Win 7, 2 of Studio, Fedora and Suse
[03:30] <studio-user409> All running on an updated but obiously behing the time Del 24000 with upgraded processor and 500 MB drives
[03:32] <studio-user409> So right now I'm on the weird 16.04 studio that should go bbye
[03:33] <studio-user409> It ticks one a second and nothing stops it. Besides its taking up too much room
[03:35] <studio-user409> Is there a simple way of telling this 16.04 to erase itself?
[03:39] <studio-user409> Sorry, my bad, seems to be some instructions but not toattly relevant out there. Hugs and Kisses!
[23:04] <Xenos_> good time of day
[23:05] <Xenos_> anyone alive in here?
[23:08] <Xenos_> #channellist