14:00:25 <jeremiah> #startmeeting
14:00:25 <MeetBot> Meeting started Thu Jan 27 14:00:25 2022 UTC.  The chair is jeremiah. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:47 <jeremiah> I love meetbot.
14:00:59 <h01ger> o/
14:01:02 <utkarsh2102> me, too! \o/
14:01:40 <jeremiah> Well, since we're all so punctual and we have a backlog, let's get started. :)
14:01:52 <bunk> .
14:02:03 <jeremiah> #topic - How to join ELTS documentation
14:02:08 <el_cubano> hi
14:02:32 <jeremiah> I wrote a short bit about how the specifics of joining ELTS
14:02:57 <buxy> o/
14:02:59 <jeremiah> Folks can review. It's not much, I just mention ssh keys and such.
14:03:38 <jeremiah> But I mention it here for completeness' sake.
14:04:05 <jeremiah> The next topic;
14:04:13 <jeremiah> #topic - Archiving of ELTS packages, usecases and solution(s)
14:04:34 <jeremiah> I ought to have sent this along for more discussion after the last meeting.
14:04:51 <jeremiah> But I wrote up what I thought was the problem and some of the related issues;
14:05:03 <jeremiah> https://gitlab.com/freexian-lts/extended-lts/-/issues/4
14:05:27 <jeremiah> What I think we need is a policy
14:06:04 <jeremiah> Perhaps the policy is "use git when possible"?
14:06:16 <utkarsh2102> I think we can convert this to a "policy" once we start to try the "git as dvcs in elts" - which we haven't yet.
14:06:29 <utkarsh2102> yep, though I'd call this as one proposed solution.
14:07:04 <codehelp> IIRC extra storage can be arranged along the lines of the extra ELTS repositories - buxy?
14:07:05 <utkarsh2102> once we start to try it and spend a couple of weeks and think that this is working out perfectly, we could convert this to a "policy" but yes, a rough one would be to use git as much as possible,
14:07:40 <codehelp> (for the large pkgs that don't have everything in git - plus for packages that just take ages to build from git)
14:07:58 <bunk> What should actually be in git?
14:08:02 <bunk> Sources?
14:08:04 <bunk> Binaries?
14:08:13 <utkarsh2102> at least the history of `debian/`
14:08:27 * codehelp would prefer not binaries & sources when it is practical to do so?
14:08:40 <utkarsh2102> bunk: what we generally use salsa for. To maintain the history/commits or what changed over time.
14:08:44 <bunk> sources in git would be pretty useless for the "easier rollback for clients" usecase
14:08:45 <el_cubano> Probably upstream sources as well.  From time to time we put new upstream versions into LTS/ELTS and it would be helpful to have the upstream part as well.
14:08:56 <codehelp> binaries need that extra storage
14:08:59 <ta> shouldn't it be used to rollback broken packages?
14:09:02 <el_cubano> Especially for upstream versions that are not represented in the current stable release.
14:09:10 <ta> than binaries are needed ...
14:09:41 <codehelp> definitely need to keep the orig.tar to cover for when the suite disappears from the Debian mirrors
14:09:44 <utkarsh2102> if we're looking for a solution for "customers" then we ought to have something like snapshot.freexian.com or similar.
14:09:59 <utkarsh2102> but if it's just for now (eg: codehelp needed something for systemd), then git should do.
14:10:17 <utkarsh2102> s/now/us^
14:10:26 <buxy> we keep mixing all those discussions, ideally we want both, we want clear history of source changes in git, and we want a snapshot service
14:10:42 <utkarsh2102> yes!
14:11:12 <bunk> One problem with "clear history of source changes in git" in Debian is that whatever is in git might differ from what is actually used in the source package.
14:11:38 <buxy> the snapshot service requires sysadmin/development/investigation time that I don't have, one of the solution was suggested by Chris, we could first see if DSA would be willing to host snapshots for ELTS, it's pretty limited in size
14:12:47 <utkarsh2102> but here's the problem: snapshots tracks packages in the archive. If DSA were to handle ELTS uploads, then they'd need to somehow track our private repositories as well.
14:12:48 <buxy> but the git part is easy to do without requiring that kind of work and thus it would be nice to make progress here
14:12:58 <utkarsh2102> I mean, not entirely private, but you get the point. :)
14:13:26 <buxy> yeah, I would have to setup the rsync service at least
14:13:37 <utkarsh2102> right! :)
14:14:15 <buxy> I'm also not a big fan of asking DSA to host something that's not on debian.org per se
14:14:35 <codehelp> so get what we can into git, including ensuring the current Debian src is in git before making the first (E)LTS upload
14:14:59 <utkarsh2102> I agree^
14:15:13 <el_cubano> That sounds like a good first step
14:15:27 <ta> ELTS and LTS?
14:15:40 <utkarsh2102> we can use salsa-ci.yml to generate binaries as artifacts. And it would be there, too, as "job artifacts".
14:15:56 <jeremiah> If I'm not mistaken, there is already work being done to add LTS packages to git (by Anton).
14:15:58 <utkarsh2102> it just needs tweaking of salsa-ci.yml file.
14:16:36 <codehelp> I've a blog entry & docs on how to get Salsa working for contrib & non-free packages
14:16:47 <bwh> utkarsh2102: Assuming the packages can actually be built in CI, which is not true for large packages
14:16:48 <utkarsh2102> \o/
14:16:57 <jeremiah> Do those artifacts hang around? Or does Salsa delete those after a while?
14:17:07 <utkarsh2102> bwh: correct, some exceptions would always be there.
14:17:12 <bwh> (e.g. linux would probably take over 10 hours to build with the current shared workers)
14:17:18 <codehelp> jeremiah: by default, they hand around "too long" - but only the latest build
14:17:20 <utkarsh2102> jeremiah: after a month or two, there are gone, unfortunately.
14:17:43 <utkarsh2102> unless, salsa admins do us a favor and re-enable that. And it can then stay forever, I think.
14:17:49 <jeremiah> Ah. So not a sneaky "back door" storage system.
14:17:55 <utkarsh2102> heh.
14:17:55 <codehelp> only for "latest"
14:17:59 <buxy> the expiration time is configurable but we don't want to waste resources either
14:18:08 <utkarsh2102> right!
14:19:24 <buxy> At some point, we could look into having Freexian provide a dedicated gitlab runner with increased limits if that turns out to be useful.
14:19:53 <utkarsh2102> yep, esp. when we have gitlab package in the archive, which is pretty usable, too! \o/
14:20:24 <jeremiah> What about dgit? I think that was mentioned as a possible solution in the past.
14:20:37 <codehelp> that's a change in workflow
14:22:04 <jeremiah> It appears to me that the consensus seems to favor using git when feasible and continuing to look for a long term solution to other storage.
14:22:10 <buxy> can we expand on "so get what we can into git, including ensuring the current Debian src is in git before making the first (E)LTS upload" ?
14:22:29 <buxy> Do we want to fork the existing repository? or only if it uses the gbp workflow?
14:22:43 <buxy> and in other cases we just do a single "gbp import-dsc"?
14:23:11 <utkarsh2102> I prefer `gbp import-dsc`
14:23:25 <codehelp> If the project is already in Salsa, that covers what I was thinking of "ensure Debian src is in git"
14:23:29 <utkarsh2102> not all repositories can be forxed since a lot of them have no history for stretch.
14:23:37 <ta> I think it is enough to just put our changes into our repository
14:23:38 <el_cubano> That's also my preferred approach (gbp import-dsc)
14:23:41 <utkarsh2102> s/stretch/LTS or ELTS/g
14:24:27 <utkarsh2102> so, I'd propose: if repo exists under our umbrella, clone that and push changes there. Otherwise, `gbp import-dsc` it and create a new repo and push that under our namespace.
14:24:31 <utkarsh2102> does that make sense?
14:24:51 <el_cubano> Should this be something that is noted in (d|e)la-needed.txt?
14:25:06 <utkarsh2102> maybe in the README?
14:25:14 <utkarsh2102> once we have an agreement or something
14:26:34 <jeremiah> This has evolved as a nice transition into our next topic, how do we _enforce_ this policy;
14:26:55 <jeremiah> #topic - Enforce git as DVCS in ELTS
14:27:11 <utkarsh2102> "mutual understanding and co-operation" would be my goto answer, hehe :P
14:27:14 <el_cubano> I referred to (d|e)la-needed.txt because the time/place of claiming a package seems like the best place to alert the developer to the existence of a Git repo where the work ought to take place
14:27:40 <utkarsh2102> sure, we could do either or both. :)
14:29:16 <buxy> It's hard to enforce at this point given that the upload always goes throuh a source package upload.
14:29:35 <jeremiah> This seems to have evolved then into a policy recommendation along the lines of "get what we can into git, including ensuring the current Debian src is in git before making the first (E)LTS upload and follow the documentation in the README and (d|e)la-needed.txt"
14:30:07 <utkarsh2102> pretty much sums it up
14:30:11 <utkarsh2102> and nicely, hehe :D
14:30:23 <buxy> So it's more education of contributors and some regular checks to remind people that have not done so that can help. But at the same time, there are exceptions...
14:30:37 <codehelp> which can be documented somewhere
14:31:12 <utkarsh2102> I can take care of documentation, if that helps, jeremiah?
14:31:17 <utkarsh2102> for the README^
14:31:27 <jeremiah> #action Utkarsh document policy recommendation.
14:32:48 <jeremiah> Thanks Utkarsh! I'll also summarize this discussion in the issue tracker.
14:33:06 <utkarsh2102> awesome!
14:33:21 <jeremiah> #topic New Tryton project proposals
14:33:47 <jeremiah> There are two new proposals for a funded project for Tryton
14:34:06 <jeremiah> If the LTS team can review https://salsa.debian.org/freexian-team/project-funding/-/tree/master/proposed
14:34:23 <jeremiah> Then we can organize a poll, like we did last time, to approve or reject.
14:34:33 <buxy> What do we use as branch names? debian/$CODENAME as recommended by DEP-14?
14:35:28 <utkarsh2102> `gbp import-dsc` creates master, pristine-tar, and upstream. I use them as-is.
14:35:54 <buxy> well we will have to maintain stretch and jessie in parallel
14:36:05 <utkarsh2102> so master is what I use but I don't have problem changing it to debian/{stretch,jessie}
14:36:20 <jeremiah> I find DEP-14 easiest to use IMHO
14:36:25 <ta> --debian-branch=debian/strech
14:36:26 <utkarsh2102> wait a sec
14:36:52 <utkarsh2102> buxy: how are you intending to keep the history for a package for both stretch and jessie, in the same repository?
14:37:02 <buxy> someone should submit a project to fund to harmonize the default behaviour of gbp with dep-14
14:37:14 <buxy> I would approve it immediately ;-)
14:37:23 <utkarsh2102> heh
14:37:43 <buxy> utkarsh2102: yes, why would that be strange?
14:37:52 <codehelp> could be different upstream versions
14:38:09 <buxy> and?
14:38:33 <utkarsh2102> what would upstream branch contain then?
14:38:36 <codehelp> so upstream/{suite} ?
14:39:00 <jeremiah> You can tag the upstream branch
14:39:15 <codehelp> not sure how that's going to work in Salsa
14:39:23 <utkarsh2102> that does mean a new entry in debian/gbp.conf.
14:39:26 <utkarsh2102> codehelp^
14:39:49 <buxy> DEP-14 says upstream/latest by defaut if you import them all in the right order, but upstream/1.2.x for example if you need to create a branch for old stable releases
14:39:54 <utkarsh2102> two different d/gbp.conf for both the d/{stretch,jessie} branches.
14:41:07 <utkarsh2102> buxy: I was hoping we would use https://salsa.debian.org/lts-team for LTS packages and https://salsa.debian.org/elts-team (or equivalent) for ELTS pacakges. :)
14:41:41 <buxy> utkarsh2102: that's useless overhead IMO
14:42:19 <utkarsh2102> most of what's present at https://salsa.debian.org/lts-team/packages/ has "master" atm, I think
14:42:45 <codehelp> probably due to the current gbp default
14:42:52 <utkarsh2102> buxy: I agree, I don't mind adapting to this new way
14:43:19 <utkarsh2102> but yes, I like the default way - have been used to it and it's much more easy for me
14:43:44 <buxy> hence the need of this discussion to define a policy before doing different things each on our side
14:44:06 <utkarsh2102> hehe, yep
14:44:49 <codehelp> utkarsh2102: I'm not sure if the Salsa "extract-source" job using origtargz is going to like upstream/{suite} - that part doesn't respect debian/gbp.conf settings.
14:45:22 <codehelp> so it depends on how much reliance is wanted on the CI when the objective is actually just to have it git
14:45:23 <utkarsh2102> OH YEAH!
14:45:34 <buxy> codehelp: doesn't it rely on the corresponding upstream tag? it shouldn't matter where the tag points to
14:45:52 <utkarsh2102> does it?
14:46:08 * codehelp has had problems working out just what is relies on - it does get confused on some of the packages I've been looking at.
14:46:25 <codehelp> poke it and see is probably the initial answer
14:46:57 <buxy> at least in standard gbp usage, it's the upstream tag that is the reference used to checkout the upstream sources
14:47:15 <utkarsh2102> I'mma try this out today!
14:47:22 <utkarsh2102> this discussion has made me really curious
14:47:27 <codehelp> maybe another funding proposal should look at smoothing out some of the Salsa pipeline scripting ...
14:48:01 <bwh> I've been looking at that quite a bit lately...
14:48:06 <utkarsh2102> salsa admins really like things their way, so do run that by them if this becomes a thing.
14:48:11 <jeremiah> There's also a proposal for 'tag2upload' if you're interested in wading into those waters.
14:48:22 * codehelp runs away
14:48:34 <utkarsh2102> lol
14:49:06 <buxy> From day 1, I have been hoping that people like you would jump to try to do that kind of infra improvement and get it funded through Freexian!
14:49:16 <buxy> (you in plural form)
14:49:31 <el_cubano> vous?
14:49:38 <el_cubano> lol, in Spanish we have "ustedes" for that :-)
14:49:41 <utkarsh2102> "y'all"
14:49:42 <codehelp> it's really messy - the utopia of all packages building in the same way is a *long* way in the distance
14:49:43 <utkarsh2102> yeah!
14:49:52 <jeremiah> youse guys
14:49:58 <utkarsh2102> hehe
14:50:00 <el_cubano> utkarsh2102: That's singular.  The plural is "all y'all".  Just ask someone from Texas :-p
14:50:21 <utkarsh2102> has all my life been a life? :o
14:50:33 <utkarsh2102> lie*, d'oh
14:50:35 * el_cubano is sorry to be the one to have to say it, but "yes"
14:50:42 <codehelp> anyways, are we on to Tryton yet?
14:50:58 <buxy> Let's move on, right.
14:51:06 <jeremiah> Okay, right. :)
14:51:17 <jeremiah> The plan is to have a poll for next week
14:51:22 <utkarsh2102> if tryton helps Freexian do better, then I am huge +1. \o/
14:51:38 <el_cubano> codehelp: Good point about the ideal being a long way off.  But the best way to arrive there is by trying to get there, seeing what works best, and then repeating that as often as possible.
14:52:00 <codehelp> el_cubano: yes, one step at a time.
14:52:26 <el_cubano> Right.  This is definitely an instance where an iterative approach seems like the absolute best possible approach.
14:52:27 * codehelp is still at the "swearing at Salsa as ccache breaks SCons again" stage
14:52:33 <el_cubano> lol
14:53:58 <jeremiah> I encourage everyone to have a quick look at the Tryton proposals, they seem quite straight forward.
14:54:15 <jeremiah> I've informed the submitter, Mathias, that there may be questions in the issues I've created
14:54:42 * codehelp would tend to gunicorn rather than uwsgi for the first one but that's implementation detail.
14:55:46 <jeremiah> codehelp: Would you be willing to be reviewer if the proposals are accepted?
14:56:14 <codehelp> yes, I can do that. I've been playing with Tryton for the freexian payment support already.
14:56:18 <utkarsh2102> buxy and codehelp do appears to be ideal reviewers, imo. :D
14:56:21 <buxy> utkarsh2102: the only thing that helps Freexian in those two projects at this point, is the simplified setup of the uwsgi/nginx part, the modules we use are already packaged, but then it's nice to make tryton more generally useful for everybody, few enterprise are using a free software ERP, and if the good availability in Debian can convince a few more to use it, it's good for the ecosystem IMO
14:56:34 <utkarsh2102> s/appears/appear/g
14:57:23 <jeremiah> I can state that when I worked with a Free Software company that was looking for an ERP, they found nothing usable despite trying a couple and even paying for support.
14:57:32 <buxy> utkarsh2102: yeah, I was wondering if codehelp would be willing to do that :)
14:57:56 <utkarsh2102> oh sure. But I was worried with the low popcon score. There are many alternatives and I was worried that we'd fund for nothing. But that's not the case here so all good! \o/
14:57:59 <jeremiah> There is a real need for a usable, fully functional ERP
14:58:10 <utkarsh2102> oh, TIL!^
14:58:25 <codehelp> the issue with a fully operational Tryton web service is it's likely to need https as well and that's not something to do in packaging scripts
14:59:08 <jeremiah> But that seems like a quick certbot call away?
14:59:28 <jeremiah> Or are you thinking that one should be able to simply install Tryton and be up and running?
14:59:36 <codehelp> dehydrated et al, yes, more that it needs some understanding of the ongoing requirements of https
15:00:02 <codehelp> and the fact that LetsEncrypt needs a public IP, not a local test VM on a NAT connection
15:00:41 <utkarsh2102> would've been a mess if it were any other way, I feel^
15:01:02 <codehelp> I'd tend to providing an example webserver config with example of what it would look like on a public host
15:01:41 <buxy> it could start by using a standard path for the certificate, have that a symlink pointing to the snakeoil certificate and then replace those links once you switched to LetsEncrypt
15:02:21 <bwh> codehelp: A public IP is not required; I get certificates for internal machines using the dns-01 challenge method
15:02:56 <codehelp> ah, ok. Thanks.
15:03:33 <bwh> (but this is dependent on the API of my DNS provider, so it's even less packageable)
15:03:55 <jeremiah> Excellent. If there's no further discussion on Tryton and/or ELTS git repos, we can move to AoB?
15:04:10 <utkarsh2102> I think, yes
15:04:18 <jeremiah> #topic - Any other business
15:05:06 <utkarsh2102> I got one - please complete the Freexian survey if you're like me and haven't. :)
15:05:57 <jeremiah> Yes, good point.
15:06:12 <utkarsh2102> (but it's at the top of my list of things to do, so I should be completing that shortly.)
15:06:23 <jeremiah> It only takes a minute or two.
15:07:30 <utkarsh2102> yeah, but I wanted to be thorough with the "Freexian mission statement" thread before I'd proceed to the next stage of the survey. :)
15:09:09 <jeremiah> We've run a bit over time.
15:09:17 <buxy> For the tryton proposals, do we ack a single one and wait the outcome before considering the other?
15:09:26 <jeremiah> Good question.
15:10:48 <codehelp> the changes to the tryton-server packaging probably won't affect the packaging of modules
15:11:43 <buxy> Maybe you can get this answered with the vote/poll and a separate question? Yeah the two projects are relatively independant.
15:11:57 <codehelp> are there people available to do both at the same time?
15:12:44 <buxy> codehelp: in both case it's Matthias that is going to do the work, he won't do them at the same time
15:13:03 <codehelp> then I think we ack both and let him decide as the work proceeds
15:13:06 <buxy> but it's about us: do we want to validate both projects at once or do them one after the other
15:13:55 <jeremiah> Might be better, but a little more work, to do one after the other.
15:14:52 <buxy> Anyway, I'm happy to leave that to your call.
15:16:11 <jeremiah> Okay. In any case, I'll consolidate the two issues. I ought to have left the MR up longer and used that for questions as buxy noted, this is what we did with the previous proposal.
15:16:55 <jeremiah> I'm writing a checklist for funded projects process so I don't have to try and excavate in Salsa / Gitlab.
15:17:42 <jeremiah> In the current phase the process calls for about one week of questions and feedback, then a poll.
15:18:42 <jeremiah> Anything else we should discuss?
15:20:03 <jeremiah> I will end the meeting then. Thank you.
15:20:13 <jeremiah> #endmeeting