=== mfo_ is now known as mfo
[06:14] <kchsieh> Hello, I am seeking for sponsor for my SRU, https://bugs.launchpad.net/ubuntu/+source/libmbim/+bug/2071877. could someone help? thanks.
[06:14] -ubottu:#ubuntu-devel- Launchpad bug 2071877 in libmbim (Ubuntu) "Support sending AT commnad by mbim-cli for Compal WWAN module" [Undecided, New]
[08:39] <rbasak> bdrung: could you review https://code.launchpad.net/~racb/ubuntu-sponsoring/+git/ubuntu-sponsoring/+merge/468585 for me please? Or if not you, what should our review process be?
=== pushkarnk1 is now known as pushkarnk
[16:22] <juliank> rbasak: I think I need to write some magic wrapper around git-buildpackage that automatically adds $(git-ubuntu prepare-upload args) in there *if my current branch is a git-ubuntu one*
[16:23] <juliank> So I can use the same command for uploading apt and friends and git-ubuntu Ubuntu packages
[16:24] <juliank> Also would the bot get mad if I introduced a faux-sync in apt uploads that made it link the upstream commit as the RHS merge part
[16:24] <juliank> I suppose it would
[16:25] <juliank> But that would be interesting to add these such that you have the upstream commits too
[16:25] <juliank> in git-ubuntu branch basically it does git merge --ours upstream
[16:26] <rbasak> juliank: FWIW, I'd like there to be a "git ubuntu build -S" or similar command that does the right thing. There are some edge case lossy cases that need special handling.
[16:27] <rbasak> juliank: you can do it but I think it's a really bad idea to pull in upstream commits in like that. You'll end up with a commit graph that has a commiti double for everything. It won't affect normal operation, but it'd be a complete mess to follow if you wanted to look at the history for any reason.
[16:27] <rbasak> And it'd be permanent.
[16:28] <juliank> rbasak: It is messy yeah
[16:29] <juliank> rbasak: git ubuntu build -S is ok as long as it exports cleanly into a directory from the commit, adjusting time stamps to the commit time stamp :)
[16:29] <juliank> Then you can build nice native packages
[16:30] <rbasak> For an initial implementation I'd probably use a tmpdir and then run dpkg-buildpacakge
[16:30] <rbasak> Not sure how to implement the timestamp thing.
[16:30] <juliank> i.e. basically do git export --prefix=<package name>-<upstream-version>/ | tar xf -C $tmpdir
[16:30] <juliank> and build in there
[16:31] <rbasak> I think I'd like it to work from a dirty working tree too, bumping the changelog version sensibly in that case.
[16:31] <juliank> I think just use debuild when building from dirty
[16:31] <rbasak> You mean git archive? That'd work but would require different handling for a dirty tree build.
[16:32] <juliank> Um yes git archive
[16:32] <juliank> That's what git-buildpackage does
[16:32] <juliank> I still believe integrating with git-buildpackage would be sweetest because that way I can add all my usual git-buildpackage pre-build hooks and any inherited from Debian also works
[16:32] <rbasak> Thanks for the discussion. I hope to look at this fairly soon (in the next month or two). I might need to ping you then to make sure the behaviour is as expected!
[16:33] <rbasak> There's nothing to stop you from using git-buildpackage yourself locally, with a wrapper if you want, and we might be able to put some functionality for that into git-ubuntu itself.
[16:33] <juliank> Like apt has prebuild and postbuild hooks in debian/gbp that do some verification
[16:33] <rbasak> However, in the general case it doesn't work, because git-ubuntu round trips correctly and gbp has no handling for that (it doesn't need to).
[16:33] <rbasak> For example if the uploader left a .git directory in there.
[16:33] <rbasak> The Debian uploader I mean.
[16:34] <juliank> indeed
[16:34] <rbasak> And in some cases it's needed! See old dotnet package for example. I don't recall if the final upload worked around it but it was an issue that had to be dealt with.
[16:34] <juliank> git has file rewrite filters, but I guess no rename filters
[16:35] <rbasak> There's also the issue of upstream leaving .gitignore and .gitattribute files around and that kind of thing.
[16:35] <rbasak> If using gbp in Debian, then the git checkout is expected to work with gbp, with those things fixed.
[16:35] <juliank> You say it's an issue, dgit people say it is a feature
[16:35] <juliank> They actively want all the .git* files in there (not the dir) and override dpkg excludes!
[16:36] <rbasak> However in the general case it cannot influence the source build because we don't know whether the maintainer used them to generate the source package or not.
[16:36] <rbasak> This is one step further from dgit, too. dgit-using package maintainers can adjust their tree to what dgit needs.
[16:36] <juliank> ".gitignore is in the repository and the upload should match the repository" or something they say
[16:37] <juliank> And I did not keep up with the whole tag2upload thing, apparently they now stuff a shallow igt clone into a tarball and that will be all sorts of fun
[16:37] <rbasak> We don't have that luxury and have to be functional with whatever Debian maintainers throw at us. So what's in the tree must not be able to influence the source package build itself, otherwise git-ubuntu won't round trip correctly.
[16:38] <rbasak> This means ignoring the clean target too, probably.
[18:52] <ahasenack> bdrung: hi, when you have a moment, could you reply to #security's question on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/comments/29 ? Basically if ESM releases are also affected
[18:52] -ubottu:#ubuntu-devel- Launchpad bug 2055718 in tzdata (Ubuntu Mantic) "timezone changed unexpectedly from EST to America/Adak or America/Indiana/Indianapolis" [Undecided, Fix Committed]
[19:39] <bdrung> ahasenack, answered in the bug report