[06:00] <blr> wgrant: one problem (possibly not the only problem), is the the semantics of dirty headers are still weird (I could have implemented this better in bzrlib)... each group of dirty headers is only associated with the first patch, where really all of the following patches before a blankline should be associated.
[06:03] <blr> so currently if the diff looks like [dirty, dirty, patch, patch, patch, dirty, ...etc] we get [{dirty: foo, patch: <patch0>}, patch1, patch2]
[06:04] <blr> where really we should probably have [{dirty: foo, patches: [<patch0>, <patch1>, etc]}]
[06:06] <blr> bzrlib of course only sees dirty lines for the first patch it parses
[06:07] <blr> I think I do have an interim fix though which should demangle the mail diffs.
[06:12] <wgrant> blr: Why wouldn't it be [{dirty: foo, patch: patch0}, patch1, patch2, {dirty: bar, patch: patch3}]?
[06:13] <blr> wgrant: if the first 3 patches are from the same file?
[06:13] <wgrant> blr: Three patches can't be from the same file, but the hunks could be.
[06:17] <blr> hmm, sorry you're correct, I think the diff_text in the test is actually in an impossible state.
[06:18] <blr> wgrant: would you mind looking at test_codereviewcomment.py
[06:18] <blr> presumably the 'baz' and 'foo' patch headers would always have a dirty header
[06:22] <blr> and in practice would always be preceded with a newline
[06:23] <wgrant> blr: In which branch?
[06:23] <wgrant> I don't see a baz in test_codereviewcomment in devel.
[06:28] <blr> wgrant: hmm second patch in the diff_text
[06:32] <blr> wgrant: http://pastebin.ubuntu.com/11840023/
[06:33] <blr> wgrant: that first dirty header has always been in the sample data, but presumably it is incorrect?
[06:33] <wgrant> blr: What's wrong with it?
[06:34] <blr> ah they're supposed to represent directories
[06:35] <blr> in which case it should be bar.py and baz and foo should have their own dirty headers?
[06:37] <blr> I don't think we generate diffs with patches in succession like that without headers.
[06:39] <wgrant> That diff looks believable to me.
[06:39] <wgrant> A directory was added, which is only indicated by a [06:40] <wgrant> In our parsing, that will appear as a dirty line on the patch that follows it.
[06:40] <wgrant> Now, technically it has no relationship with that patch, but it doesn't particularly matter if we associate them.
[06:42] <blr> wgrant: in what case would the second and third patches not have dirty headers (or a blankline)?
[06:44] <wgrant> blr: I don't know if we'd generate them like that (though git might), but there's no reason we can't parse them AFAICS.
[06:45] <blr> wgrant: sure, we are parsing them like that now, it just didn't seem to align with reality
[06:45] <wgrant> blr: Parsing them like what?
[06:45] <blr> I've added another patch preceeded by a blankline and a new dirty header in this branch
[06:46] <wgrant> Ah, it was misinterpreting the blank line case?
[06:46] <blr> wgrant: I mean, we can parse a diff in that state.
[06:47] <blr> well, we didn't have test data with a blankline/new header prior to this, which accounts for some of the failings in the tests.
[06:48] <wgrant> Right.
[06:48] <blr> wgrant: just wanted to ascertain if there were circumstances where we might generate a diff like that.
[06:48] <wgrant> Yep, I understand now.
[06:48] <wgrant> git may, not sure.
[06:48] <wgrant> We should test the various cases.
[06:48] <blr> sorry my brain is a little fried after looking at this all day
[06:48] <wgrant> No gap, blank gap, dirty gap, dirty and blank gap.
[06:48] <wgrant> Oh I know the feeling,
[06:48] <blr> I'm probably not making much sense :)
[06:48] <blr> right
[06:49] <blr> wgrant: anyhow, I'm parsing elmo's big diff and it seems to be fine now
[06:50] <wgrant> blr: Great, small bzrlib fix?
[06:51] <blr> no, I think bzrlib is actually fine.. the problem there was a malformed hunk header in my test which made me erroneously think the problem was in bzr
[06:53] <blr> wgrant: our comment count includes the blanklines before dirty headers which bzrlib throws away
[06:57] <wgrant> blr: But if bzrlib throws them away then how can we know if they were there?
[06:57] <wgrant> (unless you do what Colin suggested, and keep track of which lines bzr emits yourself)
[06:58] <blr> wgrant: we consistently render a blankline before a dirty header
[06:58] <blr> well, all but the first
[07:06] <blr> Perhaps this should all be refactored, but this fix does appear to work, so perhaps we should land it and revisit it.
[07:06] <wgrant> blr: So you just assume there's always a blank line between patches?
[07:07] <blr> wgrant: I've written two tests using elmo's diff, not sure I should commit them however, that logic is basically tested in other tests, but I did want to parse a real (large) diff
[07:07] <blr> well, that does appear to be the case.
[07:07] <wgrant> blr: Yeah, no point having such a huge diff (of proprietary code, no less)
[10:28] <cjwatson> blr: There's always a blank line between bzrlib-generated patches, but not between git-generated patches.
[10:28] <cjwatson> blr: So we can't assume there's a blank line there.
[10:29] <cjwatson> blr: And we probably shouldn't insert one into git patches either.
[10:41] <cjwatson> wgrant: Shall I take it from your review that you would like me to fix IPersonSet.getByEmail(None) to return None?
[10:41] <cjwatson> AttributeError: 'NoneType' object has no attribute 'lower'
[10:57] <wgrant> cjwatson: Oh, hm, nevermind then.
[10:58] <cjwatson> OK.  That was why I left the wrapper in place.  Though I'll have another look since we seem to be unnecessarily running things through safe_fix_maintainer again when we could pass in an unadorned e-mail address instead.
[16:22] <cjwatson> unnecessarily running things through safe_fix_maintainer again> ignore that, looking at the wrong branch.  So I'll just land this.
[21:13] <blr> morning
[21:16] <blr> cjwatson: then perhaps we should not count them when generating the comment dict
[21:19] <blr> cjwatson: we also have no test using a git generated diff
[21:36] <blr> so afaict, we either need to change the behaviour of the caller, or add some heuristics to detect a bzr (unified) vs git (coimbined) diff.
[21:38] <blr> not certain if bzrlib.patches can parse a combined diff actually.. I suppose I should test that :)
[22:24] <wgrant> blr: The comment dict is a map of physical diff lines to comments.
[22:24] <wgrant> blr: We can't not count them.
[22:24] <wgrant> The parser which is used to generate the email must be able to cope with the line being there or the line not being there.
[22:30] <blr> wgrant: I think it will have to be special cased for git anyway.
[22:32] <wgrant> blr: Why?
[22:32] <blr> git diffs are not unified diffs?
[22:32] <wgrant> They conform to every definition of that term that I know of.
[22:32] <wgrant> How do they differ?
[22:34] <blr> wgrant: hunk headers differ
[22:35] <wgrant> blr: In what way? The only difference I know of is that the --- and +++ lines don't carry timestamps.
[22:36] <blr> git combined diffs can have hunk headers comparing two or more files
[22:36] <blr> I'm not sure bzrlib is going to parse those
[22:36] <blr> I have yet to check though, it may happily.
[22:37] <blr> have a look at http://git-scm.com/docs/git-diff under "combined diff format"
[22:38] <wgrant> blr: Does the way we use pygit2 actually give those to us?
[22:38] <blr> not certain
[22:40] <wgrant> It would be pretty hostile for it to just give them to us without us asking.
[22:41] <blr> wgrant: how would feel about some code then which checks for the presence of a blank line preceding a hunk header before passing the diff to bzrlib?
[22:43] <cjwatson> bzrlib parses git patches justfine.
[22:43] <cjwatson> tested that many times.
[22:43] <blr> great, that simplifies things.
[22:44] <cjwatson> all we need to do is to be able to cope with arbitrary stuff in between the bits bzrlib gives us.
[22:44] <cjwatson> which is easy because bzrlib preserves the order
[22:44] <cjwatson> at worst it skips some lines
[22:45] <cjwatson> anyway, back a bit later, gaming
[22:49] <wgrant> blr: If LP parses the patch before passing it to bzrlib then it might as well do the whole thing itself.
[22:49] <wgrant> bzrlib needs to preserve the blank line(s), or we need to take Colin's approach.
[22:54] <blr> yep, okay, I'll have a look.
[23:13] <blr> wgrant: "if line.startswith('[23:21] <wgrant> blr: That won't work.
[23:21] <wgrant> blr: It will, for example, consider any blank line within a hunk to be part of the next dirty head.
[23:23] <blr> hmm, in the context of this iterator, not certain how I can determine if the blank is followed by a dirtyheader
[23:25] <cjwatson> also with git diffs I think there's a line starting with "diff"
[23:25] <blr> cjwatson: and also "index"?
[23:28] <wgrant> Yes.
[23:28] <wgrant> There is an arbitrary set of junk between the end of one patch and the start of the next.
[23:30] <blr> unfortunately there's nothing denoting the end of a patch, so presumably we will always have to regex the line
[23:32] <wgrant> Is the junk just any line that doesn't start with '+', '-', '@' or ' '?
[23:34] <wgrant> (or you could count the lines described in the hunk header. not sure which is messier)
[23:35] <blr> junk is anything preceding '--- '
[23:37] <blr> begiunning is set when the first patch line is encountered
[23:37] <blr> so this should work: if beginning and line.startswith(dirty_headers) or not line.strip()
[23:38] <blr> where dirty_headers is a tuple of things we care about
[23:38] <blr> or maybe it should just all be preserved
[23:39] <wgrant> "or not line.strip()" will catch lines in the middle of a hunk.
[23:39] <blr> not if beginning is False?
[23:39] <wgrant> Junk can't just be anything preceding '--- ', because the entire previous hunk precedes it.


