| 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:17 |
|---|---|---|
| sarnold | ehashman: which package? | 02:19 |
| ehashman | sarnold: leiningen | 02:20 |
| ehashman | all the deps need to get synced too I think | 02:21 |
| 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:22 |
| ubottu | Debian bug 761305 in ftp.debian.org "RM: leiningen: RoM; obsolete; request from upstream" [Normal,Open] http://bugs.debian.org/761305 | 02:22 |
| 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 |
| ubottu | 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 |
| dpb1 | heh | 02:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| xnox | currently freeipa is not installable in bionic-proposed. | 02:29 |
| sarnold | that's one way to cut down on bug reports.. :) | 02:29 |
| tjaalton | xnox: because the current version would crash on start if confured via ipa-dns-install | 03:19 |
| tjaalton | uh | 03:20 |
| tjaalton | configured | 03:20 |
| 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:21 |
| slangasek | ok | 03:22 |
| 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 :) | 03:24 |
| baltix-linux | Hi | 09:24 |
| 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:26 |
| 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:37 |
| Mirv | s/9.5/12.5/ | 09:38 |
| 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:46 |
| ubottu | Debian bug 688735 in cryptsetup "Some strings need to be set up for i18n" [Wishlist,Open] | 09:46 |
| 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:55 |
| baltix-linux | Mirv: in Lithuanian ubiquity translations :) | 09:56 |
| baltix-linux | cyphermox: so, will you do manual ubiquity translation export from launchpad today? | 09:57 |
| Mirv | baltix-linux: he'll wake up within 5 hours or so, so we'll find out then | 09:59 |
| juliank | Mirv: I don't know, not this week certainly | 10:12 |
| rbasak | xnox: do you have an opinion on bug 1712817 please? | 11:56 |
| ubottu | bug 1712817 in freeradius (Ubuntu) "postinst fails if the service is disabled via systemd" [Low,Invalid] https://launchpad.net/bugs/1712817 | 11:56 |
| 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? | 11:57 |
| 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:47 |
| 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:48 |
| xnox | rbasak, sure, about quotes. | 12:49 |
| xnox | 😃 | 12:49 |
| rbasak | Thanks | 12:50 |
| rbasak | I've updated the bug and added a debhelper task. | 12:50 |
| LocutusOfBorg | tjaalton, are you trying bind9 rebuilds / transition= | 13:29 |
| LocutusOfBorg | ? | 13:29 |
| tjaalton | LocutusOfBorg: what transition? | 13:56 |
| tjaalton | isc-dhcp would need to be rebuilt, that's all | 14:01 |
| tjaalton | bind9-dyndb-ldap too of course | 14:01 |
| === maclin1 is now known as maclin | ||
| LocutusOfBorg | so tjaalton you will take care of freeipa migration? thanks! | 14:20 |
| tjaalton | sure, if it's accepted | 14:21 |
| tjaalton | bind 9.12 will bundle all libs in bind-libs, so no more shlib bump rebuilds.. | 14:25 |
| * mvo hugs rbalint for the latest u-u fixes | 14:41 | |
| 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:52 |
| 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:56 |
| 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? | 14:57 |
| mvo | didrocks: yes, the build includes a custom LP upload that makes it end up in the right place | 15:03 |
| 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:04 |
| didrocks | mvo: excellent! Thanks :) | 15:06 |
| jbicha | mvo: I just pushed directly now | 15:08 |
| mvo | jbicha: thank you! | 15:14 |
| 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:21 |
| rbasak | balloons: around? Can you help with golang-github-juju-testing please? | 15:27 |
| balloons | rbasak, yea, I've been watching mongodb | 15:28 |
| balloons | rbasak, what do you need? | 15:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| cjwatson | The sync to Ubuntu was automatic | 15:35 |
| balloons | right. So mwhudson and I were working through juju's golang needs and getting them into debian | 15:36 |
| balloons | But that was some time ago, and I set it aside to pursue the snap | 15:37 |
| 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:38 |
| rbasak | Aha: https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111 | 15:45 |
| balloons | rbasak, yes, pulling in the newer version makes more sense if you want it to work with 3.6 | 15:52 |
| 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:53 |
| rbasak | The package might be a candidate for orphaning in Debian. | 15:54 |
| balloons | rbasak, there's many new github-juju*-dev packages in bionic | 15:55 |
| balloons | 15 looks like? | 15:55 |
| rbasak | I got a pass with this: http://paste.ubuntu.com/p/kVK4Fdn3Ry/ | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| balloons | thanks rbasak | 16:09 |
| 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:10 |
| balloons | rbasak, we'll plan to get juju 2.4-beta1 first thing next week as weel | 16:11 |
| === sergiusens_ is now known as sergiusens | ||
| jbicha | slangasek: for an especially serious example of the GNOME Software issue, see bug 1756788 | 19:18 |
| ubottu | 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| slangasek | and the "compulsory"ness is a function of the flavor metapackage, not of the application | 19:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| slangasek | he's probably used to me spoiling that | 19:28 |
| jbicha | yeah, I guess this is really bad for Lubuntu if Lubuntu users want to try to use GNOME Software | 19:29 |
| jbicha | yet more fun from Lubuntu not wanting to use Recommends yet :) | 19:30 |
| jbicha | we've had this issue since 2016 though | 19:30 |
| jbicha | ximion: the context is https://lists.ubuntu.com/archives/ubuntu-devel/2018-April/040278.html | 19:32 |
| bdmurray | Isn't it bad for any flavor that uses GNOME software though? | 19:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| jbicha | (update-manager and software-properties are the first and only things to use compulsory for LXDE that I can see) | 19:43 |
| 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:45 |
| 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:47 |
| 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:48 |
| * 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:49 |
| jbicha | (sorry I forked the conversation) | 19:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| juliank | is it? | 19:56 |
| ximion | jup - "smart" | 19:56 |
| 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) | 19:59 |
| 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:04 |
| ginggs | tsimonq2: nodejs 8.11.1~dfsg-2 was uploaded to unstable | 20:05 |
| tsimonq2 | ginggs: You can follow through with the transition yourself? ;) | 20:06 |
| ginggs | tsimonq2: sync it | 20:08 |
| tsimonq2 | ginggs: No you. :P | 20:09 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:20 |
| tsimonq2 | I won't touch it with a ten foot pole. | 20:22 |
| ginggs | jbicha: I do not want any version of nodejs :p | 20:26 |
| jbicha | ginggs: how about haskell? | 20:27 |
| ginggs | jbicha: not my thing either | 20:28 |
| tsimonq2 | Funny we talk about new transitions... *nudges acheronuk* | 20:54 |
| tsimonq2 | I totally don't plan on doing a Qt transition last minute... :P | 20:55 |
| tsimonq2 | (/s) | 20:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!