[00:03] <slangasek> pitti: I see you demoted xchat-indicator to -proposed when removing xchat from the archive; rather than removing it?  and no bug filed?
[00:10] <nacc> slangasek: just to confirm, does that error from lintian occur for the -doc package? i think the old pacakge has a lintian-overrides file that refers to some of the sphinx files
[00:10] <slangasek> nacc: it shows up on the source package
[00:10] <slangasek> nacc: so lintian foo.dsc
[00:19] <nacc> slangasek: yeah, i think the old pacakge built using dh_sphinxdoc? and symlinked the _static/ dirs to the ones provided by sphinx-rtd-theme
[00:20] <slangasek> nacc: however, this pertains to the contents of the source package; somehow the same version of lintian thinks source is present in the previous package version, but not in the new one
[00:21] <nacc> slangasek: ah, i think i see what changed
[00:22] <nacc> slangasek: i don't belieeve the old source actually contained, e.g., modernizr.min.js, and i see no reference to it in the old source. The new source now has the generated .js file (presumably generated by sphinx) in the tarball
[00:23] <nacc> "* Modernizr 2.6.2 (Custom Build) | MIT & BSD
[00:23] <nacc> with the build in a URL, it seems
[00:24] <nacc> i'm not sure why that was done, though, let me see if i can find out
[00:24] <nacc> slangasek: so upstream (gh) has embedded the templates in the src
[00:25] <nacc> not sure why, other than maybe knowing with js is going to be used for the web UI ... I'd think we'd want to use the symlink provided by the other package as the old source did?
[00:26] <slangasek> nacc: that is certainly an option; I have no strong opinion on it, but would ask whether we want to be on the hook for packaging changes on this universe package
[00:27] <nacc> slangasek: yeah, that's not great. I'm not sure who, if anyone, cares about it, but i do see that it's maintained by rackpsace and is the "official" API to connect to openstack with PHP, which seems sort of improtant
[00:30] <nacc> slangasek: i see what you mean, though, it might be easiest to just drop it, as not being compatible with php5? i'm not sure
[00:30] <nacc> slangasek: and no one has demanded that we keep it around, afaict
[00:31] <slangasek> nacc: yes; no reverse-dependencies, in universe, could be dropped instead of spending a lot of time on it
[00:31] <nacc> no bugs against it ever, afaict, either
[00:32] <nacc> slangasek: so let's say someone does come runnign and say they want it, is there a process to re-add it after release? or would we simply say they're out of luck? I just would lke to understand that policy
[00:32] <slangasek> nacc: if nobody got around to asking for it until after release, they'd be out of luck
[00:32] <nacc> slangasek: ok
[00:33] <Umeaboy> cyphermox: Nobody is answering in #ubuntu-unity.
[00:33] <nacc> slangasek: let's hold off on this one, i'll check with my team and get back to you, but probably we'll just plan on deleting it
[00:34] <nacc> slangasek: presumably it'll come back in via sync in 16.10, if debian picks it up
[00:47] <nacc> slangasek: ok, i'm doing some digging and only kohana 3.3 (not pacakged in debian either) supports php7, i think we should drop all of them, but i'll need toresolve the dep you found with pnp4nagios-web
[00:48] <nacc> slangasek: and i think the resolution to that dep is we can't build the -web package with php7 :/
[00:48] <nacc> as it depends on kohana we won't have, unless we package 3.3
[02:18] <cjwatson> doko: https://bugs.launchpad.net/ubuntu/+source/libuniversal-require-perl/+bug/1560288 for devscripts, and I've uploaded a merge that fixes the test failures once that's processed.  Could you subscribe ~foundations-bugs to libuniversal-require-perl, which I think would be appropriate?
[02:18] <ubottu> Launchpad bug 1560288 in libuniversal-require-perl (Ubuntu) "[MIR] libuniversal-require-perl" [Undecided,New]
=== juliank is now known as Guest49292
=== juliank_ is now known as juliank
[06:31] <cpaelzer> good morning
[07:18] <doko> cjwatson, foundations already is subscribed
=== Logan is now known as Guest92038
[07:25] <doko> jtaylor, xenial now has locales-all, no need to keep this diff (seen for matplotlib)
[07:26] <pitti> Good morning
[07:32] <pitti> infinity: when would be a good time to upload langpacks for the final beta?
[07:32] <infinity> pitti: Right now.
[07:32] <infinity> pitti: Or a week ago.
[07:33] <pitti> wgrant: can you please start a xenial langpack export manually? I just requested a full export
[07:33] <infinity> pitti: (if they all get through before my morning, that works for me, I can respin the world when I wake up)
[07:33] <wgrant> pitti: Looking
[07:33] <pitti> infinity: well, it's not utterly important, just makes the images slightly smaller
[07:34] <infinity> pitti: Yeah.  But if you're doing it anyway, happy to take them.  I'm sure today's builds won't be the last.
[07:34] <pitti> infinity: congrats to landing glibc, this was a mouthful
[07:37] <pitti> infinity: ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd got stuck on some flakiness; I re-tried the test, but ok to still land this? there's two or three  urgent fixes people asked me about
[07:38] <pitti> (and only bug and test fixes)
[07:42] <pitti> Trevinho: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gtk+3.0 is stuck on software-properties regression; simple to fix, will upload now
[08:26] <dholbach> good morning
[09:46] <flexiondotorg> When the option to ignore future crash reports is selected by a user in apport, where is that "configuration" stored?
[09:47] <pitti> flexiondotorg: in ~/.apport-ignore.xml
[09:47] <flexiondotorg> pitti, Thanks. can system wide exclusions be made?
[09:48] <pitti> flexiondotorg: not at the moment, no
[09:48] <flexiondotorg> pitti, OK, thanks.
[09:48] <pitti> flexiondotorg: well, you can blacklist *all* crashes from a binary, independent of the version
[09:48] <flexiondotorg> How?
[09:49] <flexiondotorg> Found it.
[09:51] <pitti> flexiondotorg: /etc/apport/blacklist.d/README.blacklist
[09:51] <flexiondotorg> Yep, reading it now :)
[09:51] <flexiondotorg> Thanks.
[10:01] <Trevinho> pitti: hey, thanks for letting me know.
[10:22] <flexiondotorg> pitti, If you're able can I request you take a peek at bug please?
[10:22] <pitti> flexiondotorg: which bug?
[10:22] <flexiondotorg> pitti, I've contacted upstream, they are implicationg systemd to some extent.
[10:22] <flexiondotorg> pitti, https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1533206
[10:22] <ubottu> Launchpad bug 1533206 in blueman (Ubuntu) "Blueman-applet crash on login: DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out" [High,Confirmed]
[10:23] <flexiondotorg> pitti, Upstream issue - https://github.com/blueman-project/blueman/issues/488
[10:26] <pitti> flexiondotorg: so something tries to dbus-activate blueman, but that either crashes or immediately terminates itself
[10:26] <pitti> would certainly be useful to get the output from that
[10:26] <flexiondotorg> pitti, blueman-applet is autostarted on Ubuntu MATE and Xubuntu upon login. I think possibly Lubuntu too.
[10:27] <pitti> well, this isn't about the applet, it's about the service it tries to activate
[10:27] <flexiondotorg> blueman-applet will crash is bluetooth is not present or disabled.
[10:27] <flexiondotorg> pitti, I think so too. But upstream and feel systemd is at fault to some extent.
[10:28] <pitti> uh, how's that?
[10:28] <pitti> is blueman-applet talking to bluez? or is that a different dbus serivce?
[10:28] <flexiondotorg> Well, see their comment in the upstream issue.
[10:29] <flexiondotorg> Yes, it talks to org.bluez
[10:29] <flexiondotorg> My feeling is blueman-applet should catch the exception.
[10:29] <pitti> well, if you disable bluetooth.service you won't be able to talk to bluez, yes
[10:29] <flexiondotorg> But, other than exitting silently, I've found now way to do that without generate a traceback elsewhere.
[10:30] <pitti> so if bluez is meant to run all the time (I think it's not, as it activates on demand only *if* you have BT hw), then the client needs to be able to cope with it not being there
[10:30] <flexiondotorg> So, my ideas were. Blacklist blueman-applet in apport or fail silently.
[10:31] <flexiondotorg> pitti, Agreed. And so do upstream. But the 2.0.3 version appears quite brittle. There current development branch is more robust but in flux and not release ready.
[10:32] <flexiondotorg> I'm not keen on failing silently. At least with blacklist via apport we backtraces are still captured in xsession-errors.
[10:33] <pitti> you wouldn't get any crash of that any more, though
[10:33] <pitti> I don't know what indicator-bluetooth does if it can't talk to bluez, but I figure it'd just hide itself?
[10:33] <flexiondotorg> Yes, no crash reports for the blueman-applet, but the rest of blueman and BlueZ would still generate reports.
[10:33] <flexiondotorg> We have plenty of blueman-applet crash reports ;-)
[10:34] <flexiondotorg> indicator-bluetooth is not an option for Ubuntu MATE :-(
[10:35] <flexiondotorg> Don't know if it is suitable for Xubuntu or Lubuntu.
[10:35] <pitti> no, but I thought it might be worth to compare what that does
[10:36] <pitti> FWIW, bluetooth.service is running here despite having no BT devices
[10:37] <davmor2> pitti: yes I think it runs because you can have dongle for keyboards and stuff
[10:38] <pitti> ah, "sudo rfkill list" shows that I don't have soft-blocked tpacpi_bluetooth_sw
[10:38] <flexiondotorg> pitti, And org.bluez is avaiable via dbus?
[10:39] <pitti> after soft-blocking tpacpi_bluetooth_sw it doesn't start any more, ok; so all as intended
[10:40] <pitti> but it gets auto-activated again once I try to talk to it via dbus
=== dpm_ is now known as dpm
[10:56] <cjwatson> doko: Thanks.
[10:57] <cjwatson> Maybe I was looking in the wrong place; I see it now.
[10:58] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[11:40] <juliank> Oh, Debian import is working again? :)
[11:44] <cjwatson> juliank: Yeah, it's finished with sid.  Of course dinstall being broken is clouding the issue a little.
[12:30] <ricotz> cjwatson, hi, what is the plan to deal with the "broken" ppa keys with new apt
[12:32] <cjwatson> ricotz: The keys aren't broken; we only need to re-sign things with the rough equivalent of --digest-algo SHA512.  This now happens for anything newly-published, but for the long tail of PPAs that haven't been touched in a while we will be re-signing them in bulk once we get the code finished to do so efficiently.
[12:32] <cjwatson> (There are so many PPAs that this isn't entirely trivial ...)
[12:34] <ricotz> cjwatson, yeah, that is what I meant with broken, thanks for clarifying
[12:34] <ricotz> is there a bug report which I can follow?
[12:36] <cjwatson> ricotz: No
[12:36] <cjwatson> ricotz: Well, actually bug 1556666 will do I guess
[12:36] <ubottu> bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [High,Fix committed] https://launchpad.net/bugs/1556666
[12:38] <ricotz> cjwatson, thanks
[12:38]  * cjwatson posts a brief update there
[12:48] <Laney> infinity: Any idea what's up with locales on the pending desktop image? There's none and no /usr/lib/locale/locale-archive...
=== _salem is now known as salem_
[13:15] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[13:52]  * dholbach hugs sil2100 
=== Laney changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[14:08]  * sil2100 hugs dholbach back
[14:16] <Mirv> tkamppeter: can you check hplip sync from Debian at bug #1559419 ? looks like mostly packaging fixes
[14:16] <ubottu> bug 1559419 in hplip (Ubuntu) "Sync hplip 3.16.2+repack0-7 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1559419
[14:18] <Mirv> I've syncpackage'd three packages for flexiondotorg without a seeming error, let's see if they appear after a delay or what's up
[14:19] <flexiondotorg> Mirv, Thanks :-)
[14:19] <flexiondotorg> Was one of them Pluma?
[14:20] <Mirv> flexiondotorg: no, the three mate packages. don't thank me yet since they're currently still in /dev/null from what I can see :)
[14:20] <flexiondotorg> Hah!
[14:20] <flexiondotorg> OK, let's see.
[14:21] <flexiondotorg> I've currently got an uninstallable image. Fixing a package to correct that now.
[14:21] <flexiondotorg> So hopefully I can rebuild with those package you've synced as well :-)
[14:23] <Mirv> flexiondotorg: oh, a correction. they're right there in the queue, so no problem. it's the final freeze that just started in action.
[14:29] <flexiondotorg> Mirv, Which packages? mate-tweak, mate-settings-daemon, and mate-dock-applet?
[14:30] <Mirv> flexiondotorg: yes, and I saw they were actually synced before already as promised by barry. but they'll stay in the unapproved queue for some time now.
[14:30] <flexiondotorg> Mirv, OK. I requested an unblock.
[14:32] <Mirv> flexiondotorg: what about pluma or eom? sil2100 commented on the bugs probably mistaking the current archive rework for them not being in debian unstable. anyway, would you need them before final beta?
[14:32] <barry> yeah, it was a bit unfortunate that the debian import bug overlapped with final beta freeze.  i guess it will all work out tho
[14:32] <flexiondotorg> Pluma would be good because is fixes a shell code injection.
[14:32] <sil2100> Mirv: well, I checked the tracker in the morning and didn't see those, syncpackage didn't find the new versions as well
[14:33] <flexiondotorg> eom just correct man page formatting.
[14:33] <cjwatson> Which morning?
[14:33] <sil2100> syncpackage: Error: Version in Debian 1.12.2-1 (unstable) isn't newer than Ubuntu 1.12.2-1 (xenial-proposed)
[14:33] <sil2100> This is what I got around 2-3 hours ago
[14:33] <sil2100> Ah, someone synced that already, sorry
[14:33] <sil2100> Miss-read it ;)
[14:33] <cjwatson> sil2100: The Debian archive publisher has also been broken for a couple of days.
[14:33] <sil2100> k
[14:34] <cjwatson> So anything uploaded to Debian for the last couple of days won't be visible, but not due to any fault on our side.
[14:34] <Mirv> sil2100: yes so that's the reworks, syncpackage now started working two hours ago
[14:34] <sil2100> Ok, all clear, since I didn't see it in https://tracker.debian.org/pkg/eom , syncpackage wasn't helping in the morning, so well
[14:37] <cjwatson> superm1: if you want removals to happen, please subscribe ubuntu-archive to the bug - commenting on a bug I filed and hoping that I'll see the bug mail only works by luck
[14:37] <cjwatson> (bug 1339073)
[14:37] <ubottu> bug 1339073 in mythnettv (Ubuntu) "depends on mplayer/mencoder, which don't work with libav 10" [Undecided,New] https://launchpad.net/bugs/1339073
[14:37] <cjwatson> superm1: can't deal with it at the moment but I've subscribed ubuntu-archive so that it's in the queue
[14:46] <nacc> slangasek: we can drop pnp4nagios :) (https://github.com/lingej/pnp4nagios/issues/125#issuecomment-199683297)
[14:47] <Son_Goku> nacc: do we have a list somewhere of php things that have worked/failed so far with php7?
[14:48] <Son_Goku> because you haven’t been updating the etherpad and apparently magic happened and every single thing has been a success in the ppa...
[14:48] <nacc> Son_Goku: not really, I provided in a bug a list of packages that rebuilt successfully here with some sed commands
[14:48] <Son_Goku> ah
[14:48] <Son_Goku> nacc: it seems like this has gone… really smoothly
[14:49] <nacc> Son_Goku: well, we still have 400+ pacakges that depend on php5 in the archive
[14:49] <Son_Goku> right
[14:50] <Son_Goku> nacc: are we keeping drupal 7 in xenial? afaik, only drupal8 is fully supported with php7
[14:51] <nacc> Son_Goku: well, drupal8 isn't packaged in a debian either
[14:51] <Son_Goku> erk
[14:51] <nacc> Son_Goku: will have to see once i get to it on the list
[14:52] <Son_Goku> nacc: since I think we’ve got most of the core things out of the way, I think I’ll focus more of my efforts on testing applications with php7 to see if they pass a basic sanity check
[14:52] <nacc> Son_Goku: sounds good
[14:52] <nacc> Son_Goku: it would be good to verify the various extensions work too, php-memcached, etc.
[14:52] <Son_Goku> yeah
[14:52] <Son_Goku> I expect that I’ll hit the extensions as I do this
[14:53] <nacc> Son_Goku: great, thanks
[14:53] <Son_Goku> np
[15:04] <Mirv> doko: can you think of something during the last two weeks (since 2016-03-07) that could cause this behavior change on i386/armhf bug #1560528 ? I'm trying to figure out if it's something to worry about or not, that out-of-range mappings don't fail.
[15:04] <ubottu> bug 1560528 in qtbase-opensource-src (Ubuntu) "tst_LargeFile::mapOffsetOverflow started failing on 32-bit xenial" [Undecided,New] https://launchpad.net/bugs/1560528
[15:05] <nacc> Son_Goku: it would also be good to periodically scan new bugs against php5 and php7.0 packages
[15:06] <nacc> cyphermox: debian maintainer might have already contacted you about it, but he said your sg3-utils changes failed to build?
[15:07] <cyphermox> yes
[15:07] <nacc> cyphermox: ok, thanks; sounds like he's willing to cut a 1.41-2 once that's resolved
[15:08] <cyphermox> nacc: sg3-utils is built in Ubuntu; so it's just a matter of figuring out what small bit is missing
[15:26] <nacc> cyphermox: ah i see
[15:27] <cyphermox> nacc: it's not currently my top priority, do you want to look into it? I'm guessing you ask because you need sg3-utils for something?
[15:28] <cyphermox> otherwise I'll get to it tonight after work.
[15:29] <nacc> cyphermox: i can add it to my list, but no guarantees :) it was on my list of debian differences to look at, but honestly, while we can sync to get the versions to match, it seems like it would be almost exactly our delta being applied, as debian has been taking your patches :)
[15:29] <cyphermox> yes
[15:29] <pitti> cjwatson: oh, so many lgw buildds down? that cloud seems to work reasonably well for me
[15:30] <nacc> jgrimm: --^ can you take it off the list for now?
[15:30] <cjwatson> pitti: those went down about a day or so, I'll try kicking them.
[15:30] <cjwatson> *day or so ago
[15:32] <jgrimm> nacc, ack. got it.
[15:33] <pitti> infinity: spoon-feeding langpack upload now (uploading is achingly slow since this moved to snakefruit, argh)
[15:33] <pitti> about 2.5 packages per minute, so this will take ~ 2 hours
[15:34] <cjwatson> which bit is slow?
[15:34] <pitti> cjwatson: dput to upload.ubuntu.com
[15:34] <cjwatson> that's peculiar, should be much faster
[15:34] <pitti> cjwatson: macquarie got decommissioned as it ran on lucid, so langpack builds got moved to snakefruit
[15:35] <pitti> I already verified that it's not going through the proxy
[15:35] <cjwatson> I mean, OK, snakefruit tends to be loaded, but dput is hardly CPU-intensive
[15:35] <pitti> it's loaded in the mornings due to that git --repack thingy, but it's not particularly loaded right now
[15:35] <pitti> 3.8, that's laughable
[15:35]  * pitti has seen 80 in the mornings with that git job
[15:36] <pitti> it apparently doesn't seem to be a bandwidth problem, as even uploading the empty ~ 1 kB update packages takes ages
[15:47] <doko> also seen here
[15:48] <infinity> pitti: Landing systemd seems reasonable to me.
[15:49] <pitti> doko: where do you try it from?
[15:49] <doko> pitti, dput from home
[15:49] <cjwatson> ftp or sftp?
[15:50] <infinity> Laney: *raise brow*
[15:50] <infinity> Laney: Lemme look.  That seems not sane.
[15:50] <pitti> ftp
[15:50] <Laney> infinity: greetings
[15:50] <doko> dput's default
[15:51] <cjwatson> pepo isn't loaded either
[15:51] <Laney> infinity: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1560459 is you-ish too (sorry)
[15:51] <ubottu> Launchpad bug 1560459 in ubiquity (Ubuntu) "ubiquity crashed with GLib.GError in customize_installer(): vte-pty-error: grantpt failed: Operation not permitted (1)" [Critical,Confirmed]
[15:52] <infinity> Laney: I see all sorts of locales being generated in the build log.
[15:52] <Laney> Quite
[15:53] <infinity> The grantpt one is more interesting.
[15:53] <jgrimm> cyphermox, xnox were one of you going to be able to sponsor/upload multipath-tools for rharper?
[15:53] <cjwatson> an strace -f -s1024 -tt of the client side of dput might perhaps enlighten slightly
[15:55] <infinity> Laney: Grabbing an ISO now to see WTF is up.
[15:55] <infinity> Laney: I'm running 2.23 locally with all sorts of vte terminals and no such problem, so I'm guessing it's something to do with the live system itself.
[15:56] <Laney> infinity: It's probably some pkexec/sudo madness with ubiquity
[15:56] <doko> locale issue with perl? but only on ppc64el so far: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/r/redmine/20160322_153214@/log.gz
[15:56] <doko> infinity, ^^^
[15:58] <infinity> doko: That's just what perl does when your environment references a locale you don't have built.  I blame the ppc64el adt image.
[15:59] <infinity> Given those images shouldn't even have locales installed, they sure shouldn't have an environment referencing anything other than C or C.UTF-8
[15:59] <infinity> pitti: ^
[16:26] <pitti> "unable to connect to postgresql server"
[16:26] <pitti> I'm quite sure they do have locales installed, it's in minimal
[16:27] <pitti> ah yes, invalid locale when configuring postgresql, hmm
[16:27] <pitti> the default locale in autopkgtest is C.UTF-8
[16:27] <pitti> why would that not be available
=== dpm is now known as dpm-afk
[16:28] <dobey> is there a trivial way to evaluate a "foo | bar" build dependency to see what the result would be, without building a source package and trying to build it?
[16:29] <pitti> dpkg-checkbuilddeps checks for missing ones at least
[16:29]  * pitti waves good night, not feeling well
[16:30] <dobey> night pitti
[16:40] <Laney> infinity: https://paste.ubuntu.com/15473053/ <- that totally fixes it
[16:40] <Laney> but is it sane?
[16:41] <infinity> Laney: Oh, hrm.  The usage there might not be sane in the first place.  Lemme look at the context.
[16:41] <Laney> infinity: /usr/share/locales/install-language-pack grew this parameter too with 2.23
[16:42] <infinity> Laney: Right, it's the other part I'm questioning.
[16:42] <infinity> Laney: Since I dropped the ability to call "locale-gen $random-lang"
[16:44] <infinity> Ahh, but it also writes to /etc/locale.gen which will work.
[16:44] <infinity> Laney: So, you can probably drop the second argument.
[16:44] <infinity> Laney: Then the only difference between keep-existing and not will be performance.
[16:46] <Laney> I guess it's because install-language-pack does *not* write to locale.gen
[16:46] <infinity> Laney: No, it's because we're calling locale-gen with that extra arg.
[16:46] <infinity> Which changes where it looks for generation.
[16:47] <infinity> Laney: If you call locale-gen bare, it uses /etc/locale.gen and /var/lib/supported.d/*
[16:47] <infinity> Laney: if you call it with the second arg, it only uses /var/lib/supported.d/$arg
[16:47] <infinity> Laney: Which doesn't exist when calling it with random strings.
[16:47] <Laney> 'kay, so just /usr/sbin/locale-gen will work
[16:47] <Laney> lemme try that
[16:47] <infinity> Laney: So, drop the second arg to fix the bug, and add --keep-missing for performance reasons.
[16:48] <infinity> keep-existing, even.
[16:48] <Laney> nod
[16:49] <slangasek> --just-keep-swimming
[16:49] <infinity> --dont-stop-believing
[16:50] <Laney> 'Just' #1560459 then
[16:50] <infinity> Laney: Yeah, I'm looking at that one right now.
[16:53] <matsubara> Hi there, not sure who to ask about the debian-installer, but we got a bug report for the server iso https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1559507 where the keyboard selection fails. I commented in the bug report with what I found about the issue and would like to ask someone that knows better about the installer. Who would be that person?
[16:53] <ubottu> Launchpad bug 1559507 in debian-installer (Ubuntu) "Keyboard selection is missed" [High,Confirmed]
[16:56] <dobey> dpkg-checkbuilddeps: Unmet build dependencies: golang-go (>= 2:1.6) | gccgo
[16:56] <dobey> :(
[16:57] <infinity> dobey: build log?
[16:59] <infinity> Laney: Huh.  Surprisingly, fixing the locale also lets gnome-terminal start again.
[17:00] <Laney> infinity: Yeah. It was failing because it was sad about the locale.
[17:00] <Laney> the bug was initially reported by davmor2 as "gnome-terminal doesn't start" :)
[17:01] <davmor2> infinity, Laney: it might also fix ubiquity as cyphermox said that the session calls terminal
[17:02] <Laney> nein
[17:02] <davmor2> :(
[17:02] <davmor2> shame would of been nice
[17:02] <dobey> infinity: https://launchpadlibrarian.net/249586552/buildlog_ubuntu-vivid-ppc64el.pay-service_15.10+15.04.20160322-0ubuntu1_BUILDING.txt.gz
[17:03] <dobey> infinity: but the unmet i pasted was from me playing around with a local control file to see if i could come up with something that works on vivid, without having to generate control from control.in
[17:05] <infinity> dobey: Oh.  If you're doing it locally, you want to feed --resolve-alternatives to sbuild
[17:05] <superm1> cjwatson: ah okay thanks will do in future
[17:05] <infinity> dobey: That's the LP default, but not the sbuild default.
[17:06] <Laney> casper uploaded
[17:06] <cyphermox> davmor2: to be precise, I expected that fixing glibc would fix ubiquity
[17:06] <dobey> infinity: i'm just doing dpkg-checkbuilddeps locally
[17:06] <infinity> dobey: dpkg-checkbuilddeps should be happy with that if one of those package is installed.
[17:07] <infinity> cyphermox: Not sure yet if anything needs to be "fixed" in glibc, per se.
[17:07] <infinity> cyphermox: But I'm tracing back where that error comes from in the first place.
[17:07] <dobey> infinity: it's only happy if it's installed though?
[17:07] <cyphermox> infinity: ok
[17:08] <infinity> dobey: Well, yes.  That's the point of dpkg-checkbuilddeps.
[17:09] <dobey> oh
[17:09] <dobey> so i have to do an actual build to do an actual test i guess
[17:10] <dobey> ok
[17:10] <infinity> Hrm. I wonder if a vte rebuild would just fix it.
=== spineau is now known as spineau_afk
[17:19] <infinity> Laney: I'm deep in vte hell.  Having a hard time believing this isn't already fixed, since we're pretty much the last distro to drop pt_chown.  Still digging.
[17:57] <mitya57> cjwatson, were syncs really fixed? syncpackage python-markdown says that version 2.6.6-1 has not been picked up by LP yet, however it was uploaded ~35 hrs ago.
[17:58] <mitya57> (should I just wait?)
[18:01] <cjwatson> mitya57: Syncs were really fixed, but independently, the Debian archive publisher is broken ...
[18:01] <cjwatson> mitya57: And has been for a couple of days
[18:02] <cjwatson> mitya57: It's all fine at our end, but we can only pick up things that Debian has actually published for real
[18:02] <cjwatson> mitya57: You'll be able to see when Debian's stuff is fixed by watching the timestamp on http://ftp.debian.org/debian/dists/unstable/InRelease
[18:03] <mitya57> cjwatson, ah, thanks, that explains it
[18:03] <mitya57> I now see that in #debian-devel topic :)
[18:04] <cjwatson> Breaking multiple things in the same area is an excellent way to confuse everyone about which bits are fixed.
[18:15] <slangasek> nacc: hum, please /don't/ open tasks for packages that can be rebuilt without modification... those should really just be a list of packages
[18:16] <slangasek> if you open tasks for them, we have to close the tasks again, and then it's not an automated process ;)
[18:16] <nacc> slangasek: ah ok, it's only the one soo far
[18:16] <nacc> slangasek: feel free to delete the one for assetic, i'll provide a list for the remainder as i encounter them now
[18:29] <nacc> Pharaoh_Atem: can you look into php-memcached? I think it's installing the .ini file in the wrong place, /etc/php/mods-available ... similar to waht you saw with imagick, slangasek
[18:30] <Pharaoh_Atem> nacc: sure
[18:30] <Pharaoh_Atem> one moment
[18:38] <nacc> Pharaoh_Atem: slangasek: i think we just need another rebuild of php-memcached, i just built the version in release and it poitned to thee right location in /etc/php/7.0/; do you want a bug for that request?
[18:41] <mapreri> JOOI, does somebody have any idea how/what it would take to move from ubuntu's system of building -dbgsym to the debian's implementation?
[18:41] <slangasek> nacc: I'll kick off a no-change rebuild, no bug neede
[18:41] <slangasek> d
[18:42] <nacc> slangasek: thanks! I think i will do a search at some point if any pcakges refer to /etc/php/mods-available, as they need a rebuild if so
=== alexisb is now known as alexisb-afk
[18:50] <pitti> infinity: all langpacks, and systemd, waiting in xenial-proposed; I take it you want to steer the landing yourself, to coordinate with rebuilds?
[18:50]  * pitti crawls back to bed, cu tomorrow
[18:51] <sarnold> gnight pitti :)
[18:52] <infinity> pitti: I'd be more than happy with you letting them all in.
[19:17] <Pharaoh_Atem> nacc: looks like php-memcached is installing to the wrong location
[19:17] <Pharaoh_Atem> it threw warnings at me
[19:18] <nacc> Pharaoh_Atem: might still be pending a rebuild
[19:19] <nacc> Pharaoh_Atem: build2 is in proposed, i think
[19:19] <nacc> https://launchpad.net/ubuntu/+source/php-memcached
[19:56] <mwhudson> good morning distro
=== nhandler_ is now known as nhandler
=== alexisb-afk is now known as alexisb
=== salem_ is now known as _salem
[22:06] <nacc> slangasek: so cakephp (universe) only supports php7 with 2.8 (which is now in experimental)
[22:06] <nacc> slangasek: https://github.com/cakephp/cakephp/issues/8087
[22:07] <nacc> slangasek: we don't run the tests (although they do exist) so the 2.7 version will appear to build and work; but realistically we should either ship 2.8 or nothing if we are moving to php7
[22:08] <slangasek> nacc: cakephp has a revdep (zoneminder), so if 2.8 will be compatible with zoneminder, syncing from experimental seems preferable
[22:09] <nacc> slangasek: yep, i saw that just now, will look at it now
[22:10] <nacc> slangasek: so i think zoneminder is 2.8 compat, but i'll need to test it in my lxc (https://github.com/ZoneMinder/ZoneMinder/pull/1306)
[22:40] <nacc> slangasek: LP: #1560709
[22:40] <ubottu> Launchpad bug 1560709 in zoneminder (Ubuntu) "Please sync cakephp 2.8.0-1 from Debian experimental" [Undecided,New] https://launchpad.net/bugs/1560709
[22:40] <nacc> slangasek: on rebuild of zoneminder, it changes the dep to need cakephp >= 2.8.0, as well
[23:05] <nacc> slangasek: thanks for the quick turnaround on php-memached, i can confirm the new version is correct in the archive now
[23:05] <nacc> Pharaoh_Atem: --^
[23:19] <Pharaoh_Atem> nacc: double checking now
[23:21] <nacc> Pharaoh_Atem: thanks
[23:28] <Pharaoh_Atem> nacc: looks peachy 👍
[23:29] <nacc> Pharaoh_Atem: cool, thanks for confirming
[23:29] <nacc> Pharaoh_Atem: do you konw what, normally, would provid phpdoc?
[23:29] <nacc> as a command
[23:31] <Pharaoh_Atem> php-pear(PhpDocumenter)
[23:31] <nacc> Pharaoh_Atem: is that pacakged in either debian or ubuntu?
[23:31] <nacc> i don't thnk it is
[23:31] <Pharaoh_Atem> let me quickly check
[23:31] <nacc> Pharaoh_Atem: davical calls it unconditionally in its makefile, which is fine, but means we're not generating docs for it
[23:31] <Pharaoh_Atem> O.o
[23:32] <Pharaoh_Atem> holy crap, it's missing
[23:32] <nacc> not a new issue, but i wonder if it should be something that is pacakged
[23:32] <Pharaoh_Atem> how is something like that... missing?!
[23:32] <nacc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=206536
[23:32] <ubottu> Debian bug 206536 in wnpp "RFP: php-phpdocumentor -- phpDocumentor provides automatic documenting of php api" [Wishlist,Open]
[23:33] <Pharaoh_Atem> Fedora has had it since at least Fedora Core 6
[23:33] <nacc> on 10/2013, it seems like php-apigen was considered a replacement
[23:34] <Pharaoh_Atem> but it doesn't provide /usr/bin/phpdoc
[23:34] <nacc> agreed :)
[23:34] <nacc> i meant, functionally
[23:34] <Pharaoh_Atem> and doesn't use the same format as phpdoc either
[23:34] <nacc> or that ml post claims as much
[23:34] <nacc> i'll e-mail ondrej
[23:36] <Pharaoh_Atem> afaik, apigen is also only useful for web based documentation
[23:37] <nacc> clearly no one has been pushing for it in debian or ubuntu :/
[23:38] <Pharaoh_Atem> that's... unfortunate
[23:45] <nacc> slangasek: is it worth me trying to fixup dh-make-php to be php7 compatible, or should we just drop it? it only support php5, afaict, and i believe pkg-php-tools supersedes the functionality
[23:45] <nacc> Pharaoh_Atem: would appreciate your input too
[23:46] <nacc> there is a reverse build-dep on it, but i'm looking into that now
[23:46] <Pharaoh_Atem> if the functionality is fully superseded, I don't see a reason why dh-make-php is needed
[23:47] <Pharaoh_Atem> do the pkg-php-tools provide a debhelper thing?
[23:47] <slangasek> nacc: it's not for me to say what's worth fixing or not; anything that's not worth fixing, we should definitely remove.  and dh-make-php only has two revdeps (php-letodms-lucene->letodms), so I don't think it'd be at the top of the priority list
[23:47] <nacc> slangasek: agreed, i'm just looking at so much stuff, appreciate other eyes periodically :)
[23:47] <slangasek> dh-make-php is a helper tool for source package templating. I'm not sure why something would build-depend on it at all
[23:48] <nacc> slangasek: i don't think it actually should
[23:48] <nacc> it was used to build the package originally
[23:48] <nacc> afaict
[23:48] <nacc> ah ha... per `man dh_pecl`:
[23:48] <nacc> "If you use this program, your package should build-depend on php4-dev and
[23:48] <nacc> php5-dev, as well as dh-make-php (the package containing this script)."
[23:48] <nacc> i wonder why
[23:49] <Pharaoh_Atem> helpful as always, I guess
[23:52] <nacc> trying a build w/o it
[23:55] <nacc> ah ah, it relies on a cdbs pear.mk provided by the same package
[23:55] <nacc> slangasek: so it's a hlper & runtime tool :/
[23:55] <nacc> err, build-time
[23:56] <slangasek> nacc: oh, cdbs; yeah, nuke it all from orbit ;)