[15:57] tsimonq2: I have packaged the new version of calf plugins (that came out in November and everyone seems to have abandoned). It was requested by the developer that I use the latest git version since it fixes a bug that would cause DAWs such as ardour and qtractor to crash. [15:58] But... lintian keeps yelling at me about the changelog version not being higher. >:( [15:58] False positive perhaps? https://launchpad.net/~eeickmeyer/+archive/ubuntu/ppa/ [16:20] I believe -controls is still waiting for release too. [16:46] cyphermox: If you're around, perhaps you could take a look (if you want)? ^ [18:12] Eickmeyer: I would disagree that packaging a new upstream Git snapshot is good practice unless there are patches you can not cherry-pick. [18:13] Eickmeyer: Have you talked with the Debian Multimedia Team at all? [18:13] Ideally it should go through Debian. [18:14] tsimonq2: I have not, but somebody else filed a bug against the Debian package and there has been no response. [18:16] Additionally, all patches in the git version are required to fix the crashing per the developer. [18:19] If nothing else, this should go into Universe. It would be nice to push it upstream to Debian, but as you alluded, a git snapshot wouldn't fly there. The developer fears that 0.90.1 won't be ready in time. [18:20] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901705 [18:20] Debian bug 901705 in calf-plugins "Latest stable version is 0.90.0" [Normal,Open] [18:23] I suppose for Debian's purposes I could go with the official 0.90.0 version, but the developer seems to be against this. [18:31] Eickmeyer: calf? [18:32] cyphermox: Yes. It's a set of audio effects and instrument plugins. [18:32] you absolutely can take a snapshot if that's what you really want [18:32] it's just that snapshots are often not a good idea because unstability, bugs, etc. [18:32] it depends on the project itself, if they release often, etc. [18:32] The developer wants a snapshot to fix a major bug causing other software to crash. [18:33] They don't release often. The latest release was in November and it was their first in over 2 years. [18:34] However, there were a number of bugs that, until recently, broke stuff. [18:34] They don't think the next release (0.90.1) will be ready by October. [18:35] Eickmeyer: if you're okay with the bugs that might introduce; that's fine. [18:36] because, well, you'll be stuck with the bugs, since it's mostly a package that only ubuntustudio uses [18:37] Eickmeyer: so; can you fix the packaging such that you're pulling a snapshot for the upstream code and keeping the debian packaging? [18:37] cyphermox: That's exactly what I'm doing. My pull is set to the github repo, and my push is set to my PPA currently. [18:38] the version number looks odd for that [18:38] How so? [18:39] My pull from github treats it as a branch merge. [18:39] ah, nevermind, I got confused by the makeup of it [18:40] So, I can update as bug fixes happen. [18:40] If I get bug reports, I'll throw them upstream unless it's a packaging issue. [18:40] wait, no, the packaging is wrong [18:40] What do I need to do? [18:41] how did you get the snapshot in the first place? [18:42] Pulled from the calf developer's github repo, added and tweaked the official /debian directory from the old version. [18:42] the issue is that you have both the source and the debian/ directory in the same tarball right now; that's usually wrong (but not always), and certainly deviates from how things were [18:42] ok [18:42] but generating the tarball? [18:42] The source in git does not contain a /debian directory. [18:42] right [18:44] Launchpad is generating the tarball. I push to https://code.launchpad.net/~eeickmeyer/ubuntustudio/+git/calf and autobuild. [18:44] ah, I see [18:45] right, you don't really want to go git add things to the upstream repo like that, it does confuse LP recipes [18:46] That's why I'm not adding to the upstream repo, I'm just adding the /debian directory locally and pushing to the lp:~eeickmeyer/ubuntustudio/+git/calf repo. [18:47] Additonally, I can cherry pick patches easily by pulling and checking the last commit. [18:47] well, to LP with your current recipe, this is equivalent to it being straight in the upstream repo [18:48] you could do this by keeping your debian/ directory in a separate branch or tree, and then compositing from the recipe [18:48] ie: "merge fix-build lp:~bzr/bzr/fix-build" [18:50] I tried that, it didn't work too well for a different package since it required modifications to the makefile as well. This was easier, but I see what you're saying. It is possible with this since it didn't require any modification to the source, just the /debian directory. [18:51] such that say, your current tree is your debian/ stuff (as-is, doesn't need to change), and you have an untouched git source repo, then you can use the untouched git repo as the original code, add the merge command, etc [18:51] even if it requires modifications to the source [18:51] then you should use patches to handle this :) [18:51] I see. [18:51] otherwise, you might want to look at git-dpm; which can let you do all this, at the cost of a slightly more complicated way of patching the source [18:52] https://wiki.debian.org/PackagingWithGit/GitDpm [18:52] ^ that's what we use for grub2, but it *is* a bit complex, and people often get tripped up -- I certainly did at the beginning [18:53] I'm trying to figure out how I'd create patches from the upstream git repo in my head right now. [18:53] so; to simplify; what I'm looking for to sponsor would be a source package where you have the pristine upstream source in one tarball, and the debian stuff in a separate tarball (with the patches there if you need to change the upstream code -- use quilt if possible) [18:53] Eickmeyer: create patches from the upstream git? [18:54] you mean for stuff that you need to change for your build, or for cherry-picking? [18:55] Sure. So, for instance, a bug gets fixed upstream based on a bug report received on launchpad, how would I get those fixes downstream? [18:55] you have two options [18:55] if you use snapshots, and want all the commits from upstream, you can take a new snapshot [18:55] otherwise you can pick individual commits and turn them into patches under debian/patches [18:56] (I gave a class some years ago about how to do this, I'll look that up for you) [18:57] https://wiki.ubuntu.com/MeetingLogs/devweek1201/IncorporatingUpstreamChanges [18:57] actually, you have a third option, convince upstream to make a release and upload that :) [18:59] I might do that as well. But, if you want me to change to a tarball + merge /debian directory, I guess i need to work on that. [19:00] Eickmeyer: and I can share scripts I have used in the past to take snapshots for NetworkManager, with great results [19:00] with that you could create the tarball, copy just debian/ from wherever you have it in, and make sure the version number is correct (my scripts tell you what it should be) and you can upload [19:02] Looks like I need to make a "calf-packaging" repo with just debian/. [19:02] I use ~/bin/generate-git-source-version: https://paste.ubuntu.com/p/WNrSb4MpqW/ [19:03] Okay, so that just generates the tarball? [19:03] and ~/bin/git-make-snapshot (which calls the previous script): https://paste.ubuntu.com/p/3bPKqv98Jp/ [19:03] pretty much [19:04] it gets you the tarball with the upstream repo, and the right version number for a snapshot (whether it needs a ~ or + and the hash of the commit, etc.) [19:05] Okay. Since I've been using a simple "git push", how do I upload to LP? [19:05] you have a gpg key in LP? [19:05] Yes. [19:06] you can use "dput" to upload straight to a PPA [19:06] ie. dput ppa:eickmeyer/ppa file.changes [19:07] that means you need the .changes file [19:07] which you build with "debuild -S", or "gbp buildpackage -S", depending on how you keep the packaging [19:07] Yes, but what about the initial tarball to combine with the packaging source with the recipe? [19:08] I'm not sure I follow what you mean by that? [19:08] So, the initial git snapshot would be a tarball, correct? [19:08] yep [19:09] you want the tarball in a directory, then extract it to make calf-(version) in that directory, copy debian/ inside [19:09] So, that needs to get to launchpad for the recipe to make it with a merge of the packaging source I upload separately, correct? [19:09] OIC [19:09] then running 'debuild -S' should get you the other files you need [19:09] it makes no use of a recipe whatsoever [19:10] So, you're saying I need to do all the packaging locally? [19:10] not necessarily [19:10] I was getting you through the steps to do things locally, manually, because it's the basis for how it works in general :) [19:11] if you want to use a recipe in LP, it's as you pointed it out -- you want a repo for the debian packaging, and a repo for the upstream code [19:11] then the recipe combines all that, and generates the source package that it uploads [19:11] Yeah, that's what I was alluding to. :) [19:11] using that, I think you also need some small extra bits in debian/ to make it work correctly [19:12] Well, I think I got those extra bits otherwise it wouldn't have built using the recipe I used. All I'd be doing is taking the /debian package out of what I've got and put it in a separate repo, right? [19:13] it would have built, just exactly the way it's built right now [19:13] I mean, as a first step. [19:13] which is incorrect -- it creates a native pacakge, with both the debian/ and upstream stuff together in the same tarball [19:13] lemme think about it for a second [19:14] maybe what I'd start with to get you working with the recipe again would be to begin with http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.new.upstream.html [19:15] so; generating the tarball from upstream, then 'gbp import-orig $file' [19:16] or http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.convert.html if you want to do things from the repo you already have [19:17] that might be even easier, you can git checkout -b from a commit to get the upstream branch, and keep the other one for your packaging -- you'll want to read more on it [19:19] Eickmeyer: I see the debian git repo is already in the right format for git-buildpackage [19:19] Oh, that's good. [19:20] that means if you start from https://salsa.debian.org/multimedia-team/calf.git; you could then load the snapshot (after creating the tarball, however you prefer to do it) with 'gbp import-orig $file' [19:20] cyphermox: There were a number of issues with the rules file that I had to fix, so that wouldn't work very well. [19:20] it'll update all the upstream files (everything but debian/) to what ti should be, then you can commit any changes you need on top of that [19:21] Okay, I see. [19:21] Trying to wrap my head around this. [19:21] there's no way around it being a bit of work [19:22] but that'll get you a package I or any other ubuntu developer would be happy to upload, and you'll also easily be able to send patches to debian :) [19:23] I know it's like drinking from the firehose right now :) [19:24] Yeah. I'm just trying to create the "calf-packaging" repo at the moment for the sake of the stuff I've done. [19:26] I thought you already had that for the recipes [19:27] hm. cooking smells upstairs mean I should probably go check on the dinner. [19:29] cyphermox: Just pushed my packaging code: https://code.launchpad.net/~eeickmeyer/ubuntustudio/+git/calf-packaging [19:30] I'll see if I can get the upstream tarballed and then push patches into my packaging. [19:32] ok [19:33] why do you need patches in your packaging right now? [19:33] I'm afraid we might have had a misunderstanding [19:38] Eickmeyer: I'm thinking all you need is the upstream tarball right now; because then you can take the git tree from debian, run gbp import-orig with the tarball; and finally copy over your debian/ directory and you'll be done [19:38] in fact, you potentially already have part of it [19:39] it depends if you have a 'pristine-tar' branch that already exists for your tree [19:39] or an 'upstream' branch [19:40] Could I push the source snapshot to a launchpad repo and have the recipe merge the source and packaging repo? [19:40] For instance, local clone pushed to launchpad without any revisions. [19:41] Nm, I see what You're saying. [19:41] well, I think one git tree would be better than two :) [19:41] then you won't need to change your recipe either [19:45] I have the upstream tarball locally (did a git clone folllowed by git archive). [19:45] Where should I put it on LP? [19:45] there isn't really a location [19:45] that's why I was recommending starting with the debian tree, and running gbp import-orid [19:46] *import-orig [19:46] that imports the tarball in the upstream branch to get things just right [19:47] Eickmeyer: would it help if I did the steps here, but not push, so you could see the set of commands and the idea behind them? [19:47] Yeah, that would be great. [19:49] ok, give me a minute [20:26] Eickmeyer: https://paste.ubuntu.com/p/24jqkkFSfp/ [20:26] I should make this in a wiki page, and I'm sure there's already one somewhere.. [20:29] there I did things as root because I was in an lxd container, but that was just so I could copy-paste correctly, you certainly shouldn't develop stuff as root :) [20:37] Absolutely. :) [20:38] hopefully this helps a bit [20:52] cyphermox: It should. Unfortunately, I have run out of time and must go to work. :( [21:07] np, kind of busy here too now :)