[00:00] tsimonq2: "If there are files that need to be installed into your package but your standard make install won't do it, put the filenames and destinations into this install file." Where am I lost? [00:00] Those 2 cases are not mutually exclusive [00:01] OK. So... where does make install play a part? [00:02] Using make install can help you understand what is programmatically going to is is programmatically going to be installed by a cement but if it's a different file that doesn't exist in she makes realm then it can install it [00:02] Excuse my talk to text but that is my summary of that [00:02] cement = CMake? [00:03] So install files can be used for both files that have been generated by a sea have been generated by a seamache and files that have not been generated by a sea make [00:04] So we specify everything in the .install file whether "make install" would do it or not? [00:04] But it's not technically necessary in some situations? [00:05] (Like, a very simple package where "make install" handles everything in a reasonable way could just be left without an install file, but one can be provided to make things clear and sensible? And to handle anything "make install" misses?) [00:07] (I get the "what" behind the install file, I'm just digging for the "why" so that I have a clear understanding of everything.) [00:23] I guess what would help it click the most for me is, in what situation would a package not include one or more install files? [00:29] "(Like, a very simple package..." <- That is precisely right. [00:29] "I guess what would help it click..." <- Like you said, a very small package [00:29] So they're not mandatory, but you should include one even if you don't have to. [00:29] Or rather, a very simple package [00:30] Ah, OK, I think I get it. So my last message was wrong. [00:30] arraybolt3[m]: I forget what policy says but it helps you keep track of upstream changes so I'd always opt for one [00:30] I can't even find anything about the install files in the policy so 🤷‍♂️ [00:30] Nice. Love it. [00:30] Hey here's a curveball for you, back to copyright... [00:31] Is the upstream source DFSG-compatible? [00:31] For installer-prompt? Yes. For everything? [00:31] s/compatible/compliant/ [00:31] * arraybolt3[m] digs in docs [00:32] Debian Free Software Guidelines. I'm not saying you need to dig into it at the same level as I did as a DD, for you it's probably one of those things where you read it once and get an understanding of it, and you kind of have a gut feeling to recheck it if something feels off [00:33] (As a DD I had to read long license text for several licenses to determine whether they were DFSG-compatible and why or why not, precisely. That's too intense of a grilling for someone who hasn't explicitly volunteered for it. :P) [00:34] I might actually go ahead and try that (later). I always read the terms and conditions for almost everything (though I skipped Stack Exchange, Thomas is a mod on Ask Ubuntu and I was too tired to delve through that mess). I've read the entire GPL v2 and v3, and even decided on v3 rather than v2 for one software package I made once. [00:34] In fact, with the right Googling you may get this answer in less than 5 minutes [00:35] arraybolt3[m]: Check the Lubuntu Developer wiki page, there's a link somewhere [00:38] Simon Quigley (Developer): I believe you have to be DSFG-compliant for a package to be accepted into Debian's main archive, but not for contrib or non-free. Not sure about Ubuntu yet, though. [00:38] arraybolt3[m]: Ubuntu follows the same criteria. [00:39] Nice. So main and universe are DSFG-compliant, restricted and multiverse not? [00:39] So, for the two licenses present in this package, are they both DFSG compliant? [00:40] arraybolt3[m]: Restricted and multiverse just gets a little fuzzy. [00:40] GPL-3, yes. [00:40] (Looking up CC-BY...) [00:40] (I found this awesome partial list of DSFG-compliant licenses, I'm just gonna cheat and use that.) [00:41] (And it's in Debians official docs!) [00:41] For every up and coming MOTU I mentored, I (used to at least) make them merge msttcorefonts from Debian :P (one of the most complicated mind-numbing convoluted hacky easy-to-break merges you will ever do) and that's in multiverse. That code is "open" but a license is required to be accepted before it can be installed. [00:41] CC-BY 4.0 is also DSFG. [00:41] That answers my question :) [00:42] arraybolt3[m]: Nice fins [00:42] * Nice find [00:42] tsimonq2: Oh no. Pretty much anything Microsoft proprietary+Debian is virtually guaranteed to be easier to shatter than Arch Linux, right? [00:43] tsimonq2: This is what they mean when they say "evil and pedantic, just like your sponsors" :P [00:43] arraybolt3[m]: Yeah it is a mindf*** [00:43] (So that's why you do '-E-', '-v-', '-I', '-L', '+pedantic' for Lintian!) [00:43] In that order :P [00:43] I can be evil when getting to the final stages of grilling someone for upload right endorsement [00:44] Like "you're off by one line in your diff redo it" evil :P [00:44] tsimonq2: Not sure if qualifies as evil when the alternative is to let someone wreak havoc. [00:44] You'll know when you're there... cause you'll be able to handle it ;) [00:44] arraybolt3[m]: Fair enough [00:44] Tricky, sure. Evil? Not. [00:46] Cruel is probably a more accurate description :P [00:47] Hey, you talking about copyright files just made me realize I botched debian/copyright for installer-prompt. Better fix that... [00:47] Quick question, do we usually license the debian directory under some specific license, or is making it the same license at the source code par for the course? [00:48] arraybolt3[m]: I mean you're the guy packaging it, do you care if we just save the lines in the copyright file and also do GPL v3? :) [00:48] Nope, don't care, just want to not go against any policies or anything. (Shoot, I'm not even retaining copyright, I'm plopping it under "Lubuntu Developers", so really it's your decision, not mine.) [00:49] (Or at least the decision of the collective developers, so probably the Lubuntu Council, but if it's fine to save the lines, I'mma save the lines.) [00:49] (I can dive down rabbit holes sometimes...) [00:50] OK, back to how I botched it. Forgot to specify the CC-BY 4.0 in the copyright file. Fixing... [00:51] arraybolt3[m]: Lubuntu Developers works [00:51] In fact you can just do the entire source including debian/ under the same copyright declaration [00:52] OK, so quick question, where do we intend to put img/background.png in the final package? [00:52] (Oh wait, this is a source package, nevermind...) [00:56] arraybolt3[m]: Yeah for copyright it's source code paths only [00:59] Oh great, now I have to plop the whole license text in. (CC-BY-4.0, why can't I just license it as something easy? 😢) [00:59] arraybolt3[m]: Have fun. ;) [00:59] This is interesting, it's the license I picked, but I only picked it because the artwork contest requires it... [00:59] Well, thankfully, I can just hork it from another package from codesearch.debian.net. [01:00] I mean, check the lubuntu-artwork copyright [01:00] (And if that isn't up to date there's a problem lol) [01:00] arraybolt3[m]: Very nice [01:00] Oh, not a bad idea. [01:00] (In response to the lubuntu-artwork package idea) [01:01] tsimonq2: Nope, everyone went with CC-BY-SA. [01:03] OK, that was easier than I thought. [01:04] arraybolt3[m]: Cc Dan Simmons for accuracy [01:04] Dan Simmons: that [01:04] Aha [01:05] Not that I have anything against CC-BY-SA, but I tried to do CC0, so CC-BY seemed closer. [01:12] arraybolt3 @arraybolt3:matrix.org: And once we get this through NEW we can also add those icons :) [01:13] You liked those? I sure had fun making them. [01:14] Quick question, the source code for installer-prompt had the path to the background image hardcoded in. Once it's packaged, will that interfere with the executable's ability to find the image? [01:15] arraybolt3[m]: Nope just make sure that png is installed in that path [01:16] Right... but we can't put a folder called "img" in /usr. So I'm guessing the working directory will be in usr/share/installer-prompt/, and the picture in usr/share/installer-prompt/img? [01:17] Yep [01:18] See CMakeLists.txt [01:18] (I was looking in there...) [01:19] Ah, I see the code changed since last I saw it. That makes it all make sense. [01:28] "Not that I have anything against..." <- CC0 is stuff I horked from unsplash. That is the license they provide. [01:30] kc2bez[m]: Unsplash is awesome. [01:30] It really is. [01:36] Si [01:36] Simon Quigley (Developer): Sorry if I'm being slow packaging, I'm simultaneously trying to do belated spring cleaning. [01:36] I do want to do the packaging though. [01:36] And I'm pretty far into it. [01:37] * (enter instead of tab strikes again!) [02:02] You're okay arraybolt3 @arraybolt3:matrix.org [02:02] Just had dinner with the family probably going to do more $sidejob work [02:03] Ping me when you're stuck :) [04:01] Simon Quigley (Developer): Help [04:02] (Hit Enter too early, was going to make that funny, now it just looks pathetic...) [04:02] (And now I'm realizing I should probably figure this out myself. So now I look pathetic and amateur. Go figure.) [04:06] Simon Quigley (Developer): OK, I'm a bit stuck after all. I cannot figure out what's supposed to go in debian/upstream/signing-key.asc, but I do know that simply grabbing the .asc file that signs the source tarball doesn't work. [04:09] arraybolt3[m]: I would have to look up the exact terminology for you but you are just simply exporting my public key and an arrow to formats so that's used skin can process it [04:09] Armored [04:10] Oh, like what I do for adding a PPA to sbuild. Got it. [04:14] tsimonq2: Thank you, that worked. [05:35] Simon Quigley (Developer): During the packaging, I'm getting "no-manual-page" Lintian output, would you like to write a man page, would you like me to, or would you like me to override it? [05:39] Simon Quigley (Developer): It wants manual pages for lubuntu-installer and lubuntu-installer-prompt. [05:43] (I can see already to override the lubuntu-installer script man page, it's not ever intended to be used by the end user, it's just for use by lubuntu-installer-prompt itself.) [05:48] Simon Quigley (Developer): Also, getting this: "lubuntu-installer-prompt: using-first-person-in-description line 2: we" Super easy to fix, but since I copied the description straight out of your GitHub repo, I want your go-ahead before fixing it. [05:48] Other than that, this thing is building Lintian-clean, and I'm about to test it out in a live session! 🎉 [05:56] "Simon Quigley (Developer..." <- Override, there's no CLI interface [05:56] "Simon Quigley (Developer): It..." <- All good, disregard [05:56] "Simon Quigley (Developer): Also,..." <- What specific part of the description is it complaining about? [05:57] Simon Quigley (Developer): "Eventually we want to extend this to support multiple flavors." [05:57] * (Developer): "Eventually **we, * we** want [05:57] Eventually the goal is this will be extended to support multiple flavors. [05:57] Or similar [05:57] Not particular [05:57] In fact, that line prob shouldn't exist in a package desc [05:57] I mean think about it :] [05:58] Yeah, I see your point. [05:58] s/]/)/ [05:58] OK, I can just remove that part if you'd like. [05:58] Well... maybe. [05:58] Thoughts? [05:58] (I kinda liked :] ) [05:58] Simon Quigley (Developer): I'll just quote a snippet out of the Wine package description, that should summarize my thoughts. [05:59] Cool sounds good man [05:59] Ah, it used to say something like "This is buggy and a lot of stuff won't work", or something. [05:59] I'll be home likely in the next 30 mins. Just depends on the intense conversation I'm about to have with my girlfriend on whether or not I'll be around tonight. :P [05:59] My idea was, "If it's kinda incomplete but we're releasing it anyway, why not put the line in there?" [06:00] (If I'm sucking away your time for your family, don't let me do that. I can stop pinging you and just pick up whenever you're back.) [06:00] I mean, technically speaking it's feature-complete for a 0.x release. 1.0 may have all the fancy bells and whistles. [06:00] arraybolt3[m]: Nah I'm still out and about you're cool [06:01] Thanks for your consideration but I'm waiting until I'm done with this task for $sidejob before I face the music [06:17] While I'm waiting for the Kinetic ISO to zsync, want me to GitHub my packaging so far and submit it for your roasting? [06:17] Simon Quigley (Developer): Ping [06:23] Sure [06:24] Just got home and it wasn't an instant argument, I'm surprised :) only a matter of time... [06:24] Anyway [06:25] "While I'm waiting for the..." <- When you test it you'll need to log out and log back in (password box stays empty) for it to show as intended [06:26] Simon Quigley (Developer): OK, not quite sure what that means at this moment, but I'll find out pretty soon here. [06:27] arraybolt3[m]: As in like, install the package, log out of the LXQt session (but don't reboot!) and log back in (for the second time so it doesn't bite you in the ass later: **the password is blank**) :) [06:27] As in, doesn't exist [06:27] Null [06:27] :)) [06:27] Simon Quigley (Developer): Alright, tell me how bad I did: https://github.com/ArrayBolt3/installer-prompt-packaging [06:28] * tsimonq2 cracks his knuckles [06:28] tsimonq2: Oh I get it, because this is in the live session. Sorry, trying to manage GitHub, prepare for testing, and do tech support all at once. [06:29] You're good man :) [06:29] I probably botched the install dependencies I just remembered. So expect for me to need to fix that. [06:29] (The build deps are good though.) [06:29] (AFAIK.) [06:29] That's part of why I need to test, is to know what install deps are needed. [06:29] Cool. I will be sure to review jubilant-doodle ASAP. ;) [06:30] * arraybolt3[m] understands why GitHub does that, but also think sometimes it comes out really funny. [06:30] * arraybolt3[m] * understands why GitHub does that, but also thinks sometimes it comes out really funny. [06:47] Lmaooo [06:47] Aaaand... fail. Missing qt6-qpa-plugins, need to add that as an install dependency. But once I installed that, I got it to work. [06:47] Reviewing by mobile before I put it through the local script gauntlet [06:47] However... it does need some help with UI layout. Screenshot of problem incoming... [06:48] * arraybolt3[m] uploaded an image: (2049KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/OHqnjaXxiAxENRkQkWGWCyYP/image.png > [06:48] (Well, it caught my second monitor, so there's extra junk in there, but you can see the problem with how it looks in a VM window. [06:48] * VM window.) [06:49] Not sure how we're going to make it look right on all screen sizes. [06:49] Hmm. We'll have to work on that. [06:49] What is your rationale for `debian/source/options`? [06:49] Also, if the user clicks "Install Lubuntu", then backs out of the installer, the installer-prompt is still there. Bug or feature? [06:50] arraybolt3[m]: It is? Where does it go? [06:51] tsimonq2: I'm doing the packaging in a Git repo, I saw that other packages in LXQt had the option, and since it looked like it was making sure the gitignore file didn't get packaged in, I put it in too. [06:51] ✅ debian/upstream and debian/watch with manually reviewing it, thanks [06:51] tsimonq2: As in, backing out of the installer lands you back on the installer-prompt screen. [06:52] arraybolt3[m]: Three different LXQt packaging repos all use that option. [06:52] arraybolt3[m]: But my question to you is, **why** do they use that option? :) [06:53] I guess I should look up exactly why, I was guessing at what it did... and I know how guessing turned out last time. [06:53] arraybolt3[m]: Oh, yeah. File an issue on GH please [06:54] arraybolt3[m]: It's not about guessing, guessing is okay every once in a while in controlled settings, I just want you to understand why you're making the decisions you're making [06:54] That makes sense. I figured, "looks reasonable, other, good packaging uses it, go with the flow." [06:54] Also, I would definitely prefer you take the time to formulate a researched answer to questions over just giving me your gut reaction unless you know you know the whys. [06:55] Well, you did ask my rationale, so I was answering with what my rationale was. I could have dug around and found out exactly what the option did and then tell you would I should have done, but I didn't think that was exactly what you were asking. [06:55] Thorough and comprehensive answers that show understanding but take longer > the first thing that pops into your head because the pressure makes you want to give me an answer quicker :) [06:56] Makes good sense. [06:58] Hmm, I'm having a hard time even finding info about the tar-ignore option... [06:58] arraybolt3[m]: Imagine this... you're 3 years down the line and one of the members of the Ubuntu Release Team asks you, "why tf would you do such a thing? What's your rationale?" you should be able to say "okay, looking at this again, I see my rationale was x, y, z, but I can see why you would question it." It's part of what they teach you as a lawyer, to be able to defend against rebuttals before they're made [06:58] Ah, found it. [06:58] Happens to all of us. Happened to me this cycle and same with Erich. My tl;dr is just be prepared to defend your decisions, make them confidently [06:59] So if I ask for rationale, there's a reason I'm asking you [06:59] tsimonq2: That's good thinking. I actually do logical debate as a recreational activity, so this clicks instantly for me. [06:59] But I also want to know the rationale :) [07:00] arraybolt3[m]: Perfect. Just keep that in mind. If you're stuck in a rabbit hole, I'm probably one of the more friendlier and patient faces you'll find :) [07:00] But research is key. Especially when you're on your own and $new_fancy_thing is made default and I'm not around :) [07:01] OK, I'm going to have to find out what dpkg-source even is before I can answer correctly what that option does. [07:01] arraybolt3[m]: Ooh, nice one. Let me know if you have any questions. [07:03] So here's something I'm noticing, and maybe you can confirm that I'm understanding right here. We a lot of times have our packaging separate from the source code. I've noticed Debian has source and packaging together. And dpkg-source packs and unpacks Debian source archives. Does that mean it makes the orig.tar.gz files, or at least can make them? [07:03] If so, I believe the "tar-ignore" option I set is only useful for if we had our packaging and source together... but we don't, so I believe I should remove it. [07:06] So, the "good" answer to your question: "My rationale behind setting that option was simply that multiple other packaging directories I checked had that option set. However, upon further investigation, it looks like it's unnecessary for this particular package, and should be removed." [07:07] * arraybolt3[m] thinks that sounds like a newbie trying to sound professional, because that's exactly what it is [07:08] arraybolt3[m]: No, so what dpkg-source does it takes the orig tarball, unpacks it as per the rules you set, errors if there's a local diff that's not in a patch, and builds the package. All that happens in the background in a tmp directory [07:08] Oh great. So I'm totally off in left field here. [07:08] arraybolt3[m]: Success is built on a mountain of mistakes. If you start with something small like that and hone it in, a while from now you'll have it down. [07:09] So, wait, if dpkg-source doesn't make the orig.tar.gz file, then why does the man page say this? [07:09] arraybolt3[m]: You just have it exactly backwards. It doesn't take the source and makes the orig, it takes the orig and makes the source [07:10] (Matrix is being mean, hold on...) [07:10] arraybolt3[m]: I dunno, my understanding could be rusty but I know that orig isn't touched [07:10] If this option is specified, the pattern will be passed to tar(1)'s --exclude option when it is called [07:10] to generate a .orig.tar or .tar file (--tar-ignore since dpkg 1.15.6). For example, -ICVS will make [07:10] tar skip over CVS directories when generating a .tar.gz file. The option may be repeated multiple times [07:10] to list multiple patterns to exclude. [07:10] OH [07:10] Okay [07:10] So [07:10] That's what tar-ignore does. [07:11] Imagine this... there's a tarball with mostly free code. There's one module that's nonfree. You want to not include a copy of that source, anywhere in the archive. So you strip it and retar the orig [07:11] That usually adds a +dfsg suffix [07:11] ...get it, 'cause it's to be compliant with the DFSG? [07:12] Anyway, it can make a derivative orig, but can't entirely generate a new pristine original [07:12] So "tar-ignore=.gitignore" says to leave the .gitignore file out if making a derivative orig? [07:13] No, that's a cleaner way of just stripping it before it gets to the source [07:14] See, we're talking about two different things, let me explain... [07:14] That gitignore file is free software. We can legally ship it in the Debian and Ubuntu archives [07:14] We don't have to build a new tar [07:14] The existing tar is fine to ship [07:15] A full repack is for non-free files that we literally need to purge from the archive for legal reasons [07:15] Right. [07:15] But we don't want the .gitignore to be in there during the build process, so while we ship it since it's legally fine to, we also strip it since it's otherwise useless to us? [07:16] I think this particular issue is sorted by your formalized evaluation summary ;) [07:16] It may be unnecessary. Doesn't hurt [07:17] Upstream may include debian/ in the gitignore file, think about that too :) [07:17] That could cause problems if it got through to the build process, right? [07:18] Nah, it's trivial [07:18] So, just the what. tar-ignore keeps files from within the tar from getting into the build process during the sbuild. Right or wrong? [07:18] (I just want to get a good handle on this so I know when to use the option in the future.) [07:18] arraybolt3[m]: Yes correct [07:19] And it's only used if the tar is entirely free, as we discussed before [07:19] click Got it! [07:20] tsimonq2: (Well, I guess they're not mutually exclusive, you can use that option and still repack a tar but holy convoluted wtf lmao) [07:21] Makes sense. Like tar-ignore out just the .gitignore and then repack to remove the non-free stuff or something. [07:21] arraybolt3[m]: Yeah [07:21] One part of me thinks I should get rid of the option to shave a tiny bit of space off of the source package, another part of me thinks, if everyone else thinks it's a good idea, let's also do it. What do you think? [07:22] I'm about the same [07:22] LOL that didn't help... [07:23] Pick one and roll with it [07:23] I don't mind [07:23] Most practical thing to my mind is remove it. We'll shave some precious bytes of space off that might help someone store that one extra browser cookie or something. [07:24] Next question, I think we've spent enough time here... [07:25] What does this line do and what purpose does it serve with respect to long term package maintenence? [07:25] ``` [07:25] dh_missing --fail-missing [07:25] ``` [07:25] One moment, may have just nuked Git yet again... [07:25] (Oh my gosh I ended up removing the .install file entirely because I was frustrated with trying to get it to work, that needs fixed.) [07:26] arraybolt3[m]: Nuked Git the program or your local Git clone? ;) [07:26] Local Git clone. [07:27] I just pushed it, may as well wipe and start over (ran "git add -A && git commit -m "message" in the wrong directory in detached HEAD mode, not sure how to undo that). [07:27] ``` [07:27] git checkout PATH [07:27] ``` [07:27] That will bring the file back [07:27] arraybolt3[m]: git checkout master [07:27] git status [07:28] I did "git checkout 0.2.0" earlier to fix an sbuild gripe when I had my source and packaging all together a bit ago, so doing "git checkout master" might wreak real havoc. [07:28] I'll save it as an interesting Git-fu testbed, and clone so I can keep going. [07:29] > <@tsimonq2:linuxdelta.com> What does this line do and what purpose does it serve with respect to long term package maintenence?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d8133b0f0db3720008c762da5eff19ded49bfb5d) [07:29] arraybolt3[m]: man git-stash when switching branches around to get clean inline conflicts [07:31] > <@tsimonq2:linuxdelta.com> What does this line do and what purpose does it serve with respect to long term package maintenence?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/75c39cc67eda8429149acaf5f78ed542f532e048) [07:32] For the lubuntu-installer-prompt project, this should help us not forget to install the icons once we add them. [07:33] Thanks! Covers all the bases :) [07:33] I did that "research then reply" thing you suggested. Looks like it's working! [07:33] :D [07:34] Okay this one is going to be the toughest part of the manual source package review... [07:34] debian/control time... [07:35] (There are problems I know about in there, so don't be surprised if something looks awry, it is. I only remembered them after pushing the repo.) [07:35] (I'm about to fix them.) [07:42] - Add your name to uploaders, you did more than I.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ecbd41023ef5093a37db763cb30f7e21c8bdf8c6) [07:42] I'm going to go afk, I don't expect you to answer all that tonight :) [07:42] Besides those questions that about wraps up the package minus my script gauntlet [07:43] Whew, OK, looks like I have some work cut out for me. At least I got it Lintian clean thought. [07:43] There is literally a script called `check-all-the-things` :P [07:43] Lintian won't save you 100% >:P [07:43] Anyway, thanks for your hard work. I appreciate it [07:43] tsimonq2: Evidently! [07:43] Have a great night, as always, ping with questions [07:44] Thank you! See you hopefully tomorrow [07:44] * hopefully tomorrow. [11:36] [telegram] in this particular case they are translations that come from weblate, I will look at the rest of the packages (re @lubuntu_bot: (irc) Please excuse my talk to texans I'm driving but if you look at the upstream repositories the individual ones there should be websites commits in each one of the commit histories so and histories so for example feather pad well probably not feather paths probably not a good example maybe PC m [11:37] [telegram] they are weblate commits [11:38] [telegram] example —- > https://github.com/lxqt/pcmanfm-qt/commit/640c9e17aa49d07d24a9f61863050d9640bced58 [11:38] Commit 640c9e1 in lxqt/pcmanfm-qt "Weblate commits (#1600)" [11:39] [telegram] if that's not what you want, let me know [11:50] [telegram] my first pull request xD [11:50] [telegram] https://github.com/lubuntu-team/lubuntu-update-notifier/pull/4 [11:50] Pull 4 in lubuntu-team/lubuntu-update-notifier "Update upg-apply.desktop" [Open] [11:56] [telegram] I have to look at the operation of the po files, supposedly I should see the entire program in Spanish, but I see it in English. [11:56] [telegram] The same can happen with the Japanese. [17:06] * tsimonq2 uploaded an image: (212KiB) < https://libera.ems.host/_matrix/media/r0/download/linuxdelta.com/ziYpiPYZsTojDGUDExRxdmgL/Screenshot_20220701-120610_Reddit.jpg > [17:15] "Screenshot_20220701-120610_Reddi..." <- Yup, true story. libfuse2 is needed for janky appimages. They refuse to update the appimage code to support the newer standard. [17:16] Please elaborate on what the newer standard is, I'm not familiar [17:16] I think it is libfuse3 [17:17] libfuse2 was dropped from main [17:17] I will dig up some links in a few. [17:17] Cool, thanks [17:20] [telegram] Yes is libfuse3 installed by default (re @lubuntu_bot: (irc) I think it is libfuse3) [17:25] Here is the bug https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1965636 [17:25] Launchpad bug 1965636 in ubuntukylin-meta (Ubuntu Jammy) "libfuse2 no longer included in jammy, required for AppImages" [Undecided, Confirmed] [17:27] Twitter was on fire over it too. https://twitter.com/probonopd/status/1519816861893939201?s=20&t=4yYxehYhW37or4FXAnC5vw [17:32] Should we join them? [17:32] Which side? [17:32] XD [17:32] We haven't joined either as of yet. [17:34] XD [17:34] Uhhh including it [17:34] Does it take up a lot of space? [17:35] [telegram] Is in universe (re @lubuntu_bot: (irc) libfuse2 was dropped from main) [17:35] I don't think it does, we could possibly do that. [17:36] They seem to be co-installable. [17:36] I want to know what guiverc @guiverc:matrix.org thinks too :) [17:36] lubot: right like everything else that makes us "L"ubuntu [17:37] tsimonq2: I agree. [17:38] [telegram] The problem is solved with sudo apt install libfuse2, but by default it doesn't work (re @lubuntu_bot: (irc) They seem to be co-installable.) [17:38] Right, it isn't seeded. [17:44] I guess my biggest concern here is the security aspect but it is no different than any other package in Universe. [18:05] "I guess my biggest concern..." <- I've done those kind of security updates before. [19:48] Simon Quigley (Developer): I'd say include libfuse2, there are applications (such as LMMS) where the version in the archive doesn't actually have all of the features (LMMS is missing VST support in the archive), but the AppImage does. [20:36] Simon Quigley (Developer): "Please explain what this does: `Rules-Requires-Root: no`" This field specifies whether some form of root privileges (root or fakeroot) are necessary for some part of the build process Since I was able to successfully build the program in Qt Creator without root privileges (to the best of my knowledge), this led me to believe that the package did not require root privileges to build, so I set this field [20:36] to "no" to silence a Lintian gripe. [20:36] Simon Quigley (Developer): "What is the difference between a package with `Architecture: all` and `Architecture: amd64`? Why do you specify amd64 and not all?" The Architecture field specifies what CPU types the package is designed for. Since this package is a binary package, setting `Architecture: all` would be quite wrong, as it would attempt to run one particular CPU's code regardless of what CPU the user has (so an ARM user [20:36] could install it even if it's amd64 code, but it will probably fail to run). `Architecture: any` might possibly work, but Lubuntu only ships installation images for the amd64 architecture AFAIK, so users of other architectures will never use this application. Thus, `Architecture: amd64` is the most sane choice I can see. [20:36] Simon Quigley (Developer): Still need to look up the bit about `${misc:Depends}` and `${shlibs:Depends}`. [20:58] "Simon Quigley (Developer): "What..." <- What about in the future when we build Calamares for the RPi? [20:59] I think amd64 is wrong there for long-term expansion purposes [20:59] I mean, we build cala on all arches [21:01] Simon Quigley (Developer): In that instance, `Architecture: any` may be the way to go. It just seems wasteful to do `Architecture: any` for now, since it's never going to be used. If we do make an installation image for the RPi, then changing it to any would be best IMO. [21:04] Simon Quigley (Developer): Is it not possible to change architectures later? [21:05] Siq [21:05] (enter instead of tab strikes again!) [21:09] Simon Quigley (Developer): I guess I can see what you're saying, though, just because Intel/AMD has ruled for the last 20 years or so, doesn't mean it will always be that way. SD cards took over floppy disks. Streaming replaced DVD drives. Cellular, cable, and fiber got the advantage over dial-up. Apple is leaving Intel and going for ARM. So I think I actually agree with you now. I'll change it to `Architecture: any`. [21:13] "Simon Quigley (Developer): In..." <- I figure if we're gonna put this through NEW we should prob do all arches [21:13] So yes arch:any [21:14] (Approaching stuff from the standpoint of being ready for the future is a good idea. It's why Debian is prepped for using GNU/Hurd (like actually) or kfreebsd. It's why Linux Mint has a Debian edition in the event Ubuntu dies (which I sure hope it doesn't!). We should be prepped for modern technologies like Intel CPUs to no longer be commonplace, and be ready to change direction should that happen with minimal effort.) [21:17] tsimonq2: Quick question, what does "put this through NEW" mean? [21:24] Simon Quigley (Developer): Also, I'm a bit stuck trying to make the install file. I'll pastebin the error I'm getting, maybe you can tell me what lubuntu-installer-prompt is doing differently from a bunch of our other packaging, or where I've boffo-ed the packaging. [21:25] https://pastebin.com/a6tBR6YU [21:26] My lubuntu-installer-prompt.install file: https://termbin.com/ygfq [21:27] s/our/the/, s/packaging/software we package/ [21:28] "Quick question, what does "put..." <- When you upload a new source package or even upload a source with new binaries on any arch, it goes through a manual review queue [21:29] arraybolt3[m]: Remove the leading / [21:29] From the last line [21:29] I realized the error I pasted doesn't have enough context, here's the whole thing: https://termbin.com/iy9k [21:29] tsimonq2: Will try that [21:32] Still getting a nearly identical error message. [21:39] Simon Quigley (Developer): I see what's happening - the build is placing files under "debian/lubuntu-installer-prompt" rather than under "debian/tmp". I can't see any visible difference between what FeatherPad and lubuntu-installer-prompt are doing in their packaging, so I'm suspecting the source code to be at fault here. I think I can make the install file work with it, but would it be preferable to change the source code? [21:42] (I think I figured it out, needed to add a dh_install override to debian/rules IIUC. Let's find out!) [21:43] Try it out, feel free to send patches if you get it and need to modify the source :] [21:43] s/]/)/ [22:40] Simon Quigley (Developer): Bah, I can't figure it out. CMake is placing the built files in debian/lubuntu-installer-prompt, not debian/tmp, and I cannot figure out how to get it to put the files in the right spot for the install file to find them. Everything just works without the install file. Suggestions? [22:41] Axe the install file then :] [22:41] (Also tried overriding dh_install to use debian/lubuntu-installer-prompt as the source directory, but since the CMake install process put them where they ultimately were supposed to go in the first place, that just kept erroring out. At this point, I really think omitting the install file entirely would be best.) [22:41] s/]/)/ [22:41] OK. [22:49] Simon Quigley (Developer): "What does `${misc:Depends}` and `${shlibs:Depends}` do? Why are they there?" Debhelper is capable of detecting certain package dependencies and inserting them where these variables are located. `${misc:Depends}` contains any dependencies introduced by Debhelper commands, while `${shlibs:Depends}` contains all of the shared library dependencies for an application. They probably could be removed and the [22:49] necessary dependencies manually filled in instead, but it would be a pain, and potentially be unreliable. [22:51] (There's also `${perl:Depends}` for Perl dependencies, but our app doesn't use Perl, so it's not necessary.) [22:57] Simon Quigley (Developer): https://github.com/ArrayBolt3/installer-prompt-packaging Builds Lintian clean, applied all suggested changes, installs and works out of the box first time in a live Lubuntu Kinetic ISO. And I couldn't find "check-all-the-things" for Ubuntu with a quick first try, so that's still to be done. [22:59] s/"/`/, s/"/`/ [23:02] Simon Quigley (Developer): One more test I might should run would be to upload this to a PPA and try it out in RISC-V to see what happens there. [23:24] And I accidentally left the "tar-ignore=.gitignore" option. But we didn't care whether it was there or not, so I'm just going to leave it. [23:25] (PPA build was successful on all arches, RISC-V64 build is in progress on my local system.) [23:25] "Simon Quigley (Developer): "What..." <- You're correct. I'd say keep them [23:25] "Simon Quigley (Developer): https..." <- Sweet! [23:26] Nice work, keep it going :] [23:26] s/]/)/ [23:27] Thanks, I think this is almost ready! [23:27] If not ready. [23:54] Simon Quigley (Developer): Bug report for lubuntu-installer-prompt. https://github.com/lubuntu-team/installer-prompt/issues/1 [23:54] Issue 1 in lubuntu-team/installer-prompt "Display doesn't always render correctly, depending on screen size" [Open]