Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, After installing our current 'git-subrepo' deb i noticed, that bash-completion integration with git does not work. The git-subrepo's own bash completion works, after you've already typed the first two words 'git subrepo TAB TAB', but the initial recognition of the 'subrepo' sub-command to the 'git' command does not work. It turns out, that current git (bash-completion) in sid does not recognize our 'git-subrepo' executables installed by default into the git-core directory. The git bash-completion support finds git sub-commands using the 'git --list- cmds=comma-separated-list-of-cmdgroups', which executes a specific search for each group. Unfortunately none of the searches brings up the 'subrepo' sub- command. I do not know what is needed for the 'git-subrepo' inside 'git-core' to be recognized there. However i noticed, that the --list-cmds group 'other' scans the /usr/bin/ directory, where our old friend 'git-debrebase' and friends already reside and are being successfully recognized by git. Thus i prepared a change (in my salsa repo: in https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the target installation directory, which seems to work. Could you please take a look, how that holds water in debian. thanks, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Dne 25.04.2024 (čet) ob 12:59 +0200 je Daniel Gröber napisal(a): > On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote: > > Ok, so i'll prepare merge request in salsa gitlab, after pushing my > > change in my working branch? > > So creating a MR is fine but it's not the whole story with gbp. With gbp > you're always dealing with both a debian and an upstream branch so the MR > model doesn't fit since it just deals with the one branch you point it > at. That doesn't really hurt as long as you remember to push your upstream > branch also since I won't be pressing that merge button on the web ui > anyway. > > Technically I can still just assume your upstream branch points to the > upstream/* tag you push -- assuming you don't forget to push the upstream > tag. Seriously this workflow has so many trap doors for DMs it's insane :) > > Anyway. What I want to see is a nice linear series of sensible commits with > your packaging changes and one merge to bring in the new upstream [history] > on the debian branch, the conventional upstream/* tag and the corresponding > upstream branch which should be fast-forward from the previous upstream > history. > > [history]: That's the one default gbp workflow tweak I insist on when it's > possible i.e. when the need for dealing with tarballs doesn't get in the > way. I want git-blame to work in packaging repos. It's increadibly valuable > for debugging but squashing the upstream changes as import-orig defaults to > looses most of that context. > > So you should be doing something like this: > > $ git remote add upstream https://github.com/ingydotnet/git-subrepo.git > $ git fetch upstream > $ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch > # changes and create the merge > $ gbp dch > > $ gbp buildpackage [...sbuild runes...] > > $ git push --tags salsa debian/sid upstream > > There's also `gbp push` to make the git-push easier but it only works after > doing a `gbp tag` to create the debian/* tag. This is however inappropriate > for you as DM to do as the convention is to have the debian tag correspond > to what I upload not what you propose to me :) > > On my side I'll do: > > $ gbp pull samo > > $ gbp buildpackage [...sbuild runes...] > > $ gbp tag# creates the debian/* tag > $ debrelease # upload to ftp-master > $ gbp push salsa > > Hope that gives you something more actionable than my previous mails. > Thanks for this explanation. I suppose we shall apply this workflow upon the git-repo, that you are going to push into the debian/* namespace. As i understand, we are going to push and pull our changes from the same branches of the sam git-repo, however i got a bit confused by your 'gbp pull samo' command which indicates another git-repo involved. If your initial command should've been 'gbp pull salsa', then it is clear to me. > > > PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do > like to keep Debian work public and that includes teaching new > contributors, do you mind if I copy our conversation back to the BTS? I do not mind at all. --Samo
Bug#979188: Maintaining git-subrepo in Debian?
On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote: > Ok, so i'll prepare merge request in salsa gitlab, after pushing my > change in my working branch? So creating a MR is fine but it's not the whole story with gbp. With gbp you're always dealing with both a debian and an upstream branch so the MR model doesn't fit since it just deals with the one branch you point it at. That doesn't really hurt as long as you remember to push your upstream branch also since I won't be pressing that merge button on the web ui anyway. Technically I can still just assume your upstream branch points to the upstream/* tag you push -- assuming you don't forget to push the upstream tag. Seriously this workflow has so many trap doors for DMs it's insane :) Anyway. What I want to see is a nice linear series of sensible commits with your packaging changes and one merge to bring in the new upstream [history] on the debian branch, the conventional upstream/* tag and the corresponding upstream branch which should be fast-forward from the previous upstream history. [history]: That's the one default gbp workflow tweak I insist on when it's possible i.e. when the need for dealing with tarballs doesn't get in the way. I want git-blame to work in packaging repos. It's increadibly valuable for debugging but squashing the upstream changes as import-orig defaults to looses most of that context. So you should be doing something like this: $ git remote add upstream https://github.com/ingydotnet/git-subrepo.git $ git fetch upstream $ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch # changes and create the merge $ gbp dch $ gbp buildpackage [...sbuild runes...] $ git push --tags salsa debian/sid upstream There's also `gbp push` to make the git-push easier but it only works after doing a `gbp tag` to create the debian/* tag. This is however inappropriate for you as DM to do as the convention is to have the debian tag correspond to what I upload not what you propose to me :) On my side I'll do: $ gbp pull samo $ gbp buildpackage [...sbuild runes...] $ gbp tag# creates the debian/* tag $ debrelease # upload to ftp-master $ gbp push salsa Hope that gives you something more actionable than my previous mails. > > Have you found any docs for this workflow? > Not really, it was just an idea while reading about gbp and git-debrebase. Right, that's what I figured but I wasn't sure :) > > I've thought about it some more and perhaps we should for now use something > > simpler (plain gbp) until you get the hang of it and/or the (unapplied) > > patches actually get in the way. > > I agree, i just found my fork of your git-subrepo a nice small playground. As > an > exercise i've converted it into a git-debrebase tree (via: man 7 > git-debrebase: > 'converting an existing package'). Playing with this stuff sure is important to figure out whats going on ;) --Daniel PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do like to keep Debian work public and that includes teaching new contributors, do you mind if I copy our conversation back to the BTS? signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Dne 01.05.2024 (sre) ob 23:09 +0200 je Samo Pogačnik napisal(a): > Hi Daniel, > > After installing our current 'git-subrepo' deb i noticed, that bash-completion > integration with git does not work. The git-subrepo's own bash completion > works, > after you've already typed the first two words 'git subrepo TAB TAB', but the > initial recognition of the 'subrepo' sub-command to the 'git' command does not > work. > > It turns out, that current git (bash-completion) in sid does not recognize our > 'git-subrepo' executables installed by default into the git-core directory. > The > git bash-completion support finds git sub-commands using the 'git --list- > cmds=comma-separated-list-of-cmdgroups', which executes a specific search for > each group. Unfortunately none of the searches brings up the 'subrepo' sub- > command. I do not know what is needed for the 'git-subrepo' inside 'git-core' > to > be recognized there. However i noticed, that the --list-cmds group 'other' > scans > the /usr/bin/ directory, where our old friend 'git-debrebase' and friends > already reside and are being successfully recognized by git. Thus i prepared a > change (in my salsa repo: in > https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the > target installation directory, which seems to work. > > Could you please take a look, how that holds water in debian. > > thanks, Samo Unfortunately, lintian is not happy with my solution above (does not allow subdirs in /usr/bin and however git-subrepo script searches its helper functions in git-subrepo.d subdir in the location of main git-subrepo script). I managed to prepare another solution, without changing upstream sources in a way to move 'git-subrepo' executable scripts into /usr/libexec/git-subrepo and by adding a symlink to main git-subrepo executable into /usr/bin. That way bash- completion integration works as in the initial solution and lintian is also happy. I pushed (forced) the new solution over the previous one. regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 18.03.2024 (pon) ob 13:55 +0100 je Daniel Gröber napisal(a): > > A good place to start is https://wiki.debian.org/Packaging > > If you prefer a talk format there's Lucas' (excellent) tutorial > https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf > I can't find a recording of it but the slides are pretty extensive. > > In video format there is > https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/ > but I can't vouch for that one. > > We can also do a call to figure out where you're at and what info you need > because the huge scope of the general packaging related documentation can > be a bit overwhelming and confusing, even if what you need to know is like > 5% of that. Thanks for all your input, i'll try to setup the debian/build environment first and go through the provided links. Which debian-specific tools do you find essential in your workflow, so that i can focus on them while reading the docs? regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 24.04.2024 (sre) ob 17:33 +0200 je Daniel Gröber napisal(a): > I'll push the repo there and give you access, you just have to adjust the > Vcs-* fields and get those changes to me in a way that I actually want to > accept them ;P > > FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but > I'm still trying to hone your git collab maintanance skillz :) > Ok, so i'll prepare merge request in salsa gitlab, after pushing my change in my working branch? > > idea was to reverse the gbp's view on its branches, where the debian/sid > > is the continuous branch and the patch-queue branches are the > > intermediate and temporary ones. > > I have to admit I've never really considered this to be a possible > workflow. Honestly I don't think it's a good idea to hold a loaded gun > (gbp) the wrong way round ;) > > Have you found any docs for this workflow? Not really, it was just an idea while reading about gbp and git-debrebase. > > > In this experiment i am trying to have the patch-queue branch the main > > continuous branch, brought (by any git means) to the state, where one > > could do 'gbp pq export' to a fresh debian/sid branch rooted before any > > upstream commits grouped at the end of the patch-queue branch. > > git-subrepo is a relatively simple upstream so I would really not deviate > from established and documented workflows for it. I get you probably want > to explore the possible git workflows in Debian and admittedly my idea to > use git-debrebase is probably also severe overkill (and I'm also guilty of > just wanting to play with it too ;). > > I've thought about it some more and perhaps we should for now use something > simpler (plain gbp) until you get the hang of it and/or the (unapplied) > patches actually get in the way. I agree, i just found my fork of your git-subrepo a nice small playground. As an exercise i've converted it into a git-debrebase tree (via: man 7 git-debrebase: 'converting an existing package'). regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 12.04.2024 (pet) ob 16:02 +0200 je Daniel Gröber napisal(a): > > +git-subrepo (0.4.6-1) unstable; urgency=medium > + > + [ Daniel Gröber ] > + * Fix Vcs URLs, s/guest-dxld/dxld-guest/ > + * Update changelog for 0.4.3-2 release > > Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does > usually filter those out. > > + * Add salsa-ci config > + * Revert "Update changelog for 0.4.3-2 release" > > I would collapse such VCS artifacts too since the changelog is from the > perspective of "what changed since the last version" in the end, not a blow > by blow of the git changes we used to get there. It's a judgement call tho. > > + > + [ Samo Pogačnik ] > + * Updated debian/control info > > Needs to be a lot more specifict than that. In d/changelog you're talking > to two main groups of readers: other Debian contibutors (i.e. me) and > actual end users. Does this tell me what I need to know to figure out why > you made that change? Not really. > > Looking at the diff it should have even been two commits "d/control: Point > Vcs at samo" and "d/control: Make myself Maintainer". > Thanks for the review. I followed your suggestions above and recommited d/control and d/changelog. > As for the Vcs change: I'd prefer if we put the git repo in the debian/* > namespace on Salsa. > Here i am not sure who can / how to do this? > > I also made another git-subrepo_rebase project ( > > https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with > > rebasing of debian branch onto each renewed upstream. I assume rebasing > > workflow > > shoud somehow avoid commiting patch series into main-working branch. I > > understood git-debrebase figured that out, but ... (see below) > > I have a hard time figuring out what is going on in your repos. Damn I > already hate gbp from a review standpoint. > > I'm not sure you've internalized this, with gbp you really don't want to do > any manual git-pull/git-merge calls. Let it do it throught it's > gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of > me when I try to review the package. > I feel i owe you more explanation of what i am trying to achieve here (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The idea was to reverse the gbp's view on its branches, where the debian/sid is the continuous branch and the patch-queue branches are the intermediate and temporary ones. In this experiment i am trying to have the patch-queue branch the main continuous branch, brought (by any git means) to the state, where one could do 'gbp pq export' to a fresh debian/sid branch rooted before any upstream commits grouped at the end of the patch-queue branch. So, when a new upstream version is to be integrated (after pulling the upstream repo): --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/upstream_version). 2. rebasing main patch-queue branch onto upstream at its new release 3. squashing existing d/* commits of previous releases into a single commit 4. do any necessary work on d/* and upstream code to make things work in new version 5. rebase/reorder commits after the squashed commit on patch-queue branch to put any d/* commits in front of any upstream commits 6. create a new debian/sid branch from the latest d/* commit 7. on patch-queue branch run 'gbp pq export' to generate final changes (patches) on new debian/sid --- For each new debian release (same upstream), a similar procedure is needed: --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/debian_version). 2. do any necessary work on d/* and upstream code to make things work in new debian release 3. rebase/reorder new commits on the patch-queue branch to put any d/* commits in front of any upstream commits 4. create a new debian/sid branch from the latest d/* commit 5. on patch-queue branch run 'gbp pq export' to generate final changes on new debian/sid --- The main problem i face is: How to run test builds directly from patch queue branch to get equivalent 'snapshot' results as from the final debian/sid branch? > > I watched video about git-debrebase and it seemed reasonable to me at first, > > however they lost me when dgit and pushing to dgit repo got into play. > > The history structure does get a bit confusing yeah. My main takeway: > "patches applied" workflows exist *mind blown*. I hadn't seen that yet, > exactly what I've been looking for since gbp-pq sucks and quilt is no > better. I just want to use striaght up git damn it and that's what > debrebase and dgit seems to let you do :) > I somehow managed to avoid quilt until now so i can not really comment it, but i agree that having a patched git branch is light years better than having a series of patches acompanying the original code. > > I'm actually tending to just
Bug#979188: Maintaining git-subrepo in Debian?
Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a): > Hi Samo, > > wouldn't you know it I've become a DD before I got a response to the > git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it > just now. > > Are you still interested in maintaining git-subrepo in Debian? > > I'm trying to limit my personal packaging work to stuff I actually use on a > regular basis and apparently subrepo is not that essential, but as a DD I > can now sponsor any uploads and help you with figuring out the Debian > workflow and such though. > > My packaging from way back when is at > https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably > needs a once over to check for updates necessary changes tho. > > Thanks, > --Daniel Hi Daniel, please excuse me for my late response, but my situation from 2020/21 when we proposed the git-subrepo ITP changed in a way that i am spending most of my free time off-line. With this on mind i am not sure, if i am responsive enough for a maintainers job (i might be off-line for a few weeks from time to time). However, i am tempted to push this through and give git-subrepo more audience. Unfortunately i am more experienced in embedded Linux (yocto / openembedded / bitbake) than in debian packaging and my desktop is more or less Ubuntu. If you think that may shortcomings aren't that much of a showstopper, feel free to send me your procedures/commands to deal with your salsa/git-subrepo repo. I would very much appreciate any guidance regarding debian packaging procedures and needed packaging/testing environment. And of course congratulations on becoming a DD! best regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 08, 2024 at 09:01:24PM +0200, Samo Pogačnik wrote: > > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: > > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html > > (note the navigation buttons in the top right) > > Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo > according to gbp manual and now i am not sure if generated changelog is ok. You can just edit the changelog `gbp dch` generates. I do find it fucks up most of the time the way I use it and just edit it. I am starting to think gbp is more trouble that it's worth now that I'm starting to look at some of the other workflows... +git-subrepo (0.4.6-1) unstable; urgency=medium + + [ Daniel Gröber ] + * Fix Vcs URLs, s/guest-dxld/dxld-guest/ + * Update changelog for 0.4.3-2 release Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does usually filter those out. + * Add salsa-ci config + * Revert "Update changelog for 0.4.3-2 release" I would collapse such VCS artifacts too since the changelog is from the perspective of "what changed since the last version" in the end, not a blow by blow of the git changes we used to get there. It's a judgement call tho. + + [ Samo Pogačnik ] + * Updated debian/control info Needs to be a lot more specifict than that. In d/changelog you're talking to two main groups of readers: other Debian contibutors (i.e. me) and actual end users. Does this tell me what I need to know to figure out why you made that change? Not really. Looking at the diff it should have even been two commits "d/control: Point Vcs at samo" and "d/control: Make myself Maintainer". As for the Vcs change: I'd prefer if we put the git repo in the debian/* namespace on Salsa. + + -- Samo Pogačnik Sun, 07 Apr 2024 19:31:14 + > I also made another git-subrepo_rebase project ( > https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with > rebasing of debian branch onto each renewed upstream. I assume rebasing > workflow > shoud somehow avoid commiting patch series into main-working branch. I > understood git-debrebase figured that out, but ... (see below) I have a hard time figuring out what is going on in your repos. Damn I already hate gbp from a review standpoint. I'm not sure you've internalized this, with gbp you really don't want to do any manual git-pull/git-merge calls. Let it do it throught it's gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of me when I try to review the package. > > I wish we could use a rebase workflow with gbp but I haven't found a way to > > do it yet. At least not with gbp import-ref as-is. We could work on a patch > > for it I suppose ;) > > > I think i am a bit too green for that Maybe, maybe not. Only one way to find out. > I watched video about git-debrebase and it seemed reasonable to me at first, > however they lost me when dgit and pushing to dgit repo got into play. The history structure does get a bit confusing yeah. My main takeway: "patches applied" workflows exist *mind blown*. I hadn't seen that yet, exactly what I've been looking for since gbp-pq sucks and quilt is no better. I just want to use striaght up git damn it and that's what debrebase and dgit seems to let you do :) I'm actually tending to just jumping onto dgit. Should actually make things easier for you once I figure out how it works. There's even nice docs for the sponsorship workflow https://manpages.debian.org/testing/dgit/dgit-sponsorship.7.en.html unlike with gbp where upload sponsorship seems to just not have been considered in it's design if my DM experience with it is any indication :D Opinions? --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 15, 2024 at 09:13:03PM +0200, Samo Pogačnik wrote: > Thanks for the review. I followed your suggestions above and recommited > d/control and > d/changelog. > > > As for the Vcs change: I'd prefer if we put the git repo in the debian/* > > namespace on Salsa. > > > > Here i am not sure who can / how to do this? I'll push the repo there and give you access, you just have to adjust the Vcs-* fields and get those changes to me in a way that I actually want to accept them ;P FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but I'm still trying to hone your git collab maintanance skillz :) > I feel i owe you more explanation of what i am trying to achieve here > (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The > idea was to reverse the gbp's view on its branches, where the debian/sid > is the continuous branch and the patch-queue branches are the > intermediate and temporary ones. I have to admit I've never really considered this to be a possible workflow. Honestly I don't think it's a good idea to hold a loaded gun (gbp) the wrong way round ;) Have you found any docs for this workflow? > In this experiment i am trying to have the patch-queue branch the main > continuous branch, brought (by any git means) to the state, where one > could do 'gbp pq export' to a fresh debian/sid branch rooted before any > upstream commits grouped at the end of the patch-queue branch. git-subrepo is a relatively simple upstream so I would really not deviate from established and documented workflows for it. I get you probably want to explore the possible git workflows in Debian and admittedly my idea to use git-debrebase is probably also severe overkill (and I'm also guilty of just wanting to play with it too ;). I've thought about it some more and perhaps we should for now use something simpler (plain gbp) until you get the hang of it and/or the (unapplied) patches actually get in the way. > So, when a new upstream version is to be integrated (after pulling the > upstream repo): tl;dr honestly. Look, we already have too many possible workflows for git maint. in Debian adding a new one that doesn't have wide usage yet isn't going to help unless it brings something new to the table. So how does this compare to the other 50 workflows? :^) > I feel/hope debrebase is doing something similar as my little experiment but > with all the debian specific bells and whistles, i am currently not even aware > of. I would say that, if dgit/debrebase provides a workflow without messing > with patch-sets (and tarballs), then this is the tool... There's no escaping tarballs in Debian :3 Except maybe with dgit but even then you need to think about calling origtargz... *chanting* In the tarball, part of the tarball, in the tarball, part of the tarball ...[ad nauseam] https://youtu.be/SxGjdx1NXfg?feature=shared=49 and also: https://www.youtube.com/watch?v=EM9kl6jY09A --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Sun, Mar 31, 2024 at 01:42:48PM +0200, Samo Pogačnik wrote: > I prepared a new git-subrepo in salsa as a fork of your project ( > https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and > prepared debby> a new 'debian/sid' branch. Would you be so kind to take a look at it and comment > on what should be changed/fixed and how to proceed. You removed the (Closes Bug#) ITP reference from d/changelog. It's policy to close that but with the first upload, so you have to keep it. Workflow wise I don't see why you needed to make a merge commit at d0cc659. Can you explan what you were doing? On Wed, Mar 27, 2024 at 07:27:31PM +0100, Samo Pogačnik wrote: > Thank you for the valuable information. Currently i managed to reactivate my > Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was > also able to setup debian-sid chrooted environment on my old Ubuntu laptop up > to > the point that i think i can successfully rebuild your current 'git-subrepo' > project using the following commands after entering 'debian-sid' (schroot -c > debian-sid): > $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git I don't use pristine-tar unless absolutely required (due to DFSG repacking or some such), gbp defaults to using git-archive to generate tarballs so just leave off the pristine-tar options. Packaging repos usually declare whether they use pristine-tar in d/gbp.conf so there should rarely be a need to fiddle with the options here. > $ cd git-subrepo > $ gbp buildpackage --git-pristine-tar-commit Don't use --git-pristine-tar-commit. Proper proceedure is to do that explicitily using gbp import-org (if using that). There's another option for importing upstream sources which I prefer (but that is a bit of a PITA): `gbp import-ref` it is a pure git workflow leaving the tarball hassle to gbp and that preserves upstream git history and git-blame'ability. Admittedly it's not very widely used in Debian ATM (which may change thanks to the current xz kerfluffle) so docs may be lacking. Let me know if you can't figure it out. > I hope this is the correct procedure - i wasn't very confident seing 'sbuild' > requireing another 'chroot' from within my original 'chroot', however it seems > to be working now? Seems ok, but building in "clean" chroots (using sbuild) is strongly preferred for real testing. sbuild calls schroot internally. You run it from your system like normal. You just have to configure a tell it which base chroot to use and that chroot needs special handling to be as close to the buildd ones as feasible. Relevant chroot bootstrapping tools often have an "sbuild"/"buildd" mode. I tend to use sbuild-createchroot(8) from ubuntu-dev-tools for chroot building, but debspawn is probably orders of magnitudes easier as far as setup and maintainance of the environments is concerned. > My plan now is to fork your git-subrepo project, fetch latest upstream changes > and rebuild the latest version. Would that be ok to get to the point, when a > new > ITP could have been issued? You don't need a new ITP, it's still open and valid. If you want to be proper you can change the "owner" field to yourself. Send an email to cont...@bugs.debian.org, see https://www.debian.org/Bugs/server-control. Good practice for interacting with the BTS anyway. > > https://github.com/lkhq/debspawn looks really neat and tidy but may be > > untrodden ground. Could be workable if you feel up to trying it. I would > > also be curios to know if it works well. See > > https://github.com/lkhq/debspawn/issues/27 for some discussion between > > ximion (the author) and josh (sbuild maintainer) how it compares against > > sbuild. > > > I might try debspawn on another 'non-debian' 'nixos-based' machine, but this > may > not happen very quickly. As i understood, it only requires a systemd-based > Linux. I wouldn't trust it working outside of Debian. It's a Debian tool for and by Debian people. > > Aah, it's nice and warm in the jungle but simetimes you get lost between > > all the vines~ > > I get lost a lot. Three years ago even so that i created new docker-pbuilder- > based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my > head around debian ways. You can imagine that the project wasn't accepted very > well on debian-devel:). c.f. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence While sometimes we may need to build to understand others need to see you understand before they let you build on their land ;-) --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, wouldn't you know it I've become a DD before I got a response to the git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it just now. Are you still interested in maintaining git-subrepo in Debian? I'm trying to limit my personal packaging work to stuff I actually use on a regular basis and apparently subrepo is not that essential, but as a DD I can now sponsor any uploads and help you with figuring out the Debian workflow and such though. My packaging from way back when is at https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably needs a once over to check for updates necessary changes tho. Thanks, --Daniel
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 01, 2024 at 07:54:09PM +0200, Samo Pogačnik wrote: > > Workflow wise I don't see why you needed to make a merge commit at > > d0cc659. Can you explan what you were doing? > > Well, after i updated the upstream branch, i wanted to preserve your > original debian/sid branch, so i renamed it and merged it into the new > debian/sid branch, based at the latest 0.4.6 release tag of the upstream > branch. > > Actually, this is the point, where i need to learn, how debian/sid branch > is to be managed in a 'debianized' git repo through upstream updates? Right, that's not how to do things in a git-buildpackage repo. See the problem gbp is solving is that Debian source packages (.dsc) are composed of two parts (tarballs) the upstream part (.orig.tar.*) and the debian part (debian.tar.*). To represent this in git gbp has the concept of an upstream branch and a debian branch. When updating your gbp packaging repo to a new upstream version you have to update the upstream branch pointer and merge that into the debian branch separately. import-orig and import-ref will do this for you as it's a hassle. Honestly I really hate this part of gbp's design. Having two branches is just such a hassle to manage and makes all the operations gbp performs non-atomic and it has to support rollback of whatever it has already tried to do in case anything (say a git-merge) fails down the line ... it's a mess. There are other git workflows in use in Debian, eg. dgit, but they're even harder to get your head around, or at least I haven't managed to, so gbp it is for now :/ Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html (note the navigation buttons in the top right) > > I don't use pristine-tar unless absolutely required (due to DFSG repacking > > or some such), gbp defaults to using git-archive to generate tarballs so > > just leave off the pristine-tar options. > > > > Packaging repos usually declare whether they use pristine-tar in d/gbp.conf > > so there should rarely be a need to fiddle with the options here. > > > I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to > 'False' i can simply run 'gbp buildpackage'. Would you recommend setting > 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo? Oh I didn't even know gbp has a user config file. That seems ill-concieved. Gah. Yeah I would strongly reccomend not messing with the pristine-tar option in the user-config. We could explicitly set it =False in d/gbp.conf but I'd rather not as I don't think that's commonly done at all though I can find a number of occurrences in my Debian packaging workdir. > > There's another option for importing upstream sources which I prefer (but > > that is a bit of a PITA): `gbp import-ref` it is a pure git workflow > > leaving the tarball hassle to gbp and that preserves upstream git history > > and git-blame'ability. > > > > Admittedly it's not very widely used in Debian ATM (which may change thanks > > to the current xz kerfluffle) so docs may be lacking. Let me know if you > > can't figure it out. > > > something new for me to digest:) Actually i preserved upstream history in > my manual git-subrepo upstream branch update and lost your history in new > debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer > upstream could solve that as well... I wish we could use a rebase workflow with gbp but I haven't found a way to do it yet. At least not with gbp import-ref as-is. We could work on a patch for it I suppose ;) I just want to avoid using a custom script to import upstream sources if at all possible. Debian already has too much fude factor in packaging. > > sbuild calls schroot internally. You run it from your system like > > normal. You just have to configure a tell it which base chroot to use and > > that chroot needs special handling to be as close to the buildd ones as > > feasible. Relevant chroot bootstrapping tools often have an > > "sbuild"/"buildd" mode. > > > > I tend to use sbuild-createchroot(8) from ubuntu-dev-tools > > for chroot > > building, but debspawn is probably orders of magnitudes easier as far as > > setup and maintainance of the environments is concerned. > > Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild) > to create chroot used by sbuild, however sbuild is not run from my old > ubuntu host directly, but from 'schroot -c debian-sid' prepared > previously (see: > https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild) I don't see why that would be necessary though? Ubuntu also uses sbuild, the version in their archive should work just fine for our purposes as long as you make it use a Debian chroot. --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, just a quick update. Dne 01.04.2024 (pon) ob 23:07 +0200 je Daniel Gröber napisal(a): > > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html > (note the navigation buttons in the top right) > Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo according to gbp manual and now i am not sure if generated changelog is ok. I also made another git-subrepo_rebase project ( https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with rebasing of debian branch onto each renewed upstream. I assume rebasing workflow shoud somehow avoid commiting patch series into main-working branch. I understood git-debrebase figured that out, but ... (see below) > > > > I wish we could use a rebase workflow with gbp but I haven't found a way to > do it yet. At least not with gbp import-ref as-is. We could work on a patch > for it I suppose ;) > I think i am a bit too green for that, however i may provide some crazy idea:) I watched video about git-debrebase and it seemed reasonable to me at first, however they lost me when dgit and pushing to dgit repo got into play. regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 24.03.2024 (ned) ob 17:46 +0100 je Daniel Gröber napisal(a): > For building I use debuild or git-buildpackage+sbuild depending on context. > > I create chroots for sbuild with a wrapper script around > sbuild-createchroot using btrfs-snapshots for efficiency. > > To keep working on a package without having to reinstall the entire > dependency tree (as sbuild does) every time I tweak sbuild's > --anything-failed-commands or use schroot directly with a different chroot > profile setup which has my homedir mounted. > > I'm not sure all of that is the easiest setup these days. It certainly > needs "gardening" to keep it updated and in-sync between both my laptop and > workstation and I have been looking into alternatives. > Thank you for the valuable information. Currently i managed to reactivate my Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was also able to setup debian-sid chrooted environment on my old Ubuntu laptop up to the point that i think i can successfully rebuild your current 'git-subrepo' project using the following commands after entering 'debian-sid' (schroot -c debian-sid): $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git $ cd git-subrepo $ gbp buildpackage --git-pristine-tar-commit $ gbp buildpackage I hope this is the correct procedure - i wasn't very confident seing 'sbuild' requireing another 'chroot' from within my original 'chroot', however it seems to be working now? My plan now is to fork your git-subrepo project, fetch latest upstream changes and rebuild the latest version. Would that be ok to get to the point, when a new ITP could have been issued? > https://github.com/lkhq/debspawn looks really neat and tidy but may be > untrodden ground. Could be workable if you feel up to trying it. I would > also be curios to know if it works well. See > https://github.com/lkhq/debspawn/issues/27 for some discussion between > ximion (the author) and josh (sbuild maintainer) how it compares against > sbuild. > I might try debspawn on another 'non-debian' 'nixos-based' machine, but this may not happen very quickly. As i understood, it only requires a systemd-based Linux. > When trying to understand how the build tools work and fit together keep in > mind that debuild (the traditional default) is nothing but a wrapper around > dpkg-buildpackage (which has a more extensive manpage) and passess most > options down as-is. git-buildpackage (by default) wraps debuild (or > optionally sbuild if you tell it to). sbuild allows building in chroots and > has a number of fancy options to make that easy. > > Aah, it's nice and warm in the jungle but simetimes you get lost between > all the vines~ > --Daniel I get lost a lot. Three years ago even so that i created new docker-pbuilder- based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my head around debian ways. You can imagine that the project wasn't accepted very well on debian-devel:). thanks again, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, I prepared a new git-subrepo in salsa as a fork of your project ( https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and prepared a new 'debian/sid' branch. Would you be so kind to take a look at it and comment on what should be changed/fixed and how to proceed. thanks, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Fri, Mar 15, 2024 at 06:42:54PM +0100, Samo Pogačnik wrote: > Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a): > > Are you still interested in maintaining git-subrepo in Debian? > > please excuse me for my late response, but my situation from 2020/21 when > we proposed the git-subrepo ITP changed in a way that i am spending most > of my free time off-line. With this on mind i am not sure, if i am > responsive enough for a maintainers job (i might be off-line for a few > weeks from time to time). Given that git-subrepo doesn't have much upstream activity these days I don't find that very concerning at all. In fact Debian development is pretty well suited to an offline workflow -- if only because the tools we use were designed so long ago that having no internet was still common ;) Only thing I would recommend you get yourself is a setup where you can send/read your email offline and without Debian stuff getting lost. As long as you surface regularly and especially some time before it's release'o'clock it doesn't matter much. Worst case I'm expected to deal with any packages under my sponsorship umbrella so the responsibility doesn't rest enrirely on you anyway. Now you may wonder "why don't I just do it then" and I just find having someone else on board that cares (more intensly) about a package helps make the drudgery of maintanance more fun ;) > However, i am tempted to push this through and give git-subrepo more > audience. Unfortunately i am more experienced in embedded Linux (yocto / > openembedded / bitbake) than in debian packaging and my desktop is more > or less Ubuntu. Not a big deal either. The packaging should mostly be done IIRC and since subrepo is just a simple shell script it's about the simplest thing to package I can imagine, no need to worry there. The main job(s) of a maintainer are responding to bugs, fixing or forwarding them, communicating with upstream and reviewing new versions, perhaps writing new docs if you can see users struggling. All of which are more about humans than about computer obscurities. As for the Ubuntu bit. There are tons of ways to get a Debian development environment on your system, I don't know what the easiest one is for you since that depends on what you're familiar with. Docker is certainly possible and AFAIK the dockerhub images are maintained by DDs. You just have to keep in mind to build/test with Debian unstable since that's where the actual development happens. Depending on whether you want git-subrepo to also be available for the current release (bookworm) we could also publish to the backports repo but that does double the amount of package building/testing work we have to do. > If you think that may shortcomings I don't think about people that way, what you call shortcomings I call *untapped potential* ;) > I would very much appreciate any guidance regarding debian packaging > procedures and needed packaging/testing environment. A good place to start is https://wiki.debian.org/Packaging If you prefer a talk format there's Lucas' (excellent) tutorial https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf I can't find a recording of it but the slides are pretty extensive. In video format there is https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/ but I can't vouch for that one. We can also do a call to figure out where you're at and what info you need because the huge scope of the general packaging related documentation can be a bit overwhelming and confusing, even if what you need to know is like 5% of that. > And of course congratulations on becoming a DD! Yey, now the real work begins ;) --Daniel
Bug#979188: Maintaining git-subrepo in Debian?
On Mon, Apr 01, 2024 at 11:07:50PM +0200, Daniel Gröber wrote: > I wish we could use a rebase workflow with gbp but I haven't found a way to > do it yet. At least not with gbp import-ref as-is. We could work on a patch > for it I suppose ;) Looking at git-debrebase (https://www.youtube.com/watch?v=iov10lD7tcg) now. Looks promising, hmm. --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 31.03.2024 (ned) ob 16:01 +0200 je Daniel Gröber napisal(a): > > You removed the (Closes Bug#) ITP reference from d/changelog. It's policy > to close that but with the first upload, so you have to keep it. > Fixed (even salsa pipeline is happy:). > Workflow wise I don't see why you needed to make a merge commit at > d0cc659. Can you explan what you were doing? > Well, after i updated the upstream branch, i wanted to preserve your original debian/sid branch, so i renamed it and merged it into the new debian/sid branch, based at the latest 0.4.6 release tag of the upstream branch. Actually, this is the point, where i need to learn, how debian/sid branch is to be managed in a 'debianized' git repo through upstream updates? > I don't use pristine-tar unless absolutely required (due to DFSG repacking > or some such), gbp defaults to using git-archive to generate tarballs so > just leave off the pristine-tar options. > > Packaging repos usually declare whether they use pristine-tar in d/gbp.conf > so there should rarely be a need to fiddle with the options here. > I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to 'False' i can simply run 'gbp buildpackage'. Would you recommend setting 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo? > There's another option for importing upstream sources which I prefer (but > that is a bit of a PITA): `gbp import-ref` it is a pure git workflow > leaving the tarball hassle to gbp and that preserves upstream git history > and git-blame'ability. > > Admittedly it's not very widely used in Debian ATM (which may change thanks > to the current xz kerfluffle) so docs may be lacking. Let me know if you > can't figure it out. > something new for me to digest:) Actually i preserved upstream history in my manual git-subrepo upstream branch update and lost your history in new debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer upstream could solve that as well... > sbuild calls schroot internally. You run it from your system like > normal. You just have to configure a tell it which base chroot to use and > that chroot needs special handling to be as close to the buildd ones as > feasible. Relevant chroot bootstrapping tools often have an > "sbuild"/"buildd" mode. > > I tend to use sbuild-createchroot(8) from ubuntu-dev-tools > for chroot > building, but debspawn is probably orders of magnitudes easier as far as > setup and maintainance of the environments is concerned. > Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild) to create chroot used by sbuild, however sbuild is not run from my old ubuntu host directly, but from 'schroot -c debian-sid' prepared previously (see: https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild) > You don't need a new ITP, it's still open and valid. If you want to be > proper you can change the "owner" field to yourself. Send an email to > cont...@bugs.debian.org, see > https://www.debian.org/Bugs/server-control. Good practice for interacting > with the BTS anyway. > noted and thanks for valuable insights. best regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Tue, Mar 19, 2024 at 10:00:44PM +0100, Samo Pogačnik wrote: > > We can also do a call to figure out where you're at and what info you need > > because the huge scope of the general packaging related documentation can > > be a bit overwhelming and confusing, even if what you need to know is like > > 5% of that. > > Thanks for all your input, i'll try to setup the debian/build environment > first > and go through the provided links. Which debian-specific tools do you find > essential in your workflow, so that i can focus on them while reading the > docs? For building I use debuild or git-buildpackage+sbuild depending on context. I create chroots for sbuild with a wrapper script around sbuild-createchroot using btrfs-snapshots for efficiency. To keep working on a package without having to reinstall the entire dependency tree (as sbuild does) every time I tweak sbuild's --anything-failed-commands or use schroot directly with a different chroot profile setup which has my homedir mounted. I'm not sure all of that is the easiest setup these days. It certainly needs "gardening" to keep it updated and in-sync between both my laptop and workstation and I have been looking into alternatives. https://github.com/lkhq/debspawn looks really neat and tidy but may be untrodden ground. Could be workable if you feel up to trying it. I would also be curios to know if it works well. See https://github.com/lkhq/debspawn/issues/27 for some discussion between ximion (the author) and josh (sbuild maintainer) how it compares against sbuild. When trying to understand how the build tools work and fit together keep in mind that debuild (the traditional default) is nothing but a wrapper around dpkg-buildpackage (which has a more extensive manpage) and passess most options down as-is. git-buildpackage (by default) wraps debuild (or optionally sbuild if you tell it to). sbuild allows building in chroots and has a number of fancy options to make that easy. Aah, it's nice and warm in the jungle but simetimes you get lost between all the vines~ --Daniel signature.asc Description: PGP signature
Re: Help required: riseup-vpn
On Sat, May 04, 2024 at 04:01:12PM +0100, Jeremy Sowden wrote: > > I am also puzzled with different paths for the same binaries across qt > > versions for instance qmlcachegen is: > > > > qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen > > qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen > > > > Why is that? > > Presumably so one can co-install the dev tools for multiple releases > of QT. Why not use /usr/lib/qt6/bin/qmlcachegen and /usr/lib/qt5/bin/qmlcachegen then? The names of binary packages are also inconsistent and I am not sure if there;s a good reason for that? > > In any case, I am not sure how to proceed from here (the error with > > lrelease). Can anyone help out, please? My changes are available in > > salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn > > > > I'd appreciate any pointers. > > You can tell the GUI build script to use the qt6 lrelease and qmake > binaries: Yep, I came up with a similar patch eventually :) Best, Nilesh signature.asc Description: PGP signature
Re: Help required: riseup-vpn
On Sat, May 04, 2024 at 05:56:18PM +0530, Nilesh Patra wrote: > Hi all, > > I am trying to update riseup-vpn to its latest version. I am seeing some > confused mix of qt5 and qt6 - not really sure how qt updates for applications > work. I tried to replace qt5 packages (builddeps) with its qt6 equivalents > but I > end up with: > > | ==BUILD GUI=== > | TARGET: bitmask-vpn > | VENDOR_PATH: providers > | [build.sh] VENDOR_PATH = providers > | [+] Building BitmaskVPN > | lrelease: could not find a Qt installation of '' > | make[2]: *** [Makefile:151: build_gui] Error 1 > | make[2]: Leaving directory > '/<>/_build/src/0xacab.org/leap/bitmask-vpn' > > I was getting a different error with qt5: > > | /usr/lib/qt5/bin/qmlcachegen > --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc > -o release/gui_main_qml.cpp ../../gui/main.qml > | Error compiling qml file: ../../gui/main.qml:0: error: Library import > requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > > But given that the readme says to use qt6, I should not be using qt5 here. The > versions from the qml file have been omitted in this release. > > I am also puzzled with different paths for the same binaries across qt > versions > for instance qmlcachegen is: > > qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen > qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen > > Why is that? > > In any case, I am not sure how to proceed from here (the error with > lrelease). Can anyone help out, please? > My changes are available in salsa at: > https://salsa.debian.org/go-team/packages/riseup-vpn I could get it working with: cd $(BUILDDIR) && $(MAKE) build VERSION=$(VERSION) LRELEASE=/usr/lib/qt6/bin/lrelease QMAKE=/usr/bin/qmake6 PROVIDER=riseup TARGET=riseup-vpn in d/rules. Seems lrelease from qtchooser does not work properly for qt6? Best, Nilesh signature.asc Description: PGP signature
Re: Help required: riseup-vpn
On 2024-05-04, at 17:56:06 +0530, Nilesh Patra wrote:
> I am trying to update riseup-vpn to its latest version. I am seeing
> some confused mix of qt5 and qt6 - not really sure how qt updates for
> applications work. I tried to replace qt5 packages (builddeps) with
> its qt6 equivalents but I end up with:
>
> | ==BUILD GUI===
> | TARGET: bitmask-vpn
> | VENDOR_PATH: providers
> | [build.sh] VENDOR_PATH = providers
> | [+] Building BitmaskVPN
> | lrelease: could not find a Qt installation of ''
> | make[2]: *** [Makefile:151: build_gui] Error 1
> | make[2]: Leaving directory
> '/<>/_build/src/0xacab.org/leap/bitmask-vpn'
>
> I was getting a different error with qt5:
>
> | /usr/lib/qt5/bin/qmlcachegen
> --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc
> -o release/gui_main_qml.cpp ../../gui/main.qml
> | Error compiling qml file: ../../gui/main.qml:0: error: Library import
> requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
>
> But given that the readme says to use qt6, I should not be using qt5
> here. The versions from the qml file have been omitted in this
> release.
>
> I am also puzzled with different paths for the same binaries across qt
> versions for instance qmlcachegen is:
>
> qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen
> qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen
>
> Why is that?
Presumably so one can co-install the dev tools for multiple releases
of QT.
> In any case, I am not sure how to proceed from here (the error with
> lrelease). Can anyone help out, please? My changes are available in
> salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn
>
> I'd appreciate any pointers.
You can tell the GUI build script to use the qt6 lrelease and qmake
binaries:
diff --git a/debian/rules b/debian/rules
index 0e587fbc94d5..31656e0ad777 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,8 @@ export DH_GOLANG_INSTALL_EXTRA=Makefile gui tests
vendor/modules.txt branding pr
export BUILDDIR=_build/src/0xacab.org/leap/bitmask-vpn/
export GOPATH = ${CURDIR}/_build:/usr/share/gocode
export GO111MODULE := off
+export LRELEASE := /usr/lib/qt6/bin/lrelease
+export QMAKE := qmake6
include /usr/share/dpkg/pkg-info.mk
@@ -24,7 +26,7 @@ override_dh_auto_build:
override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
# Qmake test
- cd $(BUILDDIR) && qmake test.pro -o tests/Makefile.test && \
+ cd $(BUILDDIR) && $(QMAKE) test.pro -o tests/Makefile.test && \
cd tests && $(MAKE) -f Makefile.test && $(MAKE) -f
Makefile.test clean
# Golang test
DH_GOLANG_EXCLUDES=gui dh_auto_test
You can also drop the build-dep on qtchooser, 'cause it only work with
qt4 and qt6, I believe.
J.
signature.asc
Description: PGP signature
Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system
Control: block -1 by 1005961 On 03.05.2024 23:45, Christoph Biedl wrote: Hi, That would be necessary - although I don't know how to solve this in a sensible way. Sorry for disturbing your best intentions to bring nq back in shape - but this problem will not disappear by ignoring it. Completely agree. Let's see if there are reactions for the re-opened bug. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Help required: riseup-vpn
Hi all, I am trying to update riseup-vpn to its latest version. I am seeing some confused mix of qt5 and qt6 - not really sure how qt updates for applications work. I tried to replace qt5 packages (builddeps) with its qt6 equivalents but I end up with: | ==BUILD GUI=== | TARGET: bitmask-vpn | VENDOR_PATH: providers | [build.sh] VENDOR_PATH = providers | [+] Building BitmaskVPN | lrelease: could not find a Qt installation of '' | make[2]: *** [Makefile:151: build_gui] Error 1 | make[2]: Leaving directory '/<>/_build/src/0xacab.org/leap/bitmask-vpn' I was getting a different error with qt5: | /usr/lib/qt5/bin/qmlcachegen --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc -o release/gui_main_qml.cpp ../../gui/main.qml | Error compiling qml file: ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version But given that the readme says to use qt6, I should not be using qt5 here. The versions from the qml file have been omitted in this release. I am also puzzled with different paths for the same binaries across qt versions for instance qmlcachegen is: qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen Why is that? In any case, I am not sure how to proceed from here (the error with lrelease). Can anyone help out, please? My changes are available in salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn I'd appreciate any pointers. Best, Nilesh signature.asc Description: PGP signature
