[02:15] <lotuspsychje> good morning
[08:14] <lordievader> Good moring
[11:45] <lotuspsychje> wawrek: apt-cache search spell check can help?
[11:48] <wawrek> thank you
[11:48] <lotuspsychje> snap find spell also shows a few
[12:05] <wawrek> I still have problems setting it up
[12:11] <akem> You need to install the myspell-XX package, ex: myspell-es or myspell-fr for spanish or french respectivly.
[12:12] <akem> Then once installed restart libreoffice and go in the language spelling setup part.
[12:13] <wawrek> this doesn't seem to work - I don't know how to set it up
[12:14] <akem> It worked for me, what language do you need?
[12:17] <akem> There is also an option in Libreoffice "Online dictionnaries" you may have a look. But i have the french version...
[12:17] <wawrek> no dictionary available
[12:17] <wawrek> any packages to be installed in libre office
[12:17] <wawrek> ?
[12:20] <akem> Shouldn't have to.
[12:21] <akem> You may try this: https://askubuntu.com/questions/72099/how-to-install-a-libreoffice-language-tools-spelling-check-thesaurus
[12:30] <wawrek> thanks. nothing really works. I have the latest aspell, libreoffice-l10n. I can't get it to work
[19:03] <Eickmeyer[m]> sarnold: For better discussion about audio that doesn't have to do with audio production or music, #lau is a thing (Linux Audio Users).
[19:04] <Eickmeyer[m]> That person was trying to bypass all audio servers and use ALSA directly with gaming. That's beyond our scope.
[19:10] <sarnold> Eickmeyer[m]: cool, thanks
[19:10] <sarnold> Eickmeyer[m]: (I did wonder a bit if his solution was a bit of an x-y problem or not, and figured you guys would know where to send him :)
[19:11] <Eickmeyer[m]> I told him that we don't support what he's trying to do, really.
[19:12] <sarnold> bummer, sorry to send him your way just for you to be the bearer of bad news
[19:27] <Eickmeyer[m]> sarnold: Yeah, it's all good. Just trying ot minimize the people that are sent there because I seem to be the only one in there answering questions and it's burning me out. I put out a call-to-action by the community with no response.
[19:28] <sarnold> :(
[19:28] <sarnold> Eickmeyer[m]: that's rough :(*
[19:28] <Eickmeyer[m]> It is.
[19:28] <Eickmeyer[m]> Everybody wants Ubuntu Studio, but nobody wants to help others.
[19:28] <akem> I don't want Ubuntu Studio.
[19:29] <Eickmeyer[m]> akem: Now you're just pushing my buttons.
[19:29] <akem> The red button only.
[19:29] <akem> :P
[19:29] <sarnold> one push only
[19:29]  * daftykins hands Eickmeyer[m] the sharpened penguin
[19:30] <Bashing-om> Eickmeyer[m]: Your article is picked up for UWN - maybe a bit of help there.
[19:30] <Eickmeyer[m]> We'll see. A spanish-speaking website picked it up and went completely alarmist: "Ubuntu Studio is DYING!!!!11!!!" smdh
[19:31] <Eickmeyer[m]> Granted, I made the article a bit click-baity.
[19:32] <Bashing-om> Eickmeyer[m]: Any consolation; we too have been screamming for help for UWN ... meager responses :(
[19:52] <oerheks> github buying javascript thingy npm .. https://github.blog/2020-03-16-npm-is-joining-github/
[20:05] <Bashing-om> UWN622 is on the streets: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue622 :D
[20:05] <oerheks> yay
[20:33] <pragmaticenigma> Wonder if the devs would be receptive to having the IRC clients in dev releases of Ubuntu preset to login into #ubuntu+1 instead of main
[20:33] <daftykins> i think it was suggested long ago but isn't worth the work
[23:05] <jeremy31> and there would be issues with the channels being +r


[08:35] <lau> hi, I'd like to build a new version of docker.io package with the latest upstream release
[08:35] <lau> it is for testing purpose only
[08:36] <lau> I am reading the ubuntu packaging guide
[08:40] <lau> as far as I undertand using udd, correct me if this is wrong please :
[08:40] <lau> - bzr branch ubuntu:docker.io
[08:40] <lau> - cd docker.io
[08:41] <Unit193> bzr branches haven't been updated in a while, last I knew.
[08:42] <lau>  - bzr merge-upstream --version 1.12.0 https://github.com/docker/docker/archive/v1.12.0.tar.gz
[08:43] <lau> Unit193: I am very new to ubuntu packaging
[08:43] <lau> do you mean that udd is not the way to go ?
[08:44] <lau> - http://packaging.ubuntu.com/html/udd-latest.html ?
[08:45] <lau> what would be a correct process to upgrade the docker.io ubuntu package locally for testing purpose with the latest upstream release ?
[08:45] <Unit193> !info docker.io unstable
[08:46] <Unit193> Awwwh, oh well.
[08:46] <Unit193> lau: Did you see the channel #ubuntu-packaging?
[08:55] <lau> oh no did not know this one :-) thank you


[00:04] <jml> lifeless, hello :)
[00:22] <spiv> jml: pong
[00:23] <spiv> jml: how was EuroPython?
[00:23] <jml> spiv, it was great :)
[00:23] <jml> spiv, I just sent my trip report to warthogs & am about to send my Bazaar sprint report
[00:24] <jml> spiv, regarding the --allow-writes patch. I'm thinking of marking the bug as wontfix, you filed the original bug IIRC -- what do you think?
[00:24] <jelmer> 'evening spiv, jml
[00:25] <jelmer> spiv: Do you perhaps know what the state/plans for nested trees is?
[00:25] <jml> jelmer, g'day.
[00:25] <spiv> jml: I did?  I vaguely thought it was poolie...
[00:26] <jml> spiv, you are right.
[00:26] <jml> and I am daft.
[00:27] <spiv> jelmer: morning :)
[00:28] <spiv> jelmer: abentley's was working on addressing the various concerns people had, the details of that are in his devnotes branch I think.  It certainly won't make 2.0, but given that abentley has a fair bit of code already and the design questions are largely worked out it's hopefully not too far into the future.
[00:29] <spiv> It probably depends on abentley's other priorties more than anything else...
[00:29] <jelmer> spiv: ah, ok - thanks
[00:58] <spiv> spm: ping; where did we get to with lp: URLs and bzr's PQM?
[00:58] <spiv> spm: (it's still not working)
[01:34] <poolie> hello
[01:35] <poolie> hello jml, welcome back
[01:35] <poolie> i think regarding --allow-writes there is still an issue there that should be addressed
[01:35] <poolie> but
[01:35] <poolie> perhaps not in the way recommended by the bug
[01:36] <poolie> how about just giving a warning if it's used in --serve mode/
[01:36] <poolie> i mean, in non-inetd mode
[01:36] <jml> poolie, yeah. I've reverted the bug back to 'Triaged'.
[01:36] <jml> poolie, that sounds fine to me. Simple & to the point.
[01:39] <poolie> did you pick this because it looked easy, or was there some stronger motivation?
[01:52] <SpamapS> I want to make a copy of my current working copy and then revert so I can build the old version.. can I just 'cp -arf working working2' and then 'bzr revert' in working, and still keep my local changes in working2?
[01:53] <poolie> yes
[01:54] <lifeless> you can also branch and then use 'bzr merge --uncommitted'
[01:55] <lifeless> jml: bug 307166
[01:55] <lifeless> jml: I'm curious why you removed the launchpad tag?
[01:56] <jml> lifeless, because I didn't read the stack trace.
[01:57] <jml> lifeless, and reading only the error, I assumed that the OP mistook a general network error for a Launchpad-specific thing.
[01:57] <jml> In any case, it's a dupe of a bug I just fixed.
[01:57] <lifeless> cool
[01:57] <lifeless> what about bug 216924
[01:58] <jml> wow, untriaged bugs starting with 2
[01:59] <jml> lifeless, do you think it's a bug in the lp plugin?
[01:59] <lifeless> yes
[01:59] <lifeless> the backtrace shows its the lp plugin calling xmlrpclib
[02:00] <lifeless> its got nothing to do with ssh
[02:01] <jml> you think the plugin should catch that error and... ?
[02:01] <lifeless> I think we should determine the root cause
[02:01] <lifeless> my gut says its a dup of the 'lp plugin does not honour proxy settings'
[02:01] <lifeless> bug
[02:01] <lifeless> what does the 'launchpad' tag mean to you?
[02:02] <jml> bug in the launchpad plugin
[02:02] <lifeless> to me it means 'fixing this bug will make life easier/nicer for users of bzr with launchpad
[02:03] <jml> I see.
[02:03] <poolie> to me just 'related to launchpad'
[02:03] <lifeless> the lp plugin is just 'code that is unique to working with lp'
[02:03] <lifeless> not the entire set of related to lp
[02:04] <lifeless> jml: I'm tagging that launchpad again
[02:04] <jml> lifeless, ok
[02:04] <lifeless> jml: because you can only get that error using lp:
[02:04] <lifeless> as only lp: uses xmlrpc
[02:04] <jml> lifeless, fair enough.
[02:05] <jml> lifeless, re: "the lp plugin is just 'code that is unique to working with lp' not the entire set of related to lp" -- yes that goes without saying, what's your point?
[02:09] <lifeless> jml: my point is that the tag, and experience is broader than the plugin
[02:16] <jml> lifeless, I'd kind of like a way of saying "this bug affects the launchpad plugin".
[02:17] <lifeless> jml: why?
[02:17] <jml> lifeless, but I guess that the space of bugs related to launchpad more generally isn't big enough for that to help
[02:17] <poolie> jml, i've read your trip report, if you want to chat just give me a call
[02:17] <mwhudson> hey guess what
[02:17] <mwhudson> lrucache isn't thread safe
[02:17] <jml> lifeless, because it matches my mental model of the world :)
[02:18]  * mwhudson really really should not have made that mistake :/
[02:18] <poolie> :/
[02:18] <poolie> mwhudson: there's not really any promise that any bzr class is thread safe
[02:18] <mwhudson> poolie: yes, i know
[02:18] <poolie> and in general making single classes threadsafe can be an antipattern
[02:18] <poolie> k
[02:18] <mwhudson> a failure to think straight on my part
[02:21] <lifeless> jml: you'd need to explain your model then.
[02:22] <lifeless> we're threadsafe like the C++ STL is
[02:22] <lifeless> which is to say, we're safe for a single thread :)
[02:23] <fullermd> Threadsafe, not threadSsafe   :p
[02:24] <mwhudson> "not conspicuously stupid about it"
[02:46] <jml> abentley, bundlebuggy appears to be down
[02:47] <abentley> jml: restarted
[02:47] <jml> abentley, thanks.
[04:09] <poolie> jml, i filed bug 396335
[04:09] <lifeless> poolie: uhm
[04:09] <lifeless> poolie: I don't know if you are aware but there are a bunch of other approaches for that
[04:09] <lifeless> that don't need maintenance in the same way
[04:10] <poolie> i know there's various efforts to have a systematic way to add/remove ppas
[04:10] <poolie> this bug is kindof a workaround for the lack of them
[04:11] <poolie> what kind of maintenance are you talking about though?
[04:11] <lifeless> two things mainly
[04:12] <lifeless> one is that the deb is introducing static data, so it has to be at least a little careful because users may remove the data without removin the deb
[04:12] <lifeless> and the other is that the keys it adds are static
[04:12] <lifeless> but archive keys are often rotated
[04:12] <poolie> really?
[04:12] <lifeless> and even if lp isn't rotating ppa keys today, I fully expect it will have to at some point
[04:12] <lifeless> (it being whatever deb is created)
[04:13] <poolie> for values of often = never :)
[04:13] <poolie> well,
[04:13] <lifeless> ubuntu and debian archive keys are rotated
[04:13] <poolie> if they start doing that, they'll have to work out some some solution for the thousands of people who've manually added the keys now
[04:15] <jml> wow.
[04:16] <jml> just came across the first time I've ever wanted to sort bugs by id
[04:16] <lifeless> jml: thanks for the slides; looks like you created a really good narrative
[04:18] <jml> lifeless, my pleasure.
[04:20] <jml> btw, I just came across this bug: https://bugs.edge.launchpad.net/bzr/+bug/183831
[04:20] <jml> it has a patch that hasn't been responded to.
[04:20] <jml> the author of the patch asked me about it at EuroPython, I think.
[04:43] <RenatoSilva> How do I unpush?
[04:43] <lifeless> push --overwrite -r -2
[04:43] <lifeless> or whatever is the right revision
[04:43] <RenatoSilva> I pushed a new revision, I want to uncommit and push the revision again to lp
[04:43] <RenatoSilva> lifeless: thank you!
[04:43] <lifeless> or if you have a new revision locally, just push --overwrite
[04:46] <RenatoSilva> lifeless: ?
[04:47] <RenatoSilva> lifeless: pushed revision was 130...
[04:47] <RenatoSilva> lifeless: I uncommited, commited again (a new 130)
[04:47] <RenatoSilva> lifeless: if worked without specifying the rev number
[04:47] <RenatoSilva> *it
[04:54] <lifeless> yes
[04:55] <lifeless> the rev number is when you want to specify a rev other than  tip
[04:55] <lifeless> --overwrite is all that is needed to force the push
[05:04] <RenatoSilva> lifeless: thank you
[05:06]  * spiv -> lunch
[05:11] <RenatoSilva> When a bug is invalid for a project, but there's a watch in the project for a external bug, what does this mean?
[05:12] <lifeless> it means the bug is recorded in  two places
[05:14] <RenatoSilva> I mean it's like the bug itself is invalid
[05:15] <lifeless> I'm not sure what you mean
[05:15] <lifeless> but perhaps an example would help
[05:15] <RenatoSilva> lifeless: in bug 388300, Eclipse was checked as invalid, however I reported it initially as general error "bzr-eclipse does not work with accented paths"
[05:16] <RenatoSilva> lifeless: now we know it's an xmloutput issue, but the external bug may also be affecting bzr-eclipse
[05:18] <RenatoSilva> lifeless: eclipse was marked as invalid, because the title changed...that's ok, I just wonder if I should generalize the title again (and change eclipse's invalid status), or either open a new bug pointing to that bug
[05:18] <RenatoSilva> to the eclipse external bug
[05:21] <lifeless> RenatoSilva: if changes are needed to eclipse to close the bug
[05:22] <lifeless> RenatoSilva: then it would be appropriate for a task to be open (not invalid) on eclipse
[05:22] <lifeless> however the external bug is marked resolved
[05:23] <lifeless> perhaps the external link needs to be updated
[05:26] <poolie> jml, any reason you're using BB rather than lp reviews?
[05:26] <poolie> i hear they're rather good :)
[05:31] <jml> poolie, well, I'm not really.
[05:32] <poolie> oh, i just thought i saw one from you
[05:33] <poolie> also, maybe you shoud send your report somewhere else too
[05:33] <jml> poolie, yeah, that was an RFC patch
[05:33] <poolie> like a europython list?
[05:33] <jml> poolie, I guess I could have used a merge proposals
[05:34] <jml> but I hoped I'd get responses more quickly on the ML
[05:34] <jml> I guess I was wrong
[05:34] <poolie> mm
[05:35] <jml> good idea re forwarding
[05:35] <RenatoSilva> lifeless: it's just about organizing the issues, maybe it's better to create a new bug
[05:35] <lifeless> RenatoSilva: I don't know
[05:35] <RenatoSilva> lifeless: is is resolved as duplicate of another bug (also watched in lp bug)
[05:37] <poolie> jeez i'm sick of launchpad repeating the bug description in the first bugmail
[05:37] <RenatoSilva> lifeless: most of bug content is about xmloutput, eclipse's bug is a little part
[05:39] <jml> poolie, yeah.
[05:39] <lifeless> I don't mind it being included
[05:40] <lifeless> it helps when you are added to an already inflight bug
[05:40] <poolie> it's provably stupid when it's including *the exact same text* twice
[05:40] <poolie> ffs
[05:41] <poolie> seriously
[05:41] <lifeless> oh, I haven't noticed that
[05:41] <poolie> sending you the description when you're added to a bug would be useful i agree
[05:41] <poolie> and even when i have 'include bug descriptions' turned off

