=== Spads_ is now known as Spads === JanC is now known as Guest61812 === JanC_ is now known as JanC [06:11] I'm *pretty* sure that the switch to systemd-resolved has crazily broken DNS in my lxc containers. [06:11] And with that, Happy Holidays! I'm off! === smb` is now known as smb === smb is now known as Guest58912 === Guest58912 is now known as smb [09:42] morning! matplotlib, python-stdlib-extensions and pandas show test regressions in lmfit-py on armhf - where lmfit-py is not installable since python-pandas removal. What needs to be done to let them migrate? [09:48] Can some SRU team member please review owncloud-client in Yakkety queue? It is the second part of the fix for the serious bug (because owncloud-client makes the whole desktop unusable, LP: #1635577). [09:48] Launchpad bug 1635577 in unity (Ubuntu) "memory leak in unity-panel-service" [High,Triaged] https://launchpad.net/bugs/1635577 === marcusto_ is now known as marcustomlinson [10:52] hi all - I just upgraded to zesty (finally!), but am a bit surprised by seeing 2 network-related applets loaded? Is that known/desired? [10:54] what I mean is: https://www.dropbox.com/s/2553cau97dadn86/applets.png?dl=0 [10:55] and that "missing icon" shows flight mode, VPN and wifi switches [12:47] BenC, hello! long time no speak. [12:47] xnox: Hello [12:48] BenC, I don't see you idling on #ubuntu-powerpc and your last upload is from 2013. Haven't seen you during most recent UOS powerpc discussion either. So you are not quite as active as you used to before, way back when. [12:49] BenC, are you picking up maintainance in Debian? as powerpc port there got relegated to non-release one. [12:49] Agreed, but that doesn’t preclude me from being contacted when the TB claims to have contacted the community. [12:49] BenC, currently we see a lot of fallout from powerpc port. FTBFS + lack of toolchain maintainance and support. [12:49] BenC, we did reach out to a few people, including some new company in UK that also does powerpc hardware. [12:50] BenC, from my point of view, irrespective of people and companies involved. [12:51] lack of golang-go support and gcc/binutils support/development upstream is a huge red flag. [12:51] It’s an obstacle that can be overcome, though. [12:51] BenC, as far as I undersntad big endian port is not tier1 in gcc upstream =/ [12:51] And seriously, I fixed haskell on ppc when it was a huge mess. [12:52] BenC, but seriously, lack of openstack and golango is a blocker to run a lot of infrastructure that we depend on. [12:52] most launchpad builders are in scalingstack now (s390x will be very soon) [12:53] and we run autopkgtests based on that. And there is no support for docker (lack of golang) and other go based tools (e.g. juju) [12:53] I understand that I personally haven’t devoted a lot of time lately to powerpc, but everyone in Ubuntu who should know, knows I am THE guy that handles ppc and if some discussion came up, I should have gotten a courtesy poke. [12:53] That not happening is egregious to say the least. [12:53] BenC, without firefox, golang, and openstack => i do believe powerpc is a viable platform for any new workloads on either server or desktop. [12:54] Regardless of the outcome (which probably would haven’t changed), it was not an oversite, it was a bad choice. [12:54] hence 2016-04 + 5 years is the timeframe to get people off it. [12:54] No one is getting off of it. PPC is not a dead platform. [12:55] lack of openstack is a red herring FWIW [12:55] BenC, part of the TB decision to announce now about removal for feature freeze, to give a really huge public red warnings, such that if there is actuall demand for this port, to commit to revitalise it. [12:56] I’m not committing to support something that was literally yanked out from under me without so much as a /m on IRC. [12:56] I’ve put years and hundreds of hours into already and it got me nothing. [12:56] the reason powerpc isn't in scalingstack yet is that we haven't yet finished deploying the new scalingstack region with new (already-written) charms that will let us run builders for an alternate architecture that isn't runtime-switchable [12:57] so please don't use scalingstack as a reason here, it's not the port's fault [12:57] ack. [12:57] cjwatson, my understanding was that it's possible to do powerpc virtual machines on ppc64el hardware, but not on powerpc hardware. Or is that a wrong statement too? [12:57] That’s bull [12:57] just don't use this as a reason if you don't understand it :P [12:58] I run VMs on my hardware with KVM all the time. [12:58] but in any case that's irrelevant for scalingstack, since we intend to run it on ppc64el hardware [12:58] (seeing as we have it) [12:59] ack. [12:59] what about firefox and golang then? [12:59] juju has decided not to support running on 32-bit AIUI, but that's not fatal [13:00] I’ve fixed firefox on ppc at least 4 times in the past. [13:00] Go lang, I’ve nevr looked at but it can’t be insurmountable. [13:00] i think it needs an upstream buildbot [13:00] (firefox) [13:00] rather than keep on fixing it downstream. [13:02] All technical reasons aside. If the TB decided that, I support the TB. [13:02] BenC, from my point of view i'm more inclined to kill i386 & armhf than powerpc, but all of them are on my personal "no longer relevant list". [13:02] What I don’t support is an out right lie that the TB contacted relevant persons in their decision. [13:03] e.g. we have been seeing i386-only graphical/desktop bugs in the last development cycle which nobody notices. [13:03] armhf> geez [13:03] hello realism [13:03] * xnox wants 128bit computers for christmas [13:04] =) [13:04] I don't think architecture removal is a fit subject for trolling :P === scottt is now known as Guest31038 [14:10] BenC: golang should be working on ppc64 and ppc64le [14:11] at least here in Fedora, we have it working: https://koji.fedoraproject.org/koji/buildinfo?buildID=822120 [14:12] the only architecture we don't have golang working on is s390 (it works on s390x) [14:13] Son_Goku: "powerpc" is the Ubuntu name for the 32-bit big-endian port [14:13] anyone still around from the CD Image Team able to have a quick look at this please? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-budgie [14:13] Son_Goku: it works on Ubuntu ppc64el too [14:13] xnox: I agree with you on armhfp, only because it's a huge nuisance to get working [14:14] why can't everyone just be on proper aarch64 :) [14:14] cjwatson: you guys don't support ppc64 (big endian), I guess? [14:36] Son_Goku: not at the moment [14:36] ehh, if you don't have to, don't [15:27] Tribaal: indicator-network shows up in zesty because of how systemd works, and there not being a unity8 systemd session thing yet [15:27] Tribaal: there's an open bug about it already [15:30] also, a fix in this silo https://bileto.ubuntu.com/#/ticket/2321 [16:31] cjwatson: still around? I believe the reason by the builds for Ubuntu Budgie are failing is because there are no tasks in this project - lp:~ubuntu-core-dev/tasksel/ubuntu ... correct assumption? [16:36] possibly but I'm afraid I'm out of time to look at that [16:36] there's an update script in tasksel, should just need updating the Makefile for budgie and then running it, hopefully [16:50] cjwatson: ok - thanks for your help. I've created a bug report and proposed a merge. Hopefully someone can pick this up in the new year. cheers. === davmor2 is now known as davmor2_EOY === Sir_Gallantmon is now known as Son_Goku === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [18:33] How do I prepare this pkg for Ubuntu? http://ppa.launchpad.net/nilarimogard/webupd8/ubuntu/pool/main/y/youtube-dlg/ [19:56] dobey, i have a fix for it too! [19:56] Trevinho, ^ [19:56] indeed pete-woods pointed it out. [19:57] xnox: eh? [19:57] oh [19:57] you mean Tribaal there, not Trevinho i guess [19:59] I just forgot I had unity 8 installed TBH [19:59] Tribaal, hehe. [20:00] i should really land that silo, I guess. [20:00] then again, i am on holiday. [20:00] doko, python 3.6 is so nice, i want it default =) [20:01] xnox: it could totally wait until next year as far as I'm concerned :) [20:01] Python 3.6 <3 [20:06] that silo isn't ready to land [20:06] xnox: ^^ so don't worry about it :) [20:06] ack [20:07] the other silo we were asking you to land, has some issues, too :( [20:16] happy new year =) didn't get a chance to look into it [20:16] * xnox was EOY yesterday [20:20] well it's not my fault you're on irc :) === JanC is now known as Guest57833 === JanC_ is now known as JanC [22:29] where is the source code for resolvconf? [22:30] in a graveyard [22:30] deep in Debian Alioth [22:30] where zombies hack on things to make our lives more confused [22:32] karstensrage: do you mean the ubuntu package? [22:32] karstensrage: you can use `pull-debian-source` or `pull-lp-source` [22:33] https://anonscm.debian.org/cgit/resolvconf/resolvconf.git appears to be an active git repository [22:37] i mean the actual source code [22:37] not the debian package [22:39] it's a native package, so that presumably is the "actual sourcecode" [22:39] karstensrage: well pull... get you the source for the package. Given a homepage of: http://alioth.debian.org/projects/resolvconf/, cjwatson's link seems correct [22:39] https://alioth.debian.org/scm/?group_id=30851 as well [22:39] at least it's more active than os-prober [22:39] .... [22:39] the Debian package is a superset of the source code, anyway [22:40] yep [22:40] ironically, given that os-prober is used in more distros, it should be less dead [22:41] yeah, we should get round to doing a patch application run there [22:51] so there is no C code for resolvconf its just a bunch of scripts? [22:54] karstensrage: doesn't appear to be any [22:55] hmm [22:55] so i am writing an NSS library like nss_ldap [22:55] 16.04 fails to boot up if the library is ithere [22:55] its due to resolvconf calling getpwnam("*") [22:56] so where would it be doing that? [22:58] karstensrage: how do you know resolvconf is the one doing this? [22:59] i log it [22:59] getpid and then open /proc/pid/comm [23:00] karstensrage: resolvconf itself is just a shell script [23:02] karstensrage: execsnoop may give you some extra visibility on what's going on https://github.com/brendangregg/perf-tools [23:02] it might be hard to execute it early enough though :/ [23:07] cjwatson: there's even a bug in rhbz where there are complaints that patches sent upstream aren't getting applied in os-prober [23:09] cjwatson: https://bugzilla.redhat.com/show_bug.cgi?id=875356 [23:09] bugzilla.redhat.com bug 875356 in os-prober "OS prober is slow" [Unspecified,New] [23:10] ok, we clearly haven't been doing well there. bugging me about it tonight isn't going to work though, exhausted [23:10] so rain check please? [23:10] cjwatson: sure [23:10] can do without the highlights about it in multiple channels [23:10] cjwatson: did you not see my messages this morning in #debian-boot? [23:11] cjwatson, yes, of course, I was trying to get somebody's attention, though :/ [23:11] that's what I mean by multiple channels [23:12] and it was dinnertime so I didn't reply straight away [23:12] what time zone are you in? [23:12] Europe/London [23:12] ah [23:12] that explains it [23:12] my morning was your evening [23:12] sorry [23:13] as long as you're aware of it and can do something about it, then everything will be fine [23:14] I do need a break for a while to have Christmas/Hanukkah and stuff, but hopefully after that [23:14] that's fine [23:15] all I ask is for some acknowledgement so that everyone knows upstream isn't dead :) [23:15] I don't want to go on the cart [23:22] I have a question about the packaging process. I am following this currently http://packaging.ubuntu.com/html/packaging-new-software.html#starting-a-package but im not understanding how to start a new package [23:23] this is just changing a package that already exists [23:23] cjwatson: Son_Goku: what about os-prober? or is this purely an upstream thing? [23:23] disclaimer: I'm not completely there, I have some food cooking for tomorrow I need to check on. [23:25] cyphermox: upstream os-prober has been kind of dead-ish for the past year, and various distros (Fedora, openSUSE, Mageia, etc.) have been forced to heavily patch os-prober to make it functional because they languish... somewhere (in the ML?) [23:25] Son_Goku: ah, ok [23:26] this is particularly problematic in the Fedora community, as we keep fixing things and now the maintainer has stopped bothering trying to send stuff upstream because nothing happens [23:27] now a couple of folks are saying that we should fork it because Debian upstream doesn't seem to care and everything is stalling waiting for them to review and merge things [23:27] (I particularly dislike forking for this purpose, because it's usually quite easy to solve that problem without forking) [23:27] yeah, we'd definitely prefer to avoid that, it would be a bunch of unnecessary annoyance [23:28] that's why I was trying to get someone's attention this morning [23:28] * cjwatson adds a card on their trello board so that it stands some chance of actually happening [23:28] again, sorry for being rude to you, but I'd really rather not end up in another situation where this happens again [23:29] the last time this happened with a debian upstream project, we wound up having two implementations of update-alternatives [23:29] eesh, that [23:29] and that situation *still* persists [23:29] technically, there are three now :/ [23:29] because one didn't know about the other fork [23:29] cjwatson: you're upstream for os-prober? [23:29] tbf the period when dpkg was at best semi-maintained wasn't fun for Debian either [23:29] cyphermox: well, d-i committer, and I've done a bunch on it in the past [23:30] ack [23:30] not for a while because I've generally not done much with d-i [23:30] well in that case I could just as well merge patches [23:30] but grub2 wants it to work well, so ... [23:30] yep [23:30] cjwatson: I understand, we had a similar situation with rpm a few years ago [23:30] cyphermox: be my guest :) [23:30] it seems we're all doomed to have these happen to us :) [23:31] cjwatson: I'll have a look, but not this weekend :/ [23:31] indeed! [23:31] oh, and if you're curious: there's the original Debian Perl implementation of update-alternatives, which was forked by Mandriva to be used for its distro, now used by OpenMandriva [23:32] separately, Red Hat reimplemented it in C for the Red Hat/Fedora family, and that implementation is used today in Fedora, and Mageia just switched to it [23:32] hippybear: you might start with debmake [23:32] we have guests for dinner on Sunday so I need to do All The Tidying, and I'm singing a solo at church on Saturday night ... [23:32] hippybear: you have an entirely new package? [23:32] and SUSE uses a modified version of the original Debian Perl version [23:32] and Debian itself independently rewrote it later into C and uses that version now [23:32] so... fun times :/ [23:36] of course, SUSE also did the thing where they reimplemented chkconfig in Perl, and that version (not the original one in C) is what's packaged in Debian [23:38] * cjwatson looks at SUSE's man-db patch again [23:38] lalala I wish I hadn't done that [23:42] sometimes I wonder about SUSE... [23:44] cjwatson: run before it's too late [23:44] and happy holidays; I'm off to check on the cooking and various other preparations ;) [23:45] sometimes I wonder if I should bother filing bugs against chkconfig and other things like it in Debian [23:45] then I remember that people rarely respond to bugs in debbugs, and then I walk away [23:46] even LP has a better track record than debbugs