[01:04] <highvoltage> I have a package that used to use debconf, but it doesn't anymore.
[01:05] <highvoltage> It now uses the minimal rules file from dh7, but it still runs dh_installdebconf
[01:05] <highvoltage> how would I disable that?
[01:10] <highvoltage> ah, I still had a .templates file
[01:12] <maxwellian> highvoltage wins! :)
[01:12] <highvoltage> :)
[08:46] <and471> I am having trouble getting a pbuilder environment working
[08:46] <and471> I run sudo pbuilder create
[08:46] <and471> but it doesn't seem to finish correctly
[09:03] <geser> do you have an error message?
[09:14] <and471> geser, http://pastebin.ubuntu.com/471765/
[09:14] <and471> geser, sorry it took me so long, I didn't realise there was a response
[09:23] <and471> if an upstream has a .svn or .bzr directory, do I delete this before creating the orig.tar.gz or leave it there?
[09:27] <wgrant> and471: Why are you creating the orig.tar.gz? Does upstream not provide a tarball?
[09:36] <and471> wgrant, no I have to obtain it from a bzr branch
[09:39] <geser> and471: why not use "bzr export" to obtain a tar?
[09:40] <and471> geser, becuase I didn't know about that command :)
[09:40] <and471> geser, wgrant, thanks
[09:40] <and471> geser, did you have any luck with that log?
[09:41] <geser> and471: sorry no, I remember seeing that error in the past but don't remember the solution for it
[09:43] <and471> geser, no problem
[09:43] <and471> can anyone else help me? I am trying to create a pbuilder environment but I keep getting the error on the log http://pastebin.ubuntu.com/471765/
[09:44] <wgrant> and471: What is the host operating system?
[09:45] <and471> wgrant, ubuntu lucid
[09:45] <wgrant> and471: bzr export is pretty convenient. You can just say 'bzr export ../PROJECT-VERSION.tar.gz', and it will create the tarball for you.
[09:45] <wgrant> Not very well known :(
[09:45] <wgrant> and471: Hm. Using a stock Ubuntu kernel?
[09:45] <and471> wgrant, I think so, let me check...
[09:46] <and471> wgrant, 2.6.32-22-generic
[09:48] <wgrant> and471: Hmm. No idea, sorry.
[09:49] <and471> np
[15:15] <freeflyi1g> hi all, can we upload new package to universe directly now?
[15:22] <shadeslayer> freeflying: are you MOTU?
[15:22] <freeflying> shadeslayer: yes
[15:22] <shadeslayer> hmm well .. i would guess you need to go through revu
[15:23] <shadeslayer> freeflying: also can you sponsor a upload ? :D
[15:23] <shadeslayer> webkitkde from https://edge.launchpad.net/~rohangarg/+archive/experimental/+packages
[15:23] <shadeslayer> ( after its done building :P )
[15:24] <freeflying> shadeslayer: I'm not sure about the exact process now, so no idea
[15:25] <shadeslayer> freeflying: errr.. whut?
[15:25] <shadeslayer> regarding revu?
[15:26] <freeflying> shadeslayer: rearding with revu, we still need to adovates?
[15:26] <shadeslayer> yeah afaik
[15:26] <freeflying> shadeslayer: I remember we can do upload directly, right?
[15:26] <shadeslayer> well.. im not entirely sure...
[15:26] <shadeslayer> but id rather go through revu
[15:27] <shadeslayer> ( for a new package )
[15:27] <shadeslayer> always better to get more eyes looking at a package
[15:28] <freeflying> shadeslayer: what I'm trying to sponsor is a package made by a DD, and meanwhile he has contributed a lot to ubuntu
[15:28] <shadeslayer> ah
[15:28] <shadeslayer> freeflying: so the package is already in debian?
[15:28] <freeflying> shadeslayer: so he is familiar with both the policy of ubuntu and debian
[15:28] <freeflying> shadeslayer: not yet
[15:28] <shadeslayer> freeflying: then i would advise : upload to debian > sync/merge to ubuntu
[15:29] <shadeslayer> since he is a DD .. that should be easy
[15:29] <freeflying> shadeslayer: its kindly a ubuntu specific package
[15:29] <shadeslayer> oh.. hmm.. no idea then how to proceed :P
[15:29] <freeflying> shadeslayer: normally, we prefer to have it in debian firstly
[15:29] <shadeslayer> yep
[15:30] <shadeslayer> but we do have local packages as well
[15:30] <shadeslayer> ( local as in, only in ubuntu )
[15:30] <freeflying> ic
[15:30] <freeflying> shadeslayer: anyway, appreciate your suggestions
[15:31] <shadeslayer> :)
[15:31] <shadeslayer> not many people around since its a weekend
[15:32] <freeflying> shadeslayer: yes
[15:34] <shadeslayer> freeflying: will you sponsor my package? :)
[15:35] <freeflying> shadeslayer: depends on whether can I upload it directly :)
[15:35] <shadeslayer> brr... stupid thing will take 30 mins to build :S
[15:36] <shadeslayer> freeflying: yeah.. it already is in ubuntu
[15:36] <freeflying> shadeslayer: then I'd like :)
[15:47] <geser> freeflying: Given that REVU has almost no reviewers, a DD created the package and you also looked at it, you could probably upload it directly.
[16:01] <shadeslayer> freeflying: thanks :D
[16:12] <shadeslayer> freeflying: amd64 is building : https://edge.launchpad.net/~rohangarg/+archive/experimental/+build/1899551 : should finish in 20 mins :)
[16:37] <bdrung_> shadeslayer: the rule is that 2 MOTU have to review the package. if a MOTU creates a package, another MOTU has to check (1 + 1 = 2) before the upload
[16:51] <tumbleweed> bdrung_: oh, btw I gave grab-udd-merge some love today. How's your debdiff review tool coming along?
[16:52] <bdrung_> tumbleweed: it's on its way
[16:52] <bdrung_> tumbleweed: i already sponsored two SRU requests
[16:53] <bdrung_> tumbleweed: currently it supports only debdiffs - the normal diff support is the biggest part that is missing
[16:53] <tumbleweed> aah. That shouldn't be too hard to add, though
[16:53] <bdrung_> tumbleweed: btw, do you have time to sponsor bug #553328?
[16:55] <tumbleweed> bdrung_: not being a core dev, all I can do is review
[16:55] <bdrung_> tumbleweed: k, then i have to do it
[16:58] <bdrung_> tumbleweed: the biggest problem that needs to be fixed, before i can upload the script is the name of the script
[16:59] <bdrung_> some ideas: sponsor-patch, review-patch, review, sponsor
[16:59] <tumbleweed> I guess that depends how much scope it covers
[16:59] <bdrung_> the basic feature: take a patch or debdiff, create a package, and upload it somewhere
[17:00] <tumbleweed> sponsor-patch sounds good
[17:00] <tumbleweed> although sponsor-patch does sound patch-only rather than debdiff
[17:01] <bdrung_> some use cases: sponsor debdiffs (ubuntu-sponsors), upload patches to a PPA (ubuntu-reviewers)
[17:01] <micahg> bdrung_: how about sponsor-foo
[17:01] <micahg> bdrung_: or even sponsor-fu :)
[17:02] <bdrung_> micahg: that's a combination of foo and sponsor-patch :D
[17:02] <bdrung_> tumbleweed: a debdiff is technically a patch
[17:03] <bdrung_> mv foo sponsor-patch
[17:03] <shadeslayer> bdrung_: ah ok
[17:04] <bdrung_> micahg: sponsor-fu sounds nice, but sponsor-patch is more descriptive
[17:04] <shadeslayer> can someone sponsor my package tho?
[17:04] <tumbleweed> bdrung_: yes it is, although in Debian/Ubuntu when we say patch, we often mean an upstream-source patch without a new changelog entries
[17:05] <shadeslayer> webkitkde
[17:05] <shadeslayer> from https://edge.launchpad.net/~rohangarg/+archive/experimental
[17:05] <bdrung_> tumbleweed: that'll be supported, too
[17:06] <tumbleweed> yes, it works. Hell, grab-udd-merge doesn't sound like a reviewing tool, but that was my main aim for writing it :)
[17:07] <bdrung_> tumbleweed: 6 FIXME remaining
[17:07] <micahg> shadeslayer: already a package with that name in archive
[17:07] <shadeslayer> micahg: its a update to that
[17:08] <shadeslayer> the one in the archive is a svn checkout
[17:08] <bdrung_> shadeslayer: then prepare a debdiff
[17:08] <shadeslayer> whereas the one i have is a new upstream release
[17:08] <shadeslayer> bdrung_: itll be huge ;)
[17:08] <shadeslayer> so i have a diff of the old packaging vs new packaging
[17:09] <bdrung_> shadeslayer: in this case upload it somewhere
[17:09] <micahg> shadeslayer: why not get in debian first?
[17:09] <shadeslayer> bdrung_: its in my pap
[17:09] <shadeslayer> *ppa
[17:09] <bdrung_> REVU was designed for new packages
[17:09] <shadeslayer> micahg: hmm.. well i can.. but itll take time.. since i have to make a sbuilder first
[17:09] <bdrung_> shadeslayer: the 2 MOTU rule applies to new packages (not new upstream releases)
[17:09] <shadeslayer> bdrung_: i know
[17:09] <shadeslayer> its not a new package
[17:10] <micahg> which is why I mentioned existing source as well :)
[17:10] <shadeslayer> freeflying was asking about new packages
[17:10] <shadeslayer> not me :)
[17:10] <shadeslayer> oh this is a mess :P
[17:10] <shadeslayer> ok look... we have https://launchpad.net/ubuntu/+source/webkitkde
[17:11] <micahg> shadeslayer: a release was done last month in debian, so I think the maintainer is active, you might want to file an update request there with any patches for the packaging
[17:11] <shadeslayer> and i packaged  a update to that https://edge.launchpad.net/~rohangarg/+archive/experimental
[17:12] <shadeslayer> micahg: err.. i cant find webkitkde on p.d.o
[17:12] <shadeslayer> ah nvm
[17:12] <micahg> shadeslayer: http://packages.qa.debian.org/w/webkitkde.html
[17:12] <shadeslayer> google++
[17:13] <shadeslayer> hmm i need a sbuilder now...
[17:16] <shadeslayer> micahg: any idea how i can specify a certain release.gpg file to sbuilder?
[17:17] <micahg> shadeslayer: sorry, I use pbuilder
[17:17] <bdrung_> o/ pbuilder user
[17:18] <shadeslayer> well.... my sponsor asks for sbuild build logs :)
[17:26] <bdrung_> shadeslayer: there is no big difference between sbuild and pbuilder. your sponsor may be happy with a pbuilder log
[17:26] <shadeslayer> ok :)
[17:27] <bdrung_> tumbleweed: http://paste.debian.net/81976/
[17:27] <bdrung_> shadeslayer: he probably wants a log from a build in a safe environment
[17:28] <shadeslayer> bdrung_: im also poking cmot.. who is the original maintainer of the package
[17:28] <shadeslayer> this will take some time...i have to do some other work as well
[17:30] <bdrung_> tumbleweed: this is the current state
[17:31] <tumbleweed> bdrung_: thanks, will play with it
[17:33] <bdrung_> how can i compare if two patches are identical (the meta data may differ)?
[17:35] <tumbleweed> parse and normalise out the metadata? (i.e. strip timestamps, sort files and hunks)
[17:36] <tumbleweed> filterdiff can do some normalisation
[17:37] <tumbleweed> bdrung_: intending to support merges from debian?
[17:37] <bdrung_> tumbleweed: yes
[17:38] <bdrung_> tumbleweed: once i worked through the SRU list, i will add merge support
[17:38] <tumbleweed> cool
[17:39] <bdrung_> tumbleweed: in the end it should be able to sponsor everything except syncs (which ack-sync does)
[17:40] <tumbleweed> including bzr workflows?
[17:41] <bdrung_> tumbleweed: i didn't look into that, but it shouldn't be that hard to add it
[18:02] <ari-tczew> TheMuso: bug 612127 updated
[19:31] <vish> hmm , is it allowed to use  ’ instead of ' in debian/control?
[19:32] <micahg> vish: in what context?
[19:32] <vish> for "you’re"
[19:33] <micahg> vish: ?
[19:33] <tumbleweed> I'm imagining description
[19:33] <vish> micahg: oh , in the description of the package
[19:33] <micahg> vish: why not?
[19:34] <vish> micahg: yeah , i was just checking, not sure that why asked :)
[19:34] <tumbleweed> it should probably be ASCII, unless UTF-8 is actually needed, but it *is* allowed
[19:34] <micahg> vish: do you have the whole context?
[19:34] <vish> micahg: the debdiff > http://launchpadlibrarian.net/52831364/abuse-sdl_0.7.1-1ubuntu1.debdiff
[19:35] <vish> it showed up as "If youâ€™re one to get easily addicted"
[19:35] <micahg> vish: yeah, that should be an apostrophe
[19:35] <micahg> someone's editor might have made it something else
[19:36] <stalcup> vish: why not use "you are"?
[19:37] <micahg> vish: that should go through Debian though
[19:37] <vish> stalcup: well , we can use but it is usually shortened as you're , hence used it.
[19:37] <tumbleweed> that looks like it's correct UTF8, but it shows up incorrectly in a web-browser
[19:38] <vish> tumbleweed: micahg: cool! thanks , it didnt give any problems locally  , but it was weird seeing it in the browser :)
[19:38] <stalcup> okay, it is your choice afterall
[19:38] <stalcup> :)
[19:38] <tumbleweed> vish: if it were me, i'd change it to a '
[19:38] <Laney> Control files are *required* to be utf8
[19:39] <vish> hmm.. righto.. changing it.. :)
[19:39] <Laney> there's no reason to change it. Try running isutf8 from moreutils on the file and see if it's valid
[19:40] <micahg> vish: make sure to update the debdiff in debian :)
[19:41] <tumbleweed> Laney: there's no strong reason. But I live by the rule that source code should be ASCII unless it has a good reason not to be. i.e. not for a single character
[19:41] <vish> micahg: i wrote that.. not yet uploaded anywhere.  or did you mean send that to debian too , if so , yup sent it :)
[19:42] <micahg> vish: yeah, I saw it attached to a debian bug, just reminding you to update the debdiff for the apostrophe :0
[19:42] <jpds> ☺
[19:45] <Laney> That seems like a very bizarre requirement
[19:50] <stalcup> ohmy
[19:54] <crimsun> interesting: http://www.frogatto.com/about
[20:35] <micahg> archive builders are basically empty, good time to sponsor :)
[20:36] <crimsun> whittling away at the patch queue
[20:37] <Laney> I wonder why darcs FTBFS
[20:37] <Laney> builds just fine locally :(
[20:38] <crimsun> I've run into a lot of those lately on the i386 buildds
[20:39] <crimsun> a couple are scons-related (ugh), though
[20:39] <Laney> http://launchpadlibrarian.net/52801546/buildlog_ubuntu-maverick-i386.darcs_2.4.4-1_FAILEDTOBUILD.txt.gz
[20:39] <X3> scones with sugar on top
[20:39] <Laney> it just hangs at the test suite
[20:39] <Laney> seems fairly inexplicable to me
[20:42] <X3> seems I see lots of version errors
[20:42] <X3> src/Darcs/External.hs:37:36:
[20:42] <X3> Warning: In the use of `try'
[20:42] <X3> (imported from Control.Exception, but defined in base:Control.OldException):
[20:42] <X3> Deprecated: "Future versions of base will not support the old exceptions style. Please switch to extensible exceptions."
[20:42] <Laney> shouldn't matter
[20:42] <X3> idk
[20:42] <Laney> warnings, not errors
[20:43] <micahg> does anyone remember an ML post about .la files going away?
[20:43] <Laney> it worked on amd64, and locally on i386
[20:45] <Laney> and on Debian, of course
[20:46] <X3> Checking for already installed source dependencies...
[20:46] <X3> debhelper: missing
[20:46] <X3> etc etc
[20:46] <tumbleweed> micahg: debian policy 3.9.1
[20:47] <micahg> tumbleweed: is that where I saw it?
[20:47] <Laney> X3: I think you are misinterpreting the build log, I'm afraid
[20:47] <tumbleweed> well, I remember seeing it, and that's all I can find :)
[20:47] <X3> Build started at 20100731-2304 downfrom here seems bad
[20:47] <X3> darcs_2.4.4-1.dsc exists in cwd
[20:47] <X3> sh: gcc: not found
[20:48] <X3> and below is worst
[20:48] <micahg> tumbleweed: ah, thanks, so, is it a regression is a package stopped shipping those?
[20:49] <X3> though idk if that a reason for it to fail, just pointing at it
[20:49] <Laney> yeah that is interesting
[20:49] <X3> prolly
[20:50]  * X3 goes away
[20:50] <Laney> but gcc is in build-essential
[20:52] <tumbleweed> micahg: as I read it, only if another package needs them for it's own .la files. But I don't have any experience with that issue myself
[20:52] <micahg> tumbleweed: k, thansk
[20:57] <Laney> and it even does get installed
[20:57] <Laney> whatever could be going on here? :(
[20:58] <tumbleweed> there was a new gcc-4.5 last night, causing some dependancy issues in my pbuilders
[20:59] <Laney> happened before yesterday
[20:59] <tumbleweed> I assume it's sorted out (waiting for my mirror to sync)
[20:59] <Laney> even successful builds have this though: http://launchpadlibrarian.net/52685301/buildlog_ubuntu-maverick-i386.smuxi_<IP_ADDRESS>-1_FULLYBUILT.txt.gz
[21:40] <lucas> can we create teams on launchpad and automatically get an associated public mailing list?
[21:40] <lucas> or are mailing lists still managed separately?
[21:40] <lucas> (still *only* managed separately)
[21:40] <Laney> I don't know about automatically, but teams can have MLs now
[21:40] <lucas> ok, good
[21:40] <Laney> (→ #launchpad)
[21:40] <james_w> lucas: no, you can do that, but it requires that everyone that wants to subscribe join the team
[21:41] <lucas> that would be fine. it would be a "process sync requests for DDs" team.
[21:45] <lucas> is there a reason why --lp isn't the default for requestsync?
[21:45] <micahg> does it still require launchpadlib setup?
[21:45] <lucas> likely, but it's so much user-friendly
[21:46] <tumbleweed> yes, but the manpage tells you exactly what to do. (we assume ubuntu developers can read manpages)
[21:46] <geser> micahg: afaik yes as I don't remember any changes regarding this
[21:46] <micahg> lucas: my guess is that's why --lp isn't default then ^^
[21:47] <tumbleweed> micahg: the alternative is to have a mail set up, right?
[21:47] <geser> lucas: as the --lp option got introduced some persons mentioned that they preferred email as standard and as nobody proposed to changed that it didn't get changed yet
[21:48] <geser> tumbleweed: an open port 25 into the internet is enough
[21:48] <tumbleweed> lucas: where's the delay with sync requests for DDs? It's rare to see sync requests on the sponsor queue for more than a day or two. (but ACKed requests can take a while to be processed)
[21:48] <lucas> tumbleweed: well, it was to propose a solution for people who don't want to create an LP account
[21:48] <lucas> and also, to have a requestsync that does the right thing by default ;)
[21:49] <lucas> my proposal would be:
[21:49] <tumbleweed> geser: ok, I assumed it required a mailserver, so I used --lp from day 1
[21:49] <lucas> - document requestsync for people who have a LP account (preferably with --lp)
[21:49] <lucas> - have a team that can forward the requests for others
[21:57] <geser> lucas: do you know how much demand for such a team exists? (to forward sync requests from persons who don't want a LP account)
[21:58] <lucas> I don't know, I just want to have a fallback solution ready in case people complain about the requirement to create an account on LP
[21:58] <lucas> (which I could understand)
[22:01]  * tumbleweed handles sync requests from a debian sponsor of mine (who has an LP account but isn't interested in learning ubuntu procedures)
[22:16] <Rhonda> hmm.
[22:16] <Rhonda> I just uploaded pgadmin3 to Debian - how long should I wait for doing the syncrequest? It's a bugfix release, and it potential fixes some of the launchpad bugs.
[22:17] <crimsun> as soon as it appears in incoming, it's fair game ;)
[22:18] <Laney> even before that
[22:18] <Laney> as soon as you have the dsc :)
[22:18] <Rhonda> *blinks* :)
[22:19] <Rhonda> I have the dsc even before I uploaded it to Debian. :)
[22:19] <Laney> indeed
[22:19] <Laney> if you so wished, you could upload that
[22:19]  * hyperair dangles syncpackage in front of Rhonda
[22:19] <Rhonda> syncpackage? Not requestsync?
[22:19] <Laney> but really I'd wait until rmadison knows about it and file a normal sync request
[22:19] <Laney> unless you can't wait for some reason
[22:20] <Laney> syncpackage is a script to upload syncs yourself
[22:20] <crimsun> why isn't syncpackage in lucid-* ? :/
[22:20] <Rhonda> I definitely can wait as long as maverick can wait (and it can AIUI). :)
[22:20] <Rhonda> syncpackage is in squeeze :P
[22:20] <Laney> crimsun: isn't it in ubuntu-dev-tools/lucid?
[22:21] <crimsun> Laney: not that I can find
[22:21] <Laney> it's reasonably new, could be post-lucid
[22:21] <Laney> bzr branch lp:ubuntu-dev-tools
[22:21] <geser> no, syncpackage was left out on purpose from u-d-t on lucid
[22:22] <hyperair> Laney: ubuntu-dev-tools in maverick has it.
[22:22] <Laney> I know
[22:22] <Laney> used it just today
[22:22] <crimsun> bah, I'm running lucid for hysterical raisins
 pgadmin3 1.10.5-1 uploaded by Gerfried Fuchs<EMAIL_ADDRESS>[22:22]  * hyperair has had it in ~/bin since before u-d-t had it
[22:22] <Rhonda> So incoming has it. :P
[22:22] <Laney> yeah I had pitti's version too
[22:23] <hyperair> Rhonda: so syncpackage and dput it. =D
[22:23] <Laney> Rhonda: requestsync won't let you do it until dinstall has grabbed it
[22:23] <Laney> urgh, why?
[22:23] <crimsun> as someone who has broken the archive before, I'm a bit hesitant to run stuff like it :p
[22:23] <Laney> I really think that should only be for the non-default urgent case
[22:23] <hyperair> hmm? break the archive how?
[22:23] <Rhonda> hyperair: Too much of a burden me thinks. ;)
[22:23] <hyperair> haha
[22:24] <crimsun> hyperair: I broke gcc for all 64-bit arches via an alsa-lib upload many releases ago.
[22:24] <geser> syncpackage is still in some "gray" area as the AA didn't say if it's okay to use it or not, there is a preference though to have it directly in LP
[22:24] <hyperair> crimsun: wait, how does gcc break on an alsa-lib upload?
[22:24] <crimsun> hyperair: a combination of lib32 hilarity on both packages
[22:25] <Laney> In general I wonder what the big rush is :)
[22:25] <hyperair> crimsun: eh, but how is that caused by syncpackage?
[22:25] <crimsun> hyperair: it isn't related at all. I'm referring to my hesitation to run syncpackage for that reason.
[22:26] <geser> Laney: I guess everybody is warming up for late uploads before FF on Aug 12th :)
[22:26] <hyperair> @_@
[22:30] <ari-tczew> what about sponsorship for patches attached before FF?
[22:31] <ari-tczew> I mean about situation when I'll prepare a patch and it will stay in sponsors-queue till FF and it won't be sponsored.
[22:31] <hyperair> you'll just have to get desperate and ping people.
[22:32] <ari-tczew> no, I won't prepare FFe. Patches atatched before Aug 12th should be sponsored without FFe.
[22:32] <hyperair> ari-tczew: the deadline is there for testing purposes. it has to enter the archive, with time for new bugs to be found and fixed before archive.
[22:32] <hyperair> i mean before release.
[22:33] <hyperair> i'm sorry, but i won't sponsor anything that is not a bugfix upload post-FF without FFe approval.
[22:34] <Laney> you should account for such delays when preparing uploads
[22:34] <ari-tczew> hyperair: so if I'll prepare a patch for merge Aug 11th and my patch won't be sponsored (late) do I have to prepare FFe?
[22:35] <hyperair> ari-tczew: if it requires it, yes.
[22:35] <ari-tczew> I mean about main component mainly.
[22:35] <hyperair> even more so.
[22:36] <ari-tczew> ok, 1-2 days before FF are too late, I could understand. But if I'll prepare a patch 5 days before FF and my patch won't be sponsored till FF, I won't prepare FF.
[22:36] <ari-tczew> ...prepare FFe
[22:37] <hyperair> then your patch won't get sponsored until the next release.
[22:37] <iulian> Why not?
[22:37] <hyperair> unless someone else prepares FFe for you.
[22:37] <iulian> ari-tczew: ^
[22:38] <hyperair> because he's missing the entire point of having a FF.
[22:38] <ari-tczew> iulian: sorry, I'll prepare a patch during before FF time.
[22:40] <iulian> ari-tczew: So when we enter Feature Freeze, you stop making patches?
[22:40] <iulian> Just because we're in FF?
[22:41] <ari-tczew> iulian: listen, now I prepare merges. Not every merge will fix any bug. I won't got time for looking merges which could fix bugs.
[22:42] <tumbleweed> my feeling is: your bugs awaiting sponnsorship are still. If Build-dependancies change incompatibly, or a newer version appears in debian, or Ubuntu enters FF, etc. you need to fix it. If you wait for a sponsor to tell you that and reject it, you are just wasting a sponsors time.
[22:42] <tumbleweed> "...are still your bugs"
[22:42] <ari-tczew> and FFe takes more time
[22:43] <tumbleweed> you can take that attitude, but it won't help get your requests approved
[22:44] <ari-tczew> tumbleweed: in my opinion should be following: all requests filled before FF should be sponsored even during FF, because they are prepared on time.
[22:45] <tumbleweed> ari-tczew: there are requests in the sponsorship queue that were filed before maverick development started
[22:45] <tumbleweed> we don't go merging those during feature freeze
[22:47] <tumbleweed> yeah, it's a pain when FF rolls around and you have things in the queue. If you want to be sure that you don't run into issues, start adding FFes. If you want to take the risk of them not being accepted, don't.
[22:49] <ari-tczew> tumbleweed: I see no reason for prepare FFe request if merge doesn't fix any important bug.
[22:51] <tumbleweed> fair enough
[22:52] <ari-tczew> iulian: even I stop making patches during FF, what does it matter?
[22:54] <iulian> ari-tczew: It's up to you.
[22:59] <ari-tczew> iulian: I don't understand. Please say directly what do you think.
[23:03] <iulian> I think that you should not stop making patches during FF.
[23:07] <ari-tczew> iulian: why?
[23:08] <iulian> Because they might be important for us.
[23:08] <pablohof> hi, i'm building a package where i need to restart apache after processing python-support triggers, but postinst is called before. any idea if this is possible and how to do it ?
[23:09] <micahg> ari-tczew: you might just want to get the FFe first, before doing teh work if one is required
[23:11] <ari-tczew> micahg: you mean about doing work 1-2 days before FF right?
[23:11] <micahg> ari-tczew: I was actually talking about after FF, but that might work too
[23:12] <ari-tczew> iulian: how does it compare to my motu application?
[23:22] <ari-tczew> iulian: do you think that if I don't make patches during FF, I'm useless member?
[23:23] <ari-tczew> come on, just say
[23:25] <hyperair> ari-tczew: patches are made as necessary. otherwise i'm a useless MOTU.
[23:26] <ari-tczew> hyperair: congrats
[23:26] <hyperair> why, thank you.
[23:26] <micahg> hyperair: so, do think that sqlite issue is sqlite based or banshee based?
[23:27] <hyperair> micahg: i'm tempted to say sqlite, but i haven't heard about any sqlite regression with any other application.
[23:27] <hyperair> micahg: so it could be just the way banshee uses sqlite.
[23:28] <hyperair> perhaps banshee uses sqlite in a way that wasn't intended. or perhaps banshee uses sqlite in a way that exposes a bug in sqlite.
[23:28]  * hyperair shrugs
[23:28] <hyperair> it's really hard to tell.
[23:28] <micahg> hyperair: right, I haven't seen anything else either, I'll keep an eye on sqlite, have you checked b.g.o for other issues?
[23:29] <hyperair> micahg: nope.
[23:29]  * hyperair checks
[23:30]  * Laney is generating comparative logs
[23:30] <hyperair> Laney: thanks, that would be useful.
[23:31] <Laney> whichever one it's on now is seriously lengthy
[23:31] <hyperair> micahg: nothing based on a search for sqlite.
[23:31] <Laney> 65507ms
[23:31] <hyperair> whoa, that's really bad.
[23:31] <hyperair> is it CPU or IO-bound?
[23:31] <Laney> clu
[23:31] <Laney> cpu
[23:31] <hyperair> hmm
[23:32] <hyperair> that makes it even worse.
[23:32] <Laney> It's the DELETE FROM CoreCache queries
[23:33] <hyperair> well, i'm off to go back to sleep. (shouldn't have stared at the computer after waking up for a drink of water)
[23:33] <Laney> seeya
[23:33] <hyperair> Laney: it might be a good idea to consult with people in #sqlite.
[23:33] <hyperair> and yeah, seeya =)
[23:33] <Laney> I'll be going to bed myself in a minute
[23:34] <Laney> will upload logs to the bgo bug, but yeah, tomorrow
[23:35] <micahg> I'll keep an eye on sqlite bugs in case anyone reports other issues
[23:48] <Laney> yeah that is a significant performance hit
[23:49] <micahg> Laney: well, there are already a few bugs scheduled for 3.7.1, so my geuss is it'll be released relatively soon, so if we find out if there's an issue with sqlite, we can get that in too
[23:50] <Laney> micahg: are you seeing it?
[23:50] <micahg> Laney: no, I'm not on maverick yet
[23:50] <micahg> I guess I can backport sqlite and check


[07:03] <dholbach> good morning
[07:03] <fgimenez> good morning
[07:04] <dholbach> hi fgimenez
[08:59] <JamesTait> Good morning all; happy Hug Your Cat Day! 😃
[11:25] <elopio> good morning.
[11:26] <elopio> hey fgimenez: what do you think about the latest version, ready to promote to stable?
[11:27] <fgimenez> elopio, hi, yes, seems good so far
[11:28] <fgimenez> elopio, i'm finishing the script for the complete upgrade path proposed by rsalveti, that will give us more confidence
[11:28] <elopio> fgimenez: nice, thank you.
[12:00] <sergiusens> rsalveti: mind doing a no change rebuild upload of the archive version of 'ubuntu-snappy' to get the powerpc binaries built? It seems we never built them
[12:13] <Chipaca> rsalveti: where was the 15.04.x blueprint?
[12:13] <sergiusens> Chipaca: https://trello.com/c/wxQzJ9uT/18-create-15-04-1-stable-image
[12:13] <rsalveti> sergiusens: wonder if we would need a no change upload
[12:13] <rsalveti> yeah, that's the one
[12:13] <sergiusens> Chipaca: and the bug task i there
[12:13] <rsalveti> sergiusens: since it was copied from vivid
[12:14] <Chipaca> k
[12:14] <rsalveti> https://launchpad.net/snappy/+milestone/15.04.1
[12:14] <rsalveti> as well
[12:14] <sergiusens> rsalveti: yeah, it was copied from a ppa that probably didn't build for powerpc
[12:14] <sergiusens> rsalveti: yeah, I just gave him the parent link ;-)
[12:14] <sergiusens> Chipaca: from the work items, do you know of anything that can be crossed out?
[12:16] <Chipaca> sergiusens: some of them should be landing about now
[12:17] <sergiusens> Chipaca: do you know anything about the backporting ones?
[12:18] <Chipaca> sergiusens: i've jused approved several backporting MPs
[12:18] <Chipaca> s/jused/just/, and by just i mean an hour or so ago
[12:18] <Chipaca> before lunch
[12:18] <sergiusens> Chipaca: these specifically Backport lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls
[12:18] <sergiusens> Chipaca: and yeah, I saw :-)
[12:18] <Chipaca> and mvo's 15.04 moar-errors one could land if he's not going to be around
[12:23] <rsalveti> sergiusens: want to do another release and I can sponsor your upload?
[12:23] <rsalveti> sergiusens: or just a rebuild is fine?
[12:24] <sergiusens> rsalveti: just a rebuild, a release forces a lot of catching up on u-d-f
[12:24] <rsalveti> sergiusens: right, sure
[12:24] <sergiusens> rsalveti: I can confirm in a bit though
[12:25] <sergiusens> to triple check why powerpc isn't there
[12:25] <rsalveti> sure, will wait then
[12:26] <Chipaca> do we need to do anything with bug #1449625 for it to be SRUable?
[12:26] <nothal> Bug #1449625: systemd and bin-path exported variables are not in sync <Snappy:Fix Committed> <Snappy 15.04:Fix Committed> <http://launchpad.net/bugs/1449625>
[12:27] <Chipaca> marked it "done" in the trello, but then thought to ask, because it explicitly says SRU there :)
[12:28] <sergiusens> Chipaca: we should probably SRU everything that's making it into lp:snappy/15.04
[12:28]  * Chipaca marks it "done"
[12:30] <Chipaca> do we really support "upgrading to edge"?
[12:30] <Chipaca> i thought that was a corner case brought about by fiddling with files
[12:30] <rsalveti> edge 15.04 or rolling?
[12:41] <sergiusens> Chipaca: we want to support upgrading to edge when we have proper channels and os/kernel snaps
[12:45] <mterry> sergiusens, you mentioned being able to set up tarmac for ubuntu-core-launcher?  Can you also do it for snapcraft?
[12:47] <sergiusens> mterry: yeah, I saw tedg's request :-)
[12:47] <sergiusens> will do it in a bit
[12:47] <mterry> sergiusens, oh didn't know he asked too  :)
[12:58] <sergiusens> Chipaca: nagging welcome ;-) https://code.launchpad.net/~sergiusens/snappy/YouShallNotPass/+merge/261079
[12:58]  * Chipaca prepares the nag
[13:02] <Chipaca> sergiusens: +1'ed with a nit
[13:04] <sergiusens> Chipaca: nice catch ;-)
[13:04] <Chipaca> sergiusens: which makes me realise
[13:04] <sergiusens> Chipaca: pushed
[13:04] <Chipaca> sergiusens: you're not testing the use of it
[13:05] <sergiusens> uh oh :-P
[13:05] <sergiusens> Chipaca: right! Not the error, which I guess I'll do now
[13:05] <Chipaca> :)
[13:08] <sergiusens> Chipaca: o, now I need interpackage architecture stubbing, yay
[13:08] <Chipaca> ...
[13:09] <Chipaca> no, no you don't
[13:09] <Chipaca> just test with "xyzzy" architecture
[13:09] <Chipaca> that is, in the package, put architectures: foo, bar, baz
[13:09] <Chipaca> but properly ;)
[13:10] <sergiusens> Chipaca: oh, I was going to build a test snap, not test the error only ;-)
[13:10] <Chipaca> sergiusens: you're already testing that you detect the "right" arch in the unit test
[13:10] <Chipaca> sergiusens: you just need to test that you report the error in the integration test
[13:11] <Chipaca> sergiusens: yes, i meant in the package.yaml
[13:11] <sergiusens> Chipaca: right, but I rely on UbuntuArchitecture() which depends on the system where you run the test ;-) That's why I said interpackage :-)
[13:11] <sergiusens> so I'll do what I was going to do ;-)
[13:12] <Chipaca> sergiusens: not sure i follow
[13:13] <sergiusens> helpers.UbuntuArchitecture() uses the systems arch, it's all fine if we all run on amd64 but this will all fail when using a different system
[13:13] <sergiusens> meh, I understand myself ;-)
[13:13] <sergiusens> I just need to mock UbuntuArchitecture
[13:13] <Chipaca> sergiusens: um
[13:13] <Chipaca> sergiusens: i don't see that need
[13:13] <Chipaca> hence my questioning it
[13:14] <sergiusens> Chipaca: I'm a lazy typer today https://plus.google.com/hangouts/_/canonical.com/seetheneed
[13:35] <sergiusens> Chipaca: see if you like it now
[13:37] <Chipaca> sergiusens: top-approved
[13:37] <Chipaca> purrfect :)
[13:38] <sergiusens> Chipaca: thanks
[13:38] <sergiusens> Chipaca: I always spend some time figuring out which "test helper" we want :-P not sure if the same happens to you
[13:46] <Chipaca> sergiusens: "write a new one every time" is probably a suboptimal strategy
[15:01] <sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/YouShallNotPassBeforeEither/+merge/261097
[15:25] <elopio> rsalveti: do you think we will need to test something on the phones in the next months?
[15:25] <elopio> I'm wondering if I can leave them here so somebody else gets them.
[15:25] <rsalveti> elopio: you never know
[15:25] <rsalveti> elopio: I'd suggest you to keep them with you
[15:25] <rsalveti> unless requested by someone else
[15:28] <sergiusens> rsalveti: elopio you only really need one; I guess we will mostly be doing the core work (os and kernel snap)
[15:28] <sergiusens> but would leave ui work to others
[15:29] <rsalveti> right
[15:30] <elopio> yes. That's what I was thinking. I need a phone to call my mother too :)
[15:30] <elopio> I'll ask how hard would it be to get the others back if we happen to need them later.
[15:55] <kyrofa> Chipaca, ping
[15:59] <rickspencer3> jdstrand, so it is it totally legit for me to let to snaps to talk to each other over localhost:whateverports?
[15:59] <sergiusens> rsalveti: how was https://bugs.launchpad.net/snappy/+bug/1424586 Fix Released? Asking in the sense of backporting ;-)
[16:00] <sergiusens> or is that what fgimenez is working on?
[16:00] <sergiusens> if that's the case, mterry just took over the last bug in that list that is !apparmor
[16:01] <sergiusens> rickspencer3: there is language to prevent that in package.yaml but it is not enforced yet (internal vs external)
[16:02] <fgimenez> sergiusens, i'm using the upgrade script just for testing one of the upgrade paths, anyway seems to be a different approach from that bug
[16:03] <jdstrand> rickspencer3: yes, for external ports (see https://developer.ubuntu.com/en/snappy/guides/package-metadata/). for internal ports there are ideas in the vision doc to create firewall rules that could interfere
[16:04] <fgimenez> sergiusens, the bug fix implements what we were talking about in yesterday's standup, modifying channel.ini to allow an update from the current version
[16:04] <jdstrand> rickspencer3: so internal today would work too. also note, ports is in meta.md but we don't do anything with it yet afaik
[16:05] <sergiusens> fgimenez: yeah, that's in selftests iirc
[16:05] <jdstrand> rsalveti: btw, is there a card for that ^. it seems like we should at least have ingress filtering for anything in 'ports/internal'
[16:05] <jdstrand> actually, that gives me a thought
[16:05] <fgimenez> sergiusens, yep, it's one of them
[16:06] <jdstrand> I thinks ports is not implemented in part because we wanted a ports service to say whether or not something was assigned
[16:07] <jdstrand> what if we used netfilter as the database? ie, if you specify 'ports/external' then you get an ACCEPT rule with an id/comment as the PKGNAME_APPNAME and an DROP rule for external interfaces for ports/internal with an id/comment
[16:08] <jdstrand> sergiusens, rsalveti: ^ idea for whoever implements something more with 'ports'
[16:08] <Chipaca> kyrofa: pong
[16:09] <jdstrand> sergiusens, rsalveti: in this manner, snappy can parse iptables output and determine if something on the system is assigned a port
[16:09] <kyrofa> Chipaca, I'm just getting started on a dbus daemon in golang, and I see you've contributed to go-dbus. Do you recommend that lib?
[16:10] <Chipaca> kyrofa: last time i checked, it was the better of the go dbus wrappers
[16:10] <Chipaca> kyrofa: what's your daemon interfacing with?
[16:10] <kyrofa> Chipaca, the Unity8 QML progress widget
[16:12] <Chipaca> kyrofa: so you're binding qt/qml?
[16:14] <jdstrand> rickspencer3: in case it isn't obvious, if you open a port, anyone can connect to it, so things would have to be designed with that in mind
[16:14] <kyrofa> Chipaca, no, I mean that's what it's communicating with via dbus. Perhaps I misunderstood the question?
[16:14] <Chipaca> kyrofa: ah, ok :)
[16:14] <sergiusens> jdstrand: so DENY by default and if declared as an external port we add an ACCEPT and if negotiable we find a free slot and assign it there and somehow send that back to the package
[16:14] <Chipaca> kyrofa: i was just asking because if you were binding qt or glib anyway, it might make more sense to use their dbus implementation
[16:14] <jdstrand> future internal ports intend to help-- you declare an internal port and what apps can connect to it
[16:15] <sergiusens> jdstrand: but iptables doesn't solve the app1 <-> app2 problem though
[16:15] <jdstrand> sergiusens: yes, essentially
[16:15] <kyrofa> Chipaca, ahh, gotcha :)
[16:15] <Chipaca> sergiusens: how "stable" are data dirs? can i tell a guy to ship a symlink to their data dir in their app?
[16:15] <kyrofa> Chipaca, alright, I appreciate your help! I'll dive into using go-dbus :)
[16:15] <jdstrand> sergiusens: no it doesn't yet-- that would come later
[16:15] <sergiusens> jdstrand: we should probably add this to the backlog
[16:15] <jdstrand> sergiusens: that is in the vision doc
[16:15] <Chipaca> kyrofa: enjoy! holler when it breaks :)
[16:16] <kyrofa> Chipaca, ha! Will do ;)
[16:16] <jdstrand> sergiusens: it would probably make sense to look at ufw's default setup, how it sets up chains, etc for inspiration
[16:17] <jdstrand> if you want, I can help with the design
[16:17] <jdstrand> or at least review/comment on it
[16:18] <jdstrand> sergiusens: alternatively to default DROP, you setup only the rules that are specific to what is declared in ports
[16:18] <jdstrand> that might be a safer first step until we understand frameworks better
[16:19] <jdstrand> but we can talk about it
[16:19] <sergiusens> jdstrand: tracked now https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
[16:21] <jdstrand> sergiusens: awesome (commented)
[16:22] <jdstrand> sergiusens: it probably will make sense to discuss with th architects team since there will be interactions between snaps and frameworks
[16:22] <jdstrand> sergiusens: eg, a router framework and an unrelated snap. I'd like to be invited to that call with the architects
[16:26] <jdstrand> sergiusens: so, for the vision work (additional filtering of internal ports for app to app filtering), the basic idea is create a net cgroup that tags the network traffic, and then you have rules that reference the tag
[16:27] <jdstrand> sergiusens: I think that should be done as a second step
[16:38] <jdstrand> sergiusens: ok, I'll stop talking here-- I added my thoughts to the card
[16:38] <jdstrand> since it is clear that is what you want ;P
[16:43] <sergiusens> jdstrand: oh, sorry, I'm preparing lunch ;-)
[16:44] <sergiusens> jdstrand: we can discuss here in a bit and then I'll summarize neatly in the card
[16:44] <sergiusens> but food first since it's almost 2pm and I need to eat ;-)
[16:45] <jdstrand> sergiusens: I was just teasing. Everything I have time to discuss today is in the card so I think we are good for nowe
[16:45] <jdstrand> now*
[16:46] <mterry> sergiusens, added a .tarmac.sh to lp:snapcraft
[16:46] <mterry> Missed that in lp:snappy
[17:11] <rsalveti> sergiusens: for bug 1424586, only trunk is fix released
[17:11] <rsalveti> the 15.04 task is still opened
[17:21] <rsalveti> sergiusens: can you check if we can backport the selftests as well?
[17:21] <rsalveti> then we drop the older separated branch completely
[17:22] <rsalveti> and I believe the current self tests are compatible with both 15.04 and rolling
[17:23] <rsalveti> jdstrand: sergiusens: thanks for creating the card
[17:23] <rsalveti> I think ricmm will own that from the arch side of things
[17:23] <rsalveti> ricmm: https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
[17:23] <rsalveti> he's our network architect :-)
[17:24] <rsalveti> let me add this as a topic for the archs call to make sure we don't forget
[17:51] <ricmm> rsalveti: yea please add that to go over it tomorrow
[17:52] <rsalveti> already did
[17:52] <ricmm> thx
[18:08] <sergiusens> rsalveti: right, but there is no link to any code so I have no idea what work was done for that
[18:08] <sergiusens> wrt to the bug
[18:08] <rsalveti> right, mvo just added a comment pointing out the branch
[18:08] <rsalveti> but didn't link to the bug
[18:08] <sergiusens> ricmm: rsalveti I also need an 'am I online API' where online can be, lan, wan, internet
[18:08] <rsalveti> https://bugs.launchpad.net/snappy/+bug/1424586/comments/6
[18:08] <sergiusens> rsalveti: ok
[18:09] <rsalveti> sergiusens: hm, right
[18:09] <sergiusens> rsalveti: there, I linked to the bug
[18:09] <rsalveti> thanks
[18:10] <rsalveti> for 15.04 we hopefully can just backport the selftests merge
[18:10] <sergiusens> rsalveti: selftests though, those are cross release still, so there shouldn't be any backport work
[18:10] <sergiusens> rsalveti: since this landed in the selftest series and not in trunk
[18:10] <rsalveti> sergiusens: right, but we still need to merge under the 15.04 branch, right?
[18:10] <rsalveti> sergiusens: but thought selftests were later merged
[18:10] <sergiusens> rsalveti: I don't think selftests are in trunk yet
[18:11] <rsalveti> man, I hate this code browse interface for bzr
[18:12] <rsalveti> yeah, thought mvo had merged that
[18:13] <sergiusens> rsalveti: nope, and I don't see an MP anymore
[18:13] <rsalveti> so all good then
[18:13] <rsalveti> we'll merge for 15.04.2 I guess
[18:13] <sergiusens> rsalveti: I know there were commens from elopio in an original let's "merge it" MP
[18:13] <rsalveti> right
[18:13] <sergiusens> I guess this may have died in relation to his work into converting to go
[18:13] <rsalveti> could be
[18:14] <rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592
[18:14] <rsalveti> yeah, still wip
[18:15] <rsalveti> @reviewlist
[18:15] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[18:15] <nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot/+merge/261114 | Needs Information: 1 (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
[18:16] <rsalveti> why is it not there?
[18:25] <sergiusens> rsalveti: the webui isn't showing it either (which is why I thought it was destroyed)
[18:25] <rsalveti> weeeeeird
[18:26] <rsalveti> hm, showing fine here
[18:26] <rsalveti> https://code.launchpad.net/~snappy-dev/snappy/snappy/+activereviews
[18:26] <rsalveti> lp:~mvo/snappy/snappy-merge-integration-tests ⇒ lp:snappy
[18:26] <sergiusens> rsalveti: oh, right, I'm looking at lp:snappy/+activereviews
[18:26] <sergiusens> rsalveti: you don't see it in the reviewlist because it's WiP
[18:27] <sergiusens> that should be @worklist ;)
[18:28] <rsalveti> oh, got it
[18:28] <rsalveti> makes sense
[18:28] <rsalveti> it's just that it's really uncommon for people to let the status as wip
[18:37] <mterry> I'm getting "operation not supported" and a failure to install hello-world on latest rolling image
[18:38] <mterry> Anyone else seeing that or is my image just borked?
[18:41] <rsalveti> iirc latest rolling is still not properly in shape
[18:41] <rsalveti> so might just be a valid bug
[18:44] <sergiusens> mterry: rsalveti that's a go 1.4 bug (from Chipaca's findings)
[18:45] <sergiusens> rsalveti: nah, this team does the right thing ;-) If it's not ready for review WiP is the right status :-)
[18:48] <sergiusens> @reviewlist
[18:48] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[18:48] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | Needs Fixing: 1 (less than a day old)
[18:51] <mterry> sergiusens, I'm looking at this rollback code
[18:51] <mterry> sergiusens, and actually, we output "Setting %s to version %s" AFTER we rollback
[18:51] <mterry> sergiusens, so there's no feedback for a bit
[18:51] <mterry> sergiusens, I'm going to modify my branch to move that up
[18:52] <sergiusens> mterry: meh
[18:52] <sergiusens> mterry: I think it's too late :-/
[18:53] <mterry> sergiusens, I caught it  :)
[18:53] <mterry> sergiusens, no i didn't
[18:53] <mterry> sergiusens, sight
[18:53] <mterry> oh well
[18:53] <sergiusens> mterry: just leave it, we should have a proper spinner in place
[18:53] <mterry> sergiusens, fair enough
[18:54] <sergiusens> mterry: we can reset trunk if you want ;-)
[18:55] <mterry> yes pls
[18:55] <sergiusens> mterry: ok, one sec
[18:55] <mterry> :)
[18:56] <sergiusens> mterry: done
[18:57] <mterry> sergiusens, wait what?  That is a thing we do?
[18:57] <mterry> sergiusens, I thought you were joking
[18:57] <sergiusens> mterry: sometimes, yes
[18:57] <sergiusens> mterry: we once had someone (not naming names) do something bad with trunk
[18:57] <mterry> sergiusens, you crazy.  OK, let me set branch status
[18:57] <sergiusens> mterry: anyways, no smilies or anything and I take you seriously ;-)
[18:58] <sergiusens> sorry
[18:58] <mterry> sergiusens, that's fair.  I just didn't think it was a real thing, so I didn't take you seriously  :)
[18:58] <mterry> I mean
[18:58] <mterry> I know you can always push --overwrite
[18:58] <mterry> But I thought we had protections against that
[18:59] <sergiusens> mterry: oh, yeah, I know what you mean; but yeah, it's doable and very easy to make a mistake
[19:00] <sergiusens> a common mistake, bzr branch <code>; cd <code>; bzr merge <branch>; bzr push <code>; sleep (a lot); write_core; bzr commit; bzr push (oops)
[19:02] <sergiusens> mterry: it's solvable by putting trunk under a different team and only having the merge bot there
[19:03] <rickspencer3> sergiusens, not sure if you are still here, but are you saying that if I try to send data over localhost:n ... that it will stop working when the security policy is fully implemented?
[19:03] <mterry> sergiusens, yeah I try to never reuse branch directories for that reason
[19:04] <sergiusens> mterry: I can't wait for our git migration ;-)
[19:04] <sergiusens> rickspencer3: I am
[19:04] <sergiusens> rickspencer3: and yes, it would stop if you declare your port as internal (I don't recall the spec completely from the top of my head right now)
[19:08] <rickspencer3> sergiusens, ok, I'll wait until the proper implementation for socket communication
[19:09] <rickspencer3> is there a standard way that folks are parsing yaml in Go?
[19:10] <sergiusens> rickspencer3: we use gopkg.in/yaml.v2
[19:10] <sergiusens> rickspencer3: http://godoc.org/gopkg.in/yaml.v2
[19:22] <mterry> rsalveti, I think we may want bug 1457183 in 15.04.1 too
[19:23] <rsalveti> mterry: yeah, makes sense, thanks
[19:35] <mterry> When is lp:snappy/selftest run?
[20:05] <rsalveti> sergiusens should know if enabled as part of the merging process
[20:05] <rsalveti> but generally we want to run it as part of proposed-migration and after the image gets published
[20:05] <rsalveti> but that is currently disabled, since we had the ps4 outage
[20:06] <sergiusens> rsalveti: I can't run it yet as part of the merging process, well I could but it would take a couple of hours I guess (vm inside a vm)
[20:07] <rsalveti> right
[20:07] <rsalveti> so the goal is to have that, eventually
[20:07] <rsalveti> mterry: so your answer is only when manually testing it
[20:08] <mterry> rsalveti, fair
[20:08] <mterry> but the plan is more
[20:28] <Chipaca> sergiusens: suggestions for "integrate()"?
[20:28] <Chipaca> sergiusens: generateIntegration()?
[20:29] <Chipaca> sergiusens: ohblahdeeOhblahdahIntegrationLalalalalalala()
[20:29] <Chipaca> sergiusens: antiderivative()
[20:34] <sergiusens> Chipaca: doStuff()
[20:34] <Chipaca> sergiusens: doPerformHelpWorker()
[20:34] <sergiusens> Chipaca: legacyIntegrationHooks?
[20:35] <sergiusens> @bugs
[20:35] <nothal> sergiusens: No such command!
[20:35] <sergiusens> @help
[20:35] <nothal> "list" To see the available commands ; "help cmd" for specific command help
[20:35] <Chipaca> well, some of it is legacy, some isn't
[20:35] <sergiusens> @help list
[20:35] <nothal> Lista las órdenes disponibles.
[20:35] <Chipaca> @list
[20:35] <nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
[20:35] <Chipaca> @critical
[20:35] <sergiusens> yay, half translations
[20:35] <sergiusens> @bug
[20:35] <sergiusens> hmmm
[20:35] <Chipaca> bug is for “bug # yadda”
[20:35] <sergiusens> Chipaca: !hal broke
[20:36] <Chipaca> but @critical isn't
[20:36] <Chipaca> these python programs, coming here, using up all the bugs
[20:36] <sergiusens> @help bug
[20:36] <nothal>  Search a bug and show it's id, title and status
[20:36] <sergiusens> Chipaca: yeah, I want @bugs :-P
[20:36] <Chipaca> @help critical
[20:36] <nothal> show the crtical bugs for self.project (could be a meta project)
[20:36] <Chipaca> verterok: @critical ne marche plus?
[20:37] <sergiusens> Chipaca: do you know about https://bugs.launchpad.net/snappy/+bug/1460152 ?
[20:37] <Chipaca> verterok: also, why doesn't @reviewlist list everything?
[20:37] <Chipaca> ubottu: i know since i last lucked, mvo picked it up somehow?
[20:37] <Chipaca> or maybe somebody assigned to it
[20:37] <Chipaca> ubottu: sorry, i meant sergiusens
[20:37] <Chipaca> ubottu: i never assume that which i am interacting with is intelligent
[20:38] <sergiusens> Chipaca: I am only a human, pleaase don't think I'm intelligent :-)
[20:38] <Chipaca> ubottu: it's merely a convenient abstraction
[20:38] <verterok> Chipaca: what do you mean it doesn't list everything?
[20:38] <Chipaca> verterok: compare
[20:38] <Chipaca> @reviewlist
[20:38] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[20:38] <nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot-15.04/+merge/261135 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[20:38] <Chipaca> verterok: and code.launchpad.net/snappy/+activereviews
[20:38] <nothal> https://code.launchpad.net/~chipaca/snappy/removeClick/+merge/260560 | Needs Information: 1 (5 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1459212-check-required-fields/+merge/260509 | Needs Fixing: 1 (6 days old)
[20:38] <nothal> https://code.launchpad.net/~sergiusens/snappy/frameworkPath/+merge/260202 | Needs Information: 1, Approve: 1 (8 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | Approve: 1 (8 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (14 days old)
[20:39] <Chipaca> verterok: in particular, two of mvo's branches and two of my branches don't show up
[20:39] <verterok> Chipaca: help me here, which ones? :)
[20:40] <Chipaca> verterok: of mine, lp:~chipaca/snappy/setActiveClick and lp:~chipaca/snappy/unsetActiveClick
[20:40] <Chipaca> verterok: of mvo, dunno, i just counted
[20:40]  * Chipaca is bad at making set differences
[20:41] <verterok> Chipaca: k, one example is ok
[20:41] <Chipaca> verterok: this is without looking at mvo's git one :)
[20:42] <verterok> yeah, no git branches/repo support last time I checked launchpadlib
[20:42] <Chipaca> no worries
[20:42]  * Chipaca hopes that will come
[20:43] <Chipaca> sergiusens: before i started the ubottu nonesense, did you read my reply?
[20:43] <sergiusens> Chipaca: I think rsalveti said it was on cjwatson's list
[20:43] <sergiusens> Chipaca: about me not being intelligent?
[20:44] <sergiusens> Chipaca: or this new goodie? https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144
[20:44] <Chipaca> sergiusens: yes. I mean no, about mvo being on the bug
[20:44] <sergiusens> Chipaca: which shows up on the list ;-)
[20:44] <Chipaca> yeah, that one
[20:44] <Chipaca> sergiusens: noticed it suddenly had a patch and a branch on the milestone list
[20:45] <sergiusens> Chipaca: wrt to integrate() add some comment or the word legacy there, we are planning on getting rid of it, right?
[20:45] <Chipaca> sergiusens: we had a drive-by mvo it seems
[20:45] <Chipaca> sergiusens: maybe :) it's mostly for generating the click manifest, so yes
[20:45] <sergiusens> Chipaca: I know of people that had enough mana to summon him :-)
[20:47] <Chipaca> i found a good place to have a sprint!
[20:47] <Chipaca> http://www.waterwaysholidays.com/detail/alvdove15.htm
[20:47] <mterry> jdstrand, where is docker packaging?  I wanted to get the same error you did in bug 1442410
[20:48] <Chipaca> mvo: boo!
[20:51] <mvo> hey Chipaca
[20:51] <mvo> Chipaca: how are you?
[20:51] <Chipaca> me? I'm fine. My irc client doesn't crash all the time.
[20:51] <sergiusens> lol
[20:56] <Chipaca> so, given http://www.washingtonpost.com/blogs/the-switch/wp/2015/06/04/fbi-official-companies-should-help-us-prevent-encryption-above-all-else/
[20:56] <Chipaca> when do we start encrypting snappy?
[21:00] <verterok> Chipaca: it seems the bot was in a weird state, kicked it a bit
[21:00] <verterok> @reviewlist
[21:00] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[21:00] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[21:00]  * Chipaca kicks nothal
[21:00]  * nothal kicks Chipaca
[21:01] <verterok> @reviewlist
[21:01] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[21:01] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[21:02] <verterok> Chipaca: something is broken. sorry. will redeploy it
[21:02] <Chipaca> k...
[21:03] <verterok> @critical
[21:04] <Chipaca> sergiusens: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync
[21:04]  * verterok kicks harder
[21:04] <mvo> hey Chipaca, sorr,y looks like my network is a bit unreliable
[21:04] <Chipaca> sergiusens: are meregd already into ubuntu:vivid/ubuntu-core-upgrader
[21:04] <mvo> Chipaca: did you say anything?
 Chipaca: how are you?
[21:05] <Chipaca> * mvo has quit (Client Quit)
 me? I'm fine. My irc client doesn't crash all the time.
 lol
[21:05] <mvo> my irc client is fine, my network is not ;)
[21:05] <Chipaca> fair enough
[21:05] <mvo> I heard ubuntu-core-upgrader, whats up with that?
[21:05] <mvo> seems to be ok now though (the network), fingers crossed ;)
[21:05] <Chipaca> mvo: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync are meregd already into ubuntu:vivid/ubuntu-core-upgrader
[21:06] <mvo> cool, yeah, quite possible
[21:06]  * mvo can't remember but it rings a bell
[21:06] <Chipaca> mvo: that is, i bzr branch'ed ubuntu:vivid/ubuntu-core-upgrader, and merging those two branches gave me no diff
[21:07] <Chipaca> mvo: does this mean the task wrt the upgrader for 15.04.1 is done?
[21:07] <Chipaca> mvo: or is there more to it?
[21:07]  * Chipaca has no idea
[21:07] <mvo> Chipaca: let me quickly double check
[21:07] <Chipaca> mvo: should i be letting you work at all?
[21:08] <mvo> Chipaca: heh :)
[21:09] <mvo> Chipaca: so its merged but it seems like its not uploaded yet, I will push to the PPA for now and we need a proper SRU
[21:09] <Chipaca> mvo: ok. I thought it landed in ubuntu:yadda after being in the archive proper, but obviously not
[21:14] <mvo> Chipaca: I land it now
[21:16]  * rsalveti waves to mvo
[21:16] <rsalveti> yeah, we can take care of the SRU side later
[21:17] <rsalveti> guess that would include core-upgrader and core-launcher
[21:18] <mvo> hey rsalveti
[21:18] <mvo> rsalveti: yeah
[21:18] <mterry> sergiusens, you said earlier that install problems on rolling were "a go 1.4 bug (from Chipaca's findings)"
[21:18] <mterry> sergiusens, is there a workaround or a bug to track?
[21:18] <Chipaca> mterry: well, well
[21:18] <Chipaca> mterry: there is no bug for the 1.4 thing afaik, maybe there should be
[21:19] <Chipaca> mterry: we'd have to check with a "proper" go 1.4 first
[21:19] <Chipaca> as this was just with my locally-compiled go 1.4, which might have other issues
[21:19] <Chipaca> (it hasn't been a problem before, but)
[21:19] <Chipaca> mterry: what exactly are you seeing?
[21:20] <mterry> Chipaca, when I try to "sudo snappy install" something, I get "operation not supported" and then a message about unpack from /tmp to the real place failed
[21:20] <Chipaca> ah, yes, that sounds exactly like the thing that happened with my 1.4
[21:20] <mvo> Chipaca, mterry: AIUI lp:~mterry/ubuntu-core-launcher/tmpdir-15.04 needs to land in the PPA as well (its not yet, correct?)
[21:21] <Chipaca> mvo: correct
[21:21] <mterry> mvo, I'd like it to land yeah
[21:21] <mvo> cool, shall I do the merge/upload-to-ppa dance or is someone already on it?
[21:22] <mvo> (sorry, I'm a bit out of the loop)
[21:22] <Chipaca> I've +1'ed and top-approved
[21:22] <rsalveti> one other we need review https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104
[21:22] <rsalveti> and then upload as well
[21:22] <Chipaca> rsalveti: that's the one mvo just asked about
[21:22] <Chipaca> rsalveti: and the review is done
[21:22] <rsalveti> indeed, sorry, was going over my tabs
[21:22] <Chipaca> (as i'd reviewed the original one, it was quick)
[21:23] <rsalveti> mvo: I can do as well, you should not even be here :-)
[21:24] <rsalveti> the workaround for the apparmor mr should be automatically merged and uploaded, so that is fine
[21:24] <rsalveti> guess we just need to create the backporting branch once that lands in trunk
[21:26] <rsalveti> Chipaca: lol, that article would be a good one for the onion
[21:26] <Chipaca> rsalveti: :-/
[21:27] <mvo> rsalveti: I have a backport branch pushed as well :)
[21:27]  * rsalveti hugs mvo
[21:28] <mvo> rsalveti: I can do the merge/upload, thats fine (unless you already started that or I duplicate the work of someone else)
[21:28] <rsalveti> didn't yet start, unless Chipaca is on it, I don't think anyone is on it yet
[21:29] <Chipaca> i can't upload, i don't think
[21:29] <rsalveti> you should be able to
[21:29] <rsalveti> you're part of ~snappy-dev
[21:30] <Chipaca> Excellent.
[21:30]  * Chipaca did not just do his mr burns impression
[21:30] <rsalveti> I'll trigger another image once everything is there
[21:30] <rsalveti> and hopefully we should have our first RC
[21:32] <mterry> mvo, I saw your comment about helpers/, which I also helped make worse with my EnvVar stuff
[21:32] <mterry> mvo, maybe we need a second "general" package
[21:32] <Chipaca> mterry: what was the comment?
[21:32] <mvo> mterry: yeah! or maybe I'm overthinking this, I'm not sure yet :)
[21:32] <mterry> on lp:~sergiusens/snappy/YouShallNotPass merge, just saying a func maybe doesn't belong in helpers/
[21:32] <mterry> Chipaca, ^
[21:33] <mvo> but I would love to have a tiny bit more structure in helpers as its a bit of a misc/ dir right now and at some point it was meant to be stuff-missing-in-stdlib or something like that
[21:33] <mterry> Chipaca, so wait.  About the go1.4 bug.  no workaround yet?  Should I just go back to 15.04 for testing?
[21:34] <Chipaca> mterry: given the bug, yes, go back to 15.04
[21:34] <Chipaca> especially as that's what we're releasing rsn :)
[21:35] <Chipaca> mterry: or, compile snappy with 1.3 for W
[21:35] <Chipaca> mterry: until we've sorted that one out
[21:35] <mvo> rsalveti: once the workaround branch lands (assuming it gets a ok fromthe reviewers) we need to trigger the daily build for that branch, let me quickly search the url for that
[21:35] <mterry> Chipaca, pfft, 15.04 is old hat, even if we are shipping a point release  :)
[21:35] <Chipaca> go's "compatibility promise", on which they base not supporting releases for more than ~6 months, has bit us before now, so
[21:35] <mvo> rsalveti: https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily/ <- thats the page
[21:36]  * mvo wishes we had git-dch for bzr or git so that it would auto-create the debian/changelog from the vcs comments
[21:41] <rsalveti> mvo: awesome, thanks
[21:42] <rsalveti> yeah
[21:45] <rsalveti> Chipaca: can I just cross lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync ?
[21:46] <Chipaca> rsalveti: AIUI if you're asking, no
[21:46] <Chipaca> rsalveti: mvo said he could do it, you told him you could and that he shouldn't be here
[21:46] <Chipaca> rsalveti: or maybe i misunderstood
[21:47]  * mvo is confused now ;)
[21:47] <rsalveti> Chipaca: sorry, you said earlier that you tried merging jhunt's branches and got a 0 diff
[21:47]  * rsalveti reads backlog
[21:48] <mvo> yeah, the use-os-sync was merged but not uploaded, I uploaded that now to the ppa and to wily
[21:48] <rsalveti> yeah, then all good
[21:49] <rsalveti> crossing then
[21:49] <mvo> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages should have the info looks like its indeed there
[21:50] <rsalveti> awesome
[21:50] <mvo> Chipaca: I need to buy you tea (or beer) for all the silly mistakes you need to endure in my branches, thanks a lot for spotting these issues
[21:51]  * Chipaca blushes
[21:51] <Chipaca> mvo: you've put up with a lot of nonsense in my branches, glad to be finally paying it back :D
[21:51] <mvo> lol
[21:52] <Chipaca> still have to learn to do reviews like yours though; almost makes me want to put more mps up just to get them :)
[21:53] <Chipaca> ANYway, i should put down the computer and go wash the dishes and get the house ready for the night
[21:53] <mvo> Chipaca: a more serious question about the oauth signing branch, you point out (correctly) that buf.Grow(len(inputString)*3) may be too small and I need to count the bytes. should I simply use len(s)*3 (quotes) *4 (utf-8 len) - or convert the str to bytes before checking the len?
[21:53] <Chipaca> mvo: you're converting it to bytes anyway
[21:54] <Chipaca> mvo: might as well do it earlier
[21:54] <mvo> Chipaca: do that, I will call it a day soon too
[21:54] <mvo> Chipaca: yeah, sounds sensible
[21:54] <mvo> Chipaca: thanks a bunch
[22:17] <mvo> rsalveti: its hopefully all prepared for the release-candidate, just ping me again if there is anything that needs work. I will keep a eye on my mail to see if my MPs get approved
[22:17] <rsalveti> mvo: sure, thanks so much
[22:19] <mvo> your welcome!
[22:19]  * mvo &
[23:46] <rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 would only work if the base image (stable) already had such changes, right?
[23:47] <rsalveti> it seems our problem is that we'll be updating from stable to edge using the tools that are currently available at stable
[23:47] <rsalveti> so it would only work after doing another update
[23:48] <rsalveti> guess that's the usual problem of updating using the tools available from the older image (like we had with touch)
[23:53] <rsalveti> added a comment to the MR (for lp:snappy)