[05:16] <Lord-Kamina> Nobody's packaged libxml++3 for ubuntu OR debian? wow.
[15:22] <b-rad> 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] <b-rad> 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] <b-rad> 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] <nacc> b-rad: why are you doing something in a PPA that's already done by the archive?
[16:11] <nacc> b-rad: 4.4 is available for trusty (it's the hwe kernel there)
[16:12] <nacc> b-rad: and you can have both 4.4 and 4.15 installed on the same machine in 16.04
[16:12] <b-rad> i provide the entire media tree backported to all previous supported versions
[16:13] <nacc> media tree?
[16:13] <b-rad> the question is not about what is installed on a machine, it is about what is supported in the ppa
[16:13] <b-rad> drivers/media
[16:13] <nacc> b-rad: ... that didn't really answer my question
[16:13] <nacc> you stated "currently for trusty i just copy the xenial 4.4 packages back"
[16:13] <nacc> why ... there are 4.4 packages for trusty already
[16:14] <b-rad> "my" xenial packages with the entire mainline media tree backported and integrated
[16:14] <nacc> 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] <b-rad> 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] <b-rad> if linux-4.15 is treater as a separate package to linux-4.4 then everything is ok
[16:17] <b-rad> but both are "linux" hence my concern
[16:17] <nacc> linux is a source package
[16:19] <b-rad> and you cannot submit lower versions of source packages
[16:19] <nacc> b-rad: yes, but you would't have the same srcpkg multiple times anyways
[16:20] <nacc> b-rad: sorry, i think you need to provide more details for me to help; maybe someone else has more context
[16:32] <cjwatson> 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] <b-rad> thanks cjwatson, that was my fear. So instead of copying back I'll need to change from linux to linux-hwe
[16:33] <b-rad> or rather just use that branch and leave as is
[16:33] <b-rad> was just trying to see if i could prevent some rebuilding
[16:34] <cjwatson> you could also just have multiple PPAs
[16:34] <cjwatson> either strategy should be workable
[16:34] <b-rad> yes, that is still an option i'm entertaining and might be required to keep disk space within limits
[16:34] <cjwatson> well, we can always bump quotas, but either way
[16:35] <b-rad> 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] <b-rad> if i hit the limit i'll message you
[16:43] <cjwatson> b-rad: https://answers.launchpad.net/launchpad/+addquestion for that kind of thing rather than messaging me directly, please
[16:44] <b-rad> will do
[16:58] <Lord-Kamina> cjwatson, you're part of the team who did the ubuntu archive tools, yes?
[17:01] <cjwatson> Yes
[17:02] <Lord-Kamina> 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] <Lord-Kamina> 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] <tsimonq2> Lord-Kamina: There's a flag for that I think.
[17:06] <tsimonq2> I know, I've been in the same situation with copy-package. :/
[17:09] <cjwatson> I can't take bug reports on IRC, sorry
[17:09] <cjwatson> copy-package has a --skip-missing flag but remove-package doesn't
[17:09] <cjwatson> https://bugs.launchpad.net/ubuntu-archive-tools exists
[17:11] <tsimonq2> cjwatson: Bah, in that case, it should simple enough to just contribute the code.
[17:11]  * tsimonq2 works on it
[17:11] <cjwatson> Feel free, thanks
[17:18] <tsimonq2> cjwatson: https://code.launchpad.net/~tsimonq2/ubuntu-archive-tools/skip-missing-remove-package/+merge/351370
[17:20] <tsimonq2> Lord-Kamina: ^
[17:28] <cjwatson> Doesn't work, I'm afraid.  I've commented.
[17:31] <tsimonq2> cjwatson: Oh, perhaps there just needs to be "continue" below print("Skipping").
[17:31] <tsimonq2> But I'll do what you commented.
[17:33] <cjwatson> tsimonq2: "continue" there wouldn't help, because it's not inside the loop.
[17:33] <tsimonq2> Right.
[17:33] <tsimonq2> Ah, got it now.
[17:34] <cjwatson> 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] <tsimonq2> 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] <cjwatson> I don't understand that remark, but this looks better.  Will ponder a little more.
[17:38] <tsimonq2> OK.
[17:41] <cjwatson> You have another review.
[17:41] <cjwatson> If you could possibly try out the code before asking for review that would be awesome ;-)
[17:42] <cjwatson> (I use neovim with the 'ale' plugin for this.  Dunno what editor you use though.)
[17:48] <Lord-Kamina> Awesome. Thanks!
[17:51] <Lord-Kamina> I'm currently trying to sort out the mess that is icu-le-hb
[17:56] <tsimonq2> cjwatson: I just use plain Vim, but I'll look around.
[17:56] <tsimonq2> Thanks.
[17:57] <cjwatson> I think ale works with vim too, though I haven't tried
[18:07] <Lord-Kamina> Is it possible to compile gcc-7 using just gcc 4.8?
[18:08] <cjwatson> You'd have to ask GCC people.
[18:19] <tsimonq2> cjwatson: Better?
[18:22] <cjwatson> tsimonq2: Try "./remove-package --help" ...
[18:22] <tsimonq2> grr
[18:22] <tsimonq2> Sorry.
[18:22] <cjwatson> (I do have some code to convert more scripts to argparse, but let's not do that as part of this)
[18:23] <tsimonq2> cjwatson: .
[18:24] <cjwatson> tsimonq2: Looks good now, thanks.  Merged.
[18:25] <tsimonq2> Thanks!
[18:25] <tsimonq2> Lord-Kamina: ^
[18:27] <Lord-Kamina> Awesome, thank you!
[18:33] <Lord-Kamina> 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] <Lord-Kamina> Like, 4.8 depends on 5, 4.9 depends on 5 and 6, 5 depends on 5, 6, 7...?
[18:33] <cjwatson> No
[18:33] <cjwatson> Ask somebody who maintains them
[18:34] <Lord-Kamina> I asked you because you appear among the team members.
[18:34] <cjwatson> (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] <Lord-Kamina> Anyway... I'll find somebody else, thanks anyway.
[18:34] <cjwatson> Oh, that's weird historical reasons
[18:34] <cjwatson> I don't actually maintain it
[18:35] <cjwatson> I actually forget why, it was probably so that I could see private builds in one of those PPAs at one point
[18:35] <Lord-Kamina> Who should I actually ask, Matthias Klose?
[18:35] <cjwatson> He'd be your best bet
[18:35] <cjwatson> The test archive is basically a playground I think