[05:51] <poolie> going back to reconfigure
[06:44] <poolie> lifeless: in the context of unstacking
[06:44] <poolie> at the moment unstacking fails with revisionnotfound if you have any tags pointing to not-present revisions
[06:45] <poolie> this should probably not happen...
[06:46] <lifeless> I think fetch is still broken wrt that case
[06:46] <poolie> at any rate it should be consistent with branch, which seems to only copy things referenced in the branch
[06:47] <poolie> it looks like fetch makes no effort to copy the revs referenced by tags?
[06:48] <lifeless> thats right; there is a bug open on that
[07:13] <lifeless> ciao
[07:20] <spiv> Woah, "repo.add_inventory(...)" on a stacked gc repo is adding the inventory to repo's fallback, not repo.
[07:21] <spiv> Hmm, something is weird here.
[07:21] <vila> spiv: isn't the fallback read-only ?
[07:21] <vila> err, Hi all ! :)
[07:22] <spiv> Hmm, or it's just the way I'm introspecting the vf that's the issue.
[07:28] <poolie> hello spiv
[07:28] <poolie> hello vila, spiv
[07:28] <poolie> spiv, how's stuff?
[07:30] <jml> is https://bugs.edge.launchpad.net/bzr/+bug/393349 a dupe of something deeper?
[07:35] <poolie> probably
[08:01] <jml> poolie, spiv, vila: could one of you please review https://lists.ubuntu.com/archives/bazaar/2009q3/060202.html
[08:02] <jml> it's one of the patches from the sprint.
[08:02] <vila> I think spiv is the usual suspect here :)
[08:03] <spiv> poolie: alright, that stacking cross-format test is passing finally.  I'm just trying to figure out why more mundane (pack-0.92 to pack-0.92, for instance) tests are failing, which I only just noticed after fixing the stacking bug.
[08:04] <spiv> jml: heh, coincidentally I updated my bzr-ping plugin to report that just a few days ago.
[08:09] <spiv> Aah, ghosts.  I see the bug.
[08:09]  * spiv fixes
[08:15] <spiv> Ok, just one failing test left.
[08:15] <spiv> Well, 1 x every format :)
[08:20] <spiv> Weird, only one format fails when I run just those tests.
[08:28] <lifeless> spiv: global state
[08:32] <spiv> lifeless: you'd think so, but it turns out be pebkac (well, that and test names that are very similar to the eye, particuarly in the rather noisy output of multiple test failures) :)
[08:51]  * spiv exhales and pushes the branch with all interrepo and fetch tests passing, finally.
[08:54]  * vila cries, one more bug in python http server...
[09:28] <awilkins> vila: Heh, and the bugs in the RFC implementations bump into the bugs in IIS's implementations :-)
[09:30] <vila> awilkins: err, any specific in mind ? I just fixed one where the http server weren't inserting a Content-Length header (which I more or less think is kind of mandatory in 1.1 which presumably is needed for https)
[09:30]  * vila sounds very confident isn't it ? :-D
[09:30] <awilkins> vila: It's the one I worked around somewhere...
[09:31]  * awilkins looks up the revision
[09:31] <vila> awilkins: really ? The only case where it seems to cause a problem is pycurl+https client hanging, all other combinations are fine
[09:31] <awilkins> r 3539
[09:32] <awilkins> It's a problem with it serving ranges in IIS
[09:32] <awilkins> RFC822 in Python is wrong, as is RFC2046 in IIS
[09:33] <awilkins> It's essentially about the way it quotes multipart content boundary lines
[09:33] <vila> awilkins: Oh, I remember that one
[09:33] <awilkins> But it has a workaround ; and really, you're not going to get it fixed in IIS
[09:33] <vila> Sure, but the one I just fixed is in the python's http server
[09:34] <vila> And *that* means that our http clients are tolerant about that, except pycurl for https :-)
[09:35] <fullermd> Funny how every time I hear 'pycurl' here or on the list or anywhere, it's followed by "is screwing up XYZ for me"...
[09:36] <awilkins> Off the top of my head the only thing I can think of for your automatic make-a-tunnel problem is that you may want to have a private key with no passphrase ; the part where it's automatically starts the tunnel is escaping me
[09:36] <vila> fullermd: that's called rumors and I suspect someone is trying to get pycurl deprecated
[09:37] <awilkins> pycurl screws things up for me on Windows
[09:37] <vila> awilkins: Oh, good, I end up to that conclusion too (no pass-phrase) as for the automatic start, I found 2 possible solutions: 1) use inetd, 2) a perl script called autotunnel (a bit hackish though and not because it's written in perl ;-)
[09:38] <vila> on the other hand, the automatic part is really needed only for my laptop usage and less important
[09:38] <vila> awilkins: what is pycurl screwing ?
[09:38] <awilkins> I'm content with manually establishing tunnels tvbh
[09:39] <awilkins> vila: I don't recally, I abandoned using it about a year ago
[09:39] <vila> tvbh ?
[09:40] <vila> tbvh I can translate to 'to be very honest' with my crystal ball but... tvbh...
[09:46] <awilkins> vila: Was meant to be tbh but I'm suffer from fat fingers. Too many sausage sandwiches I think.
[09:46] <fullermd> Through Verbose Barnyard Hovels?
[09:47] <vila> :)
[09:48] <awilkins> And pycurl must have annoyed me, the folder is now called "curl_off"
[10:10] <bialix> vila: bonjour
[10:10] <vila> Hello bialix !
[10:10] <bialix> I have a question about review process on LP
[10:11] <vila> Are you asking if you can ask ?
[10:11] <bialix> what should be done to mark patch as approved
[10:11] <bialix> ?
[10:11] <vila> :-)
[10:11] <bialix> e.g. https://code.launchpad.net/~bialix/bzr/lp-bzr.exe/+merge/8259
[10:11] <bialix> 2 approve votes is not enough now?
[10:13] <spiv> vila: I don't think Content-Length is mandatory; e.g. if the transfer-encoding is chunked you don't need it to reliably determine end-of-body.
[10:13] <vila> bialix: the second rapprover should land the patch :)
[10:13] <Peng_> (testing my IRC client, sorry) bzr+ssh://example.com/
[10:13] <vila> spiv: yeah, chunked and Content-Length are exclusive
[10:13]  * fullermd fails Peng_'s client.
[10:14] <Peng_> fullermd: :D
[10:14] <bialix> vila: wait, there is 2 queues now: https://code.launchpad.net/bzr/+activereviews and https://code.launchpad.net/bzr/+approvedmerges
[10:14] <bialix> my patch in the former
[10:14] <bialix> what should be done to take it into the latter?>
[10:15] <bialix> and what is "Review type" when I'm adding manually additional reviewers?
[10:15] <knielsen> Hi, I'm a bit worried about this bug: https://bugs.launchpad.net/bzr/+bug/375898 ... it has been sitting there for a couple of month now, and it's basically a showstopper, crash on merge into tree with no known work-around :-(
[10:16] <vila> bialix: ha, yes, the proposal status should be update, that's not the same as the review status
[10:16] <bialix_> rats, my new patch for unicode locks affected by difference between lp:bzr and http//bzr.dev
[10:17] <knielsen> There is a reproducible test case ... it's been blocking our merge of PBXT into MariaDB for two months now :-( ... so any help would be much appreciated
[10:17] <bialix_> what should I do now?
[10:17] <vila> bialix: ha, yes, the proposal status should be update, that's not the same as the review status
[10:17] <bialix_> vila: sorry, I have been disconnected for some time
[10:18] <vila> as for "Review type", I have no idea :) Try searching lp help :D
[10:18] <bialix_> vila: so, I'm not bzr-core member, so I have no rights to change proposal status, it seems
[10:19] <spiv> bialix_: for bzr just leave the review-type blank; some projects (e.g. launchpad) have separate UI review and database schema review on top of basic code review.
[10:20] <spiv> But for bzr we just have reviews, no special differentiation.
[10:20] <bialix_> ok, my new patch https://code.launchpad.net/~bialix/bzr/lock-unicode-win32/+merge/8297 affected by divergence between bzr.dev and lp:bzr. Should I resubmit it later?
[10:21] <vila> generally yes
[10:21] <knielsen> importance for  https://bugs.launchpad.net/bzr/+bug/375898 is "medium" which seems too low, as it basically makes your tree corrupt and unusable ... sounds more like critical to me ... ?
[10:22] <bialix_> vila: ok, will do later today
[10:22] <bialix_> jam is working these days?
[10:23] <vila> knielsen: it would be best to check with jam and abentley in a couple of hours US TZs
[10:23] <knielsen> vila: ok, will do, thanks
[10:30] <poolie> hello vila
[10:30] <vila> poolie: hi again :)
[10:32] <poolie> if you have a chance, robert would appreciate you doing his check review
[10:32] <poolie> it's kind of big
[10:33] <poolie> he got an initial review from ian, but ian is away this week
[10:33] <vila> poolie: I'm already reviewing it :-)
[10:33] <fullermd> Hopefully that doesn't mean reviewing it drives people away  :p
[10:34] <poolie> on the other hand it cures cancer :)
[10:34] <vila> fullermd: in fact it does... I'll be in vacations the week after next week :)
[10:38] <poolie> :)
[10:38] <fullermd> Hm.  I'll review it then; I could use an escape week...
[10:49]  * LarstiQ fumbles about with the launchpad review ui
[11:11] <maxb> I have bzr-gtk installed to be able to use "bzr visualize", but I don't want the popup notifications when I bzr pull - where can I stop those? Thanks.
[11:11] <Wellark^1> hi! I'm planning to start a project which uses bazaar for version control. I'm interested about the current state of GPG integration. This page http://bazaar-vcs.org/BzrGpgSigning seems to be outdated and I would like to know what's the current status. Particularly I'm interested whether or not is it possible to demand and force every commit which land to shared repositories on remote server to be signed. Thanks.
[11:15] <poolie> Wellark^1: it's probably possible by writing a hook on the server
[11:15] <poolie> i think there may be one already
[11:22] <Wellark^1> ok. cool!
[11:22] <Wellark^1> I'm sure I can work that out when I begin deployment
[11:23] <poolie> you could send mail...
[11:23] <Wellark^1> I was just worried if GPG side is completely broken or something like that :)
[11:50] <lifeless> maxb: disable the applet
[11:50] <maxb> what applet?
[11:51] <maxb> removing the bzr-dbus package seems to have stopped them
[11:51] <lifeless> theres a bzr gtk process being started by your session
[11:51] <lifeless> bzr-dbus is just the transport
[11:53] <maxb> Oh, so there is. Too much magic :-)
[11:55] <lifeless> bzr-dbus has glue to do notifications on cross process, or LAN etc
[11:55] <lifeless> and I plan to hook in jabber when I get some time
[12:49] <NEBAP|work> is it possible to checkout a shared repository?
[12:49] <mzz> NEBAP|work: it's definitely possible to checkout branches living inside a shared repository.
[12:50] <mzz> NEBAP|work: checking out an entire shared repository doesn't make sense, but there may be a command that automates checking out all the branches inside one.
[12:50] <NEBAP|work> mzz: but then I have to create a shared repository myself in the local location, too. Is there a way to checkout the hole "structure" of a project?
[12:50] <mzz> NEBAP|work: see above.
[12:51] <NEBAP|work> hmm
[12:51] <mzz> NEBAP|work: it's not at all required for your local shared repository layout to match the remote one
[12:51] <NEBAP|work> I introduce the layout I want to have for the project, maybe I´m wrong with building it in bazaar
[12:52] <mzz> NEBAP|work: for example if the remote repository has /path/to/repo/trunk, /path/to/repo/branches/foo-feature, etc, it'd make perfect sense to put them in local/repo/remote/trunk, local/repo/remote/branches/foo-feature, etc
[12:52] <mzz> NEBAP|work: compared to (say) svn: a svn repository is much more like a bzr branch than a bzr repository. bzr repositories are normally purely an optimization
[12:54] <NEBAP|work> hmm
[12:55] <bob2> multi-pull plugin
[12:55] <NEBAP|work> Can you checkout my preferred layout and tell me what each folder should be (e. g. branch or shared repository)?? http://pastebin.com/d496f0521
[12:56] <NEBAP|work> I´ve started using bazaar for some private projects which worked very well
[12:56] <NEBAP|work> now I want to setup a bigger project in our company with bazaar
[12:56] <mzz> NEBAP|work: the bazaar manual documents the pros and cons of a handful of repository layouts. Have you read that bit?
[12:57] <NEBAP|work> yes
[12:57] <NEBAP|work> but there is no hint how to setup those layouts
[12:57] <NEBAP|work> the question is
[12:57] <vila> NEBAP|work: Both (MyProject) and (Module1, Module2) are good candidates for shared repos
[12:58] <mzz> NEBAP|work: unless your projects are pretty large you shouldn't worry too much about repository layout imoh
[12:58] <mzz> imho, even
[12:58] <NEBAP|work> is it useful for a developer to just use a branch (e. g. bzr branch .../MyProject/Module1/Branches/FeatureX; make changes and commit)
[12:58] <vila> the choice mostly depends on the expected volume, the safe bet is to use Module1, Module2
[12:58]  * vila agrees with mzz
[12:59] <NEBAP|work> so it´s ok to use some shared repos in a shared repo?
[12:59] <vila> NEBAP|work: you can, but be sure everybody understand the consequences
[12:59] <NEBAP|work> ^^
[13:00] <NEBAP|work> what are the consequences?
[13:00] <NEBAP|work> I think I´ve understand the usage of a shared repository with some branches
[13:00] <vila> Unexpected use of 'MyProject' repository ?
[13:00] <vila> Or did you imply some other repos *below* ModuleN
[13:01] <NEBAP|work> yes
[13:01] <vila> NEBAP|work: let's forget about repos for a minute,
[13:02] <NEBAP|work> ok let me tell you about the functionality I want to have
[13:02] <vila> imagine that each branch stores the whole history of a project, each time you create a branch you copy that whole history to start with, and then each branch update its history, pull/push/merge occur, the histories are now different
[13:03] <NEBAP|work> using the layout I´ve posted before
[13:03] <NEBAP|work> I want to have a overall place where the hole project (all modules) are stored
[13:04] <NEBAP|work> to let a developer checkout all stuff in a single call (e. g. bzr checkout .../myproject)
[13:04] <vila> NEBAP|work: you can't right now
[13:05] <NEBAP|work> for each module I want to have a trunk storing the mainline of the project and a container for the branches to let a developer checkout a the trunk, create a feature branch under branches, commit to it and then merge it back to the mainline branch
[13:05] <NEBAP|work> hmm
[13:06] <NEBAP|work> is it possible to use a shared repository in a branch?
[13:06] <vila> NEBAP|work: A standalone branch use its own private repository
[13:06] <NEBAP|work> hmm
[13:07] <NEBAP|work> a shared repository is useful for the feature branches to use a common place to store the history and prevent the branches to keep a history themselfes, right?
[13:07] <vila> right
[13:07] <NEBAP|work> so the moduleX folder should be a shared repo
[13:08] <vila> I think so
[13:08] <NEBAP|work> ok
[13:08] <NEBAP|work> what is if I use a branch for the ProjectX folder?
[13:08] <NEBAP|work> which contains the shared repositories?
[13:08] <vila> :-)
[13:08] <NEBAP|work> the ProjectX folder doesn´t have to share the history
[13:08] <vila> NEBAP|work: you mean http://bazaar-vcs.org/NestedTreesDesign/
[13:08] <NEBAP|work> because there is no code in the container folder :)
[13:09] <vila> NEBAP|work: define ProjectX
[13:10] <NEBAP|work> ProjectX is just a container for the ModuleX folders (shared repos)
[13:10] <NEBAP|work> but shouldn´t hold a common history
[13:11] <NEBAP|work> because Module1 and Module2 have nothing to do with each other
[13:12] <NEBAP|work> the only thing I can´t do in this layout is "bzr commit" in the ProjectX folder to commit each modules changes
[13:12] <NEBAP|work> right?
[13:13] <vila> right
[13:14] <NEBAP|work> here is my updated example http://pastebin.com/d63396cf8
[13:14] <vila> NEBAP|work: that sounds a lot like a server layout though, developers don't have to fully mirror it
[13:14] <NEBAP|work> yes
[13:14] <NEBAP|work> but they can if they want :)
[13:14] <NEBAP|work> does this layout make sense?
[13:14] <vila> MyProject is not a branch, it's just a directory
[13:15] <vila> of course they can if they want
[13:15] <NEBAP|work> but does it make sense to set MyProject up as branch?
[13:15] <vila> but I suspect they don't want a copy of all feature branches even if they want all trunks
[13:15] <vila> not really, what will you put into it ?
[13:16] <NEBAP|work> to let developers do the following: "bzr branch .../MyProject" ?
[13:16] <NEBAP|work> to load the hole project
[13:16] <NEBAP|work> or doesn´t it work?
[13:16] <vila> no, that will not work
[13:16] <NEBAP|work> k
[13:16] <vila> but the developers can use the multi-pull plugin
[13:16] <vila> which address, I think, your need
[13:16] <NEBAP|work> my current layout looks similar to the posted but "MyProject" is just a folder and "Branches" is just a folder is that fine?
[13:17] <NEBAP|work> k
[13:17] <NEBAP|work> maybe they won´t need
[13:17] <NEBAP|work> but thank you for the hint :)
[13:17] <NEBAP|work> but now this is the layout on my server
[13:17] <NEBAP|work> what has a developer to do if he / she wants to start a new feature branch?
[13:18] <NEBAP|work> building up a local shared repository
[13:18] <vila> err, "similar..but...is that fine?" is quite a tricky question :)
[13:18] <NEBAP|work> ^^
[13:18] <NEBAP|work> sorry, I´m not the best english speaker ;)
[13:19] <NEBAP|work> I just wanted you to ask if you think this layout is ok: http://pastebin.com/d3bed7893
[13:19] <vila> mkdir MyProject ; cd My project ; bzr init-repo Module1 ; bzr branch <server_url>/MyProject/Module1/Trunk Module1/Trunk
[13:20] <NEBAP|work> ok
[13:20] <vila> yup, layout ok
[13:20] <NEBAP|work> so the developer has to setup a local branch :)
[13:20] <NEBAP|work> thank you
[13:21] <NEBAP|work> if I´m right, the developer shouldn´t use the --no-tree option as this doesn´t show the folders ..
[13:21] <vila> has to setup a local shared repo, yes, that's better if he intend to use several branches, but that's not required
[13:21] <NEBAP|work> k
[13:21] <vila> exact, the developer is *supposed* to work with the trees :-0)
[13:22] <NEBAP|work> but holding the trunk as a mirror and using some branches is "better" in a shared repository, because the history is just hold one time in the shared repo
[13:22] <NEBAP|work> ?
[13:22] <vila> It is more important when working disconnected from a central server but still not mandatory (ok, I will stop to mention the non-mandatory part from now :)
[13:23] <NEBAP|work> k :)
[13:23] <NEBAP|work> thank you alot
[13:23] <NEBAP|work> very helpful
[13:23] <vila> On a LAN, you care less about having a local mirror
[13:23] <vila> because your network bandwidth/latency may be better than your disk's :-)
[13:23] <NEBAP|work> it´s very hard to understand all the useful functions of bazaar in a short time ;)
[13:23] <NEBAP|work> hehe
[13:23] <NEBAP|work> yeah
[13:24] <vila> That's why we try to start from the workflow before chosing the layout, but it's not, oops
[13:26] <NEBAP|work> ^^
[13:26] <NEBAP|work> I just want to setup the server layout at first to avoid problems later
[13:26] <NEBAP|work> loosing a history can be a very big problem ..
[13:28] <mzz> imho as long as you get what goes into what branch right you'll be mostly ok
[13:29] <mzz> that is: as long as you figure out if you want separate branches per project or need one branch containing multiple projects for some reason
[13:29] <NEBAP|work> hmm
[13:29]  * vila agrees with mzz
[13:29] <mzz> you can reorganize at what level repositories live transparently, and to some extent move branches around on the filesystem too
[13:29] <mzz> splitting up or joining branches is much more of a headache
[13:29] <NEBAP|work> I´ve just seen the cool log entries if you using the feature branch layout
[13:30] <mzz> oh, yes, you definitely want feature branches
[13:30] <NEBAP|work> :)
[13:30] <mzz> but where on the fs those branches live is much less important
[13:30] <NEBAP|work> it´s just a few times more readable using this feature
[13:30] <NEBAP|work> ah k
[13:31] <mzz> it's just that any checkouts that are currently bound to them get upset if they move around
[13:31] <NEBAP|work> we´ve just used subversion before, bazaar gives us a bunch of new possibilities :)
[13:31] <mzz> (I forgot just how badly confused a non-lightweight checkout gets)
[13:31] <mzz> a heavyweight checkout can probably just be unbound if the branch it is bound to goes away, and an unbound branch doesn't care
[13:32] <mzz> so those filesystem paths don't matter that much, they don't make it into history (the branch nick does, but the full branch location shouldn't)
[13:33] <mzz> so if you change your mind on how you organize branches you'll have to deal with some temporary pain as people currently using them switch to the new location, but it won't show up in history
[13:33] <mzz> makes sense?
[13:34] <NEBAP|work> yes, I just hope I got you right :), as I said, I´m not the best english speaker ..
[13:35] <NEBAP|work> you mean that checkouts have problems if the corresponding server location changes?
[13:35] <mzz> I don't recall if heavyweight ones do. Let me try.
[13:36] <NEBAP|work> don´t think, because you can use the unbind function to let them stay standalone (imho)
[13:36] <vila> NEBAP|work: I you use plain branches, you won't run into the problems mzz mentioned
[13:36] <NEBAP|work> k
[13:36] <NEBAP|work> which type of branches does mzz use?
[13:37] <vila> lightweigth or heavyweigth checkouts I presume which allow an indirection between the working tree and the branch itself
[13:38] <mzz> a heavyweight branch will just unbind and rebind if the underlying branch moves
[13:38] <mzz> so that's not an issue (no more of one than when using regular branches, and you have to respecify the push/pull location)
[13:39] <mzz> lightweight branches get a bit upset
[13:39] <mzz> that's probably a bug, and there might be a workaround for it
[13:40] <NEBAP|work> hmm
[13:41] <mzz> my local setup is slightly odd (I store code in working-tree-less branches on a fileserver on my lan, and hack in lightweight checkouts on the local drive)
[13:41] <NEBAP|work> but all those problems are just present if I change the server location, right?
[13:41] <mzz> you might want to not duplicate that setup :)
[13:41] <NEBAP|work> ^^
[13:41] <mzz> it's really a nonissue unless you use lightweight checkouts, and I should file a bug on those actually
[13:42] <mzz> if you use heavyweight checkouts or regular branches you can just tell bzr where the parent branch went if it moves
[13:42] <NEBAP|work> hmm I just want to use the a lightweight checkout to mirror the trunk in each module
[13:42] <NEBAP|work> k
[13:42] <NEBAP|work> ok, but server location shouldn´t change
[13:42] <NEBAP|work> so there should be no problem with my setup :)
[13:42] <mzz> lightweight branches you'd have to recreate, unless you're feeling adventurous and change the location in .bzr/branch/location (but that's pretty horrible)
[13:43] <NEBAP|work> ^^
[13:43] <mzz> but I'm pretty sure that's just a bug and I should file it
[13:43] <NEBAP|work> yeah, should be possible to reroute the lightweight checkout like the heavyweight one
[13:44] <NEBAP|work> just one last question, should the developers in my layout store there branches on the server?
[13:44] <NEBAP|work> I think they should for backup reasons
[13:45] <vila> s/should/can/ they want to do that either for backup or because they are ready to share or because they want it to be reviewed before merging, etc
[13:45] <NEBAP|work> k
[13:45] <NEBAP|work> thank you both for your very good help
[13:46] <NEBAP|work> safed me a lot of time and probably a lot of trouble :)
[13:47] <vila> NEBAP|work: always happy yo help (tm)
[13:47] <NEBAP|work> :D
[13:48] <vila> s/yo/to/
[13:49] <mzz> ah, interesting
[13:50] <mzz> NEBAP|work: https://bugs.launchpad.net/bzr/+bug/105192/comments/7 if you do want to use lightweight checkouts and end up rearranging
[13:50] <NEBAP|work> mzz thanks
[13:51] <NEBAP|work> I think most commercial projects / softwares can learn from the great support some open source projects offer ..
[13:51] <NEBAP|work> or better the communities behind those projects
[13:53] <NEBAP|work> one last question
[13:53] <NEBAP|work> if I want to create a branch of the trunk
[13:53] <NEBAP|work> should I create this branch from the server location of the trunk
[13:53] <NEBAP|work> or from my local trunk mirror?
[13:53] <NEBAP|work> the trunk mirror is a lightweight checkout from the server
[13:55] <vila> a lightweight checkout is *not* a mirror (at least, that's not what is generally called a mirror whose purpose is to avoid accessing the mirrored server)
[13:55] <vila> since in both cases you are accessing the server, it doesn't matter
[13:55] <NEBAP|work> ^^
[13:56] <NEBAP|work> so I shouldn´t use the lightweight checkout for the mirror?
[13:56] <NEBAP|work> what should I use instead?
[13:56] <vila> a standalone branch
[13:56] <vila> and pull regularly
[13:56] <NEBAP|work> I´m trying to use the feature branch layout
[13:56] <NEBAP|work> ok
[13:56] <NEBAP|work> so make a branch from the server trunk
[13:56] <NEBAP|work> make the feature branch
[13:56] <vila> that's what *I* do
[13:56] <NEBAP|work> commit
[13:57] <NEBAP|work> merge the feature branch into the trunk mirror
[13:57] <NEBAP|work> and push the trunk mirror back on the server?
[13:57] <vila> haaaa, now you're exposing your workflow :)
[13:57] <NEBAP|work> ^^
[13:58] <NEBAP|work> so you see, your help isn´t just wasted time ;)
[13:58] <vila> in that case you'b better keep your trunk as a lightweight checkout :)
[13:58] <NEBAP|work> k
[13:59] <NEBAP|work> so after commiting to the feature branch is just
[13:59] <vila> but don't call it a mirror and think about 'bzr update'ing it on a regular basis and especially before merging
[13:59] <NEBAP|work> s/is/I
[13:59] <NEBAP|work> just merge the feature branch in the trunk checkout
[13:59] <vila> right
[13:59] <NEBAP|work> and then commit the trunk checkout to send changes to the server
[13:59] <vila> yes
[13:59] <NEBAP|work> ah cool :)
[14:00] <NEBAP|work> but using push in a brunch doesn´t just overwrite the target, it does more like a commit, right?
[14:00] <vila> at worst you will run into diverged branches if someone else committed between your last update/pull and your commit
[14:01] <vila> push *add* revisions to the target putting both branches (local and remote) back in sync
[14:02] <NEBAP|work> hmm
[14:02] <NEBAP|work> so maybe is push more safe then using a lightweight checkout?
[14:03] <NEBAP|work> to use the send command (using a readonly branch on the server), have I to use a branch or a checkout?
[14:04] <mzz> a checkout of a readonly branch is itself pretty readonly
[14:05] <mzz> well, I guess there's --local, but if you want to commit I'd just use a plain old branch
[14:05] <NEBAP|work> ah ok, sound logically ^^
[14:05] <NEBAP|work> ok
[14:05] <mzz> in fact generally when in doubt just use a plain old branch
[14:05] <NEBAP|work> thank you guys
[14:05] <NEBAP|work> ^^
[14:06] <NEBAP|work> I just tried to use the cool send feature and run into some troubles
[14:06] <NEBAP|work> s/run/ran
[14:06] <vila> What do you want to use 'send' for ?
[14:06] <mzz> and yeah, who or what are you sending to?
[14:07] <NEBAP|work> to avoid problems when more people commit to the trunk, my idea was to make the trunk readonly and force the developers to send the changes to the "committer" which then, can also do some code review
[14:08] <vila> NEBAP|work: send needs a public branch and a submit branch
[14:09] <NEBAP|work> but in contrast it becames a very complex layout then, if I don´t want to lose the possibilty to backup the feature branches ..
[14:09] <vila> the submit branch is where your want the merge proposal to be applied, the public branch is where you will find revisions not included in the bundle if you need them
[14:09] <NEBAP|work> public branch -> read only on the server, submit branch?
[14:10] <NEBAP|work> ah ok
[14:10] <NEBAP|work> seems to be a bit hard with my layout ^^
[14:10] <NEBAP|work> just an idea :)
[14:11] <NEBAP|work> thank you
[14:39] <bialix> hello jam
[14:40] <Tak> jelmer: ping
[14:51] <bialix> jam: thank you.
[15:30] <Tak> ok, so `bzr pull` from a branch of an svn repo fails with an unknown branch id
[15:31] <Tak> but `bzr rebase` gives "Base branch is descendant of current branch. Pulling instead" and succeeds
[15:42] <vila> jam: += 1 in pyx ? What pyrex version are you using :-D
[15:52] <jam> vila: <IP_ADDRESS>
[15:52] <jam> I'll certainly fix those for landing
[15:53] <jam> anyway, I'm in-and-out, (mostly out) this morning because my son is sick again
[15:53] <jam> If you want, you can call my cell phone right now
[15:53] <vila> :-/
[15:53] <jam> I'll have 30min or so to talk
[15:53] <vila> jam: I'm reviewing your rework-annotate proposal
[15:53] <jam> sure
[15:53] <jam> I thought you might want to talk directly about it
[16:11] <flutherben> Hi all--I have a question: Is there a way to make the output of "bzr revno" not show the progress bar and all the download statistics?
[16:12] <beuno> flutherben, maybe if you add -q?
[16:13] <flutherben> Thanks, beuno, I tried --quiet, didn't seem to do it
[16:13] <flutherben> I think it's some kind of global bzr setting
[16:14] <beuno> flutherben, then you will likely have to do it through python to avoid getting a progress bar
[16:16] <mzz> iirc there's some magical env var to disable progress bars
[16:16] <mzz> sec
[16:16]  * beuno does not know the encantation
[16:16] <beuno> vila, hi  :)
[16:17] <mzz> BZR_PROGRESS_BAR=something, I think, sec
[16:18] <mzz> of course I'm not getting any progress bar on "bzr revno" anyway. Hmm, what gets me a progress bar
[16:18] <flutherben> it's only since I moved to 1.16
[16:18] <flutherben> now I'm seeing a bug about "not respecting BZR_PROGRESS_BAR", though it's not clear what the options are yet
[16:19] <mzz> hmm, yes.
[16:19] <mzz> the one function looking at BZR_PROGRESS_BAR is marked deprecated
[16:19] <mzz> err, or maybe not. sec.
[16:20] <mzz> "bzr help configuration" still documents BZR_PROGRESS_BAR
[16:24] <flutherben> hmmm, what's strange it is only seems to be happy on my server, though it's the same version of bzr
[16:35] <awilkins> Holy dungbeetle, verterok, bzr-hudson makes Maven download lots of stuff
[16:36] <vila> hi beuno :)
[16:36] <verterok> awilkins: yes, hudson plugins download a lot of stuff :)
[16:36] <awilkins> Bah, no bzr-java-lib
[16:37]  * awilkins sets up a Hudson job for that too
[16:37] <verterok> awilkins: bzr-java-lib? btw, some changes landed in bzr-java-lib trunk, now it's using commons-logging
[16:40] <flutherben> I can't find any way to turn it off (the BZR_PROGRESS_BAR)
[16:40] <vila> flutherben: 'BZR_PROGRESS_BAR=none bzr revno' should work
[16:40] <flutherben> doesn't work
[16:41] <vila> which bzr version ?
[16:41] <flutherben> 1.16.1
[16:42] <flutherben> http://dpaste.com/64136/
[16:42] <vila> flutherben: fixed in bzr.dev, will be part of bzr 1.17
[16:42] <flutherben> ah, that explains it
[16:42] <flutherben> thanks
[16:43] <vila> there was bug #321935 and bug #339385 at least, both are fixed
[16:51] <flutherben> alright, I guess it's time I move to the dev version
[17:03] <CalicoJck> hello, i was hoping someone might be able to point me in the right direction here...i'm trying to integrate to a subversion server that doesn't have a consistent repository layout.  Depending on which subtree of the repository you are in, branches and tags exist in different locations (or sometimes not at all).  Is there a way to specify the repository layout in subversion.conf for different subtrees of the same subversion repository?
[17:04] <flutherben> Great, using the dev version, now it works
[17:04] <flutherben> thanks
[17:05] <flutherben> also, is bzr co --lightweight the fastest way to get a copy of a branch?
[17:05] <exarkun> Can I specify a custom Python function implementing a merge algorithm to be applied to files which match a particular pattern?
[17:05] <beuno> flutherben, you just want a working tree?
[17:05] <flutherben> yeah
[17:05] <beuno> if so, maybe "bzr branch BRANCH --stacked" is faster. Not sure
[17:05] <flutherben> cool, thx
[19:07] <huf> hi. what's the best way to backup a bzr repo?
[19:07] <huf> just copy the files as they are?
[19:07] <huf> or is there some command i can use that converts to a more future-proof format?
[19:08] <beuno> huf, I just rsync .bzr
[19:09] <beuno> bzr isn's very nice to rsync, but it works
[20:19] <knielsen> abentley: someone suggested I ask you about https://bugs.launchpad.net/bzr/+bug/375898 ... any ideas? It's been sitting for about two months, it is a case where repo gets basically corrupt/unusable due to bzr merge crashing, there is a reproducible test case ...
[20:20] <knielsen> I'm asking, as it is somehow blocking our merging of PBXT into MariaDB ...
[20:21] <knielsen> jam: ^^^ your name was also suggeste :)
[20:22] <abentley> knielsen: Problems like that are quite subtle, so I have no idea how easy or hard it would be to fix.
[20:22] <knielsen> abentley: hm, really?
[20:22] <knielsen> abentley: well, I agree the test case is far from minimal :-( probably >50k commits
[20:23] <knielsen> and not at all clear how to reduce it
[20:24] <abentley> knielsen: I'm not sure how to respond.
[20:25] <knielsen> abentley: no worries, I think you responded fine, the issue has been looked at, but the root cause is not known ....
[20:26] <knielsen> that means probably that we should look into an alternative way to solve the problem, as a fix is not likely to appear soon. Maybe we will have to track merging manually, which ought to avoid the problem
[20:29] <alecwh> Hi, I want to branch my code to work on a site redesign. In git, all I do is "git branch feature_x" (where feature_x would be the experimental feature) in the working directory, and then "git branch" to see which one I'm currently "on".  Then I want to merge my branch back in when I'm done with the site redesign. how do I do this in bzr?
[20:29] <knielsen> abentley: It does worry me somewhat so see repository corruptions like this, was quite fortunate that I happened to test that particular merge before pushing into our main repository and potentially having to roll back lots of commits
[20:30] <Peng_> alecwh: "bzr branch" and "bzr merge". It's just that it's more equivalent to "git clone".
[20:30] <abentley> knielsen: This is not a repository corruption.  It's all to do with merge and the working tree.
[20:31] <knielsen> abentley: hm... are you saying you can see from the bug that the branch is ok, and once the bug in bzr is fixed, the merge could complete?
[20:31] <alecwh> Peng_: when I do this in bzr, inside my working directory, it says, "bzr: ERROR: Not a branch: "/var/www/redesign/"." (from this command: bzr branch redesign)
[20:31] <Peng_> alecwh: bzr help branch :P
[20:31] <alecwh> Peng_: good point, thanks. =)
[20:31] <abentley> knielsen: I am saying there's no reason to suspect this is anything other than a bug in merge.
[20:32] <Peng_> alecwh: cd .. && bzr branch $OLDPWD redesign && cd redesign
[20:32] <Peng_> alecwh: :D
[20:32] <knielsen> abentley: ok, thanks for your help!
[20:32] <alecwh> Peng_: Thanks, I'll be sure to check the docs next time.
[20:40] <alecwh> Does bazaar support topic branching (like git's "branch feature_x")?
[20:40] <dash> alecwh: sure. 'bzr branch oldbranch/ newbranch'
[20:41] <SamB> git doesn't support topic branching in particular -- it just supports branching
[20:41] <SamB> more-or-less correctly
[20:41] <Peng_> alecwh: Bazaar just doesn't support having multiple branches in the same directory.
[20:42] <alecwh> dash: no, I don't want bzr to create another physical branch. With git, I can do a "git branch" and it will show me what branch I am currently on, and then I can switch to one very easily without navigating directories.
[20:42] <SamB> how you use it is your bussiness
[20:42] <alecwh> Peng_: ah, dang.
[20:42] <Peng_> (Well, you can sort of do it with a lightweight checkout and "bzr switch", but...)
[20:42] <SamB> alecwh: I usually use a repo dir full of treeless branch directories in parallell with a lightweight checkout of one of them
[20:42] <dash> weird
[20:42] <Peng_> I'm lazy. I just have lots of trees sucking disk space. :D
[20:43] <dash> same here
[20:43] <Peng_> I usually "bzr remove-tree" them when I'm done, at least on the larger projexts.
[21:24] <RenatoSilva> join #launchpad
[21:53] <RenatoSilva> verterok: hi
[21:53] <RenatoSilva> clear
[21:54] <verterok> RenatoSilva: hi
[21:55] <RenatoSilva> verterok: I've written the other test...
[21:56] <RenatoSilva> verterok: they're running ok for me
[21:56] <verterok> RenatoSilva: thanks!, I have the email in my TODO queue, just that I wasn't hable top take a look yet, I think in a few hours (after my "work day")
[22:09] <RenatoSilva> verterok: ok
[22:41] <flutherben> I was moving hard drives, and I copied over a bzr directory, and now when I commit I'm seeing "aborting commit write group: NoSuchId"
[22:42] <flutherben> any simple way to fix this?
[22:45] <LarstiQ> flutherben: could you paste the traceback?
[22:46] <flutherben> http://dpaste.com/64303/
[22:46] <LarstiQ> interesting
[22:47] <LarstiQ> flutherben: the ~/.bzr.log should have a fuller traceback
[22:47] <LarstiQ> flutherben: what does `bzr info` say?
[22:47] <flutherben> ah
[22:47]  * LarstiQ wild guess would be that it's a branch without its repository
[22:47] <flutherben> bzr info is pointing to a renamed home repository
[22:48] <flutherben> can I re-brand this brand to a new repo?
[22:48] <LarstiQ> depends on what is going on
[22:49] <flutherben> ok, I'll paste the output
[22:49] <LarstiQ> if I'm right, then no, because the branch's revisions are not in the repo it is finding
[22:49] <flutherben> this is the output from bzr-info:
[22:49] <flutherben> http://dpaste.com/64306/
[22:49] <flutherben> (and panda-mirror has been renamed to panda-trunk
[22:50] <flutherben> but it's a new hard drive
[22:50] <flutherben> so it's not the exact same tree
[22:51] <flutherben> and here's my bzr.log
[22:54] <LarstiQ> right, so it is using a shared repository
[22:54] <LarstiQ> flutherben: do you know which repository it was using on the old harddrive?
[22:54] <flutherben> yeah, and I still have access to it
[22:54] <flutherben> panda_mirror
[22:55] <flutherben> er, panda-mirror
[22:57] <LarstiQ> so if you cp -a this branch there, does it give the same error?
[22:58] <flutherben> lemme see
[22:58] <flutherben> I'd prefer to use this new repository, but that would actually be fine
[22:58] <flutherben> hold on
[22:59] <LarstiQ> just trying to confirm my suspicions
[22:59] <LarstiQ> flutherben: how did you copy this branch over from the old to the new one?
[22:59] <flutherben> I just copied it (using os x finder) from the old repo into the new repo
[22:59] <flutherben> seems kinda foolish when I think about it now
[23:00] <flutherben> but the repos are both checkouts of the same branch
[23:00] <LarstiQ> flutherben: yeah, I thought that might be the case.
[23:00] <LarstiQ> flutherben: repo != branch
[23:00] <flutherben> yeah, that makes sense
[23:00] <LarstiQ> flutherben: the repository is what contains the actual revisions, a branch just references them
[23:01] <LarstiQ> flutherben: so if you copy a reference to a place that doesn't have the actual data, boom
[23:01] <LarstiQ> flutherben: using `bzr branch` instead of os cp would prevent that from happening
[23:01] <flutherben> got it
[23:01] <flutherben> lemme try and move it back to the old repo
[23:01] <flutherben> check in there
[23:02] <flutherben> and then bzr branch it in
[23:05] <flutherben> ok, moving it and committing worked
[23:05] <flutherben> I'm getting confused about the bzr branch command
[23:05] <flutherben> is it bzr branch old_dir new_dir?
[23:05] <flutherben> and it will just know to switch repos?
[23:09] <flutherben> wow, it all just worked
[23:09] <flutherben> thanks a lot, LarstiQ
[23:09] <flutherben> I was about to start manually changing things
[23:09] <flutherben> great!
[23:10] <LarstiQ> flutherben: yes, it will know about which repos to use
[23:11] <LarstiQ> flutherben: pleased to be of help
[23:11] <LarstiQ> flutherben: in the future, please don't cp/mv branches out of their repositories, but either copy the repository too or use `bzr branch` :)
[23:11] <flutherben> yeah, for sure
[23:36] <lifeless> bbs
[23:58] <poolie> good morning
[23:59] <LarstiQ> moin poolie
[23:59] <poolie> i'm hoping to fix the rest of bug 391411 and other stacking issues today
[23:59] <poolie> hi LarstiQ


[21:38] <blackboxsw> forgot to follow up on Friday, the Bionic 18.04 for cloud-init acceptance into -proposed was an oversight  and was resolved Friday.


[03:07] <[rg]> hello, is there an interal bug list for ubiquity?
[07:43] <Skuggen> Anyone know the specifics of the user used to run dep8 tests? We have a test failing for MySQL 8.0.17 that gives the same failure as if it had been run as root, but the test does not have needs-root (and the test runner would give a warning if it detected being run as root)
[07:46] <Skuggen> Might be that the SUDO_USER environment variable is set
[08:48] <xnox> CarlFK:  i'm still not convinced it's a good idea =) sorry, setting to won't fix
[08:49] <xnox> CarlFK:  maybe you can find someone else who is more agreable to get that change in.
[08:54] <RAOF> Skuggen: as far as I know, there are no guarantees about the user your dep8 test is run under. If you need to be non-root, create a new user in the test and run under that.
[08:54] <RAOF> (I recently ran into this with colord; you could check its dep8 tests if you like)
[08:56] <Skuggen> RAOF: Thanks! Might be simpler to disable that one test (it is also run during the build)
[12:32] <ahasenack> vorlon: I am taking the bug, yes, thanks. Could I add a review slot for you when the time comes? I'm planning on not even activating the service unit, since the timer will call it.
[12:32] <ahasenack> just let it run over the weekend to confirm it works with just the timer unit activated
[12:32] <ahasenack> (I just let it run over the weekend ...)
[12:43] <Beret> I'm still hitting that weird bug reporting bug I've seen nearly all cycle
[12:43] <Beret> I filed it but it's weird - https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1845950
[12:52] <rbasak> Beret: so that sort of happened to me yesterday, but in Bionic. It was the Privacy settings - disabling reporting there also seemed to disable manually requesting a report in the way you describe. It isn't that for you is it?
[12:54] <Beret> rbasak, problem reporting is set to "Automatic" on the affected system
[12:54] <Beret> so doesn't look like that's it here
[12:55] <rbasak> ack
[13:01] <rbasak> What's the current expectation for Python 2 in Eoan?
[13:01] <rbasak> If I have a port ready for a package in universe, do you want an FFe or should I wait for the next cycle?
[13:56] <vorlon> ahasenack: yes, I can review
[15:10] <rafaeldtinoco> rbasak: https://pastebin.ubuntu.com/p/q58SPFKByt/
[15:11] <rafaeldtinoco> rbasak: the merge request that is accurate is
[15:11] <rafaeldtinoco> https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/simplestreams/+git/simplestreams/+ref/xenial-1686437-keystone-v3
[15:12] <rbasak> rafaeldtinoco: would it be best to get Bryce to sponsor it tomorrow?
[15:12] <rafaeldtinoco> yep
[15:12] <rafaeldtinoco> I think so
[15:13] <rafaeldtinoco> its complex enough for context switch
[15:13] <rafaeldtinoco> you're right
[17:21] <xnox> Laney:  vorlon: i hate initramfs-tools! end of message
 phew
[17:23] <xnox> ahasenack:  related
[17:23] <ahasenack> :)
[19:53] <bdmurray> juliank: Would using Version.section, seen in bug 1845593, also fix bug 1841675?
[19:54] <juliank> bdmurray: sounds like ir


