[02:10] arges, rbasak: anything we can do to get this SRU moving? not being able to use apport is Not Good™ https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1764399 [02:10] Launchpad bug 1764399 in lubuntu-meta (Ubuntu Cosmic) "running apport in terminal doesn't work, as python3-launchpadlib is not installed by default in Lubuntu Bionic" [Critical,Fix committed] [02:10] (btw i'm assuming the vanguard roles go by utc date, as it's currently wednesday by said time) [03:15] What would we need to do to make debugging on Ubuntu as nice as it in in Fedora? === maclin1 is now known as maclin [10:24] wxl: looks like it's been accepted since your message. Do you need anything else? [10:24] RAOF: maybe start by stating how exactly Ubuntu is deficient? [10:34] rbasak: Oh, huh. My second line didn't come through. [10:34] rbasak: Specifically - on Fedora, when you start gdb it'll give you the `dnf debug-install` line to get the debugging info for all the relevant libraries. [10:35] rbasak: And then once you've got them installed, you get source listings in gdb for everything. [10:39] That sounds handy [10:39] I guess that just needs implementing for Ubuntu? [10:39] I can't imagine that the underlying mechanism is particularly exclusive to one distribution [10:39] RAOF: I filed an apport bug for that [10:40] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1747644 [10:40] Launchpad bug 1747644 in apport (Ubuntu) "apport-retrace package should automatically add the debugsymbol repository" [Low,Confirmed] [10:44] hi all [10:44] https://wiki.ubuntu.com/StableReleaseUpdates [10:44] ^^ just read it, microreleases are fine [10:46] julian: ping [13:05] hey fellow packagers, I want to remove a binary from a src, but it has a special twist this time [13:05] normally I'd breaks/replaces from the main package that now takes over the functionality [13:06] the special part this time is that it is not exactly taken over - so it might be discussion worthy if "replaces" would be correct (it would get it uninstalled thou which is what we want) [13:06] now the more special and why I ask [13:06] I'd want the postrm of the old package that is removed NOT to be executed [13:07] it had modified config files and would restore them back, I'd prefer if there would be a way to eliminate it without that [13:07] I currently lean towards trying a transitional package that will replace it [13:07] but if there is a known best approach to the scenario described above let me know [13:08] TL;DR: src:A want to get rid of binary A-1, but NOT have postrm of A-1 be processed [13:09] tricky [13:11] If there is no best-known-approach I'm fine to find out - I just want to avoid puzzling just to be told "nah usually done that way" :-) [13:16] I believe that this is a situation where there is no good answer. I have once in the past resorted to manually removing the postrm from my package's preinst, but obviously you have to be extremely careful about that sort of nonsense ... [13:17] (And in fact I think that may have been an older version of the same package, rather than a different package that I was replacing) [13:17] cjwatson: thanks for the example [13:18] I'll for now go and test a few variants that come to my mind [13:18] worst case I'm back here even more confused in a bit :-) [15:18] rbasak, nacc: How is the Git importer working out for packages? [15:18] Lubuntu wants to try importing our packages if that's OK. [15:19] Our packageset might not be up to date (?) but it would fit super well into our workflow. [15:46] tsimonq2: we can probably whitelist your packages so they all get imported, no problem. But can you explain your use case? The importer might not necessarily fit your workflow. What do you do at the moment? [16:06] rbasak: it's a todo i have to work with the lubuntu devs to explain what the importer does :) [16:06] tsimonq2: would now work? [16:08] rbasak: At the moment, we use Phab.Lubuntu.me to do task tracking internally at Lubuntu, and we have Git repositories for some core packages mirrored there so we can reference them in tasks. [16:08] Right now, when we work on packaging changes that are more than a simple patch, I usually use something like gbp to import the repo and then mirror it on Phab. The goal here would be to have everything mirrored there and have team members (mainly wxl, more in the future) have the ability to submit patches to packages there, where I (or another person with upload access) would review and merge. [16:08] I can handle things on my side as long as it's imported on LP. [16:12] One question I do have is this; can I make commits in the actual Git repo then just tag when I want to upload? How is the actual workflow if I just wanted to use it as a Git remote? [16:12] Because something would be better than nothing right now. [16:13] tsimonq2: the imported repositories are basically read-only, by and large. [16:14] tsimonq2: you *can* provide rich history corresponding to uploads [16:14] tsimonq2: right now, that's only possible with what we call 'upload tags', which are only create-able by folks in ~usd-import-team [16:14] OK. [16:14] Read-only is fine for now, I think. [16:15] we eventually want to be able to get to a point where you can just approve an MP against a branch in the imported repository. Then if you dput the same source-ful contents (Git Tree) as the approved MP, the importer will see that and internally create an upload tag and integrate the MP as rich history (which would also make it "Merged") [16:16] then the only ACL we have to have is who can approve MPs, wich would be tied back to who can upload to the source package in question [16:16] Right. [16:16] So how far away is that? [16:16] https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+ref/importer-abstract-out-upload-tags [16:17] it probably needs some further massage, because it was the last thing I did [16:17] OK. [16:18] but in theory, we're not actually that far away -- we do need some LP work, to get the ACL part in place correctly (afaict, the logic all present in the data model we just need to give a name to the 'upload-capable' alias) [16:18] obviously it's really down to rbasak right now, though :) [16:21] OK; so for now, could a read-only import please be done of all of the packages we explicitly seed that are in Universe? (And additionally, all direct dependencies of the lxqt and lxqt-core binaries) [16:23] tsimonq2: that's something rbasak has to agree to (I technically can do the one-off imports, but the keepup tool is running inside Canonical) [16:27] I agree to do it. But I would like to discuss more to make sure that I think it'll be benefitial rather than problematic. If, after we've discussed, you still think you want it, I wouldn't obstruct that. [16:29] tsimonq2: where does your packaging start? Debian? Or do you maintain the origin packaging yourselves? [16:30] tsimonq2: could you perhaps show me an example that's typical for you? [16:30] rbasak: So for core packages, I would point you at lp:lubuntu-artwork or lp:lubuntu-deefault-settings. [16:31] *lubuntu-default-settings [16:31] tsimonq2: OK. Are those maintained in a VCS somewhere? [16:31] rbasak: good point [16:33] rbasak: Yes. [16:33] (thus the "lp:") [16:33] Sorry otp. Back later. === mhcerri_ is now known as mhcerri [16:53] tsimonq2: sorry, I'm running out of time today. Can we chat more tomorrow? [16:55] rbasak: Sure. [17:02] I should be able to follow along as well === imcleod__ is now known as imcleod === jtaylor_ is now known as jtaylor [19:55] rbasak: nope, thanks. :) [19:55] @VikingRedwolf who else? [19:55] Error: "VikingRedwolf" is not a valid command. [19:56] oops wrong channel