[02:17] 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] ehashman: which package? [02:20] sarnold: leiningen [02:21] all the deps need to get synced too I think [02:22] source package name is "leiningen-clojure" [02:22] it's all stuff in universe [02:22] ahh I wondered ... leiningen looks like it was removed in 2014, hehe [02:22] yeah [02:22] I revived it [02:22] "(From Debian) RoM; obsolete; request from upstream; Debian bug #761305" [02:22] Debian bug 761305 in ftp.debian.org "RM: leiningen: RoM; obsolete; request from upstream" [Normal,Open] http://bugs.debian.org/761305 [02:23] Oh [02:23] ehashman: From doko: "see Debian #889533, leiningen-clojure not ready for release. remove it + rdeps (cider)" [02:23] https://launchpad.net/ubuntu/+source/leiningen-clojure/+publishinghistory [02:23] Debian bug 889533 in src:leiningen-clojure "leiningen-clojure FTBFS with libclojure-java 1.9.0~alpha15-1" [Serious,Open] http://bugs.debian.org/889533 [02:23] heh [02:24] tsimonq2: yes, I'm working on that [02:24] 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] so the issue is that it got RM'd >2 weeks ago but I only found out today [02:25] 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] but like you said, it's a universe package, hopefully it wouldn't be too onerous.. [02:25] sarnold: Feature Freeze doesn't apply to Source NEW unless it's already in the distro [02:26] Although that's iffy. [02:26] tsimonq2: *whooooosh* :D [02:26] I would have gotten to this a lot sooner had I known [02:26] ehashman: I can sync it as soon as you have a solution uploaded. [02:26] slangasek: around? ^^ [02:27] 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] ehashman: OK; if I don't respond on IRC, tsimonq2@ubuntu.com [02:28] thanks!! [02:28] Thanks for fixing the package! [02:28] 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] currently freeipa is not installable in bionic-proposed. [02:29] that's one way to cut down on bug reports.. :) [03:19] xnox: because the current version would crash on start if confured via ipa-dns-install [03:20] uh [03:20] configured [03:21] and i merged and pushed the update but it was dirty and got rejected :) [03:21] i'll file a ffe [03:21] slangasek: ^ [03:22] ok [03:24] 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] slangasek: thanks :) [09:24] Hi [09:26] cyphermox: hi, I'm finishing ubiquity and ubiquity-slideshow translations, when you will update tranlations from launchpad for final 18.04 release? [09:37] 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] s/9.5/12.5/ [09:46] 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:46] Debian bug 688735 in cryptsetup "Some strings need to be set up for i18n" [Wishlist,Open] [09:55] 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] Mirv: in Lithuanian ubiquity translations :) [09:57] cyphermox: so, will you do manual ubiquity translation export from launchpad today? [09:59] baltix-linux: he'll wake up within 5 hours or so, so we'll find out then [10:12] Mirv: I don't know, not this week certainly [11:56] xnox: do you have an opinion on bug 1712817 please? [11:56] bug 1712817 in freeradius (Ubuntu) "postinst fails if the service is disabled via systemd" [Low,Invalid] https://launchpad.net/bugs/1712817 [11:57] 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] 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] xnox: thanks. debhelper, or invoke-rc.d? [12:47] xnox: and may I quote that message in the bug? :) [12:48] 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] 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] rbasak, sure, about quotes. [12:49] 😃 [12:50] Thanks [12:50] I've updated the bug and added a debhelper task. [13:29] tjaalton, are you trying bind9 rebuilds / transition= [13:29] ? [13:56] LocutusOfBorg: what transition? [14:01] isc-dhcp would need to be rebuilt, that's all [14:01] bind9-dyndb-ldap too of course === maclin1 is now known as maclin [14:20] so tjaalton you will take care of freeipa migration? thanks! [14:21] sure, if it's accepted [14:25] 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] 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] didrocks: correct, its a custom upload type [14:56] didrocks: you speak aobut do-release-upgrade itself, not some dependencies of it, right? [14:57] 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] didrocks: yes, the build includes a custom LP upload that makes it end up in the right place [15:04] 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] mvo: excellent! Thanks :) [15:08] mvo: I just pushed directly now [15:14] jbicha: thank you! [15:21] Is there a place to find the URL to the latest test rebuild? [15:21] I find myself always searching for doko's email. I wonder if there's a better wayl [15:21] way. [15:21] Oh [15:21] http://qa.ubuntuwire.org/ftbfs/rebuilds/ maybe [15:27] balloons: around? Can you help with golang-github-juju-testing please? [15:28] rbasak, yea, I've been watching mongodb [15:28] rbasak, what do you need? [15:29] Error parsing command line: unrecognised option '--nohttpinterface' [15:29] I suspect that's been dropped in 3.6. [15:29] balloons: is golang-github-juju-testing still needed? [15:29] I don't see any rdepends. [15:29] Was it for the former archive juju package for example? [15:30] Hmm. [15:30] It's not Ubuntu-only. It was synced from Debian. [15:30] rbasak, ahh, it was added as build-depends for juju I assume [15:30] rbasak, yes, we synced golang libs to debian [15:31] balloons: so it can be removed now? [15:31] 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] rbasak, so yes, +1 [15:32] Unfortunately if it's synced from Debian I'm not sure the AAs will want to just remove it. [15:33] I'm not sure to what extent it should be removed from Debian. [15:33] rbasak, interesting.. it's only in bionic [15:33] It was only added there very recently. [15:33] Depends on the Debian Go packaging team's policies I guess. [15:33] Maybe a force-badtest would be acceptable though? [15:33] there's several new juju libs in bionic [15:34] I suppose the summary is that the package needs its dep8 test updating to work against mongodb 3.6. [15:34] That's why I didn't recognize it. I'm not sure who did those uploads [15:34] You can see it in https://tracker.debian.org/pkg/golang-github-juju-testing [15:35] The sync to Ubuntu was automatic [15:36] right. So mwhudson and I were working through juju's golang needs and getting them into debian [15:37] But that was some time ago, and I set it aside to pursue the snap [15:38] I think I can just drop the --nohttpinterface [15:38] AFAICT, the (deprecated) HTTP interface was removed in 3.6. [15:38] So presumably not specifying that will result in the same behaviour in 3.6. [15:45] Aha: https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111 [15:52] rbasak, yes, pulling in the newer version makes more sense if you want it to work with 3.6 [15:53] balloons: I'm looking at just cherry-picking that fix. [15:53] ahh right.. [15:53] it's actually tiny [15:53] I don't see the point in pulling in the newer version if nobody actually needs it. [15:54] The package might be a candidate for orphaning in Debian. [15:55] rbasak, there's many new github-juju*-dev packages in bionic [15:55] 15 looks like? [15:58] I got a pass with this: http://paste.ubuntu.com/p/kVK4Fdn3Ry/ [15:59] orphaning> seems like a bizarre response in the case of something that was first uploaded a couple of months ago [15:59] orphaning is a response to not being maintained, which normally requires longer than that [16:00] 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] if it shouldn't be in Debian then the correct response would be to ask the maintainer about having it removed [16:00] And it's a Juju-specific package. [16:00] rbasak: they're not the Debian maintainer, so that's not terribly relevant [16:00] they weren't maintaining it in Debian to begin with :) [16:00] I'm under the impression that mwhudson is a member of the Go packaging team in Debian. [16:01] yes, indeed. That's why I was surprised to see it [16:01] andyrock: What release of Ubuntu would you want a version of plymouth to test with? [16:01] perhaps, but he has no involvement in the changelog of that package. [16:01] Oh [16:01] I missed that. [16:01] bionic is fine [16:01] I assumed it was uploaded via balloons and mwhudson. [16:01] 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] *on it if [16:01] right. To be clear, I have no knowledge of those packages, and as cjwatson pointed out, mwhudson didn't push it either [16:02] bdmurray: I can test it in few hours [16:02] Can I get a peer review from someone for http://paste.ubuntu.com/p/kVK4Fdn3Ry/ please? [16:02] It builds and passes autopkgtest for me locally. And I locally reproduced the current failure, too. [16:03] rbasak: LGTM [16:03] Thanks. I'll upload. [16:03] And submittodebian. [16:03] That should unstick mongodb 3.6 hopefully. [16:09] thanks rbasak [16:10] balloons: np. It has built. Now we wait a couple of publisher runs I think. [16:10] balloons: I'm nearing EOD now, so I'll have to resume on Monday to get this landed if necessary. [16:10] rbasak, no worries. I very much appreciate you getting this landed, and doing so quickly [16:11] rbasak, we'll plan to get juju 2.4-beta1 first thing next week as weel === sergiusens_ is now known as sergiusens [19:18] slangasek: for an especially serious example of the GNOME Software issue, see bug 1756788 [19:18] bug 1756788 in gnome-session (Ubuntu) "Removing "Startup Applications" in "Ubuntu Software" makes the system unable to launch GDM" [High,Fix released] https://launchpad.net/bugs/1756788 [19:19] 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] heh [19:19] when it's clicked, GNOME Software happily removes the package using PackageKit [19:20] it the package is say, update-manager, then PackageKit will remove ubuntu-desktop because ubuntu-desktop has depends: update-manager set [19:20] GNOME Software does not tell the user that things like this are happening [19:20] right; I share bdmurray's unease with the shape of the solution, however [19:20] 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] 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] 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] why ship these appstream files in the individual packages instead of in gnome-software itself? [19:22] because gnome-software isn't the source of packages [19:22] no, it's the source of the damage [19:22] I mean sure it could ship its own whitelists for this issue [19:23] but appstream metadata in general should be shipped with the individual app [19:23] the compulsory field is controversial; some users really want to remove system apps [19:23] 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] and the "compulsory"ness is a function of the flavor metapackage, not of the application [19:25] yes [19:25] you should probably talk to ximion if you have concerns about appstream ;) [19:25] 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] 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] ok, then talk to hughsie or Laney or robert_ancell ;) [19:27] Laney: hi I talk to you [19:27] :) [19:27] lol, he's probably trying to enjoy his weekend [19:28] he's probably used to me spoiling that [19:29] yeah, I guess this is really bad for Lubuntu if Lubuntu users want to try to use GNOME Software [19:30] yet more fun from Lubuntu not wanting to use Recommends yet :) [19:30] we've had this issue since 2016 though [19:32] ximion: the context is https://lists.ubuntu.com/archives/ubuntu-devel/2018-April/040278.html [19:36] Isn't it bad for any flavor that uses GNOME software though? [19:37] jbicha: I have seen that mail :-) [19:37] slangasek: what is compulsory or not is set by the upstream project, usually [19:37] ximion: that's nonsense [19:38] we as a distribution define what is compulsory for our desktop flavors [19:38] 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] and that definition lives in the metapackages, not in the individual components [19:39] bdmurray: it's not too bad for Budgie or Unity which have pretty similar Depends to Ubuntu [19:39] 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] but apt show lubuntu-desktop is a bit horrifying when considering this issue [19:40] 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] 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] 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] I'm not sure if that's supported? [19:42] 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] ximion: which upstream? asgen? [19:43] (update-manager and software-properties are the first and only things to use compulsory for LXDE that I can see) [19:45] 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] 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] 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] oh, missed the discussion here [19:50] (sorry I forked the conversation) [19:52] 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] 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] or do you really have rules like "if that package is installed, it should stay installed" somewhere? [19:54] ximion: But we can special case -desktop [19:54] And yes, we do, but we use it for more important stuff [19:54] I remember that in the past apt would let mre remove any Ubuntu metapackage without any problems [19:54] 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] 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] PackageKit is essentially as smart as apt on the command-line here [19:56] is it? [19:56] jup - "smart" [19:59] 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] 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] tsimonq2: nodejs 8.11.1~dfsg-2 was uploaded to unstable [20:06] ginggs: You can follow through with the transition yourself? ;) [20:08] tsimonq2: sync it [20:09] ginggs: No you. :P [20:12] jbicha: PK would tell you that, but this information not showing up is a GNOME design decision [20:12] (AFAIK KDE Discover started to display that information for updates, at least) [20:13] ginggs, tsimonq2: don't worry, nodejs is seeded on kubuntu, I'll reject with prejudice :P [20:13] some smart mechanism to prevent desktop metapackage removals would be nice [20:14] 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] i'll help with the migration if slangasek let's it in [20:15] *lets - aargh [20:15] 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] tsimonq2: will you take care of that? [20:20] 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] slangasek: hahahaha [20:20] ginggs: No. :P [20:22] I won't touch it with a ten foot pole. [20:26] jbicha: I do not want any version of nodejs :p [20:27] ginggs: how about haskell? [20:28] jbicha: not my thing either [20:54] Funny we talk about new transitions... *nudges acheronuk* [20:55] I totally don't plan on doing a Qt transition last minute... :P [20:56] (/s)