[14:58] <cyphermox> o/
[14:58] <sil2100> \o
[14:59] <robru> o~
[15:00] <pitti> *\o
[15:01] <chiluk> o/
[15:01] <barry> o=
[15:01]  * slangasek waves
[15:02] <cyphermox> pitti: pom poms?
[15:02] <slangasek> #startmeeting
[15:02] <meetingology> Meeting started Thu Apr 14 15:02:17 2016 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:02] <pitti> cyphermox: piece of birthday cake :)
[15:02]  * pitti hands out a piece to everyone
[15:02] <cyphermox> oh cool
[15:02] <cyphermox> but the cake is a lie.
[15:02] <pitti> it's quite real here, I assure you :)
[15:03] <xnox> oooh i have left over cake
[15:03] <barry> hbmp!
[15:03] <slangasek> pitti: your birthday?  the calendar doesn't tell me it's your birthday
[15:04] <slangasek> maybe I need a better calendar instead of trusting G+ to keep me informed ;)
[15:04] <infinity> He didn't say it was his cake.
[15:04] <cyphermox> pitti: best wishes for your birthday
[15:04] <infinity> For all we know, he stole it.
[15:04] <chiluk> pitti it's my birthday as well!
[15:04] <slangasek> infinity: quite possible, hence asking rather than assuming ;)
[15:04] <cyphermox> infinity: he could steal his own birthday cake too.
[15:04] <barry> chiluk: hb!
[15:05] <pitti> chiluk: wow, happy joint birthday then! *clink*
[15:05] <slangasek> pitti, chiluk: happy birthday!
[15:05] <cyphermox> chiluk: happy birthday
[15:05] <sil2100> pitti, chiluk: happy birthday then!
[15:05] <slangasek> [TOPIC] Lightning round
[15:05] <chiluk> that's pretty rate.
[15:05] <chiluk> rare
[15:05] <bdmurray> didn't this happen last year in Austin?
[15:05] <pitti> cheers!
[15:05] <slangasek> $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx xnox chiluk)
[15:05] <slangasek> doko chiluk bdmurray slangasek cyphermox barry xnox tdaitx infinity pitti robru sil2100 caribou
[15:05] <pitti> yes, I chalked up my 35th in Austin last year
[15:06] <infinity> Young'un.
[15:06] <slangasek> doko isn't making the meeting, sent his status to list
[15:06] <slangasek> chiluk:
[15:06] <pitti> dholbach got me space ice cream (freeze-dried)
[15:06] <chiluk> lp1567539. Finally got access to some ppc64el hardware, and spent a day rebooting, attempting to dump, and trying again.  Eventually came to the conclusion that crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M@32M is the correct magic line that needs to be added to ppc64el machines.
[15:06] <chiluk> -done-
[15:06] <chiluk> bug 1567539
[15:06] <pitti> chiluk: that looks totally obvious (... WUT?)
[15:06] <bdmurray> worked with stub to migrate to a consolidated cassandra database
[15:06] <bdmurray> rebuild of bucket versions count on real cassandra (final import finished)
[15:07] <bdmurray> backported python-pycassa fix to precise (Traceback after migration)
[15:07] <bdmurray> tested staging cassandra for DateTime bug (no luck)
[15:07] <bdmurray> reported / verified fix for RT 90484 re: daisy app servers OOPS
[15:07] <bdmurray> uploaded u-r-u and u-m fixes for LP: #1566141 (turn off screensaver)
[15:07] <bdmurray> fixed u-r-u bug LP: #1509655 (conffile dialog)
[15:07] <bdmurray> worked on a fix for LP: #1569233
[15:07] <bdmurray> investigation into LP: #1530518
[15:07] <bdmurray> package-subscribers modifications for dev release and xz
[15:07] <slangasek> chiluk: what, you didn't learn that rule in elementary school? 2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M@32M , never 2G-4G:320M,4G-32G:512M,32G-64G:768M,64G-128G:2048M,128G-:4096M@32M
[15:07] <bdmurray> submitted RT re: installing packages on cranberry and snakefruit
[15:07] <bdmurray> upgrader / foundations bug triage
[15:07] <bdmurray> travel arrangements
[15:07] <bdmurray> ✔ done
[15:08] <chiluk> ah I see you changed the value for 32-64g
[15:08] <slangasek> no I would never change it
[15:08] <slangasek> I know my ABCs and my 32Gs
[15:08] <slangasek>  * wandered down to the CPC team's sprint that was in town this week, to talk about image building, seed ownership, and other fun topics
[15:08] <slangasek>  * poked a bit at the lua build failures, found something that may be a glibc regression, worked around it (LP: #1570055)
[15:08] <slangasek>  * published snappy images to cdimage.ubuntu.com as a one-off, pending proper central launchpad building of them
[15:08] <slangasek>  * queue processing for the release: juju 2.0 packages all reviewed
[15:08] <slangasek>  * sprint travel planning; Austin the first week in May, Vancouver the second
[15:08] <slangasek>  * looking to get a completely free edk2 package in for 16.04, so we have proper UEFI firmware images that can be pulled in by default where needed (thanks to dannf for driving most of this)
[15:08] <slangasek>  * off tomorrow
[15:08] <slangasek> (done)
[15:09] <robru> wait what about vancouver
[15:09] <cyphermox> xenial:
[15:09] <cyphermox> - NetworkManager 1.1.93
[15:09] <cyphermox> - add tpm2-tools Depends on libtss2-utils (bug LP: #1569057)
[15:09] <cyphermox> - debugged n-m-pptp VPN crashes in ppp (bug LP: #1568336)
[15:09] <cyphermox> - desktop-base / debian logo in grub theme issue
[15:09] <chiluk> slangasec is it the whole team that will be in austin in may?
[15:09] <cyphermox> - fixed password validation feedback for Mok in ubiquity (bug LP: #1560940)
[15:09] <cyphermox> - fixing network-manager autopkgtests
[15:09] <cyphermox> - localechooser fix for language translation data (bug LP: #1551285)
[15:09] <slangasek> robru: not a sprint you need to worry about
[15:09] <slangasek> chiluk: yes
[15:09] <chiluk> kick ass..
[15:09] <cyphermox> - merged ubiquity fix from FourDollars
[15:09] <cyphermox> - misc ubiquity bugfix
[15:09] <cyphermox> - missing zh_CN glyphs in grub (bug LP: #1559933)
[15:09] <cyphermox>   - bisected in freetype (newest from Debian also no good); I need to look all it and grub-mkfont harder.
[15:09] <robru> slangasek: but that's my home turf!
[15:09] <cyphermox> - testing ltrace upload (bug LP: #1547152)
[15:09] <cyphermox>   - on ppc64el, armhf and x86
[15:09] <cyphermox> - translation updates (bug LP: #1569232)
[15:09] <xnox> robru, snappy sprint in vancouver i think.
[15:09] <cyphermox>   - ubiquity and ubiquity-slideshow-ubuntu
[15:09] <cyphermox> - ubiquity mokutil integration fixes (bug LP: #1567445)
[15:09] <cyphermox> - vt switching in ubiquity/oem-config (bug LP: #1567194)
[15:09] <cyphermox> ±other stuff:
[15:09] <cyphermox> - backporting ltrace patches for ppc64el
[15:09] <cyphermox> - setting up raspi2 for armhf testing
[15:10] <cyphermox> (done)
[15:10] <barry> paramiko FTBFS; gdebi <IP_ADDRESS>ubuntu1 (fixes FTBFS); debian bug #815294 (python-scripttest FTBFS); routes 2.2-1ubuntu2 (fixes FTBFS); looked at lua5.x FTBFS (LP: #1570055; investigated on powerpc, but slangasek fixed it); other FTBFS and -proposed migration investigations
[15:10] <barry> system-image 3.1 rode the train
[15:10] <barry> LP: #1568889 triage
[15:10] <barry> LP: #1530518
[15:10] <barry> starting to look at python-pip FTBFS
[15:10] <barry> --done--
[15:10] <xnox> unbroke gnupg2 upstart usersessions
[15:10] <pitti> cyphermox: any bad feedback about NM yet? I didn't hear anything so far
[15:10] <xnox> archive-reorg merged boost sources
[15:10] <xnox> s390x installer fixes
[15:10] <xnox> s390x package fixes
[15:10] <xnox> unbroke update-notifier motd after full-upgrade
[15:10] <xnox> done
[15:10] <cyphermox> pitti: some bug reports, but that's unavoidable.
[15:11] <xnox> pitti, i'm having nameserver woes, but cannot pin down the semantics of the bug yet.
[15:11] <cyphermox> pitti: that said, I'll need your help to iron out a small issue in the units for ubiquity
[15:11] <bdmurray> cyphermox: I opened some bugs from crashes the other day
[15:11] <tdaitx> # 2016-04-14
[15:11] <tdaitx> = Security update for OpenJDK 7
[15:11] <tdaitx> * Backported 8 patches (1 jaxp + 7 jdk)
[15:11] <tdaitx> * Working on the only hotspot patch
[15:11] <tdaitx> - The changes depend on other changesets, but most of those introduce additional unwanted features for OpenJDK 7 and are proving a challenge to isolate
[15:11] <tdaitx> - In a different approach I refactored the patch in order to have it apply directly to OpenJDK 7, without other backports, but it segfaults
[15:11] <tdaitx> - Broke down modified patch (132 chunks originally) and identified offending chunks (83 of them, trying to isolate them further than that)
[15:11] <tdaitx> - Debugging segfault to identify offending code, but hotspot is hard
[15:11] <tdaitx> = Other
[15:11] <tdaitx> - Finished travel arrangements
[15:11] <tdaitx> - Next Thursday is a holiday (will work and swap it)
[15:11] <tdaitx> (done)
[15:11] <cyphermox> bdmurray: yep, I have some in a list
[15:12] <infinity>  - Mostly queue reviews and fielding release-related IRC pings
[15:12] <infinity>  - Discussions with kernel team about [redacted]
[15:12] <infinity>  - Prepping final (hopefully?) pre-freeze glibc upload
[15:12] <infinity>  - Mid-review of armhf+raspi2 cdimage merge
[15:12] <infinity>  - Working on updating IBM PPC userspace tools
[15:12] <infinity>  - Worked with Dmitri to get s390-tools out of minimal
[15:12] <infinity>  - Lots of archive cleanup
[15:12] <infinity>  - Sprint/travel plans
[15:12] <infinity>  - s390x build maintenance, and glib2.0 FTBFS fix
[15:12] <infinity> (done)
[15:12] <cyphermox> infinity: you need to review my cpc merge!
[15:12] <pitti> autopkgtest:
[15:12] <pitti>  - Add option to set more appropriate parallel= build option in LXC (#1569750)
[15:12] <pitti>  - Automate setup of armf LXD test slave
[15:12] <pitti>  - Fixed failure to run setup script on lcy01
[15:12] <infinity> cyphermox: Yeah, I'm fixing it up right now. :P
[15:12] <pitti>  - Investigate wrong hostname, turned out that it's the postfix test that does that (#1570001)
[15:12] <pitti>  - Refine daily autopkgtest image builds, charm up the automation (#1569546)
[15:12] <pitti>  - Reattempt to use arm64 scalingstack instances for armhf autopkgtesting, works well enough now (#1531768); automate setup of armf LXD test slave, but no control logic yet
[15:12] <pitti> distro:
[15:12] <pitti>  - Fix FTBFS: dicto-moby-thesaurus, grep, libvigraimpex, mako, python-configglue, ros-robot-model, ubuntu-drivers-common (armhf)
[15:12] <pitti>  - apt: Apply David's fix for upgrade failures involving Pre-Depends (#1560797)
[15:12] <pitti>  - apport: disable LP crash reports for final release
[15:12] <pitti>  - lxd: Investigate looping startup failure (#1569698)
[15:12] <pitti>  - network-manager: fix failure to start under upstart (#1569204)
[15:12] <pitti>  - systemd: Fix enabling of linked units (#1563590), keymap updates
[15:12] <pitti>  - udev: fix handling of change events with multipath devices (#1565969), fix wrong device naming with ibmveth (#1561096)
[15:12] <pitti>  - Investigate ssh installation failure in QA desktop tests (#1554266)
[15:12] <pitti>  - Review proposed openssl FIPS change; landed now, just needs a followup upload for some patch cleanup (#1553309)
[15:12] <pitti>  - Discuss improving the lxd debconfery with stgraber (#1567874)
[15:12] <pitti>  - archive admin, release engineering, queue reviews, etc.
[15:12] <pitti>  (done)
[15:13] <robru> lp:cupstream2distro
[15:13] <robru> - switched xenial half of dual silos to target overlay ppa so phone development not slowed by archive freeze
[15:13] <robru> lp:bileto ephemeral PPA work marches on
[15:13] <robru> - learned how to mock coroutines
[15:13] <robru> - wrote a big chunk of unit tests
[15:13] <robru> - fixed issue with dpkg-buildpackage not signing packages
[15:13] <robru> (dune)
[15:13] <xnox> infinity, will you take the bugfix patches into glibc for the bug #1564918 ?
[15:13] <sil2100> - Landing team work, silo coordination, preparing landing e-mails
[15:13] <sil2100> - RTM status meetings
[15:13] <sil2100> - Security hotfix OTA:
[15:13] <sil2100>   * Consulting the vulnerability, agreeing on putting the store to manual-review
[15:13] <sil2100>   * Staying late and landing the fix and re-spinning a snapshot-based rc image
[15:13] <sil2100>   * Release to the users
[15:13] <sil2100>   * Prepare the release notes, ask for CVE publication
[15:13] <sil2100> - Language packs:
[15:13] <sil2100>   * Investigating and fixing missing UITK translations from l-o-m runs
[15:13] <sil2100>   * Looking into invalid translation percentages for ubuntu-rtm/15.04 (1152% translation ratio is not good)
[15:13] <sil2100> - Copying images as requested by management for OTA-10.2, sending for testing
[15:13] <sil2100> - Dealing with some miscommunication issues between various teams
[15:13] <sil2100> - Some work on the testability branch in system-image
[15:13] <sil2100> - Writing down a draft for emergency procedures in touch (security updates, reverts)
[15:13] <sil2100> - First DMB meeting, partaking in review of 3 applicants, re-scheduling remaining candidates
[15:13] <sil2100> - Clean up on some unused system-image channels
[15:13] <sil2100> - Answering touch user e-mails (got strangely a lot of those this week)
[15:13] <sil2100> (done)
[15:14] <slangasek> pitti: openssl \o/
[15:14] <pitti> slangasek: well, I wouldn't call it \o/
[15:15] <slangasek> :)
[15:15] <pitti> slangasek: there's another followup upload coming with some patch cleanup (talking to jmbl as we speak)
[15:15] <pitti> but the bulk is in ind eed
[15:15] <infinity> xnox: The glibc upload will include an update to the tip of the 2.23 branch, which they claim contains the fixes.
[15:15] <cyphermox> pitti: scary openssl FIPS changes? :)
[15:15] <xnox> infinity, excellante.
[15:15] <slangasek> and no caribou because he is auditioning for a role as Sebastian the Crab
[15:15] <cyphermox> (scary because it's openssl, not scary because of the patches)
[15:16] <pitti> cyphermox: you bet :/
[15:16] <infinity> slangasek: He... What?
[15:16] <pitti> cyphermox: no, scary because of the patches indeed
[15:16] <slangasek> infinity: he's under the sea
[15:16] <cyphermox> pitti: well, a bit of that too ;)
[15:16]  * infinity needs to read his email more closely.
[15:17] <slangasek> infinity: no, you just need to think like me, that's all
[15:17] <slangasek> any questions re: status?
[15:17] <cyphermox> is under the sea a euphemism for sick?
[15:17] <slangasek> cyphermox: no, he wrote that he is literally under the sea at this time :)  (EuroStar)
[15:18] <cyphermox> oh, cool!
[15:18]  * pitti still catching up reading
[15:19] <cyphermox> no questions from me.
[15:19] <slangasek> [TOPIC] AOB
[15:19] <slangasek> anything else for the meeting?
[15:19] <slangasek> oh
[15:19] <slangasek> release week next week
[15:19] <slangasek> so no meeting, I'll take it off the calendar
[15:21] <slangasek> everybody has sprint travel booked by now, I hope?
[15:22] <barry> sprint*s*
[15:22] <pitti> yes, for both (cloud and foundations/kernel/security)
[15:24] <slangasek> remember, if you don't get your travel dates into the spreadsheet, you won't have a hotel room and will have to sleep in the hotel kitchen instead
[15:24] <tdaitx> yes, booked both
[15:24] <infinity> slangasek: On a bed of knives?
[15:24] <barry> slangasek: but at least then you can get 24h breakfast
[15:24] <pitti> oh, not in a nearby pub?
[15:25] <slangasek> infinity: you can use spatulas, they're not cruel
[15:25] <infinity> I do like me a cruelty-free spatula.
[15:25] <tdaitx> pitti: if we don't put the dates we get to sleep in a nearby pub? and you only tell me this now?
[15:25] <robru> i do believe I am fully booked for both
[15:26] <robru> hehe
[15:26] <pitti> cyphermox, slangasek: do you plan a final shim upload/signing for xenial to fix that FTBFS, or will that be done in the next SRU?
[15:26] <infinity> Turning shim around that fast isn't possible.
[15:26] <slangasek> pitti: we don't upload shim for FTBFS fixes, only when we must get a new shim signed
[15:26] <cyphermox> we'll need to get started thinking about a new shim though
[15:26] <slangasek> the fix is staged but it doesn't go anywhere until we need one
[15:26] <cyphermox> ie. for my MokSBStateRT patch
[15:26] <pitti> ack
[15:27] <slangasek> cyphermox: right
[15:27] <cyphermox> and perhaps consider setting up fallback.efi correctly
[15:27] <slangasek> cyphermox: should that be done before we rotate the daily signing key?
[15:27] <cyphermox> hrm
[15:27] <slangasek> setting up fallback.efi doesn't need to be done in the shim package, we should handle it from shim-signed or elsewhere
[15:28] <slangasek> (so that we're not causing churn to shim by packaging changes either)
[15:28] <cyphermox> sure, but while looking at shim, is what I mean
[15:28] <slangasek> right
[15:28] <osama> I need a local community for my university
[15:28] <infinity> I need a pony
[15:29] <slangasek> osama: sorry, this isn't really the place to ask; we're in the middle of a team meeting
[15:29] <infinity> osama: (This is a channel for holding meetings (which we're currently in the middle of), not for meeting people)
[15:29] <slangasek> ok! anything else?
[15:29] <osama> so lead me anywhere else please!
[15:29] <cyphermox> osama: there probably is a channel for the country or state you live in, look in http://loco.ubuntu.com/
[15:30] <osama> ok sorry buddies and thanks
[15:32] <slangasek> #endmeeting
[15:32] <meetingology> Meeting ended Thu Apr 14 15:32:05 2016 UTC.
[15:32] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-04-14-15.02.moin.txt
[15:32] <xnox> bug #1
[15:32] <barry> thanks!
[15:32] <xnox> pitti, ^
[15:32] <tdaitx> infinity: here you go http://www.canadianponyclub.org/
[15:32] <tdaitx> =)
[15:32] <bdmurray> I thought we had a pony
[15:33] <bdmurray> Although that was back in the day
[15:33] <cyphermox> tdaitx: 6 to 25 yr olds only. it's a private club
[15:33] <xnox> they have ponies "For Enjoyment"
[15:33] <pitti> bdmurray: indeed, almost forgot about that!


[12:58] <Goog_Josh> does anybody khow why cron can't exec some applications like totem, kaffeine etc.?
[18:09] <bilalakhtar> kenvandine: Back?
[18:12] <bilalakhtar> kenvandine: ah, leave it, 'twas about sponsoring
[18:13] <lamalex> anyone know if chris has a ppa for firefox 4?
[18:13] <bilalakhtar> maybe
[18:13]  * bilalakhtar checks
[18:13]  * lamalex just realized he can check himself
[18:13] <lamalex> duh
[18:14] <lamalex> im still tired from uds :P
[18:21] <bilalakhtar> lamalex: https://edge.launchpad.net/~mozillateam/+archive/firefox-next
[18:21] <bilalakhtar> bye, hafta go
[19:51] <lamalex> anyone know if there's a maverick ppa for gtk3? is it possible to install gtk3 along side gtk2?
[19:52] <lamalex> ah, I've just found https://launchpad.net/~ubuntu-desktop/+archive/gnome3-builds
[20:05] <lamalex> hey, do any of you know if we'll be using the same gnome-appearance-properties in Natty as we use in Maverick, or if we'll be changing to gnome-control-center
[20:09] <TheMuso> lamalex: I think seb128 can give you a better idea of that, and of course he is not around, being a weekend.
[20:10]  * lamalex should probably not be around either
[20:10] <lamalex> and you too
[20:10] <chrisccoulson> TheMuso, are you still in orlando?
[20:10] <TheMuso> No, I am in Boston, for plumbers later this week.
[20:11] <TheMuso> Currently in my room, hoping to hook up with others later for a drink/some communal hacking if I can find them.


[00:50] <wxl> kc2bez[m]: looks like we got our answer and should concoct something for calamares to do with the file check https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1918733/comments/2
[00:52] <kc2bez[m]> Okie dokie, will make a task for that.
[00:53] <wxl> thank you
[00:53] <wxl> we can steal the json parsing we use in geomirror
[00:54] <kc2bez[m]> Yeah, good idea.
[00:54] <wxl> to be fair we could probably steal the apport code since it parses it for bugs
[01:00] <wxl> jphilips: good luck. you might also want to try to suggest adding the functionality in on the snapcraft forum.
[01:01] -lugito:#lubuntu-devel- [T203: Calamares should evaluate the results of the casper file integrity check.] kc2bez (Dan Simmons) just created this task: https://phab.lubuntu.me/T203
[01:01] <wxl> danke
[01:01] <wxl> oops on that last message jeez
[01:05] <kc2bez[m]> I got caught up on the -flavors channel. It makes sense now :D
[01:08] <wxl> yep :)
[04:48] <guiverc> careful with COPY.LINK.ADDRESS from a re-sized qterminal window..  (i think)
[04:53] <guiverc> newly discovered/filed bug 1918858... I'll test it in debian/opensuse & if present there too, likely file upstream (as I can)
[06:19] -lugito:#lubuntu-devel- [Lubuntu CI] jobgenerator just failed after succeeding: https://ci.lubuntu.me/job/jobgenerator/905/


[02:50] <shift_wreck> 'elo bluetux
[02:50] <bluetux> shang, hello
[02:50] <bluetux> sorry
[02:50] <bluetux> shift_wreck, hello
[02:50] <shift_wreck> you can call me shang if you want :)
[02:50] <shift_wreck> whats up?
[02:51] <bluetux> No, just join :-)
[02:51] <shift_wreck> ah, welcome
[02:51] <bluetux> Thanks you~~
[02:51] <shift_wreck> yep
[07:00] <suji> hi
[07:00] <suji> what package need to download torrent file in Ubuntu?
[07:03] <jussi01> suji: support is in #ubuntu
[07:03] <suji> ok


[04:20] <db`> Hi Ops,
[04:20] <db`> Got +q on #ubuntu
[04:20] <db`> for "spam" apparently.
[04:20] <db`> I had posted 1 long message seeking help.
[04:20] <db`> Can please fix my account in there?
[04:22] <db`> Got +q ed again
[04:29] <Unit193> ...Yes, because you did the same thing again...


[13:13] <billfarrow> what would we need to host a local Global Jam workshop in the Triangle ?
[14:16] <holstein> billfarrow: not much really
[14:16] <holstein> we (akgraner internalkernel and i) were talking about doing one more online anyways
[14:16] <holstein> just say when, and let the where's be local
[14:17] <holstein> send out emails about where you are doing it, and then try and check in here :)
[14:17] <holstein> anyways... you really just need a place with internet, and some folks to come
[14:18] <billfarrow> yeah, I don't want to drive 3hrs to Charlotte, but I would like more face to face colaboration
[14:18] <holstein> where are you?
[14:18] <billfarrow> Nivex: do you want to do some Global Jam together ?
[14:18] <holstein> we are hosting something in asheville for sure
[14:18] <billfarrow> holstein: Raleigh
[14:19] <holstein> i say, pick a place, and send it out on the list
[14:19] <holstein> someone will probably come
[14:20] <billfarrow> I think we could russle something up here.  I have no idea what we would do, but get enough smart people in a room and something good should happen
[14:21] <holstein> well, you just check in on here, and we can make sure we are not doubling our efforts
[14:21] <holstein> we'll probably try and fix wikis


[06:20] <ochosi> Unit193: and running it with gdb so you can give me a backtrace for that?
[06:28] <Unit193> Heh, first time I've installed a dbgsym package from that repo. :P
[06:28] <Unit193> Ugh, restarting the panel means I have to re-sort everything.
[06:29] <Unit193> ochosi: I'm not hitting it right now. :/
[06:39] <ochosi> :)
[06:39] <ochosi> maybe related to a plugin?
[06:39] <ochosi> although it would have to be an internal one to make the panel crash...
[06:41] <Unit193> http://paste.openstack.org/show/kMbz9fNWE0GDIzLj5mR9/ doesn't really look like a crash exactly..
[07:54] <ochosi> Unit193: that's just the regular terminal output, no? or did you use PANEL_DEBUG=gdb?
[07:55] <ochosi> cause that by itself doesn't tell me much
[07:56] <Unit193> Indeed it doesn't, and yeah not running under debug.  The issue is it sits for a while before I restart, and as noted if I quit and start it, I can't seem to hit the issue.
[08:01] <ochosi> you'd have to always start it in debug mode...
[09:58] <bluesabre> https://wiki.ubuntu.com/BetaFreeze (last edited by micahg) :)
[09:59] <bluesabre> Went ahead and pushed the panel since its a bugfix release... hopefully will just slide through the queue :)
[10:05] <ochosi> kewl
[10:05] <ochosi> thanks
[10:05] <ochosi> i think they added an auto-approve mechanism this cycle
[10:06] <ochosi> so it may actually just slide through unnoticed
[10:14] <bluesabre> I think that only applies to unseeded things, so it will require an approval
[10:15] <bluesabre> Up until the last few days, they sometimes just release the queue
[10:15] <bluesabre> That's what I'm hoping for :D
[18:55] -SwissBot:#xubuntu-devel- ::platform:: Move non-cloud kernels from supported-cloud to supported-kernel-common. @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=af3ab25c182186b6f781fabdbbf207979224305a (by Adam Conrad)
[19:03] -SwissBot:#xubuntu-devel- ::platform:: Add missing linux-snapdragon to supported-kernel-common. @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=a155c3c2200746fb4db6313c59833c1f16a8f6fb (by Adam Conrad)


[06:13] <mup> PR snapd#9586 opened: update-pot: include file locations in translation template, and extract strings from desktop files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9586>
[07:09] <mup> PR snapd#9587 opened: snap: fix failing unittest for quantity.FormatDuration() <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9587>
[07:14] <mborzecki> morning
[07:14] <jamesh> Do we have a unit test that assumes all months have 30 days?
[07:15] <zyga> good morning
[07:16] <zyga> mvo, with samuele away for the part of the week, 9546 won't make official progress but perhaps it could be reviewed by others to spot any mistakes or weirdness
[07:16] <jamesh> It looks like the TestSnapshotImportHappy test was written to start failing on November 1st
[07:16] <zyga> I suspect the changes are acceptable by him now, he just ran out of review time on Friday
[07:17] <zyga> hey jamesh :)
[07:17] <jamesh> hi zyga
[07:19] <mborzecki> zyga: jamesh: hey
[07:22] <mvo> good morning mborzecki and zyga
[07:23] <mborzecki> mvo: hey
[07:23] <mvo> and good afternoon jamesh :)
[07:23] <mvo> zyga: I will try to have a look
[07:23] <mvo> jamesh: I pushed a PR to fix the failing unittest
[07:23] <mvo> jamesh, mborzecki PR#9587 fwiw
[07:24] <zyga> mvo, thanks, no rush but I think making that landable will allow the rest to be reviewed in parallel
[07:26] <zyga> mvo, https://github.com/snapcore/snapd/pull/9204 is green and has +2 but should be acked by someone the last time
[07:26] <mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
[07:26] <zyga> jamesh, I think you will like that ^
[07:26] <zyga> it makes snap identification work on Fedora and elsewhere
[07:26] <zyga> where we have cgroupv2
[07:28] <jamesh> mvo: might it be better to remove the check entirely?  Your fix looks like it will only help up until March
[07:29] <mvo> jamesh: not opposed to remove it, it's the wrong layer for this test anyway
[07:34] <mvo> mborzecki: how do you feel about merging 9582?
[07:51] <mborzecki> mvo: sounds good to me, i can open a followup with test name tweak
[08:02] <pstolowski> morning
[08:02] <mvo> good morning pstolowski
[08:03] <zyga> hey pstolowski :)
[08:05] <pstolowski> o/
[08:05] <mborzecki> mvo: if you don't mind i'll push a patch dropping the check competely to #9587
[08:05] <mup> PR #9587: snap: fix failing unittest for quantity.FormatDuration() <Skip spread> <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9587>
[08:05] <mvo> mborzecki: please do
[08:14] <mup> PR snapd#9588 opened: dirs: add "gentoo" to altDirDistros <Created by zmedico> <https://github.com/snapcore/snapd/pull/9588>
[08:19] <zyga> mborzecki, https://github.com/snapcore/snapd/pull/9588#pullrequestreview-521409043
[08:19] <mup> PR #9588: dirs: add "gentoo" to altDirDistros <Created by zmedico> <https://github.com/snapcore/snapd/pull/9588>
[08:19] <zyga> FYI
[08:24] <mup> PR snapd#9582 closed: gadget/quantity: introduce a new package that captures quantities  <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9582>
[08:34] <mup> PR snapd#9589 opened: gadget/quantity: tweak test name <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9589>
[08:54] <mup> PR snapd#9587 closed: snap: fix failing unittest for quantity.FormatDuration() <Skip spread> <⚠ Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9587>
[09:24]  * dot-tobias says hi
[09:41] <mvo> can someone check 9560 please? needs a second review, maybe mborzecki  ?
[09:42] <mborzecki> mvo: i have it open, just checkign some things that ondra raised
[09:43] <mvo> mborzecki: sure, thank you! no rush
[09:45] <mvo> zyga: nice, 9204 is green now \o/
[09:54] <mup> PR snapd#9589 closed: gadget/quantity: tweak test name <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9589>
[10:08] <niemeyer> Heya
[10:08] <niemeyer> Good morning all
[10:08] <niemeyer> pstolowski: Around?
[10:09] <pstolowski> niemeyer: hey, yes
[10:09] <niemeyer> pstolowski: Do you have a moment to explain the task-id/change-id presence in the timing module?
[10:11] <niemeyer> pstolowski: Even ignoring the encapsulation concern (timing knows about details of tasks/changes usage of itself), it seems curious that this logic takes effect precisely when timings are empty
[10:18] <pstolowski> niemeyer: yes. 1 - we enrich the data returned to snap debug timings with doing/undoing times obtained from tasks, and we combine this data when queried; 2 - for change-id, we want to correlate a change with ensure loop that triggered it
[10:19] <niemeyer> pstolowski: Yeah, I understand the idea of tagging. Seems sound. I don't understand the idea of preserving a timing that has no timings.
[10:22] <pstolowski> niemeyer: i don't think this is the case -  see func (t *Timings) Save(s GetSaver) line 140 & 141, and flatten() line 85
[10:23] <niemeyer> 	if len(t.timings) == 0 && !isEnsureWithChange {
[10:23] <niemeyer> 		return nil
[10:23] <niemeyer> 	}
[10:25] <niemeyer> pstolowski: The only use cases I can identify are clearly being used only to prevent wiping out empty timings
[10:29] <pstolowski> niemeyer: right,  i see what you mean, i need to think what was the driver for this change
[10:29] <niemeyer> pstolowski: If it's irrelevant, that's a nice cleanup. Besides simplifying the logic and making it less obscure, it also takes away the only reason why there's breakage of encapsulation there.
[10:31] <niemeyer> pstolowski: There's also a potential change in API that would reduce the API surface of the module. But that's a more involved improvement and that isn't really fixing any clear structural issues.
[10:35] <pstolowski> niemeyer: so related PR is https://github.com/snapcore/snapd/pull/6904 and second paragraph of the description summarizes the reason for keeping empty timing in this case; there was a small followup https://github.com/snapcore/snapd/pull/6921 where I unfortunately dropped the comment that was useful
[10:35] <mup> PR #6904: timings: always store ensure timings as long as they have an associated change <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6904>
[10:35] <mup> PR #6921: timings: tweak the conditional for ensure timings <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6921>
[10:39] <niemeyer> pstolowski: Ah, it's nice to have the background, thanks. It still seems suboptimal, though.. you have two pieces of logic inside the module fighting with each other, and in a pretty convoluted manner, requiring knowledge of completely unrelated things.
[10:39] <niemeyer> pstolowski: That is,
[10:40] <niemeyer> pstolowski: There's one thing that removes fast timings, one thing that removes top-level empty timings, and one thing that prevents both of these from working.
[10:40] <niemeyer> pstolowski: If top-level timings are relevant even if they are empty, then we might just keep them around.
[10:41] <niemeyer> pstolowski: If fast timings are still relevant because people might search for them, we might just keep them around as well.
[10:41] <niemeyer> pstolowski: Or reduce the threshold until it's more honest
[10:42] <niemeyer> Either way, thanks for the background. That's indeed what I was looking for and now I know how to proceed with the skeleton here. This is not super important for snapd, so I'll let you decide whether/when to look into it.
[10:43] <pstolowski> niemeyer: yes, i see how it is convoluted.  the only concern is not to  exhaust our timings "buffer" in the state, we want to keep a limited number of them, and we want only those that are time-consuming, so we don't want empty timings there in most cases
[10:45] <niemeyer> pstolowski: Sounds like the code disagrees. You've made a decision based on UX to actually have non-time consuming things around to satisfy user searches.
[10:47] <niemeyer> pstolowski: Proper encapsulation would try to understand that requirement and design for it, instead of teaching the module to do guess work based on deep knowledge of things far away.
[10:52] <pstolowski> niemeyer: no disagreement. in the defence of that, this was initially all about task/changes (and imported state). a year later it was separated with https://github.com/snapcore/snapd/pull/8283
[10:52] <mup> PR #8283: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8283>
[10:56] <niemeyer> pstolowski: What I see there is Samuele working exactly on the direction being suggested here, which is clean up the encapsulation
[10:56] <pstolowski> unbelievable, it's 2 years since timings were introduced, time flies...
[10:56] <niemeyer> pstolowski: This is a top-level package..
[10:56] <niemeyer> Yeah, timing flies
[10:57] <pstolowski> niemeyer: yes.. although the driver had a different angle as mentioned on mattermost... we wanted to not import state package elsewhere
[10:57] <niemeyer> pstolowski: Not importing the state package only has a meaning if you're not marrying with its internals :)
[10:58] <pstolowski> yes sure
[11:31] <mvo> mborzecki: 9577 looks good to me now, wdyt?
[11:37] <mvo> mborzecki: I fixed one missing test update in 9560 and then I think this can land :) thanks for the review!
[11:38] <mborzecki> mvo: i've done the followup changes, but having some trouble with mocking sfdisk properly
[12:01] <pstolowski> mvo: i've a spread test for download timeout, slightly tricky stuff
[12:01] <pstolowski> see #9590
[12:01] <mup> PR #9590: tests: download timeout spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/9590>
[12:02] <mvo> pstolowski: nice
[12:04] <mvo> pstolowski: just looked, really cool
[12:05] <pstolowski> mvo: let's see if it's not flaky or something.. i only run it on 20.04
[12:05] <mup> PR snapd#9590 opened: tests: download timeout spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/9590>
[12:45] <mup> PR snapd#9560 closed: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions <Run nested> <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9560>
[12:45] <mup> PR snapd#9591 opened: gadget, gadget/install: move helpers to install package, refactor unit tests <Run nested> <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9591>
[12:45] <mborzecki> mvo: ^^
[13:34] <mborzecki> mvo: pushed some changes to #9577
[13:34] <mup> PR #9577: many: seal a fallback object to the recovery boot chain <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9577>
[13:57] <mvo> mborzecki: \o/ thank you
[14:38] <ijohnson> mvo: I also think we need https://github.com/snapcore/snapd/pull/9541 for 2.48, but we are still blocked on moving forward with that :-/
[14:38] <mup> PR #9541: osutil/disks: re-implement partition searching for disk w/ non-adjacent parts <Bug> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9541>
[14:39] <mvo> ijohnson: let's raise it again today
[14:39] <ijohnson> sounds good
[14:39]  * mvo puts it on the meeting agenda
[15:09]  * cachio lunch
[15:14] <mup> PR snapcraft#3340 closed: include SNAPCRAFT_STAGE in XDG_DATA_DIRS, needed to find Gir files built by other parts <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3340>
[15:15] <mup> Issue core20#94 opened: fix pi4 names for wlan0 and eth0 <Created by xnox> <https://github.com/snapcore/core20/issues/94>
[15:47] <mborzecki> need to drive the kids a bit
[15:58] <ijohnson> mvo: submitted review for 9577
[15:59] <mvo> ijohnson: thanks!
[15:59] <ijohnson> np
[15:59] <ijohnson> I will work on my followup to use that logic in snap-bootstrap today as we discussed
[16:02] <mvo> ta
[16:15] <pstolowski> quick errand, bbiab
[16:55] <mvo> cachio: I see failures like: "2020-11-02 16:00:35 Cannot allocate google-nested:ubuntu-18.04-64: cannot find any Google image matching "ubuntu-1804-64-virt-enabled" on project "computeengine" or "ubuntu-os-cloud"" in pr 9591, is there some gce issue?
[16:55] <mup> PR #9591: gadget, gadget/install: move helpers to install package, refactor unit tests <Run nested> <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9591>
[16:55] <ijohnson> mvo: cachio I think the issue is that there are too many images in our gce project, usually cachio just goes in and clears out some old images and it works again
[16:55] <cachio> mvo, let me cehck, I think I need to clean up
[16:56] <mvo> ijohnson: oh, right :(
[16:56] <ijohnson> because gce api is silly and still doesn't know how to return more than X images if there are more than X images in the project
[16:57] <cachio> ijohnson, well, they have pagination to support taht
[16:57] <cachio> but spread does not support pagination
[16:58] <mvo> ijohnson: I noticed two small issues around 9577 https://github.com/snapcore/snapd/pull/9577#discussion_r516113171 and https://github.com/snapcore/snapd/pull/9577#discussion_r516062913 otherwise this is good to go
[16:58] <mup> PR #9577: many: seal a fallback object to the recovery boot chain <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9577>
[16:58] <ijohnson> ah I see
[16:58] <ijohnson> mvo: looking now
[16:58] <mvo> ijohnson: \o/
[16:58] <mvo> ijohnson: spread> there are two draft PRs for spread to support pagination but both not quite get it right :/
[16:59] <ijohnson> ah I see
[16:59] <ijohnson> I thought this was gce's fault
[17:00] <cachio> mvo, do you want to re-trigger
[17:00] <cachio> mvo, already cleaned up
[17:01] <ijohnson> mvo: re 9577, do you mean in `TestMakeBootable20RunModeSealKeyErr` that ResealKeys (or SealKeys? I forget which one) is never actually called?
[17:01] <pstolowski> re
[17:06] <mvo> ijohnson: sorry, I mean in https://github.com/snapcore/snapd/pull/9577#discussion_r516113171 that there is no check like "c.Assert(sealKeysCalls, Equals, 2)" (or 1)
[17:06] <mup> PR #9577: many: seal a fallback object to the recovery boot chain <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9577>
[17:06] <ijohnson> mvo: ah yes you are right that is true
[17:06] <ijohnson> that is less of an issue than I thought you were trying to say :-)
[17:06] <mvo> ijohnson: it also already fails after the first call with an error so it will never be true in the switch
[17:07] <mvo> ijohnson: it also means we don't actually test the error transmission from the second call :)
[17:07] <mvo> ijohnson: it's probably not much of an issue, I agreee
[17:12]  * mvo gets dinner
[17:39] <timothy> hi zyga, is confinement broken on Fedora 33?
[17:40] <timothy> https://paste.centos.org/view/e5b46b5b