13:59:04 <el_cubano> #startmeeting
13:59:04 <MeetBot> Meeting started Thu Jul 27 13:59:04 2023 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:59:12 <el_cubano> Hello everyone!
13:59:14 <tobi_m> anf my mate is cold but with Ginger
13:59:26 <tobi_m> o/
13:59:31 <bhe[m]> Hello
13:59:35 <rbalint> hi!
13:59:37 <el_cubano> I know that many of you have already announced yoursleves, but please go ahead and say 'hi' again for the meeting record
13:59:44 <spwhitton> hello!
13:59:44 <jochensp> hi
13:59:45 <guilhem> o/
13:59:47 <apo> hi
13:59:48 <rbalint> hi
13:59:58 <santiago> hi
14:00:00 <tobi_m> hi
14:00:15 <tumbleweed> hi
14:00:18 <lamby> hi
14:00:23 <bwh> hi
14:00:57 <bunk> hi
14:01:24 <pochu[m]> hi
14:02:36 <el_cubano> As always, the meeting agenda is located here: https://pad.riseup.net/p/lts-meeting-agenda
14:03:02 <el_cubano> There are only a few items, so it is possible that today's meeting will be somewhat short.
14:03:22 <petn-randall> hi
14:03:35 <el_cubano> OK. I am going to turn things over to petn-randall , who would like to discuss gbp.conf and Samba-related matters
14:03:38 <el_cubano> petn-randall: Please go ahead
14:03:45 <el_cubano> #topic gbp.conf
14:03:45 <petn-randall> Thanks
14:03:45 <h01ger> o/
14:05:01 <rouca> hi
14:05:05 <utkarsh2102> my client stopped working for a minute there, anyway, hi again! \o
14:05:09 <petn-randall> So I think I brought it up a few meetings back, but the gist is that gbp importing packages of several releases will cause the "upstream" branch to flip-flop between upstream releases, which can be confusing when debugging things.
14:05:44 <petn-randall> So I propose to set in debian/gbp.conf the "upstream" branch to a per-release branch to make things easier.
14:05:53 <rouca> petn-randall: dep 14 said to use upstream/1.x branch and so on
14:06:00 <ta> (hi, sorry for being a bit late)
14:06:27 <pochu[m]> we could also use upstream/buster et al
14:06:37 <rouca> petn-randall: it does not work however if downstream use an upstream branch (git fail saying upstream exists)
14:06:54 <tobi_m> this happens when importing a new upstream release?
14:07:05 <petn-randall> As (IIRC) beuc pointed out, the current setup doesn't break anything, but it's a bit surprising to be working on v1.2.3, and find v.2.4.5 in the upstream branch, because someone else worked on a different release after you.
14:07:05 <rouca> tobi_m: yes this happen
14:07:25 <tumbleweed> tobi_m: a new upstream point release for an older series, when the upstream branch has already moved on
14:08:57 <petn-randall> rouca: Can you elaborate?
14:08:59 <lamby> I would +1 the adoption of upstream/$release to avoid this; I've been using this for personal packages for this reason.
14:09:27 <tobi_m> once a new upstream version is importet, the upstream branch is technically not needed for working on the debian/x branches. so maybe not pushing upstream branches might work too?
14:09:40 <spwhitton> tobi_m: I resorted to that with nsis.
14:09:58 <spwhitton> upstream/$release seems simplest.
14:10:07 <jochensp> +1 for upstream/$release
14:10:15 <petn-randall> I don't recall the exact package I was working on, but it broke my expectation and sent me down a rabbit hole for while before I noticed it. And I'd like to keep the principle of least surprise for all the potential LTS newcomers.
14:10:21 <tobi_m> but i see that it might be a easier to understand workflow
14:10:22 <el_cubano> +1 for upstream/$release
14:10:31 <rbalint> lamby, spwhitton it is the simplest, but it is not in dep-14 :-(
14:10:43 <spwhitton> rbalint: not sure that matters?
14:10:44 <el_cubano> petn-randall: I know that I did this (unwittingly) with apache2. Perhaps that was the one you were working on.
14:10:56 <petn-randall> Yeah, that was it; apache2.
14:11:52 <petn-randall> +1 for upstream/$release
14:11:56 <rbalint> spwhitton: maybe we could add upstream/$release recommendation to dep14
14:12:00 <el_cubano> rbalint: Would there be a DEP-14 conforming solution that allows for multiple upstream branches?
14:12:09 <tobi_m> though I'd suggest to only use upstream/release if a new upstream version is needed.
14:12:10 <spwhitton> rbalint: yeah.
14:12:31 <santiago> not pushing the upstream branch wouldn't impact lts-team/pipeline?
14:12:54 <petn-randall> Not pushing is hard to prevent, as the usual workflow is a `gbp push` at the end.
14:13:01 <el_cubano> tobi_m: This tends to be common when we do LTS (buster) and ELTS (stretch and sometimes jessie) work in the same repo
14:13:05 <rouca> petn-randall: git does not like to add a upstream/something branch when it exist an upstream branch
14:13:10 <petn-randall> And I'd rather not trade one pitfall for another.
14:13:34 <tobi_m> rouca: good point
14:13:43 <rbalint> el_cubano: dep14 suggests upstream/1.2.x style branch names, when there are older branches in addition to upstream/latest and I followed that so far
14:14:22 <petn-randall> rouca: Ah! So there'd be extra renaming work when changing over.
14:14:44 <rouca> petn-randall: if we get in sync with existing debian I do not like renaming
14:14:49 <el_cubano> rbalint: I see. I wasn't understanding clearly.
14:15:18 <rouca> I think we should ask some guidance on dep14 (dep14 is good but does not take care of legacy)
14:15:23 <el_cubano> It seems like upstream/x.y.z style of naming would be best for instances when the same upstream version exists in more than one Debian release (which is a lot of the time)
14:15:37 <tumbleweed> yeah
14:15:50 <rouca> el_cubano: yeah dep14 nming is good
14:16:16 <spwhitton> good point.
14:16:21 <rouca> A way to work arround is the double remote for existing branch
14:17:15 <pochu> the X team uses upstream-$release
14:17:24 <rbalint> having an 'upstream' branch indeed prevents having upstream/1.2.x and probably we should ask the maintainers to move to 'upstream/latest' in git repo if there is a need for upstream/1.2.x
14:17:24 <petn-randall> rouca: I'm not sure I understand. You're against getting in sync with Debian? I'm not sure what current practice is in Debian; I think there's no concensus on this.
14:18:21 <rouca> petn-randall: no I will give you example. salsa.debian.org/somestuff have an upstream branch
14:18:47 <el_cubano> From our perspective, it would be good to be able to fork from maintainer repos when they are available (and the maintainers are willing to have the work co-exist). However, it isn't strictly necessary.
14:18:58 <rouca> we clone the repo as salsa.debian.org/lts-team/package/somestuff
14:19:23 <rbalint> i think upstream/1.2.x schemed would would work anywhere where upstream/buster would work, so following dep14 would be a plus for upstream/1.2.x
14:19:23 <el_cubano> Is it possible that in a repo where the maintainer using only 'upstream' as the upstream branch that we could simply add other upstream/x.y.z branches (only as needed)?
14:19:28 <rouca> if think it is in this case a bad idea to remove the upstream branch on salsa.debian.org/lts-team/package/somestuff  in order to ccreate a upstream/1.X branch
14:19:45 <tumbleweed> how does having upstream prevent upstream/1.2.x from existing?
14:19:48 <rouca> el_cubano: no it is not possible if upstream branch exist
14:19:49 <lamby> el_cubano: You can't add "foo/bar" if "foo" exists.
14:20:10 <rouca> lamby: technically it is possible to workarround
14:20:28 <petn-randall> Did the packaging workflow change? My last news is that we start a fresh packaging repo, but I admit I missed last meeting due to miscommunication.
14:20:37 <rouca> by creating an empty salsa.debian.org/lts-team/package/somestuff  and add a remote salsamain thant point to  salsa.debian.org/somestuff
14:20:57 <tobi_m> forking an existing repo is preferred
14:21:00 <tumbleweed> ah, git doesn't permit it, right
14:21:01 <rouca> in this case it will create a branch salsamain/upstream instrad of upstream
14:21:29 <pochu> we can rename the branch in our fork, or we can just use a dash instead of a slash
14:21:35 <tobi_m> (i still need to follow up on that, we had some discussion there already)
14:22:26 <rouca> pochu: yes we could rename but or use a dash but the problem will be the same for stable security update and lts
14:22:29 <tobi_m> I'd avoid renaming and eg go for a dash
14:22:38 <el_cubano> rouca: I was not aware of the existence of branch 'foo' preventing the creation of branch 'foo/bar'
14:22:38 <rouca> I believe we should clarify the dep14
14:23:04 <el_cubano> pochu: That's what I was about to suggest
14:23:36 <tumbleweed> this is a good argument for upstream/latest by default
14:23:51 <santiago> indeed!
14:23:56 <rouca> yes for newer repo
14:24:06 <rouca> upstream/lastest is the best
14:24:33 <el_cubano> petn-randall: rouca: could the two of you discuss this and write up a summary to send to debian-lts@l.d.o? We can let the discussion take place there, and when we arrive at a consensus we can come up with a plan of action for new repos and for how to deal with already existing repos.
14:24:54 <rouca> el_cubano: ok let go
14:25:39 <el_cubano> petn-randall: Does that sound good to you?
14:25:52 <petn-randall> Sounds good!
14:26:00 <tobi_m> rouca petn-randall lets align that with my forking propsal as well
14:26:20 <tobi_m> i see some overlap here
14:26:21 <petn-randall> tobi_m: Where can I read up on that?
14:26:27 <santiago> tobi_m, what is your forking proposal?
14:27:06 <el_cubano> #action petn-randall, rouca to discuss branching and how to implement (including gbp.conf for standardization) and then post proposal to debian-lts@l.d.o
14:27:07 <tobi_m> im crurrently afk (on mobile) so i dont have the link right now
14:27:30 <tobi_m> but it is on the mailling list somewhere
14:28:02 <el_cubano> I think that we can move on to the Samba discussion and that those who are interested in the branching/forking/gbp.conf proposal can discuss it on the mailing list (otherwise we will be here all day :-)
14:28:04 <petn-randall> ACK
14:28:23 <el_cubano> #topic Samba (EOL plus info on customer setups)
14:28:28 <el_cubano> petn-randall: You are up again
14:28:33 <tobi_m> https://pad.riseup.net/p/lts-forking-a-repo-keep
14:29:52 <el_cubano> #info Tobi's proposal for forking repos: https://pad.riseup.net/p/lts-forking-a-repo-keep
14:30:22 <petn-randall> So I got a mail today from jmm/mjt/carnil that they are effectively EOLing samba in buster. The question here is if we also drop support for it in (E)LTS, or if we (freexian) wants to take over support there, as I'm guessing it's due to lack of manpower.
14:30:37 <petn-randall> Err, bullseye (11)
14:30:45 <petn-randall> too many b's
14:31:59 <el_cubano> Is their plan to drop support for samba in bullseye altogether?
14:32:13 <petn-randall> Since samba has a high popcon score with Frexian's customers, I'm not sure they'd be too happy about it.
14:32:16 <petn-randall> el_cubano: yes.
14:32:18 <apo> We should follow Moritz' suggestion and only support certain features of samba. Everything else is EOL. If customers need everything samba has to offer we could try to backport a newer release
14:32:39 <rouca> backport if possible seems a good suggestion
14:33:06 <el_cubano> I would agree with the backport solution.
14:33:12 <ta> aren't the changes made to actual versions of samba too extensive to be able to backport patches?
14:33:27 <apo> Moritz wrote:
14:33:29 <apo> Create a page on wiki.debian.org which strongly advises to move to bookworm
14:33:39 <el_cubano> ta: In the current state and old versions of Samba that we have, yes sometimes they are impossible
14:33:41 <apo> Create a page on wiki.debian.org which strongly advises to move to bookworm
14:33:41 <apo> or bullseye + samba from backports
14:33:54 <apo> List the use cases which are still supported with a caveat (but e.g. explicitly
14:33:56 <petn-randall> So their current plan is to only support samba in stable, recommend upgrading to stable, and only support oldstable through oldstable-backports.
14:33:57 <apo> tells people not to use it to run an Active Directory domain controller)
14:34:10 <apo> Triage remaining issues based on that policy and ship updates for the remaining
14:34:10 <el_cubano> petn-randall: If you could share the mail you received (directly with me), that would be helpful
14:34:17 <ta> el_cubano: so in the end we would blacklist almost all features as well?
14:34:18 <apo> use cases.
14:34:54 <rouca> what are the use case of client ?
14:34:58 <tobi_m> what's the impact on our customers?
14:35:07 <el_cubano> I have previously worked on the Samba packages (plus reviewed petn-randall's recent work on it) and I have some thoughts about how we would handle it from the perspective of LTS/ELTS
14:35:33 <el_cubano> rouca: I don't think we have any significant data on that.
14:35:35 <petn-randall> el_cubano: Shall I send it to your @d.o mail?
14:35:42 <el_cubano> petn-randall: Sure, that's perfect
14:36:04 <el_cubano> tobi_m: That is difficult to assess without knowing the various configurations.
14:36:52 <el_cubano> I will take an action to talk more in detail with petn-randall, review the proposal from the seteam, and look at some internal data that I have access to, and then I'll come up with a proposal
14:37:10 <rouca> note that backport will be limited by need of python3.6
14:37:30 <el_cubano> #action el_cubano to talk with petn-randall, review the proposal from the seteam, and look at some internal data, then draft a proposal
14:37:37 <el_cubano> rouca: noted
14:37:43 <rouca> and GnuTLS 3.4.7
14:38:03 <el_cubano> #info samba backport could be limited by python3.6, gnutls, and perhaps other build-deps/deps
14:38:06 <petn-randall> Sounds good to me. AFAICS it boils down to either taking over security support for oldstable and older, or drop support.
14:38:26 <el_cubano> OK. Any other comments on this particular issue of Samba?
14:38:35 <jochensp> el_cubano: for stretch I backported the recent fix for domain controllers, the fix was easy but still need to test
14:39:07 <petn-randall> I've made some progress for that, it's about 70% ready.
14:39:20 <jochensp> ..so will delay testing till you have a proposal
14:40:18 <el_cubano> jochensp: Ack
14:40:37 <petn-randall> I've been working on a functional test harness for samba (and potentially other packages interacting over the network with other OSes), the hard work was actually to build working images for buster.
14:41:21 <el_cubano> And the basic idea I am considering proposing would still benefit from that.
14:41:28 <petn-randall> Since the bug jochensp isn't covered by unit tests, it's an undocumented change in behaviour of Windows 10/11 with the latest monthy patch.
14:41:31 <el_cubano> So, that's definitely beneficial to have
14:41:34 <pochu> petn-randall: that sounds pretty useful
14:41:43 <el_cubano> OK. So moving one
14:41:47 <rouca> yes could be used for docker
14:41:50 <el_cubano> s/one/on/
14:42:01 <el_cubano> #topic Dealing with stale hours
14:42:03 <jochensp> petn-randall: buster images are easy with debvm
14:42:20 <petn-randall> Yup, it's a tool to build Debian and Windows VMs, and then provision them.
14:42:54 <el_cubano> A couple of months ago I noticed that we had some contributors who had been allocated hours but who had gone dormant. I have gone through and returned the hours of those dormant contributors to the pool and I have marked them as inactive.
14:43:32 <el_cubano> I have a TODO item to develop a policy for when hours will be automatically returned (so that we can implement it with tooling as part of the monthly dispatch of hours)
14:44:06 <el_cubano> If I took hours from you and you meant to stay active, please make sure to mark yourself active again in contributors.yml by the end of the month so that you receive more hours in the dispatch at the start of August
14:44:36 <el_cubano> Also, if you know that you will not be able to work the hours that you have been allocated, please save me the trouble of having to chase you down and return yours hours
14:45:24 <petn-randall> Looks sensible to me.
14:46:18 <santiago> ack!
14:47:08 <rouca> ack
14:47:12 <petn-randall> el_cubano: I think it would also be a good idea to send those contributors a mail to notify them about being set as inactive.
14:47:34 <el_cubano> petn-randall: I did that already (and it would be part of any automated solution I come up with)
14:48:08 <petn-randall> great
14:48:34 <el_cubano> So, with the additional hours that I was able to return to the pool, we will hopefully get closer to allocating hours to everyone closer to their 'max' hours
14:49:12 <el_cubano> Last month several contributors received quite a bit less than they would have liked (based on their 'max') and there is very clearly more than enough work to go around.
14:50:00 <el_cubano> Keep in mind that we are adding new contributors as well, so the pool will have to stretch further. That also means it would be good only request a quantity of hours you are reasonably confident that you can exhaust during the course of the month
14:50:46 <el_cubano> Naturally, we also know that things come up and if you don't manage to use them all up one month, it's not a big deal. At the moment I am more concerned about people carrying 10+ hours over month after month
14:52:03 <el_cubano> OK. I don't have anything else about hours. So unless there are any questions about this, let's move on to the last item.
14:52:09 <el_cubano> #topic AOB
14:52:17 <petn-randall> We skipped the 3 point
14:52:26 <petn-randall> 3rd
14:52:43 <el_cubano> petn-randall: I sort of thought we covered that with the EOL discussion
14:52:56 <el_cubano> #topic Samba, part deux
14:53:16 <el_cubano> petn-randall: Sorry about that. Please go ahead
14:53:37 <petn-randall> Assuming we're still supporting samba with the discussion from #2, it would be great to have the config our customers run, so I can implement those setups in the tests.
14:54:54 <petn-randall> Since there's a plethora of possible samba setups it would be good to concentrate on the handful that are actually used/needed by our customers. Is there a way to contact them and ask them for the config?
14:55:49 <el_cubano> We have a technical point of contact for those who are paying sponsors. However, I would probably start with a call debian-lts@l.d.o
14:55:59 <el_cubano> That might give a reasonably good cross-section of configurations
14:56:02 <tumbleweed> we have quite a number of customers with samba in their lists
14:56:20 <el_cubano> If after that we feel like there is a gap, we can reach out to paying sponsor customers individually
14:56:27 <utkarsh2102> true
14:56:32 <petn-randall> Alright, sounds good.
14:57:05 <rouca> agreed may be some will have special interest and can come with special need after a mail to lts@d.o
14:57:06 <petn-randall> #action petn-randall sends an mail to debian-lts@, asking for user's samba config.
14:58:05 <el_cubano> that sounds good
14:58:17 <el_cubano> OK, we are at time, so back to AOB
14:58:18 <petn-randall> Alright, I'm done with this topic.
14:58:21 <el_cubano> #topic AOB
14:58:38 <el_cubano> Does anybody have anything for AOB?
14:58:38 <utkarsh2102> I've got one small thing
14:58:42 <el_cubano> Go ahead
14:58:54 <utkarsh2102> thanks
14:59:12 <rouca> I have also another thing about docker
14:59:14 <petn-randall> Is anyone member of the libvirt packaging and can approve my request on https://salsa.debian.org/libvirt-team/?
14:59:40 <rouca> packagee is ready but need testing
14:59:48 <utkarsh2102> so there was a regression reported in ckeditor a while ago, I did the update and got one person reporting this regression. The smoke test was really fine so it could be an edge case or something.
15:00:00 <petn-randall> I have packaged rhsrvany (ITP #996850) in the process of building the test suite for samba.
15:00:11 <rouca> utkarsh2102: could you send me a mail
15:00:13 <utkarsh2102> I am a bit too swamped lately to be doing LTS/ELTS actively but I do intend to start doing it from next month onward.
15:00:28 <utkarsh2102> but untill that happens, could someone take a look at ckeditor's regression, please?
15:00:30 <rouca> utkarsh2102: I am maint of ckeditor forget to answer I supoe
15:00:51 <utkarsh2102> rouca: oh lovely, many thanks! I'll send the mail and copy you.
15:03:30 <utkarsh2102> just to explicit, my AOB is done^ :)
15:03:41 <utkarsh2102> to be*, d'oh
15:05:45 <rouca> about docker if omebdy is fluent in doing clustered docker
15:05:51 <el_cubano> OK. The only other thing I wanted to bring up is a reminder that Raphael and Sophie are on vacation through the end of next week
15:06:12 <el_cubano> Payment for invoices submitted at the start of August will be delayed until they return
15:08:06 <santiago> rouca, I am maybe not the most fluent on doing d-in-d, but I can add reviewing it to my ToDo list
15:08:31 <el_cubano> OK. Anyone else?
15:09:17 <petn-randall> AFAICS nobody from libvirt team is present here, so what would be the best way to proceed?
15:10:04 <el_cubano> petn-randall: I would recommend mailing the maintainers/uploaders directly
15:10:14 <petn-randall> will do, thanks
15:10:20 <utkarsh2102> petn-randall: mail Guido Gunther
15:10:32 <petn-randall> https://wiki.debian.org/Teams/DebianLibvirtTeam looks horribly out of date, might poke them about that, too.
15:10:35 <utkarsh2102> they should be able to help you
15:10:42 <petn-randall> cheers
15:10:53 <el_cubano> Alright, thanks to everyone for your hard work!
15:10:58 <el_cubano> Have a great day.
15:11:04 <petn-randall> you too!
15:11:05 <tobi_m> same!
15:11:07 <ta> ok, bye bye
15:11:08 <apo> dito, bye bye
15:11:11 <spwhitton> thank you.
15:11:12 <santiago> likewise!
15:11:13 <lamby> o/
15:11:15 <rouca> santiago: thanks many mthank
15:11:16 <rouca> bue
15:11:17 <guilhem> bye
15:11:17 <rbalint> thank you, bye!
15:11:18 <rouca> bye
15:11:19 * petn-randall (っ◔◡◔)っ
15:11:28 <el_cubano> #endmeeting