[12:14] <barebone> tensorpudding, do you mean that ubuntu-10.10-desktop-i386.iso.torrent will work fine? I'm running i386 version of Lucid.
[12:14] <Alan> or is it still an "alpha ancient build" ?
[12:14] <_kroson_> Alan: still alpha :S
[12:14] <Alan> on the other hand, that "alpha" has been working fine for me for 2 years now
[12:14] <_kroson_> but its not old, the latest one is less than a month old
[12:14] <tensorpudding> barebone: If you're already running lucid, you should upgrade using the Upgrade Manager.
[12:14] <danyR> as anyone read this: http://blog.dustinkirkland.com/2010/10/try-ubuntu-server-in-cloud-on-our-dime.html ?
[12:14] <Alan> a lot more stable than the wrapped-32-bit stuff
[12:14] <tensorpudding> barebone: unless you really want to wipe out your current install
[12:14] <dmatt> tensorpudding: i am on amd64 for 2 years an always had flash working
[12:15] <Dr_Willis> dmatt:  same here.
[12:15] <barebone> tensorpudding, but I have question to upload. Will it erase data, or any software support problem?
[12:15] <barebone> tensorpudding,  *update
[12:15] <tensorpudding> barebone: running the update from the update manager will not touch your personal data
[12:15] <Dr_Willis> theres always a possibilty for issues with upgeradeing... when in doubt backup your imporntant stuff..
[12:16] <Dr_Willis> thats just common sence.
[12:16] <barebone> tensorpudding, even the home folder?
[12:16] <yofel> well, 32-bit flash on 64bit worked fine here too, but I got npviewer.bin crashes all the time and had to reload the site to get flash working again, the new 64bit flash pre-release works fine so far
[12:16] <tensorpudding> barebone: it won't touch the home folder
[12:16] <barebone> tensorpudding, if that's it, then I will update. That will save a lot effort.
[12:17] <Alan> yeah, that's what happened for me, the plugin wrapper is what always crashed...
[12:17] <Alan> I <3 that google chrome will use plugins in your ~/.mozilla/plugins
[12:17] <BUGabundo> motning
[12:17] <BUGabundo> happy 101010 and happy 10.10 release
[12:18] <barebone> tensorpudding, for your information, my home directory is not a separate drive, I use all of my last dive for ubuntu.
[12:18] <barebone> tensorpudding, Do you think it's still safe?
[12:18] <penguin42> BUGabundo: Mornin'
[12:18] <Dr_Willis> Upgrading the system should not touch anytying in the users home at all.
[12:18] <arif-ali> anyone have any ideas on my problem, is there a specific argument that I may be missing?
[12:18] <tensorpudding> barebone: it will be safe
[12:19] <dmatt> Dr_Willis: it will touch settings in hidden folders
[12:19] <Dr_Willis> dmatt:  what settings?  Ive never seen the package manager ever touch anything in /home/usernames
[12:20] <yofel> ok, with DHT enabled the ubuntu torrents finally seed too :)
[12:20] <gnomefreak> when downloading the torent do i just open it for the .iso?
[12:21] <gnomefreak> it has been a damn load time since i downloaded without using my script
[12:21] <gnomefreak> s/load/long
[12:21] <Dr_Willis> gnomefreak:  double click on torrent.. starts torrent clients. and starts downloading the  iso.
[12:21] <dmatt> Dr_Willis: settings for all programs, like ~/.kde or ~/.gnome - i think it is changed to new defaults
[12:21] <gnomefreak> Dr_Willis: thanks
[12:21] <Dr_Willis> dmatt:  ive never seen that happen in several years of ubuntu ussage.
[12:22] <Dr_Willis> dmatt:  it can change the system defaults.. but user settings hav3 always been untouched, and those can override the system defaults
[12:22] <tsimpson> dmatt: packages NEVER touch $HOME, the updated applications will when first run though
[12:22] <Dr_Willis> or they 'can' at least change :)
[12:23] <dmatt> tsimpson: it means it is changed after all
[12:23] <tsimpson> dmatt: but not by the update, only by the actual applications
[12:23] <tsimpson> if you don't run the newly updated app, it's not changed
[12:24] <dmatt> tsimpson: I get the point
[12:25] <jstressman> no ideas on why I can't see Kanji? :/
[12:26] <dmatt> just saying "Upgrading the system should not touch anytying in the users home at all." is not the whole truth, because all the application then do changes
[12:26] <tsimpson> no, the upgrade doesn't touch any user files. the upgraded application will
[12:26] <tsimpson> but that can only happen after they have been upgraded
[12:27] <dmatt> just backup if any data conversion goes wrong that's what i'm trying to promote
[12:27] <tsimpson> hence, the upgrade will not touch anything in $HOME
[12:29] <barebone> tensorpudding, just a question, https://help.ubuntu.com/community/Upgrades page says, I need to backup of my important data.
[12:29] <skyburne1> today is 42
[12:29] <skyburne1> 101010 -> 42
[12:29] <skyburne1> cool date
[12:29] <barebone> tensorpudding, does it applicable for older versions?
[12:29] <penguin42> skyburne1: Heck I hadn't realised that!
[12:30] <skyburne1> this date is a towel date
[12:30] <skyburne1> unique
[12:30] <jstressman> if I just installed a 10.10 nightly 2 days ago, do I need to reinstall, or can I "upgrade" to the release version?
[12:30] <rumpe1> jstressman, you don't need to do anything special... just upgrade your packages as usual
[12:30] <jstressman> rumpe1: k. thanks. :)
[12:30] <Dr_Willis> if you upgraded recently - you may allready be up to date
[12:31] <dmatt> tsimpson: technically you're 100% correct. But if my wihe would asked that question, I would say your settings will be changed because that is the end result of  upgrade process and then running same applications as usual
[12:31] <dmatt> wife
[12:31] <Pr070cal> should i update first then install the nvidia drivers or install the drivers then update ?
[12:32] <tsimpson> dmatt: then the same can be said about most regular updates
[12:32] <Dr_Willis> Pr070cal:  it really shouldent matter.
[12:32] <Pr070cal> i was having the xorg 19. in-compatable issue on beta
[12:33] <Dr_Willis> Pr070cal:  i would upgrade, then install the drivers
[12:33] <Pr070cal> cool fingers crossed :)
[12:33] <dmatt> tsimpson: regular updates do not change application versions, only bugfixes are included, which should not be any problem
[12:34] <tsimpson> dmatt: not always true, an app can change the way it manages settings as part of an update
[12:34] <tsimpson> it may add/remove settings or change default values
[12:38] <dmatt> tsimpson: any disruptive change must follow SRU policy https://wiki.ubuntu.com/StableReleaseUpdates
[13:14] <jstressman> hrm.... torrent is just sitting at 94.96% :(
[13:14] <jstressman> has been for like 30 mins.
[13:18] <lapion> what time will this channel be converted to ubuntu ?
[13:19] <yofel> lapion: this channel is already invite only and redirects you too #ubuntu
[13:19] <yofel> it will be open again once the natty toolchain has been uploaded (around UDS usually)
[13:20] <BUGabundo> it is?
[13:20] <jstressman> restarting Transmission fixed it... 96.32% now...
[13:20] <BUGabundo> so I managed to get in on time?
[13:20] <jstressman> I'll finish it and leave it seeding.
[13:20]  * BUGabundo looks at builders for toolchain entries
[13:20] <yofel> BUGabundo: you got in 4 minutes before it was closed :P
[13:21] <BUGabundo> YAY for me :D
[13:21] <BUGabundo> its always so frustrating
[13:22] <BUGabundo> ahh I missed ikonia /topic change
[13:24] <ikonia> easy to miss
[13:28] <Kuba> !isitout
[13:29] <Kuba> holy @#$$@# ;]
[13:29] <Dr_Willis> You just ruined the quiet! :P
[13:29] <Kuba> where is the party?
[13:29] <Dr_Willis> !party
[13:29] <Glowball> Not at #ubuntu-release-parte, that's for sure
[13:29] <Glowball> party*
[13:30] <Kuba> Something's happenging there
[13:30] <Kuba> gonna be goin!
[13:32] <penguin42> no wonder it's still so quiet then :-)
[13:32] <Dr_Willis> Yep
[13:32] <Dr_Willis> compaer3d to the anarchy in #ubuntu
[13:35] <Ian_corne> :)
[13:35] <Glowball> Why +m?
[13:36] <Glowball> Hmm, until Natty alpha comes out?
[13:37] <Dr_Willis> Yep.. we are special.
[13:37] <BUGabundo> "soon" hummmmm baconnnnn
[13:37] <tsimpson> because any discussion in here will be offtopic
[13:38] <tsimpson> support for released versions is in #ubuntu, and general chat in #ubuntu-offtopic
[13:38] <tsimpson> party in #ubuntu-release-party
[13:38] <tsimpson> so, until alpha1, this channel is a bit pointless :)
[13:38] <Dr_Willis> Im still wondering if the TERM variable gettting set to dumb bug ever got fixed..
[13:39] <BUGabundo> tsimpson: no. #ubuntu+2 is ON topic
[13:39] <Dr_Willis> because its still happening here.
[13:39] <penguin42> Dr_Willis: Bug 621927 ?
[13:39] <BUGabundo> tsimpson: once toolchain is up, ill be upgrading
[13:39] <BUGabundo> not so pointless for me
[13:39] <Dr_Willis> penguin42:  i found about 4 terminal emulators still haaving the same issue
[13:39] <tsimpson> BUGabundo: then you should idle in -devel :)
[13:39] <penguin42> Dr_Willis: Yeh they're all ones that share the same core problem
[13:39] <BUGabundo> those are to hardcore for me :P
[13:40] <BUGabundo> I love my friends in this #
[13:40] <BUGabundo> got used to _live_ in here, for the past 3 years
[13:40]  * penguin42 pats BUGabundo
[13:40] <tsimpson> if -devel is hard-core, upgrading your toolchain is probably not a good idea :p
[13:40] <BUGabundo> learned a lot with many of the regular
[13:40] <BUGabundo> made friendships
[13:40] <BUGabundo> and miss some that are now gone
[13:40]  * BUGabundo looks at bruce89
[13:40] <BUGabundo> tsimpson: those are not the same :P
[13:41] <BUGabundo> I can't run stable
[13:41] <BUGabundo> its to bored
[13:41] <BUGabundo> even my android runs kernel <IP_ADDRESS>
[13:41] <BUGabundo> that's more up to date then most PCs
[13:43] <penguin42> BUGabundo: You know how to build kernels from git right?
[13:44] <BUGabundo> penguin42: never did it :P
[13:44] <BUGabundo> you guys keep forgetting, I try to be _just_ an user
[13:44] <BUGabundo> one that is somewhat more informed then others, and likes to provide support, ideas, feedback, file bugs
[13:45] <tsimpson> -devel would welcome you :)
[13:47] <BUGabundo> I'm afraid seb128 would smack my arse jk jk
[13:48] <BUGabundo> tsimpson: but dully noted, once I logoff here, ill join -dev
[13:48] <tsimpson> anyone can still idle here, just not speak ;)
[13:50] <BUGabundo> shame
[13:52] <Dr_Willis> Shhhh,,,, we are idleing!
[13:56] <BUGabundo> jpds: how are mirrors?
[13:57] <BUGabundo> guess it's a good time to re-update my isos
[13:57] <BUGabundo> _all_ of them
[13:57] <BUGabundo> around 20GBs
[14:01] <lapion> I was wondering if it's possible to convert/upgrade from 32bit to 64bit
[14:02] <tsimpson> no, you'll need to reinstall
[14:03] <penguin42> lapion: I have seen someone do a truly grim hack to do that - but it's truly truly grim
[14:04] <BUGabundo> lapion: no
[14:04] <BUGabundo> yeah, in theory its possible
[14:04] <BUGabundo> just move 32bits lib dir, and install the 64bits with -force
[14:05] <lapion> I have done upgrades by simply changing the software sources.. but after a certain version it was not possible anymore
[14:05] <BUGabundo> change aptdb arch and then install a 64bits kernel
[14:05] <BUGabundo> lapion: do your self a favor : DON'T DO IT
[14:05] <BUGabundo> dpkg -l your install packages
[14:05] <BUGabundo> or even better dselect
[14:06] <BUGabundo> backup /etc
[14:06] <BUGabundo> reinstall 64bits restore dselect package list and settings
[14:06] <BUGabundo> you are done in 10 min
[14:06] <lapion> well can do a full-backup.. and then try it just for trying.. it's a scratch system anyhow..
[14:06] <BUGabundo> ofc
[14:24] <gnomefreak> ah much better :)
[14:32] <gnomefreak> cool


