[05:15] <JonOomph> Hi! I noticed a bug on Ubuntu 16.10 with the libunittest++ package, which is breaking my launchpad build recipe. What is the best way to report this bug? Thx!
[05:15] <JonOomph> It's throwing lots of errors when attempting to link against libunittest++, such as (...relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC)
[05:16] <JonOomph> I only get this error on Ubuntu 16.10 build servers... it's very strange =)


[00:33] <mjflick> hi, i compiled bzr but i'm getting the following error when running it, "bzrlib._static_tuple_c.StaticTuple is not a type object"
[00:33] <mjflick> any ideas what's broken here?
[00:33] <lifeless> what python ?
[00:34] <mjflick> 2.5.2
[00:36] <poolie> kind of sounds like something's out of date with your python version
[00:36] <mjflick> great
[01:01] <spiv> Hi folks.
[01:27] <poolie> hi there spiv
[02:29] <poolie> lifeless, http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
[02:59] <echo-area> spiv, vila: I'm sorry I was busy doing other things these days so I didn't follow up spiv's bug report and didn't work on the document improvement of types of conflicts yet.  I'm still busy now, but I'll return to this later.  Apologize.
[03:59] <AfC> Is there no way to engineer out the "updating git map" step? It's going to take half an hour!
[04:02] <AfC> then "fatal: The remote end hung up unexpectedly"
[04:02] <poolie> :/
[04:02] <AfC> then, we start again at 0/19738
[04:02] <poolie> jelmer would know best, and he's likely asleep?
[04:02] <AfC> bloody hell
[04:02] <poolie> file a bug?
[04:02] <AfC> yeah
[04:02] <AfC> poolie: I guess I've kinda got tired of hassling Jelmer with bugs about bzr-git
[04:03] <mwhudson> i bet you haven't done it nearly as much as me
[04:03] <AfC> I never seem to be able to get it to work :(
[04:03] <poolie> i don't think he feels hassledh
[04:03] <poolie> and they do seem to get closed
[04:05] <AfC> poolie: filed, https://bugs.launchpad.net/bzr/+bug/753155
[04:08] <poolie> thanks
[06:13] <poolie> ok, SRUs here i come
[07:15] <poolie> OK, sru for bug 707075 proposed; let's see
[07:17] <lifeless> thats no good
[07:18] <lifeless> 2.5 seconds for me
[07:18] <lifeless> 177 queries though
[07:18] <lifeless> which makes me sad
[07:55] <vila> lifeless: 197 queries/external actions issued in 4.01 seconds here
[07:55] <vila> hi all !
[07:56] <vila> poolie: 2.1.4 is planned for next week, are you ok to wait a bit and use bug #707075 (come one ubot5, try better) to drive the 2.1.4 SRU ?
[07:56] <vila> good bot
[07:57] <lifeless> vila: thats interesting, I wonder why
[07:57] <vila> lifeless: 177 vs 197 you mean ? I was about to ask
[07:58] <lifeless> possibly there is a memcache fragment in there we missed
[07:58] <lifeless> but it should be disabled on BugTask:+index
[08:10]  * spiv steps AFK.
[08:10] <spiv> Back in a bit.
[08:12]  * vila scratches head
[08:13] <vila> poolie: how can I check that bzr has been uploaded to maverick-proposed ? It doesn't show up in synaptic...
[08:16] <lifeless> vila: become an ubuntu archive-admin
[08:16] <lifeless> vila: you might be able to see it in the maverick +queue page
[08:17] <vila> lifeless: the intent is to test it, I hope testing is open to non-admin people
[08:17] <lifeless> once its accepted into -proposed, yes
[08:17] <vila> oh, ok, that's probably the issue then
[08:20] <maxb> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text=bzr
[08:20] <maxb> vila: ^
[08:21] <vila> maxb: you rock ;)
[08:22] <vila> >-/ http://launchpadlibrarian.net/68515880/bzr_2.2.1-0ubuntu1_2.2.4-0ubuntu1.diff.gz mentions 2.2.2-dev in the generated C files
[08:24] <vila> may be the generated content is correct but if it has been generated there but this seems really wrong
[08:25] <vila> it should be 2.2.3-dev according to my local workflow
[08:25] <vila> err, no, 2.2.4-dev of course
[08:27] <vila> ok, false alarm
[08:28] <vila> it's a local glitch, I rely on make there *but* rename the directories after releases, so the path mentioned is the one that was current the last time the file has been generated
[08:29] <vila> I should probably add 'make clean; make' somewhere to avoid this
[08:30] <vila> on the other hand, full paths should be used only when building locally for debug purposes, relative paths should be used otherwise,
[08:31] <vila> especially for releases so that the above diff will stop containing the spurious comment changes
[08:33] <vila> I thought we had a bug for that but all I can find is bug #336933 which is only tangentially related
[08:38] <maxb> vila: I would like that. I suppose we need to either fix pyrexc or apply sed
[08:41] <vila> maxb: yup, I vaguely remember looking at that loong ago but don't remember ever finding a solution (didn't try sed though)
[08:41] <vila> but injecting sed between generation and compilation in build_extension may be tricky
[08:41] <fullermd> I recall doing a bunch of sed'ery in my (unsuccessful) attempt to figure out why they were blowing up a couple years back.
[08:43] <vila> and Cython may proceed differently, but anyway, it may be worth another try
[08:43] <fullermd> Last I checked, cython just flat didn't work, so that's easy to ignore  ;)
[08:43] <vila> hehe
[08:59] <poolie> hi spiv, vila, jam, jelmer
[08:59] <jelmer> hey poolie
[08:59] <vila> poolie: hey
[09:00] <poolie> hi there
[09:00] <poolie> iirc we're going to a have a standup call now?
[09:01] <spiv> poolie: yes
[09:02] <jam> hi poolie, what method?
[09:03]  * spiv is on mumble
[09:03] <poolie> mumble?
[09:04] <poolie> it apparently wants to be reinitialized for natty
[09:04] <jam> apparently we upset vila
[09:04] <poolie> :)
[09:19] <vila> poolie, jam, jelmer, spiv : Gee, I lack caffeine: lp says 2011-*05*-12 and that's right unless someone insists about releasing 2.1.4 sooner, next month seems fine as far as SRUs are concerned
[09:21] <poolie> hi jelmer?
[09:21] <jam> vila: not a whole lot of stuff in the 2.1 series that I can see *needs* release
[09:22] <jam> Though it is nice if we are going to do a backport to actually get it out to users.
[09:22] <vila> jam: sure, but what we want is to get 2.1 updated for lucid which is LTS, so it's more about having the SRUs running (and we need to SRU 2.2 *before* 2.1 AIUI)
[09:22] <poolie> still here?
[09:22] <jelmer> FFS
[09:22] <poolie> jelmer, that's nice
[09:22] <jam> jelmer: want to finish up in IRC
[09:22] <jam> we'll just talk about you behind your back
[09:22] <jelmer> yeah, that might be better, my mumble seems unreliable today
[09:22] <poolie> jelmer, you should send a mail about that great result
[09:22] <jelmer> jam: >-)
[09:23] <vila> jelmer: don't worry, I had to *reboot* myself ;)
[09:23] <jelmer> This week I'd like to work on finishing the bzr-svn/bzr-hg/bzr-git releases and getting them and a newer bzr deployed on LP
[09:23] <vila> \o/
[09:23] <jelmer> as well as getting the transport-segments patch finished
[09:24] <poolie> that sounds good
[09:24] <poolie> spiv's talking about getting the twisted failure patch and workaround done
[09:24] <poolie> i'll send minutes too
[09:25] <poolie> we could try using canonical asterisk conferencing next time
[09:25] <poolie> or skype
[09:25] <poolie> spiv: and the patch to upstream twisted?
[09:26] <poolie> oh, just briefly
[09:26] <poolie> because the kanban is working well i was thinking about changing what we do with bugs
[09:26] <poolie> specifically actually using fix committed/fix released to remind us to make a release
[09:27] <vila> meh, for bzr itself you mean ?
[09:27] <poolie> yes
[09:27] <vila> We stopped using fix committed to ease the RM work IIRC
[09:28] <jam> vila: and to avoid the "100 bug spam updates when a release is made"
[09:28] <vila> and I thought Fix committed was going to be deprecated anyway
[09:29] <vila> jam: hmm, yeah, *I* wouldn't mind that if I wasn't the RM as a reminder of which fixes are about to be released
[09:30] <jelmer> it should be possible to do a trivial script that marks all bugs for a milestone as fix released
[09:31] <vila> arf arf, headset delivered *just* after the online meeting, the irony :)
[09:31] <jelmer> vila: :)
[09:38] <vila> jelmer: right, truth is I'm mainly using the milestone pages to see which bugs are fixed by which release and that will still work if we use Fix Committed so I'm not violently *against* using it (I always liked the distinction between committed and released myself though I used it to distinguish between: there are a fix in *a* branch and the fix has landed in the official branch)
[09:39] <vila> but anyway, worth discussing on the list as poolie proposed
[11:54] <poolie> o/ spiv
[11:58] <jam> poolie: does feed-pqm notice that Branch A is approved but its prerequisite B is not?
[11:59] <poolie> no
[11:59] <jam> poolie: I thought so, but just checking
[12:00] <poolie> what do you think it should do?
[12:00] <poolie> arguably lp should warn you about this
[12:01] <jam> poolie: warn/not show it as submittable/ something
[12:02] <poolie> yes
[12:02] <jam> I'm reviewing Jelmer's stack, and the first I need to discuss a bit more, most of the follow ups are obviously ok
[12:02] <jam> but I don't want to mark them Approved, since it would want to be submitted
[12:02] <jam> poolie: speaking of which, I think you have 3-4 "approved but not landed" branches.
[12:03] <jelmer> jam: hi
[12:04] <jam> hey jelmer
[12:04] <jam> jelmer: questions are in https://code.launchpad.net/~jelmer/bzr/knitpackrepo/+merge/56383
[12:05] <poolie> it is not all that great at showing the whole stack
[12:06] <jam> poolie: I realize it is a little bit tricky, since prerequisite branches are off-to-the-side, since you don't set a prerequisite merge-proposal
[12:06] <jam> which is where the "is this merged" is generally tracked
[12:07] <askhl_> Hi.  I have a bzr repository with multiple branches and tags, and would like to transfer this whole structure to a project in Launchpad.  How should this be done?
[12:08] <jelmer> jam: ah, thanks
[12:08] <askhl_> (One could conceivable create series for the different tags and manually push each tag/branch as appropriate.  Is this the smartest way or is there a better way?)
[12:08] <jam> askhl_: generally you would create a new project on launchpad, then push up your primary development branch, mark it as such, then push up the rest
[12:08] <askhl_> conceivably*
[12:09] <askhl_> jam: so the rest of the branches/tags are simply pushed individually?
[12:09] <jam> askhl_: I'm not sure what you are doing with tags, but yes
[12:09] <jam> for the branches
[12:09] <askhl_> jam: the tags correspond to stable versions.  I guess they're sort of like series
[12:10] <askhl_> jam: thanks for the help
[12:12] <jam> askhl_: what are the branches then? My guess is you would just have a series branch that happens to have the individual release tags on it.
[12:12] <jam> I don't know if you need separate branches for each release tag.
[12:12] <jam> s/need/need or want/
[12:15] <spiv> jam: related bug I filed today: https://bugs.launchpad.net/launchpad/+bug/753185
[12:26] <askhl_> Say, we have this repository.  And we would like to push the branches in this repository to LP.  But when attempting to do so, it complains that "location is a repository".  Apparently the subdirectories are not quite branches that can be pushed.  How do we proceed?
[12:26] <spiv> askhl_: push the branches, not the repository.
[12:26]  * spiv -> dinner
[12:27] <askhl_> spiv: I'm in one of them (trunk) and running bzr push lp:<project>.  That's when it complains
[12:28] <askhl_> Strange.  The trunk is actually not reported to be a branch by bzr info, while the other branches are.  Maybe this is an error in svn2bzr (which has been used)?
[12:29] <askhl_> But we need trunk to be a branch (including revision history)...
[12:33] <vila> askhl_: directory has not the same meaning in bzr and svn, in bzr it's just a revision store, bzr deals with branches mainly
[12:33] <vila> askhl_: a branch can have multiple tags, each one associated with a specific revision
[12:34] <vila> askhl_: launchpad hosts only branches with some of them having aliases for convenience
[12:35] <vila> lp:bzr is a shortcut for the dev focus branch which is lp:~bzr-pqm/bzr/bzr.dev
[12:36] <vila> for project branches, the url syntax is lp:~<user>/<project>/<branch>
[12:36] <askhl_> vila: thanks
[12:37] <vila> so, if 'bzr push lp:<project>' fails, that's possibly because the dev focus is not correctly defined for <project>
[12:37] <askhl_> So right now the problem is that svn2bzr converted the trunk branch of svn to something which is not a branch in the bzr sense.  So we need to make a branch out of it (including entire revision history) and push it to LP.
[12:37] <askhl_> We managed to push one of the non-trunk svn tags (technically a branch) successfully, it's just that trunk itself is not a branch for some reason
[12:38] <vila> askhl_: well, you need a branch to start with, I'm pretty surprised that svn2bzr produced something that isn't one
[12:38] <vila> askhl_: if you do 'bzr info' in any directory, it should tell you what it thinks the directory contains
[12:39] <vila> askhl_: pastebin'ing the result may ease the dialog ;)
[12:39] <askhl_> vila: right, bzr info reports that it is a 'shared repository', whereas for the other branches it reports two lines, one stating that it is a shared repository (or part thereof), the other stating that it is a branch
[12:40] <vila> right, so a shared repository is a repository used my multiple branches (a repository can also be private to a branch)
[12:40] <fullermd> A 'branches' run may be helpful.
[12:40] <vila> so you did the first 'bzr info' at the repository level, the branches should be down the hierarchy starting there
[12:41] <vila> ha, of course, fullermd to the rescue ;)
[12:41] <vila> askhl_: try 'bzr branches' ^
[12:41] <fullermd> From the 'top level' of your conversion.
[12:42] <askhl_> Oh, there's the problem: svn2bzr has converted all the *subdirectories* of trunk into different branches
[12:42] <fullermd> jelmer: I haven't read your email yet, but just from the subject line I'm totally in favor of whatever it contains   :p
[12:42] <vila> askhl_: 'branches' is part of the bzrtools plugin (in case you got an Unknown command error)
[12:43] <askhl_> as revealed by svn branches
[12:43] <askhl_> That explains it then
[12:44] <askhl_> Thank you, vila  and fullermd
[12:45]  * fullermd goes back to lurking until vila almost solves the next problem, then jumps in to take the credit   8-}
[12:46] <vila> fullermd: for once I didn't start with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief which may have been an error ;)
[12:48] <vila> askhl_: I'm not that familiar with svn myself, but from the various discussions here, people use bzr-svn more than svn2bzr, you may want to have a look at it
[12:49] <fullermd> I should blow an afternoon sometime trying to see if bzr-svn can be sweet-talked into running over the BSD src repo, but I have a feeling I'd spend hours just trying to tell it the repo structure.
[12:49] <fullermd> Then more hours and several times my RAM waiting for it to figure out what to do...
[12:50] <vila> askhl_: also, launchpad can import from svn so you may wan to look there too, maybe it can do the work for you ;)
[12:50] <askhl_> vila: it seems that bzr-svn is useful for using bzr as a frontend to svn repos, whereas we are converting an svn repo to bzr permanently.  I think we'll figure it out now with bzr2svn, so things should be fine! (until we get more questions of course .))
[12:50] <jelmer> askhl_: bzr-svn has a "bzr svn-import" command that has behaviour similar to svn2bzr
[12:51] <jelmer> fullermd: how weird is the repository layout?
[12:51] <vila> jelmer: it uses CVS :-D
[12:52] <fullermd> Fairly.  Ignoring stuff that's unnecessary for a generally-good-coverage import, there's still a fair spread of stuff to get...
[12:53] <fullermd> vila: ports is still CVS.  The master for src is in svn.
[12:53] <jelmer> jam: whoa, 77 entries in your sys.path?
[12:53] <fullermd> I think about trying ports again sometimes too, but I sober up real quick  :p
[12:53] <vila> :)
[12:53] <jelmer> jam: I heard people complain about a single additional entry in sys.path on Ubuntu
[12:54] <jam> jelmer: easy_install defaults to putting every installed software into a custom location
[12:54] <jam> so that you can have 2.4 and 2.5 installed, but pick which one is active
[12:54] <jam> however, Launchpadlib has *huge* dependencies
[12:55] <jam> (well, a very large dependency stack)
[12:55] <jam> which I don't want to manually install, but obviously has some severe negatives w/ easy_install
[12:55] <jelmer> jam: hey, it's nothing compared to Launchpad's dependency stack :-P
[12:55] <jam> jelmer: sure, but you can't easy_install Launchpad on Windows, either
[12:57] <jelmer> that's probably for the best :)
[13:22] <jelmer> whoa, we had *9* knit pack repository formats?
[13:27] <maxb> I count 7 _released_ ones
[13:42] <vila> jelmer: part of why bialix was talking about a zoo format :-}
[13:42] <vila> err, format zoo
[13:44] <jelmer> yeah
[15:11] <dije> Doing a checkout to my home directory from a branch at ~/bzr_scm/dot, I get the following error:
[15:11] <dije> bzr: ERROR: Failed to rename /Users/phil/Library/Preferences to /Users/phil/.bzr/checkout/limbo/new-159/Preferences: [Errno 13] Permission denied
[15:11] <dije> How can I remediate this?
[15:13] <dije> (On Mac OS X 10.5.8, Titanium PowerBook G4)
[15:14] <dije> Anybody here?
[15:15] <jelmer> dije: hi
[15:15] <dije> jelmer: hi
[15:15] <jelmer> dije: I'm here, but I'm not entirely sure what's going on there
[15:16] <dije> Nothing shows on a google search
[15:16] <jelmer> brb
[16:54] <achiang> hello, what is the preferred GUI bzr tool?
[16:54] <achiang> i guess it's just bzr-gtk?
[16:55] <james_w> qbzr is actually better these days I think
[16:56] <james_w> bzr-explorer provides a nice intergrated environment if you prefer that to the "bunch of tools" approach
[16:59] <achiang> james_w: ok
[16:59] <achiang> james_w: i need to do a rather complex operation
[17:00] <achiang> trunk is A, merged in branch B; then had to revert B (bzr merge . --revision -2..-3); then A had more changes; then I added B back in; more changes, now i need to revert B again. :-/
[17:15] <achiang> james_w: thanks for the tip on bzr explorer. i'm stumbling my way through this morass of my own making
[18:07] <LeoNerd> ARGH FSCKING REVERT
[18:07] <LeoNerd> "bzr revert" after shelve/unshelve thought it was safe to blow away my changes. It wasn't. Any chance I can get them back, or is that gone gone?
[18:08] <james_w> LeoNerd, there will be .~N~ files for each changed file
[18:09] <james_w> where N is a number >=1, use the last for each
[18:09] <LeoNerd> No.. there aren't.
[18:09] <james_w> you used --no-backup?
[18:09] <LeoNerd> Normally there are.. not immediately after shelve/unshelve
[18:09] <LeoNerd> revert believes it's reverting after a merge, so doesn't bother to keep them
[18:09] <james_w> erk
[18:10] <LeoNerd> Fortunately I happen to have the diffs in my xterm scrollback buffer, so I can reapply. Problem is, it also reverted adding a new file, for which I dno't have the original content
[18:14] <james_w> would you file a bug on the unshelve+revert thing
[18:14] <james_w> ?
[18:14] <james_w> once you are finished unpicking the fallout
[18:14] <LeoNerd> I thought there already was one
[18:14] <james_w> oh, ok
[18:14] <LeoNerd> Atleast, I've known about it for like a year now.. seen mention of it. I was presuming debian was just behind the times in not giving me a fixed one
[18:14] <LeoNerd> Was wondering if anyone knows if the 'shelve'd content is stored somewhere after unshelve, that I could get at still
[18:15] <james_w> I don't know that it is
[19:32] <philsf> I have a local versioned dir , and I want to set it up in a server. I didn't find in the site docs what is needed on the server side to use it remotely. Is a user account and ssh access enough?
[19:47] <maxb> philsf: Yes. You can then simply use bzr+ssh://host/path/to/dir URLs in bzr commands
[20:29] <philsf> maxb, so I can just rsync the whole dir, including .bzr/* to the destination?
[20:30] <maxb> It would work, though it's not the nicest way
[20:30] <maxb> Is Bazaar installed on the serve?
[20:30] <maxb> *server
[20:30] <philsf> not yet
[20:31] <maxb> You can use Bazaar using sftp://host/path/to/dir URLs without having bzr installed remotely, though the performance will not be as good as bzr+ssh
[20:34] <philsf> what's the polite way to transfer the whole branch, instead of rsyncing the whole thing?
[20:37] <maxb> bzr push remote-url-where-you-want-it
[20:39] <philsf> forgive my ignorance, what's the difference?
[20:40]  * jelmer waves
[20:40] <maxb> Not a great deal, but: 1) pushing doesn't create a working tree on the server, and 2) your local branch remembers where you pushed it to for convenience when you want to push updates
[21:04] <philsf> thanks, bye
[23:33] <AfC> How hard would it be to have Bazaar insert a \n instead of clearing the terminal line when it's printing status messages?
[23:34] <jelmer> AfC: with status messages, do you mean progress indication messages?
[23:34] <AfC> jelmer: yes?
[23:35] <AfC> The stuff that spews out on teminal for 10ms then gets erased whenever you do anything
[23:36] <AfC> jelmer: [are those "progress indication messages"?]
[23:37] <jelmer> I'm not sure which messages you mean, I haven't seen any messages from bzr get erased when I type stuff.
[23:37] <jelmer> AfC: can you give an example of the contents of one of those messages?
[23:37] <AfC> jelmer: "...Inserting stream..."
[23:38] <jelmer> ah, those are indeed the progress indication messages
[23:38] <jelmer> adding a newline there will mean *a lot* of output though
[23:39] <jelmer> it's not a generic status message, it just tells you what bzr is working on; if something completes quickly enough it's not shown
[23:39] <AfC> I'd obviously want to nuance it that things that are just updating the 0/100 wouldn't trigger the \n, just a changed message
[23:40] <jelmer> AfC: I think you're just asking for more high-level output on what's actually been completed?
[23:40] <AfC> jelmer: I want to evaluate (subjectively) the impact of seeing more output from bzr when running things. We all know git "seems" faster, and I want to see whether that has to do with it looking like it's "doing more" per unit time / per unit message
[23:41] <AfC> jelmer: [but as an aside, having no idea what any of Bazaar's messages actually are makes it harder for all of us user types to communicate with the bzr hackers about "why it is doing ____"]
[23:41] <AfC> jelmer: [so I'd like to start seeing 'em]
[23:42] <jelmer> AfC: the related code is in bzrlib/uyi/text.py, see show_progress()
[23:42] <jelmer> s/uyi/ui/
[23:43] <AfC> Eeeek!
[23:44] <AfC> http://bazaar-vcs.org/bzr/bzr.dev/ is permanently redirected to http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
[23:44] <AfC> bzr: ERROR: Cannot lock LockDir(http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[23:44] <AfC> what the heck/
[23:44] <AfC> from
[23:44] <AfC> $ bzr pull
[23:44] <AfC> oh... it's a format 1.14 branch. Is bzr.dev 2a yet?
[23:44] <AfC> still, that's some error message
[23:45] <jelmer> yeah, I'm pretty sure bzr.dev is 2a
[23:45] <jelmer> AfC: is this a checkout perhaps?
[23:45] <AfC> jelmer: yeah, I assume so
[23:45] <AfC> jelmer: I always do "read-only" checkouts (mirrors?) of upstream.
[23:45] <AfC> Shouldn't I?
[23:46] <jelmer> AfC: you can, but you should in that case use "bzr up" to update
[23:46] <jelmer> AfC: you were trying to pull new changes into your local branch and its master branch, to which you have no write access
[23:46] <jelmer> (the error message about the master branch being readonly is more than weird, I admit)
[23:46] <AfC> jelmer: update vs pull sometimes being one thing and sometimes being another is probably THE thing I hate the most about bzr, :(
[23:47] <AfC> In a branch, regardless of what type it is, it should be pull, or update. They shouldn't be the same sometimes.
[23:47] <jelmer> AfC: hopefully it's something that will be addressed in the 3.0 UI revamp
[23:47] <AfC> I hope we can clean this up in 3.0
[23:47] <AfC> jelmer: tag you're it
[23:47] <jelmer> AfC: well, technically they are different things.. but I won't go there, I get your point.
[23:48] <AfC> jelmer: I know they're different things. That's why I'd rather they be 2 commands that you have to do
[23:48] <AfC> jelmer: the whole thing is founded in the idea that "people shouldn't have to do two steps" but look at the confusion that resulted.
[23:49] <AfC> jelmer: if pull and update are different and have side effects, then they're different.
[23:49] <AfC> {shrug}
[23:50] <AfC> Meanwhile, starting again,
[23:50] <AfC> $ bzr branch http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
[23:50] <AfC> can't give me an estimate of total size to be transfered? :(


[06:56] <dholbach> good morning
[07:03] <svij> hey dholbach dpm
[07:03] <svij> seems that both of you are back from holidays
[07:03] <dpm> morning svij
[07:05] <dholbach> hey svij
[07:05] <dholbach> hey dpm
[07:05] <dholbach> :)
[07:05] <dholbach> I'm going to be buried in email for a while though and it's my patch pilot day, so don't expect too much attention in the next hours ;-)
[07:07] <svij> so you're actually pretending that you work?  :D
[07:12] <dholbach> true, but even more cheeky :-P
[07:13] <dholbach> I take it you're in a good mood today? :)
[07:15] <svij> sure ;)
[07:23] <Kilos> morning all
[07:23] <Kilos> hi dholbach
[07:24] <dholbach> hey Kilos
[07:41] <svij> hey Kilos
[07:56] <elacheche> Morning LoCos!
[07:56] <Kilos> o/
[15:55] <Hebert> e ae galera buntu
[15:56] <Hebert> uma informação --- qual a versão mais recente do ubuntu
[15:56] <Hebert> ?
[15:59] <CrazyLemon> !br
[16:01] <Hebert> ok thanks
[16:04] <dholbach> hey nhaines, jose - how are things? how is UFCS coming on? does anything still need to be organised?
[17:48] <WaVeR> ping elacheche


[07:03] <ePierre> Hi!
[07:04] <elfy> hi ePierre
[07:10] <jibel> Good morning
[07:19] <elfy> morning jibel - a day for resting I think for those lucky enough to be at home :)
[07:23] <jibel> elfy, morning. Right, it'll be a quiet day, essentially triaging incoming bugs from people upgrading to 14.04. And if the sun is still there this afternoon finish early and go to the beach :)
[07:25] <ePierre> jibel = JB Lallement ?
[07:25] <ePierre> (stupid question, I just wanna make sure ahah)
[07:26] <jibel> ePierre, yes
[07:26] <ePierre> cool! hi then :) and thanks for your hard work triaging bugs in launchpad
[07:27] <ePierre> that's an herculean task!
[07:28] <jibel> thank you
[07:29] <elfy> jibel: yep :) good luck with that :p
[07:30] <jibel> actually, there is are very few real upgrade issues. The most common are people with xorg-edgers PPA installed, and people with cinnamon which is broken in Trusty and apparently the maintainer doesn't care
[07:31] <ePierre> and in that case, how do you deal with this kind of issues?
[07:32] <ePierre> I'm actually curious, because I know Ubuntu depends a lot on upstream projects, and sometimes upstream doesn't update or support a new release, or they have another goal than what the current users are expecting, so end users file bugs that are actually not...
[07:41] <jibel> ePierre, if a user is blocked because he installed third party packages, I usually advise how to revert to official Ubuntu packages. If it's a broken package, then it is the responsibility of the maintainer of the package to fix the problem. So I identify the problem, mark it triaged set importance and that's it. Overall I'm making sure that the core of the system is in good shape and no important
[07:41] <jibel> issue felt between the cracks
[07:42] <elfy> jibel: I've not seen any major issues with us - yet
[08:12] <DanChapman> good morning
[08:15] <elfy> hi DanChapman
[08:19] <DanChapman> hey elfy, hows it going?
[08:20] <elfy> not as good as it should be - I should be in Brighton with friends - the weekend went pear-shaped :(
[08:24] <ePierre> what does "pear-shaped" mean in that case? :)
[08:24] <elfy> wrong ... I'm still at home ;)
[08:25] <ePierre> jibel, thanks for the clarification! and how is upstream informed about bugs relative to one of their project? Say a bug is filed for ibus, is the ibus dev team aware of that? Or is there an official ibus packager/maintainer for Ubuntu whoś in touch with the dev team?
[08:27] <elfy> ePierre: check out bug 1284635
[08:28] <elfy> that actually is an ibus bug - Aron Xu works on the Ubuntu Desktop Team - and is upstream afaik for ibus
[08:42] <ePierre> oh cool, Aaron is in Taiwan :)
[08:43] <ePierre> ah no, he's in China, but part of the Taiwan loco team
[08:46] <ePierre> elfy, ok but in the case of this bug, it's Aron responsibility to check if the problem comes from Ubuntu or from iBus, and if it's the latter case, then he has to get in touch with ibus dev team/file a bug in their bugtracker?
[19:11] <Letozaf_> elopio, hello
[19:42] <balloons> aloha Letozaf_
[19:42] <Letozaf_> hello balloons
[19:42] <Letozaf_> balloons, howzit ?
[19:43] <balloons> not too bad..
[19:43] <balloons> trusty is out, cleanup ensues
[19:44] <Letozaf_> balloons, :)
[19:46] <balloons> what are you up to Letozaf_ ?
[19:47] <Letozaf_> balloons, I am looking at reminders app test wrote by elopio
[19:47] <balloons> Letozaf_, ohh excellent
[19:47] <Letozaf_> Letozaf_, have some questions to ask him
[19:48] <Letozaf_> balloons, hope he will be around some time
[19:48] <balloons> Letozaf_, next week things should go back to normal with more folks around
[19:48] <balloons> pretty dead atm.. :-)
[19:49] <Letozaf_> balloons, yes Easter holidays :)


[08:41] <doko> vorlon: the hello autopkg test was meant to replace the libreoffice autopkg test trigger
[09:28] <vorlon> doko: ok, and it's buggy; do you want to fix it?
[09:36] <doko> vorlon: so the correct fix would be to detect the 77 exit status, and then fail in the end with this?
[09:36] <doko> and likely allowing stderr
[11:13] -queuebot:#ubuntu-release- Unapproved: chromium-browser (cosmic-proposed/universe) [71.0.3578.98-0ubuntu<IP_ADDRESS> => 72.0.3626.119-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[12:04] -queuebot:#ubuntu-release- Unapproved: rejected libunistring [source] (bionic-proposed) [0.9.10-1ubuntu0.1]
[12:06] -queuebot:#ubuntu-release- Unapproved: accepted network-manager-fortisslvpn [source] (bionic-proposed) [1.2.8-1ubuntu1]
[12:09] <Riddell> libxcb update uploaded again should anyone be doing New/SRU queue review https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1777994
[12:11] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.10]
[12:31] <cpaelzer> thanks
[13:11] <Odd_Bloke> Still looking for a quick hints merge on https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 if anyone has a minute.
[13:12] <Odd_Bloke> (The current version of Vagrant in the release pocket doesn't work with the Virtualbox in the release pocket, which is why I'm keen to get this migrated.)
[13:41] -queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.1]
[13:44] <cpaelzer> sil2100: hi thanks for releasing libpam-mount for bug 1804408 on cosmic
[13:44] <cpaelzer> sil2100: I wonder where the bionic variant of it got lost thou
[13:44] <cpaelzer> I uploaded on the same day, and it was blocked for the 18.04.2 semi-freeze
[13:45] <cpaelzer> but the release of the SUR for cosmic made me re-check and I can't see it in B-proposed nor b-unapproved
[13:45] <cpaelzer> sil2100: I wonder if from the SRU-masters POV you have an idea what happened
[13:46] <cpaelzer> I see no accept/denial nor anything similar
[13:46] <cpaelzer> I'll also double check that I uploaded it back then ....
[13:47] <cpaelzer> Feb  7 17:15 libpam-mount_2.16-3ubuntu0.1_source.ubuntu.upload
[13:47] <cpaelzer> yeah sucessfully uploaded at the same time as the cosmic version (2.16-5ubuntu0.1)
[13:48] <sil2100> cpaelzer: let me finish one review and try to investigate
[13:48] <cpaelzer> sure
[13:49] <cpaelzer> In case "just re-upload it" is an option I can easily do so, but usually if things get lost it is worth to check why :-)
[13:50] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.1]
[13:51] <sil2100> cpaelzer: oh, I see it in the Unapproved queue
[13:51] <sil2100> cpaelzer: I'll review it now
[13:51] <cpaelzer> sil2100: stop the "investigation" it is just that the bionic queue is 42 entries long, I'm at #32 and the default view on LP limits to 30 results
[13:51] <sil2100> Probably you didn't see it as it was on the second page ;)
[13:51] <sil2100> Yeah
[13:55] -queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [source] (bionic-proposed) [2.16-3ubuntu0.1]
[13:56] <sil2100> cpaelzer: done ^
[13:57] <cpaelzer> Thank you sil2100
[14:58] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1012.12~18.04.1] (kernel)
[15:02] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1012.12~18.04.1]
[15:03] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1012.12] (kernel)
[15:04] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1012.12]
[15:04] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1040.44] (kernel)
[15:12] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1040.44]
[16:36] -queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 => 2.7.15-4ubuntu4~18.04] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.0] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1] (openstack, ubuntu-server) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 => 3.7.2-1~18.04.1] (no packageset) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 => 2.0.9-0ubuntu1] (no packageset) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 => 1.84-1ubuntu0.1] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 => 1.0.1-1ubuntu1.1] (no packageset) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 => 2.1.4-1ubuntu1.3] (core) (sync)
[16:36] -queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
[16:50] <juliank> Laney, sil2100, vorlon Should we add any other fields to the autopkgtest journals? I'm not sure what we could be interested in. We could tag failing result logs by exit code, for example
[16:51] <juliank> Then we could do queries by exit code
[16:51] <juliank> but it would only show results, and miss the head of the run
[16:52] <juliank> I feel like we should have a common word we can all configure highlights on, so people can ping about autopkgtest stuff
[16:54] <infinity> juliank: Jabberwocky.
[16:55] <juliank> infinity: i don't like
[16:55] <juliank> I thought @adt but that's too obscure
[16:55] <xnox> argggg
[16:56] <xnox> g
[16:56] <xnox> used wrong from email again
[16:57] <xnox> oh, i am subscribed
[16:57] <infinity> juliank: https://www.youtube.com/watch?v=spyJ5yxTfas
[16:57] <xnox> ah
[16:57] <xnox> The reason it is being held:
[16:57] <xnox>     Too many recipients to the message
[16:57] <xnox> infinity, if you please moderate that email?! =)
[16:57] <infinity> xnox: ... to?
[16:58] <Laney> juliank: cloud region would be good
[16:58] <xnox> infinity,     https://lists.ubuntu.com/mailman/confirm/ubuntu-release/3cbf130433d6a020d9b281155971e932f36bcb74 ubuntu-release mailing list
[16:58] <xnox> infinity, but that's my post/no-post url....
[16:58] <infinity> xnox: The name of the list would have been enough. :P
[16:58] <xnox> ah
[16:58]  * xnox is mailman failure
[16:59]  * Laney tries... to... resist...
[16:59] <Laney> s/mailman //
[16:59] <Laney> sorry :(
[16:59] <juliank> Laney: OK, but we can query for that by limiting on the @<cloud>*.service already, so it doesn ot at
[17:00] <juliank> but that applies to arch too, so...
[17:01] <juliank> We could also differentiate between upstream tests and ubuntu and huge queue tests
[17:01] <juliank> I have no idea how much space this eats
[17:01] <juliank> Gotta read up on the journal format :)
[17:02] <xnox> infinity, also, what did i just watch?!!!!!!!
[17:02] <infinity> xnox: Jabberwocky!  You don't know what it is?
[17:03] <Laney> juliank: the journal is supposed to auto prune anyway, so I wouldn't worry about that
[17:04] <Laney> although it did stop doing that and fill up the disk the other day ...
[17:04] <juliank> +1
[17:04] <xnox> infinity, no idea
[17:04] <xnox> https://www.youtube.com/watch?v=WQVFe8TbFi4 -> this is now on autoplay
[17:04] <infinity> xnox: (That's the joke)
[17:05] <xnox> i'm confused what the show is
[17:05] <Laney> it might be nice to make the other scripts log to the journal too, with some nice metadata
[17:05] <infinity> The show is Better off Ted.  Some of the better TV ever written.
[17:05] <Laney> the maintenance job / the daily image building / ...
[17:05] <xnox> wait is that the 6 parallel / perpendicular lines, with weird colors?!
[17:05] <xnox> ah
[17:05] <Laney> interesting interleaving of conversations, here
[17:06] <xnox> it's unrelated, but added this on autoplay https://www.youtube.com/watch?v=BKorP55Aqvg
[17:07] <juliank> Laney: FWIW, I just removed the attached card you wanted access to. It was the card for scheduling our session
[17:07] <Laney> ok
[17:07] <juliank> it was only supposed to link from "schedule session" -> "https://trello.com/c/wvz1NPzD/26-adding-a-second-cloud-worker" but trello said it would recommended bidirectional ...
[17:40] <vorlon> doko: if it's exit status 77, we shouldn't fail, based on the definition of the upstream test
[17:41] <vorlon> doko: autopkgtest doesn't honor exit status 77, that's (apparently?) an automake thing
[19:03] <tsimonq2> vorlon: css> ack
[20:51] <ginggs> vorlon, doko: any ideas about pandas test regression on ppc64el? ../../../usr/lib/python2.7/dist-packages/pandas/tests/series/test_analytics.py::TestSeriesAnalytics::test_sum_overflow[True] Killed
[20:51] <ginggs> same test passes during the build
[21:04] <mwhudson> ginggs: oom?
[21:06] <ginggs> mwhudson: could be, thanks - how can i prove, or avoid that?
[21:07] <mwhudson> ginggs: no idea to be honest
[21:07] <mwhudson> ginggs: you can mark a package as "big" which means its tests run in a vm with more ram
[21:16] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
[21:16] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
[21:43] -queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (cosmic-proposed/main) [3.30.2-0ubuntu1 => <IP_ADDRESS>-0ubuntu1] (ubuntu-desktop)
[23:41] <tumbleweed> vorlon: looks like reverse-depends has been broken since the 9th. Looking at it...
[23:47] <tsimonq2> Laney: Looking at bug 1654761 again, new code up at https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/363643
[23:48] <tsimonq2> I think I have a much better grasp of the situation this time around (and my programming skills have improved :P)


[21:43] <JackFrost> I have http://paste.openstack.org/show/UGto7TYyd7A1roF5hn7i/ for xscreensaver, unless someone really thinks 60_sequential_glslideshow.patch is worth keeping (and if so, then forward it upstream already)