[00:01] <magicaltrout> well one thing thats coming in our next release is like 1 click schema design (assuming you have a sane table) so it'll make it easy(ier) to do saiku demos which will be cool
[00:02] <magicaltrout> anyway.... i'm offski
[00:02] <magicaltrout> cya arosales hope your lightning talk goes well
[00:02] <magicaltrout> oh on a slight side note admcleod the speakers gift from apachecon was posh chocolate, one was bluecheese
[00:02] <magicaltrout> it was disgusting......
[01:41] <blahdeblah> Hi all; what's the preferred method for shutting down the local lxd-based controller/model when I'm not using it?  Just lxc stop?
[01:46] <lazyPower> blahdeblah - that should work just fine yeah.
[01:47] <blahdeblah> thanks lazyPower - I found my hard disk a *lot* more chattery while the local provider is running
[01:47] <lazyPower> oh certainly, hte logging to mongo keeps that pretty  much constant
[01:47] <blahdeblah> ugh; any way we can turn that off?
[01:48] <lazyPower> logging to mongo? afraid not, thats a core function of the controller now that there's multi-model support
[01:48] <blahdeblah> :-(
[01:50]  * blahdeblah would really like a "This is just my laptop; don't destroy my SSD or log anything" setting
[01:51] <lazyPower> that sounds like a decent feature request
[01:51] <lazyPower> i would bug that, and see if makes it on the roadmap
[01:54] <lathiat> yeah i keep having to remember to lxc stop it


[00:05] -queuebot:#ubuntu-release- Unapproved: nano (xenial-proposed/main) [2.5.3-2 => 2.5.3-2ubuntu1] (core)
[00:31] -queuebot:#ubuntu-release- Unapproved: libseccomp (trusty-proposed/main) [2.2.3-2ubuntu1~ubuntu14.04.1 => 2.1.1-1ubuntu1~trusty1] (core)
[00:34] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu3]
[00:40] <slangasek> coreycb: hi, so ddebs.  What kind of disk requirements do you have for these on the cloud archive, now / in the future?
[02:32] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu13 => 229-4ubuntu14] (core)
[02:39] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (yakkety-proposed) [1.79ubuntu1.1]
[02:40] -queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu3 => 1.78ubuntu4] (core)
[02:45] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu4]
[02:47] <slangasek> bdmurray: I could use ^^ a different set of eyes on the systemd/xenial piece of that
[05:23] -queuebot:#ubuntu-release- New binary: jdupes [ppc64el] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: jdupes [s390x] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [arm64] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [powerpc] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [armhf] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: zorp [ppc64el] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: libcgns [ppc64el] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: libcgns [s390x] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: chicken [s390x] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: chicken [ppc64el] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: jdupes [i386] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: jdupes [amd64] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: libcgns [powerpc] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcgns [arm64] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcgns [armhf] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: chicken [powerpc] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: libcgns [i386] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: libcgns [amd64] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: chicken [i386] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: zorp [amd64] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: netdata [amd64] (zesty-proposed/none) [1.3.0+dfsg-1] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: chicken [armhf] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: chicken [amd64] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: zorp [i386] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: zorp [arm64] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:48] -queuebot:#ubuntu-release- New binary: chicken [arm64] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:48] -queuebot:#ubuntu-release- New binary: zorp [armhf] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[07:10] <mardy> seb128: hi! Would you have a little time to remove a couple of packages from xenial-proposed?
[07:10] <seb128> mardy, hey, are they in the queue or accepted SRUs? I'm not in the SRU team so while I technical can I'm not supposed to deal with SRUs
[07:13] <mardy> seb128: I'm not sure, they certainly were not accepted, the verification failed
[07:13] <seb128> oh, then they got accepted
[07:13] <mardy> seb128: it's online-accounts and gnome-control-center-signon, in case you are able to check
[07:13] <seb128> otherwise they would be in the unapproved queue and nobody would have tested them
[07:13] <seb128> but let me have a look
[07:14] <seb128> https://launchpad.net/ubuntu/+source/gnome-control-center-signon/0.1.9+16.04.20160719-0ubuntu1
[07:17] <seb128> mardy, is that the upload you are talking about ^? the corresponding bug is verification-needed with a comment from you stating what to verify, not verification-failed?
[07:20] <mardy> seb128: yes, it's that one: dbarth verified it and noticed the failure, I'll ask him to add a comment there
[07:21] <seb128> mardy, thanks, once it's verification-failed the SRU team should handle it (maybe add a comment stating if you want it removed or if you want to do a follow up upload with extra fix to replace the current version in xenial-proposed)
[07:22] <mardy> seb128: ah ok, that makes sense
[07:22] <mardy> seb128: thanks!
[07:23] <seb128> yw!
[07:26] -queuebot:#ubuntu-release- Unapproved: signing-party (yakkety-proposed/universe) [2.4-1 => 2.4-1ubuntu1] (no packageset)
[09:37] <jibel> Could someone review snapd 2.20 in xenial and yakkety queues?
[09:38] <jibel> apw, ^ can you help with this ?
[10:02] <jibel> tjaalton, ^ can you help with the review of snapd 2.20?
[10:04] <jibel> rbasak, ^ or anyone from the sru team :)
[10:05] <tjaalton> jibel: i can give it a try later
[10:05] <seb128> tjaalton, you joined the SRU team? ;-)
[10:05] <tjaalton> yes
[10:05] <seb128> nice
[10:06] <jibel> tjaalton, cool, how later is later?
[10:06] <sil2100> Could someone review dbus in the xenial and yakkety queues? ;)
[10:07] <jibel> sil2100, no way, snapd first ;)
[10:07] <seb128> in all fairness he's asking for several days
[10:07] <seb128> so dbus should be first :p
[10:07] <jibel> meh
[10:07] <sil2100> ...sorry!
[10:07] <seb128> we already miss pitti :-/
[10:07] <tjaalton> jibel: I see 14 older packages in the queue ;)
[10:08] <jibel> tjaalton, I know, do your best.
[10:08] <seb128> but would be good to get snapd in today, otherwise I can see some people who are going to be grumpy about things
[10:09] <seb128> on the good side, maybe that would convince some of the team managers to allocate resources in their team to do SRU reviews... ;-)
[10:10] <sil2100> I'm in mid-training to join the SRU team
[10:10] <sil2100> At least that's the idea, I guess
[10:11] <tjaalton> great
[10:13] -queuebot:#ubuntu-release- Unapproved: accepted nano [source] (xenial-proposed) [2.5.3-2ubuntu1]
[10:16] <tjaalton> jibel: looks like bdmurray reviewed it already? see the comment on 1648520
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (xenial-proposed) [1.13.2+dfsg-5ubuntu1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (trusty-proposed) [1.12+dfsg-2ubuntu5.3]
[10:23] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (yakkety-proposed) [1.14.3+dfsg-2ubuntu1]
[10:39] -queuebot:#ubuntu-release- New binary: strongswan [s390x] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:40] -queuebot:#ubuntu-release- New binary: strongswan [ppc64el] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [amd64] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [powerpc] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [i386] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:55] <jibel> tjaalton, thanks, I'll check with mvo
[11:01] <tjaalton> sil2100: I don't know why, but sru-review can't see dbus for yakkety, while it's clearly on the queue
[11:03] <sil2100> tjaalton: hmm, maybe it's because I set yakkety-updates in the changelog instead of yakkety?
[11:03] <tjaalton> ah
[11:03] <sil2100> I noticed that a bit uh later
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (xenial-proposed) [1.10.6-1ubuntu3.2]
[11:05] <tjaalton> well, I can ack it from lp instead, but it won't send a notification to the bug(s)
[11:05] <tjaalton> aiui
[11:05] -queuebot:#ubuntu-release- New binary: strongswan [armhf] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[11:06] -queuebot:#ubuntu-release- New binary: strongswan [arm64] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[11:06] <tjaalton> I'll do it manually
[11:07] <sil2100> I can re-upload if this is the problem
[11:07] <tjaalton> oh actually
[11:07] <tjaalton> yeah
[11:07] <sil2100> (I mean, yakkety-updates instead of yakkety)
[11:07] <tjaalton> probably best
[11:08] <tjaalton> rejected
[11:08] -queuebot:#ubuntu-release- Unapproved: rejected dbus [source] (yakkety-updates) [1.10.10-1ubuntu1.2]
[11:09] <sil2100> tjaalton: re-uploaded :)
[11:09] <sil2100> Thanks!
[11:09] -queuebot:#ubuntu-release- Unapproved: dbus (yakkety-proposed/main) [1.10.10-1ubuntu1.1 => 1.10.10-1ubuntu1.2] (core)
[11:12] <tjaalton> sil2100: now zeromq3, maybe upload with a changelog that does not refer to (LP: #1597439), because the MIR is fixed already
[11:12] <ubot5`> Launchpad bug 1597439 in zeromq3 (Ubuntu) "[MIR] zeromq3" [High,Fix released] https://launchpad.net/bugs/1597439
[11:14] -queuebot:#ubuntu-release- Unapproved: rejected zeromq3 [source] (yakkety-proposed) [4.2.0-2ubuntu0.16.10]
[11:14] -queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (yakkety-proposed) [1.10.10-1ubuntu1.2]
[11:26] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[11:28] <sil2100> tjaalton: ah, you mean with the same changelog but without the bug reference, yes?
[11:28] <tjaalton> sil2100: right, or ref modified so that the tools don't catch it
[11:28] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[11:31] <sil2100> tjaalton: ok, re-uploaded :)
[11:31] -queuebot:#ubuntu-release- New source: snapd (trusty-proposed/primary) [2.20~14.04.0ubuntu1]
[11:32] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[11:32] -queuebot:#ubuntu-release- Unapproved: zeromq3 (yakkety-proposed/main) [4.1.5+git20160811+2fc86bc-0ubuntu2 => 4.2.0-2ubuntu0.16.10] (kubuntu)
[11:43] <tjaalton> sil2100: thanks, looks like 4.2.0 is still in zesty-proposed so can't ack it yet
[11:44] <sil2100> tjaalton: oh? Oh my, how did I miss that
[11:44]  * sil2100 feels ashamed now
[11:44] <sil2100> Ok, I'll re-poke you once I deal with this
[11:44] <bluesabre> Good morning! Would anybody be interested in releasing sgt-launcher from the NEW queue? lp 1641300
[11:44] <ubot5`> Launchpad bug 1641300 in Ubuntu "[needs-packaging] sgt-launcher" [Wishlist,Fix committed] https://launchpad.net/bugs/1641300
[11:52] <tjaalton> how come ubuntu doesn't have cairo-c5, which blocks ricochet
[11:53] -queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (yakkety-proposed/main) [3.20.4-0ubuntu1 => 3.20.5-0ubuntu0.1] (ubuntu-desktop)
[11:57] <tjaalton> cairo-5c actually, just doesn't build
[12:00] <jibel> tjaalton, mvo replied, snapd ready for review again
[12:42] <jibel> or bdmurray ^
[12:49] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (yakkety-proposed) [16.07.2-0ubuntu<IP_ADDRESS>]
[12:49] <tjaalton> ok
[13:06] <coreycb> slangasek, it looks like the quota for our newton-updates PPA is 20GB.  so my guess of PPA disc space used currently would be 100GB (20 x 5 releases).  do you think we can translate that to space needed for ddebs?
[13:13] <cjwatson> so, um
[13:14] <cjwatson> ddebs.ubuntu.com is basically a compatibility thing
[13:14] <cjwatson> is it not possible for clients to fetch the ddebs directly from LP?
[13:18] <cjwatson> you're going to have to store the ddebs in LP regardless, so let's not duplicate that storage on ddebs.u.c
[13:38] <tjaalton> jibel: you uploaded the same snapd package twice?
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.2]
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.3]
[13:50] -queuebot:#ubuntu-release- Unapproved: accepted tracker [source] (yakkety-proposed) [1.10.2-0ubuntu0.1]
[14:01] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10]
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted signing-party [source] (yakkety-proposed) [2.4-1ubuntu1]
[14:03] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20]
[14:12] <jibel> tjaalton, mvo uploaded the same package and modified the changelog to remove the reference to lp bugs and address bdmurray's comment. I'm just relaying the message here because mvo's on holidays
[14:21] <slangasek> jibel, tjaalton: I see that the new snapd package has merged ubuntu-core-launcher / snap-confine into the source.  I am concerned about whether the existing SRU exception provides appropriate CI coverage of those components
[14:23] <tjaalton> jibel: ok
[14:27] <tjaalton> slangasek: good point, I probably wouldn't have noticed..
[14:28] <jibel> slangasek, okay, let me check with the team
[15:03] <jibel> slangasek, a successful run of the unit tests for snap-confine on one arch would be enough for this time?
[15:30] <slangasek> jibel: on one arch> I wouldn't think so.  Do the unit tests not run at package build time / autopkgtest time?
[16:15] <lamont> can someone please accept cloud-init into yakkety-proposed?
[16:18] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[16:20] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[16:22] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[16:47] <lamont> tjaalton: can you accept cloud-init into yakkety-proposed?
[16:57] <lamont> tjaalton: actually, hold off on that for a bit
[17:05] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.5 => 0.103ubuntu4.6] (core)
[17:21] <tjaalton> lamont: okay
[17:22] <lamont> tjaalton: chatted with smoser - we're going to have that one land after the current SRU lands on Monday.  (trivial workaround in new functionality, ergo not critical to the current SRU)
[17:22] <tjaalton> sounds perfect ;)
[17:22] <lamont> not sure what your processes say about letting it sit in the queue until then
[17:23] <tjaalton> can sit
[17:23] <ppisati> bug 1636838
[17:23] <ubot5`> bug 1636838 in linux-raspi2 (Ubuntu) "Failed to boot" [Undecided,Confirmed] https://launchpad.net/bugs/1636838
[17:23] <ppisati> so, i've covered all the possible upgrade paths
[17:24] <ppisati> if the four packages mentioned there could be release from -proposed to -updates
[17:24] <ppisati> that would be nice
[17:24] <ppisati> Xenial and Yakkety, thanks
[17:25] <smoser> tjaalton, lamont actually, just nix the yakkety cloud-init
[17:25] <smoser> i'll upload another in line with what is in zesty
[17:27] <lamont> smoser: presumably that upload will be next week?
[17:28] -queuebot:#ubuntu-release- New binary: mongo-tools [s390x] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: mongo-tools [ppc64el] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: node-tar-stream [amd64] (zesty-proposed/universe) [1.5.2-1] (no packageset)
[17:31] -queuebot:#ubuntu-release- New binary: fsm-el [amd64] (zesty-proposed/universe) [0.2.1-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: node-has-cors [amd64] (zesty-proposed/universe) [1.1.0-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: node-lodash-packages [amd64] (zesty-proposed/universe) [4.15.0-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: mongo-tools [i386] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:35] <smoser> lamont, well, i'll put it into the queue right now
[17:35] <smoser> and then it can be let into -proposed later.
[17:37] -queuebot:#ubuntu-release- New binary: mongo-tools [amd64] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: mongo-tools [armhf] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:42] <lamont> ack
[18:01] <doko> please unblock the binutils/linux autopkg test, this test always failed with 4.8 ...
[18:16] <lamont> smoser: I believe that all of the cases 1621507 cares about are verified, so I marked it verification-done... anything specific that we need to do wrt 1621615 before I also mark it?
[18:17] <infinity> doko: I'll grab binutils in my big unblock the world right after I'm done cleaning up the kernel (so in a few hours, probably).
[18:24] <smoser> lamont, its fine with me
[18:34] <clivejo> infinity: did you get a chance to look at krita?
[18:35] <infinity> clivejo: Nope, going flat out with several other things.  If it's urgent, you'll want another AA.  If not, it might have to wait for my holidays.
[18:35] <clivejo> it used to be in the source package calligra
[18:35] <infinity> And the goodwill of me as a community member, rather than a Canonical employee.
[18:35] <clivejo> which has been split out
[18:35] <infinity> Since Canonical owns about 180% of my time until next week. :)
[18:37] <clivejo> wow, were you naughty as the company Christmas party too?!?
[18:38] <clivejo> any other AA willing to have a look please?
[18:51] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.23+16.10 => 2.24+16.10] (no packageset)
[18:52] <davmor2> infinity: only 180% what did you do so right? ;)
[18:52] <infinity> davmor2: Time off for good behaviour.
[18:52] <davmor2> infinity: pfff
[18:59] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.23 => 2.24] (no packageset)
[18:59] <sergiusens> slangasek mind taking a look ^ ?
[19:19] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[19:22] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[19:25] <slangasek> sergiusens: looking
[19:27] <slangasek> sergiusens: what's this armv7 autopkgtest disabling about?
[19:30] <slangasek> sergiusens: a lot of autopkgtest disabling going on today in the SRU queue.  NACK on this; we want the tests to run, and if they fail they fail
[19:31] <slangasek> sergiusens: also, your check won't actually match the armhf autopkgtest runners, if that was your intent, since they're all arm64 kernels ;)
[19:33] <sergiusens> slangasek because we want them green and making them green progressively
[19:34] <slangasek> sergiusens: making them artificially green is not particularly beneficial here
[19:34] <sergiusens> slangasek these are in-flight right now https://github.com/snapcore/snapcraft/pull/971 https://github.com/snapcore/snapcraft/pull/990
[19:34] <sergiusens> elopio ^
[19:35] <sergiusens> slangasek the reason we care to make them green is to not break them again, but I can understand your concerns
[19:35] <slangasek> sergiusens: but you're making them green by no-op'ing all of the autopkgtests that are run
[19:35] <slangasek> "To not break them again" - but they seem to have never worked in the first place
[19:36] <sergiusens> slangasek in my defense, I took my QA guy's advice
[19:37] <slangasek> :-)
[19:37] <sergiusens> slangasek I can enable them in a new push if you want
[19:37] <slangasek> sergiusens: yes please
[19:37] <sergiusens> slangasek if you reject I can use the same versions, right?
[19:37] <slangasek> sergiusens: (or I can just edit this out and reupload on my side)
[19:37] <slangasek> sergiusens: yes
[19:38] <elopio> slangasek: we are not disabling them. We are enabling them[
[19:38] <sergiusens> slangasek k, will do in a bit
[19:38] <slangasek> elopio: that's not what the diff looked like to me?
[19:38] <elopio> slangasek: previously, they just failed so didn't block the landings.
[19:38] -queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.24]
[19:39] <elopio> in this SRU, we are disabling integration tests so the unit tests for arm will pass and start blocking landings in case of regression.
[19:39] <elopio> in the next SRU. we are enabling the others.
[19:39] <sergiusens> slangasek fwiw, pitti had mocked the containers to return a uname for an expected armhf machine on those arm64 servers
[19:40] <slangasek> elopio: what unit tests are those?  debian/tests/control lists only two tests; both of which are failing on armhf; and both of which have been no-op'ed in this upload
[19:40] <elopio> slangasek: the unit tests run during package build.
[19:40] <slangasek> sergiusens: a) ugh b) it's still not the right way to check the target architecture
[19:40] <sergiusens> slangasek I know, we have a fix planned for that
[19:40] <slangasek> elopio: ok, which still means that you're getting a meaningless green on autopkgtests
[19:40] <elopio> before this sru, our package failed to build in armhf.
[19:41] <slangasek> elopio: the autopkgtests are being run at build time?
[19:41] <elopio> slangasek: yes, meaningless green for now. My PRs that are ready to land will make the autopkgtests blockers in case of regression too.
[19:42] <slangasek> elopio: still a nack from me.  Failing autopkgtests > skipped autopkgtests.
[19:42] <elopio> uh, I disagree totally with that. Failing autopkgtests means that if unit tests also fail, we still land.
[19:43] <elopio> right now, we are blocking on unit tests regression, that's better than never identifying regressions.
[19:43] <slangasek> where are you triggering the autopkgtests from that this blocks landing?
[19:43] <elopio> travis on each pull request.
[19:43] <elopio> we caught a failure in a test yesterday, that was assuming amd64.
[19:43] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.23 => 2.24] (no packageset)
[19:43] <elopio> that wouldn't have been possible if we had just full autopkgtest failures.
[19:44] <sergiusens> elopio just fix it all in one stretch during holidays ;-)
[19:44] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.23+16.10 => 2.24+16.10] (no packageset)
[19:44] <sergiusens> slangasek pushed both up again
[19:44] <elopio> I tried to land the three in the same SRU last week, but failed.
[19:45] <slangasek> if you wanted to conditionally skip these tests in the travis environment, that would be fine with me
[19:45] <slangasek> but in proposed-migration, failing autopkgtests > skipped autopkgtests
[19:45] <elopio> I can't skip only in travis, because travis runs the same as proposed-migration.
[19:45] -queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (yakkety-proposed) [2.24+16.10]
[19:46] <slangasek> but it runs under travis as a harness, which could be configured to ignore autopkgtest failures on armhf
[19:46] <elopio> and, I still disagree. It's better to notice that there are regressions in a few tests, than to run many more tests but never catch anything.
[19:46] <elopio> but well, we can revert and just plainly fail in arm for one more release.
[19:46] <sergiusens> elopio if it is a requirement, it is a requirement, just take that and propose a change later ;-)
[19:46] <sergiusens> slangasek elopio to be fair as well, this is not travis, this is the adt webhook for upstreams thing
[19:46] <slangasek> you're not running *a few* tests.  You are literally running *zero* autopkgtests, with this change
[19:47] <slangasek> if you had left one autopkgtest enabled, then I would agree with you ;)
[19:48] <sergiusens> slangasek unit tests run on package build and given our arch all nature the package is built only on amd64 whilst on adt it is natively built (in the case of adt for upstreams at least)
[19:48] <elopio> https://github.com/snapcore/snapcraft/pull/1005
[19:48] <sergiusens> slangasek in any case I see you rejected rejected snapcraft [source] (yakkety-proposed) [2.24+16.10] after I uploaded again any reason?
[19:51] <infinity> 12:31 < slangasek> sergiusens: also, your check won't actually match the armhf autopkgtest runners, if that was your intent, since they're all arm64 kernels ;)
[19:51] <infinity> slangasek: ^-- If you mean "uname -m" won't be "armv7l", you'd be wrong.  Though, still fair to point out that assuming uname==userspace is wrong.
[19:52] <sergiusens> infinity I promise to migrate to what we discussed 2 weeks ago as soon the holidays are over
[19:53] <infinity> sergiusens: Yeah, I know you're good for keeping your promise there.  Was more just pointing out to slangasek that his understanding of the infrastructure is wrong. :)
[19:54] <infinity> slangasek: Also, it's not about "mocked containers", per se, as sergiusens implies, it's just that 32-bit tests are run under linux32, just as 32-bit builds are.
[19:54] <infinity> slangasek: Though, the extra trick there is that linux32 on aarch64 would usually return armv8l, and we have a kernel hack in place that makes that armv7l because upstream is wrong and I'm sick of arguing the point with them. :P
[19:58] <slangasek> infinity: haha ok
[19:59] <elopio> infinity: hey, your point was taken. No argue there.
[19:59] <slangasek> sergiusens: that should have been the reject of the original yakkety upload, which I hadn't rejected yet. your second upload is still in the queue
[19:59] <slangasek> except now it's not - accepted
[20:00] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.24+16.10]
[20:05] <elopio> thanks slangasek. For the next release I will give you a full green armhf. And then, the rest archs.
[20:05] <slangasek> elopio: great :)
[20:06] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.24]
[20:16] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[20:16] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[20:17] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[20:17] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[20:32] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[20:33] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[20:33] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[20:34] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[21:09] <sergiusens> slangasek thanks!
[22:35] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.20ubuntu1]
[22:46] -queuebot:#ubuntu-release- Unapproved: tracker (yakkety-proposed/main) [1.10.2-0ubuntu0.1 => 1.10.3-0ubuntu0.1] (desktop-extra, ubuntugnome)


[15:42] <OvenWerks> Eickmeyer: FYI (in case you didn't already know) systemctl has not only --system and --user but also --global
[15:43] <Eickmeyer> OvenWerks: Yep.
[15:43] <OvenWerks> Eickmeyer: sudo systemctl --user does not work it has to be done as the user and it adds or takes away files in .config/systemd/user
[15:44] <OvenWerks> --global does files in /etc/systemd/user
[15:45] <OvenWerks> It seems we can switch between pulse/jack and pipewire without a reboot.
[15:45] <Eickmeyer> --global affects all users.
[15:46] <OvenWerks> yeah, so I am wondering which I should use in controls
[15:47] <Eickmeyer> .config/systemd/user trumps /etc/systemd/user in the path, so I'd use --user.
[15:47] <OvenWerks> audio is kind of a global service, only one user can use it at a time.
[15:47] <Eickmeyer> And that's true too.
[15:47] <Eickmeyer> You can't switch users, but logging out and logging in as a different user with a different config can be a thing.
[15:48] <OvenWerks> but if two people use a machine they may both want different setups
[15:49] <Eickmeyer> Right. I'd consider university audio workstations.
[15:51] <OvenWerks> ok, I will set up for --user, it seems to work.
[15:53] <OvenWerks> Eickmeyer: it seems that with pipewire, I don't really need autojack, everything can be set up by the gui anyway.
[15:54] <Eickmeyer> OvenWerks: Right, it seems to "just work", in theory.
[15:54] <OvenWerks> Autojack just needs to "stay out of the way" as in not try to restart pulse
[16:00] <Eickmeyer> Patchance was accepted into Lunar yesterday, building right now in backports for Jammy and Kinetic.
[16:06] <OvenWerks> I guess it won't just show up in an update, so when it makes it I will need to install
[16:15] <Eickmeyer> No, it won't show up because it would have to be added for a meta first.
[16:17] <OvenWerks> If it works well, I will change the Carla button to connections or patch bay or something and have it launch Patchance, catia, patchage or Carla depending on what it finds
[18:17] <OvenWerks> Eickmeyer: just installed Patchance, I like what it does with the Midi-Bridge, nice short names. There is a bug with port names for ports over 9 (or one could argue port names under 10) https://i.imgur.com/JNne4Wt.png
[18:19] <ErichEickmeyer[m> Probably a bug in https://github.com/Houston4444/HoustonPatchbay then.
[18:28] <OvenWerks> Is it the same project? Or a wrapper?
[18:29] <Eickmeyer> So, Patchance (and RaySession) use HoustonPatchbay as the patchbay.
[18:30] <Eickmeyer> It's basically a static lib in both projects, OvenWerks.
[18:33] <OvenWerks> It is interesting to see how different people interperate the names for a patch bay. I am looking at 4 of them: patchance, Carla, Qjackctl, and qpwgraph
[18:33] <OvenWerks> The last two are both by RNC
[18:34] <Eickmeyer> Carla's patchbay comes from Catia. Qpwgraph's patchbay comes from Qjackctl.
[18:34] <OvenWerks> Carla's patchbay is better than catia which is broken
[18:35] <OvenWerks> But I would guess it uses a lot of the same code
[18:35] <OvenWerks> but qjackctl and qpwgraph name the ports (or at least the port boxes) differently
[18:35] <Eickmeyer> Considering it's the same author, I'd guarantee it.
[18:37] <OvenWerks> I would like to see him move some of the fixes in Carla over to Catia.
[18:38] <Eickmeyer> Are you sure you're not mixing up Catia with Claudia? Because Claudia is broken.
[18:39] <OvenWerks> Catia which was broken out into it's own project shows two of each client (or maybe three?)
[18:39] <Eickmeyer> Oh, I didn't know Catia was broken out of Cadence.
[18:39] <OvenWerks> It has one that shows no ports but is just the client
[18:40] <OvenWerks> So it shows controls for example even though controls has no ports
[18:42] <OvenWerks> qjackctl and Carla both show MidiBridge ports as the full long name. In both cases the "box" name is part of the port name (or the client name)
[18:43] <OvenWerks> Actually, patchance does too, but also uses an icon for the program if available and stock icons for devices
[18:44] <OvenWerks> I think the Icons are a nice touch and it helps my eyes pick out clients easier
[18:55] <OvenWerks> qpwgraph, even being similar looking to qjackctl, uses the device description for the box name and then gives each port the full port name. So for example, I have my audiofire12 set so in jack_lsp it is system:playback_aux* and most of these graph applications show it as such but qpwgraph shows the box name as AudioFire12 Pro
[19:08] <OvenWerks> Eickmeyer: Onr thing I don't like about all of them when running pipewire is that when opening pavucontrol or even clicking on the plasma audio widget in the taskbar is that they show up as clients connected to many things, sometimes many clients. It makes the graph very hard to work with. It shows up in jack_lsp too, so this is a PW bug (feature?)
[19:10] <Eickmeyer> I'm not sure. I think in those cases a patchbay becomes the source of truth over pavucontrol.
[19:12] <OvenWerks> I suspect pavu control or plasma pa uses the signals for metering but I think they should be counted as special and hidden because the user doesn't gain anything by changing the connections which will in any case get recreated with each change anyway.


 Here of late Saturdays are always slow .. People do not fix on saturdays ??. Or 'buntu is so stable it no longer breaks ?
[07:20] <ducasse> could be they just have other things to do, like get drunk :)
[07:23] <Bashing-om> What a waste ,, when they could be ;buntu'n ! ( I do not miss them drink nights and days )
[07:29] <ducasse> me neither, quit that kind of thing a looong time ago.
[07:38] <Bashing-om> reformed alchy is me .. All those wasted nights and days ,, and the conflicts ! legal expenses ! insurance ! .. nope not going back ! ( A drunkard shall not inherit the kingdom of Heaven )
[07:44] <Bashing-om> Anyway, backing down and out .. Yall take care of things = good night .
[08:36] <lordievader> Good morning.
[08:37] <ducasse> wb lordievader
[08:37] <lordievader> Hey ducasse, how are you this sunday?
[08:43] <ducasse> good, thanks. staying in, waiting for some people to come pick up a desk and some other furniture i'm giving away. how are you?
[08:46] <lordievader> Doing okay, wanting to install Firefox Nightly, but there doesn't seem to be an ebuild for that :(
[08:49] <ducasse> that's one of the disadvantages of using a smaller distro, probably the main reason why i'm still on ubuntu on my desktop...
[08:55] <lordievader> This is gentoo that I am talking about, their latests is 51, mozilla latest is 53.
[08:55] <lordievader> Installed that yesterday on Windows, was quite happy with the improvement.
[12:34] <BluesKaj> Hiya folks


[00:10] <retrojeff> ohhhh pidgin was showing broken because I have a PPA enabled
[00:10] <retrojeff> disabled the PPA and now its fine
[00:28] <retrojeff> ok marking libautopilot-qt for upgrade
[00:28] <retrojeff> holy hell batman
[00:29] <retrojeff> like just that 1 package so many things depend on it
[00:31] <retrojeff> oh I am going about this backwords
[00:31] <retrojeff> I need to remove/purge packages that are not used it 16.04
[00:31] <retrojeff> and upgrade the rest
[12:35] <BluesKaj> Hey all
[18:36] <retrojeff> ok so I am now running 16.10
[18:36] <retrojeff> most if not all my packages are up to date
[18:37] <retrojeff> after spending close to 5 hours resolving depends
[18:37] <retrojeff> ohhhhhhh 16.04 not 16.10
[18:37] <retrojeff> anyways every 5 min if I dont touch anything my screen will blank
[18:38] <retrojeff> and moving the mouse will return to the login screen
[18:38] <retrojeff> and xscreensaver is not running
[18:38] <retrojeff> bug #1
[18:38] <retrojeff> stupid bot hush
[18:39] <retrojeff> ./me slaps ubottu with a large trout
[18:39] <retrojeff> the 2nd problem is certain menus have odd boxes around them
[18:41] <retrojeff> I think both these issues are related to nvidia drivers
[18:46] <retrojeff> ok the blank screen thing its related to bbswitch


[14:04] <ubuntushop> ubuntustudio 23.10 oem-prepare end user wants to remove aptdeamon, but this package is essential
[15:24] <Eickmeyer> ubuntushop: File a bug against ubiquity
[15:24] <Eickmeyer> 'ubuntu-bug ubiquity'
[15:25] <Eickmeyer> And I hate to say it, but it probably won't get fixed as it would require a respin of the .iso image and we're moving to an entirely new install process for 24.04
[16:15] <ubuntushop> removing aptdaemon (which also removes oem-config and oem-config-gtk) and installing oem-config again before running oem-config-prepare fixes the error.
[16:16] <ubuntushop> will the new installer has oem install?
[16:17] <ubuntushop>  so installing oem-config, but not oem-config gtk
[16:18] <ubuntushop> no problem in ubuntu 23.10 legacy
[17:12] <Eickmeyer> ubuntushop: We didn't define anything for oem-config, so I don't know what to tell you.
[17:12] <Eickmeyer> ubuntushop: New installer *must* have an OEM install, otherwise Ubuntu Desktop won't be using it.
[17:13] <Eickmeyer> ubuntushop: But please know, you're barking up the wrong tree here.
[17:14] <Eickmeyer> ubuntushop: There's literally nothing we can do about it. This is the kind of thing we wish we knew *before* release, not nearly two months later.
[17:14] <Eickmeyer> ubuntushop: Testing oem stuff is something usually reserved for LTS releases, and we don't have any OEM partners for Ubuntu Studio currently.
[18:41] <ubuntushop> Ok, thanks.


[09:24] <mxx> hello,anybody?
[23:59] <sbtech> anyone run into a permission denied error during the juju bootstrap process? It is happening right after MaaS deploys the server and the landscape install starts


[02:30] <cjohnston> I guess my email opened me up to recieving all sorts of email.. from emails about support for tutorials on my website to who knows what else
[02:55] <pleia2> is this a good thing?
[03:02] <cjohnston> depends
[03:03] <cjohnston> a few about UUD.. all asking about lernid
[03:03] <cjohnston> and one wanting me to help someone setup a lamp stack
[03:10] <Vantrax> fyi peoples ill be away for a week at a linux conference
[03:18] <pleia2> Vantrax: cool, LCA?
[03:20] <Vantrax> yep
[03:20] <Vantrax> Im presenting and running a discussion group
[03:20] <pleia2> awesome :)
[03:20] <pleia2> I hear it's a great conference, have you been before?
[03:20] <Vantrax> nope
[03:21] <Vantrax> I hear its in the top 3 in the world now
[03:21] <Vantrax> linus was giving the keynote last year
[03:21] <pleia2> yeah
[03:21] <Vantrax> he usually attends apparently
[03:21] <Vantrax> as does stalman
[16:54] <pendulum_> pleia2: Just a small note, but I think you meant to say "remote participation"?
[16:54] <pendulum_> (in your blog)
[16:55] <pleia2> what did I say?
[16:55] <pleia2> oh, the second one
[16:55] <pleia2> thanks :)
[16:56] <pleia2> pendulum_ is all over my blog today!
[16:56] <pendulum_> Np. Thanks for blogging :)
[16:56] <pleia2> :)
[16:56] <pendulum_> Hah
[16:57] <pleia2> figured I'd push the User Days post out now while my blog is being visited lots for the UW thing
[16:57] <pendulum_> Yeah
[16:57] <pendulum_> Oh, if I ping you the rss feed link when I get home tonight, can you add me to the UW planet?
[16:58] <pleia2> sure
[17:02] <pendulum_> Thank you :)
[18:19] <DiegoTc> ping cjohnston


[00:19] <TiMiDo> Nice. I finally, got accept. it, officially Ubuntu, Member,
[01:24] <TiMiDo> thanks a lot itnet7
[01:39] <mhall119> congrats TiMiDo
[01:39] <TiMiDo> thank you mhall119 ;)


[00:02] <poolie> jam, igc, spiv: call now
[00:02] <jam> poolie: waiting for you to show up :)
[00:16] <lifeless> jam: also - #ubuntu-wow
[00:16] <lifeless> poolie: ^
[00:21] <poolie> thanks
[00:21] <poolie> lifeless, igc: reading the thread now, this might take more than 15 mins
[00:22] <lifeless> -> food then
[00:22] <igc> poolie,lifeless: let's aim for 10 then
[00:27] <poolie> k
[00:50] <lifeless> abentley: ping; are you interested in me making MPVersionedFile meet the VersionedFile (reduced) api ?
[00:58] <lifeless> abentley: also can I request a review from you for my loom push fix.
[01:01] <ChrisPitzer> Hello.  I've used bzr in linux before, but now I'm trying to get it working in windows through putty.  I can run bzr in a terminal, or I can run putty and log on to my server (where I'd like to build a repository) with putty... but I'm not sure how to run bzr in putty...  I think I'm missing something.
[01:01] <lifeless> poolie: igc: its 10
[01:02] <igc> poolie,lifeless: normal number?
[01:02] <lifeless> igc: as far as I knew, yes.
[01:02] <poolie> we could use skype if that's easier?
[01:02] <lifeless> elevator music @ home sucks
[01:03] <igc> calling in now on normal number
[01:06] <dagreen> hey, can someone help a noob with an admin question?
[01:06] <dagreen> I'd like to setup an server for a central repository
[01:06] <dagreen> the docs tell me to use sftp to upload a branch
[01:07] <dagreen> but I want to make it publicly accessible
[01:07] <dagreen> how would I do this with sftp?
[01:07] <bob2> you can make it read-only accessible via http, and have users write via sftp
[01:08] <dagreen> so, setup an apache server?
[01:09] <bob2> well, whatever htpd you like.  you could setup an anonymous sftp account if you prefer.
[01:09] <bob2> gnu used to do that for cvs over ssh, iirc
[01:09] <dagreen> OK.  so, I tried searching for some good docs on settings up sftp, but came up short
[01:10] <dagreen> can someone point me to a good guide?
[01:10] <dagreen> I can setup sftp so users can access their own home dir, but not to a shared dir
[01:10] <dagreen> or even how to allow anonymous access for that matter?
[01:12] <poolie> this is hard enough even if i can hear you :)
[01:12] <poolie> dagreen: on unix or windows
[01:12] <dagreen> fedora
[01:13] <ChrisPitzer> How do i uze bzr in putty?
[01:13] <dagreen> unix
[01:13] <bob2> ChrisPitzer: what preciesly are you trying to do?  use bzr+ssh:// urls?
[01:13] <poolie> dagreen: so basically you should put them in a unix group
[01:14] <poolie> and create a directory writeable by that group to hold the repositories
[01:14] <poolie> if you're trying to host an open source project you can alternatively use launchpad.net
[01:14] <dagreen> not open source, internal company use
[01:15] <dagreen> so, if they were to checkout a project by typing bzr branch sftp://my-server/myproject
[01:16] <dagreen> do I have to put a link to that directory from all their home directories or something?
[01:16] <bob2> no
[01:16] <ChrisPitzer> bob2: I'm trying to use putty to ssh onto a server and set up / work with bzr repositories.
[01:17] <bob2> users connected via sftp have the same access rights as they would if they logged in via ssh
[01:17] <bob2> so it can go anywhere they could normally reach it (e.g. /srv/bzr/)
[01:17] <bob2> ChrisPitzer: as in ssh in via putty, and run bzr from the command line on the remote machine?
[01:18] <ChrisPitzer> i tried that - bzr isn't installed on the remote machine.
[01:18] <bob2> there's your problem then ;)
[01:18] <ChrisPitzer> haha.
[01:18] <ChrisPitzer> i know
[01:19] <bob2> you can access it remotely with sftp:// urls, have you tried that?
[01:19] <ChrisPitzer> i have bzr installed on *this* machine though... can't I use this bzr instance to create remote repositories...?
[01:19] <ChrisPitzer> just from the command line - no putty...?
[01:19] <bob2> "bzr init-repo sftp://blah/blah"
[01:19] <ChrisPitzer> hu... I'll give it a shot - brb
[01:20] <bob2> I think you need paramiko installed for that
[01:20] <ChrisPitzer> (i still think very "windows" some times)
[01:21] <dagreen> poolie:  after I shared directory and give the appropriate permissions to the group, how do I make it so that directory is the root when they sftp??
[01:23] <bob2> don't think regular openssh has sftp chrooting
[01:23] <dagreen> k, so the only way to make urls look like root is through http then, right
[01:24] <dagreen> ?
[01:36] <poolie> dagreen: just use sftp://host//home/group/repo
[01:37] <dagreen> k.  that should work for me.   didn''t know there was a /home/group
[01:37] <dagreen> thx
[01:39] <ChrisPitzer> so... check my crummy syntax here...
[01:40] <ChrisPitzer>  bzr init<EMAIL_ADDRESS>[01:40] <ChrisPitzer> because, that results in a bunch of happy text with a last line of "bzr: ERROR: No such file: '/src':"
[01:43] <bob2> try //src
[01:45] <ChrisPitzer> same sad ending.  "no such file: '//src' "
[01:45] <bob2> is there a /src on sub.domain.com?
[01:45] <ChrisPitzer> hehe... yes.
[01:46] <ChrisPitzer> where is // ? root?
[01:46] <ChrisPitzer> ooooh... bingo
[01:46] <ChrisPitzer> that's it.  I need to specify full path on the server, not relative.
[01:51] <fullermd> With sftp you can specify relative with a ~<EMAIL_ADDRESS>[01:55] <ChrisPitzer> thanks!
[02:28] <awmcclain> Hey all. So, am I right in figuring out that bzr-email ONLY works from the client-side?
[02:28] <spiv> That's right.
[02:29] <igc> lifeless: was it just me that dropped out?
[02:29] <awmcclain> That is frustrating.
[02:29] <igc> poolie:^
[02:29] <lifeless> igc: yes, credit ran out
[02:36] <radix> awmcclain:  https://bugs.edge.launchpad.net/bzr/+bug/211967
[02:36] <ubotu> Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed]
[02:38] <igc> lifeless: dropped out - I think we're done though, yes?
[02:38] <igc> poolie:^
[02:39] <igc> lifeless: if not, you can call me on my home line now
[02:40] <lifeless> poolie: the knit fetch hotfix has landed in trunk
[02:41] <spiv> awmcclain: we're working on fixing that.  I just updated the bug radix linked to with some details.
[02:41] <radix> woot
[02:41] <awmcclain> yay!
[02:41] <awmcclain> Ok. Not a problem.
[02:42] <radix> oh, so it might already be possible?
[02:42] <radix> great
[02:42] <spiv> radix: yeah
[02:42] <spiv> radix: "might" being the important word, I don't think it's actually been tested yet.  In theory it should be fine...
[02:42] <lifeless> spiv: bzr-email needs to be altered
[02:43] <spiv> lifeless: right.  I didn't mean to give the impression that bzr-email specifically would Just Work, yet.
[02:43] <spiv> Just that it should now be possible to write something that uses the new hook, and have that get triggered on the server.
[02:49] <lifeless> thumper: your patch is merged
[02:50] <thumper> yay
[02:50] <thumper> ta
[03:12] <abentley> lifeless: Updating the MPVersionedFile API is fine with me.  I guess reducing the number of APIs is a win, but it doesn't seem like a big win to me.
[03:13] <lifeless> abentley: i just noted in passing was all
[03:13] <abentley> Oh, I thought you were offering to change it.
[03:14] <lifeless> abentley: yes, if you thought it was a good thing
[03:14] <lifeless> but I also don't have a strong drive to do so
[03:16] <abentley> This loom push thing you want me to review is actually a patch to the loom plugin?
[03:20] <lifeless> yes
[03:21] <lifeless> there are two folk writing loom code
[03:21] <lifeless> and I like peer review
[03:22] <lifeless> I've taken a short cut in fixing push; I'm hoping you'll assess whether the short cut is ok, or say 'its better to leave it broken for a bit and get a more tasteful fix'
[03:24] <abentley> bb:approve I think it's a worthwhile improvement.  I suspect the wrong hook will fire, but I guess that's tolerable for now.
[03:24] <pygi> hey folks
[03:24] <lifeless> thank you
[03:25] <abentley> re BB, I apologize for the downtime.  It messed up this morning, and I wasn't able to get it working again.
[03:25] <lifeless> ouch
[03:25] <abentley> It's like everything I try to improve things makes it worse.
[03:28] <lifeless> is there any assistence you'd like ?
[03:39] <abentley> lifeless: I'd like to see if using pgsql clears up the locking issues.  Do you know a good way to convert the data?
[03:39] <lifeless> I'd probably export vis csv or similar
[03:40] <abentley> Really.  Huh.
[03:40] <lifeless> *via*
[03:40] <abentley> I did try just doing an SQL dump.
[03:40] <abentley> But it seems like pg doesn't recognize some of SQLite's escaping.
[03:41] <lifeless> alternatively you could do a select & insert within python
[03:41] <lifeless> I'm sure there are good toolchains to do this, I've never needed to though
[04:00] <lifeless> got to love the weather
[04:03] <RAOF> lifeless: It's probably different where you are than here.  Nice and sunny? :)
[04:05] <poolfool_> It's dark in Denver Colorado .. but it was a nice day.
[04:05] <poolfool_> To the BZR team, thank you for a great tool.
[04:08] <lifeless> RAOF: loud rain
[04:08] <lifeless> poolfool_: thanks!
[04:10] <poolfool_> lifeless: have you thought about doing a pod cast? FLOSS with leo leport(sp) had somone from the GIT team on in January.
[04:10] <lifeless> that could be interesting
[04:11] <bob2> no swearing.
[04:11] <poolfool_> http://twit.tv/FLOSS
[04:12] <poolfool_> bob2: searing?
[04:12] <poolfool_> s/searing/swearing/
[05:16]  * spiv -> lunch
[05:49] <igc> bbiab - picking kids up from school today
[05:54] <lifeless> http://www.justdave.net/dave/2008/04/06/bugzillamozillaorg-now-in-version-control/
[05:54] <lifeless> ^ cute
[06:48] <lifeless> poolie: ping
[06:49] <poolie> pong, the witch is dead,...
[06:50] <fullermd> Phew.    But that was in another country.  And besides, the wench is dead."
[07:44] <joerg_> Hi. Does anybody know what to do if I get the error message "bzrlib.errors.TokenMismatch: The lock token [...] does not match lock token (remote tokens)" while committing?  (bzr 1.3)
[07:46] <lifeless> jelmer: you had someone break the lock on you
[07:46] <lifeless> meh
[07:46] <lifeless> joerg_: ^
[07:47] <joerg_> any idea lifeless?
[07:47] <lifeless> try again
[07:47] <lifeless> it may be out of date
[07:47] <lifeless> or if its bound it may need to be pushed at this point
[07:49] <joerg_> I'm not sure what "bound" means. Do you suppose to try bzr update and then bzr commit again?
[07:52] <lifeless> yes
[07:53] <joerg_> docu says: "If you have a local branch and wish to make it a checkout, use the bind command like this: bzr bind sftp://centralhost/srv/bzr/X-repo/X-trunk"
[07:53] <joerg_> That is not the case. Its a checkout from a branch laying on the server repo
[07:56] <lifeless> k
[07:56] <lifeless> just do update and commit I think
[07:56] <joerg_> ok I try it. Thank you!
[08:04] <poolie> spiv: steve says you were going to speak to jam about the problem of " attempt to add line-delta in non-delta knit"
[08:04] <poolie> do you know what's up with that?
[08:07] <spiv> poolie: No, I don't know what's up with that.
[08:07] <spiv> poolie: jam thought it might be related to the critical fix we did for 1.3.1rc1
[08:08] <lifeless> bye for the day
[08:08] <spiv> poolie: which sounds plausible but not hugely likely to me. I don't know anything more about it.
[08:09] <spiv> (if anything, I'd expect the fix we did to try insert fulltexts unexpectedly, rather than line-deltas)
[08:11] <poolie> bye lifeless
[08:11] <poolie> it does seem to be in a similar area
[08:12] <poolie> i asked andreas to open a bug about it
[08:12] <fullermd> Is the ghost issue considered serious enough to be a 1.4 blocker?
[08:12] <spiv> Yeah.  I suspect it's related somehow, maybe the same root cause that caused the 1.3 regression?
[08:13] <spiv> I don't think I've seen a traceback for it yet though, so it's hard to speculate.
[08:54] <igc> night all
[10:20] <poolie> good night
[10:55] <awilkins> If you have an SSH key in launchpad you should be able to use bzr_shh to download anything from an LP bzr repo, no?
[10:56] <awilkins> Or is it sftp?
[10:56] <james_w> both should work
[10:57] <awilkins> I'm having trouble, is there a particular form for the username?
[10:57] <james_w> whatever your lp username is
[10:57] <james_w> what's your lp homepage URL?
[10:57] <awilkins> https://launchpad.net/~adrian-wilkins
[10:58] <james_w> and which branch are you trying to fetch?
[10:58] <awilkins> I've tried my email address (with @ escaped and not escaped), adrian-wilkins, all sorts
[10:59] <spiv> awilkins: you should be able to use URLs like<EMAIL_ADDRESS>[11:00] <awilkins> Hmmph, it works with paramiko but not plink
[11:00] <spiv> Ah, I don't know much about the magic to make plink work.
[11:00]  * spiv -> food
[11:00] <ubotu> New bug: #217650 in bzr "Use of authentication.conf causes update to fail" [Undecided,New] https://launchpad.net/bugs/217650
[11:00] <awilkins> That's a regression, it should work with either
[11:01] <awilkins> It used to work with plink AFAIK
[11:01] <awilkins> Installing paramiko on Win32 is a PITA compared to plink as well.
[11:53] <awilkins> That horizon feature would be nice around now :-)
[11:54] <awilkins> What's the practice for submitting merges ; do you submit them all to bzr.dev, or do you submit them to the branch you are making them from?
[11:55] <ubotu> New bug: #217666 in bzr "exceptions.MemoryError when getting http://arch.sv.gnu.org/archives/emacs/bzr/emacs.app" [Undecided,New] https://launchpad.net/bugs/217666
[11:56] <james_w> awilkins: bzr.dev, unless you are making a change to something not yet merged, or fixing something on a release branch
[11:57] <awilkins> james_w: It's jsut a little patch to a couple of the hidden commands to make them more consistent with bzr unknowns
[11:58] <james_w> bzr.dev sounds right then.
[11:58] <awilkins> Is there a mail I can bzr send to? Or do I put up a bug with a merge bundle in it?
[11:58] <awilkins> (PQM is a bit much right now)
[11:59] <james_w> bzr send --mail-to<EMAIL_ADDRESS>[11:59] <awilkins> Groovy.
[13:25] <ubotu> New bug: #217701 in bzr "attempt to add line-delta in non-delta knit" [Undecided,New] https://launchpad.net/bugs/217701
[14:55] <ubotu> New bug: #217737 in bzr "bzr merge gives error over Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x01697050>"" [Undecided,New] https://launchpad.net/bugs/217737
[17:40] <dwt> Morning
[17:40] <dwt> I'm trying to use bzr with svn and have problems pushing to svn
[17:41] <dwt> it fails with error "('Mindestens eine Eigenschafts"anderung ist fehlgeschlagen; Projektarchiv nicht ge"andert', 175008)" wich roughly translates to "at least one property couldn't be changed"
[17:44] <dwt> Well, I'm quite puzzled what it means by that and am currently trying to convince it to give me a propper english response so I can search for it.
[17:46] <andrea-bs> dwt: type `LANG=en_US.UTF-8` in a shell and try to push
[17:47] <dwt> thanks andrea-bs - I'm trying it right now
[17:50] <Bronger> How can I force a synchronisation between an SVN repo and a local Bazaar branch?  Bazaar claims that both a diverged (which is technically correct), however, de-facto both branches contain exactly the same files.  I could merge, but then I get tons of conflicts.
[17:52] <dwt> Well, now it's much more talkative. I actually get a traceback and tells me that 5 should file a bug.
[17:52] <dwt> well....
[17:52] <dwt> The error is: SubversionException: ('At least one property change failed; repository is unchanged', 175008)
[17:52] <dwt> I'm gonna google for that
[17:52] <dwt> but if anybody of you can give me a hint how to debug this further, I'd love to hear it. :)
[17:53] <andrea-bs> dwt: this sounds like a bug, could you please past the entire traceback on <http://paste.ubuntu.com>?
[17:54] <dwt> sure
[17:54] <dwt> http://paste.ubuntu.com/7133/
[17:57] <dwt> It could be a bit more verbose about what property exactly it couldn't change....
[17:57] <andrea-bs> dwt: it seems a repo problem rather than a bzr problem
[17:58] <dwt> ok.....
[17:58] <dwt> I'l test that with svn
[17:58] <dwt> and see what I get
[18:01] <andrea-bs> I have to go now, bye!
[18:02] <dwt> thansk anyway andrea-bs
[18:02] <dwt> Well, subversion works perfectly
[18:02] <dwt> and I can also pull changes I got from subversion
[18:02] <dwt> and merge them and everything
[18:03] <dwt> though no push
[18:15] <newz2000> jam: can you remind me how your push and update plugin works again?
[18:16] <newz2000> never mind, I realized it runs automatically
[18:16] <newz2000> :-)
[18:16] <jam> newz2000: if you have it installed (the newest version) when you do 'bzr push' it should check if it is an ssh connection, and then run 'ssh host; bzr update' fo ryou
[18:16] <jam> for you
[18:16] <jam> newz2000: right, an earlier version required you to run 'bzr push-and-update' instead of 'bzr push'
[18:17] <jam> the newest version just installs a post-push hook to do it automatically
[18:17] <newz2000> nice plugin. Just what I need. :-)
[19:19] <Stavros> can someone help me use bzr-svn? i can't figure it out :/
[19:19] <Stavros> i do bzr branch svn://whatever and i get bzr: ERROR: Permission denied: ".": Can't get password
[19:21] <jelmer> Stavros: hi
[19:21] <jelmer> Stavros: See the FAQ
[19:23] <Stavros> i did, hmm
[19:23] <Stavros> it needed an svn info, svn up didn't cache the password
[19:23] <Stavros> but now it fails with permission denied
[19:24] <Stavros> :/
[19:24] <jelmer> did you run "svn info" on the root url of the repository?
[19:24] <jelmer> What OS are you on?
[19:24] <Stavros> windows
[19:24] <Stavros> i didn't, sec :/
[19:24] <Stavros> apparently i don't have permission to do that
[19:24] <jelmer> Stavros: Ah, it's broken on Windows atm unless you have Subversion 1.5 I think
[19:25] <Stavros> i installed the patched binding
[19:25] <Stavros> s
[19:25] <Stavros> i can't stand svn, it bogs down my entire system to do a simple diff
[19:25] <Stavros> bah, i guess i'll have to live with it...
[19:25] <jelmer> Stavros: the patched bindings don't contain the required fix for this
[19:25] <Stavros> is it safe to push with bzr-svn?
[19:25] <Stavros> ah
[19:25] <jelmer> yes
[19:25] <Stavros> i ah, good
[19:26] <Stavros> i don't want to much the repo up if it works eventually
[19:47] <abadger1999> Hey, how would I get the reverse of "bzr diff"?
[19:48] <dato> abadger1999: between two revisions?
[19:48] <abadger1999> ie: the diff of working tree -> latest commit.
[19:48] <dato> ah
[19:48] <abadger1999> I released a package out of a modified working tree instead of a fresh checkout.
[19:49] <dato> personally I'd do
[19:49] <dato> b commit -m foo
[19:49] <dato> b diff -r -1..-2
[19:49] <dato> b uncommit
[19:49] <andrea-bs> abadger1999: try with "bzr merge file.diff"
[19:49] <abadger1999> dato: Thanks!  That'll work for me.
[19:49] <abadger1999> andrea-bs: k.  I'll try that first
[19:51] <andrea-bs> abadger1999: it works with patches generated by "bzr send" and I'm not sure if this will work also with diff output
[19:51] <abadger1999> andrea-bs: bzr merge just tells me "Nothing to do."
[19:53] <andrea-bs> abadger1999: patch originalfile patchfile
[19:54] <foom> hey, so, is a "bzr obliterate" feature on the plan anywhere? I just had to remove some data from svn that was committed a year ago. It wasn't trivial, but it was possible, without screwing up every developer's checkout everywhere. It seems like with all the fancy DVCSes, that's simply impossible. (which is a problem)
[21:06] <Noia> >.>
[21:06] <Noia> whats the difference between bzr and svn
[21:06] <Noia> lol
[21:11] <asabil> Noia: to keep it short: bzr is better :p
[21:53] <lifeless> hi jam
[21:53] <jam> lifeless: hi
[21:53] <jam> lifeless: have you done anything with instrumenting packs?
[21:53] <jam> I've been thinking about doing a little bit of hit/miss stuff
[21:54] <jam> and then my ISP decided it required authenticated sends, and I had to spend way too much time getting Postfix to properly talk to them.
[21:55] <lifeless> jam: exim4 ftw :P
[21:55] <jam> well, my server is currently a really old FC4 install
[21:56] <lifeless> jam: no, as I said in my mail I don't have the time to do anything about it right now
[21:56] <lifeless> but I wanted to share the underpinnings that seemed to be missing when folk were trying to analyse it. lsprof is good, but it can't tell right from wrong.
[21:56] <jam> (the problem was that FC4 versus Breezy, and Breezy didn't recognize my SATA hard-drive card automatically)
[21:57] <jam> lifeless: well you could pretty easily, if you broke up the cache hit into a separate function
[21:57] <jam> I've certainly done stuff like create an inner function for loops so I can see how much time is spent in each
[21:57] <jam> def run_loop_x():
[21:57] <jam>   for foo in bar:
[21:57] <jam>   pass
[21:57] <jam> run_loop_x()
[21:58] <lifeless> jam: that doesn't tell right from wrong
[21:58] <jam> lifeless: that is to profile the time spent in that loop (as an example)
[21:58] <lifeless> yes, but I never said lsprof can't do that
[21:58] <jam> You could try something similar for cases where there is a hit versus a miss
[21:58] <jam> call a different func
[21:59] <jam> but I'm not sure where the time is actually spent
[21:59] <jam> anyway, I understand your point
[21:59] <jam> it is still hard to *time* a miss versus a hit
[21:59] <jam> counting isn't hard
[22:00] <lifeless> its also hard to decide if the amount of time per unit is as expected, or the number of units is as expected
[22:00] <lifeless> that requires a model for the operation
[22:01] <lifeless> e.g. for working tree operations we all share the model of '1 stat per file, and 1 read per file if needed'
[22:01] <jam> lifeless: by the way, I think our pack => knit fetcher causes weird problems with revision_id references
[22:01] <jam> specifically, I think I see it generating revisions out of order
[22:01] <jam> (newest first, rather than topologically sorted)
[22:01] <jam> I can say that my knit repository (which I push to from packs) has all sorts of crazy stuff going on
[22:01] <jam> still technically "correct" but just improperly orderd
[22:02] <lifeless> interesting
[22:02] <jam> The problem is that I'm generally seeing all of this as artifacts in revisions.kndx, without actually reproducing it
[22:08] <jam> lifeless:  can I have you take a peek at a line of code
[22:08] <jam> Specifically line 662 of bzrlib/index.py
[22:08] <jam> It seems to be mixing indices
[22:08] <jam>             index = self._parsed_byte_index(location)
[22:08] <jam>             # if the key is below the start of the range, its below
[22:08] <jam>             if key < self._parsed_key_map[index][0]:
[22:09] <jam> lifeless: if I'm actually reading a bug, then it would indicate we are not properly "bisecting"
[22:10] <jam> or does _parsed_key_map[index] always match up to _parsed_byte_index
[22:11] <lifeless> in the __init__
[22:12] <lifeless>         # a sorted list of slice-addresses for the parsed bytes of the file.
[22:12] <lifeless>         # e.g. (0,1) would mean that byte 0 is parsed.
[22:12] <lifeless>         self._parsed_byte_map = []
[22:12] <lifeless>         # a sorted list of keys matching each slice address for parsed bytes
[22:12] <lifeless>         # e.g. (None, 'foo@bar') would mean that the first byte contained no
[22:12] <lifeless>         # key, and the end byte of the slice is the of the data for 'foo@bar'
[22:12] <lifeless>         self._parsed_key_map = []
[22:12] <lifeless> (they use the same values to lookup
[22:12] <lifeless> its not a single map to a tuple because of bisect needs
[22:12] <lifeless> oh, where is my cleanup of this code
[22:13] <lifeless> I have a branch that introduces an abstraction here
[22:13] <lifeless> pushing it now
[22:15] <ubotu> New bug: #217917 in bzr ""bzr commit" MemoryError crash" [Undecided,New] https://launchpad.net/bugs/217917
[22:24] <lifeless> jam: whats an operation thats still problematic ?
[22:50] <goozbach> Quick question: I couldn't find an answer in the bzr user guide.
[22:51] <goozbach> I want a "pushed" branch to always have the current contents
[22:52] <goozbach> eg, I run bzr push from my laptop, and want the pushed location (a web accessable directory on a server) to automatically update
[22:52] <jam> lifeless: well 'bzr status' after a pending merge, but that is bad for other reasons :)
[22:52] <mwhudson> goozbach: the push-and-update plugin can do that
[22:52] <goozbach> is this possible without creating a hook
[22:52] <jam> a simple 'bzr log' on a very long history is bad
[22:52]  * goozbach googles
[22:53] <goozbach> mwhudson: thanks
[22:53] <jam> lifeless: 'time bzr log --short -r -10..-1 bzr.dev' is quite a bit longer than it should be
[22:53] <jam> goozbach: cd ~/.bazaar/plugins;  bzr branch lp:bzr-push-and-update push_and_update
[22:53] <jam> (possibly with a mkdir -p ~/.bazaar/plugins first)
[22:54] <goozbach> jam: just got it
[22:54] <goozbach> thanks though
[22:54] <jam> goozbach: it will update if it detects that the remote location has a working tree, and you are connecting over sftp or bzr+ssh
[22:54] <jam> it won't do it if you are using ftp etc
[22:54] <goozbach> yay!
[22:54] <lifeless> jam: 2.5 seconds for me
[22:55] <goozbach> hooray for not re-inventing the wheel
[22:55] <goozbach> thanks guys
[22:55] <jam> lifeless: yeah, but it used to be <1s
[22:55] <lifeless> k
[22:55] <goozbach> I knew I wasn't the only one who wanted that to happen
[22:55] <jam> goozbach: it does require that you have bzr installed on the remote machine, and have regular 'ssh' access
[22:55] <jam> in case that matters
[22:56] <jam> (it basically just calls 'ssh host bzr update' for you)
[22:56] <jam> lifeless: 'bzr log --long -r -10..-1' would also be even worse, I just never use it
[22:57] <jam> --long is going to do a whole revision-graph search because of dotted revnos
[22:57] <goozbach> jam: it's working.
[22:57] <goozbach> I was mostly wondering if someone else had done the legwork
[22:58] <goozbach> yay!
[22:59] <jam> goozbach: yep, I'm glad it works for you, feel free to post bugs, etc.
[22:59] <jam> it is pretty simple, though, so I don't expect you would have problems.
[23:00] <jam> I suppose I should now trap into the 'branch_changed_revision' hook in 1.4, so that it will also work if you have a checkout of the public location, rather than only on push
[23:50] <spiv> Good morning.
[23:54] <jam> morning spiv
[23:55] <igc> morning
[23:55] <igc> morning jam, spiv


[04:49] <slangasek> tsimonq2: it'll probably be "today", but we don't exactly have a hard committment to anyone regarding the clean-up of cdimage etc.
[04:53] <tsimonq2> slangasek: OK, understood.
[04:54] <tsimonq2> slangasek: And by "today", are you still in a US timezone or are you in Europe somewhere? ;)
[04:54] <slangasek> neither
[04:54] <slangasek> Cape Town sprint
[04:54] <valorie> oooo
[04:54] <tsimonq2> Oooooh nice
[04:55] <valorie> have always wanted to spend some time in south africa
[04:55] <tsimonq2> ^
[09:15] <Laney> tsimonq2: if you test it and file a bug (use requestbackport), then ping me the number I can upload it
[09:16] <tsimonq2> Laney: ack, will do, thanks
[09:32]  * tsimonq2 lolwats @
[09:32] <tsimonq2> Err:4 http://ppa.launchpad.net/tsimonq2/backports/ubuntu artful InRelease
[09:32] <tsimonq2>   403  Forbidden
[09:33] <tsimonq2> aha, weird
[09:36] <cjwatson> Possibly a proxy problem or something.  It's fine on ppa.l.n
[09:36] <tsimonq2> Right, and it was only temporary. Weird.
[09:37] <tsimonq2> Laney: Boom: https://bugs.launchpad.net/artful-backports/+bug/1743334
[12:43] -queuebot:#ubuntu-release- Unapproved: accepted parted [source] (artful-proposed) [3.2-18ubuntu0.1]
[12:45] -queuebot:#ubuntu-release- Unapproved: accepted parted [source] (xenial-proposed) [3.2-15ubuntu0.1]
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (artful-proposed) [1:17.10.12]
[16:24] -queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (artful-proposed) [0.9.7-2ubuntu1]
[16:27] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (artful-proposed) [0.9.7-2ubuntu1]
[17:01] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (artful-proposed) [1.8.4-1ubuntu3.1]
[17:26] -queuebot:#ubuntu-release- New binary: pgq-node [amd64] (bionic-proposed/none) [3.2.5-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: r-cran-devtools [amd64] (bionic-proposed/none) [1.13.4-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: r-cran-devtools [i386] (bionic-proposed/none) [1.13.4-1] (no packageset)
[17:30] -queuebot:#ubuntu-release- New binary: r-cran-psych [amd64] (bionic-proposed/none) [1.7.8-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: r-cran-rhandsontable [amd64] (bionic-proposed/none) [0.3.4+dfsg-1] (no packageset)
[20:25] <tsimonq2> Laney: If a package that I want to go into Backports needs debhelper 10, do I have to backport debhelper, or can I just make the appropriate packaging changes?
[20:51] <rbasak> AIUI, it's fine to adjust things not to need debhelper 10
[20:51] <rbasak> Looks like it's only needed for Trusty?
[20:52] <valorie> Laney: tsimonq2 - thanks for working on that!
[20:55] -queuebot:#ubuntu-release- Unapproved: shim-signed (artful-proposed/main) [1.32 => 1.33.1~17.10.1] (core) (sync)
[20:56] -queuebot:#ubuntu-release- Unapproved: shim (artful-proposed/main) [0.9+1474479173.6c180c6-1ubuntu1 => 13-0ubuntu2] (core) (sync)
[20:58] <tsimonq2> rbasak: Right.
[20:58] <tsimonq2> rbasak: (I think that might be the only thing but haven't heavily checked quite yet.)
[22:23] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (artful-proposed/main) [1:17.10.8 => 1:17.10.9] (core)
[22:24] <Laney> Right
[23:10] -queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2 => 10-2] (core)
[23:10] -queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-2 => 10-2] (core)