[12:05] <bradb> oh...for *the* entertainment
[02:13] <jordi> mdke: the Chinese is probably valid
[02:13] <mdke> heya
[02:13] <jordi> The Spanish variants aren't most probably
[02:13] <jordi> hey
[02:13] <jordi> just came back from the concert
[02:14] <jordi> tomorrow will be a loooong day I'm afraid
[02:14] <mdke> friday :)
[04:08] <jamesh> spiv: ping?
[04:31] <spiv> jamesh: pong
[04:32] <jamesh> spiv: SteveA said to add the Python license to the tickcount code, however the Python license seems very specific to Python and the PSF
[04:32] <jamesh> spiv: I was wondering if you knew what sort of text people used when they wanted to apply the license to other code?
[04:34] <spiv> jamesh: http://www.python.org/moin/PythonSoftwareFoundationLicenseFaq
[04:34] <spiv> (although it isn't responding for me, so here's the google cache http://<IP_ADDRESS>/search?q=cache:Po4ZYunZLYAJ:www.python.org/moin/PythonSoftwareFoundationLicenseFaq+psf+license+faq&hl=en&ct=clnk&cd=1)
[04:34] <jamesh> okay, so search+replace is the answer
[04:36] <spiv> jamesh: Although as that FAQ mentions, the PSF licence is not actually an appropriate initial license for contributions to Python.
[04:36] <jamesh> yeah
[04:40] <jamesh> the legal opinions of the MIT license I've heard are that it includes a patent grant
[05:01] <jamesh> spiv: do you think bazaar.launchpad.net/~launchpad/tickcount/devel would be a good name for the branch on the supermirror?
[05:02] <spiv> jamesh: Seems ok.  I wonder if it's worth having a tickcout team to own it instead of launchpad?
[05:02] <spiv> tickcount, rather :)
[05:02] <spiv> Yeah, the thing about not accepting MIT licenses is interesting, I didn't know that.
[05:03] <jamesh> especially since both AFL and Apache licenses are GPL incompatible ...
[05:03] <spiv> Although does the MIT licence probably give you enough scope to relicense with one of the acceptable ones?
[05:06] <jamesh> the MIT license says you can "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software" provided the copyright notice is preserved
[05:06] <jamesh> so it lets you do pretty much anything except claim you wrote it
[05:07] <jamesh> the legal opinion I heard was that it would be impossible to grant the rights in the MIT license without licensing the applicable patents
[05:08] <spiv> I'm mainly curious because Twisted is MIT licensed, and there's periodically talk of including parts of it in the standard library.
[05:09] <spiv> (which probably will never happen, but who knows...)
[05:15] <jamesh> as for branch naming, I guess I'll make it owned by launchpad for now -- we can always change the branch owner at a later date
[05:19] <spiv> Yeah.
[05:20] <jamesh> hmm.  product registrants don't seem to be able to change the registrant anymore
[05:21] <spiv> I think there's a bug open on that.
[05:22] <jamesh> yeah.  Looks like carlos locked it down to protect a particular view
[05:25] <spiv> Well, if the tests passed... ;)
[08:00] <spiv> SteveA: ping... infrastructure voip call now?
[08:05] <stub> mmm
[08:06] <spiv> I have to go in about 25 minutes...
[08:10] <spiv> stub: did you get my cherrypick request for the authserver?
[08:11] <stub> spiv: yes. Distracted on other things atm though. Should go out later today.
[08:11] <spiv> stub: wonderful, thanks!
[08:28] <stub> Anything thrilling we should be discussing in the infrastructure call?
[08:28] <stub> I've got nothing to add except work on the test runner is in progress.
[08:29] <jamesh> not directly related to infrastructure, but I wanted to ask SteveA about the tickcount licensing (given what the faq on the Python wiki says)
[08:32] <spiv> Nothing springing to my mind.
[08:39] <stub> jamesh: SteveA wants tickcount to go into a future Python release and one step of that involves putting the correct licence on it as per the Python wiki.
[08:42] <jamesh> stub: yeah, and the wiki says that the Python license is not the correct license.
[08:43] <stub> And it says what the correct license is?
[08:43] <jamesh> they list the AFL and Apache 2.0 public license
[08:43] <jamesh> as acceptable ones
[08:44] <stub> bad wiki
[08:45] <jamesh> http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq <- "Why can't I contribute code under the PSF License?"
[08:49] <stub> Bah. I don't like any licence longer than a paragraph. They just cause headaches and arguments.
[08:49] <jamesh> the choice of acceptable licenses seems to be constrained to those with an explicit patent grant
[08:55] <jamesh> stub: did you manage to solve the slowness with pushing to bazaar.launchpad.net?
[08:56] <jamesh> it seemed about as fast as I'd expect when I tested it
[08:57] <stub> jamesh: It finished eventually. Just slow. No idea if it is something magic about that  particular branch or if it is purely network related meaning it is slower here.
[08:57] <jamesh> stub: the number of files you listed under .bzr sounded like a lot for weaves
[08:57] <stub> It was knit format
[08:57] <jamesh> stub: It should be 2*number of files in repo + constant
[08:58] <stub> Branch is here if you think you can make sense out of it: https://launchpad.net/people/stub/+branch/pytz/devel
[08:59] <sivang> morning
[09:02] <jamesh> stub: doing a "bzr branch" of that branch just gives 215 files, which seems reasonable
[09:02] <stub> Weird...
[09:03] <stub> They are almost all in .bzr/repository
[09:03] <jamesh> I wonder what else is in that repository?
[09:03] <stub> repository/knits in fact
[09:04] <jamesh> $ find .bzr/repository/knits -type f | wc -l
[09:04] <jamesh> 196
[09:04] <jamesh> so that's 98 files (since there is a knit and a knit index for each one)
[09:07] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileJIDj7e.html
[09:23] <jamesh> stub: here's the difference between your directory listing and what I saw: https://chinstrap.ubuntu.com/~dsilvers/paste/file99dQiu.html
[09:26] <stub> If I bzr push, I get a branch containing 1400+ knits. If I bzr branch, I get a branch containing 196 knits.
[09:26] <stub> mpool: Have I broken something again?
[09:28] <stub> I shouldn't be allowed near computers
[09:29] <jamesh> the real question is what is in those 1200 extra knits
[09:30] <stub> Are knits binary format or a text format compressed?
[09:31] <stub> Ahh... gzipped
[09:31] <SteveA> morning
[09:32] <SteveA> hi folks.  i overslept.  sorry bout that.
[09:32] <stub> Hmmm.... very weird. It looks like files from a different branch in the same old arch repository
[09:35] <stub> So it looks like my pytz branch ended up with a load of history from other branches in the same archive that is preserved when pushed but ignored when branched. There are cases where this would be a security bug (thankfully I kept my public and private archives seperate).
[09:35] <stub> And that information was even preserved when converting the weaves to knits using bog standard 'bzr update'
[09:36] <stub> SteveA: jamesh first time, me second time, so it looks like spiv is due to be late next ;)
[09:36] <stub> SteveA: We declared the call boring anyway
[09:37] <stub> And IRC chats are more productive because nobody knows you are drinking beer
[09:38] <SteveA> jamesh: please put the tickcount stuff under the LGPL.  We'll relicence it later if it gets into the standard library.
[09:41] <SteveA> although, the MIT would do just as well
[09:45] <jamesh> SteveA: done.  It is available here: https://launchpad.net/people/launchpad/+branch/tickcount/devel
[09:45] <SteveA> spiv: how's sftp stuff going?
[09:45] <jamesh> (hasn't been pulled from the SFTP server yet though
[09:46] <stub> So that error message actually means 'I haven't gotten around to mirroring this yet'? Is that an open bug anyone?
[09:47] <jamesh> I think it means "I tried to mirror it, but it hadn't been fully pushed to the supermirror at the time
[09:47] <jamesh> i.e. unfortunate timing
[10:02] <lifeless> moining
[10:15] <stub> spiv: authserver updated
[10:18] <lifeless> stub: its not a bug
[10:18] <lifeless> stub: it means what jamesh says and it will correct it self normally
[10:18] <lifeless> the inclusion of the local path in the error is a bug and there is one open on it
[10:19] <stub> lifeless: Any thoughts on the extra 1200 knits issue in your scrollback?
[10:20] <lifeless> what issue ?
[10:20] <lifeless> (scrollback is long, give me a time delta or a summary)
[10:22] <stub> I have a branch that was converted from arch and subsequently converted from weave to knits that contains about 1440 knits. There are only a dozen or so files under rcs though. If I push, the knits are propogated to the new branch. If I branch, the number of knits drops to 196.
[10:22] <stub> The extra knits appear to be from other branches in the old arch repository
[10:23] <stub> I can fix it obviously enough just by branching, but it might be a symptom of something you need to worry about. Possibly a security issue as private data may accidently end up getting pushed when not intended.
[10:23] <lifeless> bzr version ?
[10:24] <stub> 0.8.2
[10:24] <lifeless> fixed in .dev I believe
[10:24] <stub> The conversion from arch would have been an earlier version though
[10:24] <lifeless> https://launchpad.net/products/bzr/+bug/43713
[10:24] <Ubugtu> Malone bug 43713 in bzr "bzr branch clones too much" [High,Fix released]
[10:25] <stub> This is not repositories
[10:25] <lifeless> it is under the hood
[10:25] <stub> ok
[10:26] <stub> branch seems to remove the surious knits, but push doesn't. Could it have been fixed for branch only?
[10:26] <lifeless> no
[10:27] <lifeless> this is the vlone logic:
[10:27] <lifeless>             dir_to = br_from.bzrdir.clone(location_url,
[10:27] <lifeless>                 revision_id=br_from.last_revision())
[10:27] <lifeless> the revision_id parameter is the key one to make this be fixed.
[10:27] <stub> ok
[11:32] <highvoltage> hi #launchpad
[11:33] <highvoltage> if i want to add myself to a meeting for in paris, do i subscribe to the meeting in launchpad?
[11:33] <highvoltage> or is there another way i should join?
[11:34] <SteveA> highvoltage: make sure the dates you'll attend the meeting are set in launchpad, and then subscribe to the meetings in launchpad, as you say
[11:34] <highvoltage> SteveA: thanks, will do.
[11:38] <highvoltage> i don't want to oversusbscribe to meetings right now, just to the meetings that i am very, very interested in.
[11:38] <highvoltage> if there's a gap on a day, can i attend a meeting?
[11:39] <highvoltage> or do i absolutely have to subscribe now in order to be able to attend?
[11:40] <SteveA> the conference organisers will use an automated scheduling program to schedule the meetings and attendees
[11:40] <SteveA> and each person will get an webpage with their own meetings on it for the day
[11:41] <SteveA> so, if you want to take advantage of this, you should subscribe
[11:41] <SteveA> if not, i expect you can just turn up to meetings, provided there is enough space around the table
[11:42] <highvoltage> ok, thanks for the tip.
[11:43] <lifeless> hmmm, the roadmap is a little borked
[11:45] <SteveA> lifeless: context-free non-sequiteur
[11:47] <lifeless> the roadmap in the sprint app within launchpad is not doing an effective sort
[11:51] <SteveA> lifeless: is it something we should get fixed before the paris meeting?
[11:52] <lifeless> probably not - its an implementation roadmap not a meeting scheduling map, AFAICT
[11:52] <lifeless> as long as the meeting scheduler takes priority into account it will be fine.
[11:52] <lifeless> but we should fix it before the sprint ends :)
[11:54] <SteveA> jamesh: ping
[11:55] <SteveA> lifeless: i don't have mental bandwidth to look into it / understand it right now.
[11:55] <SteveA> but maybe you and james can establish whether the scheduler will work as intended
[11:55] <SteveA> and file a bug for what should change
[11:55] <SteveA> the roadmap table is certainly meant to be about implementation
[11:58] <jamesh> SteveA: pong
[11:58] <jamesh> the scheduler algorithm uses the priorities
[11:58] <SteveA> jamesh: would you read the last 15 lines of scrollback, and see if we need to file a spec tracker UI bug?
[11:58] <Yannig> Hello everybody
[12:03] <LarstiQ> has anyone seen the python.org call for trackers? http://wiki.python.org/moin/CallForTrackers
[12:04] <SteveA> yes
[12:05] <SteveA> we'll be submitting an entry for launchpad
[12:05] <jamesh> lifeless: it looks like the code that drives that page tries to apply a partial ordering to the incomplete specs based on dependencies
[12:06] <jamesh> lifeless: it doesn't do anything with priorities
[12:06] <lifeless> jamesh: yes, I know :)
[12:06] <jamesh>         # XXX sabdfl 2006-04-07 this is incomplete and will not build a
[12:06] <jamesh>         # proper comprehensive roadmap
[12:06] <lifeless> jamesh: it should start with priorities, then backfile in the dependencies, traversing in priority order
[12:06] <lifeless> as a depth first search
[12:07] <jamesh> yep
[12:16] <adrighem> Hi all.
[12:17] <adrighem> I want to set up a "GNOME Translation group" in rosetta, but don't see how this can be done.
[12:18] <adrighem> The page says "Only Official coordinators will be able to add you to the GNOME teams in Rosetta."
[12:18] <LarstiQ> hey vincent
[12:18] <adrighem> ehhh, hi?
[12:18] <LarstiQ> adrighem: what, we visit the same faculty and you don't recognise me! ;)
[12:18] <adrighem> Oh, okay.
[12:19] <LarstiQ> adrighem: you're part of the gnome nl translation team, right?
[12:19] <adrighem> LarstiQ: not only part, I'm the coordinator...but rosetta doesn't seem to agree.
[12:20] <LarstiQ> carlos: awake?
[12:20] <carlos> LarstiQ: hi
[12:20] <LarstiQ> carlos: can you help adrighem?
[12:20] <carlos> LarstiQ: sure, I didn't see his request ;-) Thanks
[12:20] <adrighem> Hi carlos. Can you create a dutch gnome team in rosetta?
[12:21] <adrighem> (nl)
[12:21] <carlos> adrighem: atm is a bit useless to do it because we are not importing GNOME's products
[12:21] <carlos> adrighem: but is ok to setup it now so you have it ready when we start doing those imports
[12:21] <LarstiQ> what are those imports waiting on?
[12:21] <adrighem> carlos: my thought exactly. ;)
[12:21] <carlos> adrighem: I guess you are the official coordinator in GNOME, right?
[12:21] <adrighem> carlos: yup
[12:22] <carlos> LarstiQ: having more time from me to expend on it...
[12:22] <LarstiQ> carlos: ah :)
[12:23] <carlos> adrighem: ok, confirmed that you are the coordinator
[12:23] <carlos> adrighem: did you create already a team in launchpad for that?
[12:23] <adrighem> carlos: no. I did not do that.
[12:23] <carlos> if the answer is no, please do it, naming it gnome-l10n-nl
[12:24] <carlos> so you are the owner of the team
[12:24] <carlos> and I will add it to the GNOME translation project group
[12:24] <adrighem> carlos: will do...one moment please.
[12:24] <carlos> adrighem: it should be a moderated team
[12:24] <carlos> so you only approve people that work with you in GNOME
[12:24] <carlos> and only those ones
[12:25] <carlos> I will not add anyone there, even If i'm asked to do it (In fact, I don't have rights to do it)
[12:25] <carlos> so you have full control of that team
[12:26] <adrighem> carlos: that's nice to know.
[12:29] <adrighem> carlos: the team has been created.
[12:30] <carlos> just a secon
[12:35] <carlos> second ;-)
[12:35] <carlos> I had a phone call
[12:35] <carlos> adrighem: done
[12:39] <adrighem> Ooooh, lemme check...
[12:42] <adrighem> carlos: thanks.
[01:03] <adrighem> And I am gone...
[01:09] <Kinnison> SteveA: There are tests for bug 47770 on my branch now
[01:09] <Ubugtu> Malone bug 47770 in launchpad-publisher ""raw-dist-upgrade" target does not support pockets" [Medium,In progress]  http://launchpad.net/bugs/47770
[01:09] <Kinnison> SteveA: care to have a look?
[01:10] <Kinnison> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/dsilvers/launchpad-repo/launchpad/bug-47770/full-diff
[01:10] <SteveA> Kinnison: yes, but not right now.  just off to lunch with bjorn
[01:11] <Kinnison> okay
[01:11] <Kinnison> thanks for the organisation yesterday btw
[01:11] <Kinnison> twas v. useful
[01:11] <SteveA> np
[01:58] <salgado> anybody up for a quick code review?
[02:01] <lifeless> sure
[02:05] <salgado> cool!
[02:05] <salgado> lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/fileFU4ZRj.html is to fix bug 48608 and a few other trivialities
[02:06] <salgado> (https://launchpad.net/products/shipit/+bug/48608)
[02:06] <LarstiQ> bogus product: https://launchpad.net/products/pssrajan
[02:07] <lifeless> salgado: 'for Macs' is a ittle misleading : it wont work on MacbookPlus
[02:09] <ddaa> "For Macs that are neither too new or too old, or for other computers that are like those Macs inside"?
[02:09] <salgado> lifeless, I agree, but this is what we're using everywhere --not only shipit. the DVDs and CD images for download are labeled like this
[02:11] <lifeless> does dvds_portlet return an HTML fragment or a tal fragment ?
[02:12] <salgado> HTML
[02:17] <lifeless> mailed to lp-reviwes.
[02:17] <lifeless> meh, thingy
[02:17] <lifeless> basically good, but missing tests.
[02:17] <lifeless> and I *know* that *you* know better.
[02:19] <salgado> you mean, tests for the changes I've done?
[02:19] <lifeless> specifically the DVD portlet
[02:19] <lifeless> it could be broken and we'd never know
[02:20] <jelmer> Strange - if I'm logged in, I can't access bug 38801, but if I log out, I can.
[02:20] <Ubugtu> Malone bug 38801 in nunit "nunit broken when using .Net 2.0 library" [Unknown,Unknown]  http://launchpad.net/bugs/38801
[02:20] <salgado> well, if by broken you mean some broken tal inside it, then we'd know because the pagetests for the /myrequest page would fail
[02:20] <lifeless> no, I mean, say the including template gets changed
[02:20] <lifeless> i.e. by a bad merge resolution.
[02:21] <lifeless> there are no tests that ensure the dvd templates are shown in the output for ubuntu/kubuntu and not for edubuntu.
[02:22] <salgado> yeah, that's right. so I guess it's better to test that the pages contain (or don't contain) some things from the portlet, right?
[02:22] <lifeless> right
[02:22] <lifeless> this is our current style of testing.
[02:22] <lifeless> and as such its fine ;).
[02:23] <salgado> btw, I'm filing a bug explaining why I didn't convert that pagetest to a new-style one. I wanted to and spent a good time on it, but there are some issues that I don't think are going to be easy to solve, so I'm leaving this for another merge
[02:24] <lifeless> sure. my main concern here is that there be a test which will fail if the new feature stops doing what its meant to
[02:49] <ddaa> lifeless: SteveA: can we have a quick meeting?
[02:49] <SteveA> ddaa: okay
[02:50] <ddaa> -> #launchpad-meeting
[02:59] <cprov> salgado: hi, will matsubara be around today or is he gone already ?
[03:00] <salgado> cprov, he's gone. he switched today with yesterday (which was a holiday)
[03:00] <cprov> salgado: uhm, okay. what about you ?
[03:00] <salgado> I switched monday with yesterday.
[03:02] <cprov> salgado: right, can you give a second oppinion about my last comment in bug #49789 ? I think it's worth to fix it ASAP ...
[03:02] <Ubugtu> Malone bug 49789 in xorg "Clicking on Codes of Conduct link in Launchpad crashes X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49789
[03:03] <salgado> sure
[03:04] <cprov> salgado: we don't have any nvidia card at office, do we ?
[03:05] <salgado> we do
[03:07] <SteveA> salgado: is kiko around?
[03:08] <salgado> SteveA, no
[03:09] <cprov> salgado: good, can you aditionally check what I suggested ? if you have time ... nonetheless I think we should fix the horizontal scroll evilness, don't you think ?
[03:16] <flacoste>  salgado: i see on PendingReviews that you have been assigned as my reviewer for my first bug patch!
[03:16] <flacoste> salgado: when do you think you will have time to take a look at it?
[03:18] <salgado> flacoste, I didn't see that. thanks for pinging me. if it's not too big I'll do it today, for sure
[03:18] <flacoste> thk! no its small, the biggest changes are to the tests that were modified to use testbrowser
[03:19] <salgado> cprov, I'll have a look, but I'm afraid I won't have time to fix it, so better wait for matsubara
[03:20] <cprov> salgado: okay, I'd do it myself if you have time for just confirming it.
[03:21] <salgado> cprov, well, at most I'd be able to confirm that it crash, but I wouldn't be able to tell for sure if what you suggest will avoid the crash
[03:22] <salgado> anyway, I'm turning another box on because I don't want mine to crash
[03:27] <cprov> salgado: ehe, good point, if the br-crew bug exists at all. It's amazing how popular nvidia is here, in br, everyone in ubuntu-br team uses it. I'm still in savage 4 age, yet
[03:29] <salgado> okay, so it doesn't crash my box with an nvidia card
[03:29] <cprov> salgado: but the pages still scrolling horizontally, doesn't it ?
[03:29] <salgado> yes, it does
[03:32] <cprov> salgado: do you think the <pre> idea would make it any better ?
[03:35] <salgado> cprov, probably, but I'm not sure it'd make it not crash
[03:35] <salgado> I'll try to test it with the proprietary nvidia driver
[03:37] <cprov> salgado: ahh, it might be the case of those guys, indeed
[03:45] <flacoste> who do I change the status of a bug in launchpad?
[03:46] <salgado> flacoste, you should have
[03:47] <flacoste> i thought too, maybe I'm just blind this morning, what is the GUI control that I should use?
[03:47] <salgado> flacoste, you have to click on the "Affects" column, to change its status
[03:47] <flacoste> wow!
[03:47] <salgado> and it's not because you're blind. it's because it's well hidden. :/
[03:47] <flacoste> found it, thanks!
[03:48] <flacoste> indeed, i would never have guessed it!
[04:12] <bradb> flacoste: That is one of Malone's bigger usability problems. We haven't yet managed to convinced the sab that changing bug status should be made visible.
[04:13] <bradb> bug 1095
[04:13] <Ubugtu> Malone bug 1095 in malone "Unnecessarily difficult to find how to change status or reassign a bug" [Medium,Confirmed]  http://launchpad.net/bugs/1095
[04:13] <flacoste> what's the rationale for keeping it hidden?
[04:13] <bradb> flacoste: I'm not sure.
[04:14] <bradb> flacoste: cool!
[04:14] <flacoste> i'm installing it now
[04:14] <bradb> I'm switching my desktop to KDE right now, for kicks.
[04:14] <bradb> I installed kubuntu on another machine yesterday, for more kicks
[04:14] <flacoste> brabd: (the plugin not your switch)
[04:15] <SteveA> bradb: ping
[04:16] <lifeless> ddaa: there are many possible failure conditions for the branch scanner.
[04:16] <lifeless> using get_revision_reconcile is a bad idea. Its designed solely for reconcile to use.
[04:16] <ddaa> lifeless: so far I assumed there were none. If the data got through the branch puller, it was valid.
[04:16] <ddaa> BTW
[04:17] <lifeless> EBADASSUMPTION. The data will be valid. That does not mean the scanner cannot fail.
[04:17] <lifeless> the puller could crash partway through a pull for instance; the puller server  can die during a scan run; the puller bzr version can be out of sync with the scanner version; the scanner can have bugs;
[04:18] <ddaa> puller crash: I thought bzr was designed to keep data consistent at all times
[04:19] <ddaa> puller server crash: it's a transient failure mode, there's already a case in the code to handle connection failures.
[04:19] <ddaa> etc.
[04:19] <ddaa> lifeless: you are giving ways the code can fail because of deployment issues and bugs
[04:20] <ddaa> I was saying that the branch scanner should not normally fail.
[04:20] <ddaa> different issues
[04:20] <ddaa> at the moment, those CorruptRepository errors are situation where the branch scanner _cannot_ complete its job regardless of bugs, just because the data is bad.
[04:21] <flacoste> newbie question: how do I generate a TAGS file for the launchpad project?
[04:21] <ddaa> make tags
[04:21] <ddaa> hu, sorry: make TAGS
[04:21] <flacoste> right!
[04:21] <lifeless> ddaa: I think it is unwise to use unsupported apis in bzr in the branch scanner.
[04:21] <flacoste> thanks!
[04:22] <lifeless> beyond that its your call.
[04:23] <ddaa> sure, that sounds bad
[04:23] <lifeless> get_revision_reconcile is not a supported api.
[04:23] <ddaa> lifeless: is there a way to avoid putting corrupt data in the supermirror?
[04:23] <lifeless> its not corrupt.
[04:24] <lifeless> its almost certain that you are hitting those branches during the middle of a pull by the supermirror
[04:24] <ddaa> well, CorruptRepository make it sound like something is corrupt
[04:24] <ddaa> lifeless: no
[04:24] <ddaa> this is a repeatable error we have with several branches
[04:24] <lifeless> I suspect that nuking the mirrored copy will correct this
[04:24] <bradb> cprov, carlos: I want to set up an xmlrpc playground on mawson. Are you doing on LP work on mawson that I might conflict with?
[04:25] <lifeless> or running bzr reconcile on them by hand
[04:25] <carlos> bradb: I only use mawson as a gateway to asuka and I'm using my own lp tree
[04:25] <carlos> bradb: so don't worry about my scripts
[04:25] <ddaa> lifeless: I guess so, but I'd rather not run bzr reconcile on vostok
[04:25] <SteveA> kiko-afk: ping
[04:25] <ddaa> lifeless: I'm interested in way to _prevent_ that situation from occuring
[04:26] <ddaa> lifeless: so it does not become yet another operational nightmare
[04:26] <lifeless> ddaa: bzr pull prevents it since 0.8
[04:26] <bradb> carlos: cool
[04:26] <cprov> bradb: there is a RF HEAD work tree there, have fun, I'm not using it right now
[04:27] <ddaa> lifeless: ah, nice. I'll give you a command line to run on vostok to clear the data
[04:36] <bradb> cprov: thanks
[04:54] <BjornT> SteveA, kiko-afk: https://chinstrap.ubuntu.com/~dsilvers/paste/filehugREW.html
[05:04] <BjornT> kiko-afk: the issued sql queries: https://chinstrap.ubuntu.com/~dsilvers/paste/filerhVQre.html
[05:12] <flacoste> bradb_: the CTAGS plugin isn't up to date with the latest kate API -> doesn't compile :-(
[05:14] <bradb_> flacoste: bummer
[05:24] <salgado> flacoste, BjornT, I have a question about the support tracker:
[05:24] <salgado> can I link more than one bug to a single ticket?
[05:24] <flacoste> you should be able to yes
[05:25] <flacoste> the bugs attribute is a list
[05:25] <flacoste> so if the interface doesn't let you, it's a bug
[05:25] <flacoste> you can only create one bug from a support request though
[05:26] <salgado> right, and this is because the bug is created using the ticket's title and subject, verbatim?
[05:26] <salgado> then it wouldn't make sense to create two identical bugs
[05:37] <jordi> carlos?
[05:37] <carlos> jordi: ?
[05:38] <kiko-afk> salgado, can't you edit them?
[05:38] <kiko-afk> BjornT, looking
[05:39] <salgado> kiko, not when filing the bug from a ticket
[05:39] <kiko> salgado, flacoste: that sounds wrong to me!
[05:39] <BjornT> kiko: the problem seems to be caused by the owner being None for the missing message
[05:40] <kiko> BjornT, is message.owner not null?
[05:40] <flacoste> kiko: file a bug on launchpad-support-tracker :-)
[05:40] <kiko> flacoste, doing so as we speak
[05:41] <kiko> BjornT, so message.owner is not null in message.py
[05:41] <kiko> BjornT, that's why a regular join is emitted
[05:41] <kiko> instead of a left outer join
[05:41] <kiko> BjornT, can you change that and try again?
[05:41] <kiko> BjornT, alternatively, enforce message.owner is not null in the database!
[05:42] <BjornT> kiko: ok, i'll try to change that.
[05:42] <kiko> BjornT, do you know if message.owner is really nullable?
[05:44] <BjornT> kiko: i can't see why message.owner should be nullable. can you check if we have any messages in production with a null owner?
[05:44] <kiko> will do so now.
[05:45] <SteveA> even so, it is surely a bug that foo.count() differs from len(list(foo))
[05:46] <kiko> SteveA, do you understand why it happens?
[05:46] <BjornT> removing notNull=True fixes the problem.
[05:46] <kiko> BjornT, sure.
[05:48] <kiko> SteveA?
[05:49] <SteveA> what?
[05:49] <kiko> do you understand why it happens?
[05:49] <SteveA> no
[05:49] <SteveA> i can look at the code
[05:49] <kiko> ok. do you want to call me to follow up on other stuff as well?
[05:50] <kiko> SteveA?
[05:50] <SteveA> sure, we can have a call
[05:50] <kiko> ring rin
[05:52] <SteveA> kiko: looks like a prejoin bug
[05:52] <kiko> SteveA, not necessarily, but maybe.
[05:52] <SteveA> it's sticking WHERE terms where they don't belong
[05:52] <kiko> what?
[05:53] <SteveA> (Pdb) bug_two.messages.count()
[05:53] <SteveA> 3
[05:53] <SteveA> WHERE Message.id = BugMessage.message and
[05:53] <SteveA>     BugMessage.bug = Bug.id and
[05:53] <SteveA>         Bug.id = 2
[05:53] <SteveA>
[05:53] <SteveA> (Pdb) len(list(bug_two.messages))
[05:53] <SteveA> 2
[05:53] <SteveA> WHERE
[05:53] <SteveA> _prejoin0.id = Message.owner AND  Message.id = BugMessage.message and
[05:53] <SteveA> BugMessage.bug = Bug.id and
[05:53] <SteveA> Bug.id = 2
[05:53] <SteveA>
[05:53] <kiko> SteveA, as I told BjornT, the database schema is wrong
[05:54] <kiko> BjornT, there are no messages with null owners in the database.
[05:54] <SteveA> the prejoin stuff should barf rather than give incorrect results, then
[05:54] <kiko> SteveA, let me think about this for a second.
[05:54] <SteveA> kiko: office or mofo?
[05:54] <kiko> office
[05:54] <kiko> BjornT, you can add the not null constraint.
[05:57] <BjornT> kiko: yeah, i'll do that later. for this patch i'll simply set an owner in sampledata, since stub isn't around to approve the db patch.
[06:06] <doko> carlos: ping
[06:07] <carlos> doko: pong
[06:09] <doko> carlos: about the helpcontent2 statistics, did people translate any significant part?
[06:10] <carlos> doko: sorry, I hadn't time to look at it. I'm finishing some open branches that I would want to have merged before Paris and I need to write down a spec for next week...
[06:10] <carlos> doko: I would say... Ignore the updates from Rosetta and build new language packs now and we will include them later
[06:11] <doko> ok
[06:32] <bradb> hey cool. i clicked on a message in my inbox in kmail, dragged it to a folder, clicked "Move Here", and all my Inbox messages seem to have disappeared
[06:33] <lifeless> rockin
[06:37] <ddaa> bradb: embrace the love of Thunderbird
[06:37] <ddaa> least aggravating GUI mail client I have tried so far
[06:37] <bradb> phew, restarting kmail brought them back
[06:38] <bradb> applying filters on all messages in kmail over imap makes it behave in ways i've never seen any mail app behave before
[06:39] <ddaa> some mail client seem to have trouble with the notion that IMAP is meant to be _online_
[06:45] <kiko> offline imap is scary
[06:45] <sivang> ddaa: problems with evo?
[06:46] <ddaa> unchecked memory consumption, sigsev almost every time when quitting (and losing recent change in message status), insufficient ability to walk and chew gum, sluggish response
[06:47] <ddaa> leaving around spamd instances when crashing
[06:47] <ddaa> incredibly slow when processing massive numbers of messages
[06:48] <ddaa> storing state outside of the IMAP data
[06:48] <ddaa> (and losing it sometimes)
[06:52] <bradb_> hm, apparently there are tools for compressing the contents of a directory before sending them over the wire. perhaps i'll use those instead.
[06:56] <lifeless> ddaa: I have few problems but they annoy the heck out of me when they happen
[06:56] <lifeless> ddaa: Ihave 47K messages in INBOX
[06:56] <ddaa> lifeless: evo is fast when it has generated its caches
[06:57] <ddaa> but some operations (e.g. setting the label on several thousand messages) and building the caches take forever
[06:58] <kiko> bradb, BjornT, for the record, fixed bug 1555; just submitted off to spiv for review.
[06:58] <Ubugtu> Malone bug 1555 in launchpad "BugMessage.selectOneBy doesn't work as expected" [Medium,Confirmed]  http://launchpad.net/bugs/1555
[06:58] <ddaa> also, it has sometimes trouble figuring out that other clients have modified the IMAP boxes, and then I need to remove the cache...
[07:12] <lifeless> I'm offline until paris, phone/sms me in emergencies and I'll arrange 'net.
[07:16] <sivang> lifeless: have a nice trip, see you there :)
[07:46] <SteveA> carlos: ping
[07:47] <carlos> SteveA: pong
[07:47] <SteveA> kiko: ping
[07:54] <SteveA> kiko: ping
[08:03] <kiko> SteveA, pong
[08:03] <kiko> what's up?
[08:19] <Ubugtu> Malone bug 45310 in bzr "Branching large repository uses a ridiculous amount of RAM" [High,Unconfirmed]  http://launchpad.net/bugs/45310
[08:19] <flacoste> s/gives/gives up/
[08:40] <bradb_> now kmail is turning my messages into zombies!
[08:40] <bradb_> I click on a message, and suddenly it says "No Subject" and "Unknown" sender
[08:42] <flacoste> bradb_: what is your IMAP server?
[08:42] <bradb_> pobox
[08:42] <flacoste> hmm, i don't know about that one
[08:42] <bradb_> this is a disaster
[08:43] <flacoste> bradb_: look into the the server settings, there might be an option in there to tweak the protocol usage...
[08:43] <flacoste> (in kmail, i mean)
[08:44] <bradb_> flacoste: have you ever seen this kind of thing?
[08:45] <flacoste> i have seen messages "disappearing" from the inbox with UW-Imap when a mailbox was accessed from two clients
[08:45] <flacoste> (it only disappeard in the GUI though)
[08:47] <kiko> I use mbox and mutt
[08:47] <kiko> 1970s technology that WORKS
[08:48] <bradb> kiko: i need imap though
[08:49] <kiko> "need"
[08:49] <bradb> soho business owner, on the go, etc.
[08:49] <kiko> as I said "need"!
[08:49] <SteveA> bradb: soho business owner?
[08:49] <SteveA> like a strip-club magnate?
[08:49] <bradb> i hope nobody took that last statement seriously :P
[08:49] <kiko> poker table enterpreneur
[08:50] <bradb> heh
[08:50] <bradb> i haven't played in too long
[08:50] <bradb> NO SUBJEFAT GAH
[08:52] <kiko> less pitiful than mine with 500 incoming
[08:53] <bradb> kiko: KMail will make your problems go away
[08:54] <kiko> yeah I believe you
[09:05] <kiko_bsb> salgado, yes, correct.
[09:14] <salgado> what beneffits would we have by doing that?
[09:14] <salgado> kiko_bsb, ^
[09:14] <salgado> benefits too
[09:16] <kiko_bsb> salgado, doing it in the same way as everybody else does?
[09:20] <salgado> hmmm. don't you think having to check whether mirror_admins is None in every callsite, or having a getMirrorAdmins() method to do that is enough reason to do it differently?
[09:22] <kiko_bsb> salgado, well, I don't know about "every callsite"
[09:22] <kiko_bsb> how many callsites would you have to change?
[09:22] <kiko_bsb> I think it makes the distribution nicer to set up
[09:22] <kiko_bsb> no need to worry about this stuff until it becomes necessary
[09:23] <kiko_bsb> anyway, that's just a fluff comment
[09:23] <kiko_bsb> but you /are/ being inconsistent from bug and security contact
[09:23] <kiko_bsb> fwiw
[09:23] <kiko_bsb> IMNBWAGD though
[09:24] <salgado> there's at least three callsites, as we're doing the permission check manually
[09:24] <flacoste> salgado: regarding the warning message to the user accessing the +makebug page when there are already bugs linked to it
[09:25] <flacoste> I place the message in a div with class="warning message" ?
[09:27] <salgado> maybe just informational message
[09:27] <salgado> hmmm. I'm not sure
[09:28] <salgado> that's a question for the great mpt!
[09:28] <flacoste> he's in a sprint now
[09:28] <kiko_bsb> well
[09:28] <kiko_bsb> think about it
[09:28] <kiko_bsb> is it a warning
[09:28] <kiko_bsb> or is it something normal?
[09:29] <flacoste> it's an error
[09:29] <kiko_bsb> there's also error message
[09:29] <kiko_bsb> I believe.
[09:29] <flacoste> well, it depends how you view it because the only way the user is going to get there is if he enters the url himself
[09:30] <salgado> or a bookmark
[09:30] <flacoste> bookmark a form?
[09:30] <kiko_bsb> just send him to jail, do not pass GO, do not collect R$200
[09:30] <flacoste> anyway, I think that a concept in Launchpad is that the URL is part of the GUI? so, in that case, we should consider it a normal action then
[09:31] <flacoste> so in that case either error or informational should be used, i think
[09:32] <kiko_bsb> I say it's an error
[09:32] <flacoste> fine, I'll use error
[09:33] <salgado> yeah, I was concerned that we could be presenting an error for a user who actually clicked on the link (suppose he had a stale ticket page), but the chance of it happening is too small for us to consider it, I think
[09:40] <flacoste> salgado: what do you think if I implement the check in the view, that way the user would be redirected to the ticket page with the error message
[09:40] <flacoste> instead of having a blank page with the error message (the related bug portlets doesn't appear in that page which would be kind of helpful)?
[09:49] <flacoste> bradb: is there a mail interface to Malone?
[09:49] <flacoste> (like debbugs)?
[09:50] <bradb> flacoste: yeah
[09:51] <bradb> flacoste: https://help.launchpad.net/UsingMaloneEmail
[09:52] <flacoste> great!
[09:54] <flacoste> bradb: about there is entry in the LauncpadHackingFAQ which is relevant to yesterday's question about where to put tests relevant to corner-case bug:
[09:54] <flacoste> Where should I put my tests: in a `test_foo.py` module, or a `foo.txt` doctest file?
[09:54] <flacoste>     *
[09:54] <flacoste>       You should prefer doctests. A good rule of thumb is that test_*.py modules are best for tests that aren't useful for documentation, but instead for increasing test coverage to obscure or hard-to-reach code paths.
[09:54] <flacoste>       It is very easy to write test code that says "check foo does bar", without explaining why. Doctests tend to trick the author into explaining why.
[09:55] <flacoste> I guess that yesterday's error +editstatus oopses when a product uses malone and has a support contact would qualify for a test_*.py module
[09:55] <bradb> true. it seems people rarely write tests other than doc or pagetests these days, though maybe i haven't been watching enough TV
[09:57] <flacoste> we could added that to a tests/test_malone_bugs.py file
[09:59] <flacoste> def test_bug49891
[10:02] <bradb> flacoste: you should ask SteveA or lifeless where exactly to put tests for corner case bugs that don't fit in doc or pagetests
[10:02] <bradb> I think a convention that links the test name to a bug is interesting
[10:11] <salgado> flacoste, yeah, that's a good idea. :)
[10:12] <flacoste> which one: putting the guard in the view or the naming convention for tests covering corner case bug report?
[10:13] <flacoste> bradb: the email interface seems very cool!
[10:14] <bradb> flacoste: it's one of the better parts of Malone, yeah. :)
[10:14] <salgado> flacoste, the guard in the view
[10:14] <flacoste> glad you like it, because it's done :-)
[10:15] <salgado> hmmm. the naming convention sounds nice too. although it may be a problem if you're working offline
[10:16] <flacoste> putting in comments the summary of the bug would probably be appropriate
[10:16] <salgado> if we could make sure every test had at least a very basic docstring, it won't be a problem
[10:16] <salgado> yeah, agreed
[10:19] <bradb> when i said "linking" i didn't mean URLs :)
[10:19] <bradb> i mean using names to describe things clearly
[10:19] <bradb> it's useful, IMHO, to be able to know what regression, e.g., which bug, a test is preventing by reading its name
[10:20] <bradb> s/"linking"/"links"/
[10:46] <flacoste> salgado-brb: do you what to take a look at the new branch or should I submit it to PQM?
[11:01] <flacoste> where do I find the documentation on how to submit a request to PQM?
[11:02] <flacoste> https://launchpad.canonical.com/PQMInstructions seems not up to date
[11:02] <carlos> flacoste: The best way to do it is to use pqm-submit plugin for bzr
[11:03] <flacoste> tnx!
[11:03] <salgado> flacoste, sure, I can have a quick look
[11:03] <flacoste> carlos: where do I find this plugin?
[11:03] <flacoste> do you want me to send you the diff?
[11:04] <salgado> flacoste, http://bzr.arbash-meinel.com/plugins/pqm-submit/
[11:04] <salgado> flacoste, or just paste it on chinstrap
[11:04] <flacoste> salgado: how does pasting chinstrap work?
[11:05] <salgado> flacoste, you can do a bzr diff | utilities/paste (if you've already read that script and have a file with the user/password)
[11:05] <salgado> flacoste, otherwise you can just use https://chinstrap.ubuntu.com/~dsilvers/paste/
[11:08] <flacoste> salgado: do you prefer a diff to what you saw or the complete diff?
[11:09] <salgado> I guess just a diff from what I saw
[11:09] <salgado> whatever is easier
[11:10] <flacoste> it will be the complete diff
[11:10] <flacoste> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filedDDF8X.html
[11:15] <salgado> flacoste, I think the check would be better done inside the view's initialize() method
[11:16] <flacoste> does a LaunchpadView has a initialize method?
[11:16] <salgado> yes
[11:16] <salgado> lib/canonical/launchpad/webapp/publisher.py
[11:16] <flacoste> ok, can be done
[11:18] <salgado> because I think what's expected from a process() method is to actually process the submitted data, while the check would be something that always needs to be performed
[11:19] <flacoste> indeed
[11:19] <flacoste> i'll move it to a initialize method
[11:19] <bradb> slightly cleaner might be to have a process_form method, which calls a validate and process method
[11:19] <bradb> because intialize isn't really any better a place for validation code, IMHO
[11:20] <bradb> (and at least it would smell more like a GeneralFormView)
[11:20] <salgado> another thing... you've changed ticket-makebug.pt to use 4 spaces of indentation. although we definitely have lots of templates using 4 spaces of indentation, I think we're only using 2 spaces now
[11:21] <salgado> bradb, that's not really validation of the form, the check we're talking about
[11:21] <salgado> it checks if the page should be rendered or if the user should be redirected
[11:21] <flacoste> salgado: yes, the space is a mess up caused by adding a conditional and then removing it
[11:22] <flacoste> i should have reverted before putting my changes in
[11:23] <bradb> salgado: ah, ok
[11:26] <flacoste> salgado: thanks for the review! i'll implement those changes and submit it to PQM on monday
[11:26] <salgado> flacoste, you're welcome! nice work, btw. :)
[11:26] <flacoste> tnx! pair programming with bradb yesterday jumpstarted the whole thing!
[11:27] <bradb> we were agile
[11:27] <bradb> (tm)
[11:27] <flacoste> good week-end everybody!
[11:28] <flacoste> bradb: have a nice trip to Paris and see you in London!
[11:28] <bradb> flacoste: thanks, see you there :)
[11:29] <salgado> see ya!
[11:29] <Keybuk> znarl, elmo: ping
[11:29] <Keybuk> uh, ww
[11:33] <ddaa> Keybuk: what is that mail you sent me about?
[11:33] <Keybuk> no idea, something about bzrk it looked like
[11:34] <ddaa> it looks like nothing to me, there's no attachement to your mail


[06:46] <dholbach> good morning
[06:58] <fgimenez> good morning
[08:06] <rickspencer3> mvo, https://bugs.launchpad.net/snappy/+bug/1465724
[09:00] <JamesTait> Good morning all; happy Monday and happy Onion Rings Day! 😃
[10:25]  * ogra_ grumbles at lool for including HTML tables in mails
[10:25] <lool> the joys of HTML emails
[10:26] <zyga> ogra_: it's the company 2.0
[10:26] <zyga> ogra_: without shell
[10:26] <zyga> ogra_: with html
[10:26] <zyga> ogra_: about the removal of {dpkg,apt,bash,python}
[10:26] <zyga> ogra_: I'd love to have a roadmap for that
[10:26] <ogra_> zyga, and without answering inline in emails :P
[10:26] <zyga> ogra_: for people like me
[10:26] <zyga> ogra_: to know when something must be ready on my side
[10:26] <zyga> ogra_: so that my app continues to work
[10:26] <zyga> ogra_: and I think for everyone in the dev community
[10:26] <ogra_> zyga, simpoly dont make use of them :P
[10:26] <zyga> ogra_: as any time you remove stuff from the image
[10:26] <zyga> ogra_: you break compatiblity
[10:27] <ogra_> then you wont be bitten by their removal
[10:27] <zyga> ogra_: that's unrealistic, go rewrite my software for me
[10:27] <ogra_> no we dont
[10:27] <zyga> ogra_: sure, that's just reality
[10:27] <ogra_> we never guranteed compatibility beyond the snappy command
[10:27] <ogra_> no it is not
[10:27] <zyga> ogra_: well, then snappy is a lousy thing to target
[10:27] <zyga> ogra_: it's worse than docker
[10:27] <zyga> ogra_: just bring your own distro
[10:27] <ogra_> reality ios that the core system is abused as a dependency where it shouldnt
[10:28] <zyga> ogra_: well, regardless of what you think about what is in the core and what can be used
[10:28] <zyga> ogra_: if the core grants you nothing
[10:28] <zyga> ogra_: then it's not a core
[10:28] <ogra_> it doesnt
[10:28] <zyga> ogra_: it's not a thing at all
[10:28] <ogra_> it is enough OS to boot and to run the snappy command ... that is all it is
[10:28] <zyga> ogra_: great, who wants that?
[10:28] <ogra_> and thats all we promise
[10:29]  * zyga is grumpy about that
[10:29] <ogra_> thats the design of snppy
[10:29] <ogra_> *snappy
[10:29] <ogra_> it hasnt been described differently anywhere
[10:29] <zyga> ogra_: this is like putting people in an empty room, not giving them any tools to fill the room and say, 'enjoy'
[10:29] <ogra_> zyga, that is why your snap should include everything it needs, a snap needs to be self contained
[10:30] <zyga> ogra_: IMO we should have started with the empty room and added stuff, we started with a room with some things labelled "don't touch" (but nobody stopped you if you did)
[10:30] <ogra_> not dependencies ... not even on core
[10:30] <zyga> ogra_: microsoft and apple learned the hard way that's not the way to do it
[10:30]  * zyga feels that snappy is not useful withouy stuff like snapcraft being done on day one
[10:30] <ogra_> we couldnt start with the empty room ... simply because we use legacy tools in core that we cant immediately replace
[10:30] <ogra_> i.e. system-image
[10:30] <zyga> ogra_: ha, but you ask everyone to replace theirs
[10:30] <zyga> ogra_: I see what you do
[10:31] <zyga> ogra_: but it's hard to work in this world
[10:31] <ogra_> we never and nowhere asked anyone to add a dependency on core ... quite the opposite
[10:31] <zyga> ogra_: the problem is in wording
[10:31] <zyga> ogra_: show me a link on .ubuntu.com that lists what the core provides
[10:31] <zyga> ogra_: and a big warning that says everything else is not supported
[10:32] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/wily-preinstalled-core-armhf.manifest
[10:32] <zyga> ogra_: and that {insert name of big thing people see and assume it's there} will go away
[10:32] <zyga> ogra_: be serious
[10:32] <ogra_> nothing is supported
[10:32] <zyga> ogra_: I want high-level thing
[10:32] <zyga> ogra_: on ubuntu.com, in html
[10:32] <zyga> ogra_: with explanation
[10:32] <zyga> ogra_: nobody understands snappy because of failure of communication
[10:32] <ogra_> i am serious, that is the list of bits core provides ... but that doesnt mean you should depend on anything in there ... this isnt dpkg
[10:32] <zyga> ogra_: of what snappy is and isnt
[10:33] <zyga> ogra_: and each time you ship a new core that has one bit less, something that works now will break -- and that's fine, it's just a failure to communicate this correctly
[10:34] <ogra_> if it breaks the creator of that "something else" made a mistake ...
[10:34] <zyga> ogra_: and all those issues just contribute to the fact that snappy is hard to taget today, because of misunderstandings and missing tooling
[10:34] <ogra_> since ... again, a snap needs to be self contained
[10:34] <zyga> ogra_: no, we're all people, nobody cares, if to make something great you need to make it great for developers and all the other people, or nobody will care
[10:34] <zyga> ogra_: is libc assumed?
[10:35] <zyga> ogra_: is this written down anywhere? any design doc? a white paper? anything that I can read apart from being grumpy to collegues?
[10:35] <zyga> (which I'd much much rather not do)
[10:36] <ogra_> it surely is ... it is the fundamental design principle of snappy
[10:36] <ogra_> (now dont ask me where in these 100s of google docs ... )
[10:37] <zyga> so how can anyone write a good snap todaty
[10:37] <zyga> if we as a company failed to communicate this clearly
[10:38] <ogra_> by including everything you need for execution inside your snap
[10:38] <zyga> I shouldn't be doing this, you are not at fault here
[10:39] <ogra_> well, i'm promoting it ... and on purpose (and i knew that there will be resistance but i want to get peoples minds straight before the world falls apart because we remove something)
[10:39] <zyga> ogra_: don't mistake resistance
[10:39] <zyga> ogra_: with walking blindfolded over a minefield
[10:40] <zyga> ogra_: I'm forced to deliver somthing onto a platform I don't fully understand, that is changing, that has no tooling, that is totally barren (by design) -- this is frustrating as a developer experience
[10:40] <zyga> ogra_: it seems to me that the best way to do what I want is to just ship a debian chroot until some form of better tooling exists, maybe, someday
[10:41] <ogra_> zyga, well, one reason for me working on py-snapper (or node-snapper) or ted and mike working on snapcraft, is to solve that ... we are just not there yet with the tooling
[10:41] <ogra_> you are a pre-early-adopter here ...
[10:42] <ogra_> you cant ship a debian chroot ... i dont think the security policy will allow chrooting ... you would have to depend on a container framework like docker or lxc
[10:42] <zyga> ogra_: and one that has a large app to port
[10:43] <zyga> ogra_: neither py-snapper nor anything like that will help me as my app is just more complex than that and relies on a zoo of tools
[10:43] <ogra_> then you need to ship that zoo
[10:43] <zyga> ogra_: in docker?
[10:43] <ogra_> by using deb2snap or whatnot
[10:43] <ogra_> or in docker
[10:43] <zyga> ogra_: deb2snap ~30-50 packages
[10:44] <zyga> ogra_: into one huge snap (if that's possible by deb2snap)
[10:44] <zyga> ogra_: then path everything to understand new executable names
[10:44] <ogra_> i think it is, AFIK deb2snap can take a package list
[10:44] <ogra_> and it mangles the executable names, preload and library paths for you
[10:52] <sergiusens> ogra_: zyga 15.04 will not break; rolling on the other hand...
[10:53] <ogra_> right
[10:53] <ogra_> but even if it will not break it is wrong to depend on core even there :)
[10:55] <ogra_> sergiusens, btw, putting files into /system/boot/uboot does indeed not work since we have a-b mounted on top :)
[10:57] <sergiusens> ogra_: if you are going to put it in /system/boot/uboot maybe just target the file to no where and it will land there (but there would be no a/b logic for these)
[10:58] <sergiusens> ogra_: you wont ever be able to get anything in the store that relies on dpkg at least
[10:58] <ogra_> well, i'm pondering to just ship it in /lib/modules somewhere
[10:59] <ogra_> but we should have some plan for changelogs, configs and licenses
[11:10] <ogra_> sergiusens, bug 1467474
[12:44] <zyga> ogra_: can I bug you for a moment about snappy and wifi?
[12:44] <zyga> ogra_: from what you said earlier
[12:45] <zyga> ogra_: it seems that I need to package things like wpa supplicant and all the IP tools
[12:45] <zyga> ogra_: is that correct?
[12:45] <zyga> ogra_: the goal is to make an app that can use wifi
[12:47] <zyga> ogra_: (and to be precise, for certification, what kind of base feature set should I test for when the hardware says that wifi is supported)
[12:48] <ogra_> zyga, wpa_supplicant is shipped (hardware enablement is something that goes into core indeed)
[12:48] <ogra_> (at least generic bits of it )
[12:48] <zyga> ogra_: ah, so what kind of hardware enablement for wifi can any app rely on?
[12:48] <ogra_> and you should have all tools needed to make a wlan come up
[12:48] <zyga> ogra_: or networking in general, what kind of IP tools do we plan on supporting
[12:48] <zyga> ogra_: ok, that's good to know
[12:49] <zyga> ogra_: can you tell me how this is all supposed to work according to you
[12:49] <ogra_> though this should not be done by your snap i guess ... but rather via the owem snap in some way
[12:49] <ogra_> *oem
[12:49] <zyga> ogra_: e.g. at which level do apps come in
[12:49] <zyga> ogra_: and at which level should we test
[12:50] <zyga> ogra_: the oem snap ships kernel image, modules and support bits, correct? can it also ship commands/scripts?
[12:50] <ogra_> no, it ships bootloader and dtb files (and their overlays)
[12:50] <ogra_> kernel is in a separate part
[12:50] <zyga> ogra_: ah, so everything goes to os snap?
[12:50] <ogra_> (currently the device tarball)
[12:50] <zyga> ogra_: note: please separate current limitations
[12:51] <zyga> ogra_: from the design
[12:51] <ogra_> (soon to be its own snap too)
[12:51] <zyga> ogra_: as the cert should work beyond 15.04
[12:51] <zyga> ogra_: (at least without major changes)
[12:51] <zyga> ogra_: hmm, wait, new snap? (I though minimal system has three snaps: os + oem + gadget)
[12:52] <ogra_> so technically -> hardware enablement should happen inside the core image itself via the owm snap ... wifi configuration should happen via snappy config of the core snap i guess ... your app snap should only make use of the preconfigured hardware then
[12:52] <ogra_> *oem
[12:52] <ogra_> (whats up with me today not being able to type oem)
[12:53] <zyga> ogra_: :D
[12:53] <zyga> ogra_: ok, so snappy config (yaml) is how apps can reconfigure network? (I didn't know about that part)
[12:54] <ogra_> now there are some grey areas ... where your app snap needs to configure hardware ... (set the default resolution for a webcam that you need to set via echoing into a /sysfs node or some such ... ) not sure how that should be handled
[12:55] <zyga> ogra_: it depends on a product, if I wanted to build a STB device on top of snappy I'd have to handle network setup
[12:55] <ogra_> i havent played personally with our hardware access story, i know some bits of that landed though and enable you to use it
[12:55] <zyga> ogra_: (though perhaps in a private framework for network that my app could talk to)
[12:55] <zyga> ogra_: for certification, I'm trying to see what's the low level stuff we need to test
[12:55] <ogra_> yeah, something like that
[12:55] <zyga> ogra_: and verify through the programme
[12:55] <zyga> ogra_: when we say "wifi on $product works" what did we test?
[12:56] <zyga> ogra_: and what did we specifically left out?
[12:56] <ogra_> the prob here is that all our implementations are still rather theoretic ... while they are there we dont have much code beyond simple examples using them yet
[12:56] <zyga> ogra_: in the past I assumed we'd be testing at the framework level but that's no longer true
[12:56] <ogra_> there is a webcam example that might give some insight
[12:56] <zyga> ogra_: so what would be your advice, to wait and not create the programme?
[12:56] <zyga> ogra_: or to specify $something and just go with it for 15.04
[12:56] <ogra_> no, to challenge the current implementation by trying to implement it with whats there
[12:57] <zyga> ogra_: webcams are going to be under generic USB host capability, along with lots of other products
[12:57] <ogra_> (would be my way)
[12:57] <ogra_> to find the flaws and issues with what we created and fix them
[12:57] <zyga> ogra_: ok, if that's what you say then this is important feedback, so far we've been working on different assumptions
[12:57] <zyga> ogra_: as in, come up with requirements and start writing tests right now
[12:58] <zyga> (btw, I used deb2snap for plainbox, got 154MB archive, didn't test it yet)
[12:58] <zyga> (and it looks quite like a chroot I was thinking about earlier)
[12:58] <ogra_> yeah, for now snaps will still be rather big :)
[12:58] <ogra_> deduplication on all levels will help with that some day
[12:59] <zyga> ogra_: $now + 1 ;-)
[12:59] <ogra_> (but thats not there yet))
[12:59] <zyga> ogra_: who's working on the hardware design side of snap
[12:59] <ogra_> until then i fear we have to live with giantic snaps on disk :)
[12:59] <ogra_> well, there were some mails from jdstrand_ about that
[12:59] <zyga> on the mailing list?
[13:01] <ogra_> yep
[13:38] <seb128> slangasek, you around to help me with some uefi snappy personal boot issues? ;-)
[13:39] <ogra_> about time that x86 switches to uboot :P
[13:39] <seb128> ahah
[13:39] <ogra_> all these UEFI issues all the time
[13:43] <seb128> slangasek, the bios lists the usb stick correctly but selecting it displays a "error: file "/boot/" not found" then gives a grub shell rather that the boot menu
[14:09] <elopio> good morning.
[14:11] <tedg> Morning elopio!
[14:15] <elopio> hey tedg!
[14:16] <elopio> fgimenez: lets skip our call today. I have a good bunch of emails to read.
[14:17] <fgimenez> hi elopio, ok
[14:45] <fgimenez> elopio, any luck with the cross compilation?
[14:46] <elopio> fgimenez: I've just had a successful build, a couple of minutes ago.
[14:46] <elopio> Chipaca: ^ it seems it was actually a python problem, that maybe barry fixed.
[14:47] <fgimenez> elopio, great! should it work with the command we were using?
[14:48] <elopio> fgimenez: oh, wait, no, I've just run it in amd, not cross compile.
[14:48]  * elopio tries again.
[14:49] <Chipaca> elopio: i'm shocked. will need to sit down for a bit.
[14:49] <barry> elopio, Chipaca hi
[14:52] <elopio> fgimenez: barry: Chipaca: now I get a problem from golang-go: http://paste.ubuntu.com/11757173/
[14:53] <Chipaca> barry: hi
[14:53] <Chipaca> elopio: could you pastebin the postinst?
[14:59] <elopio> Chipaca: http://paste.ubuntu.com/11757206/
[15:04] <zyga> ogra_: I'm on image .3, I see there's wpa_supplicant there, there's no iw* tools though
[15:04] <zyga> ogra_: how would one, in practice, get wifi to work?
[15:06] <ogra_> i think there si some blog post about how thats done
[15:06]  * ogra_ has never needed wifi yet
[15:08] <elopio> Chipaca: https://www.goodreads.com/book/show/25676397-designing-connected-products
[15:12] <zyga> ogra_: any links? I'm looking around but found only similar questions
[15:12] <ogra_> i think rickspencer3 had one recently
[15:13] <ogra_> (thats still from before we added wpa_suppl. to the image though, so it has some ill instructions about making the image writable etc ... the second half should just work though)
[15:14] <zyga> ogra_: wpa_supplicant is there but perhaps that's not enough (iwconfig is not there)
[15:14] <ogra_> what for aourl you need iwconfig ?
[15:14] <ogra_> *would
[15:14] <ogra_> tsk ..
[15:14] <zyga> ogra_: not sure, probably to set the AP data
[15:15] <ogra_> you dump your wlan config into /e/n/i.d/ and thats it
[15:15] <zyga> ogra_: interfaces?
[15:15] <zyga> ogra_: to /etc/network/interfaces?
[15:15] <ogra_> there were discussions about moving away from /e/n/i to systemd's network manager tool
[15:15] <ogra_> interfaces.d ... but yeah
[15:16] <zyga> ogra_: but that stuff relies on wireless-tools
[15:16] <zyga> ogra_: and without it the hooks won't do anything
[15:16] <zyga> ogra_: dpkg -L wireless-tools
[15:16] <zyga> ogra_: grep | if-post-(up|down)
[15:18]  * zyga cannot find anything on google about rick's blog post
[15:19] <ogra_> http://askubuntu.com/questions/585790/how-to-connect-wifi-network-from-raspberry-pi-2-snappy
[15:19] <ogra_> "then added this file to /etc/network/interfaces.d/wlan0"
[15:19] <ogra_> you should only need the bit below that line
[15:20] <ogra_> (as long as you have a kernel compliant device for which a module exists)
[15:20] <zyga> thanks!, let's see
[15:21] <ogra_> (forst hit for "ubuntu snappy wireless" on google btw)
[15:22] <zyga> ogra_: nothing like personalized searches ;-) I was googling for beaglebone wifi"
[15:23] <zyga> ogra_: works, nice
[15:24] <zyga> ogra_: thanks
[15:24] <ogra_> :)
[15:24] <zyga> ogra_: one less cable for me to manage ^_^
[15:25] <zyga> I sent a question on how to snapify network-manager to the mailing list, looking forward to see how that could be done
[15:25]  * elopio walks the dog before it rains.
[15:26]  * zyga goes to the other desk to desolder some stuff
[15:28]  * davmor2 sees that zyga is after more cables, or is that not what you are trying to say at all ;)
[15:29] <zyga> dholbach: haha
[15:29] <zyga> grr
[15:29] <zyga> davmor2: ^^
[15:29] <zyga> davmor2: I want to solder angled headers for serial
[15:29] <zyga> davmor2: so that I can fit everything in the case I've got
[15:30] <davmor2> zyga: mad fool you ;)
[15:30] <zyga> davmor2: why? it's so cute when it fits in the case
[15:36] <elopio> dholbach: balloons: rsalveti said we want to make a new stable release next week.
[15:36] <elopio> so we need to start planning for the testing session by the end of this week or beginning of the next one.
[15:37] <dholbach> elopio, oooooh!
[15:37] <elopio> both are ok for me. Any preference on your side?
[15:37] <dholbach> both should be fine for me as well
[15:39] <balloons> awesome!
[15:57] <kyrofa> sergiusens, ping
[15:59] <sergiusens> kyrofa: pong
[16:00] <sergiusens> bbl pong then :-)
[16:00] <kyrofa> sergiusens, haha, okay :)
[16:03] <balloons> elopio, so I was just going to ask you if we would see a release next week. Thanks for the heads up.
[16:05] <balloons> elopio, so we should probably have a quick chat later this week. Can we pick a date for the open house yet?
[16:06] <fgimenez> elopio, i've just sent you a catch up email, one more for your pile ;)
[16:06] <elopio> fgimenez: thanks, I'll check.
[16:07] <popey> ogra_: do we have a handy guide for putting a snappy image on an sd card to play with on a pi 2?
[16:08] <ogra_> popey, https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2
[16:08] <elopio> balloons: yes, we should meet again to get the final details. We can pick a date, and then tell the team to have an RC ready for that date.
[16:08] <popey> ta
[16:10]  * balloons notes ogra_ points popey back to d.u.c
[16:10] <balloons> success!
[16:10] <ogra_> :D
[16:11] <fgimenez> nice evening everyone o/
[16:12] <balloons> elopio, as soon as you have that date, let's meet. I'll get with Daniel tomorrow to kick off the announcements and line up the onair session, etc.. But that's all easier with a date :-)
[16:13] <elopio> balloons: a part of our team is sprinting this week, so I'm inclined to do it early next week.
[16:14] <elopio> if they are back on monday, monday sounds good. I'll ask.
[16:16] <balloons> elopio, ack.
[16:27] <slangasek> seb128: a grub shell rather than the boot menu, interesting.  show me the contents of the second partition on the USB stick?
[16:27] <slangasek> certainly, "/boot" is not the expected path
[16:34] <seb128> slangasek, http://paste.ubuntu.com/11757694/
[16:35] <seb128> slangasek, http://people.canonical.com/~seb128/video20150622_154059164.mp4 is the video from the bios/grub behaviour
[16:36] <slangasek> seb128: please pastebin the text of efi/boot/grub.cfg
[16:37] <seb128> slangasek,
[16:37] <seb128> set prefix=($root)'/EFI/ubuntu/grub'
[16:37] <seb128> configfile $prefix/grub.cfg
[16:37] <seb128> EFI/BOOT/grub.cfg yoy mean right?
[16:37] <slangasek> yes
[16:37] <slangasek> it's a fat partition, so it's the same thing ;)
[16:38] <slangasek> seb128: that all looks correct and expected, and does not explain the error message you got
[16:38] <seb128> slangasek, the grub cfg is http://paste.ubuntu.com/11757708/
[16:38] <seb128> well /EFI/ubuntu/grub/grub.cfg
[16:38] <davmor2> slangasek: calling things fat is so politically incorrect can't we call it larger ;)
[16:39] <seb128> slangasek, it looks like /boot isn't mounted/it doesn't find the kernel maybe?
[16:40] <slangasek> seb128: I supposed that's possible.  If you look at sda3 and sda4, do you have the expected /boot contents?
[16:44] <seb128> slangasek, hum, no
[16:44] <seb128> wth
[16:45] <slangasek> so I guess this error is also reproducible when booting under bios ;)
[16:45] <seb128> slangasek, /system-a/boot has 3.19.0-22 files
[16:45] <seb128> but the grub config has 3.19.0-10 entries
[16:45] <seb128> oh, no
[16:45] <sergiusens> kyrofa: pong
[16:45] <seb128> I'm reading the wrong section
[16:46] <seb128> slangasek, seems about right in fact, and that image boots fine under kvm
[16:46] <seb128> I'm going to try on a non uefi machine in a bit
[16:46] <seb128> slangasek, should I be able to ls /boot from grub?
[16:46] <seb128> I wonder if it fails to mount the fs for some reason
[16:47] <seb128> slangasek, brb, trying on my laptop which is not uefi/signed boot
[16:47] <kyrofa> Hey sergiusens :)
[16:48] <kyrofa> sergiusens, one of the things the snapp scope will eventually need to do is actually launch snaps
[16:48] <kyrofa> sergiusens, but lots of snaps don't have the concept of "launching"
[16:49] <kyrofa> sergiusens, we need a way to tell which snaps have a GUI, or can be launched
[16:49] <sergiusens> kyrofa: you want the equivalent of binaries I guess; I thought tvoss was going to be looking into that
[16:49] <kyrofa> sergiusens, I'm really talking about the snappy API. I assume the store doesn't have a way to tell which snaps are launchable, but will that fit into the API when it does?
[16:50] <sergiusens> kyrofa: when there is a complete story for it, I guess it will, yes
[16:51] <kyrofa> sergiusens, alright. I wasn't sure if that would somehow fit into the "type" field or what
[16:51] <sergiusens> kyrofa: well that's a question for the elders of the internet (aka snappy architects)
[16:52] <sergiusens> kyrofa: I don't see tvoss here, so maybe olli knows who's dealing with this
[17:00] <kyrofa> sergiusens, alright, thanks :)
[17:04] <seb128> re
[17:04] <seb128> slangasek, that key works fine on my latitude
[17:04] <seb128> so the issue seems to be with the signed boot
[17:06] <slangasek> oh?  there's signed boot in place on the images already?
[17:07] <seb128> slangasek, well, I don't know, maybe it's not properly set up :p
[17:08] <seb128> slangasek, that image has grub-efi-amd64-signed installed
[17:09] <seb128> and is built with goget-u-t 0.23 so with working uefi
[17:09] <seb128> before that the boot menu of the inspiron wouldn't list the device
[17:10] <seb128> maybe it's just the uefi mode which is misconfigured...
[17:18] <slangasek> seb128: ok. so if it's booting the signed grub efi binary, one notable difference is that it will not load any modules from the disk but only use those that are built in.  So it's possible that there's something funny with your target device to cause it to require some module that's not currently part of the set we build into the signed grub
[17:20] <olli> kyrofa, from looking over the thread I think mvo (absent) or alecu can help
[17:20] <ogra_> olli, where is my armhf mir !!
[17:20] <ogra_> :)
[17:21] <seb128> slangasek, how can I tell if there is anything funny/get debug info?
[17:25] <slangasek> seb128: let me think about that
[17:25] <slangasek> seb128: I do see that this system has both bootx64.efi and grubx64.efi.  Is SecureBoot enabled on it?
[17:26] <slangasek> seb128: also, what seed are you building from?  I guess this isn't in ubuntu.wily yet
[17:28] <kyrofa> olli, alright, thank you
[17:38] <seb128> slangasek, "Is SecureBoot enabled on it?", how do I tell?
[17:39] <seb128> slangasek, seed is http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop
[17:39] <seb128> slangasek, you can see a build log on https://launchpadlibrarian.net/209683596/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
[17:40] <slangasek> seb128: checking whether secureboot is enabled: mv /efi/boot/bootx64.efi /efi/boot/bootx64.efi.bak; cp /efi/boot/grubx64.efi /efi/boot/bootx64.efi; try to boot it
[17:41] <slangasek> seb128: if you get a different error, you know secureboot is enabled :)
[17:43] <seb128> slangasek, if I do that the device stops being listed as a bootable one
[17:43] <slangasek> really? that's interesting
[17:43] <seb128> that inspiron doesn't list non uefi (or non secure) devices
[17:44] <seb128> like back then I first tried to boot a x86 iso and it never listed the device as bootable
[17:44] <slangasek> we haven't made it a non-uefi device.
[17:44] <slangasek> /efi/boot/bootx64.efi is the magic path
[17:44] <slangasek> and I would not expect the firmware to try to validate the signature on /efi/boot/bootx64.efi before it's been asked to boot it
[17:44] <seb128> bah
[17:45] <seb128> sorry, nautilus/fat fail
[17:45] <seb128> the rename didn't work
[17:45] <seb128> k, same issue
[17:46] <seb128> well "same" = file "/boot" not found
[17:46] <slangasek> ok
[17:46] <slangasek> so that means secureboot is not enabled on the device, and the problem is not related to failure to load external modules
[17:47] <seb128> that's something ;-)
[17:47] <slangasek> you probably want to debug this at the grub shell then
[17:48] <slangasek> starting with 'ls ($root)'
[17:49] <seb128> (hd0,gpt2): filesystem is fat
[17:50] <slangasek> seb128: ok.  'ls $prefix' ?
[17:50] <seb128> error: disk `(hd0,gpt2' not found
[17:51] <seb128> ups
[17:51] <seb128> sorry
[17:51] <seb128> I had extra ()
[17:52] <seb128> error: file `/boot/grub' not found.
[17:52] <seb128> ls / -> efi/
[17:52] <seb128> not sure if /boot should exist/be mounted
[17:55] <slangasek> ok that's interesting
[17:55] <slangasek> echo $prefix ?
[17:55] <slangasek> seb128: ^^
[17:56] <seb128> (hfb0,gpt2)/boot/grub
[17:56] <seb128> grr
[17:56] <seb128> (hd0,gpt2)/boot/grub
[17:56] <slangasek> ok
[17:56] <slangasek> no idea where that came from, because that's not what was specified in /efi/boot/grub.cfg
[17:57] <slangasek> and your directory listing showed only two grub.cfg on the disk, and both of them appear to be correct
[17:58] <slangasek> and you said this same image booted successfully on your UEFI-capable laptop in non-secureboot mode?
[17:59] <seb128> no
[18:00] <seb128> I've 2 laptop, the inspiron which is uefi and the latitude which is older and non-uefi
[18:00] <seb128> it boots fine in kvm and on the latitude in non-uefi
[18:00] <slangasek> ah.
[18:00] <seb128> it failes to boot on the inspiron
[18:00] <seb128> secure or not
[18:13] <slangasek> seb128: what's the precise version of ubuntu-device-flash you used for creating this image, and what commandline did you use? I'd like to try to reproduce locally
[18:14] <seb128> slangasek, I tried with the hack from http://paste.ubuntu.com/11700710/ but let me try again with trunk, proper support got merged
[18:15] <seb128> before you spend time debugging
[18:15] <seb128> though those changes are just partition size extended and using the correct channel
[18:15] <seb128> so it shouldn't make a difference
[18:17] <seb128> slangasek, command, the one on top of http://paste.ubuntu.com/11719625/
[18:21] <slangasek> seb128: ok - but I should wait for you to test the goget-ubuntu-touch trunk before I try to reproduce?
[18:23] <seb128> slangasek, as you want, I doubt it makes a difference
[18:23] <seb128> but I'm happy to try and let you know
[18:23] <seb128> it might be tomorrow morning for me though
[18:23] <_4M8B_> Hi guys , I was searching howto configure my keyboard layout in snappy but without results... Can somebody help ?
[18:24] <seb128> slangasek, $ strings EFI/BOOT/grubx64.efi | grep /boot
[18:24] <seb128> 	set prefix=($root)/boot/grub
[18:25] <_4M8B_> https://bugs.launchpad.net/snappy/+bug/1464944?comments=all -- seems to have same issue
[18:25] <seb128> unsure where that comes from though
[18:25] <_4M8B_> ah ok
[18:27] <_4M8B_> I'll wait thanks
[19:23] <slangasek> seb128: well, one thing I've confirmed, that grubx64.efi is not the grubx64.efi from the grub-efi-amd64-signed package.
[19:23] <slangasek> $ strings /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed |grep prefix=
[19:23] <slangasek> $
[19:23] <slangasek> for both wily and vivid
[19:51] <seb128> slangasek, do you get the same issue?
[19:51] <seb128> slangasek, do you have any idea where the grubx64.efi is coming from then?
[19:52] <slangasek> seb128: I haven't tried to reproduce it yet, just got udf built from trunk
[19:52] <slangasek> seb128: the grubx64.efi is being created by grub-install at udf time
[19:55] <slangasek> (apparently with wrong options)
[20:27] <slangasek> seb128: I've just run the command from http://paste.ubuntu.com/11719625/ but I don't think it worked, I wound up with cache/ubuntuimages/ubuntu-core/rolling/edge/generic_amd64/version-84.tar.xz.  Is 'AME' really the right variable name?
[20:31] <slangasek> seb128: looks like that should be UDF_UBUNTU_CORE_NAME but is ignorable; but the command should be 'personal rolling' instead of 'core rolling', since I'm pretty sure you said you were seeing this with personal rather than core
[20:45] <slangasek> seb128: reproduced that 'strings | grep prefix' output that you showed, by running 'UDF_UBUNTU_CORE_NAME=ubuntu-personal DEBUG_DISK=1 ~/bin/ubuntu-device-flash --verbose personal rolling --channel edge --output amd64-rolling.img --size 10'.  So udf is doing something buggy here
[20:47] <slangasek> (or else grub-install itself is)
[20:49] <seb128> slangasek, sorry, I was afaik, yeah unsure about why sergiusens used 'AME' in his command, UDF_UBUNTU_CORE_NAME was the hack name in mvo's patch but I think trunk has a proper option for the new channel?
[20:49] <slangasek> I don't know what that option is.  So I just reproduced it with the above command
[20:50] <seb128> k
[20:50] <seb128> http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/revision/190 was the merge for personal
[20:51] <slangasek> what is DEBUG_DISK=1 supposed to give me?  doesn't seem to give me much in the way of new output from grub-install
[20:52] <seb128> the "parted" output I think
[20:52] <seb128> e.g on http://paste.ubuntu.com/11719625/ the lines 17 to 26
[20:52] <seb128> I don't think it's useful to debug the grub issue
[20:53] <seb128> sergiusens suggested it when I was hitting partitioning errors
[20:53] <seb128> because the partitions were too small for the new image
[20:53] <slangasek> that's certainly not the cause of this problem.
[20:53] <seb128> right, that was a previous issue that got resolved by the 10G size bump
[20:54] <seb128> you can drop that env variable afaik
[20:54] <slangasek> oh, you mean the grub issue from the pastebin.  Yeah I don't know what that is
[20:54] <seb128> it's orthogonal, don't worry about it
[20:55] <seb128> we resolved that one since the pastbin was done
[20:56] <slangasek> grub-install: info: copying `/usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' -> `/boot/efi/EFI/BOOT/grubx64.efi'.
[20:56] <slangasek> aha
[20:57] <slangasek> so apparently when passing --removable it's copying the CD image not the disk image
[20:57] <slangasek> and that's where it gets the prefix=
[20:57] <slangasek> that may be a regression in grub-install in wily
[20:59] <slangasek> hmm nope
[20:59] <slangasek> same behavior in vivid, where it was working fine for me on core
[21:23] <seb128> slangasek, k, I'm calling it a day and closing IRC but drop me an email or let me know tomorrow if you figure out more about the issue!