[00:03] <jml> jam: if there's better practice for wrapping a bzr command in a plugin I'd love to read about it.
[00:05] <Ng> how easy/sane is it to call bzr's api directly from a python app if you just care about really simple add/commit stuff?
[00:06] <beuno> Ng, pretty easy
[00:07] <beuno> Ng, http://bazaar-vcs.org/Integrating_with_Bazaar
[00:07] <LarstiQ> Ng: bzrlib is supposed to be usable that way
[00:08] <Ng> nice :)
[00:08]  * beuno waves at LarstiQ
[00:08] <LarstiQ> hey beuno :)
[00:50] <jml> hey, the new progress bar in the bzr in today's ppa is pretty nice.
[00:57] <LarstiQ> jml: yup!
[00:58] <LarstiQ> jml: it not cleaning up properly is a bit suboptimal, but even then I rather like it.
[00:58] <jml> yeah.
[00:58] <jml> it actually does make bzr feel faster. :)
[00:59] <jml> although, who knows, maybe there were performance improvements in the update as well :)
[01:00] <LarstiQ> nafaik, I think you're right about it subjectively feeling faster
[01:04] <jam> jml: well, you could have used "*args, **kwargs" and then pulled out only the ones you actually cared about
[01:05] <jml> jam: yeah.
[01:05] <jml> jam: I just cargo culted from the way loom handled "switch", which was probably not the wisest thing
[01:05] <enigma> Quick question: Is there any plan to add  "--format" to bzr branch?
[01:05] <enigma> So I could do: bzr branch --format=1.9 sftp://....
[01:06] <enigma> I've noticed that I'm doing a "branch" and then "upgrade" a lot.
[01:07] <enigma> Since we've been keeping our bzr server using the rich-root-pack format.
[01:07] <enigma> And I like having 1.9-rich-root on my workstation.
[01:07] <jml> enigma: I don't know of any.
[01:07] <Ng> hmm, what about for initialising a repo from a python app - is there a better way than bzrlib::builtins::cmd_init?
[01:08] <LarstiQ> enigma: I only know of bzr init; bzr pull to accomplish that
[01:08] <LarstiQ> enigma: interesting idea though
[01:08] <jml> enigma: but it sounds like a good idea. if you start filing a bug at http://bugs.edge.launchpad.net/bzr/+filebug, Launchpad might show you a bug that's already filed.
[01:08] <jml> Ng: umm...
[01:09] <jml> Ng: I think I've written public code that does this somewhere.
[01:09] <enigma> Oh...I guess I didn't think about using a repo....thanks for the tip.
[01:10] <jml> Ng: https://code.edge.launchpad.net/~jml/+junk/bzr-establish -- it probably either calls cmd_init or copies from it.
[01:10] <enigma> So, I would do "bzr init-repo --1.9-rich-root" and then any branches I pull into that repo would automatically use 1.9-rich-root?
[01:11] <fullermd> They would automatically use that repo format, yes.
[01:11] <fullermd> I think they'd default to the upstream branch format, though.
[01:11] <Ng> jml: thanks :)
[01:11] <fullermd> So you'd probably get to sift through a bunch of 'unnamed'.
[01:12] <LarstiQ> Ng: I'd probably use bzrdir.create_repository(shared=True)
[01:12] <LarstiQ> Ng: like cmd_init_repo does as well
[01:13] <jml> I wish looms had better toolchain support
[01:13] <enigma> fullermd: "unnamed"?
[01:13] <enigma> fullermd: I didn't realize I could run a different branch format than the repo format.
[01:14] <fullermd> Well, you'd have to, since the repo format can't store a branch   :)
[01:14] <enigma> What does the repo store? Just revisions?
[01:14] <fullermd> 1.6 introduced a new branch format; I think --1.9-* uses that, instead of branch6.
[01:15] <fullermd> Yah.
[01:15] <enigma> OK.
[01:15] <enigma> fullermd: Thanks for the help.
[01:15] <fullermd> There are 3.5 formats involved; the repo, the branch, and the WT, plus a half in the container format.  They can be largely varied independently.
[01:15] <fullermd> The various names like --1.9-rich-root etc are aliases for {repo X, branch Y, WT Z}
[01:16] <enigma> Oh...if I'm running the 1.9 branch format on an client and I push back to a 1.0 branch format, is that going to cause problems?
[01:16] <fullermd> I don't think so.
[01:16] <fullermd> Generally branch formats don't introduce hitches like that; it's mostly repo formats.
[01:16] <fullermd> (like the rich-root vs. poor-root hump)
[01:17] <fullermd> Between branch5 and branch6 there were some, since branch6 supports tags and b5 didn't.  But the push would still work; it just wouldn't copy any tags.
[01:17] <enigma> fullermd: OK.
[01:17] <enigma> fullermd: What's the "WT"?
[01:17] <fullermd> I don't _think_ the 1.6 branch format made any changes that will hiccup like that.  But I don't really know; I haven't looked much at it.
[01:17] <fullermd> Working tree.
[01:17] <enigma> Oh, OK.
[01:56] <jml> are there already Python libs for parsing diffs?
[04:44] <pygi> hi folks
[10:35] <dwt> Hey guys, I'm looking for the current data of the performance testing history in bzr
[10:35] <dwt> http://bazaar-vcs.org/PerformanceHistory
[10:35]  * dwt indicates that I might find it at
[10:35] <dwt> http://codespeak.net/bzr/perf_history/summary_bzr.dev.html
[10:35] <dwt> but unfortunately thats not the case. :/
[10:35] <dwt> anymore
[10:35] <dwt> could somebody please advise?
[15:32] <maxb> Why doesn't "bzr branch" remember the source as a saved push location, and can I make it do that?
[15:34] <LarstiQ> maxb: you can bzr push :parent
[15:34] <maxb> aha
[15:34] <maxb> thanks
[15:34] <LarstiQ> maxb: after that, it will remember the push location
[15:35] <LarstiQ> maxb: on why it doesn't do that, in the model of standalone branches, theoretically it is very unlikely you will push to the same place you branch from
[15:35] <LarstiQ> in practice, I don't know if that is a good decision, although frequently it is true for me
[16:02] <rocky> jelmer: hey, i don't suppose you come up with any sort of work around for that bzr corruption bug that was reported a little while ago? (bzr-svn)
[16:03] <jelmer> rocky, no sorry, I haven't had time to look at that yet
[16:03] <rocky> maxb: any time you want bzr to remember a push/pull/merge location just remember to use --remember when you do it
[16:04] <rocky> i can imagine time is limited :)
[16:04] <jelmer> rocky, working on other bzr-svn bugs atm
[16:04] <rocky> as it is for all of us
[16:05] <rocky> i've been working on ClueReleaseManager (pypi server) lately ... to go along with ClueBzrServer (bzr-over-http) and ClueMapper (trac project admin tool)
[16:05] <rocky> which reminds me...
[16:05] <rocky> jelmer: has trac-bzr got any love lately?
[16:06] <jelmer> rocky, not much news, Alexander was working on a minor bug fix
[16:07] <rocky> jelmer: what's the last known versions of trac and bzr it works with?
[16:11] <Jc2k> jelmer: the dulwich thing we were talking about; didnt need an api change but there was a buglet that i fixed.
[18:23] <rysiek|pl> hi all
[18:24] <rysiek|pl> guys, does anyone of you use bzr through sftp?
[18:24] <rysiek|pl> a branch that a few devs use?
[18:25] <rysiek|pl> I ave run into some problems with permissions. specifically, the whole branch is owned by root:bzr and all the devs are in the bzr group
[18:26] <rysiek|pl> but if a dev creates a new file, it gets owned by devuser:bzr and the perms are set so that the group hasn't got write access to it
[18:26] <rysiek|pl> which causes obvious problems here ;)
[18:26] <rysiek|pl> so my question is: how do you overcome such problems? bzr --serve? some nifty sticky perms with proper umasks for all the devs?
[18:26] <rysiek|pl> any hints?
[18:37] <kumi> I use umasks and setgid on my branch
[18:37] <rysiek|pl> kumi: I found this helpful bugger: https://lists.ubuntu.com/archives/bazaar/2008q1/038455.html
[18:37] <rysiek|pl> kumi: are you using sftp or bzr+ssh?
[18:38] <kumi> Oh I see, you're using sftp. We use bzr+ssh
[18:39] <rysiek|pl> right, that makes it clear
[18:39] <rysiek|pl> thanks
[18:39] <rysiek|pl> I'll switch to bzr+ssh
[18:42] <kumi> Are you on linux? you might be able to continue using sftp if you use ACL
[18:42] <rysiek|pl> yeah, on linux
[18:42] <rysiek|pl> ACL? ACL for what?
[18:42] <kumi> setfacl/getfacl
[18:42] <rysiek|pl> ah, rigt
[18:42] <rysiek|pl> I'll investigate into that, thanks
[18:42] <LarstiQ> rysiek|pl: openssh had a problem with not respecting setgid bits in sftp, that got fixed in http://www.openssh.com/txt/release-5.1
[18:43] <LarstiQ> rysiek|pl: in the meantime, I do like kumi and use acls
[18:43] <rysiek|pl> LarstiQ: thanks
[18:45] <rysiek|pl> LarstiQ: don't acls work only on XFS?
[18:47] <LarstiQ> rysiek|pl: I use them on ext3, I'm sure they work on reiser too.
[18:47] <rysiek|pl> right, thanks
[18:47] <LarstiQ> and probably ext4 and btrfs
[18:47] <kumi> I think you have to mount the fs with the acl option though
[18:48] <rysiek|pl> ok
[19:51] <mxpxpod> does bzr-svn support making svn tags?
[19:59] <jelmer> mxpxpod: yes
[19:59] <mxpxpod> jelmer: just use bzr tag, right?
[20:00] <jelmer> mxpxpod: yep
[20:00] <mxpxpod> jelmer: thanks
[20:01] <mxpxpod> jelmer: how does it know where to store the svn copy it makes?
[20:02] <jelmer> mxpxpod: if you have a standard svn layout (trunk, branches, tags), it will create a new directory in tags/
[20:02] <mxpxpod> jelmer: even if I've just pulled directly from trunk, right?
[20:03] <jelmer> mxpxpod: yes
[20:03]  * jelmer back in ~15 minutes
[20:03] <mxpxpod> jelmer: thanks a ton, that's great
[20:12] <luks> jelmer: if I do a nasty thing like svn mv foo/trunk foo/branches/old-trunk; svn mv foo/branches/new-trunk foo/trunk, how much will it break bzr-svn?
[20:14] <jelmer> luks: depends on what you mean by how much
[20:14] <jelmer> luks: bzr-svn will most likely give you a divergedbranches error (unless new-trunk is a direct ancestor of old-trunk)
[20:15] <luks> jelmer: I mean if do a clean branch from foo/trunk, will it stop on the move, follow the move, follow the move but using a giant delete + add?
[20:16] <jelmer> luks: it will follow the move
[20:16] <luks> great!
[20:16] <luks> thanks
[20:16] <jelmer> luks: no delete + add involved
[20:16] <luks> I wasn't sure if it works cross-branch as well
[20:17] <jelmer> it only works if the old location is recognized as a branch location
[21:03] <rysiek|pl> hmmm
[21:03] <rysiek|pl> I jost got a crazy idea
[21:03] <rysiek|pl> would it be possible to version a single dir
[21:03] <rysiek|pl> within two branches?
[21:03] <rysiek|pl> using mount --bind?
[21:04]  * rysiek|pl 's gotta test it, although it probably will fail spectacularly
[21:16] <chaynesin> Need help setting up server repo with trees
[21:20] <davidstrauss> chaynesin: ok
[21:22] <davidstrauss> chaynesin: what's the problem you're trying to solve that the docs don't clearly address?
[21:24] <davidstrauss> chaynesin: (re: PMed question) "no trees" = "no working copy"
[21:25] <davidstrauss> chaynesin: oh wait, *without* using no tree
[21:25] <davidstrauss> hmm
[21:26] <davidstrauss> chaynesin: by default, pushing and committing to the server tree will not update the server's working copy
[21:26] <davidstrauss> chaynesin: regardless of whether the server has tree or no tree set
[21:28] <chaynesin> is there any way to maintain a server repos with working files that updates automatically with push or commit or anything else that can be done via ftp?
[21:28] <davidstrauss> chaynesin: yes, with a bzr plugin
[21:29] <chaynesin> so bzr has to be installed with that plugin on the server? what's the pluging?
[21:29] <davidstrauss> chaynesin: https://launchpad.net/bzr-push-and-update/
[21:29] <davidstrauss> chaynesin: not sure how well it will work with sftp, though
[21:30] <davidstrauss> chaynesin: ssh is generally a better solution for server repo access
[21:30] <rysiek|pl> I have a python script that runs in a screen session, watching certain changes with inotify
[21:30] <rysiek|pl> and running a bash script that updates the tree
[21:30] <davidstrauss> rysiek|pl: why don't you just run the plugin i linked to?
[21:31] <rysiek|pl> davidstrauss: I didn't know of that plugin when I needed that
[21:31] <rysiek|pl> davidstrauss: besides, this plugin (as a bzr plugin) will *not* work with ftp/sftp
[21:31] <chaynesin> so the plugin is clientside but requires ssh access. i think that will work for me.
[21:31] <davidstrauss> rysiek|pl: neither will your approach work with ftp/sftp
[21:32] <beuno> chaynesin, or bzr-upload
[21:32] <rysiek|pl> davidstrauss: oh, but it does :)
[21:32] <beuno> which will work with ftp
[21:32] <Peng_> The bzr-push-and-update plugin simply makes bzr automatically run "ssh foo@bar bzr update /path/to/branch" after pushing, so you need bzr installed remotely.
[21:32] <beuno> but it won't keep a repository on the remote side
[21:32] <beuno> just the working tree
[21:33] <rysiek|pl> davidstrauss: it just sits in a screen session monitoring the .bzr directory for changes that occur upon commits, pushes, merges, etc, and runs the bash script
[21:33] <rysiek|pl> anywhoo, just my $.02
[21:33] <amanica_> is it ok for me to send a merge-directive to the list without a bundle (just a public branch location)?
[21:33] <beuno> amanica_, yeap
[21:33] <davidstrauss> amanica_: should be fine
[21:33] <amanica_> thanx
[21:33] <beuno> amanica_, but sending in the actual patch makes it a lot easier to review
[21:33] <amanica_> the bundle is 1.1MB
[21:33] <chaynesin> is bzr-upload another pluggin  that runs on the client?
[21:34] <beuno> chaynesin, yes
[21:34] <Peng_> Heheh. I think someone sent a bundle that large a while ago; I don't remember what the reaction was.
[21:34] <beuno> amanica_, I've sent bigger ones
[21:34] <Peng_> amanica_: Just out of curiosity, what's your patch about? How'd it get that large? :D
[21:34] <rysiek|pl> chaynesin: from what I understand, there is no way to have a "server-side" bzr plugins, unless you are using bzr --serve and bzr://
[21:34] <beuno> SVGs and PNGs  :)
[21:34] <amanica_> :) last time I did that it got stuch so I had to zip it
[21:35] <davidstrauss> rysiek|pl: bzr+ssh uses server-side bzr binaries and plugsin
[21:35] <rysiek|pl> davidstrauss: yeah, sorry for the omittance
[21:36] <chaynesin> how do bzr-upload and bzr-push-and-update different, just in the command they ask via ssh the server bzr to run?
[21:37] <davidstrauss> chaynesin: bzr-upload is not designed to work in tandem with a server-side repository+tree
[21:37] <beuno> right, it just uploads the working tree
[21:37] <davidstrauss> bzr-upload is designed to publish the working tree
[21:37] <beuno> and keeps a reference of what you uploaded last
[21:37] <beuno> so iy just uploads the changed files
[21:37] <beuno> s/iy/it
[21:37] <beuno> it's mostly targeted at web development
[21:38] <chaynesin> looks like bzr-push-and-update is what I want, so I have to install bzr on the server, but can that be done w/o root?
[21:39] <davidstrauss> chaynesin: yes, but you'll have to make sure the bzr binary is in PATH or manually specified in the client commands
[21:43] <chaynesin> thanks a lot, i guess that's it for now.
[21:44] <amanica_> :( without the bundle it it still 994K  so I'm considering it with --no-patch as well. (I'll attach useful diffs for reviewing)
[21:46] <amanica_> Peng_ sorry I only saw your question now. it removes all the trailing white space from the code (about 3000 lines)
[21:46] <amanica_> (and yes, martin requested it)
[21:46] <amanica_> (aka poolie)
[21:48] <amanica_> beuno: do you think I can send it with --no-bundle and --no-patch ?  or do you think I should just send the big file?
[21:49] <Peng_> amanica_: Ah, that. Cool. :)
[21:51] <sjokkis> hi i've fucked up and commited an empty revision. how do i check out a previous one?
[21:52] <amanica_> beuno: it compresses to 285K, so maybe I can attach that also...
[21:53] <amanica_> sjokkis do you want to uncommit it?
[21:58] <sjokkis> i guess so
[21:58] <sjokkis> oh right, that's a command
[21:58] <sjokkis> gotcha
[22:13] <sohail> hi
[22:13] <sohail> is there an equivalent of svn cp?
[22:14] <Peng_> sohail: No
[22:15] <sohail> Peng_, then how do I record that I copied a file
[22:18] <Peng_> sohail: You can't.
[22:19] <Peng_> sohail: Bzr's nifty rename support comes at the price of making copies more difficult, and nobody's done the work yet.
[22:21] <sohail> Peng_, so I use double the space...
[22:22] <Peng_> sohail: I guess so.
[22:30] <sohail> Peng_, in a way I guess it is good... It made me do some overdue refactoring :-)
[22:31] <jelmer> Peng_: I don't think the rename support makes copies more difficult
[22:32] <jelmer> Peng_: it's just that the developers seem to not want to implement copy support that works worse (in terms of merge) than rename support
[23:34] <Jc2k> jelmer: around?
[23:35] <Jc2k> jelmer: im adding SSH support to dulwich (should be easy..) but i really should change the API here..
[23:59] <davidstrauss> How can I get my blog added to Bazaar Planet?
[23:59] <davidstrauss> I mean Planet Bazaar.


