=== bcurtiswx_ is now known as bcurtiswx [02:27] TheMuso, hey, there is a new version of the lcms library (lcms2) which is parallel installable with the old version (<2). As far as I can tell there will be no more development on <2 (i.e. it is not a stable branch, but allows you to run your old software and gradually port it). Question is: Do I make a new source package for lcms2 or just add a new changelog entry in the existing lcms one? [02:31] I guess the answer would be the same as the answer to the question “are you ever going to need to patch lcms1”? Is it just an soname bump, or a parallel development tree, etc? [02:32] RAOF: Agreed. Also I wonder what Debian is doing. [02:32] Yes, squeeze has frozen etc. [02:34] I sent the proposed package to Debian, but I guess they wont be using it if they are frozen [02:34] RAOF, I think the answer is "no, and all packages should migrate to lcms2" [02:35] Is there an API break? [02:35] Is the lcms → lcms2 transition just a rebuild? [02:35] RAOF, not sure, but it doesn't matter as you will have to explicitly relink against the new one anyway [02:36] The library has changed from lcms.so to lcms2.so [02:39] Ah. So I'd guess there's an API change, and it's not a simple rebuild with a different -l flag. That sounds more like you want a different source package; liblcms sounds like it'll be hanging around long enough that you could reasonably expect to want an upload. [02:39] Are they plugins, or a shared lib? If a lib, then the soname is wrong. [02:41] TheMuso, a lib, what is wrong with the soname? [02:41] It should probably be liblcms.so.2 [02:42] afaik sonames should be something like libname.so.nub [02:42] s/nub/num [02:42] RAOF: yeah [02:42] No, the renamed the source package to lcms2 [02:49] It sounds more like it wants to be a new source package, starting with “initial upload to $DISTRO”. [02:55] yep === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:51] Good morning [06:54] Hey pitti. [06:56] hey TheMuso, had a nice weekend? [06:56] pitti: Certainly did thanks. Yourself? [06:56] quiet, but nice; thanks [06:56] Quiet is good. === robert_ancell_ is now known as robert_ancell [07:34] good morning [07:35] bonjour didrocks [07:36] Guten Morgen pitti, how was your week-end? [07:37] didrocks: quiet on Saturday (was raining cats and dogs), so I did some household cleanup; we went hiking yesterday, so very nice; how was your's? [07:39] pitti: very sunny and nice in the Alps. Went to a traditional restaurant and some walking in the mountains. Just feel a little bit cold sometimes compared to Paris (< 20°C) [08:15] robert_ancell: hey, I see you are doing a lot of remerge on debian, can you have a look this week-end at gnome-shell? It's currently broken because of new mutter [08:16] didrocks, can do [08:16] robert_ancell: bug #614359 should give you all the info :) [08:16] Launchpad bug 614359 in gnome-shell (Ubuntu) "undefined symbol: mutter_plugin_effect_completed (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/614359 [08:16] robert_ancell: thanks! [08:16] robert_ancell: basically, mutter broke the API without bumping the soname, it affected us at unity, and gnome-shell had the same issue [08:17] didrocks, ok, will look at it tomorrow [08:17] robert_ancell: great! thanks a bunch! [08:44] mvo: hi [08:44] hey kiwinote [08:44] mvo: are you still working on the deb-files branch, or are you done making changes? [08:45] kiwinote: I'm not fully done, I can resume now. did you had a chnce to look over the other bits I put in? I think the deb file stuff is done, but the apturl links need a little bit of attention still [08:47] mvo: yep, I took a look at what you had changed. There are a few little sidecases which need fixing, but it looks good elsewise. [08:48] mvo: if you aren't working on it atm, then i'll fix a few little things first, otherwise I'll wait until you're done and fix them later [08:48] kiwinote: thanks for the review, I can merge them back if you put them into your branch [08:48] kiwinote: then please fix them now, we are not in a rush :) [08:48] eh, I'm not :) [08:48] mvo: sure, I'll let you know when they're done ;) [08:49] * mvo nods [08:50] hey [08:50] salut seb128, ça va ? :) [08:50] lut didrocks [08:50] hey seb128, hello mvo [08:50] ouais et toi? [08:50] hey pitti, mvo [08:51] wie gets? [08:51] seb128: ça va bien, merci :) [08:51] hey pitti, seb128 [08:54] slomo: Hi! Did you get a chance to take a look at the proposed cairo packaging changes (debian #587771)? [08:54] Debian bug 587771 in cairo "Package cairo-perf utilities" [Wishlist,Open] http://bugs.debian.org/587771 === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [09:14] mvo: for error checking/setting of deb files your branch gets the failure_string from python-apt. Do we want that, or do we want to be able to set custom error messages which are more consistent with the rest of s-c like my branch did? (I don't mind which one you want, I just wanted to verify your decision) [09:16] bah, hundredpapercut start being annoying, broken changes get uploaded and people have no consideration for translations [09:19] morning [09:19] lut huats [09:19] How are you seb128 ? [09:20] I'm fine I think, what about you? ;-) [09:20] good too ! [09:21] last week before 1 week of holidays :D [09:21] kiwinote: I think it would be great to re-use the ones from python-apt to have one a single string that needs to get translated etc. if they are too technical then that is a valid point and we should reconsider. in this case it would be nice to make python-apt return error enums so that we don't have a dupe the check() function from p-apt inside s-c [09:21] kiwinote: I hope we can make the ones in python-apt good enough for showing in s-c without loosing too much technical information [09:23] mvo: yes, it is indeed a good point not to duplicate stuff from python-apt. I'll check with mpt how technical or non-technical he wants the error messages to be in s-c. [09:24] thanks kiwinote [09:24] kiwinote: I guess its ok if deb installing is a tad more technical, but I will leave it to mpt to comment [09:24] mvo: ok, thanks === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [09:28] hi kiwinote [09:28] mpt: there is a bit above here about the failure strings for installing deb-files in s-c [09:29] mpt: the question is whether the failure strings from python-apt can be used or if they are too technical [09:30] mpt: the python-apt messages can be found at http://bazaar.launchpad.net/~mvo/python-apt/debian-sid-mirrored/annotate/head:/apt/debfile.py by searching for '_failure_string' [09:31] kiwinote, well, "Conflicts with a exisiting pkg!" isn't quite up to scratch :-) [09:32] kiwinote, when and where would these be shown? [09:33] mpt: they are shown in the summary line of the appdetailsview when someone opens a deb file with s-c when the deb-file can not be installed [09:37] mpt: individual strings can be rephrased in python-apt. The main thing is how much detail we want to show in s-c. Eg if the deb-file conflicts with pkgs already installed then python-apt will (and should) display the list of pkgs which it conflicts with. Do we want that much detail in s-c, or does less detail suffice? [09:37] kiwinote, in the summary line? Why wouldn't you be showing the summary of the package there? [09:39] mpt: if there is a better place for errors, then please let me know. I had put it there originally because the software can't be installed if there are errors which makes the summary/description/screenshot irrelevant, so atm we only display icon title and summary if there is an error and the rest is hidden [09:41] hmmmmmmmmmmm [09:44] kiwinote, I suggest putting the error message where the description would be instead. [09:44] And each of those will need tidying up. [09:44] mpt: and hiding the pkgstatusbar? [09:44] "This package cannot be installed because _______." [09:45] kiwinote, I don't know what "pkgstatusbar" maps to in the spec. The installed state bar? [09:46] mpt: yep, the coloured bar with the install/remove button in it [09:47] mpt: we can easily have a red coloured bar there, it just looks a bit odd if there is no text or button to go in it [09:50] Probably leave it there but make "Install" insensitive [09:50] bbiab [09:50] vish, starting changing descriptions over debian seems over the hundredpapercut line, can we stop that? [09:51] we can't start creating delta for such changes [09:51] mpt: ok, I'll do that then and see what it looks like [09:51] vish, changing desktop descriptions in universe is also not going to work, can you revert that change? [09:51] mpt: thanks [09:52] vish, that breaks every non english locale without a way to translate it [09:54] seb128, I wasn't aware of that. Is that happening in app-install-data, or on the ddtp descriptions? [09:54] seb128: which one? [09:55] dpm, what is happening? [09:56] vish, the something-sdl [09:56] ah.. [09:56] vish, you changed a desktop Comment [09:56] the package being in universe there is no langpack [09:56] you just break all translations by doing that [09:56] seb128: the change in the control file is ok? only need to revert the .desktop change? [09:56] we can argue over that [09:57] I think starting to change descriptions in the source this way is wrong [09:57] you are creating delta over debian and a need to merge every change where we were in sync [09:57] we don't have the manpower to start merging packages just for descriptions changes [09:57] hmm.. [09:58] if we think descriptions are not worded as they should we need an overlay layer [09:58] ie something we can change in launchpad of software-center [09:58] mpt: just a quick question: For non existent pkgs you had designed a 'Not Found' screen. Do you want that to stay the same, or do you want to display a coloured bar and then have the error message in the description field there as well? [09:58] we can't start creating diff to improve translations [09:58] ups [09:58] translations -> descriptions [09:59] it's going to cost hundred of work hours every cycle which we don't have [09:59] it's going to lead to outdated packages, conflict with debian, bugs, conflicts with upstream, etc [09:59] seb128: the changes have been sent to debian ,and changed in debian too [09:59] seb128: some are still waiting in debian for a response [09:59] no they have no been changed in debian [09:59] we have an 0ubuntu1 version now [09:59] which means we will never get debian updates in automatic way again [10:00] it will require somebody to spend time tracking it and merging it every single time debian do a change now [10:00] kiwinote, I think the "Not Found" screen shouldn't have an installed state bar, because it's not a package. [10:01] mpt: ok, then i'll change some of the internal code to deal with two different sorts of errors ;) [10:02] seb128: ex: debian bug 590238 , this was fixed , some havent even responded like the pidgin one.. what should we do? [10:02] Debian bug 590238 in xchat-gnome "xchat-gnome: Package description could have information about program use" [Minor,Open] http://bugs.debian.org/590238 [10:02] err , fix committed in debian too [10:03] vish, wait for them to upload and sync? [10:03] vish, well for things where we ubuntu changes already it's not so an issue [10:03] seb128: pidgin has been waiting for 2yrs! :s [10:04] vish, well as said if we think the descriptions quality is not matching our standard we need to figure a way to sort it which doesn't imply patching every debian source [10:05] right .. [10:06] mvo: any ideas^ ? [10:07] mvo, mpt: weren't some discussion during the years about fetching descriptions from launchpad or something? [10:07] ie having a way to rewrite the packages descriptions without having to do source changes [10:07] seb128, vish: so ideally we would get "overwrite" support for this from LP [10:07] but its not there yet [10:07] (and maybe some time to come :/) [10:08] I though that was the plan [10:08] but yeah, launchpad changes can take time [10:08] I think for high profile apps like xchat it does make sense to go and patch them even if it means that we have the burden of merging [10:08] right [10:08] I guess a alternative idea would be to (ab)use the Translations-en file [10:08] but seems we start having uploads for random universe games and small packages [10:09] it can be done today but the LP support for finding packages in the huge template is not great [10:09] there is a open spec for imporving that so that the description.pot lives alongside the normal template in LP so that its triviial and find and tranlsate [10:10] that spec is open since ~1y or so (maybe more) [10:12] hum [10:13] brb gdm testing [10:25] re [10:27] vish: for now, for non high-profile packages I suggest you send the fixes to Debian and not seek to diverge in Ubuntu for that [10:27] it's the right place to make these changes anyway [10:28] Laney: as i mentioned earlier, fixes are being send to debian [10:28] sent* [10:29] Laney: is debian in freeze now? [10:31] yes [10:32] I know they are being sent there, but it's not worth an upload in ubuntu for it [10:32] we should get it back through syncs [10:33] Laney: yup, sounds sensible.. when maintainers dont respond how should we proceed? [10:35] if they make uploads without responding to your patches then you should raise it again [10:35] if there aren't any uploads then … there's not much you can do [10:37] yeah , thats where it gets confusing , whether the maintainer is MIA or just doesnt want to change it.. [10:40] seb128: what about mvo's idea? [ using translations-en ] how do we do that ? is that acceptable? [10:42] vish, I'm not sure how we do that but as said before as long as you don't create delta over debian which creates extra work for everybody I'm fine with it [10:43] pitti, do you have any opinion on bug #605685? [10:43] Launchpad bug 605685 in ubuntu "Sync isc-dhcp 4.1.1-P1-9 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/605685 [10:44] seb128: I didn't test it, so I don't [10:44] seb128: but Mathieu mentioned that he wants the transitional packages removed [10:44] pitti, no, he said that's an option [10:44] also, we have some Ubuntu modifictions to dhcp3 which would need to be ported [10:44] so it would be a merge either way [10:44] cool! [10:45] pitti, I'm rather unsure if we should go for the new dhcp this cycle [10:46] seb128: didn't we talk about this the other day? I thought it was required for something in NM [10:47] pitti, right, just reading through the dhcp3 changelog the number of changes we have there is non trivial to port to the new version [10:48] ok, let's try to get the new one without the transitional binaries in and port changes and see where we can get [10:54] seb128: but what's the purpose of that then? [10:54] "that"? [10:54] we certainly don't want a second version in main which we didn't test and apply our changes to? [10:56] pitti, I'm trying to see how we move that forward but seems nobody is actively working on that part of the stack [10:56] hey rickspencer3 [10:56] hi seb128 [10:57] hey rickspencer3, had nice holidays? [10:57] pitti, indeed [10:57] felt like much longer than 1 week [10:57] (which I think is a good sign) [10:57] rickspencer3, on east cost time or up really early? [10:57] rickspencer3, ;-) [10:57] seb128, east coast! [10:58] for today and tomorrow [10:58] rickspencer3, so you managed to not work during the week? ;-) [10:58] ok [10:58] hey rickspencer3 :-) [10:58] hi didrocks === zyga_ is now known as zygq === zygq is now known as zyga [11:27] didrocks, you can drop your connman workitem for beta it will not be default [11:27] seb128: sure, doing it now [11:28] thanks [11:29] hmm? connman won't be default? [11:29] in that case, will network-manager get indicator support? [11:30] yw [11:34] no and no [11:37] chrisccoulson: do you happen to know if chromium supports system-wide preferences? like /etc/chromium/config/ or similar? [11:38] hi all :) [11:39] pitti - i don't think so, but i'm not entirely sure [11:39] I am grepping the source, but I can't find it [11:39] pitti: chrisccoulson: they were some initial support added last month. I didn't check again though [11:42] it seems rather weird to patch and rebuild chromium just to change the behavior for a particular mime type [11:42] apparently in ./chrome/common/chrome_paths_* [12:03] d'ooooh [12:04] seb128, it turns out I'm on holiday until Thursday! [12:04] what a dope I am [12:04] * TheMuso waves to rickspencer3. [12:04] And everyone else. [12:04] hi TheMuso [12:07] hey TheMuso [12:07] rickspencer3: go back to enjoy your holidays so! ;) [12:08] didrocks, well, I have a few things to do .. but yeah [12:08] I'll limit my time at work, for sure [12:09] rickspencer3: holidays = you're not at work. Not that you're at work only for 8 hours unlike the usual 24 x 7 :p [12:10] hehe [12:10] I don't work that much [12:11] I may be exaggerating but you get the point :D [12:14] (I think we should face the reality: rickspencer3 misses us ;)) [12:14] didrocks, yeah [12:15] plus there are new people! [12:15] I wanted to meet them today [12:15] :) === cking__ is now known as _cking [12:19] mvo: I've pushed mpt's changes of the error position to my branch along with a few small fixes to deb-file handling in general. [12:20] kiwinote: nice, thanks. I will remerge [12:20] mvo: I'll take a look at rephrasing some of the python-apt error messages now [12:21] rickspencer3, lol [12:21] rickspencer3, go back to enjoy your holidays then ;-) [12:21] seb128, I am such a dolt === DrPepperKid is now known as MacSlow|lunch [13:00] re [13:13] mvo, hi, software-center won't start for me: http://paste.ubuntu.com/475425/ [13:14] mpt: any comments on http://paste.ubuntu.com/475424/ ? [13:15] kiwinote, not perfect, but a great improvement [13:16] kiwinote, for Breaks/Conflicts, why aren't we offering to simultaneously remove the thing that it breaks or conflicts with? [13:16] mpt: thanks, I have a look [13:18] mvo: ^ is that something that python-apt can do, or would that involve using error codes and putting that functionality in s-c itself? [13:23] kiwinote: it does involve code as it requires a user decision [13:24] mvo: yeah, I was wondering more if it was within the scope of python-apt, or not really [13:24] kiwinote, don't worry about it then, it's something that (maybe) should be implemented later for Breaks/Conflicts in general, not for .debs in particular [13:24] mpt: s-c should be fixed, but the commit is still in place [13:24] mpt: now its there r996 [13:24] mpt: that should have read "still in progress" [13:25] kiwinote: hm, not really [13:26] mpt: are the string changes worth pushing, or would you have some time this week to make them perfect? [13:26] kiwinote: I mean, it does not fit that well into python-apt itself, we should make it trivial to support this strategy, but outside of p-apt itself [13:26] mvo, yep, it works, thank you [13:26] mpt: I agree with that, especailly for debs its potentially dangerous to support removing already existing stuff from the archive to essily [13:26] mpt: cheers [13:28] mvo, staging.launchpad.net is up, but I get nothing to purchase. Could this be the problem, or is it unrelated? 'File "./data/update-software-center-agent", line 36, in from softwarecenter.enums import * ImportError: No module named softwarecenter.enums' [13:29] mpt: did you do "export PYTHONPATH=." before starting s-c ? [13:29] mpt: there is a issue with the sc.staging.ubuntu.com currently (in addition to this error) [13:29] mvo, I did not [13:30] mpt: please try that [13:30] mpt: I should update the README or add a README.bzr or something like that [13:31] mvo, doing that removes that error [13:34] mpt: great, thanks [13:38] y/c [13:39] kiwinote: merged your changes, they look good. unfortunately merging into trunk gives me a bunch of conflicts. could you have a look please ? [13:40] mvo: merging mvo/deb-files into trunk? [13:42] kiwinote: yep [13:42] kiwinote: I mean, if you merge trunk into your deb-files branch, you should see the conflicts [13:43] mvo: sure, I'll fix them. (all the buy-something stuff landed in trunk after my last merge) [13:43] kiwinote: yeah, a lot of churn (again :/) [13:43] kiwinote: but that is the last big branch that is in the queue [13:43] kiwinote: I mean, that was the last big one [13:43] kiwinote: other than the deb-files one :) [13:43] mvo: there were no more apturl changes you wanted to make? [13:44] kiwinote: let me check again, but it should not interfere with fixing the conflicts [13:45] mvo: indeed, I'll let you know when I'm done ;) [13:45] kiwinote: many thanks! [14:02] seb128, re: isc-dhcp; I agree, I think it would be best to get isc-dhcp without the transitional binaries in asap, then work on the actual switch in maverick+1 [14:03] hey cyphermox [14:03] hi ;) [14:03] cyphermox, we can still try to switch this cycle I guess but seems porting the changes will be quite some work [14:04] yes, and isc-dhcp will require a MIR, and there might be other packages that require fixes, etc... lots of work IMO [14:08] seb128, looking at the changes in dhcp3, yes, it will require quite some work :) [14:09] cyphermox, ok, so let's get isc-dhcp in an work on getting it in shape this cycle [14:10] seb128, ok, I'll re-work my bzr branch to remove the transitional binaries from the latest version in unstable. Is a sync still the right process for this? [14:13] cyphermox, no, a sync is if there is no change, if you have changes it's a normal upload we need [14:13] seb128, I guess what I mean is, should I open a new bug? [14:13] desrt, no [14:13] ups [14:13] desrt, hey [14:13] cyphermox, no [14:14] seb128: hello [14:14] cyphermox, let's use the same one, I've unsubscribed ubuntu-archive now [14:14] what did i screw up now? :) [14:14] desrt, dconf 0.5 doesn't build with gir if libdconf0 is not installed [14:15] are you using --as-needed? [14:15] no [14:15] vuntz reported some issue related to that [14:15] hmm. [14:15] I just think it's not trying to use the source version [14:15] are you using 0.9.3 gobject-introspection? [14:15] or did you reduce the dependency? [14:16] we reduced the dependency [14:16] don't :) [14:16] and dropped the --no-libtool [14:16] that's what broke it [14:16] ok [14:16] desrt: you broke things again! [14:16] * vuntz hugs desrt [14:16] 0.9.3 + --no-libtool is required to add the rpath properly [14:16] I will just drop the gir for now [14:16] otherwise it won't work [14:16] vuntz: :) [14:16] gir is a mess anyway [14:17] and there are ongoing discussion now to not support python2 and gtk2 [14:17] but only python3 and gtk3 [14:17] good times [14:21] seb128: to be honest, you don't miss much by not having .gir for dconf [14:21] right [14:21] did the new vala get released while i was sleeping? :p [14:22] desrt, btw, https://bugs.edge.launchpad.net/ubuntu/+source/d-conf [14:22] desrt, yes [14:22] if so, you may want to save your time [14:22] i'm going to do 0.5.1 then [14:22] I've uploaded the version without gir for now [14:22] we didn't update vala yet [14:22] and dconf was broken due to the glib update [14:22] those old double frees are old, i think :) [14:23] the other one is with 0.5 [14:23] ya [14:23] nice trace :p [14:23] it has not been retraced yet [14:24] if i wait for a while will it improve? [14:24] yes [14:24] nice [14:24] tedg: good morning [14:24] Good morning desrt [14:24] urg [14:25] pitti, have you seen "Corrupt duplicate db:[(u'*** in database main ***\nOn page 1129 at right child: invalid page number 1171',)]" errors before? [14:25] pitti, it's from the amd64 retracer [14:25] hey tedg [14:25] I've not been able to upgrade to Maverick all weekend... something about X dependencies. Is that known? (trying again now) [14:26] Morning seb128 [14:26] tedg, not know there no [14:27] seb128: I did; I tried to fix it, but apparently it didn't work [14:27] (by dumping and recreating the DB) [14:27] Hmm, yeah. Still failing. It's a fight between xserver-xorg-video-nouvea and xorg-video-abi-7.0 [14:28] pitti, :-( [14:33] seb128: how do i know when 'retrace' is done? [14:35] desrt, the tag apport-retracing-needed will be dropped [14:35] i guess subscribers get an email? [14:35] yes [14:35] cool [14:35] you will get the stacktrace added by the retracer by email [14:36] "need-amd64-retrace" is the tag [14:36] to be exact ;-) [14:37] desrt, http://launchpadlibrarian.net/53329301/buildlog_ubuntu-maverick-i386.d-conf_0.5-1ubuntu2_FAILEDTOBUILD.txt.gz [14:38] desrt, is that a bug of yours? ;-) [14:38] looks like you tried to autogen dconf without introspection installed [14:38] why do I need it? [14:38] you need it for autogen [14:38] ./configure is fine without it [14:38] bah [14:39] aclocal needs to be able to find the m4 [14:39] stupid thing [14:39] you should ship the macros you need ;-) [14:39] maybe... [14:39] why did you autogen it? [14:39] because we run autoreconf at build time now [14:40] odd. [14:40] why odd? [14:40] that makes easier applying changes to makefile.am or configure.ac when we need to [14:40] right [14:40] i was asking because i thought maybe you did a little bit of that or something [14:40] anyway [14:40] but it underlines the argument against it: "you don't upload what you have tested" [14:40] i'll look into disting the introspection m4 for 0.5.1 [14:40] desrt, thanks [14:41] or listen to pitti :) [14:41] well, autoreconf should still work somehow :) [14:42] it would work if you build-depends on (any) version of introspection [14:42] right [14:48] pitti, do you plan to merge dbus on debian btw? if you don't I might have a try to it [14:52] seb128: Keybuk claimed it, so I didn't touch it [14:52] pitti, did he? [14:53] pitti, when I asked him at the sprint he said he had no plan to work on updating dbus [14:53] https://merges.ubuntu.com/main.html said "Scott claims" [14:53] hum, k [14:53] of course now I can't prove it because it seems to be down :/ [14:53] so, go ahead :) [14:53] anyway he will not do it apparently [14:54] ok, I will give it a go [14:54] let's see if I manage to break dbus ;-) [14:54] * pitti hugs seb128 [14:54] you don't have any special way to maintain it or merge on Debian? [14:54] * seb128 hugs pitti [14:54] no, I don't; no revision control or anything [14:54] ok [15:08] bl8: do you have package ready for maverick with your implementation of mpris2 [15:17] bl8: scratch that - doing the dist-upgrade now === asac_ is now known as asac [15:44]