[00:32] <mwhudson> do removals from debian get synced/tracked in ubuntu somehow?
[00:35] <nacc> mwhudson: do you mean do they get automremoved from ubuntu?
[00:35] <nacc> *autoremoved
[00:35] <mwhudson> nacc: yeah, or listed on some "packages no longer in debian" page
[00:37] <nacc> mwhudson: well, i know publishinghistory is aware of when a package gets deleted, but looking at the notes, it's not automatic, it is requested by someone
[00:38] <nacc> mwhudson: i'm not sure if there an existent source of packages in ubuntu but not in debian ... seems like there would be :)
[00:39] <mwhudson> nacc: ah https://wiki.ubuntu.com/ArchiveAdministration#Removals_in_Debian
[00:46] <jbicha> nacc: see also https://launchpad.net/ubuntu/yakkety and click the only in Stretch and only in Yakkety links
[01:12] <nacc> jbicha: ah thanks!
[02:49]  * mwhudson is confused: https://launchpad.net/ubuntu/+source/dh-golang shows 1.17ubuntu1 as published in yakkety
[02:50] <mwhudson> but https://launchpad.net/ubuntu/+source/golang-github-rakyll-statik/0.1.0-2/+build/9641641 uses 1.17 (and failed as a resutl)
[05:29] <Mirv> hi! could an autopkgtest magician mass restart at least http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src now that updated qt4-x11 is also in archives? this is fallout from qtchooser autosyncing from Debian, which moved files from qt4-x11 and qtbase to qtchooser, breaking the world..
[05:30] <Mirv> restart the failed ones, that is
[05:54] <Mirv> usually ^ for such I'd ask pitti at this hour, but I gave others a chance :)
[05:55] <Mirv> I guess I could for the next time start collecting restart urls from the page source and just giving them all to firefox in one go. that'd be poor man's mass restart.
[05:56] <Mirv> pitti: it'd need to be maybe --all-proposed too so it would consider both new qt4-x11 and qtbase-opensource-src?
[05:56] <Mirv> I'm not sure how to interpret all of the errors
[05:57] <Mirv> oh and consider the new qtchooser too. not having all three together causes problems.
[06:04] <pitti> Good morning
[06:04] <pitti> Mirv: yep, will do
[06:40] <Saviq> pitti, good morning - unity8 itself is happy now http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 - there's a bunch of other pkgs waiting on u8, too, so an --all-proposed for unity8 might be in order - the remaining Regressions for unity8 at least are due to what Mirv described above, so if you kick those off we should be in a more-or-less working order
[06:41] <pitti> Saviq: I did a mass-retry of related packages 30 mins ago, see backscroll and requests from Mirv
[06:41] <pitti> http://autopkgtest.ubuntu.com/running.shtml is churning :)
[06:41] <Saviq> pitti, ack, wasn't sure how broad the mass retry was - thanks!
[06:45] <ginggs> Logan: thanks, i have tried again
[07:09] <pitti> Saviq: news on http://autopkgtest.ubuntu.com/ look pleasantly green :)
[07:11] <Saviq> w00t
[07:19] <Mirv> green is good
[07:19]  * Mirv likes green
[07:19]  * pitti too!
[07:23] <dholbach> @pilot in
[07:28] <pitti> slangasek, xnox: I filed bug 1585087 about it; I can probably do without (we can drop the upstart job from a package once we add a systemd unit), this is mostly just less convenient for experiments
[07:31] <seb128> dholbach, hey, didn't you already pilot yesterday? ;-)
[07:32] <dholbach> seb128, I started, but then a bunch of other things got in between
[07:32]  * seb128 hugs dholbach
[07:32] <seb128> I plan to do a shift as well this week ;-)
[07:32] <dholbach> and it looks like it will be similar today :)
[07:32] <dholbach> so I guess I'll do my shift piecemeal :)
[07:43] <tsdgeos> is it a known bug that grub-mount takes ages on "complicated laptops"?
[07:43] <tsdgeos> takes like 15 min to run each time in my netbook with lots of partitions
[07:55] <pitti> slangasek, xnox: argh, got it; bamfdaemon also has a weird d-bus activation→ upstart redirection thing; bug updated/invalidated, unping, all good
[08:26] <dholbach> LocutusOfBorg, looks like https://launchpad.net/ubuntu/+source/python-tornado/4.3.0-1ubuntu1 ftbfs on some archers
[08:26] <dholbach> arches
[08:43] <LocutusOfBorg> dholbach, I already have a patch
[08:43] <LocutusOfBorg> I got the email, I'm testing a patch right now
[08:44] <LocutusOfBorg> let me see
[08:48] <LocutusOfBorg> how do you feel about the new debdiff on the bug?
[08:50] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[08:50] <LocutusOfBorg> FWIW it works
[09:13] <LocutusOfBorg> dholbach, hold on
[09:29] <dholbach> @pilot out
[09:31] <halvors> Hi. May the strongswan package for yakkety please be updated to version 5.4.0 which is now available?
[09:31] <halvors> Anyone knows if 16.10 will default to systemd-networkd instead of ifupdown?
[09:39] <pitti> halvors: we plan to do that on servers/cloud images, yes; desktop will continue to use NetworkManager
[11:16] <halvors> pitti: Nice :D
[11:17] <halvors> pitti: NetworkManager is not ifupdown as far as i know. I just think that systemd-networkd is a much better and more updated candidate than ifupdown.
[11:17] <halvors> May the strongswan package for yakkety please be updated to version 5.4.0 which is now available?
[11:17] <halvors> May it be possible to update the strongswan package for Ubuntu 16.04 as well?
[11:23] <pitti> stgraber, Laney: I adjusted the session dbus.upstart to not scribble over an already existing bus from dbus-user-session: http://paste.ubuntu.com/16653578/
[11:24] <pitti> stgraber, Laney: this now works with both current ubuntu (session bus) and user bus; it looks quite complicated, but now that I fought with upstart's handling of the environment I understand why the structure is that way :)
[11:25] <pitti> stgraber, Laney: does that look resonable to you?
[11:25] <pitti> maybe there's a better way than the "sleep infinity" dummy process
[11:28] <Laney> is this for "start on started dbus" things?
[11:28] <pitti> Laney: right
[11:28] <pitti> if I just exit, there's no more proces and dbus would be stopped
[11:29] <Laney> mmm
[11:29] <pitti> and a "sleep 1" isn't enough due to "stop on stopping dbus"
[11:30] <Laney> can't think of a way around that
[11:30] <pitti> "task" would also not work as then starting would block forever
[11:30] <Laney> do you need the DBUS_SESSION_BUS_ADDRESS stuff with user-session?
[11:30] <pitti> Laney: we need  to tell the upstart --user instance about this variable
[11:30] <pitti> Laney: well, in theory we could drop that, yes, as it shoudl already be in the env anyway, but I'd rather not break that
[11:30] <Laney> I thought it was well known in this case
[11:31] <pitti> Laney: yes, libdbus ought to fall back to $XDG_RUNTIME_DIR/bus; I haven't checked if that's the case, hang on
[11:31] <pitti> ah yes, that actually works with libdbus
[11:32] <pitti> but there's other implementations like gdbus or dbus-python, and I don't want to be that they all do this already
[11:32] <pitti> Laney: in the end this is only for a transitional time -- we want to drop session upstart after everything got ported :)
[11:33] <Laney> gdbus definitely does this
[11:33] <pitti> Laney: with that my prototype for launching bamfdaemon and Xeyes works nicely
[11:33] <Laney> but fine
[11:34] <pitti> Laney: I'm fine with dropping the parts too, if you prefer that
[11:34] <pitti> but I think we do need to keep the initctl notify-dbus-address, for talking to upstart itself
[11:34] <Laney> with systemd we won't be doing this stuff
[11:34] <Laney> so might shake out some things
[11:35] <pitti> Laney: we actually do
[11:35] <pitti>   dbus-update-activation-environment --verbose --systemd \
[11:35] <pitti>     DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY
[11:35] <Laney> huh!
[11:35] <Laney> then we should
[11:36] <pitti> I don't think this actually needs DBUS_SESSION_BUS_ADDRESS, but it does need $DISPLAY and $XAUTHORITY
[11:36] <pitti> not sure why Simon put it there, but I trust he knows what he's doing
[11:36] <Laney> maybe it's needed for old implementations
[11:37] <Laney> like possibly dbus-glib
[11:37] <pitti> Laney: so I now have bamfdaemon started from systemd, everything else from upstart, and stuff talks to each other
[11:37] <pitti> and it goes up and down with the session
[11:38] <pitti> having two different dbuses broke pretty well everything before
[11:38] <Laney> cool
[11:38] <Laney> so ship it IMHO
[11:39] <pitti> Laney: I currently have the bits in a separate systemd-graphical-session.deb (mostly for experimentation)
[11:39] <pitti> Laney: can you think of an appropriate existing place to put those?
[11:40] <pitti> it's an Xsession.d script, two /usr/lib/systemd/user/* files, an upstart job, and a little shell script which I hope I can eliminate
[11:41] <pitti> ubuntu-session would not be the worst place, but we want this for other flavors too
[11:41] <pitti> so maybe just put it into dbus-user-session?
[11:41] <Laney> pitti: Will it be upstream?
[11:42] <pitti> Laney: too early to say
[11:42] <pitti> Laney: I think I'll actually put the upstart job into the upstart package
[11:43] <pitti> which then leaves the Xsession.d script and the "umbrella" units
[11:43] <pitti> which could go into systemd too, but that makes it harder to opt out and uninstall/change while we develop this
[11:43] <Laney> Do something like /etc/upstart-xsessions ?
[11:44] <pitti> Laney: I really don't like this file
[11:44] <pitti> it makes very little sense
[11:44] <Laney> I mean a file which lets you opt in
[11:44] <pitti> I mean in the systemd --user context
[11:45] <Laney> could be ~/give-me-a-systemd-user-session
[11:45] <Laney> seems like it's that or make a separate deb to install
[11:46] <pitti> Laney: if we have a flag file, then we can't transition packages one by one
[11:46] <pitti> Laney: and it's a lot of runtime effort to dynamically disable/enable upstart jobs on the fly
[11:46] <pitti> Laney: my idea was to take a package, add a systemd unit, remove the upstart unit (or ship a "manual" override)
[11:47] <pitti> Laney: otherwise the upstart unit would need to check if the corresponding systemd unit is running
[11:47] <pitti> which is doable, but expensive and requires changing the existing jobs
[11:48] <Laney> pitti: Then I'm not sure what you're asking with opt-out, sorry
[11:48] <Laney> I thought you'd add something to XDG_DATA_DIRS that enables these override upstart jobs
[11:48] <pitti> Laney: hm, neither am I now, sorry
[11:48] <pitti> Laney: ah, that's actually a nice idea
[11:49] <Laney> that's what they do with switching between xdg autostart and upstart jobs atm
[11:49] <pitti> Laney: so with that, we'd do one round of porting, and then anohter round of uploading the packages  again to drop the overrides, upstart jobs, etc?
[11:50] <pitti> about three times the amount of work, but easier to revert
[11:50] <Laney> Well
[11:50] <Laney> You can just make the override unconditional when we want to enable it for everyone
[11:50] <Laney> Then it becomes cruft, but not critical to upload everything
[11:50] <pitti> *nod*
[11:51] <pitti> Laney: ok, that sounds good, I'll look into that (XDG_DATA_DIRS)
[11:52] <Laney> pitti: Looks like it's actually XDG_CONFIG_DIRS for upstart, looking at init(5)
[11:55] <LocutusOfBorg> seb128, mind if I merge hexchat?
[11:56] <seb128> LocutusOfBorg, please  do :-)
[11:56] <seb128> thanks!
[11:56] <LocutusOfBorg> can you please comment the two commits? https://anonscm.debian.org/cgit/collab-maint/hexchat.git/commit/?id=cd9bd1da61b0248e4a3ec49fe4b987546dac74ec
[11:56] <LocutusOfBorg> https://anonscm.debian.org/cgit/collab-maint/hexchat.git/commit/?id=75cbe4e74146d1db4051c337a5362ac21f471516
[11:56] <LocutusOfBorg> they are fine, right?
[11:57] <seb128> I've no idea about that
[11:57] <LocutusOfBorg> "Ubuntu server must be chat.freenode.net not irc.ubuntu.com because of hostname verification"
[11:57] <seb128> dunno about hostname verification
[11:57] <LocutusOfBorg> seems good
[11:57] <seb128> what's the issue with using the ubuntu alias?
[11:57] <seb128> what is verifying what?
[11:57] <LocutusOfBorg> not sure, maybe when people connects to irc using certificates?
[11:58] <LocutusOfBorg> BTW debian committing ubuntu-specific stuff
[11:58] <LocutusOfBorg> that patch is not used on Debian
[12:02] <cjwatson> seb128,LocutusOfBorg: "openssl s_client -connect irc.ubuntu.com:7000" shows a certificate for *.freenode.net, so using chat.freenode.net indeed seems more correct if hexchat might be connecting over SSL
[12:03] <LocutusOfBorg> <3 cjwatson
[12:03] <seb128> cjwatson, thanks
[12:03] <LocutusOfBorg> you rock, as always
[12:14] <Saviq> pitti, can you restart http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell with --all-proposed - that would, I believe, unblock unity8 and a lot of things would look better
[12:15] <Saviq> pitti, basically, any unity8 test in yakkety that isn't 8.12+16.04.20160518.1-0ubuntu1 could be triggered, would make things look much nicer
[12:31] <LocutusOfBorg> seb128, I don't like the merge
[12:31] <LocutusOfBorg> the pkconfig file is now in hexchat-plugins
[12:33] <LocutusOfBorg> so, leave it in hexchat-plugins, and add breaks+replaces?
[12:33] <LocutusOfBorg> and patch hexchat gnome to depend on it
[12:38] <seb128> LocutusOfBorg, I guess so...
[12:39] <LocutusOfBorg> there is already the breaks+replaces, because the split was done in debian too
[12:39] <LocutusOfBorg> the only remaining change is the service file
[12:39] <LocutusOfBorg> in case xchat-gnome breaks, can you please fix? :)
[12:39]  * LocutusOfBorg isn't core-dev
[12:40] <seb128> LocutusOfBorg, what needs fixing?
[12:41] <LocutusOfBorg>     - install files missing since the split, include pkgconfig needed
[12:41] <LocutusOfBorg>       to build xchat-gnome
[12:41] <LocutusOfBorg> this is from you
[12:41] <LocutusOfBorg> so I guess something will break now that the files are in another package
[12:41] <seb128> ah, right, the indicator needs to build-depends on the right one
[12:41] <LocutusOfBorg> that one yeah
[12:41] <LocutusOfBorg> :)
[12:42] <seb128> I can fix that yes
[12:42] <LocutusOfBorg> thanks
[12:45] <LocutusOfBorg> I uploaded, can you please point me to that indicator?
[12:45] <LocutusOfBorg> I fail to find it
[12:46] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/hexchat-indicator
[12:46] <LocutusOfBorg> seems empty
[12:49] <seb128> LocutusOfBorg, you need to bump the R/B versions
[12:49] <seb128> Replaces: hexchat (<< 2.10.2-1)
[12:49] <seb128> but xenial has 2.10.2-1ubuntu3
[12:49] <seb128> which is > to that
[12:49] <seb128> so it's not going to work
[12:49] <pitti> Saviq: I already restarted them twice with --all-proposed, yesterday afternoon and this morning; has anything changed again?
[12:49] <seb128> LocutusOfBorg, https://launchpad.net/distros/ubuntu/+source/xchat-indicator
[12:51] <Saviq> pitti, oh hmm, /me looking into it
[12:51] <LocutusOfBorg> seb128, xchat-indicator is universe
[12:51] <Saviq> pitti, ah, flaky test on amd64, dammit (got a fix upcoming in a silo)
[12:51] <LocutusOfBorg> I can do it
[12:51] <seb128> LocutusOfBorg, thanks
[12:51] <seb128> LocutusOfBorg, saw the comment about the version?
[12:52] <LocutusOfBorg> yes, but I dont get it completely
[12:52] <LocutusOfBorg> we need to break a version "before" the split
[12:52] <LocutusOfBorg> isn't it fine?
[12:52] <Saviq> pitti, so if you could run again for amd64, sorry about that :/
[12:53] <seb128> LocutusOfBorg, no, we need the first version after the split
[12:53] <seb128> LocutusOfBorg, because Replaces: hexchat (<< 2.10.2-1)
[12:53] <seb128> but you are on xenial and have 2.10.2-1ubuntu3
[12:53] <seb128> and install hexchat-plugins from y
[12:53] <seb128> the Replaces is not going to work
[12:53] <seb128> because it replaces only versions older than -1
[12:54] <seb128> and ours is newer than that
[12:55] <pitti> Saviq: it failed on qtdeclarative-opensource-src, qtdeclarative-opensource-src-gles, qtmir, systemd, and ubuntu-system-settings as well, though, always on amd64
[12:56] <pitti> Saviq: so if that's so hard to hit and takes ten retries or so, maybe it's easier to force-badtest this version on amd64
[12:56] <pitti> then the next unity8 upload still has to succeed
[12:58] <LocutusOfBorg> I'm uploading
[13:00] <pitti> Saviq: hinted now
[13:10] <Saviq> pitti, works for me, I suppose it failed on all others because it was actually the same test run?
[13:11] <pitti> Saviq: ah right, good point
[13:19] <tedg> Seems like the Upstart build on s390x in the Y archive is hung: https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu23/+build/9668581
[13:27] <pitti> tedg: yes, known-broken; we removed the binaries on y-release so that the s390x FTBFS doesn't block
[13:29] <tedg> pitti: Did you remove things like UAL binaries as well? The silo is giving me a dep wait.
[13:30] <pitti> tedg: I think seb128 removed upstart from s390x, but presumably not the rdepends yet
[13:30] <pitti> tedg: yeah, depwait/ftbfs is the expected result now on anything upstart-ish on s390x
[13:31] <tedg> Okay, cool. /me slashes his dreams of an s390x based phone
[13:54] <seb128> no, I just removed the unity ones
[14:00] <kenvandine> @pilot in
[14:09] <rbasak> slangasek: any news on reviewing https://github.com/ltangvald/mysql-5.7/commit/fa6ea0346929584373aee3b373cba0751fb81830 for me please?
[14:14] <caribou> what is the cleanest way to remove a (non-conffile) file that has moved to another package ?
[14:14] <caribou> I'm removing /etc/default/grub.d/kexec-tools.cfg and moving it to kdump-tools as /etc/default/grub.d/kdump-tools.cfg
[14:14] <caribou> so I want the former to be removed when the new kexec-tools package will install
[14:15] <GunnarHj> dholbach: Thanks for helping with bug #1584314! Actually there is a libx11 task too, but for now I'd ask you to unsubscribe ubuntu-sponsors, because we aren't sure yet if that fix is sufficient.
[14:15] <caribou> control file has the needed Depends/Conflicts so the new kexec-tools is installed upon install of kdump-tools but that file is left behind
[14:18] <rbasak> caribou: given that it's not a conffile, could the new kdump-tools Break on older kexec-tools (any version that expects to own the file) and in postinst, if kexec-tools.cfg exists, then rename it?
[14:19] <rbasak> I'm not sure if that's clean in every way though. I think it covers the "must not mess with users' local modifications" rule.
[14:20] <rbasak> It might break on purge edge cases.
[14:20] <dholbach> GunnarHj, oh... I'm afraid I uploaded it already
[14:20] <dholbach> https://launchpad.net/ubuntu/+source/libx11/2:1.6.3-1ubuntu3
[14:21] <GunnarHj> dholbach: Ok, thanks, it won't hurt... Then I know.
[14:24] <dholbach> ok
[14:35] <Bluefoxicy> ctrl-alt-delete logs out in gnome wtf???????
[14:35] <Bluefoxicy> instead of locking the screen lol
[14:41] <rbasak> Bluefoxicy: try #ubuntu-gnome or #ubuntu-desktop.
[14:46] <pitti> Laney: that works rather well indeed
[14:49] <Laney> pitti: great
[14:51] <pitti> https://git.launchpad.net/~pitti/+git/systemd-graphical-session FYI
[15:53] <mdeslaur> infinity, kees, slangasek, stgraber: tech board meeting in...7 minutes?
[16:51] <kenvandine> @pilot out
[16:54] <seb128> wooot, kenvandine piloting :-)
[16:54] <kenvandine> a bit :)
[16:56] <seb128> every bit counts ;-)
[19:20] <tianon> mwhudson: beyond the email Jon sent that I believe you were on CC for, nope
[19:54] <jgrimm> infinity, slangasek: did you have any opinions on email I sent (on behalf of tianon) about runc/containerd packaging & go dependencies?
[19:54] <jgrimm> hey there tianon
[19:55] <slangasek> jgrimm: I haven't formed an opinion yet; infinity is off sick
[19:55] <jgrimm> slangasek, gotcha.  ok, sort of in holding pattern on direction to get docker updated to 1.11
[20:24] <elbrus> pitti: thanks for processing cacti-spine, but interestingly, one can only use it on a fresh install when also cacti is accepted
[20:25] <pitti> elbrus: will get to that too
[20:25] <pitti> elbrus: thanks for the poke,  it was in a batch of similar SRUs wich can't be accepted yet
[20:25]  * elbrus expected that (but it looks slightly weird in the bug)
[20:27] <pitti> There are no Launchpad bugs in the changelog!
[20:27] <pitti> elbrus: ^ hmm
[20:27] <pitti> elbrus: seems you built that http://launchpadlibrarian.net/260694162/cacti_0.8.8f+ds1-4ubuntu4.16.04_source.changes with a very old (or Debian) dpkg-source :)
[20:28] <elbrus> pitti: indeed, I run Debian
[20:28]  * elbrus is DD
[20:28] <pitti> elbrus: right, I know, but I forgot that the Lauchpad-Bugs-Fixed: header was still only in ubuntu
[20:28] <elbrus> that's why; eat your own dogfood
[20:29] <elbrus> to make it worse still on Jessie...
[20:29] <pitti> elbrus: I'll reject that, rebuild the source, and reupload, so don't get scared of the REJECTED/ACCEPTED pair
[20:29] <elbrus> pitti: ack
[20:29] <rbasak> elbrus: should the cacti-spine SRU have a Breaks on older cacti if it needs a newer cacti?
[20:29] <elbrus> rbasak: it doesn't break anything
[20:30] <elbrus> as cacti can't install, cacti-spine can't install
[20:30] <rbasak> Ah, OK
[20:30] <elbrus> if you installed cacti before, you are fine
[20:30] <elbrus> so you just can't install cacti/cacti-spine in xenial right now
[20:31] <elbrus> upgrades from before with the fixed cacti-spine would work
[20:31] <rbasak> I see, thanks. I haven't really been following the details of the bug. I've been trusting you with that (since you maintain both in Debian) and not really looking at the details, only the Ubuntu process.
[20:32] <elbrus> rbasak: and thanks for that... some of those details I wasn't 100% sure of...
[20:32] <elbrus> I mean, Ubuntu process details
[20:33] <rbasak> elbrus: np. And thank _you_ for looking after Ubuntu!
[20:34]  * elbrus goes to bed now.
[20:34] <rbasak> Serving on the DMB has given me a new viewpoint. When we grant someone upload access, really it's the applicant doing _us_ a favour by uploading, not the other way round :)
[20:34] <elbrus> ;)
[20:37] <pitti> rbasak++
[20:38] <pitti> rbasak: I echo that from a sponsoring POV :)
[21:18] <nacc> is it just me, or in a systemd-only world, does memcached's /etc/init.d/memcached not make sense?
[21:19] <nacc> in particular the example provided in the same file, which doesn't work
[21:20] <nacc> given systemd, would it make sense to either update the comments in that init-script (as part of an SRU?) ... or just not ship it at all? there's a memcached.service file already
[21:27] <pitti> nacc: didn't look, but the init.d script is irrelevant if the package has an explicit .service
[21:27] <nacc> pitti: ack, that's what it seems like to me
[21:28] <nacc> pitti: would we have kept it since users can install upstart-sysv (in 16.04) -- is it relevant to upstart, i guess i mean?
[21:28] <nacc> pitti: the issue is we had an actual user try to use it as per the init-script (since it's int eh package) and it just doesn't work they way it's describe
[21:28] <pitti> nacc: possibly, yes
[21:28] <nacc> pitti: ok, i'll test and play with it, i guess, to see if i can see if it's relevant ata ll
[21:28] <nacc> it might just need clarity that it only applies to upstart
[21:28] <pitti> nacc: right, we have some LSB diversions in place to redirect "/etc/init.d/foo op" to "systemctl op foo"
[21:29] <robert_ancell> pitti, could you remove boomaga 0.7.1-1ubuntu1 from yakkety-proposed? That should have been a 0.7.1-1build4
[21:29] <pitti> robert_ancell: I'm not entirely sure whether you can go back with version numbers
[21:29] <nacc> pitti: ah ok, that would make sense; thanks for the insight!
[21:29] <robert_ancell> pitti, damn, I was wondering that too
[21:30] <nacc> i think once it's in proposed, it has to go up
[21:30] <nacc> once "published"
[21:30] <nacc> based upon reading lots of publishinghistory lately :)
[21:30] <pitti> robert_ancell: well, we can try, but it might confuse things; wgrant, up by any chance?
[21:30] <robert_ancell> They're marked as "Accepted" - does that mean it's published?
[21:31] <pitti> uploads get auto-accepted in y; publisher then happens afterwards, i. e. they get published right now
[21:31] <pitti> but the publisher shouldn't be a problem even
[21:32] <pitti> robert_ancell: TBH, if I were you I'd just reupload an -1+build4
[21:32] <robert_ancell> pitti, oh, that will work?
[21:33] <pitti> $ dpkg --compare-versions 1-1ubuntu1 lt 1-1+build4 && echo yes
[21:33] <pitti> yes
[21:33] <pitti> i. e. + > z
[21:33] <robert_ancell> ok, I'll do that
[21:33] <robert_ancell> thanks
[22:21] <wgrant> pitti: Hi