[00:05] <forestpiskie> I can tell bodhi_zazen to keep it that way jcastro :)
[00:05] <jcastro> heh
[00:05] <forestpiskie> but tbh - short is best
[00:05] <forestpiskie> so stuff works for me :p
[00:05] <bodhi_zazen> what do you wish it to read ?
[00:05] <forestpiskie> Ubuntu Stuff bodhi_zazen
[00:06] <forestpiskie> :)
[00:07] <bodhi_zazen> "Ubuntu cloud and juju" ?
[00:08] <bodhi_zazen> jcastro: ^^
[00:20] <jcastro> bodhi_zazen: yeah that sounds awesome
[00:21] <forestpiskie> does it have to go in 3rd party stuff bodhi_zazen ?
[00:21] <forestpiskie> :p
[00:21] <forestpiskie> shut up elfy
[00:22] <bodhi_zazen> Can go in main support if you all wish
[00:22] <bodhi_zazen> jcastro: I made the change
[00:22] <jcastro> rawk
[00:22] <bodhi_zazen> jcastro: you want it moved from 3rd party to servers ? main support ?
[00:23] <jcastro> dunno, what does that mean?
[00:23] <bodhi_zazen> http://ubuntuforums.org/index.php
[00:23] <bodhi_zazen> Take a look there
[00:23] <bodhi_zazen> At the top - ABT
[00:23] <bodhi_zazen> General Help
[00:24] <jcastro> Main support is fine I guess?
[00:24] <bodhi_zazen> Currently "Ubuntu Cloud and Juju" is listed in "Other Community Discussions"
[00:25] <jcastro> wherever the server stuff is I guess
[00:25] <bodhi_zazen> I can move it to general help or server section
[00:25] <bodhi_zazen> http://ubuntuforums.org/forumdisplay.php?f=339
[00:25] <bodhi_zazen> If I move it here, it will not be visible on the main page
[00:27] <forestpiskie> sub-forum perhaps bodhi_zazen - server stuff together - with seriosu head one
[00:28] <forestpiskie> good night bodhi_zazen jcastro
[00:29] <bodhi_zazen> jcastro: http://ubuntuforums.org/forumdisplay.php?f=339
[00:29] <bodhi_zazen> you can see it at the top
[00:29] <jcastro> kk
[00:29] <bodhi_zazen> If you want to move it elsewhere, ping =)
[00:30] <jcastro> looks fine to me
[07:25] <nigelb> Woah. unity-design. I don't even...
[11:52] <IdleOne> Good morning to all you weary UDS'ers
[13:38] <AlanBell> morning
[13:40] <DJones> Morning
[13:42] <Pendulum> AlanBell: recovered?
[14:01] <AlanBell> kinda
[14:34] <czajkowski> morning
[14:35] <Pendulum> hiya czajkowski
[14:37] <czajkowski> Pendulum: how do ?
[14:39] <Pendulum> okay, just finishing packing up
[14:40] <Pendulum> have only had one coughing fit this morning so that's an improvement
[14:41] <Pendulum> czajkowski: how're you?
[14:41] <czajkowski> tired/achey
[14:49]  * Pendulum shuts laptop down.
[16:46]  * popey considers breakfast
[16:56] <s-fox> Hi
[19:28] <nigelb> ha, how did I miss laney leaving ~not-canonical :)
[19:47] <s-fox> Hi nigelb
[19:47] <nigelb> hey
[19:47] <nigelb> *yawn*
[19:48] <s-fox> Have I bored you already? :(
[19:48] <nigelb> s-fox: It's 1 am :(
[19:48] <s-fox> Go to bed?
[19:48] <nigelb> about to, yeah.
[19:49] <s-fox> See you :)
[20:52] <daker_> i start feeling that LP ui is so 1900
[21:10] <daker_> czajkowski: does the LP team have a design team or someone who take car of the UI ?
[21:42] <JanC> daker_: that would be "mpt" AFAIK
[21:42] <JanC> Matthew Paul Thomas
[21:43] <mhall119> landed \o/
[21:44] <JanC> mhall119: so, _almost_ home again?  ☺
[21:56] <daker_> JanC: well i think mpt is more UX
[21:59] <JanC> if you really mean design as in pure graphics design, that would the regular design team at Canonical, I guess
[22:00] <daker_> ok
[22:00] <JanC> I'm not sure what's wrong with LP's design though (it's more functional than fancy, of course, but that's as it should be)
[22:01] <JanC> which doesn't mean it can't improve, but I don't see it as "outdated"
[22:04] <daker_> JanC: it's like you are saying, why do we need unity, gnome2 is __still__ functional.
[22:04] <daker_> or even more gnome3
[22:04] <JanC> no, unity is mostly about UX, not so much design  ;)
[22:05] <JanC> not so much graphic design
[22:06] <daker_> JanC: the design(UI) comes first then UX
[22:07] <JanC> actually, the unity looks (graphics design) were here before the unity feel (UX)  ;)
[22:08] <benonsoftware> JanC: Great artical in the APC
[22:08] <JanC> benonsoftware: ?
[22:08] <benonsoftware> Oops, sorry meant jono
[22:08] <JanC> ah  ☺
[22:08] <benonsoftware> JanC: Sorry, tab stuffed up
[22:09] <jono> benonsoftware, hey! APC?
[22:09] <benonsoftware> jono: Australian personal Computing :P, the mag
[22:09] <JanC> benonsoftware: np, I make tab-errors too  ☺
[22:09] <jono> benonsoftware, oh cool
[22:09] <jono> what article?
[22:10] <benonsoftware> jono: In the May issue of APC you've done a artical called "How Ubuntu Is Constructed"
[22:10] <s-fox> glue, lots of glue :D
[22:31] <benonsoftware> jono: Tell me you know what artical I mean ;)
[22:31] <jono> benonsoftware, I have no idea
[22:31] <jono> which one?
[22:32] <benonsoftware> jono: "How Ubuntu Is Constructed"
[22:35] <MrChrisDruif> "<jono> benonsoftware, hey! APC?" < That looked like "Hey, hey apple!"
[22:37] <jono> benonsoftware, aha!
[22:37] <jono> I assume Linux format licensed it to them
[22:37] <benonsoftware> Ah, :)
[22:38] <benonsoftware> (That was one of the main reasons why I got it :P)


