[02:17] <ehashman> hi I'm a DD and someone randomly RM'd my package from bionic without telling me, can someone help me get it back in
[02:19] <sarnold> ehashman: which package?
[02:20] <ehashman> sarnold: leiningen
[02:21] <ehashman> all the deps need to get synced too I think
[02:22] <ehashman> source package name is "leiningen-clojure"
[02:22] <ehashman> it's all stuff in universe
[02:22] <sarnold> ahh I wondered ... leiningen looks like it was removed in 2014, hehe
[02:22] <ehashman> yeah
[02:22] <ehashman> I revived it
[02:22] <tsimonq2> "(From Debian) RoM; obsolete; request from upstream; Debian bug #761305"
[02:23] <tsimonq2> Oh
[02:23] <tsimonq2> ehashman: From doko: "see Debian #889533, leiningen-clojure not ready for release. remove it + rdeps (cider)"
[02:23] <sarnold> https://launchpad.net/ubuntu/+source/leiningen-clojure/+publishinghistory
[02:23] <dpb1> heh
[02:24] <ehashman> tsimonq2: yes, I'm working on that
[02:24] <sarnold> ehashman: strictly speaking, at this point in the bionic cycle, it might be a fair amount of effort to get it back in. :/ we're well past feature freeze date, so a featurefreeze exception bug would probably need to be prepared
[02:25] <ehashman> so the issue is that it got RM'd >2 weeks ago but I only found out today
[02:25] <ehashman> I got everything rebuilding (needed a new clojure because the 1.9 upgrade broke it) but Java 9 seemed to introduce some perf regressions so I was holding off on upload
[02:25] <sarnold> but like you said, it's a universe package, hopefully it wouldn't be too onerous..
[02:25] <tsimonq2> sarnold: Feature Freeze doesn't apply to Source NEW unless it's already in the distro
[02:26] <tsimonq2> Although that's iffy.
[02:26] <sarnold> tsimonq2: *whooooosh*  :D
[02:26] <ehashman> I would have gotten to this a lot sooner had I known
[02:26] <tsimonq2> ehashman: I can sync it as soon as you have a solution uploaded.
[02:26] <sarnold> slangasek: around? ^^
[02:27] <ehashman> tsimonq2: thank you muchly, I will send you the list of everything once I get it uploaded and that bug closed, I've prioritized it for tonight
[02:27] <tsimonq2> ehashman: OK; if I don't respond on IRC, tsimonq2@ubuntu.com
[02:28] <ehashman> thanks!!
[02:28] <tsimonq2> Thanks for fixing the package!
[02:28] <xnox> tjaalton, why has freeipa bump bind9 dep? ubuntu doesn't have that point release bind merged yet.... or maybe ahasenack could quickly merge the new bind9 point release from debian?
[02:29] <xnox> currently freeipa is not installable in bionic-proposed.
[02:29] <sarnold> that's one way to cut down on bug reports.. :)
[03:19] <tjaalton> xnox: because the current version would crash on start if confured via ipa-dns-install
[03:20] <tjaalton> uh
[03:20] <tjaalton> configured
[03:21] <tjaalton> and i merged and pushed the update but it was dirty and got rejected :)
[03:21] <tjaalton> i'll file a ffe
[03:21] <tjaalton> slangasek: ^
[03:22] <slangasek> ok
[03:24] <slangasek> sarnold: not sure what the tag is for; if it's synced, it goes in the new queue and can be reviewed, but not before then?
[03:24] <sarnold> slangasek: thanks :)
[09:24] <baltix-linux> Hi
[09:26] <baltix-linux> cyphermox: hi, I'm finishing ubiquity and ubiquity-slideshow translations, when you will update tranlations from launchpad for final 18.04 release?
[09:37] <Mirv> deadline was 9.5h ago theoretically, so it depends on whether there was some scheduled export or if cyphermox will be doing that manually later
[09:38] <Mirv> s/9.5/12.5/
[09:46] <Mirv> juliank: if you can help/advise gunnarhj on cryptsetup at https://bugs.debian.org/688735 , please do. it's quite visible i18n problem and if the eventual patch is clean enough I'd think we could consider backporting it to 18.04 eventually too.
[09:55] <baltix-linux> Mirv: thanks, I found info about dead just today, so, it would be nice if my work was included, because now several strings in ubiquity translations are in english  :)
[09:56] <baltix-linux> Mirv: in Lithuanian ubiquity translations :)
[09:57] <baltix-linux> cyphermox: so, will you do manual ubiquity translation export from launchpad today?
[09:59] <Mirv> baltix-linux: he'll wake up within 5 hours or so, so we'll find out then
[10:12] <juliank> Mirv: I don't know, not this week certainly
[11:56] <rbasak> xnox: do you have an opinion on bug 1712817 please?
[11:57] <rbasak> Following my comment, on second thoughts, perhaps Debian should arrange invoke-rc.d not to fail if a service is disabled by the user, effectively providing the same behaviour as a policy-rc.d based disablement?
[12:47] <xnox> rbasak, the description sounds valid. i believe i have hit something similar before, thus yeah a fix to debhelper for this class of issues would be most welcomed.
[12:47] <rbasak> xnox: thanks. debhelper, or invoke-rc.d?
[12:47] <rbasak> xnox: and may I quote that message in the bug? :)
[12:48] <xnox> rbasak, my understanding was that maintainer scripts that are generated, do attempt to check if a thing was "enabled and active" before the upgrade; and post upgrade. But maybe they only do so for systemd native units, and not for init.d->systemd units.
[12:48] <xnox> rbasak, specifically for ubuntu, i think we need not any init.d / invoke-rc.d stuff, as we can be simply using policy + deb_systemd_helper only.....
[12:49] <xnox> rbasak, sure, about quotes.
[12:49] <xnox> 😃
[12:50] <rbasak> Thanks
[12:50] <rbasak> I've updated the bug and added a debhelper task.
[13:29] <LocutusOfBorg> tjaalton, are you trying bind9 rebuilds / transition=
[13:29] <LocutusOfBorg> ?
[13:56] <tjaalton> LocutusOfBorg: what transition?
[14:01] <tjaalton> isc-dhcp would need to be rebuilt, that's all
[14:01] <tjaalton> bind9-dyndb-ldap too of course
[14:20] <LocutusOfBorg> so tjaalton you will take care of freeipa migration? thanks!
[14:21] <tjaalton> sure, if it's accepted
[14:25] <tjaalton> bind 9.12 will bundle all libs in bind-libs, so no more shlib bump rebuilds..
[14:41]  * mvo hugs rbalint for the latest u-u fixes
[14:52] <didrocks> mvo: hey! I have a small question about do-release-upgrade. If I get some fixes in do-release-upgrade in bionic, that will end up automatically in the tarball when d-r-u new version is updated for 16.04 users?
[14:56] <mvo> didrocks: correct, its a custom upload type
[14:56] <mvo> didrocks: you speak aobut do-release-upgrade itself, not some dependencies of it, right?
[14:57] <didrocks> mvo: yeah, do-release-upgrade itself :) So, basically, I can just MP at some point, get that into bionic, and then, don't worry, correct?
[15:03] <mvo> didrocks: yes, the build includes a custom LP upload that makes it end up in the right place
[15:04] <mvo> jbicha: thanks for your c-n-f upload! would you mind doing a MP with your fix to lp:command-not-found as well? that would be great so that the lp code branch and the archive are in sync
[15:06] <didrocks> mvo: excellent! Thanks :)
[15:08] <jbicha> mvo: I just pushed directly now
[15:14] <mvo> jbicha: thank you!
[15:21] <rbasak> Is there a place to find the URL to the latest test rebuild?
[15:21] <rbasak> I find myself always searching for doko's email. I wonder if there's a better wayl
[15:21] <rbasak> way.
[15:21] <rbasak> Oh
[15:21] <rbasak> http://qa.ubuntuwire.org/ftbfs/rebuilds/ maybe
[15:27] <rbasak> balloons: around? Can you help with golang-github-juju-testing please?
[15:28] <balloons> rbasak, yea, I've been watching mongodb
[15:28] <balloons> rbasak, what do you need?
[15:29] <rbasak> Error parsing command line: unrecognised option '--nohttpinterface'
[15:29] <rbasak> I suspect that's been dropped in 3.6.
[15:29] <rbasak> balloons: is golang-github-juju-testing still needed?
[15:29] <rbasak> I don't see any rdepends.
[15:29] <rbasak> Was it for the former archive juju package for example?
[15:30] <rbasak> Hmm.
[15:30] <rbasak> It's not Ubuntu-only. It was synced from Debian.
[15:30] <balloons> rbasak, ahh, it was added as build-depends for juju I assume
[15:30] <balloons> rbasak, yes, we synced golang libs to debian
[15:31] <rbasak> balloons: so it can be removed now?
[15:31] <balloons> rbasak, if no one else is depending on it and it ftbfs we could update it, but it makes just as much sense to drop it
[15:32] <balloons> rbasak, so yes, +1
[15:32] <rbasak> Unfortunately if it's synced from Debian I'm not sure the AAs will want to just remove it.
[15:33] <rbasak> I'm not sure to what extent it should be removed from Debian.
[15:33] <balloons> rbasak, interesting.. it's only in bionic
[15:33] <cjwatson> It was only added there very recently.
[15:33] <rbasak> Depends on the Debian Go packaging team's policies I guess.
[15:33] <rbasak> Maybe a force-badtest would be acceptable though?
[15:33] <balloons> there's several new juju libs in bionic
[15:34] <rbasak> I suppose the summary is that the package needs its dep8 test updating to work against mongodb 3.6.
[15:34] <balloons> That's why I didn't recognize it. I'm not sure who did those uploads
[15:34] <cjwatson> You can see it in https://tracker.debian.org/pkg/golang-github-juju-testing
[15:35] <cjwatson> The sync to Ubuntu was automatic
[15:36] <balloons> right. So mwhudson and I were working through juju's golang needs and getting them into debian
[15:37] <balloons> But that was some time ago, and I set it aside to pursue the snap
[15:38] <rbasak> I think I can just drop the --nohttpinterface
[15:38] <rbasak> AFAICT, the (deprecated) HTTP interface was removed in 3.6.
[15:38] <rbasak> So presumably not specifying that will result in the same behaviour in 3.6.
[15:45] <rbasak> Aha: https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111
[15:52] <balloons> rbasak, yes, pulling in the newer version makes more sense if you want it to work with 3.6
[15:53] <rbasak> balloons: I'm looking at just cherry-picking that fix.
[15:53] <balloons> ahh right..
[15:53] <balloons> it's actually tiny
[15:53] <rbasak> I don't see the point in pulling in the newer version if nobody actually needs it.
[15:54] <rbasak> The package might be a candidate for orphaning in Debian.
[15:55] <balloons> rbasak, there's many new github-juju*-dev packages in bionic
[15:55] <balloons> 15 looks like?
[15:58] <rbasak> I got a pass with this: http://paste.ubuntu.com/p/kVK4Fdn3Ry/
[15:59] <cjwatson> orphaning> seems like a bizarre response in the case of something that was first uploaded a couple of months ago
[15:59] <cjwatson> orphaning is a response to not being maintained, which normally requires longer than that
[16:00] <rbasak> cjwatson: yeah, though AIUI balloons and mwhudson are no longer interested in maintaining the package in Debian (or Ubuntu) because they've switched to snaps instead?
[16:00] <cjwatson> if it shouldn't be in Debian then the correct response would be to ask the maintainer about having it removed
[16:00] <rbasak> And it's a Juju-specific package.
[16:00] <cjwatson> rbasak: they're not the Debian maintainer, so that's not terribly relevant
[16:00] <cjwatson> they weren't maintaining it in Debian to begin with :)
[16:00] <rbasak> I'm under the impression that mwhudson is a member of the Go packaging team in Debian.
[16:01] <balloons> yes, indeed. That's why I was surprised to see it
[16:01] <bdmurray> andyrock: What release of Ubuntu would you want a version of plymouth to test with?
[16:01] <cjwatson> perhaps, but he has no involvement in the changelog of that package.
[16:01] <rbasak> Oh
[16:01] <rbasak> I missed that.
[16:01] <andyrock> bionic is fine
[16:01] <rbasak> I assumed it was uploaded via balloons and mwhudson.
[16:01] <cjwatson> I certainly would not assume that e.g. everything in the Python modules packaging team was maintained by me, even though I could work on if if I wanted
[16:01] <cjwatson> *on it if
[16:01] <balloons> right. To be clear, I have no knowledge of those packages, and as cjwatson pointed out, mwhudson didn't push it either
[16:02] <andyrock> bdmurray: I can test it in few hours
[16:02] <rbasak> Can I get a peer review from someone for http://paste.ubuntu.com/p/kVK4Fdn3Ry/ please?
[16:02] <rbasak> It builds and passes autopkgtest for me locally. And I locally reproduced the current failure, too.
[16:03] <cjwatson> rbasak: LGTM
[16:03] <rbasak> Thanks. I'll upload.
[16:03] <rbasak> And submittodebian.
[16:03] <rbasak> That should unstick mongodb 3.6 hopefully.
[16:09] <balloons> thanks rbasak
[16:10] <rbasak> balloons: np. It has built. Now we wait a couple of publisher runs I think.
[16:10] <rbasak> balloons: I'm nearing EOD now, so I'll have to resume on Monday to get this landed if necessary.
[16:10] <balloons> rbasak, no worries. I very much appreciate you getting this landed, and doing so quickly
[16:11] <balloons> rbasak, we'll plan to get juju 2.4-beta1 first thing next week as weel
[19:18] <jbicha> slangasek: for an especially serious example of the GNOME Software issue, see bug 1756788
[19:19] <jbicha> there is a shiny "Remove" button in the Installed list in GNOME Software and eventually some users are going to click that button
[19:19] <slangasek> heh
[19:19] <jbicha> when it's clicked, GNOME Software happily removes the package using PackageKit
[19:20] <jbicha> it the package is say, update-manager, then PackageKit will remove ubuntu-desktop because ubuntu-desktop has depends: update-manager set
[19:20] <jbicha> GNOME Software does not tell the user that things like this are happening
[19:20] <slangasek> right; I share bdmurray's unease with the shape of the solution, however
[19:20] <jbicha> but if we add the compulsory_for_desktop field to AppStream metadta, then the app is marked as a System Application and we avoid this issue
[19:21] <slangasek> i.e. we work around a bug in GNOME Software by having to touch every package to manually tell it to not be dumb
[19:21] <jbicha> the design of GNOME Software is a much larger and older issue than we can hope to change much before bionic's release :(
[19:21] <slangasek> why ship these appstream files in the individual packages instead of in gnome-software itself?
[19:22] <jbicha> because gnome-software isn't the source of packages
[19:22] <slangasek> no, it's the source of the damage
[19:22] <jbicha> I mean sure it could ship its own whitelists for this issue
[19:23] <jbicha> but appstream metadata in general should be shipped with the individual app
[19:23] <jbicha> the compulsory field is controversial; some users really want to remove system apps
[19:23] <slangasek> if there's a reason to ship that metadata in the first place, which it's unclear to me that there is other than this bug
[19:24] <slangasek> and the "compulsory"ness is a function of the flavor metapackage, not of the application
[19:25] <jbicha> yes
[19:25] <jbicha> you should probably talk to ximion if you have concerns about appstream ;)
[19:25] <slangasek> which means that if the seeds change to drop a package, and the package's appstream is not updated, it becomes buggy again
[19:26] <slangasek> I don't think the concern I'm expressing is about appstream; it's about relying on appstream to work around gnome software not dtrt with distro policy
[19:27] <jbicha> ok, then talk to hughsie or Laney or robert_ancell ;)
[19:27] <slangasek> Laney: hi I talk to you
[19:27] <slangasek> :)
[19:27] <jbicha> lol, he's probably trying to enjoy his weekend
[19:28] <slangasek> he's probably used to me spoiling that
[19:29] <jbicha> yeah, I guess this is really bad for Lubuntu if Lubuntu users want to try to use GNOME Software
[19:30] <jbicha> yet more fun from Lubuntu not wanting to use Recommends yet :)
[19:30] <jbicha> we've had this issue since 2016 though
[19:32] <jbicha> ximion: the context is https://lists.ubuntu.com/archives/ubuntu-devel/2018-April/040278.html
[19:36] <bdmurray> Isn't it bad for any flavor that uses GNOME software though?
[19:37] <ximion> jbicha: I have seen that mail :-)
[19:37] <ximion> slangasek: what is compulsory or not is set by the upstream project, usually
[19:37] <slangasek> ximion: that's nonsense
[19:38] <slangasek> we as a distribution define what is compulsory for our desktop flavors
[19:38] <ximion> GNOME Software intentionally has no idea about what the distribution does, and I am pretty sure that hughsie wouldn't be happy to implement anything that involves parsing a lot of package dependencies
[19:38] <slangasek> and that definition lives in the metapackages, not in the individual components
[19:39] <jbicha> bdmurray: it's not too bad for Budgie or Unity which have pretty similar Depends to Ubuntu
[19:39] <ximion> that was my argument - sort of - when we added the feature a while back, but certain things like the GNOME Shell etc. are always compulsory, and that is what compulsory_for_desktop should primarily be used for
[19:39] <jbicha> but   apt show lubuntu-desktop  is a bit horrifying when considering this issue
[19:40] <ximion> i.e. stuff that you would only display in the software center to e.g. display addons, but which you would otherwise not even display there because it essentially is a system component
[19:40] <jbicha> ximion: off-topic, but do you know why there is an LXDE warning here? http://appstream.ubuntu.com/bionic/main/issues/update-manager.html
[19:41] <slangasek> ximion: I think juliank's proposal is that something could instead synthesize the 'compulsory' bits from apt metadata and inject that information into gnome-software, perhaps via appstream; but that would require us to be able to provide appstream "overrides" for apps that do ship their own appstream data for other reasons
[19:41] <slangasek> I'm not sure if that's supported?
[19:42] <ximion> jbicha: apparently LXDE wasn't registered as a DE when the list of environments was last updated... I fixed this upstream now, thanks for noticing!
[19:42] <jbicha> ximion: which upstream? asgen?
[19:43] <jbicha> (update-manager and software-properties are the first and only things to use compulsory for LXDE that I can see)
[19:45] <ximion> jbicha: AppStream itself - you can use LXDE as value though, this is just a validation warning (so it won't filter LXDE out)
[19:47] <ximion> slangasek: we support something like that (overriding and extending metadata) - this would require APT to have detailed knowledge on which packages are important (essentially treating metapackages like ubuntu-desktop specially) and it would also need to know how to write AppStream metadata
[19:48] <ximion> we could in theory also have the appstream-generator read the Germinate seed files, and have it synthesize compuksory tags for packages with components that are explicitly mentioned in there
[19:49]  * ximion can't reply to stuff on ubuntu-devel or ubuntu-desktop though with proposals like that
[19:49] <juliank> oh, missed the discussion here
[19:50] <jbicha> (sorry I forked the conversation)
[19:52] <slangasek> ximion: we have lots of knowledge in apt already about which packages are special; it's kind of meant to be authoritative about this ;)
[19:53] <ximion> slangasek: the regular standard/essential/etc. priorities for packages don't usually apply to desktop metapackages though, like ubuntu-desktop, because you sometimes want a different DE
[19:53] <ximion> or do you really have rules like "if that package is installed, it should stay installed" somewhere?
[19:54] <juliank> ximion: But we can special case <foo>-desktop
[19:54] <juliank> And yes, we do, but we use it for more important stuff
[19:54] <ximion> I remember that in the past apt would let mre remove any Ubuntu metapackage without any problems
[19:54] <slangasek> ximion: we do have such rules in the release upgrader.  I don't think a high-level frontend like gnome software should touch any desktop metapackages, and if you really want to do that you can use apt from the commandline
[19:55] <ximion> I agree it shouldn't remove them, but as of now, GNOME Software has no way of knowing that ubuntu-desktop is special
[19:55] <ximion> PackageKit is essentially as smart as apt on the command-line here
[19:56] <juliank> is it?
[19:56] <ximion> jup - "smart"
[19:59] <jbicha> apt at least tells you what it's doing (although lots of users don't understand the significance of 'ubuntu-desktop' in its output)
[20:04] <jbicha> bdmurray: did you see https://code.launchpad.net/~jbicha/apport/drop-py2/+merge/343218 or did you want to wait for Chaotic for that?
[20:05] <ginggs> tsimonq2: nodejs  8.11.1~dfsg-2 was uploaded to unstable
[20:06] <tsimonq2> ginggs: You can follow through with the transition yourself? ;)
[20:08] <ginggs> tsimonq2: sync it
[20:09] <tsimonq2> ginggs: No you. :P
[20:12] <ximion> jbicha: PK would tell you that, but this information not showing up is a GNOME design decision
[20:12] <ximion> (AFAIK KDE Discover started to display that information for updates, at least)
[20:13] <slangasek> ginggs, tsimonq2: don't worry, nodejs is seeded on kubuntu, I'll reject with prejudice :P
[20:13] <ximion> some smart mechanism to prevent desktop metapackage removals would be nice
[20:14] <ginggs> tsimonq2: it's probably a good idea for us to not have a version from experimental - there's probably very little that's changed since the last version - and it's weekend and the autopkgtest queues are empty
[20:14] <ginggs> i'll help with the migration if slangasek let's it in
[20:15] <ginggs> *lets - aargh
[20:15] <slangasek> ginggs: final freeze and it's seeded, you're going to have to have a specific rationale in terms of source changes for me to let it in rather than just the upload target listed in debian/changelog
[20:15] <ginggs> tsimonq2: will you take care of that?
[20:20] <jbicha> ginggs: it won't even build on bionic unless you also sync http-parser. you probably do not want the new version of nodejs
[20:20] <tsimonq2> slangasek: hahahaha
[20:20] <tsimonq2> ginggs: No. :P
[20:22] <tsimonq2> I won't touch it with a ten foot pole.
[20:26] <ginggs> jbicha: I do not want any version of nodejs :p
[20:27] <jbicha> ginggs: how about haskell?
[20:28] <ginggs> jbicha: not my thing either
[20:54] <tsimonq2> Funny we talk about new transitions... *nudges acheronuk*
[20:55] <tsimonq2> I totally don't plan on doing a Qt transition last minute... :P
[20:56] <tsimonq2> (/s)