[00:00] <mwhudson> ah ok so you need to give it the rich commits at the time of upload, in some sense
[00:00] <rbasak> Right now this works but you have to go via someone in ~usd-import-team to supply the rich history before you dput (and it must match what you will dput eactly)
[00:00] <rbasak> If the importer hasn't been given the rich history or if it doesn't match the upload exactly, it will synthesize a commit instead
[00:01] <mwhudson> makes sense
[00:01] <rbasak> I have a script here that will do the work for me if you have an MP
[00:01] <mwhudson> i guess it's those {logical,reconstruct,deconstruct}/$version tags it's looking for?
[00:02] <rbasak> The importer actually looks only for an "upload" tag currently.
[00:02] <mwhudson> ok well i'm still not 100% sure what i'm going to upload
[00:02] <rbasak> And all I need is the branch tip of your proposed upload to tag.
[00:02] <mwhudson> so when i do, i'll push and see if i can get you to tag it before i upload
[00:02] <rbasak> When you have it ready, throw it into an MP please. I have a script I can throw an MP at, and it'll create and send the upload tag to the importer.
[00:03] <mwhudson> ack
[00:03] <rbasak> This is only temporary. Eventually I hope that we'll have better glue for this missing piece.
[00:03] <mwhudson> sure
[00:03] <mwhudson> do you expect to get time to work on this in the next cycle?
[00:04] <rbasak> I intend to shore up the importer as it stands this coming cycle. The workflow glue I don't expect to do this cycle, sorry.
[00:04] <mwhudson> ok
[00:04] <rbasak> Though there is a Launchpad feature coming (ref-based ACLs) which may mean that we can allow uploaders to push their own rich history directly as a better stop-gap.
[00:04] <mwhudson> are the launchpad changes i've seen go by about per-ref permissions related to this?
[00:05] <mwhudson> ah haha
[02:59] <Tecan> was wondering if ubuntu is going to join the OIN openinventionnetwork to gain access to the recently opensourced 60k patents microsoft gave
[02:59] <Tecan> could make it easier for pc manufacturers to bundle ubuntu with their hardware
[03:01] <sarnold> Tecan: https://www.openinventionnetwork.com/community-of-licensees/
[03:06] <Unit193> Gain access to?  Doesn't quite sound entirely 'open source'
[03:09] <xnox> sarnold, oooh nice. didn't know we are associate member.
[03:09] <sarnold> now to do something fun with those patents! :)
[03:10] <sarnold> a buddy who spent a summer at Sun said they got a patent on subtraction once.. maybe that's a good starting point.
[03:11] <Unit193> Interesting results when one searches that page for 'buntu'
[03:20] <jbicha> I was contacted once by them a long time. They wanted UGR to join. I explained that I had almost nothing to do with that project and I didn't think it made any sense for them to be trying to target such small new distros
[03:20] <jbicha> that was https://launchpad.net/ugr which was separate from what later became Ubuntu GNOME
[03:20] <jbicha> long time ago
[03:21] <jbicha> they only had 332 licensees then!
[03:22] <sarnold> heh :)
[03:22] <sarnold> now they've got *thousands* many of which surely must still exist :) heh
[03:24] <jbicha> https://distrowatch.com/search.php?status=All only has 895. It's funny that Distrowatch has much higher standards…
[03:24] <sarnold> that seems low :)
[03:26] <jbicha> Distrowatch wouldn't add Ubuntu GNOME until we had a website
[03:26] <jbicha> it's funny because we were already approved by Ubuntu's Tech Board by that point
[03:26] <jbicha> oh and they wanted a logo
[10:24] <mwhudson> urgl
[10:24] <mwhudson> rbasak: pristine-tar is refusing to checkout one of the orig's from the cargo import you did
[10:24] <mwhudson> git branch --track pristine-tar pkg/importer/debian/pristine-tar
[10:24] <mwhudson> pristine-tar checkout cargo_0.30.0.orig-vendor.tar.gz
[10:25] <mwhudson> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
[10:26] <mwhudson> it's not important, i can get the file from debian of course, but it's a bit surprising
[10:27] <rbasak> mwhudson: the pristine-tar stuff sometimes breaks
[10:27] <rbasak> nacc (not here) better knows the failure cases I think.
[10:27] <rbasak> I believe there are bugs filed in Debian on it.
[10:27] <rbasak> So right now the importer is best effort on that only.
[10:27] <mwhudson> yeah i know some people don't really trust it, maybe i'm about to join the ranks
[10:27] <mwhudson> fair enough
[10:28] <rbasak> I'm less focused on it since we don't worry about the pristine-tar hashes being reproducible, since that won't affect anything in practice as it's just used as a file store.
[10:28] <rbasak> So we can fix it later and force push the pristine-tar branches if needed, once whatever is broken is fixed (somewhere between gbp import-orig and pristine-tar I think)
[10:29] <mwhudson> true
[10:29] <rbasak> We have an experimental subcommand "export-orig" that tries to get the orig tarball(s) from all the possible sources (you already have one in parent directory, pristine-tar, Launchpad I think)
[10:31] <mwhudson> in this case https://launchpad.net/debian/+source/cargo doesn't have the one i want, i want the one from experimental
[10:31] <mwhudson> oh wait yes it does
[10:31] <mwhudson> https://launchpad.net/debian/+source/cargo/0.30.0-1~exp1, nice
[10:32] <rbasak> In theory you should be able to check out pkg/debian/experimental and run git ubuntu export-orig I think. Not sure what'll happen though!
[10:39] <mwhudson> rbasak: https://paste.ubuntu.com/p/r8m76CRbqG/ oh well!
[10:42] <rbasak> :(
[13:09] <ahasenack> Laney: if you have a moment, could you help me troubleshoot two things in autopkgtests please, if there are logs: a) https://bileto.ubuntu.com/excuses/3487/xenial.html stuck for hours
[13:09] <ahasenack> Laney: b) https://bileto.ubuntu.com/excuses/3486/trusty.html tests didn't run, but the package has them (unless I made a super silly mistake, but I can't see it)
[13:10] <ahasenack> these would be new tests, this package had none so far
[13:13] <jbicha> ahasenack: I can't run autopkgtests for packages in my PPA (on autopkgtest.ubuntu.com) if the package in Ubuntu doesn't have autopkgtests yet. I don't know if Bileto is special.
[13:14] <ahasenack> yeah, there could be some quirk because of that, and also because it's an old release perhaps (trusty, xenial not that old)
[13:14] <ahasenack> I'm at a loss there. They run locally at least, I might as well just propose it as is and see what happens for real when it's uploaded
[14:51] <rbasak> Trevinho: around?
[14:52] <rbasak> I'm quite confused by your nautilus SRU uploads.
[14:52] <rbasak> "Fix unpaired unref on search engine" - that doesn't seem to be in Cosmic, for example?
[14:52] <Trevinho> rbasak: yes
[14:54] <Trevinho> rbasak: this is the upload where it is included in cosmic https://launchpad.net/ubuntu/+source/nautilus/1:3.26.4-0ubuntu7
[14:54] <Trevinho> rbasak: it's not a bug in bionic though, so I've not mentioned it as the bug
[14:55] <rbasak> Ah, I see. Sorry, my git-ubuntu view is behind.
[14:55] <rbasak> Presumably I can reject the previous upload that the latest one supersedes?
[15:00] <rbasak> Trevinho: the changes file for your latter upload should really include the changes in .2. Or better, squash .3 into .2 as .2 isn't going to end up being used anyway.
[15:02] <Trevinho> rbasak: yeah, well it was a reupload, after discussing with seb128 we decided to keep as it is not to break our vcs as we already released the version there.
[15:02] <Trevinho> avoiding force-pushes
[15:02] <Trevinho> but if you want we can fix and revert that.
[15:07] <seb128> rbasak, it's the same bug referenced in both entries, but I can reupload with -v if you want
[15:17] <rbasak> seb128: it will make bionic-changes accurate, so while we're both here you might as well please
[15:19] <seb128> rbasak, k, currently busy/in a meeting but I look at it after that
[15:20] <rbasak> FWIW, that workflow in general (avoiding force pushes to VCS, releasing before SRU acceptance) is broken. What if the SRU team reject an upload requesting a material change to the upload? What will you do then?
[15:22] <seb128> rbasak, well, bumping the version and doing -v is always a valid option
[15:22] <rbasak> That'll get really confusing if an SRU contains a bunch of versions in the changelog (and changes file) that never actually landed.
[15:23] <rbasak> Including reverts of previous changes, etc.
[15:23] <seb128> yeah, not optimal
[15:23] <seb128> but having things uploaded but not pushed to the vcs isn't either
[15:24] <seb128> because then others might do conflicting work
[15:24] <seb128> no perfect solution :/
[15:24] <rbasak> I suggest pushing to VCS, but don't push tag until the SRU is accepted, and use a "pending" branch or something.
[15:24] <rbasak> It'd accurately reflect reality then.
[15:24] <Trevinho> yeah, keepingin UNRELEASED until actually lands on ubuntu in the vcs would be the way
[15:25] <Trevinho> right... that would be the way. For next times :)
[15:25] <Trevinho> well, vcs-side
[15:25] <rbasak> Other developers can choose to develop against the pending branch, but also know that if the SRU is rejected they'll have to rebase, which is the reality anyway.
[15:25] <seb128> that doesn't solve the "force push" issue
[15:25] <rbasak> No force push then.
[15:25] <rbasak> Well, I suppose you'd have to delete the pending branch if the SRU is rejected.
[15:25] <rbasak> However that is the reality.
[15:26] <rbasak> It's the same as a work branch for an MP being rejected.
[15:26] <rbasak> One thing I'd like to see eventually with git-ubuntu is SRU reviews taking place in MPs.
[15:27] <rbasak> Then at queue unapproved time, it's just "a MP matching this upload was already SRU-reviewed a +1? Accept".
[15:28] <rbasak> The reason we generally want to avoid force push is because it inconveniences others developing against it. In the case of an SRU reject, that _itself_ forces developers already developing against it to rebase. So the actual mechanical force push itself adds nothing further.
[15:29] <rbasak> So in this case, I think "force push bad -> shouldn't do it" is inappropriate. It's effectively already happened thanks to our existing SRU process, outside VCS.
[15:33] <enaut> Hey guys, I'm trying to generate the man pages with help2man which requires to run my python program during package build. It does run on my system but in the ppa builder it fails. I tried adding dependencies but still get an error during build.
[15:33] <enaut> The logs are here: https://launchpadlibrarian.net/393680409/buildlog_ubuntu-bionic-amd64.ltsp-manager_18.04.2ubuntu5+355~git.f6bfc95~ubuntu18.04.1_BUILDING.txt.gz
[15:35] <enaut> Also info on how to get more specific error messages would be interesting.
[15:43] <rbasak> enaut: have you tried building locally in an isolated environment, eg. with sbuild?
[15:57] <rbasak> Trevinho: I don't follow what the change from search_thread_add_hits_idle to search_add_hits_idle has to do with the SRU bug being fixed.
[16:02] <Trevinho> rbasak: that was code submitted upstream too, so there was some refactory involved which is not strictly needed. Speaking of that change it's not related to the SRU bug (the patch is, as indicated in the changelog). This was needed for fixing a crash that was not yet in bionic but was a potential one since it appeared upstream (and in cosmic with https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1797851)
[16:03] <rbasak> Trevinho: SRU policy is that bugfixes must be minimal though?
[16:07] <Trevinho> rbasak: I think changelog entry is wrong indeed (i think I pasted the same bug number -_-), anyway sure it is; but I don't see the point of not fixing things that you know will be wrong early enough.
[16:08] <Trevinho> I mean, I don't like the pythonic way of try, catch when I can use an if first :)
[16:09] <Trevinho> let me fix the changelog though, as I didn't want to mention the bug at all initially, since wasn't there bionic, and at this point stash the changes (<- seb128)
[16:10] <Trevinho> if you don't want that patch too, is fine, but there was a memleak and a crash on destruction which is documented upstream. So up to you.
[16:10] <rbasak> Trevinho: it's fine to fix bugs, but I'd rather see them documented properly rather than hiding in some other changes.
[16:10] <Trevinho> no, it wasn't hidden.. At the countratry I also asked seb before about that. I can be more verbose on changelog if you want.
[16:10] <rbasak> Otherwise it becomes insanely difficult to review, which is already the case with this upload due to the other messing about with multiple uploads, touching patches multiple times, etc.
[16:17] <rbasak> Trevinho: I'm not really sure I follow, since I'm not sure what you intend exactly. From my POV, the changelog needs to explain every change made in the upload, and link all the bugs being fixed. So no extra changes that aren't covered by the changelog, and no bugs being fixed for which there is no bug reference in the changelog.
[16:20] <Trevinho> rbasak: well, if you want a bug then we need to upload first the version without those changes, wait for crashes to be reported (I guess will be one day), and then to resubmit the SRU. Otherwise we don't have a way to verificate something that didn't happen yet.
[16:20] <Trevinho> Also there was a mem-leak fix in the upload which is a bug, but hard to verify.
[16:22] <seb128> rbasak, that's the case there, there is one fix, and 2 changelog entries for it, one being "fix issue" and the other one is "fix the same issue harder"
[16:22] <rbasak> Trevinho: we're flexible in SRU verification requirements based on the individual situation. So if you explain in the SRU paperwork in the bug what the situation is wrt. reproduction, but can show that the bug is real and ought to be fixed in an SRU, then we can consider that and make a decision. But for that to happen, you need to have written up that explanation. In a bug. That you link to from the
[16:22] <seb128> which imho is not confusing
[16:22] <rbasak> changelog.
[16:22] <rbasak> seb128: the search_thread_add_hits_idle change in the upload isn't related to that bug though.
[16:23] <Trevinho> nope...
[16:23] <Trevinho> so let me open a bug for that where I explain things, and verification will be just not needed there though
[16:23] <Trevinho> if that's the way that should be done.
[16:24] <seb128> well, you need some sort of verification
[16:24] <seb128> would it be only "test there is no regression in that feature"
[16:24] <rbasak> I'm happy for it to be done that way. I don't intend to mandate any particular mechanism, but what I am mandating is that a decision on whether to include a particular fix or not is ultimately an SRU team decision, and you can't bypass it by just bundling the change and not mentioning it.
[16:25] <seb128> right, sorry about that one
[16:25] <seb128> I was in a meeting and didn't properly follow the details of the discussion, I though you were arguing about having 2 entries rather than 1 merged with the follow up fix
[16:25] <seb128> we are going to fix that problem
[16:25] <rbasak> Thanks.
[17:44] <seb128> rbasak, Trevinho, nautilus reuploaded