[03:16] teward: wrt subprocess.run, It doesn't do what I want it to do when I would have in the past used a command line with & at the end (works with shell=True of course but we don't want that) [03:17] if you're trying to fork something into the background that can cause a problem [03:17] OvenWerks: the other option is to just straight string call it but that's... not the best option either. You could ask sarnold's opinion [03:17] right now i'm heading to bed i'm tired [03:17] teward: we have some "convenience" buttons that start things like a mixer [03:17] good night. [03:17] tomorrow [03:18] I'll keep looking [03:18] OvenWerks: we can revert that bit, if yuo really want it included in the NEW version, you or Eickmeyer can ask vorlon in #ubuntu-release to reject the upload on those grounds. [03:18] but that's your guys call. [03:18] * teward needs sleep. [03:29] subprocess.Popen(["/bin/mycmd", "myarg"]).pid did the trick. [13:56] eesh popen's a low level operation but yeah... [13:56] that can be headachey [13:57] just tread lightly :p [13:57] OvenWerks: if you need me to reupload let me know [14:03] I asked AAs to NACK the package that WAS uploaded because of this bug [14:03] Eickmeyer: OvenWerks: ***Test the hell out of this as is - no additional changes*** before I consider it ready for sponsoring again. [14:44] no additioanl changes except bugfixes* [14:54] teward: "the package" so far as I know ubuntustudio-menu-add was ok as of yesterday about noon. After that I started working on ubuntustudio-controls to remove all shell=True [14:55] @ovenWerks are you saying that the subprocess.Popen call was not needed? [14:55] it sounded from your messages that the subprocess.run was not behaving right [14:55] and for some cases it probably won't [14:55] but i need to know specifically (because your statements were unclear) as to the state of that package. [14:55] teward: so all comments after about 12:30 (probably 1530 your time) are in reguard to -controls [14:55] ack [14:55] OK [14:55] i wasn't sure ;) [14:56] but i'll RESPONSOR this and ask seb to review it, then apologize to the AAs for the confusion [14:56] There have been no changes to menu-add [14:56] Eickmeyer: there was another two packages on the radar, weren't there? [14:56] that you bugged me about [14:59] teward: Yes, dpf-plugins and pulseeffects (though that one isn't mine, just wanted to get the ball rolling for the dev). [14:59] dpf-plugins *is* yours though yes? [15:00] teward: Well, I didn't write it, but I did the packaging. [15:03] well we can say the same for ubuntustudio-menu-add too ;) [15:04] but i mean it had your bootprints in it :P [15:04] Eickmeyer: link me that dpf-plugins bug again here please? [15:04] and sorry for switching between TG and IRC like i'm bouncing between things :p [15:08] teward: Standby... [15:11] teward: bug 1829562 [15:11] bug 1829562 in Ubuntu Studio "[Needs Packaging] DPF-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1829562 [19:16] sarnold: you around? [19:16] (I know the answer lol) [19:16] teward: pong [19:16] sarnold: teach Eickmeyer how to have the same version of a package in multiple releases per Security Patch Prep guidelines for version strings [19:16] i.e. [19:16] 3.0 in Eoan [19:16] can't be 3.0 in Disco [19:17] iut needs to be 3.0~0ubuntu0.18.10.1 etc. [19:17] here's the table the security team uses https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging [19:17] probably not-security-people have different rules but this should be pretty good to give the flavour of how it works :) [19:17] sarnold: and for native packages without debrevs? [19:17] in this case its' ubuntustudio-installer that is a bare version string [19:18] and how that'd affect Eoan too [19:18] AIUI you'd have to 'decrement' it in lower releases [19:18] but i usually avoid native packages :) [19:18] disco: 0.02, Pocket: release, Component: universe [19:18] eoan: 0.04, Pocket: release, Component: universe [19:18] these? [19:18] sarnold: yep [19:18] SRU request to 0.04 -> disco [19:18] but sec team kinda sets guidelines on the v strings :) [19:19] AH DAMN [19:19] just spilled my coffee over me >.< [19:20] uhoh [19:20] Dang. [19:20] sarnold: how would the bare versions be handled for 'backports' direct [19:20] not sure how SRU would handle that but from a version string side I see it being a problem [19:21] ~18.04.1, ~18.10.1, etc probably [19:21] yeah that's what i was going to say [19:21] because 0.04~19.04.1 < 0.04 [19:21] sarnold: Should I make it 0.04~19.04.1? [19:21] Oh, nm. [19:21] for a disco sru you probably would need to yes. [19:21] ASSUMING 0.04 is already in Eoan [19:21] Well, it's a native package, so that's an issue. [19:22] 0.04 is already in eoan. Uploaded it myself. [19:22] and I don't know if the sru team would want an 'ubuntu' in there, or if this package exists only in ubuntu, if it's alright to skip it [19:22] yeah this is one of those edge cases that I don't see coming up much [19:22] Package exists only in Ubuntu. [19:22] Completely native, not intended for Debian under any circumstance. [19:24] sarnold: If I put 0.04~19.04.1 since it's native, would that work? [19:24] it should, native or not it's merely how dpkg pays attention to what version is where and such I think [19:24] but that's probably something SRU might balk at [19:25] not sure [19:25] Not the first time we've SRU'd something native. [19:26] I don't have a whole lot of experience with sru rules, but that version number would at least keep dpkg happy :) [19:26] yep [19:26] and wouldn't be rejected by the upload system [19:28] sarnold, teward: For example, the version of ubuntustudio-controls initially included in disco was 1.7. The SRU'd version is 1.7.1. So, what would happen if I made the SRU for ubuntustudio-installer 0.03? That hasn't been used yet. [19:28] did launchpad ever see a version 0.03? [19:28] launchpad won't let you reuse version numbers [19:29] sarnold: Oh, yes, you're right, it probably did see 0.03. So, if I used the ~19.04.1 suffix, that would do the trick? [19:29] yes, it would [19:29] yes [19:29] ok. I'll do that. [19:30] Eickmeyer: 0.04 > 0.04~19.04.1 > 0.04~18.10.1 > ... [19:30] I see. [19:30] which is a dpkg-ism with how ~ behaves in the string :) [19:30] * Eickmeyer will work on this when he gets back from some minor grocery shopping [20:58] OvenWerks: teward, Eickmeyer, looking to ubuntustudio-menu-add there is no COPYING file nor mention of copyright holder or license outside of the debian dir, that seems suboptimal [21:32] copyright ubuntustudio 2019, gpl2+ [21:33] (According to the about box) [21:33] OvenWerks: seb128 is referring to a /COPYING file and a /LICENSE file. [21:34] Though, this has never been a requirement for any of our other native packages, so I'm willing to appeal this one. [21:34] Yeah, I have no idea how to create these. [21:34] what format they should be etc. [21:35] I'm not 100% sure on that one. I think the /LICENSE file just needs to contain the entire text of GPL2. [21:35] -controls has a COPYING file [21:36] in -controls the COPYING file has that [21:36] Ok, then just copy the COPYING file and that should do it. [21:40] OvenWerks: Want me to do that? [21:47] OvenWerks: Nm, put all of that in. I'll let teward know it's done. [21:49] Done. teward: new upload ready.