[00:11] hi there, are there any Canonical folks here at SCALE still? === jincreator is now known as jincreator_ [06:01] I get package iso-codes_3.57-1_all.deb Size mismatch error when trying to create build target in SDK, , Does anyone know this problem? === jincreator is now known as jincreator_ [09:54] doko: hi, i've uploaded aster, i think petsc should migrate now [12:00] autopkgtest for vlc 2.2.1-5: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression, s390x: Pass [12:00] can anybody please retry ppc64el ^^^ libupnc [14:03] hmm... I don't understand from what branch a package is coming from [14:07] if I take a look at https://launchpad.net/ubuntu/+source/reprepro, I see a precise package from 2014-05-20 with version 4.8.2-1ubuntu0.1 [14:08] however, switching to the "code" tab and examining the lp:ubuntu/precise/reprepro branch on https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/reprepro/precise I can only see the latest change being a rebuild on 2012-03-16 [14:09] so that seems to be the wrong branch to clone, but what is the correct one? [14:12] there may well not be one. use pull-lp-source [14:13] the automatic importer thing is falling apart and due a replacement [14:13] urgh, okay... [14:13] let's see what pull-lp-source actually is [14:13] we plan to replace it with a thing based on git but still have more pieces to write [14:14] pull-lp-source just downloads the source package, but has suite lookup and such so that you don't have to work out versions manually and so that it doesn't necessarily have to correspond with what's in your apt cache [14:15] ah, that's a program [14:22] that probably downloaded the dpkg source... well, whatever, seems there is no corresponding bazaar branch [14:26] right, either synthesise it yourself or make do without, I'm afraid [14:28] the git import should be more reliable once we have that going, as it's fundamentally harder to get it into a state where it doesn't want to proceed (but we don't have it scheduled yet - it'll be months rather than weeks) [14:30] I can synthesize it myself [14:30] it's just some metadata changes and a quilt patch [14:50] do you plan to switch from bzr to git? [15:22] Ionic: as I said above, that's the plan for the package imports, yes [15:32] but not for general development? [15:32] Ionic: likely that too, but organically over time rather than a big flag day [15:33] Ionic: various bits and pieces have already switched [15:34] Ionic: it won't be an "as of June everyone must switch away from bzr" kind of thing; I wouldn't ever expect that [15:35] huh, okay, just asking because I personally prefer git and always have a hard time mapping git concepts back to bzr whenever I use launchpad [15:36] Ionic: well, whenever you use bzr on Launchpad as opposed to git on Launchpad, you mean :-) [15:36] Ionic: I prefer git nowadays for my own projects too [15:36] I didn't even *know* I can use git on launchpad [15:37] although I do use git-imports, so... yeah, would make sense that these stay git archives and are not implicitly converted to bzr archive... [15:37] Ionic: we added git support to LP last year [15:37] Ionic: git-to-git imports are on the list, hopefully this year [15:38] great to know, thanks! [15:38] git recipes will be available to beta testers next week [15:38] so we're gradually ticking things off [15:39] I welcome the change :) [15:41] Ionic: https://help.launchpad.net/Code/Git FYI [17:15] ginggs_, still ftbfs on s390x ... https://launchpadlibrarian.net/235090139/buildlog_ubuntu-xenial-s390x.aster_11.5.0+dfsg2-3ubuntu2.1_BUILDING.txt.gz unconditionally linking against -lscalapack [17:21] doko, yeah it's never built on s390x in debian either, i don't know what that's about :( [19:14] cyphermox: to fix #1273201, you removed bridge_ignore_without_connections.patch from n-m. is it now expected that e.g. lxcbr0 shows up in NetworkManager now? [19:14] bug #1273201 [19:14] bug 1273201 in network-manager (Ubuntu) "bridge_ignore_without_connections.patch breaks NM created bridge at boot" [High,Fix released] https://launchpad.net/bugs/1273201 [21:32] ximion, Do you have any plans to split the gnome-software package into subpackages for plugins? Asking mostly because it seems a waste of time to put limba into main [21:33] robert_ancell: I currently want to explicitly avoid doing that, since it will result in some people having fwupd support, some have Limba support and some have xdg-app support or any combination of these... [21:34] those different featuresets would result in making it pretty hard to rely on stuff [21:34] ximion, yeah, it wasn't clear to me how you'd divide them up either. [21:36] robert_ancell: I thought about this a bit, since I saw that issue coming, and decided that I would like to avoid splitting out plugins - GS not knowing about modules can be a prblem on it's own [21:37] (GS makes the components, Limba, fwupd and soon xdg-app visible, if it starts without them users will wonder why GS is not showing the app they just installed, until they notice that gnome-software-plugin-xdg-app is missing) [21:37] also, which plugins should be split out is another complicated question [21:38] robert_ancell: btw, you might want to put appstream in main too ;-) [21:38] ximion, yep, will do that [21:39] for that thing I also though about creating some smaller binary to provide the minimal functionality needed, but decided against that since that would have resulted in lots of C code duplication, slow Python code or other dumb reimplementations of existing stuff, and I really wanted this bit to be fast (every apt update runs it) [21:39] robert_ancell: will you be at FOSDEM as well? [21:40] ximion, not at FOSDEM [21:40] hmm, would've been cool to meet you there [21:41] yeah, I don't do FOSDEM because too far for a short trip [21:42] btw, having Limba in main would of course be awesome, and in case you consider it I would be happy to help (you don't need to install it by default, of course ^^) - otherwise it would be cool to have the plugin in unstable, at least [21:42] we will have an Ubuntu-centric AppStream meeting after FOSDEM [21:42] Nice! [21:42] so I thought you might join that :P [21:43] I'll do the MIR for limba, just wondering if we'll get any pushback from security etc. [21:43] btw, thanks for the ratings&reviews work! I already love it for finally putting the star-ratings to good use, I never liked the way hughsie comouted them [21:44] also, it would be nice to maybe make the protocol for ratings & reviws part of the AppStream specification, if people can set up the server by themselves and if it is not too Ubuntu-specific [21:45] ximion, I don't know much about the details of appstream but we should certianly make it work for other distros. [21:45] The server code is open and should in theory be runnable by other distros (and it can also have reviews from different sources in the same server). [21:46] robert_ancell: Limba has a suid binary, but that one got a code review last year in January (it changed a lot though in the past year, but the stuff it does before dropping privileges is still rigurously checked) [21:46] how is g-s getting the u1 token now? [21:46] when I have some more time, I would like to make it available in AppStream - putting it in there would essentially mean that any distribution is encouraged to implement it [21:47] robert_ancell: speaking of Limba and xdg-app, any plans for a Snappy backend in GS? [21:47] Richard, Alexander and I put quite some work into GS and the AppStream spec to make these bundling tools integrate well ;-) [21:48] dobey, attente updated it to use the sso service [21:49] ximion, I'm playing around with Snappy [21:49] robert_ancell: a token from sso is required to submit reviews. i'm just curious about the client side and how it works [21:50] dobey, you can see it on the wip/rancell/reviews-3-18 branch on GNOME Software [21:50] dobey, reviews welcome :) [21:51] robert_ancell: i take it that is something in a git somewhere? [21:51] dobey, GNOME Git [21:51] becuase... https://launchpad.net/~rancell is not you [21:52] yeah, I'm robert-ancell on Launchpad [21:52] robert_ancell: nice! I still need to work with it - conceptually it seems to be similar to Limba, but without resource-sharing but with the ability to build whole OSes from Snappy packages [21:54] robert_ancell: why the complicated dbus bits? [21:54] dobey, which bits? [21:54] robert_ancell: for sso [21:54] btw, you likely want this bug fixed for Xenial: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808993 - since it requires a few bigger changes in asglib, I poke hughsie from time to time to fix it or allow me to change it :P [21:54] Debian bug 808993 in appstream-glib "gnome-software: Screenshots not loading" [Normal,Open] [21:55] robert_ancell: or is it still just using ubuntu-sso-client for the actual login stuff? [21:55] dobey, just for getting the token [21:56] robert_ancell: ah. is that a temporary thing? i understood the plan was to also replace ubuntu-sso-client [21:56] dobey, not sure, attente got that bit working [21:56] ok [21:56] well i hope it's temporary :) [21:58] dobey, so what is the correct way to get a token now? [22:01] robert_ancell: my understanding from UOS was that someone was going to write something to replace u-sso-client, using the newer REST API, for the gnome-software integration; ubuntu-sso-client isn't "incorrect" as it were, but it is using the older API, which I think the ols team would like to drop at some point (but not sure how feasible that is at this point anyway), and it is python 2.x code. [23:04] robert_ancell: if you need any information/help on AppStream, Limba and/or xdg-app or plugin stuff, let me know :) [23:04] ximion, will do, thanks! [23:04] (for gnome-software itself, hughsie is the ultimate authority)