=== guiverc2 is now known as guiverc
[16:45] <tsimonq2> arraybolt3: Heya, when you get in today, could we sync re: 1.4?
[16:45] <tsimonq2> I have a lunch planned today with some family I haven't met in a few years.
[16:45] <tsimonq2> Either way, I'd at least like to get that lxqt-menu-data stuff sorted out.
[16:46] <tsimonq2> (And perhaps, start an impromptu ~lubuntu-dev vote for you. We'll see.)
[16:53] <tsimonq2> Kay, I'll start with uploading an updated lxqt-menu-data, and working up the stack.
[16:53] <tsimonq2> I maybe have 20 minutes, but it's something.
[16:55] <tsimonq2> https://git.lubuntu.me/Lubuntu/lxqt-menu-data-packaging/commit/93cfd4d4cfe1a24128e43db14782633d3b7fc427
[16:55] -ubottu:#lubuntu-devel- Commit 93cfd4d in Lubuntu/lxqt-menu-data-packaging "Sorry Aaron, they re-did it upstream. Better luck next time with your ninja skills. ;)"
[16:55] <tsimonq2> XD
[16:59] <arraybolt3> tsimonq2: May be a couple hours before I'm in, but then sure. (lol @ the commit message)
[17:00] <tsimonq2> :D
[17:00] <tsimonq2> Also, lxqt-menu-data 1.4.1 is now in both Noble and Backports Staging.
[17:00] <tsimonq2> Should fix up some of the issues we've been facing previously.
[17:01] <arraybolt3> +1
[17:01] <tsimonq2> arraybolt3: If you could also remind me of the reverse dependency upstream is missing, that'd be cool too. :)
[17:01]  * arraybolt3 tries to jog my memory
[17:02] <arraybolt3> it was either liblxqt or libfm-qt
[17:03] <arraybolt3> <arraybolt3> 
[17:03] <arraybolt3> also have an upstream bug to file in LXQt (they forgot to mention that lxqt-menu-data is a build dep of libfm-qt now)
[17:03] <arraybolt3> so libfm-qt
[17:03] <tsimonq2> Ah, there we go.
[17:03] <tsimonq2> Thanks.
[17:03] <arraybolt3> sure thing
[17:03] <tsimonq2> Wanna handle that or should I poke upstream?
[17:03] <arraybolt3> I already poked upstream
[17:03] <arraybolt3> I think they fixed it already
[17:04] <arraybolt3> https://github.com/lxqt/libfm-qt/issues/935
[17:04] -ubottu:#lubuntu-devel- Issue 935 in lxqt/libfm-qt "lxqt-menu-data is not specified as a build dependency of libfm-qt in the README file" [Closed]
[17:05] <tsimonq2> Perfect :D
[17:07] <tsimonq2> $ dput ssh-ubuntu ../liblxqt_1.4.0-0ubuntu1_source.changes
[17:08] <tsimonq2> $ dput ssh-ppa:lubuntu-dev/backports-staging ../liblxqt_1.4.0-0ubuntu1~ppa1_source.changes
[17:14] <tsimonq2> $ dput ssh-ubuntu ../qtxdg-tools_3.12.0-0ubuntu1_source.changes
[17:15] <tsimonq2> $ dput ssh-ppa:lubuntu-dev/backports-staging ../qtxdg-tools_3.12.0-0ubuntu1~ppa1_source.changes
[17:15] <tsimonq2> Kay, so apparently I was wrong about my meeting time. It's in a few weeks. Cool.
[17:16] <tsimonq2> Anyway, I'll get a local Britney set up, so that migration to Backports can be handled ~ automagically ~
[17:21] <arraybolt3> Meeting time?
[17:21] <arraybolt3> Oh, with the family you mentioned.
[17:22] <arraybolt3> Sorry to hear that.
[17:27] <arraybolt3> Hmm, looks like we get to do some KDE Frameworks backporting :-/
[17:28] <tsimonq2> ...oh?
[17:28] <arraybolt3> See build failure emails for liblxqt
[17:28] <tsimonq2> Oh. :(
[17:28] <arraybolt3> It's choking on too-old frameworks
[17:28]  * tsimonq2 looks into why that dep was bumped
[17:29] <tsimonq2> I would like to see if that's possible/consult with RikMills, otherwise we could simply revert this: https://github.com/lxqt/liblxqt/commit/fae257647adc8729b597d9cf9617c81b99f9df42
[17:29] -ubottu:#lubuntu-devel- Commit fae2576 in lxqt/liblxqt "Port deprecated KWindowSystem"
[17:30] <tsimonq2> I mean, once Noble is released, I doubt we'll be backporting things to Jammy anymore, anyway.
[17:30] <lubot> [telegram] <RikMills> also why did I get an email about the FTBFS?
[17:30] <tsimonq2> (This day was bound to come, eventually. It already happened with, I think, libproc-dev vs v2.)
[17:30] <tsimonq2> Uh, what? Nice. XD
[17:31] <lubot> [telegram] <RikMills> Oh, the email got sent to lubuntu-devel list
[17:32] <tsimonq2> $ reverse-depends src:kwindowsystem
[17:32] <tsimonq2> [cue the entire universe]
[17:32] <tsimonq2> Nah, I think we're better off just reverting that. :P
[17:35] <lubot> [telegram] <RikMills> Possibly some lazy implementation not handling depreciation better for older stacks as well
[17:35] <lubot> [telegram] <RikMills> Though  might be wrong
[17:36] <lubot> [telegram] <RikMills> I lack a lot of context
[17:39] <tsimonq2> *shrug* me too
[17:39] <tsimonq2> Anyway, Backports will carry a patch reverting that commit.
[17:40] <lubot> [telegram] <RikMills> Have had to do that for some KDE things in the past, so no big deal if it is just that lib
[17:52] <tsimonq2> $ dput ssh-ppa:lubuntu-dev/backports-staging ../liblxqt_1.4.0-0ubuntu1~ppa2_source.changes
[18:02] <lubot> [telegram] <RikMills> crash and burn
[18:05] <lubot> [telegram] <RikMills> no debian/patches/series file
[18:05] <tsimonq2> hahahahahahahahahahahahahahahaha
[18:05] <arraybolt3> tsimonq2: I think you need to apply the patch :P
[18:06] <arraybolt3> *ducks*
[18:06] <tsimonq2> arraybolt3: Gotta love rookie mistakes. :P
[18:06] <tsimonq2> arraybolt3: Remember this when you feel bad about messing up some esoteric symbols file. ;)
[18:06] <tsimonq2> Fixing.
[18:06] <RikMills> how did you manage that?
[18:06] <arraybolt3> oh don't worry, I felt bad enough when it took me like three or four days to do libfm-qt
[18:06] <tsimonq2> RikMills: I didn't use quilt to create the patch :P
[18:07] <arraybolt3> anyway, /me stops rubbing in things before I wreck my chances of getting promoted to ~lubuntu-dev
[18:07] <tsimonq2> arraybolt3: I hope it still doesn't take you that long ;)
[18:07] <tsimonq2> arraybolt3: don't worry we're chill like that
[18:07] <arraybolt3> what I need to start doing is get things to work for everything BUT riscv64 first, then test it on riscv64.
[18:07] <arraybolt3> My problem was 30-40 minute long build times interspersed with tons of other work.
[18:08] <arraybolt3> btw if someone wanted to buy me a SiFive board I wouldn't mind that :P (jk)
[18:08] <tsimonq2> hah :D
[18:08] <tsimonq2> $ dput ssh-ppa:lubuntu-dev/backports-staging ../liblxqt_1.4.0-0ubuntu1~ppa3_source.changes
[18:09] <tsimonq2> https://git.lubuntu.me/Lubuntu/liblxqt-packaging/commit/d7602eea015346cd7d4bffb1dc82e4864c57185e
[18:09] -ubottu:#lubuntu-devel- Commit d7602ee in Lubuntu/liblxqt-packaging "So apparently, you also need a series file. Who woulda' thunk."
[18:09] <tsimonq2> lmfao
[18:09] <lubot> [telegram] <RikMills> /me holds breath
[18:09] <lubot> [telegram] <RikMills> it least until cmake checks, anyway....
[18:09] <tsimonq2> XD
[18:11] <tsimonq2> Status: successful
[18:11] <tsimonq2> Version: 1.4.0-0ubuntu1~ppa3
[18:11] <tsimonq2> \o/
[18:12] <tsimonq2> Now to wait the two hours for the publisher. :P
[18:12]  * tsimonq2 ducks
[18:13] <arraybolt3> if it only takes you two hours you're lucky
[18:13] <tsimonq2> XD
[18:14] <tsimonq2> arraybolt3: So, I know we voted to not grill you, but I have one question which some Core Developers might not know the answer to...
[18:14] <tsimonq2> arraybolt3: And my personal vote depends on it. :P
[18:15] <arraybolt3> oooh, alrighty, hit me with it
[18:15] <arraybolt3> I'm going to use something you said way earlier against you though, which is that it's better to go look something up than it is to guess and hope, so expect a delayed answer :)
[18:16] <tsimonq2> arraybolt3: Explain/highlight the differences between Debian and Ubuntu's Britney and proposed/testing migration setup. Highlight the key differences in their builders, migration policies, hints, testing delays, and onboarding process for each Release Team.
[18:16]  * tsimonq2 watches RikMills and Eickmeyer shake in their boots, knowing darn well they'd both have a hard time with this one :P
[18:16] <arraybolt3> ok, I think I actually know some of this one, stand by while I get together a good one
[18:16] <tsimonq2> Cool :)
[18:17] <arraybolt3> also expect an essay-length answer :P
[18:21] <RikMills> I think a lot of core devs would struggle on that
[18:21] <arraybolt3> my main problem is figuring out where documentation is that I *know* I've seen before...
[18:22] <RikMills> I think I might get about 2/3 right or close enough
[18:22] <lubot> [telegram] <tsimonq2> Bonus points for throwing in stable release update policies.
[18:24] <RikMills> In the end, I know that I know the most important of that, and what I don't know I can find out
[18:24] <RikMills> which is what really matters
[18:25] <lubot> [telegram] <tsimonq2> I know, it's a tough question :) but yes you're right
[18:26] <Eickmeyer> I wouldn't be shaking in my boots and I already explained to tsimonq2 why.
[18:26] <RikMills> It is like scientific research. You can't know everything that is in current knowledge, but you need to know how to find out what you are missing
[18:27] <RikMills> if/when required
[18:28] <RikMills> arraybolt3: keep a browser or browser profile for ubuntu/debian/FOSS stuff, and never clear its history
[18:29] <lubot> [telegram] <tsimonq2> +1
[18:29] <RikMills> you would not belive how helpful a history search can be
[18:30] <RikMills> what was that bug 18 months ago?
[18:30] -ubottu:#lubuntu-devel- Bug 18 in Launchpad itself "RFE: I'd like to be CC:d automatically to bugs I report" [Low, Fix Released] https://launchpad.net/bugs/18
[18:30] <RikMills> aha :D
[18:30] <RikMills> lol
[18:30] <Eickmeyer> ubottu knows. :D
[18:31] <RikMills> does bug 1 still work?
[18:31] -ubottu:#lubuntu-devel- Bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical, In Progress] https://launchpad.net/bugs/1
[18:31] <RikMills> \o/
[18:31] <Eickmeyer> Only because it affects everyone and their dust mite.
[18:33] <arraybolt3> tsimonq2: can you clarify what you mean by "differences between Debian's and Ubuntu's builders?" Are you referring to the build infra as in Launchpad vs. whatever Debian's equivalent is? Or are you referencing available build architectures? or...?
[18:34] <arraybolt3> Similar clarification for "onboarding process" - I'm unsure if you mean onboarding for a *package* or onboarding for a *packager* (which are two dramatically different things :P)
[18:34] <arraybolt3> I assume you mean the former though.
[18:34] <RikMills> I would guess all of it. even on how arch indep things are done ;)
[18:35]  * RikMills looks at LTO
[18:36] <arraybolt3> hey stop giving me hints :P
[18:36] <arraybolt3> I would have forgotten about LTO
[18:56] <arraybolt3> tsimonq2: thanks for your patience, still writing the essay
[19:06] <arraybolt3> tsimonq2: For your shredding, https://termbin.com/s4h6
[19:08] <arraybolt3> I glazed over some of the new package process and some of the Debian build infra things since I didn't know how they worked in detail, and instead referred to the documentation that I would research if I had to know how those things worked in detail. Probably at some point I will end up researching those, but I didn't want this to take me *too*
[19:08] <arraybolt3> long.
[19:11] <lubot> [telegram] <tsimonq2> Thanks, you hit every nail on the head except for one :) what I meant by the release team is, what does the onboarding process for new members look like in Debian vs Ubuntu? Additionally, what are benefits to both Ubuntu's release cadence and Debian's, and in your opinion, why should both exist?
[19:12] <arraybolt3> ahhh, right, misunderstood the question :P alright, essay part 2...
[19:13] <lubot> [telegram] <tsimonq2> Also, you're missing one major point I was looking for: less of LTO, which I consider a bonus point actually, moreso about arch:all builders and their handling in Ubuntu vs Debian, as well as how they handle support architectures vs unsupported
[19:13] <lubot> [telegram] <tsimonq2> No worries, you've been right so far ;)
[19:19] <lubot> [telegram] <tsimonq2> Hint: read the last 4 tech board agendas, searching for the name seb128
[19:20] <arraybolt3> I was just referring to https://wiki.ubuntu.com/UbuntuDevelopers and https://wiki.ubuntu.com/DeveloperMembershipBoard :D
[19:21] <lubot> [telegram] <tsimonq2> Less actual membership of developer teams, moreso the actual release team members themselves. How do they join?
[19:21] <arraybolt3> They get voted in after a grilling in a DMB meeting, I thought.
[19:22] <lubot> [telegram] <tsimonq2> *shakes head*
[19:22] <lubot> [telegram] <tsimonq2> The DMB doesn't choose the release team
[19:22] <arraybolt3> Oh teh *release* team.
[19:22] <lubot> [telegram] <tsimonq2> And DAM doesn't choose Debian Release Team members either heh
[19:22] <lubot> [telegram] <tsimonq2> yes :)
[19:22] <arraybolt3> gah. You're using terms I don't run into much :P
[19:23] <lubot> [telegram] <tsimonq2> I know you already know how people become Ubuntu Core Developers and DDs :P
[19:23] <lubot> [telegram] <tsimonq2> I know, tough question, and I'm not exactly being straightforward (somewhat on purpose)
[19:25] <arraybolt3> tsimonq2: how do I even find the older agendas?
[19:25] <arraybolt3> I found https://wiki.ubuntu.com/TechnicalBoardAgenda without trouble but that's only the latest one I believe.
[19:26] <arraybolt3> also looks like they're working on documenting their membership process according to that one
[19:26] <Eickmeyer> DING DING DING DING DING
[19:27] <arraybolt3> I take that as "you got it right" :P
[19:27] <Eickmeyer> Basically.
[19:27] <arraybolt3> I wanted to find the older ones to be sure but I cannot find them for the life of me 🤣
[19:28] <Eickmeyer> It was a trick question, which is why I was keeping my mouth shut.
[19:28] <arraybolt3> aha
[19:29] <arraybolt3> tsimonq2: welp there's the answer. I have no clue how they join, and they haven't even fully documented it yet so finding out would probably be tricky.
[19:34] <lubot> [telegram] <tsimonq2> DING DING DING DING DING
[19:34] <lubot> [telegram] <tsimonq2> XD
[19:34] <lubot> [telegram] <tsimonq2> Nah, but the wider point about differences in philosophy is important still
[19:34] <arraybolt3> tsimonq2: As for release cadence, Debian releases about once every two years, and all releases are supported for about three years (with an extra two years of support for some things via Debian LTS and potentially even longer via commercial ELTS support). Ubuntu releases once every six months, with 9 months of support for most releases and 3-10
[19:34] <arraybolt3> years of support for LTS releases (depending on whether you're using a flavor, Ubuntu Desktop or Server, or ubuntu Pro). Debian's release cadence ensures well-tested, stable software, while also providing new software via unstable for those who are brave enough to use it. Ubuntu's release cadence provides new *and* stable software on a regular
[19:34] <arraybolt3> basis, and while it may not be quite as stable as Debian, it's still very good and useful for people who need new software but don't want to fight with a terrifying rolling release or something.
[19:35] <arraybolt3> (Ubuntu's release cadence is also useful for enabling newer hardware to run Linux, especially when combined with things like HWE kernels for LTS releases.))
[19:35] <arraybolt3> I want to answer the bit about arch:all builders and how they handle supported and unsupported architectures... but I have some emergencies pulling me away in $PERSONAL_LIFE and will have to come back and answer those in a bit.
[19:35] <arraybolt3> Sorry to have to interrupt.
[19:36] <lubot> [telegram] <tsimonq2> Would you agree that sometimes taking those risks of including that newer software is necessary to help move the project forward as a whole? Where exactly would you draw that line if you had to make such a decision?
[19:36] <lubot> [telegram] <tsimonq2> No worries
[19:43] <arraybolt3> For the last question, it depends strictly on what the target audience is. New software is awesome for people who need it (developers for instance, though there are plenty of other use cases where new software is nice), while old stable software is awesome for people who need it (people who run servers, for instance, or who need their workflow to
[19:43] <arraybolt3> work and not break). I personally straddle the line between those two, running Ubuntu LTS on my hardware for stability and all sorts of distros (both stable and bleeding-edge) in VMs for whatever use case I may have.
[19:46] <arraybolt3> Ubuntu's methodology works great IMO, but so does Debian's. It depends on who's using your OS. I do like that Ubuntu does both LTS and non-LTS releases so that they help people with both use cases, but I've met people who find even Ubuntu LTS to be not quite good enough in terms of stability, and prefer Debian in those instances. I'm not that
[19:46] <arraybolt3> person, but they exist, and I'm glad Ubuntu and Debian both exist :)
[19:46] <arraybolt3> ok, now I *really* have to go :P
[19:46] <arraybolt3> brb
[20:01] <lubot> [telegram] <tsimonq2> You're missing a major point from this line in the Lubuntu Developers qualification list, and its impact on wider vendors: 
[20:01] <lubot> [telegram] <tsimonq2> 
[20:01] <lubot> [telegram] <tsimonq2> exercise great care in their work, with the understanding that their efforts have a direct impact on others, including:
[20:01] <lubot> [telegram] <tsimonq2>     every Lubuntu user.
[20:01] <lubot> [telegram] <tsimonq2>     the Ubuntu Release Team.
[20:01] <lubot> [telegram] <tsimonq2>     corporate partners who provide support for Lubuntu.
[20:01] <lubot> [telegram] <tsimonq2> 
[20:01] <lubot> [telegram] <tsimonq2> Hint: vendors pay money. Another hint: Canonical pays money to direct developers to work on projects. Also, what is Debian in this context, and why do we still need a Debian, not just an Ubuntu?
[20:02] <lubot> [telegram] <tsimonq2> In terms of the newer software requirement, please reread my question in the context of the simple phrase "follow the money" :)
[20:05] <lubot> [telegram] <tsimonq2> Also, don't feel obligated to push aside emergent, personal responsibilities in favor of answering my grilling.
[20:06] <lubot> [telegram] <tsimonq2> "Don't ask to go to the bathroom, just go, I'll be here when you come back" :)
[20:34] <arraybolt3> alright, thanks for your patience, took me a bit longer to get back in
[20:37] <arraybolt3> tsimonq2: I'm afraid I don't fully understand the question? I mean the new info you've provided doesn't seem to influence my answer, since I would always exercise great care in my work (which I believe is evident from my previous uploads and recent actions) whether there was money or vendors involved or not. I understand that Canonical is a
[20:37] <arraybolt3> business that makes money off of Ubuntu and its other products in various ways, and that our actions must not harm Canonical's reputation or goals, but should rather contribute to the ecosystem that Canonical monetizes. I'm not sure how that affects whether newer software is a good thing or not in my personal opinion though. So perhaps I'm missing
[20:37] <arraybolt3> something?
[20:40] <arraybolt3> Why we still need a Debian is fairly obvious - they do a massive load of work packaging software and we benefit directly from that by taking from their repos to provide software in ours. We do our own maintenance work thereafter (with occasional syncs from Debian in many instances), but the work they do can't be overlooked and is vital to our
[20:40] <arraybolt3> success. As I recall reading on I think Mark Shuttleworth's Ubuntu Wiki page, "without Debian there would be no Ubuntu."
[20:40] <arraybolt3> We contribute back to that ecosystem as well so that it's a symbiotic relationship.
[20:42]  * arraybolt3 goes and tries to dig up info about arch:all builders and supported architecture handling while waiting for clarification
[20:58] <arraybolt3> tsimonq2: I'm shaky on the details here, but for supported vs. unsupported architectures in Ubuntu vs. Debian, both Debian and Ubuntu build all packages (except arch:all packages) for all supported architectures unless the package excludes a particular architecture for some reason. Ubuntu also has some i386 packages that it builds for the sake of
[20:58] <arraybolt3> software compatibility, despite i386 no longer being a supported architecture. Packages to be built for i386 in Ubuntu have to be specifically added to the i386 whitelist by archive admins. Debian fully supports i386 and doesn't have this sort of thing. However Debian also has a TON of "unofficially supported" architectures that packages are built
[20:58] <arraybolt3> for (Debian ports), which is something Ubuntu doesn't have AFAIK.
[21:00] <arraybolt3> I tried but couldn't find hard info about how arch:all builders work in Debian vs. Ubuntu (I know from experience that in Ubuntu an arch:all package will sometimes be built on an amd64 builder, dunno if that's always the case though). If you could shoot me a documentation page or two for further study, that would be much appreciated.
[21:11] <RikMills> arraybolt3: never seen arch:all built on anything but amd64 in ubuntu
[21:11] <RikMills> well might have been on i386 in prehistoric times
[21:12] <RikMills> :P
[21:22]  * lubot [matrix] <arraybolt3> waits nervously for Simon to reply - I'm worried I probably butchered some of these last answers though I did try to get the answers right
[21:25] <RikMills> don't let tsimonq2 woory you. you should have seen what he was like when he started packaging ;)
[22:03] <arraybolt3> tsimonq2: I wonder if the problem is that I missed part of your question about newer software entirely. You asked where I would draw the line when it came to whether to include newer software or not to move a project forward. I'm guessing the answer you're looking for has to do with the fact that this is an LTS release, where the inclusion of
[22:03] <arraybolt3> unstable new software could have major detriments to many users, whereas with interim releases doing those things aren't a big deal and are even beneficial in many instances (like what we did with Calamares, shipping a well-tested alpha version).
[22:04] <arraybolt3> If that's the case, you probably already know my answer - shipping new unstable things in an LTS that people might pay for support for could be bad for us, bad for our users, bad for vendors, bad for everyone. In those instances we would want to hold back and ship what's stable and can be supported for a long time (3 years or more). For interim
[22:04] <arraybolt3> releases, shipping newer things sooner is something we can afford to do and probably even should do in many instances.
[22:05] <arraybolt3> So there. Finally, I think I have an answer that matches what you were trying to get at. If not, I'm ready to learn and will accept it if I don't get ~lubuntu-dev yet.
[22:10] <arraybolt3> Eickmeyer: I'm interested in the fact that you seem to have inside information on what's happening here :P don't tell me anything confidential, but if you can at least tell me if I'm doing horribly or doing decently that would be appreciated, if that's not bad.
[22:15] <arraybolt3> (also, I have to leave at sunset tonight and won't be back until sunset tomorrow at the earliest, so if that time arrives, we may need to pick this up later.)
[22:19] <arraybolt3> actually, I have to go cut wood so I guess I'll catch up with y'all later