[00:01] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (disco-proposed/main) [18 => 19.2] (core)
[00:13] <powersj> vorlon, if you are around can you poke ^
[00:13] <vorlon> sure
[00:13] <powersj> thank you
[00:37] -queuebot:#ubuntu-release- Unapproved: calamares (disco-proposed/universe) [3.2.4-0ubuntu1 => 3.2.4-0ubuntu2] (lubuntu)
[00:39] <tsimonq2> software-properties, lubuntu-default-settings, calamares, and calamares-settings-ubuntu should be the last non-RC Lubuntu updates this cycle. It would be appreciated if these could be processed prior to final freeze.
[00:40] -queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (disco-proposed/universe) [1:19.04.3 => 1:19.04.4] (lubuntu)
[00:41] <tsimonq2> (Well, RC-critical in the Final Freeze sense. I still think all are important to get in this cycle.)
[00:55] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (disco-proposed) [19.2]
[04:33] -queuebot:#ubuntu-release- Unapproved: cups-filters (disco-proposed/main) [1.22.4-1 => 1.22.5-1] (desktop-core, ubuntu-server) (sync)
[05:15] -queuebot:#ubuntu-release- Unapproved: lxml (disco-proposed/main) [4.3.2-1 => 4.3.3-1] (ubuntu-desktop, ubuntu-server) (sync)
[05:16] -queuebot:#ubuntu-release- Unapproved: libabigail (disco-proposed/universe) [1.5-1 => 1.6-1] (no packageset) (sync)
[05:17] -queuebot:#ubuntu-release- Unapproved: accepted libabigail [sync] (disco-proposed) [1.6-1]
[06:35] -queuebot:#ubuntu-release- Unapproved: libosinfo (disco-proposed/universe) [1.4.0-0ubuntu1 => 1.4.0-0ubuntu2] (desktop-extra, ubuntugnome)
[07:22] <acheronuk> Kubuntu livefs fails to build today
[07:23] <acheronuk> W: Failure while configuring base packages.  This will be re-attempted up to five times.
[07:23] <acheronuk> W: See /build/chroot/debootstrap/debootstrap.log for details (possibly the package python3-nacl is at fault)
[07:29] <acheronuk> and, yes. a local debootstrap of disco fails this morning on the same error :/
[07:34] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1030.32] (kernel)
[07:43] <infinity> acheronuk: That would be ubuntu-advantage-tools growing a bunch of new deps. :/
[07:44] <acheronuk> infinity: yeah, I just found that via python3-pymacaroons
[07:44] <acheronuk> and looking what migrated in the small hours
[07:44] <infinity> vorlon: What happened to the "ubuntu-advantage-tools can be in minimal, as long as it doesn't pull more things into minimal" plan?  Was this change a week before release okayed?
[07:45] <infinity> ahasenack: ^
[07:47] <infinity> Ahh, and found the FFe bug.
[07:47] <infinity> Gross.
[07:48] <infinity> acheronuk: Fixing overrides to fix debootstrap, I guess.
[07:51] <Ukikie> It'd be far better if this could be downgraded to recommends of minimal.
[07:53] <infinity> How would that be useful?
[07:53] <infinity> It'd still be on all installations by default, and I can't imagine any end user is so upset by it that they'll tear it out.
[07:53] <infinity> It's not large or intrusive.
[07:54] <infinity> (My whining about increasing the size of minimal is just that *any* size increase to minimal should be talked about, as the bloat creepy in a few bytes at a time)
[07:54] <infinity> s/creepy/creeps/
[07:55] <Ukikie> s/far/slightly/  Though yes you certainly have a point about it pulling it a bit more. :/
[07:57] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (disco-proposed) [1.2.5-1ubuntu1]
[07:57] <acheronuk> infinity: I assume final freeze will approx 9pm UTC as usual? (give or take)
[07:58] <infinity> acheronuk: Yep.
[07:58] -queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (disco-proposed) [3.32.1-1ubuntu1]
[07:58] -queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (disco-proposed) [0.56.1-1ubuntu1]
[07:59] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-appindicator [sync] (disco-proposed) [28-1]
[07:59] -queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [sync] (disco-proposed) [2.66.1-1]
[07:59] -queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [sync] (disco-proposed) [1.60.1-1]
[08:01] -queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1ubuntu1] (desktop-core)
[08:03] -queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
[08:03] -queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (disco-proposed) [1:19.04.4]
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (disco-proposed) [1.178ubuntu12]
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted emacs [source] (disco-proposed) [1:26.1+1-3.2ubuntu2]
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted calamares [source] (disco-proposed) [3.2.4-0ubuntu2]
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted librsvg [source] (disco-proposed) [2.44.10-1ubuntu1]
[08:04] -queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (disco-proposed) [1.22.5-1]
[08:04] -queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (disco-proposed) [1.2.5-1ubuntu1]
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (disco-proposed) [1.2.5-1ubuntu1]
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (disco-proposed) [1.2.5-1ubuntu1]
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (disco-proposed) [1.2.5-1ubuntu1]
[08:08] -queuebot:#ubuntu-release- Unapproved: gvfs (disco-proposed/main) [1.40.0-1 => 1.40.1-1] (desktop-core) (sync)
[08:10] -queuebot:#ubuntu-release- New: rejected linux-restricted-modules [source] (disco-proposed) [5.0.0-8.9]
[08:40] -queuebot:#ubuntu-release- Unapproved: pcsc-cyberjack (disco-proposed/universe) [3.99.5final.sp09-1.1ubuntu1 => 3.99.5final.sp09-2] (no packageset) (sync)
[08:41] -queuebot:#ubuntu-release- Unapproved: accepted pcsc-cyberjack [sync] (disco-proposed) [3.99.5final.sp09-2]
[08:43] -queuebot:#ubuntu-release- Unapproved: deja-dup (disco-proposed/main) [38.3-1 => 38.4-1] (ubuntu-desktop) (sync)
[09:06] -queuebot:#ubuntu-release- Unapproved: lammps (disco-proposed/universe) [0~20181211.gitad1b1897d+dfsg1-1 => 0~20181211.gitad1b1897d+dfsg1-2] (no packageset) (sync)
[09:06] -queuebot:#ubuntu-release- Unapproved: pcp (disco-proposed/universe) [4.3.0-1build1 => 4.3.1-1] (no packageset) (sync)
[09:07] -queuebot:#ubuntu-release- Unapproved: accepted lammps [sync] (disco-proposed) [0~20181211.gitad1b1897d+dfsg1-2]
[09:07] -queuebot:#ubuntu-release- Unapproved: accepted pcp [sync] (disco-proposed) [4.3.1-1]
[09:10] -queuebot:#ubuntu-release- Unapproved: graphicsmagick (disco-proposed/universe) [1.4~hg15916-1 => 1.4~hg15916-2] (ubuntustudio) (sync)
[09:10] -queuebot:#ubuntu-release- Unapproved: graphviz (disco-proposed/universe) [2.40.1-5build2 => 2.40.1-6] (kubuntu) (sync)
[09:11] -queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
[09:12] -queuebot:#ubuntu-release- Unapproved: libbpp-core (disco-proposed/universe) [2.4.1-2 => 2.4.1-3] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: accepted libbpp-core [sync] (disco-proposed) [2.4.1-3]
[09:13] -queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: lemonldap-ng (disco-proposed/universe) [2.0.2+ds-5 => 2.0.2+ds-6] (no packageset) (sync)
[09:13] <LocutusOfBorg> any AA, I think we should do the leveldb renaming...
[09:13] -queuebot:#ubuntu-release- Unapproved: weston (disco-proposed/universe) [5.0.0-2 => 5.0.0-3] (xorg) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: x2godesktopsharing (disco-proposed/universe) [<IP_ADDRESS>-1 => <IP_ADDRESS>-2] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: xnee (disco-proposed/universe) [3.19-2 => 3.19-3] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: workrave (disco-proposed/universe) [1.10.23-2 => 1.10.23-5] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: xmms2 (disco-proposed/universe) [0.8+dfsg-18.1build7 => 0.8+dfsg-18.2] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: x2goserver (disco-proposed/universe) [<IP_ADDRESS>-3 => <IP_ADDRESS>-4] (no packageset) (sync)
[09:13] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (disco-proposed/main) [0.28.2-1 => 0.28.2-2] (desktop-core) (sync)
[09:13] <LocutusOfBorg> bugs.debian.org/877773
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted lemonldap-ng [sync] (disco-proposed) [2.0.2+ds-6]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted x2godesktopsharing [sync] (disco-proposed) [<IP_ADDRESS>-2]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted xnee [sync] (disco-proposed) [3.19-3]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted workrave [sync] (disco-proposed) [1.10.23-5]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted x2goserver [sync] (disco-proposed) [<IP_ADDRESS>-4]
[09:15] -queuebot:#ubuntu-release- Unapproved: accepted xmms2 [sync] (disco-proposed) [0.8+dfsg-18.2]
[09:23] -queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.1-1ubuntu2 => 19.0.2-1ubuntu1] (core, xorg)
[09:42] -queuebot:#ubuntu-release- Unapproved: intel-media-driver (disco-proposed/universe) [18.4.0+dfsg1-1ubuntu1 => 18.4.1+dfsg1-2ubuntu1] (kubuntu)
[09:47] -queuebot:#ubuntu-release- Unapproved: python-reportlab (disco-proposed/main) [3.5.13-1 => 3.5.18-1] (desktop-core) (sync)
[10:03] <jibel> sil2100, today's ubuntu desktop build failed in debootstrap. Is someone looking into it?
[10:04] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1030.32~16.04.1] (kernel)
[10:05] <sil2100> jibel: infinity was looking into that (you can check the details in the backlog here on this channel)
[10:07] <jibel> k
[10:07] <jibel> thanks
[10:11] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1030.32~16.04.1]
[10:21] -queuebot:#ubuntu-release- Unapproved: gtk+3.0 (disco-proposed/main) [3.24.7-1ubuntu1 => 3.24.8-1ubuntu1] (ubuntu-desktop)
[10:22] <rbalint> ddstreet, thanks for the note,  re lxd
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (disco-proposed) [1.403]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (disco-proposed) [1.4~hg15916-2]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (disco-proposed) [3.24.8-1ubuntu1]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [source] (disco-proposed) [18.4.1+dfsg1-2ubuntu1]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (disco-proposed) [19.04.2]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted lxml [sync] (disco-proposed) [4.3.3-1]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted python-reportlab [sync] (disco-proposed) [3.5.18-1]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted weston [sync] (disco-proposed) [5.0.0-3]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted deja-dup [sync] (disco-proposed) [38.4-1]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted gvfs [sync] (disco-proposed) [1.40.1-1]
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (disco-proposed) [0.97.10]
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted graphviz [sync] (disco-proposed) [2.40.1-6]
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.2-1ubuntu1]
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted libosinfo [source] (disco-proposed) [1.4.0-0ubuntu2]
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput [sync] (disco-proposed) [0.28.2-2]
[10:43] -queuebot:#ubuntu-release- New binary: intel-media-driver [i386] (disco-proposed/universe) [18.4.1+dfsg1-2ubuntu1] (kubuntu)
[10:47] -queuebot:#ubuntu-release- New binary: intel-media-driver [amd64] (disco-proposed/universe) [18.4.1+dfsg1-2ubuntu1] (kubuntu)
[10:52] -queuebot:#ubuntu-release- New source: linux-restricted-modules (disco-proposed/primary) [5.0.0-10.11]
[11:18] -queuebot:#ubuntu-release- Unapproved: meson (bionic-proposed/universe) [0.45.1-2 => 0.45.1-2ubuntu<IP_ADDRESS>] (no packageset)
[12:15] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [11.0.2+9-3ubuntu1~18.04.2 => 11.0.2+9-3ubuntu1~18.04.3] (ubuntu-desktop) (sync)
[12:15] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11.0.2+9-3ubuntu1~18.10.2 => 11.0.2+9-3ubuntu1~18.10.3] (core) (sync)
[12:17] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.3]
[12:17] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (cosmic-proposed) [11.0.2+9-3ubuntu1~18.10.3]
[12:24] <ahasenack> acheronuk: what was the debootstrap failure?
[12:37] <acheronuk> ahasenack: W: Failure while configuring base packages.  This will be re-attempted up to five times.
[12:37] <acheronuk> W: See /build/chroot/debootstrap/debootstrap.log for details (possibly the package python3-nacl is at fault)
[12:37] <ahasenack> do you have said debootstrap.log?
[12:37] <ahasenack> I just ran a "debootstrap disco" here and it finished, including that package
[12:38] <ahasenack> I'm looking at https://launchpadlibrarian.net/418797037/buildlog_ubuntu_disco_amd64_ubuntu-server-live_BUILDING.txt.gz now
[12:40] <acheronuk> ahasenack: http://paste.ubuntu.com/p/5yx7m8WgC6/
[12:41] <ahasenack> dpkg: dependency problems prevent configuration of python3-nacl:
[12:41] <ahasenack>  python3-nacl depends on python3-cffi-backend-api-min (<= 9729); however:
[12:41] <ahasenack>   Package python3-cffi-backend-api-min is not installed.
[12:41] <ahasenack>  python3-nacl depends on python3-cffi-backend-api-max (>= 9729); however:
[12:41] <ahasenack>   Package python3-cffi-backend-api-max is not installed.
[12:42]  * ahasenack fires up a disco container
[12:44] <acheronuk> ahasenack: I just tried a new debootstrap locally, and it completed
[12:45] <ahasenack> yeah, and I'm checking python3-cffi-backend, it provides python3-cffi-backend-api-max and python3-cffi-backend-api-min
[12:45] <ahasenack> at least now
[12:46] <acheronuk> either someone fixed something, or archive/migration churn smoothed something out perhaps
[12:46] <acheronuk> big test is retrying my ISO fail.....
[12:46]  * ahasenack checks publishing history
[12:47] <ahasenack> python-cffi didn't change recently (https://launchpad.net/ubuntu/+source/python-cffi/+publishinghistory)
[12:50] <ahasenack> acheronuk: are you kicking one now?
[12:51] <acheronuk> ahasenack: trying. though the qa page is stuck on a (rebuilding) status from last fail, so not sure if it is registering my request
[12:51] <acheronuk> Kubuntu ^
[12:53]  * acheronuk refreshes log page
[12:54] <acheronuk> sil2100: do you know if that ^^ just taking a long time to respond, or ignoring me!
[12:55] <acheronuk> no new build appearing
[12:56] <ahasenack> what is the url, if it's something a non team member can see? (read/only)
[12:57] <acheronuk> ahasenack: cd logs: http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/disco/
[12:57] <ahasenack> and where do you trigger it, in lp?
[12:57] <acheronuk> a new build should be daily-live-20190411.2.log
[12:57] <acheronuk> ahasenack: http://iso.qa.ubuntu.com/qatracker/milestones/398/builds
[12:58] <acheronuk> tick box, and request rebuild from menus at bottom
[12:58] <ahasenack> it says "Kubuntu Desktop amd64 (re-building)", that's what you see?
[12:58] <acheronuk> if you are in a team who can
[12:59] <acheronuk> yep. but it said that before I tried
[12:59] <acheronuk> status looks 'stuck'
[12:59] <ahasenack> k
[13:04] <acheronuk> looks like its not going to play ball
[13:04]  * acheronuk wanders off for now
[13:21] <mitya57> infinity: this should fix kpmcore on s390x: https://github.com/thiagomacieira/tinycbor/pull/1
[13:21] <gitbot> thiagomacieira issue (Pull request) 1 in tinycbor "Parser: fix reading it->extra on big endian when bytesNeeded == 1" [Open]
[13:21] <mitya57> I will wait until tomorrow to let upstream review it, and then make an upload. (tinycbor is bundled into qtbase currently)
[13:34] <xnox> apw, funny story, looks like scalingstack VMs can boot fine with the azure kernel. Fixing systemd test suites to work with azure kernel.
[13:35] <infinity> mitya57: By tomorow, do you mean today? (final feeze!) :)
[13:36]  * xnox is preparing a systemd upload with morrrre bugfixes. like journalctl broken, udevadm broken, machinectl broken.
[13:37] <mitya57> infinity: ok, today is also possible, though I will have to upload it directly to Ubuntu rather than to Debian first.
[13:38] <mitya57> But first I will check in a PPA that kpmcore really builds on all architectures with this fix.
[13:42] <apw> xnox, !
[13:48] -queuebot:#ubuntu-release- Unapproved: openexr (disco-proposed/main) [2.2.1-4build1 => 2.2.1-4.1] (ubuntu-desktop) (sync)
[13:49] <ahasenack> infinity: hi, did you fix something regarding the iso build? wrt "<infinity> 07:48:05> acheronuk: Fixing overrides to fix debootstrap, I guess."
[13:51] <infinity> ahasenack: Yes.
[13:51] <ahasenack> what caused the failure? From http://paste.ubuntu.com/p/5yx7m8WgC6/ I can see that somehow python3-cffi-backend wasn't installable or available
[13:52] <infinity> Priorities needed updating when you pulled a bunch of stuff into important.
[13:52] <infinity> (debootstrap installs based on priority)
[13:52] <ahasenack> where did you fix it?
[13:52] <infinity> Archive overrides.
[13:52] <ahasenack> something I could have checked before?
[13:53] <infinity> No, but some warning before pulling a bunch more packages into minimal/important would have been nice. :P
[13:53] <infinity> But I'm trying not to be too bitter about that, it's before 8am, and I'm bitter enough about just being awake.
[13:53] <ahasenack> sorry about that
[13:54] <ahasenack> and good morning
[13:54]  * ahasenack on his second coffee cup
[13:54] <ahasenack> and thanks for fixing it
[14:04] -queuebot:#ubuntu-release- Unapproved: accepted openexr [sync] (disco-proposed) [2.2.1-4.1]
[14:05] -queuebot:#ubuntu-release- Unapproved: apport (disco-proposed/main) [2.20.10-0ubuntu26 => 2.20.10-0ubuntu27] (core)
[14:09] -queuebot:#ubuntu-release- Unapproved: python-opcua (disco-proposed/universe) [0.98.6-1 => 0.98.6-1ubuntu1] (no packageset)
[14:10] -queuebot:#ubuntu-release- Unapproved: accepted python-opcua [source] (disco-proposed) [0.98.6-1ubuntu1]
[14:10] -queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu4 => 240-6ubuntu5] (core)
[14:15] <infinity> xnox: Maybe it would be easier just to upload a systemd containing upstart or sysvinit.
[14:15] <xnox> infinity, hahahhahahhahahahhahaha
[14:15] <infinity> xnox: Dude, that's an eye-bleeding number of cherrypicks to get reviewed on the last day.  Well job.
[14:16] <xnox> infinity, they all came from systemd-stable tree, and i only picked the non-crazy ones. and we did have ~53 cherrypicks from stable already.
[14:17] <xnox> infinity, and well there are a few really bad regressions, and others are nice to haves (documentation updates).
[14:17] <xnox> like users in adm group not able to $ journalctl
[14:17] <xnox> is quite bad
[14:17] <infinity> xnox: Oh, I'm not questioning the provenance, nor if it's appropriate, just mentioning that it's unreviewable, so I have to take a lot on faith here. :P
[14:19] <infinity> xnox: Also, wow, these people could do with a strict commit message policy.
[14:20] <infinity> +Subject: basic/prioq: add prioq_peek_item()
[14:20] <infinity> (The entire commit message)
[14:20] <infinity> Also, it's wrong.
[14:20] <infinity> Amazingly.
[14:20] -queuebot:#ubuntu-release- Unapproved: gnome-shell (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.0+git20190410-1ubuntu1] (desktop-core, desktop-extra, mozilla) (sync)
[14:20] -queuebot:#ubuntu-release- Unapproved: mutter (disco-proposed/main) [3.32.0-1ubuntu2 => 3.32.0+git20190410-1ubuntu1] (desktop-core, desktop-extra) (sync)
[14:22] <infinity> Aaaand then there's the infamous 1-line change with 50 lines of explanation, which I now feel I need to spend the next half hour researching to make sure I come to the same conclusion.
[14:24] -queuebot:#ubuntu-release- Unapproved: gedit (cosmic-proposed/main) [3.30.2-0ubuntu<IP_ADDRESS> => 3.30.2-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[14:27] -queuebot:#ubuntu-release- Unapproved: gedit (bionic-proposed/main) [3.28.1-1ubuntu1.1 => 3.28.1-1ubuntu1.2] (ubuntu-desktop)
[14:27] <infinity> xnox: Is there somewhere I can rank systemd committers, maybe with a goal of voting some off the island?
[14:28] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (disco-proposed/main) [1.5 => 1.6] (desktop-core)
[14:29] <xnox> infinity, well, there is a tonne of contributors and very little committers. Which stuff in particular are you unhappy about? I can lookup who wrote, who reviewed, who cherrypicked into stable.
[14:29] <infinity> xnox: Oh, no code quality complaints (yet), but huge commit quality complaints from some. :P
[14:29] <xnox> out of https://github.com/systemd/systemd/graphs/contributors i personally like keszybz yuwata and evverx the best
[14:29] <infinity> xnox: And Aaron Plattner at nvidia gets a gold star for actually writing informative and useful commit messages.
[14:30] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190409.1-0ubuntu<IP_ADDRESS>]
[14:30] <infinity> A second gold star because one of these fixes was clearly a drive-by "oh, and I noticed in passing!" fix while he was fixing something else 10 lines away.
[14:30] <xnox> infinity, that puzzles me to. there do all the time " please split these three one-liners into one-liner per commit" and then "we have this 10k pull request of 10+ commits, let's squash that all into one"
[14:30] <infinity> (Pretty obvious because the context for fix A shows up in fix B)
[14:30] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190409.1-0ubuntu<IP_ADDRESS>]
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190409.1-0ubuntu<IP_ADDRESS>]
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190409.1-0ubuntu<IP_ADDRESS>]
[14:33] <infinity> +Subject: core/mount: move static function earlier in file
[14:33] <infinity> +
[14:33] <infinity> +No functional change.
[14:33] <infinity> ^-- y tho?
[14:33] <xnox> because the next patch, depends on it.
[14:33] <xnox> cause it's cherrypicks from master
[14:33] <xnox> and probably something starts using this function.
[14:33] <infinity> xnox: Sure, I don't mean why did you CP it, I mean HAVE A COMMIT MESSAGE THAT EXPLAINS WHY YOU'RE COMMITTING A NO-OP.
[14:33] <xnox> cause they do obscene amount of refactors =)
[14:34] <infinity> Cause it's clearly not a no-op, in larger context.
[14:34]  * xnox ponders to record infinity doing a standup code commit reviews.
[14:34] <xnox> with evan doing the voice-over of the commiters commit messages, to make it more of a dialogue.
[14:35] <infinity> So, really, you just want to see me punch Evan?
[14:35] <sergiusens> Laney: hey, I have been meaning to ask, I have been getting "SKIP Test requires machine-level isolation but testbed does not provide that" for a while on armhf and IIRC the test beds used to be able to do this. Any pointers?
[14:36] <Laney> sergiusens: nein, they've always been this way
[14:36] <sergiusens> Laney: ah, then I recall incorrectly. Are there plans to support machine-level-isolation?
[14:36] <infinity> sergiusens: armhf has always run in lxc/lxd, which doesn't provide machine isolation.
[14:37] -queuebot:#ubuntu-release- Unapproved: lxd (disco-proposed/main) [1:0.6 => 1:0.7] (edubuntu, ubuntu-server)
[14:38] <infinity> sergiusens: "Plans" might be the wrong word.  We've wanted nova/kvm-based armhf runners basically since day 1, and we're vaguely aware of the work required to make that happen, but I don't think anyone's taken it to the next step of "making a plan", nevermind "sizing/costing" or "implementing".
[14:38] <infinity> sergiusens: (To be honest, I think it's not unlikely that some people involved are just hoping armhf dies and we can stop caring)
[14:40] <xnox> infinity, sergiusens - there was progress on getting that done. We do build armhf cloud images with grub-uefi to achieve nova-armhf but last time we checked there was bad interaction of patch series. meaning it didn't boot yet.
[14:40] <stgraber> rbalint: uploaded your fix to both disco and cosmic
[14:40] <xnox> infinity, sergiusens - i think next steps is to recheck how good/bad disco grub is, and basically try harder to get disco armhf images.
[14:41] <rbalint> stgraber, thanks sorry for missing those, i focused on postinst too much
[14:41] -queuebot:#ubuntu-release- Unapproved: lxd (cosmic-proposed/main) [1:0.4.1 => 1:0.4.2] (edubuntu, ubuntu-server)
[14:42] <infinity> xnox: Well, even if we can get a working boot protocol (which, indeed, was many years in the making; many more than it should have been), then there's the question of resources.  nova instances are much fatter than lxd/lxc.  The way arm64/armhf queues drain today, I don't think we can add any more strain to that without getting a lot more hardware first.
[14:42] <xnox> and that as well.
[14:44] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (disco-proposed) [1:0.7]
[14:44] -queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (disco-proposed) [1.6]
[14:45] <infinity> +Subject: curl-util: fix use after free
[14:45] <infinity> +-        *ret = c;
[14:45] <infinity> ++        *ret = TAKE_PTR(c);
[14:45] <sergiusens> thanks for the answers
[14:45] <infinity> Thanks for all the context, useless commit message 37.
[14:46] <infinity> xnox: Is TAKE_PTR some magic macro that still works if its argument doesn't exist, or did they just kick the use-after-free can three feet down the road and call it "fixed"?
[14:47] <ddstreet> infinity so what's the deal with mariadb-10.1 on cosmic?  it looks like all the versions except cosmic-release have been deleted?  I don't care about mariadb-10.1 itself, but its autopkgtests still are run and fail every time...if we don't want to touch it on cosmic, can a AA please hint its cosmic tests as ignored?
[14:48] <ddstreet> or, i can upload a version that fixes the autopkgtests (for bionic and cosmic...bionic's tests fail too, but are hinted ignored)
[14:48] <xnox> infinity, it sets c to NULL, and whatever c pointed to is returned.
[14:48] <xnox> infinity, let me read that code with more context.
[14:51] <infinity> ddstreet: I don't see why we wouldn't want to touch it on cosmic.  There was a bionic security update that surely also applies to comsic?
[14:51] <xnox> infinity, TAKE_PTR is defined in src/basic/alloc-util.h
[14:51] <infinity> (And both could use autopkgtest fixes, if such fixes exist)
[14:52] <ddstreet> infinity yeah i don't know why the cosmic newer releases aren't available to install - i assumed there was some hidden reason
[14:53] <ddstreet> i'll fix the b/c autopkgtests and upload to both b/c
[14:53] <xnox> infinity, to be read in conjuction with _ceanup_(curl_easy_cleanupp) which tries to free(c) but given that we moved the pointer to **ret it would be wiped under the feet of the person.
[14:53] <infinity> ddstreet: What "cosmic newer releases"?
[14:53] <ddstreet> infinity well rmadison shows no mariadb-10.1 release for cosmic except what's in cosmic-release
[14:53] <xnox> infinity, hence TAKE_PTR is correct here, as we reset c to NULL on succesful returning c vai **ret.
[14:53] <infinity> ddstreet: Yes...
[14:53] <ddstreet> but, there are newer cosmic builds
[14:53] <xnox> in all other error cases, we do have _cleanup_(curl_easy_cleanupp) to free the stuct.
[14:54] <ddstreet> infinity e.g. https://launchpad.net/ubuntu/cosmic/+source/mariadb-10.1
[14:54] <infinity> ddstreet: Pre-dating cosmic release, yes.  They never made it through proposed-migration, and were moved to disco.
[14:54] <xnox> infinity, _cleanup_ & TAKE_PTR are awesome magics =)
[14:54] <ddstreet> latest is 1:10.1.35-1ubuntu1
[14:54] <infinity> ddstreet: Reading the delete messages helps.
[14:54] <ddstreet> i must have missed it
[14:54] <ddstreet> where is that?
[14:54] <infinity> https://launchpad.net/ubuntu/+source/mariadb-10.1/+publishinghistory
[14:55] <infinity> You can see it moving from cosmic-proposed to disco-proposed when disco opens.  And then deleted from disco when 10.3 replaces it.
[14:55] <ddstreet> moved to disco-proposed?
[14:55] <ddstreet> ah
[14:55] <ddstreet> so that removed it from cosmic too eh
[14:56] <infinity> ... no?
[14:56] <infinity> Moving it from cosmic-proposed to disco-proposed removed it from cosmic-proposed.  The keyword being "moved".
[14:56] <xnox> ddstreet, we have 4 suites per series. just because something is removed from -proposed doesn't affect what's published in release.
[14:56] <infinity> Anything in devel-proposed gets moved to next-devel-proposed when we release.  We don't assume all the junk in there is magically an SRU.
[14:56] <ddstreet> ok, so there was never any mariadb-10.1 in cosmic-updates ever, only in -proposed
[14:56] <infinity> Cause it's not.
[14:58] <ddstreet> ok got it, i'll upload to fix the test problesm then
[14:59] <ddstreet> first time i've seen a pkg not make it out of -proposed before the release drops
[15:00] <ddstreet> thnx!
[15:00] <infinity> ddstreet: There are 269 in disco-proposed right now, the vast majority of which will not migrate before release.
[15:03] <Laney> bdmurray: Bit dubious about this apport. That 'pass' doesn't actually do anything AFAIK. Shouldn't you move the code to bail out inside an "if e.errno != errno.ENOENT:" or try/catch AttributeError instead?
[15:04] <bdmurray> Laney: in a meeting at the moment, I'll look shortly
[15:05] <Laney> nod
[15:34] -queuebot:#ubuntu-release- Unapproved: ca-certificates-java (disco-proposed/main) [20180516ubuntu1 => 20190405ubuntu1] (core)
[15:42] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [sync] (disco-proposed) [3.32.0+git20190410-1ubuntu1]
[15:42] -queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (disco-proposed) [3.32.0+git20190410-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- Unapproved: tzsetup (disco-proposed/main) [1:0.94ubuntu1 => 1:0.94ubuntu2] (core)
[16:07] -queuebot:#ubuntu-release- Unapproved: rejected ca-certificates-java [source] (disco-proposed) [20190405ubuntu1]
[16:24] -queuebot:#ubuntu-release- Unapproved: ca-certificates-java (disco-proposed/main) [20180516ubuntu1 => 20190405ubuntu1] (core)
[16:24] <tdaitx> Laney: sorry for the ca-certificate-java wrong signature, I didn't pay attention that dch -r didn't update correctly, correct upload on the way
[16:26] <Laney> :D
[16:27] <vorlon> infinity: yeah, the ua implementation now definitely requires more bits, it's not great but I don't think there are other options (and the overall plan for the client has been in discussion for a long time before freeze, and this is trusty SRU material as well...)
[16:28] <vorlon> infinity: you didn't have any concerns about the specifics of what priority-mismatches showed?
[16:30] <wxl> infinity: As a member of both the SRU and Release team I'd like your opinion on two options. I've found usb-creator-kde is essentially non-functional. We have a patch. But it affects releases back to Xenial. Question is: 0 day SRU for all of them or release for Disco and SRU the others later. bug 1629715
[16:30] <ubot5`> bug 1629715 in usb-creator (Ubuntu) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged] https://launchpad.net/bugs/1629715
[16:39] <infinity> vorlon: I mean, I have no reason to hate those 5 packages in specific, but adding another MB of random junk to the debootstrap set annoys me on principle.
[16:40] <infinity> vorlon: (And I still feel like u-a-t should be in standard, not minimal)
[16:40]  * vorlon nods
[16:40] <infinity> I know why it was put in minimal, but I don't generally agree with it. :P
[16:40]  * vorlon nods
[17:00] <mvo> vorlon: hey - quick question about snapd 2.38 in xenial. it does not build on powerpc anymore because we have no golang-1.10 for powerpc. iirc we talked about this and agreed that its ok to not support powerpc on our side in the package (we also have no core snap for powerpc so nothing really changes if we don't update the package). but http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd now tel
[17:00] <mvo> ls me no ADT tests are running - do we need to hint something somewhere to get ADT back :) ?
[17:00] <mvo> vorlon: if you prefer that I put this into an email please say so, thats fine too of course
[17:01] -queuebot:#ubuntu-release- Unapproved: apport (disco-proposed/main) [2.20.10-0ubuntu26 => 2.20.10-0ubuntu27] (core)
[17:08] <bdmurray> Laney: ^ sorted
[17:12] <vorlon> mvo: checking
[17:13] <vorlon> mvo: I think if I remove the powerpc binaries from xenial it should be happy
[17:14] <vorlon> mvo: done; watch this space
[17:16] -queuebot:#ubuntu-release- Unapproved: cacti (disco-proposed/universe) [1.2.2+ds1-1 => 1.2.2+ds1-2] (no packageset) (sync)
[17:17] -queuebot:#ubuntu-release- New sync: gpustat (disco-proposed/primary) [0.5.0-2]
[17:17] -queuebot:#ubuntu-release- Unapproved: accepted cacti [sync] (disco-proposed) [1.2.2+ds1-2]
[17:22] <mvo> vorlon: thank you!
[17:38] -queuebot:#ubuntu-release- Unapproved: gnome-music (disco-proposed/universe) [3.32.0-1 => 3.32.1-1] (desktop-extra, ubuntugnome) (sync)
[17:43] <tsimonq2> This is (for real) the last Calamares upload unless we find something broke.
[17:43] <tsimonq2> Memory management-related patches and ensuring a critical configuration value is set.
[17:43] -queuebot:#ubuntu-release- Unapproved: calamares (disco-proposed/universe) [3.2.4-0ubuntu2 => 3.2.4-0ubuntu3] (lubuntu)
[17:49] <mvo> vorlon: hm, update_excuses now tells me: "missing build on powerpc: snapd (from 2.0.2)" - is there more that needs to be done to unblock this?
[17:51] <tsimonq2> Oh, and software-properties is fixing a simple packaging mistake.
[17:51] <tsimonq2> That's it for software-properties I think.
[17:52] -queuebot:#ubuntu-release- Unapproved: software-properties (disco-proposed/main) [0.97.10 => 0.97.11] (core)
[18:04] <vorlon> mvo: ah yes, I also need to do a powerpc-only removal of the arch: all binaries <eyeroll>
[18:06] <mvo> vorlon: no worries, thank you!
[18:17] <vorlon> Wimpress: hi, the ubuntu-mate disco ISOs have been reported as oversized for a while now. a) who should be getting emails about this on behalf of the mate team, besides just the cdimage folks? b) do you have any expectation of reducing the size for disco release, or do you want to bump the limit?
[18:18] <vorlon> tsimonq2: ^^
[18:18] <tsimonq2> vorlon: Kick the can to 2 GB please.
[18:19] <vorlon> tsimonq2: that's where we are already
[18:19] <vorlon> -rw-rw-r-- 1 cdimage cdimage<PHONE_NUMBER> Apr 10 03:06 disco-desktop-amd64.iso
[18:19] <tsimonq2> That was at 1.5 GB the other day...
[18:20] <tsimonq2> That's a bug.
[18:20] <vorlon> tsimonq2: uh no, it's been reporting as oversized for weeks
[18:20] <infinity> It was 2G last release.
[18:20] <vorlon> -rw-rw-r-- 2 cdimage cdimage<PHONE_NUMBER> Mar 26 22:55 ubuntu-mate/releases/disco/beta/ubuntu-mate-19.04-beta-desktop-amd64.iso
[18:20] <infinity> Are you maybe thinking he's talking about lubuntu because he pinged you for some reason? :P
[18:20] <tsimonq2> Ohh.
[18:21] <vorlon> I pinged him because he's a member of ubuntu-mate-dev :)
[18:21] <infinity> Aren't we all?
[18:21] <vorlon> infinity: not directly like him ;)
[18:21] <vorlon> yeah this is ubuntu-mate, everyone else is fine at this point
[18:22] <infinity> 2G sticks are still a wildly common size for people to pick up in random junk and schwag piles, would be a shame to oversize that if it can be avoided.
[18:22] <tsimonq2> If I'm wearing that hat, let me talk to the boss then. :P
[18:23] <infinity> Although, that said, the last time my dad got a bulk bag of junk USB sticks, the smallest was 8G.
[18:23] <infinity> So maybe it's time to goldfish all our ISOs!
[18:24]  * infinity goes to find 6G worth of stuff.
[18:25] <tsimonq2> Let's do a full archive d-i image. :P
[18:25] <vorlon> let's ship uncompressed squashfs for faster boot
[18:26] <Wimpress> vorlon I am aware. I did recently reduced the isos by 300MB.
[18:26] <infinity> Pretty sure that would be slower, not faster.
[18:26] <vorlon> infinity: <furious handwave>
[18:26] <infinity> vorlon: <furiosa hookwave>
[18:26] <Wimpress> I've got some options to further reduce the iso size, but it's too late to do that this cycle.
[18:27] <vorlon> infinity: let's ship 3 copies of the squashfs as a raid5 for better data integrity
[18:27] <infinity> I'm okay with getting the oversize warning when publishing disco if your goal is to shrink again for EE.
[18:27] <Wimpress> But on my task list for 19.10. Something I'll do very early in the cycle.
[18:28] <infinity> But, out of interest, what other ideas did you have, and why can't we just bang 'em out right now? :P
[18:28] <vorlon> missing build on powerpc: snapd (from 2.0.2)
[18:28] <vorlon> mvo: ^^ lol I can't win
[18:28] <vorlon> mvo: I'll just add a force hint now
[18:28] <Wimpress> Switching from fcitx to ibus to reduce the many different toolkits seeded in the iso is one.
[18:29] <mvo> vorlon: weee, thanks again!
[18:29] <Wimpress> Switching everything the python3 is a other. We have py2 and py3 components now.
[18:30] <Wimpress> I need MATE Desktop 1.22 to eradicate py2. I only committed those packages to Debian Salsa lastnight.
[18:30] <vorlon> Wimpress: does fcitx depend on the "wrong" toolkit, or does it just have overly-aggressive recommends: that pull in multiple?
[18:30] <vorlon> because the latter is definitely a bug in fcitx and I think would be appropriate to fix before release
[18:30] <Wimpress> The later.
[18:30] <xnox> vorlon, infinity - speaking of our squashfs, why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather.
[18:30] <xnox> is that because our iso9660 is a bad substrate to carry squashfs files?
[18:30] <vorlon> No results found for "unable to read metadata something rather".
[18:30] <vorlon> Results for unable to read metadata something rather (without quotes):
[18:30] <vorlon> Search Results
[18:30] <vorlon> Web results
[18:31] <Wimpress> I don't think the fcitx Recommeds is a bug.
[18:31] <vorlon> Wimpress: I do.
[18:31] <xnox> vorlon, i will file a bug report with that tile in a moment, such that google will find it!
[18:31] <vorlon> xnox: good show
[18:31] <Wimpress> It is adding yet another toolkit to the image.
[18:32] <Wimpress> Switching to ibus I can prevent that.
[18:32] <vorlon> it's a wrong use of Recommends to pull in toolkits that otherwise wouldn't be present, for an input method
[18:33] <Wimpress> It has an Indicator which is where the toolkit gets pulled in.
[18:33] <vorlon> ah, and that indicator is only implemented in the one toolkit?
[18:34] <xnox> vorlon, bug #1824407
[18:34] <ubot5`> bug 1824407 in linux (Ubuntu) " why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather" [Undecided,New] https://launchpad.net/bugs/1824407
[18:34] <infinity> ...
[18:35] <vorlon> Wimpress: but 'fcitx-frontend-all' is on ubuntu-mate-live, and that piece definitely looks wrong
[18:35] <xnox> shit like
[18:35] <xnox> Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff3660032757063
[18:35] <xnox> Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff3660032757063]
[18:35] <tjaalton> I sent an email to ubuntu-release@ asking for a reviewer to get intel-compute-runtime etc in disco before release, if possible.. any takers?-)
[18:35] <vorlon> Recommends: fcitx-frontend-gtk2, fcitx-frontend-gtk3, fcitx-frontend-qt4, fcitx-frontend-qt5
[18:35] <vorlon> yeah no die
[18:35]  * cjwatson has flashbacks to the dapper release sprint
[18:35] <vorlon> a) if the package is called *all*, why is it a Recommends instead of a Depends
[18:35] <vorlon> b) seriously who wants this
[18:36] <vorlon> Package: fcitx
[18:36] <vorlon> Recommends: [...] fcitx-frontend-all | fcitx-frontend-fbterm
[18:36] <infinity> Seeding fcitx looks like a mistake, period.
[18:36] <infinity> One should seed the config and frontend modules they want.
[18:36] <vorlon> quite possibly
[18:36] <cjwatson> surely that should be done with a virtual instead
[18:36] <infinity> (config and frontend should also have Provides that fcitx can Recommend, but fixing that today seems less fun)
[18:37] <cjwatson> Package: fcitx / Recommends: fcitx-frontend-whateverisbest | fcitx-frontend
[18:37] <cjwatson> or something
[18:37] <cjwatson> -all is just a weird approach
[18:37] <infinity> cjwatson: Yes, that would be ideal, but I'd also rather do that in Debian first, to avoid upgrade headaches when they take the patch but change the names. :P
[18:37] <vorlon> Wimpress: ^^ so all of that is fixable before release; we can support you in getting it fixed, but I don't know which of the frontends / configs are the right ones for mate without digging
[18:37] <cjwatson> yep
[18:38] <infinity> MATE is still gtk2, no?
[18:38] <infinity> Or is it 3?
[18:38] <infinity> I forget.
[18:39] <infinity> Anyhow, thanks to amazingly consistent package naming, you'd want either fcitx-frontend-gtk2 + fcitx-config-gtk2 or (wait for it) fcitx-frontend-gtk3 + fcitx-config-gtk
[18:39] <infinity> Because wat.
[18:40] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (disco-proposed/main) [64ubuntu5 => 64ubuntu6] (ubuntu-desktop) (sync)
[18:41] <Wimpress> Seeding fcitx in live is (was?) required so when CJK users select their language Ubiquity installs/configures fcitx as the IME. It was the case fcitx was preferred by CJK users. That has changed now.
[18:41]  * infinity notes that lubuntu, kylin, and kubuntu also seed fcitx.
[18:41] <Wimpress> More than happy to work on this.
[18:42] <Wimpress> Ubuntu MATE should only require GTK3 but I "think" the different toolkit versions of fcitx are to facilitate IME compatibility for apps using the different toolkits.
[18:43] <infinity> Probably.  How many Qt applications do you have installed on your ISO?
[18:43] <Wimpress> None.
[18:43] <infinity> There you go.
[18:43] -queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [<IP_ADDRESS>.7 => <IP_ADDRESS>.8] (desktop-core, ubuntu-server)
[18:43] <Wimpress> For post-install compatibility
[18:44] <Wimpress> I could make the changes to switch to Ibus now, and drop fcitx.
[18:45] <Wimpress> It will require I update the seeds, meta packages and ubuntu-mate-settings.
[18:45] <Wimpress> All things I can do easily and upload.
[18:45] <infinity> To be fair, for ibus, I only see a gtk2 and gtk3...
[18:47] <infinity> Actually, I think you're likely wrong.
[18:47] <infinity> I think the frontends are more tied to desktop than application toolkit.
[18:47] <infinity> As in, they provide modules for the IM widgets that you'd expect to ship on a gtk2/gtk3/qt4/qt5 desktop.
[18:47] <infinity> Maybe.
[18:48] <infinity> Either way.  Paring down fcitx packages or switching entirely seems to drop some unknown quantity of Qt stuff.  And that's likely fine.  But I'd say the fcitx changes would be less likely to cascade on the day of final freeze.
[18:50] <Wimpress> If the release team are happy for me to make the transition to Ibus at this stage in the cycle, I'm happy to do it.
[18:50] <infinity> Do you know what that transition entails, if there's actually a "transition" (data migration, etc?), and how to test that it's not broken?
[18:52] <Wimpress> I don't know how a transistion would work when doing a release upgrade. I'd have to talk with some of the CJK users to learn more.
[18:52] <infinity> 4a08a5af7f22db8a8791252f3f17e22442a31573 in the Ubuntu seeds seems to be the corresponding commit.
[18:53] <infinity> And I don't think we did any data migration in Ubuntu, but you could ask Gunnar.
[18:53] -queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[18:54] <Wimpress> Yes, that is my understanding from Gunnar. But there are some Japanese users who I can ask.
[18:54] <Wimpress> Is migration important for an interim?
[18:55] <infinity> I mean, it's not important to me at all if I'm told it's not necessary. :P
[18:55] <Wimpress> If it is possible, can it be done in 19.10 so LTS upgrades for 20.04 are catered for?
[18:56] <infinity> And if we didn't/don't do any migration in Ubuntu proper (like I said, ask Gunnar?), I certainly won't set a higher bar for flavours.
[18:56] <tsimonq2> fcitx> Did someone say Qt 4? *finds a hammer*
[18:58] <infinity> andyrock: It's generally considered good practice to use the same version of automake as the previous uploader (ie: the one from bionic, not the one from xenial) when updating a package that autoreconfiscates to avoid all the noise.
[18:59] <Wimpress> infinity vorlon I'll double check on migration options. But, are you OK with me making the switch now?
[19:00] <vorlon> Wimpress: to ibus, or to drop the fcitx alternate toolkits?
[19:00] <vorlon> Wimpress: if I were you I would be nervous about migrating to ibus so close to release
[19:01] <infinity> I'm okay with either, if it's testable.  The fcitx problem might require some uploads so that it's insane circular deps don't just pull everything in anyway.
[19:01] <infinity> (note that literally the only seeded package right now is 'fcitx-bin', and that pulls in the world)
[19:04] <infinity> Wimpress: I'm also entirely okay with punting this until post-release, and releasing slightly oversized.
[19:05] <infinity> Wimpress: 2G sticks will be left out for a while, but oh well.
[19:05] <infinity> Wimpress: My "why can't it be done now" inquiry was an inquiry, not a demand. :)
[19:07] <Wimpress> infinity, OK. Then I'd rather do this early in 19.10.
[19:08] <Wimpress> Our QA guys have been testing our isos this week and we're in good shape.
[19:08] <Wimpress> I'd prefer to not rock the boat right now.
[19:10] <acheronuk> is anyone able to fix this by release day? http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/
[19:11] <acheronuk> if not, I might think reverting to the standard ubuntu would look less awful
[19:14] <acheronuk> lubuntu's is also a bit 'glitched', but not quite so bad
[19:25] <vorlon> acheronuk: what is it you're asking to have fixed, and who are you asking?
[19:26] <vorlon> acheronuk: the orange in the header? something else in addition?
[19:27] <vorlon> ok, a reference to https://assets.ubuntu.com/v1/775cc62b-vanilla-grad-background.png is embedded in the html we generate
[19:28] <vorlon> that's bad... style
[19:28]  * vorlon puts on his NCIS shades
[19:28] -queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-19-g36351dea-0ubuntu1 => 18.2-22-g08bf6ff7-0ubuntu1] (ubuntu-desktop, ubuntu-server)
[19:29] <vorlon> acheronuk: is that the only thing that needs fixing?
[19:33] <acheronuk> vorlon: mostly the orange header. some of the other formatting has gone odd as well. main page content used to be more like: https://i.imgur.com/7v9DuDv.png
[19:34] <acheronuk> Simon was going to look at one point....
[19:35] <tsimonq2> xnox volunteered I think
[19:35] <tsimonq2> I can look though.
[19:35] -queuebot:#ubuntu-release- Unapproved: unity-lens-photos (disco-proposed/universe) [1.0+17.10.20170605-0ubuntu3 => 1.0+17.10.20170605-0ubuntu4] (no packageset)
[19:35] <vorlon> all I ever saw was an MP that reverted all of the HTML changes in an if kubuntu: else: which I nacked
[19:36] -queuebot:#ubuntu-release- Unapproved: accepted unity-lens-photos [source] (disco-proposed) [1.0+17.10.20170605-0ubuntu4]
[19:36] <acheronuk> with old header: https://i.imgur.com/x6Bjdg6.png
[19:37] <xnox> vorlon, i did say, we should have at least min-effort attempt at having vanilla like banner for derivatives, and i did get assets for lubuntu to use.
[19:37] <acheronuk> vorlon: yeah, that sounds familiar
[19:38] <vorlon> xnox: I guess even moving this background-image style out of the html and into the css include for Ubuntu would improve
[19:42] <tsimonq2> +1
[19:42] <tsimonq2> We'd then mostly drop custom CSS and switch out that background.
[19:47] <wxl> infinity: not sure you saw my message above about usb-creator-kde, but i'm inclined to do the 0 day SRU. if you feel otherwise, please let me know asap.
[19:48] <wxl> ^^ vorlon: since you are also SRU/Release Team you might have an opinion on whether or not to do 0 day SRU for xenial-disco on usb-creator versus release in disco and SRU the others. see bug 1629715
[19:49] <ubot5`> bug 1629715 in usb-creator (Ubuntu Disco) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged] https://launchpad.net/bugs/1629715
[19:49] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (disco-proposed/universe) [5.12.2+dfsg-4 => 5.12.2+dfsg-4ubuntu1] (kubuntu, qt5)
[19:49] <mitya57> infinity: ↑ here is the Qt upload. Tested in a PPA and kpmcore builds fine (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3696/+packages)
[19:50] <wxl> thanks for that btw mitya57
[19:51] <xnox> vorlon, stuff in http://cdimage.ubuntu.com/include/ is just there on disk, right? no git repo, no backups?
[19:51] <mitya57> wxl: Np. Unfortunately because of feature freeze this goes without upstream review, but it passes upstream tests so it should be fine.
[19:51] <mitya57> s/feature/final/
[19:51] <xnox> (well i assume there are actually whole machine backups....)
[19:52] <vorlon> xnox: yup
[19:53] <wxl> mitya57: fingers crossed :)
[20:02] <infinity> wxl: The bug's been known for years, apparently, not sure how it's suddenly urgent enough to be worth a discussion.
[20:02] <infinity> wxl: If you want to SRU it, by all means, fix it whenever, but "0-day" is a bit much.
[20:02] <wxl> infinity: yeah, i'm kind of shocked, honestly. i never use the darn thing, so..
[20:03] <wxl> infinity: i mean lubuntu's late to the game on this one.. kubuntu should have picked this up a while back.
[20:03] <wxl> infinity: that said, i blame acheronuk
[20:03] <infinity> *smirk*
[20:03] <infinity> wxl: Anyhow, regular process applies, SRU at will, I just see no reason to expedite or rush anything.
[20:04] <infinity> "Package that's been broken for years is still broken" isn't really news.
[20:04] <wxl> infinity: okie dokie. i guess i get a little alarmed when an application does not work *at all* but given the history, you're right: it's probably not that urgent.
[20:05] <acheronuk> # * (usb-creator-kde) [i386 amd64] # disabled cos it's broken
[20:05] <wxl> X'D
[20:05] <acheronuk>     Committer: Jonathan Riddell
[20:05] <acheronuk>     Date: 2014-11-11 15:58:31 UTC
[20:05] <infinity> Solid bugfix.
[20:05] <wxl> X''''''''''''''''''''''''''''''''D
[20:05] <infinity> Good job Riddell.
[20:06] <infinity> wxl: "Don't ship it" is also an entirely valid position. :P
[20:06] <acheronuk> About once every 6 months I see that and think, oh I forgot!
[20:06]  * acheronuk hides
[20:06] <wxl> infinity: yeah, i'm sure someone will whine.
[20:06] <infinity> mitya57: My hero.
[20:06] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (cosmic-proposed) [2.7.16-2~18.10]
[20:06] <wxl> admittedly the patch is rather new.. may of last year
[20:08] -queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (disco-proposed) [5.12.2+dfsg-4ubuntu1]
[20:09] -queuebot:#ubuntu-release- Unapproved: accepted tzsetup [source] (disco-proposed) [1:0.94ubuntu2]
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (disco-proposed) [2.20.10-0ubuntu27]
[20:12] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (disco-proposed) [2.20.10-0ubuntu27]
[20:12] -queuebot:#ubuntu-release- Unapproved: rejected leveldb [sync] (disco-proposed) [1.20-2.1]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:<IP_ADDRESS>]
[20:18] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.31]
[20:20] <vorlon> acheronuk: how does http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/ look now?
[20:21] <acheronuk> vorlon: I can live with that in the short term :)
[20:21] <acheronuk> thanks
[20:21] <vorlon> acheronuk: ok, I'll raise an mp to ubuntu-cdimage that should do this
[20:33] -queuebot:#ubuntu-release- Unapproved: wireshark (disco-proposed/universe) [2.6.7-1 => 2.6.8-1] (no packageset) (sync)
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted wireshark [sync] (disco-proposed) [2.6.8-1]
[20:36] -queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (cosmic-proposed) [2.7.16-2~18.10]
[20:39] -queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.3-2~18.10]
[20:40] -queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.8-1~18.10]
[20:44] -queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (cosmic-proposed) [3.6.8-1~18.10]
[20:48]  * tsimonq2 waits for final freeze to be declared
[20:49] <Eickmeyer> ^ditto tsimonq2
[20:49] <tsimonq2> I believe last time I checked it was 20  UTC?
[20:50] <infinity> 2100
[20:50] <tsimonq2> oh, ok :)
[20:50] <infinity> Which is, apparently, in 10 minutes.
[20:50] <infinity> Time flies.
[20:50] <tsimonq2> Right.
[20:51] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu2 => 1.10ubuntu3] (core)
[20:51] <tsimonq2> infinity: Can I safely assume already-uploaded stuff is safe? Or should I be profusely nagging you? :P
[20:51] <infinity> tsimonq2: You can assume that nagging won't change anything.
[20:51] <tsimonq2> That's fair.
[20:53] <infinity> tsimonq2: Ultimately, for packages only you seed, you have final say anyway (up to a point).   :P
[20:54] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu<IP_ADDRESS> => 1.5ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[20:54] <wxl> LET"S DO IT
[20:54] <tsimonq2> XD
[21:00]  * acheronuk watches the gates slam shut
[21:05] <rbalint> ha i made it with u-u :-)
[21:05] <xnox> vorlon, can you please put https://people.canonical.com/~xnox/lubuntu/ into http://cdimage.ubuntu.com/include/lubuntu/ ?
[21:06] <xnox> the two pngs from there, to there?
[21:06] <wxl> oooh fancy
[21:06] <wxl> thanks xnox
[21:08] <Eickmeyer> Oooh! Nice, xnox!
[21:08] <Eickmeyer> We need one for Ubuntu Studio, too.
[21:08] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu<IP_ADDRESS> => 1.1ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[21:15] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (bionic-proposed/universe) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.1 => 10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2] (personal-fossfreedom, ubuntu-budgie)
[21:16] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.1 => 10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2] (personal-fossfreedom, ubuntu-budgie)
[21:16] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (disco-proposed/universe) [10.5-0ubuntu1 => 10.5-0ubuntu1.1] (personal-fossfreedom, ubuntu-budgie)
[21:29] <xnox> tested ubuntu-server -> probably did not break anything
[21:31] <tsimonq2> xnox: The include directory as a whole isn't in a Git repo but Lubuntu's is.
[21:32] <tsimonq2> https://code.launchpad.net/~lubuntu-art/+git/cdimage-css
[21:32] <tsimonq2> Thanks though :)
[21:33] <xnox> now testing the new lubuntu
[21:33] <xnox> tsimonq2, but you don't have access to drop things on cdimage anyway, right?
[21:33] <xnox> tsimonq2, i will send the assets back to you later, with sources.
[21:34] <tsimonq2> Right.
[21:34] <tsimonq2> Thanks!
[21:37] <vorlon> xnox: who's signing off on those on behalf of the lubuntu team?
[21:39] <xnox> tsimonq2, that's a junk repository -> not part of any project, so i cannot give a merge proposal for it. i can like email a git patch.
[21:39] <xnox> vorlon, it's better than current stuff, and it's new logos -> not replacing anything existing to _adding_ them shouldn't be a problem, until after cdimage code is merged.
[21:39] <xnox> vorlon, and well, lubuntu will need to check out the cdimage code and possibly tweak things from there.
[21:40] <tsimonq2> I'm currently afk, I'll ack/nack in a bit unless wxl can.
[21:40] <tsimonq2> xnox: Put the commits somewhere and I can review
[21:41] <rbalint> please reject all unattended-upgrades uploads, i'd like to add one more thing
[21:41] <rbalint> (tomorrow)
[21:42] <xnox> tsimonq2, git pull https://git.launchpad.net/~xnox/+git/lubuntu-cdimage-css  master
[21:42] <tsimonq2> ta
[21:44] <vorlon> xnox: "it's better than current stuff" does not mean I take changes to the lubuntu directory from non-lubuntu devs.  anyway, since that one is git, I will only take updates via git :)
[21:46] <vorlon> acheronuk: https://code.launchpad.net/~vorlon/ubuntu-cdimage/no-hard-coded-style/+merge/365882
[21:53] <xnox> i wonder if we can make ubuntu use a css with includes too
[21:58] <acheronuk> vorlon: commented as far as I am able to
[22:03] <vorlon> xnox: that's what the cssincludes() function already does
[22:03] <xnox> vorlon, well, i've been changing it locally, and have a big diff which will become unmergable if you merge your hack in =)
[22:04] <xnox> vorlon, i guess i'll have to reincorporate your changes, if you merge that.
[22:10] <xnox> vorlon, tsimonq2 - http://people.canonical.com/~xnox/lubuntu/
[22:10] <xnox> is what i have created in my cdimage branch, making merge proposal now.
[22:18] <vorlon> xnox: you're still inlining the background style, which I don't agree with; this requires more ubuntu-cdimage code changes in the future for things that flavors should be able to manage entirely through stylesheets
[22:18] <vorlon> what you called my "hack" was a deliberate decision ;)
[22:19] <xnox> vorlon, i wasn't make any decisions around there, i am more focused on making flavour page look actually good.
[22:20] <xnox> vorlon, i can incorporate your change into my code as well (i.e. move things out of inline style into the <style> block)
[22:20] <xnox> vorlon, and you want the same to be done with the p-navigation__image i guess?
[22:22] <vorlon> xnox: hmm in principle yes, though I was taking it one step at a time
[22:23] <xnox> vorlon, note, this switches lubuntu to vanilla css, without any override.
[22:23] <vorlon> ?
[22:23] <xnox> vorlon, i guess we can include a lubuntu/vanilla.css override.
[22:23] <xnox> vorlon, well, we dropped our ubuntu.css too
[22:24] <xnox> vorlon, my code is same as ubuntu's one, with just target url replaced + top left logo + banner background.
[22:25] <vorlon> right
[22:25] <vorlon> but those overrides should live in a per-flavor css include
[22:26] <xnox> vorlon, ok, and do we have an ubuntu project css include?
[22:26] <xnox> or should I do
[22:26] <vorlon> xnox: no; currently that's the "default" and is all inlined, which I think is reasonable
[22:26] <xnox> ack
[22:26] <xnox> so inline inline inline, include override
[22:26] <vorlon> yah
[22:26] <xnox> rather than encode inlining all the projects
[22:27] <xnox> vorlon, and what to do with the favicon? (which i am not sure work)
[22:27] <vorlon> what I definitely don't want to do is to have cdimage mirrors of releases.u.c dependent on css from both assets.u.c and releases.u.c (or worse, cdimage.u.c)
[22:27] <xnox> ack
[22:28] <vorlon> i.e. I don't want the pipe flooded w/ non-mirrorable css requests on release day
[22:28] <xnox> and releases.u.c only hosts ubuntu at the moment?
[22:28] <vorlon> yes
[22:28] <xnox> cause cdimage kubuntu depends on assets on releases.ubuntu.com i believe
[22:28] <vorlon> the kubuntu css happens to also be on releases for historical reasons, and that's ok
[22:28] <vorlon> as a percentage of total traffic
[22:28] <xnox> hahahhaha
[22:28] <xnox> ok
[22:29] <xnox> tsimonq2, what do you think about http://people.canonical.com/~xnox/lubuntu/ ?
[22:30] <xnox> vs i guess the last good old publication at http://cdimage.ubuntu.com/lubuntu/releases/cosmic/release/
[22:30] <vorlon> xnox: basically, having kubuntu css on releases.u.c vs cdimage.u.c doesn't make any net difference to Canonical's bandwidth; but having to hit releases.u.c for css for the Ubuntu pages on all the cd mirrors means a lot more traffic, because it's tied to a hostname that's much heavier to mirror (releases.u.c vs assets.u.c)
[22:30] <vorlon> *and* we're already hitting assets, we don't want to hit both assets and releases
[22:31] <xnox> vorlon, i personally think, all assets should be on assets.ubuntu.com
[22:31] <xnox> vorlon, include ubuntu-cdimage.css snippet; and all flavour css/png snippets.
[22:32] <xnox> the kubuntu css, the lubuntu logos, etc.
[22:32] <xnox> back in the day we didn't have assets.ubuntu.com, but now we do, why not use it properly?
[22:34] <xnox> tsimonq2, the biggest gain from using vanilla css is that it browsable on the phone much nicer.
[22:35] <vorlon> xnox: I don't object to things moving to assets.u.c, but you need to talk with the web team about that :)
[22:36] <xnox> vorlon, i shall
[22:36] <xnox> vorlon, but i bet they are in lockdown this week.
[22:40] <vorlon> infinity: any thoughts on https://code.launchpad.net/~vorlon/ubuntu-cdimage/no-hard-coded-style/+merge/365882 ?
[23:15] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1042.46~14.04.1]
[23:16] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1030.32]
[23:22] <vorlon> infinity, Laney: I give up, I finally got a force hint to take effect for snapd on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd but it just made it a candidate without triggering any autopkgtests


[00:02] <phillw> !bug 1
[00:12] <Mark76> !bug 2
[00:12] <Mark76> :(
[00:20] <head_victim> bug 692121
[00:20] <head_victim> :D Don't need the ! afterall
[09:58] <_kosaidpo> hello guys
[09:59] <_kosaidpo> any one can help icant login via GUI it keeps displayin over n over
[10:02] <bioterror> propabl wrong desktop or something
[10:31] <_kosaidpo> hello guys anynoe hee
[10:31] <_kosaidpo> here
[14:54] <GaryD> how do i get xdg-autostart to work in openbox?
[15:05] <GaryD> i have searched forums, google, blogs, and more trying to find the answer. i just can't find it.
[15:06] <head_victim> http://openbox.org/wiki/Help:Autostart
[15:07] <head_victim> No idea if that's what you're looking for
[15:07] <Yorvyk> GaryD, http://openbox.org/wiki/Help:Autostart any good?
[15:07] <GaryD> no help there.
[15:08] <head_victim> GaryD: have a look at bug 285896
[15:08] <head_victim> Might be why
[15:08] <GaryD> i have no problems using the autostart.sh file. what i want to do is use desktop files in the /etc/xdg/autostart and /.config/autostart
[15:09] <GaryD> then how am i supposed to use xdg autostart with openbox if they aren't going to fix it?
[15:09] <GaryD> also it doesn['t come with the python-xdg package.
[15:09] <head_victim> Maybe it just doesn't install it by default
[15:09] <GaryD> so how can i get it?
[15:10] <GaryD> how does lubuntu sue xdg autostart?
[15:11] <GaryD> i am building a custom lubuntu from the mini iso. but if i were to use lubuntu straight forward, i would be able to drop some desktop files in the autostart folder and they work.
[15:11] <GaryD> so how did the lubuntu team get the xdg autostart things working?
[15:12] <head_victim> GaryD: sorry mate this is all a bit above me, I'm just working with google to try and help. If you need specifics that don't seem to be forthcoming I"d suggest dropping the mailing list a line
[15:13] <GaryD> head_victim: thanks. i will keep on keeping on i guess.
[15:14] <head_victim> GaryD: I'm certain there'd be someone on the mailing list to help out or if you want to hang around here I'm sure someone will come along. I don't know how Yorvyk is but I'm a bit out of my depth
[15:15] <Yorvyk> Same here
[15:15] <GaryD> head_victim: thanks. i am not so sure about the mailing list. i have never used one before. but i am sure i will find the answer sometime or another.
[15:24] <GaryD> the script is in the source package.
[15:27] <GaryD> does anyone know how to make a deb from the source package?
[15:33] <head_victim> GaryD: http://ubuntuforums.org/showthread.php?t=51003&highlight=checkinstall might help
[15:34] <head_victim> Again over my head but looks like it's what you want.
[15:34] <GaryD> thanks.
[18:43] <mmaksimov> Hi. Is lubuntu-control-center available via PPA?
[19:02] <Yorvyk> mmaksimov, yep, https://launchpad.net/~lubuntu-desktop/+archive/ppa
[19:10] <mmaksimov> Yorvyk, thanks. Is this ppa added by default to 10.10 installation? if yes, I'm too dumb for today and should get some sleep ;)
[19:11] <Yorvyk> mmaksimov, :)
[19:12] <mmaksimov> Yorvyk, is this "yes" or "no"?
[19:13] <Yorvyk> mmaksimov, your choice :)
[19:13] <econdudeawesome> Hi y'all! Do any of y'all get a request to unlock the keyring when you bootup? If so, do you know how to see which programs are requesting?
[19:15] <Yorvyk> econdudeawesome, is the password you log in with different to the keyring password
[19:16] <mmaksimov> Yorvyk, well, the message from add-apt-repository suggests that it was already there....
[19:17] <Yorvyk> mmaksimov, already installed ?
[19:27] <econdudeawesome> Yorvyk: no, it is the same password
[19:31] <mmaksimov> Yorvyk, I guess so.
[19:47] <econdudeawesome> hmm
[19:48] <Yorvyk> Hmmmm,
[19:49] <Yorvyk> econdudeawesome, that's the only time I've seen the keyring ask for authorisation.
[19:50] <Yorvyk> the first thing that needs it is wireless, if you have it
[19:52] <mmaksimov> Yorvyk, econdudeawesome, on my two lubuntu laptops the system always asks for the password when first connecting to wireless after logon. Logoff then logon causes another request. My password is the same that is used for login.


[00:04] <wxl> knome: looks reasonable to me. no obvious problems at first glance
[00:08] <knome> wxl, thanks. if you play around with it more (not required, but if you do), feel free to give me any feedback and/or report issues you find in github
[00:09] <knome> also, would it be something you could use?
[00:09] <knome> or would you like feature X to be able to use it
[00:10] <wxl> oh yeah i'd use this
[00:11] <knome> thanks again
[00:54] <knome> btw, loco portal admins, the ubuntu cote d'ivoire website link leads to a page you likely don't want it to link to...
[02:02] <mhall119> knome: is there a right link?
[02:06] <mhall119> ugh, looks like they may have lost the domain
[02:08] <mhall119> knome: I've removed the links for now, are you in touch with anyone on that team to let them know what happened?
[07:41] <dholbach> good morning
[14:13] <knome> mhall119, nope, i just noticed it while browsing the directory myself
[16:57] <jonobacon> dpm, I am ready when you are
[16:59] <dpm> jonobacon, wrapping up the team call
[16:59] <jonobacon> dpm, cool, just call me when you are ready
[17:03] <dpm> jonobacon, ok, all set!
[17:03] <dholbach> all right my friends - have a good one!
[17:03] <jonobacon> dpm, cool
[18:12] <jose> hmm, k-lines?


[09:44] <xnox> is lp:~ubuntu-core-dev/ubuntu/precise/grub2/precise the dev branch for grub2 with rich history?
[09:49] <cjwatson> Yes
[09:49]  * cjwatson is reminded to bump that to quantal
[09:57]  * xnox is reminded to schedule ubiquity discussion with cjwatson
[09:59] <cjwatson> yep - maybe not today though, work item central
[09:59] <cjwatson> lp:~ubuntu-core-dev/ubuntu/quantal/grub2/quantal exists now
[10:04] <xnox> cjwatson: ok. but my bugfix will target both :P
[10:04]  * xnox needs to distill work items as well
[12:13] <anoman> Hai, bagaimana melakukan instalasi ubuntu 12.04 server menggunakan keyboard USB
[12:14] <anoman> Hi, how to install ubuntu server 12.04 using a USB keyboard


[07:43] <alkisg> Hi all, somewhat unrelated question but I was told the all experts are here :D
[07:43] <alkisg> `echo on >/sys/kernel/debug/dri/0/DP-3/force` forces that output to on. How can I set it back to unspecified? It accepts on, off but I can't find anything that would set it to the initial unspecified state...


[05:53] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/4512 Successfully built
[08:09] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/4512 Publishing packages
[08:32] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/4512 UNAPPROVED queue
[13:19] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4497 Generating diffs
[13:25] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4497 Successfully built
[21:21] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4501 Needs rebuild due to higher version at destination


[13:05] <aaaaaaaaa> hi
[13:05] <aaaaaaaaa> How all ?
[15:00] <lazyPower> Good Morning Juju Community!
[15:00] <lazyPower> We'll be kicking off in a moment
[15:01] <lazyPower> http://summit.ubuntu.com/uos-1411/meeting/22389/juju-charm-school/ - if you need the link to follow along at home
[15:01] <lazyPower> If you'd like to join the hangout and talk on air with us, https://plus.google.com/hangouts/_/hoaevent/AP36tYc0Jup3WIfx2y7xjN_n5r_CqEIPHfQALDK4M8cYEvra-yB17Q?authuser=0&hl=en
[15:05] <lazyPower> uh oh, i see our summit page is missing the link
[15:05] <lazyPower> http://youtu.be/BQ_blv9JhCs - THis will get you started while we figure out what we did with the video link on summit
[15:07] <cory_fu> Do you need a PPA to install juju?
[15:09] <rbasak-uos> sudo add-apt-repository ppa:juju/stable
[15:09] <rbasak-uos> (IIRC)
[15:09] <lazyPower> that is correct!
[15:09] <lazyPower> to the new joiners - it appears we didnt put the correct link int eh summit page - you can follow along here: http://youtu.be/BQ_blv9JhCs
[15:09] <lazyPower> many apologies for the inconvenience
[15:13] <kwmonroe> \join #ubuntu-uds-devops-1
[15:15] <kwmonroe> 1/join #ubuntu-uds-devops-1nnnnnnnnnnnnnnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.mmmmmmmmmmjkllko-],m
[15:15] <lazyPower> kwmonroe: awesome cat typing
[15:19] <kwmonroe> doh!
[15:22] <larrymi2> QUESTION what's the local entry in your environments file look like?
[15:22] <kwmonroe> thanks mbruzek1!  we'll get that 1st 5 minute walkthrough doc live asap.
[15:25] <larrymi2> great thank you
[15:25] <mbruzek1> You are welcome
[15:26] <mbruzek1> Thanks for the question
[15:31] <mbruzek1> Please let us know if you have questions!
[15:42] <cory_fu> lazyPower: The syntax for relation_set is actually: hookenv.relation_set(hookenv.relation_id(), {'public-address': hookenv.unit_get('public-address')})
[15:49] <noise][> thanks for the juju intro, I got behind a bit but very helpful!
[15:52] <lazyPower> noise][: we're available in #juju here on freenode to answer any questions you may have.
[15:53] <noise][> awesome, I'm going to finish working through the python example shortly
[15:53] <lazyPower> http://pythonhosted.org/charmhelpers/
[15:53] <cory_fu> Also: https://juju.ubuntu.com/docs/
[15:56] <larrymi2> thank you!
[15:56] <lazyPower> it was our pleasure larrymi2
[17:57] <mbruzek1> If you want to join the Juju Testing conversation please go here https://plus.google.com/hangouts/_/hoaevent/AP36tYekk8djMgop1pzFddjyTDy7plhXOwcKYregkciGjHoVC0aAXQ?authuser=0&hl=en
[17:58] <mbruzek1> Our next UOS session starts soon
[18:02] <mbruzek1> https://juju.ubuntu.com/docs/authors-charm-policy.html
[18:02] <mbruzek1> We are talking about Charm Store Policy right now
[18:03] <mbruzek1> Amulet:  https://juju.ubuntu.com/docs/tools-amulet.html
[18:04] <mbruzek1> Bundletester:  https://github.com/juju-solutions/bundletester
[18:06] <sparkiegeek> lazyPower: can't see your screen, Tim has "focus"
[18:06] <mbruzek1> bundletester repository
[18:06] <mbruzek1> https://github.com/juju-solutions/bundletester
[18:08] <dpb1> mbruzek1: can you change the focus over to lazypower?
[18:08] <jamestunnicliffe> ^^
[18:08] <sparkiegeek> +1
[18:08] <mbruzek1> Thank you
[18:08] <mbruzek1> Sorry about that
[18:09] <mbruzek1> apt-get install python-pip juju charm-tools python-devel
[18:10] <sparkiegeek> why not juju deploy bundletester ?
[18:10] <tvansteenburgh> it's not a charm
[18:10] <mbruzek1> It is not a charm, it is a testing framework
[18:11] <mbruzek1> Good question sparkiegeek, we hope to have it bundled with juju as Josh S. mentioned
[18:11] <mbruzek1> in the near future.
[18:11] <sparkiegeek> mbruzek1: sounds good
[18:14] <sparkiegeek> it's impossible to see what lazyPower is typing because the heads cover up the bottom of the terminal screen
[18:15] <sparkiegeek> that's better, thanks!
[18:15] <cory_fu> Not just the top, also the bottom, which is an issue when issuing commands on the command-line
[18:15] <dpb1> mbruzek1: also the pictures of who is in the hangout cover up the command line
[18:16] <mbruzek1> dpb1: OK I will try to address that
[18:16] <dpb1> mbruzek1: thx.  understand it's hard to adjust things.
[18:16] <sparkiegeek> perhaps larger font size would help
[18:19] <dpb1> oh, cool. thanks for doing that tvansteenburgh
[18:19] <tvansteenburgh> \o/
[18:23] <dpb1> can bundletester work on an already bootstrapped environment?
[18:23] <mbruzek1> yes absoltely
[18:23] <mbruzek1> It runs faster
[18:23] <dpb1> does each test tear down and build back up the environment like on juju-test, or is that pretty much obsolete now?
[18:24] <sparkiegeek> what are the guidelines about when you put tests into a separate tests/XX-my-test file vs. many in one ?
[18:24] <tvansteenburgh> it resets the env between each test
[18:24] <tvansteenburgh> much faster than destroy/rebootstrap between each test
[18:26] <dpb1> Q: Is the name 'bundletester' is a bit misleading?  Is it for testing individual charms, as well as bundles?
[18:27] <sparkiegeek> thank you
[18:28]  * sparkiegeek guesses mojo
[18:28] <dpb1> tvansteenburgh: I think it's fine, just threw me a bit.  thanks
[18:28] <dpb1> since bundle is like a superset I can see where you are going
[18:29] <tvansteenburgh> http://reports.vapour.ws/charm-tests-by-charm
[18:29] <dpb1> mbruzek1: actually, if charles would just do export PS1='$ ' and could live without the fancy prompt, it would be better.
[18:30] <sparkiegeek> dpb1: +1
[18:30] <tvansteenburgh> https://github.com/juju-solutions/charmguardian
[18:31] <dpb1> mind blown. j/k
[18:31] <sparkiegeek> dpb1: your MP is quoted in the README.md of that project :)
[18:31] <tvansteenburgh> haha
[18:32] <dpb1> sparkiegeek: :)
[18:32] <dpb1> tvansteenburgh: this is quite nice, thanks for doing all this
[18:32] <sparkiegeek> the #! has to be at the top
[18:32] <sparkiegeek> (looks like you fixed it)
[18:33] <dpb1> Q: can the results of those bundle tests be appended to the MP, right now are they just emailed?
[18:33] <tvansteenburgh> dpb1: thanks, it's been fun. still lots to do too!
[18:33] <tvansteenburgh> dpb1: doesn't it post a link to the results on the MP?
[18:33] <JoshStrobl> I didn't realize test creation is so easy. Makes me ashamed that I haven't done it for my charms yet.
[18:34] <tvansteenburgh> a recent blog post on Juju testing: http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html
[18:34] <dpb1> tvansteenburgh: I'm checking that
[18:35] <dpb1> tvansteenburgh: for instance: https://code.launchpad.net/~brad-marshall/charms/trusty/nrpe-external-master/fix-rsyncd-conf/+merge/241482
[18:38] <tvansteenburgh> dpb1: in the review queue/auto-testing integration still needs work
[18:38] <tvansteenburgh> s/in//
[18:38] <sparkiegeek> tvansteenburgh: awesome! So the unit name that appears to relations is "normal"?
[18:38] <tvansteenburgh> yes
[18:38] <dpb1> tvansteenburgh: that is fine, looking forward to more in that area.  thanks.
[18:38] <tvansteenburgh> no more cruft
[18:38] <sparkiegeek> tvansteenburgh: tried using amulet before to test a charm that related to PostgreSQL and it was impossible
[18:40] <dpb1> yes, creating the shim was always a problem for me to, big +1 on that change (as I said before).
[18:40] <sparkiegeek> http://upload.wikimedia.org/wikipedia/commons/0/04/Potato_salad_with_egg_and_mayonnaise.jpg
[18:40] <sparkiegeek> ^^ potato salad for lazyPower
[18:42]  * dpb1 is strangely hungry
[18:42] <sparkiegeek> well you'll now get a test error instead of a test failure
[18:42] <sparkiegeek> I assume bundletester distinguishes between them?
[18:46] <tvansteenburgh> not really, exit code 0 = pass, other = fail
[18:48] <sparkiegeek> ack
[18:49] <dpb1> tvansteenburgh: does it also run unit tests?
[18:49] <dpb1> tvansteenburgh: or is that a totally separate topic
[18:49] <tvansteenburgh> yep, just put them behind a `make test` target
[18:49] <dpb1> ok
[18:49] <dpb1> great, thought it did
[18:50] <sparkiegeek> can you go over again what the technique is for getting *this* charm in amulet and not the one that's in the store?
[18:50]  * dpb1 would like to see that too
[18:50] <sparkiegeek> is it just cs:XYZ for store ones? and XYZ for local?
[18:51] <JoshStrobl> sparkiegeek, yes
[18:51] <JoshStrobl> that is my understanding as well
[18:51] <sparkiegeek> hmmm
[18:52] <sparkiegeek> so if I have a bzr branch of XYZ called "XYZ-fix-bug-123" then all my tests will break?
[18:52] <sparkiegeek> (as in my directory name isn't the same as the charm name)
[18:52] <tvansteenburgh> sparkiegeek: correct
[18:52] <dpb1> I thought it redirected to the locally checked out branch
[18:52] <dpb1> wherever you are running things from
[18:52] <sparkiegeek> tvansteenburgh: ok, cheers
[18:53] <tvansteenburgh> it would be better to check out the branch into a dir with a name that matches the charm
[18:53] <dpb1> ok
[18:53] <sparkiegeek> juju sure loves its directory names
[18:53] <tvansteenburgh> heh,  yeah :?
[18:54] <sparkiegeek> if only there was a metadata file with the name in it, oh wait :)
[18:54]  * sparkiegeek files bug
[18:54] <dpb1> link and I'll +1
[18:54] <tvansteenburgh> sparkiegeek: really good point there
[18:54] <mbruzek1> https://juju.ubuntu.com/docs/tools-amulet.html
[18:54] <tvansteenburgh> sparkiegeek: you file it, i'll fix it
[18:55] <dpb1> tvansteenburgh: nice attitude. :)
[18:57] <sparkiegeek> dpb1: tvansteenburgh: https://github.com/marcoceppi/amulet/issues/50
[18:57] <tvansteenburgh> sparkiegeek: thank you!
[18:58] <dpb1> thx sparkiegeek, nice catch
[18:58]  * JoshStrobl goes and makes dinner
[19:00] <sparkiegeek> tvansteenburgh: FWIW looks like i could run the tests with JUJU_TEST_CHARM environment variable set and that'd do similar thing
[19:00] <tvansteenburgh> sparkiegeek: yep, forgot about that :)
[19:03] <mbruzek1> http://pythonhosted.org/charmhelpers/
[19:03] <mbruzek1> https://juju.ubuntu.com/docs/tools-charm-helpers.html
[19:04] <lazyPower> http://pythonhosted.org/charmhelpers/
[19:04] <lazyPower> just to re-iterate :)
[19:14] <avoine> QUESTION: why  charmhelper is not a debian package?
[19:15] <whit> avoine, it's in flux and when it settles down, we will likely make it a deb
[19:16] <whit> right now, most f us typically use pip to pull it in
[19:17]  * whit notes that releasing to a ppa would be sensible for ch
[19:18] <avoine> ok
[19:21] <whit> avoine, right now charm helpers encompasses a broad number of concerns which need to eventually be broken into their packages
[19:22] <whit> ^ own
[19:28] <avoine> ok, the main reason I asked is because updating charmhelper makes charm MP really big and make it a package would make merge lighter
[19:28] <tvansteenburgh> avoine: totally agree
[19:29] <whit> yup
[19:29] <cory_fu> Completely agree.  As whit mentioned, `pip install charmhelpers` is currently my preferred way around that
[19:29] <whit> remember also you can peg ch to a revision or pull it from bzr with pip