[05:55] <Fudge> anyone use trasmission-remote, my local config doesn't seem to be saving accept for the hostname of the remote machine.
[06:09] <pitti> Good morning
[09:53] <pitti> Laney: good morning
[09:53] <pitti> Laney: FYI, I removed all yakkety packages from the systemd silo and reconfigured the silo for v+x+z
[09:53] <pitti> Laney: according to sil2100 I now need to wait until the PPA fully unpublishes the y packages; doing the MP fix in the meantime
[09:53] <pitti> then we can re-re-re-rebuild
[09:54] <Laney> hey pitti
[09:54] <Laney> sorry for not "hey"-ing; sprint
[09:54] <pitti> no worries :) how is it going?
[09:55] <ogra_> it goes very dutch over here
[09:56] <pitti> Laney: ok, I did https://code.launchpad.net/~pitti/indicator-datetime/fix-systemd-unit/+merge/308786, that fixes the ExecStart= line
[09:57] <pitti> Laney: not sure if the prerequisite is actually necessary, but I did it for now
[09:57] <Laney> pitti: I think it makes bileto merge in the rigth order
[09:57] <pitti> Laney: I mean, just merging the new MP is fine as it includes Ted's commits
[09:57] <Laney> ya, you can also replace it
[09:57] <Laney> but this should work too
[09:58] <pitti> Laney: oh, you mean I shouldn't replace Ted's MP from bileto but just add mine?
[09:58]  * Laney approves it
[09:58] <Laney> yes
[09:58] <pitti> ok, just adding it
[09:58] <pitti> Laney: yes, I did check the built .deb
[09:58] <Laney> I knew you would have :)
[09:59] <Laney> pitti: sprint is session rather than hack heavy, but not bad
[09:59] <Laney> we went to a museum last night with an illusion exhibition
[09:59] <Laney> like the stuff at Escher's one
[09:59] <Laney> was nice
[09:59] <Laney> but now, got one of the aforementioned sessions -> brb
[13:11] <pitti> tedg, Laney: https://bileto.ubuntu.com/#/ticket/1710 mentions a missing libindicator, which is indeed not in a PPA, nor is there an MP; I figure this should be a backport of the y/z version (new indicator-common) -- shoudl I just upload that to the landing PPA, with a ~16.04/~14.10 suffix?
[13:12] <pitti> unfortunately all the indicators now depend on this, so we need to provide it as backport
[14:04] <Laney> pitti: I don't know, sorry
[14:06] <Laney> looks like power & sound need removing on s390x
[14:06] <Laney> (z)
[14:06] <pitti> Laney: it's just a depwait, does that hurt?
[14:07] <pitti> oh, indeed
[14:07] <pitti> will do
[14:07] <sarnold> do s390x machines not have a sound card? :)
[14:07] <pitti> they have lots of fans which make noise :)
[14:07] <pitti> *swoosh*
[14:08] <Laney> is libindicator this indicator-common thing?
[14:08] <pitti> yes
[14:08] <sarnold> ahhh I wonder if anyone has done any audio -> pwm fan control things for them.. :)
[14:08] <Laney> nod
[14:09] <Laney> Can't do anything to backport that, it's got no Depends
[14:09] <Laney> s/anything/any harm/
[14:10] <pitti> Laney: right, I rather meant if that's what's missing here (direct PPA backport upload) or something else
[14:11] <Laney> pitti: you mean how procedurally to upload a new backport using bileto?
[14:11] <pitti> Laney: yes, using  bileto or direct dput (with manual changelog crafting)
[14:11] <Laney> not sure if dput will make it sad the next time
[14:12] <pitti> the latter tends to upset bileto the next time you want to land stuff, so I'm not sure about the "official" way
[14:12] <Laney> I would say propose an empty MP
[14:12] <Laney> but, -> sil2100 / robru
[14:12] <pitti> ack
[14:13] <Laney> ah, you don't need to list things in source package names if they have MPs
[14:13] <Laney> maybe that's why it says "Diff missing" for those
[14:13] <pitti> robru, sil2100: so what's the official way to get libindicator backported to v and x for https://bileto.ubuntu.com/#/ticket/1710 ? direct dput to the landing PPA with adding a ~16.04/~14.10 changelog record, or some bileto magic?
[14:14] <pitti> Laney: the ticket has "libindicator" in its source package list indeed, but no MP
[14:14] <pitti> no idea about the "diff is missing" indeed; I didn't touch the "source packages" list
[14:14] <Laney> mmm
[14:14] <Laney> someone put all the packages in there
[14:14]  * Laney removes them
[14:14] <pitti> but indicators on v/x will definitively become uninstallable without the backport
[14:15] <Laney> nod, this is necessary
[14:17] <pitti> Laney: so in theory all the complaints should now go away, right?
[14:18] <Laney> pitti: I think so
[14:18] <Laney> not sure why it's gone green though
[14:18] <Laney> (or if that matters)
[14:18] <pitti> Laney: maybe because I removed the s390x packages, but that would have been quite fast
[14:18] <Laney> more likely because I edited the source package list
[14:19] <Laney> when libindicator is published in there, try to upload and see what happens :-)
[14:19] <pitti> Laney: I'll wait for s_il2100/r_obru to respond, before I mess up its brain
[14:19] <Laney> yeah
[14:20] <Laney> I just don't propose to tinker any more until $correct_action is taken
[14:21]  * pitti wonders if the negation was intended to shift to the right by two words
[14:21] <Laney> or s/more/more,/
[14:24] <pitti> Laney: I meant, you would propose to not tinker any more; but </pedantery>
[14:28] <Laney> strong words!
[15:02] <pitti> Laney: https://bileto.ubuntu.com/#/ticket/1710 -- wohoo!
[15:02] <pitti> Laney: I clicked on regenerating the diffs, that cleaned up the remaining noise
[15:25] <seb128> oh, pitti deleted software-center :-(
[15:26]  * pitti puts down the axe -- looked like consensus to me on @u-devel, and it's still in y
[15:26] <pitti> seb128: ça va ?
[15:26] <seb128> yeah, I don't really understand tbh
[15:26] <seb128> I'm sure there are stacks for other cruft in universe
[15:26] <seb128> why do we go out of our way to delete this specific one
[15:26] <seb128> oh well
[15:26] <seb128> stacks of*
[15:27] <seb128> pitti, oui, et toi ?
[15:28] <pitti> seb128: unblocking python 3, unblocking debtags, etc. (and removing three packages is not "getting out of our way" -- porting it to py3 would :) )
[15:28] <pitti> seb128: ça va bien, merci !
[15:28] <pitti> trying to get rid of some tech debt this week while it's quiet
[15:28] <seb128> "unblocking python3"?
[15:28] <seb128> having python2 in universe doesn't block anything going to python3
[15:29] <pitti> ah well, it's not on teh images any more, right
[15:29] <seb128> but no big deal, I just don't understand why people focus on that one when I'm sure that a cruftier things in universe
[15:30] <pitti> no objection to removing those too :)
[15:30] <seb128> we never tried to bother uncrufting universe
[15:30] <seb128> hehe
[15:30] <pitti> I actually do go through teh pain of process-removals every now and then
[15:30] <seb128> that was my position in the past but people arguing the other way around, that those have some users and don't hurt anyone
[15:30] <seb128> oh, well
[15:30] <pitti> and whenever we stumble over stuff in library transitions etc., we  also tend to remove stuff
[15:30] <seb128> yeah
[15:30] <pitti> i. e. whenever cruft gets in the way, we kick it
[15:31] <seb128> I wish we had a decent software center
[15:31] <seb128> or a better one
[15:31] <seb128> software-center had flaw but gnome-software also has some
[15:31] <seb128> oh well, it's where we are now I guess
[15:35] <seb128> s/decent/better I guess also, didn't mean to be negative
[15:37] <pitti> seb128: so, one more step towards removing aptdaemon; language-selector, software-properties-gtk, and sessioninstaller still need it, though
[15:38] <seb128> we don't have plan to replace aptdaemon this cycle apparently
[15:38] <seb128> or rather nobody in our team has slots to work on that
[15:39] <xnox> desrt, import public key only (with public parts of all subkeys) and run gpg --card-status to generate stubs. That's upstream way of doing it.
[15:39] <seb128> it's also that aptdaemon works well enough/does the job so we don't have strong motivation to change
[15:39] <xnox> desrt, also, once ssh-agent is up use $ ssh-agent -l for key fingerpring, and $ ssh-agent -L to show the key public key
[15:39]  * xnox doesn't use the gpg thing for ssh auth keys
[15:40] <xnox> ssh-agent -L should always work, even for e.g. ssl cards
[15:42] <seb128> night
[15:51] <robru> pitti: Laney: if you put in an mp for a package and build it, it will be built for all three series
[15:52] <pitti> robru: ok, is that the official way to do it? as I don't really want to change/reupload it to z, that package is fine
[15:53] <pitti> robru: well, I'll bump Standards-Version :)
[15:55] <robru> pitti: you can either copy zesty into the ppa and do manual uploads for v and x,  or you can put an mp and have it built for you for all three, both ways are equally official. Generally MPs only work for packages that we are the upstream for
[15:56] <pitti> robru: it is "our" package (libindicator); my worry was if I put in manual uploads to v/x-overlay, bileto would complain about being out of sync the next time we want to land an actual libindicator change
[15:58] <robru> pitti: no, bileto doesn't check such things. You should probably check whether libindicator has forked development at some point. If you put an mp in, it'll land for all three, but maybe they have a vivid branch somewhere that they'll release from which won't contain your backport
[16:00] <pitti> robru: libindicator is not in the overlay PPA at all; the only change is the addition of indicator-common, so it's the first time it gets into the overlay
[16:00] <pitti> robru: Standards-Version MP it is, I figure :)
[16:04] <robru> pitti: https://code.launchpad.net/libindicator libindicator appears to have branches for every series, which means that your changes will be reverted next time somebody does a vivid or xenial release
[16:05] <robru> pitti: in this case you'll need two tickets, one that's just vivid and one that's just xenial, and an mp backporting your fix to both
[16:10] <pitti> robru: oh, you mean because previous libindicator changes after vivid never landed in vivid-overlay
[16:10] <pitti> robru: I don't think these branches are/should actually be active -- we *do* want to unify libindicator now
[16:12] <robru> pitti: I'm not talking about overlay at all, I'm talking about the branches used to develop libindicator. If you put one branch in a triple silo, then later somebody attempts to use the vivid branch, it will revert what you've done, because your changes will only be recorded on the trunk and not on the vivid branch.
[16:12] <robru> pitti: if you're really sure those other branches are no longer needed, please mark them abandoned