[07:43] -queuebot:#ubuntu-release- Unapproved: erlang-p1-tls (cosmic-proposed/universe) [1.0.23-2 => 1.0.23-2ubuntu0.1] (no packageset)
[08:57] <acheronuk> seb128 Laney: filled out lmdb MIR bug as best I could based on previous examples. no doubt it needs some adjustment, but hopefully that is an ok starting point
[08:58] <rbasak> wxl: the relevant policy documentation for that is https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[08:58] <Laney> acheronuk: thx, link?
[08:58] <Laney> I think I subscribed the team last week
[08:58] <rbasak> wxl: the changes will need to be reviewed, so I suggest a tracking bug for the microrelease and a breakdown of the changes included if you want to do that
[08:58] <acheronuk> Laney: LP: #1833745
[08:58] <rbasak> wxl: together with documentation of how those policy criteria are met
[08:58] <seb128> acheronuk, the MIR looks good to me , thx!
[08:59] <seb128> well I mean the description, I'm not a MIR reviewer/didn't look at the package :)
[08:59] <seb128> you can add in the description that desktop-packages is subscribed
[08:59] <acheronuk> I understood :)
[09:03] <acheronuk> seb128: I see desktop-packages under the 'may be notified'. is that good enough for this?
[09:04] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1022.22] (kernel)
[09:06] <seb128> acheronuk, yes, the team is subscribed which is what the MIR process ask for, that's just how launchpad shows subscriptions
[09:07] <acheronuk> updated then
[09:10] <seb128> thx
[09:21] <doko> apw: please could you check that kernels built with the new hardening flags build and run in eoan? no rush
[09:21] <apw> doko, fun, thanks for the heads up
[10:12] -queuebot:#ubuntu-release- Unapproved: accepted erlang-p1-tls [source] (cosmic-proposed) [1.0.23-2ubuntu0.1]
[10:14] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1022.22]
[10:17] <jamespage> morning - please can the ceph 13.2.6 uploads in the unapproved queues for cosmic and disco be rejected
[10:17] <jamespage> the patch picked for https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1833079 is foobar
[10:30] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-153.180] (core, kernel)
[10:52]  * apw looks a queuebot ... hello ?
[10:52]  * apw notes he accepted that linux-signed binary New about 2m after it appeared; and yet ... queuebot has not noticed
[10:53] <apw> oh she is gone
[10:54] <apw> stgraber, is queuebot still in your balywick ?
[10:56] <jamespage> thanks vorlon
[12:34] -queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu6.1]
[12:40] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-19.20~18.04.1] (kernel)
[12:40] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-24.25~18.04.1] (kernel)
[12:40] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-19.20] (core, kernel)
[12:40] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-19.20~18.04.1] (kernel)
[12:40] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-24.25~18.04.1] (kernel)
[12:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-24.25] (core, kernel)
[12:41] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-19.20] (core, kernel)
[12:41] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-24.25] (core, kernel)
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-19.20~18.04.1]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-24.25~18.04.1]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-24.25]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-19.20]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-19.20~18.04.1]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-24.25]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-24.25~18.04.1]
[12:41] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-19.20]
[13:45] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:<IP_ADDRESS>]
[13:51] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:<IP_ADDRESS>]
[13:54] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.34]
[14:02] <sil2100> ddstreet: ^ I rejected the bionic upload due to unrelated noise in the upload, can you re-upload it without those unneeded changes?
[14:03] <ddstreet> sil2100 that noise is intentional, see comment from bdmurray re: running pre-build.sh in #ubuntu-devel
[14:03] <sil2100> ddstreet: I know that seems to happen from time to time for u-r-u, mostly because it has some symlinks to the host directories?
[14:05] <ddstreet> sil2100 well i thought my chat with him was in u-devel, having trouble finding it in scrollback now
[14:06] <sil2100> ddstreet: if Brian is fine with it then I'm fine with that as well then
[14:06] <sil2100> Maybe it was -release?
[14:06] <ddstreet> yep just found it, was last week wed in this channel
[14:06] <ddstreet> june 19
[14:07] <sil2100> ddstreet: ah, see it, but yeah, basically the mirrors.cfg and DistUpgradeVersion.py pieces are good, but there's also some other changes for just the bionic upload
[14:08] <ddstreet> oh?  ok lemme check that, sorry
[14:08] <sil2100> ddstreet: http://launchpadlibrarian.net/429506242/ubuntu-release-upgrader_1%3A18.04.33_1%3A18.04.34.diff.gz <- nothing serious (as mentioned in my rejection message), but still, a test sources.list got removed and a variable name changed
[14:08] <ddstreet> sil2100 ah, apt_btrfs_snapshot.py
[14:08] <ddstreet> that gets pulled in from the running system
[14:08] <sil2100> Yeah
[14:09] <ddstreet> that's also part of pre-build.sh:
[14:09] <ddstreet> echo "copying apt_btrfs_snapshot.py for the upgrader tarball"
[14:09] <ddstreet> cp /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py DistUpgrade
[14:09] <sil2100> I mean, the variable name change is a no-op, but I don't know if that sources.list wasn't used somewhere in the testing?
[14:10] <sil2100> Since tests/data-sources-list-test/sources.list got dropped
[14:10] <sil2100> bdmurray: ^
[14:10] <ddstreet> that happened during pre-build.sh as well
[14:10] <sil2100> bdmurray: do you remember if that file is used anywhere during testing?
[14:13] <ddstreet> i looked at later releases, it's removed from those already in his last update apr 2019
[14:14] <bdmurray> sil2100: iirc sources.list is copied to for every test so yes its used but it gets overwritten all the time
[14:14] <ddstreet> last commit of that file in b-e: https://pastebin.ubuntu.com/p/pHnSjqsxZN/
[14:15] <ddstreet> it's gone in all except b
[14:16] <bdmurray> Right, I seem to recall make sure the cleanup of the tests worked so sources.list wasn't left over
[14:24] <ddstreet> yep, i confirmed the step in pre-build.sh that runs 'xvfb-run nosetests3' removes the sources.list file
[14:32] <teward> can someone provide a second set of eyes on some autopkgtest failures please?  I'm pretty certain the test is bad because of a Selenium / Chromium snap issue, and therefore the test is bad, but I want a second opinion...
[14:32] <sil2100> ddstreet, bdmurray: ok then, let me accept it out of Rejected then
[14:32] <sil2100> Thanks
[14:33] <teward> kopano-webapp/3.5.6+dfsg1-1 failures on amd64, arm64, armhf, and i386.  I think those tests need to be marked as 'bad tests' if possible, 'cause a dependency inside there is either not compatible with the arch or just outright crashing...
[14:35] <teward> (it's blocking nginx in proposed, currently, but from what I can tell on the logs it's literally a Chromium crashing problem.
[14:35] <teward> and since it's snapped Chromium...)
[15:00] <Laney> what's changed to make tzdata not be installed in my eoan schroot?
[15:01] <Laney> I guess mozjs60 not {Build-,}Depending on it is technically a bug even in Debian (Priority: required), but ...
[15:04] <cjwatson> I made livecd-rootfs install it in the buildd subproject again recently ...
[15:05] <cjwatson> dunno if you're using that though
[15:05] <teward> Laney: you could always amend your sbuild envs by adding it to the pristines manually
[15:06] <Laney> I probably used mk-sbuild to build it
[15:24] <stgraber> apw: yep
[15:30] <apw> stgraber, she was on holiday for a bit
[16:07] <teward> release team: can someone either failure-ignore or badtest the kopano-webapp test for armhf?  Since Chromium has moved to snaps, armhf is saying the system can't run snaps there.  Or at least, not the Chromium snap.  The remaining autopkgtest failures for kopano-webapp seem Chromium related, and Laney's looking at that since it's now been snapped.
[16:07] <teward> https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 is a bug about the autopkgtest failures, and is related.
[16:08] <teward> armhf returns: error: system does not fully support snapd: apparmor detected but insufficient permissions to use it
[16:32] -queuebot:#ubuntu-release- New: accepted ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
[16:43] -queuebot:#ubuntu-release- New binary: ubuntustudio-menu-add [amd64] (eoan-proposed/universe) [0.1] (no packageset)
[16:44] <Eickmeyer> sil2100: Thanks!
[17:09] <wxl> rbasak: does that hold true because we consider debian an upstream? the ultimate source did not do a microrelease.
[17:15] <rbasak> wxl: no point going into semantics. The effect of what you're requesting is the same as an upstream microrelease, and so that policy section applies, IMHO.
[17:15] <wxl> rbasak: well, devil's in the details. just being sure. works for me.
[17:15] <rbasak> wxl: you have a few choices here.
[17:16] <rbasak> wxl: you can cherry-pick a minimal fix which is the default SRU position.
[17:16] <rbasak> wxl: or, if you want, you can "cherry-pick" all the changes, with regular SRU paperwork for each change, as long as each individually qualifies for SRU.
[17:17] <rbasak> wxl: alternatively, the SRU microrelease policy allows the concession, under the documented terms, in a common case where that is onerous.
[17:18] <wxl> rbasak: i think this suggestion that has been made to me was for the purposes of convenience, but i think ultimately it would be better if i just go default. thanks for the advice.
[17:18] <rbasak> You're welcome. I hope that made it clear, and it sounds reasonable?
[17:19] <wxl> absolutely!
[17:19] <wxl> thanks a lot :)
[17:25] -queuebot:#ubuntu-release- New: accepted ubuntustudio-menu-add [amd64] (eoan-proposed) [0.1]
[17:51] <acheronuk> vorlon: thanks for qtbase/pinentry hint :)
[18:56] <vorlon> rikmills: n/p
[19:01] <teward> thanks to sil and the rest of the AAs for accepting ubuntustudio-menu-add - pretty sure that Eickmeyer is very happy about that :)
[19:22] <Eickmeyer> teward: Not so much me, but OvenWerks. Also gives me another package under my belt. :)
[19:24] <teward> :P
[21:19] -queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.178.1 => 1.178.2] (core, kernel)
[21:26] -queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175.5 => 1.175.6] (core, kernel)
[21:32] -queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.7 => 1.173.8] (core, kernel)
[22:36] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
[22:38] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-25.26] (core, kernel)
[22:38] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
[22:39] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-54.58] (core, kernel)
[22:39] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
[22:39] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-25.26] (core, kernel)
[22:41] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-54.58] (core, kernel)
[22:42] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-20.21]
[22:42] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-20.21]
[22:42] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-20.21]
[22:43] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-25.26]
[22:43] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-25.26]
[22:44] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-54.58]
[22:44] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-54.58]
[22:50] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1036.38] (kernel)
[22:51] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1036.38] (no packageset)
[22:53] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1017.19] (kernel)
[23:10] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1036.38]
[23:10] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1017.19]
[23:10] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1036.38]
[23:13] -queuebot:#ubuntu-release- Unapproved: lighttpd (cosmic-proposed/universe) [1.4.45-1ubuntu3 => 1.4.45-1ubuntu3.18.10] (no packageset)