[07:25] cpaelzer: could you have a look at migrating mysql and mariadb packages? or somebody else ... [07:39] doko: I'll ask rbasak to look as he is more mysql'y than myself [07:39] but I'll take a look myself if there is anything easy I can help with once I'm done with my current task [09:26] stgraber, what is your opinion wrt libxml-sax-perl ? is the patch still needed? can we forward upstream? [10:17] Hello, any hints as to why ppc64el failed? It shouldn't have, https://launchpad.net/ubuntu/+source/xfdesktop4/4.13.2-0ubuntu1 [10:26] Unit193, pbuilder-dist cosmic ppc64el create && pbuilder-dist cosmic ppc64el login? :) [10:26] Not quite how I have my pbuilder set up, but that seems unideal. [10:27] why? it works! [10:27] * LocutusOfBorg is trying this [10:30] Just seems odd that it was the only one to fail, and it wasn't an issue solved by autoreconf. [10:39] Unit193, they are installable to me [10:39] I retried the build [10:39] Yes, precisely why it's weird... [10:40] I did some perl stuff, and python is doing some weird things because of transition maybe... [10:40] it is working now, meh [12:05] rharper: You're bouncing on oftc/#qemu rharper left the room (quit: Killed (NickServ (Too many failed password attempts.))). about every 20 seconds [12:15] ahasenack: *poke* [12:15] ahasenack: You around? [12:15] ahasenack: Looks like it's time to revert the mod-proxy-uwsgi revert from your last upload (uwsgi no longer builds the module). [12:17] ahasenack: Erm, referring to apache2, that is. [12:21] infinity: hi [12:21] infinity: we should start using the one from apache now then? [12:21] ahasenack: Aye/ [12:21] ahasenack: http://launchpadlibrarian.net/371383267/apache2_2.4.33-3ubuntu1_2.4.33-3ubuntu2.diff.gz [12:21] ahasenack: Just revert every bit that refers to uwsgi, IMO. [12:22] ahasenack: I'd do that myself, but I don't want to be TIL. [12:22] infinity: ok, I'll do it. And then the other source will be removed from the archive? [12:22] ahasenack: The other binary, you mean. Which it'll be replacing. [12:23] it comes from its own source, but yeah, its binary [12:23] ahasenack: There's a lot more in the uwsgi source than just that binary. :) [12:23] I see [12:23] ahasenack: Only mod-proxy-uwsgi was dropped (because it's now part of apache) [12:23] See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894785 [12:23] Debian bug 894785 in apache2 "apache2: File conflict with libapache2-mod-proxy-uwsgi" [Serious,Fixed] [12:23] and that's the only bit that is failing to build I assume [12:24] ahasenack: No build failures. It's that things depend on libapache2-mod-proxy-uwsgi, which no longer exists because you aren't building it. :P [12:24] (or, it will no longer exist if I were to remove the NBS package) [12:25] ah, no longer builds == on purpose no longer builds [12:25] Yes. [12:25] As in, this transition happened in Debian, and you undid half of it. :) [12:26] And then we synced the other half. [12:26] for a reason, I think we were missing that sync of the other half [12:26] Likely. [12:26] it was stuck in migration [12:26] it will all come back to me once I re-enable it [12:26] Danke. [12:27] Can that happen today? [12:27] ahasenack: and when you're done with that, submit your core dev application already :) [12:27] If not, I'll grumpily do it myself, but then nag you about taking apache2 back. :P [12:27] Oh, if you don't have upload rights, I can just do it in your name and pretend I sponsored it for you. *cough* [12:28] infinity: no grumpyness needed, I'm just starting my day, plenty of time. But I'll need reviews from my peers, it's how we have been doing things. But I guess you can review it if you are still aroun [12:28] He can upload apache2 I think - through the server packageset [12:28] But still [12:28] Core dev. [12:28] ahasenack: I think infinity would count as your peer from our team's peer review perspective [12:29] I might still be on your team! [12:29] The oldest member, no less. [12:29] didn't mean to imply otherwise :) [12:30] rbasak: I still have some checkboxes to tick in that checklist of yours ;) [12:30] infinity: the second oldest member. Looks like you were beaten by 24 seconds :-P [12:31] we have that kind of resolution? [12:31] Mouse hover [12:31] rbasak: Curses. [12:31] rbasak: Deactivating Fabio would fix that. [12:31] Pretty sure he hasn't contributed in about a decade. [12:32] There are tons of people in ~ubuntu-server who don't appear to have ever been involved at all. [12:32] Yeah, some past admins were a bit nutty with the accept button. [12:32] Because building a "community" was more important to them than a useful team. [12:33] It's an open team. There is no accept button. [12:33] Oh, or that. [12:33] I thought it was once closed. [12:33] But I could be misremembering. [12:35] ubuntu-server-dev is the more crucial one in terms of privileges [12:36] Yeah, that didn't exist (cause packagesets didn't) back in "my day". [12:36] WHEN I WAS YOUR AGE. [12:46] Where you ever? [12:46] Unit193: are you handling the thunar transition? [12:47] doko: Yes, should be only one package left. [12:47] ta [12:47] xfconf should be one too, and that's also going to be done real soon™ [13:07] Phasing of update-notifier uploads has stopped due to https://errors.ubuntu.com/problem/4844575ab1a533f9e47d6fdde541010e267bd9d3 - but all I did was move around some print statements (https://launchpadlibrarian.net/375023334/update-notifier_3.168.8_3.168.9.diff.gz), does anyone see anything I'm missing? [13:10] juliank: Clearly not a new crash. [13:10] It does seem familiar [13:10] juliank: Well, the list of versions at the bottom confirms it's not new. :P [13:10] Or, wait. Unless those are all current SRU versins? [13:10] infinity: no, these are all my SRUs [13:11] Indeed they are. [13:11] Hrm. [13:12] Colour me stumped. [13:14] infinity: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/882882 [13:14] Launchpad bug 882882 in ubiquity (Ubuntu) "installer crash with ValueError: invalid literal for int() with base 10: ''" [Undecided,Invalid] [13:15] I think xnox's comment from 2012 explains it [13:15] "What happens is that debconf database is locked and status ends up as empty string." [13:15] why it's locked, though, no idea [13:15] another one: https://bugs.launchpad.net/ubuntu/+bug/537952 [13:15] Launchpad bug 537952 in Ubuntu "the installer crash" [Undecided,Fix committed] [13:15] juliank: Maybe, yeah, but why just now? [13:15] juliank: Seems fishy. [13:16] Granted, only 6 total reports, but still weird that it's only on that version. [13:17] timing issue? [13:17] the first print moved after the database opening now [13:18] (well, and after db shutdown) [13:18] Could be. [13:19] infinity: no reports from artful yet [13:19] I suspect the number of people using artful isn't high. [13:19] So that makes sense. [13:19] true [13:22] juliank, sorry, i forgot. [13:22] infinity: local test build worked, upgrade with dpkg -i with old uwsgi installed worked, just waiting on a ppa build to try with apt [13:22] https://launchpad.net/~ahasenack/+archive/ubuntu/apache2-restore-uwsgi/+packages [13:23] ahasenack: Pointer to the PPA, so I can re... Thanks. :) [13:23] branch is https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+ref/apache2-restore-uwsgi [13:23] not an mp yet, pending that ppa [13:23] xnox: there's nothing you have to be sorry about, your comment helps. [13:24] I wonder what locks the debconf db [13:24] Like, for my problem, is package-data-downloader run inside a maintainer script that does debconf itself? [13:24] ahasenack: Diff looks sane to me. [13:25] juliank: It very much could be, yes. [13:26] juliank: Try installing flashplugin-installer and see what happens? [13:26] juliank: Or ttf-mscorefonts-installer, but it might be broken in other ways. [13:26] infinity: I have that installed on my system for testing [13:26] in cosmic [13:26] but I tested those for the SRU verification [13:27] maybe I need to have both installed? [13:28] Well, I do [13:31] infinity: that seems to be it [13:31] . /usr/share/debconf/confmodule; /usr/lib/update-notifier/package-data-downloader [13:31] fails [13:31] like that [13:31] But this does not really explain it [13:33] /usr/lib/update-notifier/package-data-downloader gets run from update-notifier-common.postinst only, at least here [13:35] infinity: https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/348679 [13:35] rbasak: ^ [13:36] rbasak: we should find out why lp can't get the diff correctly for the apache package [13:36] ahasenack: libjansson4 being removed... Is that because you didn't re-add it to build-deps? [13:36] infinity: that is because of the md module, which I'm still not building [13:36] I'm not changing it in this diff [13:37] ahasenack: No, I mean it's listed for autoremoval when you remove libapache2-mod-proxy-uwsgi .. [13:37] * ahasenack checks [13:37] ahasenack: Or is that just cause your system is in a state where that was already on the hit list? [13:38] I started with a fresh cosmic container, just as the testing description says [13:38] let me see what I get out of the box [13:38] ahasenack: Kay, uwsgi-core depends on it. [13:38] ahasenack: But I'm wonder if apache2 would too, if you had it in build-deps and the module build detected it, that's all. [13:39] I will check. I thought it was because of the md module, as that's why debian added it to build-deps in https://salsa.debian.org/apache-team/apache2/commit/b9d37f2a96da2fd69bf [13:41] $ rgrep -l jansson | grep modules [13:41] modules/md/mod_md.dsp [13:41] modules/md/md_json.c [13:41] modules/md/config2.m4 [13:41] modules/md/mod_md.mak [13:41] Yeah, the source agrees. [13:41] stgraber, I merged it, please correct me if I'm wrong, maybe we can upload a revert and let it be syncd on next update [13:41] just md? [13:41] So, just a weird coincidence is all. [13:43] rbasak: If I sponsor this the usual way and don't bother with the MP (other than to review and mark it merged), some magical import tool will DTRT, right? [13:43] Like, I don't actually need to commit this to git just to make your tooling happy? [13:44] infinity: the original uwsgi-mod-proxy package recommends uwsgi-core, that's where jansson4 comes from. The new libapache2 transitional package doesn't to that of course, nor does apache2-bin (where mod-proxy-uwsgi lives now) [13:44] Oh, not that I'm in the list of reviewers anyway. :P [13:44] infinity: ops [13:45] autopilot, sorry [13:45] infinity: it's infinity in lp too? [13:45] ahasenack: Yeah. I meant it's a weird coincidence that uwsgi-core and mod_md happened to have that same dep and caused the confusion on my part. :) [13:45] infinity: the magic isn't implemented yet [13:45] no, adconrad [13:45] ahasenack: ~adconrad [13:45] rbasak: Wait, really? [13:45] rbasak: So, if I upload apache2, your branches all go to poop? [13:46] If you just upload, then the importer will manage, but the git commits won't be incorporated. New commits will be synthesized by the importer instead, but only one for each upload. [13:46] The unimplmeneted magic is to be able to detect the MP and incorporate automatically, or similar. [13:46] rbasak: Oh, sure. But that's almost more desirable. A single rebase-style commit is more readable than "here's some changes, here's a changelog". :P [13:46] (Why do people always commit changelogs separately?) [13:47] In the meantime, we can incorporate manually by pushing an "upload tag" so the importer will find it when it sees the upload. Currently that's restricted to ~usd-import-team. [13:47] I insist on commiting changelogs separately, since it reduces hell when cherry-picking. [13:47] IMHO, git makes changelogs inside source trees obsolete. They should be generated from commits when needed instead. [13:48] changelog always conflicts [13:48] Kids these days. [13:48] :) [13:48] rbasak: Well, if you want to do the thing "properly" (I'm not in the mood to learn a new workflow), go to town, I'm +1 on the debdiff in the PPA. [13:49] Which is supposedly what the branch diff is, but LP's diff is broken beyond recognition. [13:49] I was just looking at that. I don't understand why it's broken. I'll dig. [13:49] rbasak: it's been like this for all apache mps [13:50] I vaguely remember nacc saying something about a bug in python[23]?-git or whatever the name of that module is [13:50] That would seem to imply that it's very confused about what the target branch actually is. [13:50] the lp diff is correct for the top part [13:50] So it is. [13:51] it breaks once it hits that docs directory [13:51] The other 1400 files, though... [13:56] debian/changelog is IMO closer to a NEWS file than to a trad ChangeLog file. I agree that git makes the latter obsolete, but not the former. [13:57] I think it makes sense to maintain a NEWS file in a git-based source tree, but I'd want it to be done in separate commits (perhaps at release time, to nicely aggregate things together) to avoid the conflict hell. [13:58] Or learn to CP without picking the NEWS bits? [13:58] * infinity shrugs. [13:59] I think a news item belongs with the commit it's referring to, so I can trace back that way. [13:59] I'm quite capable of doing that but that doesn't stop it being painful [13:59] blame the news file, find the commit. [13:59] I'll be back in ~30m, need to fetch Ted from the pet store from his bath [13:59] For our merge workflow, you end up having to resolve the conflict manually for every single Ubuntu upload since the divergence point. [14:00] I'm sure git could be taught to resolve that itself automatically somehow, but we don't even want those parts cherry-picked anyway. [14:00] The news file won't necessarily have a 1-1 correlation between commits and entries anyway [14:01] The MP is identical to the PPA diff except for the changelog version as expected. [14:02] Then +1 from me. [14:02] ahasenack: so I pushed the upload tag for you. Upload when ready. [14:02] Go forth and merge/upload, pretty please. [14:24] LocutusOfBorg: I don't even remember doing that :) so may very well not be needed anymore indeed [14:49] stgraber, ack thanks! [14:52] back [14:52] rbasak: ok, thanks === tkamppeter_ is now known as tkamppeter [16:00] doko, https://launchpadlibrarian.net/376363514/buildlog_ubuntu-cosmic-amd64.python-taskflow_3.1.0-0ubuntu5_BUILDING.txt.gz [16:00] do you have any idea? it seems to be related to new python? [16:02] ahasenack: rbasak: yeah, i dug into it and it seems like it's something was in pygit2 or libgit2, but i forget immeidately [16:06] nacc: ok [16:08] ahasenack: in theory, we should be able to reproduce the diff that LP shows via turnip (iirc, that's the name of the project) [16:08] ahasenack: by tracing that code to the diff generation (which I believe is pretty straightforward) and then seeing if we can get the same thing in a simple tool [16:10] nacc: thanks! [16:10] I'll chase it up at some point. [16:11] rbasak: np, i remember in one case, I couldn't get pygit2 to get me quite the same thing, and that's about all I remember right now [16:11] Start from turnip.api.views.DiffMergeAPI [16:12] And if you want to reproduce exact versions and such, use a trusty container with ppa:launchpad/ubuntu/ppa [16:59] Thanks! I filed bug 1779178 so as to keep that info around for later. [16:59] bug 1779178 in usd-importer "git diff generation is sometimes wrong" [Undecided,Triaged] https://launchpad.net/bugs/1779178 [17:34] manjo: Could you respond re the verification of bug 1716517 so we can get it released? [17:34] bug 1716517 in The Ubuntu-power-systems project "[arm64/ppc64le] load ipmi_ssif/ipmi_powernv instead of ipmi_si" [Low,Incomplete] https://launchpad.net/bugs/1716517 [17:44] bdmurray, done [17:56] manjo: but it says "Installed: (none)" in the apt policy output [17:57] right .. I skipped a step where I did the apt install openipmi [17:57] so in between the status and apt policy there was an apt install which I did not cut and past .. I assume . .that would be obvious [17:58] s/assume/assumed [17:58] well its inconsistent in that comment #20 you showed the version installed (which is really the best practice) [17:58] bdmurray, I can repeat the test if you need [17:59] manjo: nah, its fine. just going forward please run 'apt policy' with the package installed [17:59] bdmurray, ack .. won't screw up [18:00] bdmurray, thanks for reaching out to me [18:05] bdmurray: is this your sru day? Is https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186 next or close to next perhaps? :) [18:05] Launchpad bug 1766186 in apache2 (Ubuntu Bionic) "IncludeOptional fails when a directory does not exist" [Low,Fix committed] [18:07] ahasenack: It is, have these autopkgtest regressions been investigated? [18:07] "these"? hm [18:07] no, I wasn't aware of them, my fault [18:08] no problem we could do better about messaging the failures [18:08] I keep assuming that if the upload made it, the tests passed [19:32] LocutusOfBorg: the taskflow upload seems to be causing issues [19:33] LocutusOfBorg: https://paste.ubuntu.com/p/wvS4kqmckj/ [19:43] not sure why that fails though. OrderedDiGraph inherits from DiGraph which defines nodes_iter. [19:46] coreycb, where did you take it? the fixed one is waiting for python breakage to reduce a bit https://launchpad.net/ubuntu/+source/python-taskflow/3.1.0-0ubuntu5/+build/15064887 [19:47] I suspect this is because of new networkx [19:48] LocutusOfBorg: i have a nova build that picked it up from cosmic-proposed [19:48] or maybe not, checking. i probably need the new one is what the issue is. [19:50] LocutusOfBorg: ok yeah i'm using 3.1.0-0ubuntu4. i'll wait on 3.1.0-0ubuntu5. sorry and thanks :) === imcleod__ is now known as imcleod [20:38] coreycb, nice to know :) I don't even know if it will build or not BTW [20:38] I hope and I have fingers crossed! [20:39] LocutusOfBorg: ok, then i'll cross my fingers too :) [22:03] coreycb, 4 pkg-openstack packages required patches to work with python3.7, "async" keyword being now reserved [22:03] I suspect lots of breakage in the archive :/ [22:11] hello jamespage, please merge kazoo from Debian? [22:11] I don't know if new deps requires mir or not... [22:12] neither if python now has automagic autopkgtest [23:40] LocutusOfBorg: I'll have a look once I'm finished with all these no-change uploads