=== DLange is now known as Guest7665 === DLange_ is now known as Guest38389 [05:16] Nobody's packaged libxml++3 for ubuntu OR debian? wow. === DLange__ is now known as DLange === blahdeblah_ is now known as blahdeblah [15:22] in the spirit of not messing up my ppa, if I include newer kernels in a particular series would that trigger the 'no lower versions' bit on launchpad? [15:23] for example, xenial original is 4.4 and hwe is now 4.15. Can 4.4 and 4.15 both exist and I can include virtual packages pointing to either with the hwe tag? or must I modify the metadata (and not just copy back) to include the hwe tags in the release itself? [15:26] currently for trusty i just copy the xenial 4.4 packages back, and I'd like to do that to tail hwe kernels on future distros for lts's while the original stock kernel is followed [16:11] b-rad: why are you doing something in a PPA that's already done by the archive? [16:11] b-rad: 4.4 is available for trusty (it's the hwe kernel there) [16:12] b-rad: and you can have both 4.4 and 4.15 installed on the same machine in 16.04 [16:12] i provide the entire media tree backported to all previous supported versions [16:13] media tree? [16:13] the question is not about what is installed on a machine, it is about what is supported in the ppa [16:13] drivers/media [16:13] b-rad: ... that didn't really answer my question [16:13] you stated "currently for trusty i just copy the xenial 4.4 packages back" [16:13] why ... there are 4.4 packages for trusty already [16:14] "my" xenial packages with the entire mainline media tree backported and integrated [16:14] b-rad: and to be clear, the 'versions' on launchpad you are referring to (i'm not sure which you are, tbh) is probably about package versions; not kernel versions [16:15] that is what i'm trying to clarify, if linux 4.15 would trigger the versioning limit and prevent future linux 4.4 packages [16:15] if linux-4.15 is treater as a separate package to linux-4.4 then everything is ok [16:17] but both are "linux" hence my concern [16:17] linux is a source package [16:19] and you cannot submit lower versions of source packages [16:19] b-rad: yes, but you would't have the same srcpkg multiple times anyways [16:20] b-rad: sorry, i think you need to provide more details for me to help; maybe someone else has more context [16:32] you can only have one current version of a given source or binary package in a given series in a PPA. If you need to maintain more than one long-term then you need to change the source package name (and also binaries, but that probably isn't a problem in this case since kernel binary packages usually include the version) [16:33] thanks cjwatson, that was my fear. So instead of copying back I'll need to change from linux to linux-hwe [16:33] or rather just use that branch and leave as is [16:33] was just trying to see if i could prevent some rebuilding [16:34] you could also just have multiple PPAs [16:34] either strategy should be workable [16:34] yes, that is still an option i'm entertaining and might be required to keep disk space within limits [16:34] well, we can always bump quotas, but either way [16:35] i should be able to modify my system to support the hwe branches, keeping everything in one place would be preferable for our end users [16:36] if i hit the limit i'll message you === chrisccoulson_ is now known as chrisccoulson [16:43] b-rad: https://answers.launchpad.net/launchpad/+addquestion for that kind of thing rather than messaging me directly, please [16:44] will do [16:58] cjwatson, you're part of the team who did the ubuntu archive tools, yes? [17:01] Yes [17:02] My humble feedback: You guys really need to make it so remove-package doesn't auto-exit if it can't find a package name when you've provided a bunch of them. [17:04] For whatever reason, it won't find all package names shown in the web interface (don't know if that's a bug on the web interface or on package-remove) and when it doesn't find any package, it quits without checking the rest. So it ends up being a sysiphean task, running the script fifty times while removing one or two packages from the command each time. :P [17:06] Lord-Kamina: There's a flag for that I think. [17:06] I know, I've been in the same situation with copy-package. :/ [17:09] I can't take bug reports on IRC, sorry [17:09] copy-package has a --skip-missing flag but remove-package doesn't [17:09] https://bugs.launchpad.net/ubuntu-archive-tools exists [17:11] cjwatson: Bah, in that case, it should simple enough to just contribute the code. [17:11] * tsimonq2 works on it [17:11] Feel free, thanks [17:18] cjwatson: https://code.launchpad.net/~tsimonq2/ubuntu-archive-tools/skip-missing-remove-package/+merge/351370 [17:20] Lord-Kamina: ^ [17:28] Doesn't work, I'm afraid. I've commented. [17:31] cjwatson: Oh, perhaps there just needs to be "continue" below print("Skipping"). [17:31] But I'll do what you commented. [17:33] tsimonq2: "continue" there wouldn't help, because it's not inside the loop. [17:33] Right. [17:33] Ah, got it now. [17:34] And it can't be in the for loop just above that, because you need the exception not to interrupt the find_all_removables generator. [17:37] cjwatson: Except, if the flag isn't given, it won't be passed to that for loop. See my updated code, this seems to be better. [17:38] I don't understand that remark, but this looks better. Will ponder a little more. [17:38] OK. [17:41] You have another review. [17:41] If you could possibly try out the code before asking for review that would be awesome ;-) [17:42] (I use neovim with the 'ale' plugin for this. Dunno what editor you use though.) [17:48] Awesome. Thanks! [17:51] I'm currently trying to sort out the mess that is icu-le-hb [17:56] cjwatson: I just use plain Vim, but I'll look around. [17:56] Thanks. [17:57] I think ale works with vim too, though I haven't tried [18:07] Is it possible to compile gcc-7 using just gcc 4.8? [18:08] You'd have to ask GCC people. [18:19] cjwatson: Better? [18:22] tsimonq2: Try "./remove-package --help" ... [18:22] grr [18:22] Sorry. [18:22] (I do have some code to convert more scripts to argparse, but let's not do that as part of this) [18:23] cjwatson: . [18:24] tsimonq2: Looks good now, thanks. Merged. [18:25] Thanks! [18:25] Lord-Kamina: ^ [18:27] Awesome, thank you! [18:33] cjwatson do you have any idea why the gcc builds on the toolchain test repository all have a source dependency on the higher versions? [18:33] Like, 4.8 depends on 5, 4.9 depends on 5 and 6, 5 depends on 5, 6, 7...? [18:33] No [18:33] Ask somebody who maintains them [18:34] I asked you because you appear among the team members. [18:34] (Just as general policy anyway - it's not very realistic to expect site admins to know about lots of individual PPAs that we don't maintain) [18:34] Anyway... I'll find somebody else, thanks anyway. [18:34] Oh, that's weird historical reasons [18:34] I don't actually maintain it [18:35] I actually forget why, it was probably so that I could see private builds in one of those PPAs at one point [18:35] Who should I actually ask, Matthias Klose? [18:35] He'd be your best bet [18:35] The test archive is basically a playground I think