[16:14] <Laney> xnox: Seems complicated for the task of saving top-level things - couldn't you check for '/' in the path?
[16:14] <Laney> (moving here from release :P)
[16:15] <xnox> Laney, this would only fix symlinks in the top-level dir though.... there might be symlinks to dirs in packages too, which should be copied.....
[16:15] <Laney> why would they be blacklisted?
[16:16] <xnox> or we can declare we don't care, than a '/' in relpath would do.
[16:16] <xnox> Laney, because blacklisted package ships it as a dir; whilst top-level one decided to move e.g. plugins dir elsewhere, hence declares a symlink dir.
[16:18] <Laney> doesn't your proposal do this 'bad' thing anyway?
[16:19] <xnox> Laney, also i noticed that libgtk2.0-0 ships a broken symlink.
[16:19] <xnox> $ ls /usr/share/doc/libgtk2.0-0/changelog.gz
[16:19] <xnox> lrwxrwxrwx 1 root root 32 Sep 21 11:54 /usr/share/doc/libgtk2.0-0/changelog.gz -> ../libgtk2.0-common/changelog.gz
[16:19] <xnox> Laney, with my proposal, the top-level package which is kept, will have its symlink installed into target. as is correct what dpkg did.
[16:20] <xnox> Laney, to be fair this is all very hackish. ideally we'd be using stacked squashfs ;-) or like actually execute dpkg to remove packages.
[16:20] <Laney> I see this "return '/' in relpath at the end"
[16:20] <Laney> so I don't get why it would work
[16:20] <xnox> Laney, but by that point all conditions above are true
[16:21] <xnox> as in, it is a blacklisted filename, it is a symlink, it is a symlink to a dir, it is not a broken symlink, and it's not a top level one.
[16:21] <xnox> and is kind of what infinity asked for
[16:21] <xnox> funny he is not in this channel.
[16:21] <Laney> yes and True means blacklisted no?
[16:21] <xnox> yes
[16:21] <xnox> horum.
[16:22] <xnox> as in do not copy.
[16:22] <xnox> argh
[16:23] <xnox> i do wonder if all of the conditions in between simply reduce to to '/i' in relpath
[16:23] <xnox> i do wonder if all of the conditions in between simply reduce to to '/' in relpath
[16:24] <xnox> also not sure if we should be copying broken symlinks from /rofs to /target
[16:25] <xnox> e.g. /usr/share/doc/libgtk2.0-0/changelog.gz
[16:25] <Laney> if the deb has it, I'd say you should keep it
[16:25] <xnox> right, it's just dirs and symlinks are funny. cause they exist in both list to keep and list to blacklist.
[16:26] <xnox> i wonder this
[16:26] <xnox> maybe directories should not be in the blacklist to begin with.
[16:26] <xnox> i.e. /usr /usr/bin should not be in the blacklist.....
[16:27] <Laney> they're all not considered anyway
[16:27] <xnox> what do you mean?
[16:27] <xnox> in this part of the code we decide what to copy from /rofs to /target
[16:27] <Laney> ubiquity stats the things and if it's a directory skips blacklisting
[16:27] <xnox> and /rofs has everything preinstalled.
[16:29] <xnox> meaning we potentially install many empty redundant dirs in /target, if they are fully blacklisted.
[16:30] <Laney> ref count them :-)
[16:30] <Laney> really though, more than a minimal amount of fixing in ubiquity is probably not a great idea at this point
[16:31] <Laney> given Installer NG™
[16:31] <xnox> Installer NG.io
[16:31] <xnox> hahahahhahaha
[16:33] <xnox> Laney, so i guess i should test this instead http://paste.ubuntu.com/p/kFPTzBMjNC/
[16:34] <xnox> cause this means our top-level tree stays.
[16:34] <xnox> and it will break when we decide to do usr/sbin -> usr/bin
[16:34] <xnox> kicking the can down the road.
[16:34] <xnox> right
[16:34] <xnox> so my long code works for nested symlinks to dirs.
[16:35] <xnox> because it does a stat on the symlink target, and if that is a dir, it skips blacklisting.
[16:35] <xnox> thus probably i never actually get to the '/' in relpath fallthrough.
[16:35] <xnox> maybe
[16:38] <Laney> how does usrmerge actually work?
[16:38] <Laney> something ships the symlink and dpkg follows that when unpacking packages?
[16:46] <xnox> Laney, debootstrap pre-creates /bin -> usr/bin symlink; dpkg never replaces a symlink with a dir; thus when it unpacks base-files or debs that ship /bin (dir) /bin/true (file) the `true` binary ends up in /usr/bin/true on disk


[08:23] <dholbach> good morning
[08:27] <MooDoo> morning
[08:57] <davidcalle> Morning o/
[09:04] <MooDoo> :)
[09:36] <popey> stupid networking
[09:36] <popey> morning all
[09:42]  * dholbach relocates to the office, brb
[11:53] <_Sponge> Morning dholbach .
[11:54] <dholbach> hey _Sponge
[11:54]  * _Sponge is freeling Woolly today :)
[11:55] <_Sponge> too much Austrian beer IMHO.
[11:55] <MooDoo> or you're getting friendly with sheep ;)
[11:56]  * _Sponge isn't from Wal;es, thank-you
[13:14]  * _Sponge is looking at tomorrows Order paper .. http://tinyurl.com/ClaareObbyrTynwald
[13:15] <_Sponge> Looks like we're getting a Credit Union, by this time next Tourist Trophy season (July)
[13:15] <_Sponge> (2017)
[14:48] <jose> dpm: ping
[15:00] <dpm> jose, pong, hablamos en ~2 en hangout?
[15:00] <jose> dpm: listo!
[15:00] <dpm> dholbach, will be a min
[15:01] <dholbach> sure
[15:06] <_Sponge> jose, There's something a_miss with http://ubuntuonair.com/
[15:06] <jose> _Sponge: which is...?
[15:07] <popey> the video was removed
[15:07] <popey> probably they re-started it
[15:07] <_Sponge> the video has been removed by the userr.
[15:07] <popey> so the link is wrong
[15:07] <jose> jcastro, I'm looking at you...
[15:09] <jose> I'll try to fix it, unless popey you're in now
[15:13] <popey> I am not
[15:13] <popey> I'll leave well alone  😃
[15:13] <popey> I break wordpress whenever I go near it ㋛
[15:18] <jose> _Sponge: should be fixed now, thanks for the pointer
[15:19] <_Sponge> Ok np. Just like to see things moving_along smoothly.
[15:20] <_Sponge> jose, not sure what "&nbsp" at the top of the screen, but I 'll leave it upto you.
[15:21] <jose> it's supposed to be a line break somewhere
[15:47] <dpm> jose, en 45 minutos te va bien hacer un hangout? Cuando dije ~2 no me fijé que no añadí "horas" :)
[15:47] <jose> dpm: yep! no hay problema.
[15:47] <dpm> ok, perfecto
[15:48] <dpm> popey, on the discussion of dekko... did ota 9.5 get released in the end?
[15:48] <popey> not yet
[15:48] <dpm> is there a date?
[15:51] <popey> A stable date? Not that I've seen.
[15:54] <dpm> ok, thanks
[16:28] <_Sponge> popey, I wonder if the Conergence phone wud fair well here https://t.co/9oWuqEXjAC
[16:29] <_Sponge> sorry for the bad link .. http://ift.tt/1RFbg0V
[16:33] <popey> _Sponge: will pass on to design, thanks
[16:33] <_Sponge> np.
[17:00] <dholbach> have a great rest of your day everyone - see you tomorrow!


[00:50] <StevenK> wgrant: Hmmm, how do I return a 400.
[00:58] <wgrant> StevenK: Maybe raise a BadRequest, but I'm not sure if you can at that point.
[00:59] <StevenK> I just tried with HTTPBadRequest and that OOPSes
[01:06] <StevenK> wgrant: BadRequest also OOPSes
[01:07] <StevenK> I might be using the wrong one, since I'm pulling it from lazr.restfulclinet
[01:07] <StevenK> *restfulclient
[01:08] <wgrant> StevenK: HTTPBadRequest is probably the right one
[01:08] <wgrant> But the request may not be sufficiently set up by then
[01:08] <wgrant> What does the traceback look like?
[01:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1595337/
[01:10] <wgrant> StevenK: Ah, so the publisher deals with it really early
[01:10] <wgrant> Might best to go the decode('utf-8', 'replace') route
[01:10] <StevenK> Right, like PATH_INFO ?
[01:11] <StevenK> wgrant: My test might be screwing that up
[01:12] <StevenK> But given it's three lines, maybe not
[01:12] <wgrant> Like PATH_INFO, yes
[01:13] <wgrant> If they don't speak UTF-8 then they're not worth understanding :)
[01:19] <StevenK> wgrant: http://pastebin.ubuntu.com/1595363/
[01:19] <wgrant> StevenK: Heh, no
[01:20] <StevenK> wgrant: Would you prefer _decode() turns into return unicode(text, 'utf-8
[01:20] <StevenK> Bleh
[01:20] <wgrant> StevenK: Well, think about what your diff will do
[01:20] <StevenK> return unicode(text, 'utf-8', 'replace') even
[01:20] <wgrant> It'll go through all the user-specified charsets
[01:20] <wgrant> Decoding each with replacements
[01:21] <wgrant> Then decode as UTF-8 with replacements
[01:21] <wgrant> What you might want to do is try to decode as the user-specified charsets
[01:21] <wgrant> Then, if they all fail, decode as UTF-8 replacements
[01:21] <wgrant> *or* just go ahead and decode as UTF-8 with replace to start with
[01:21] <wgrant> I'd prefer the former
[01:23] <StevenK> wgrant: http://pastebin.ubuntu.com/1595366/
[01:23] <wgrant> StevenK: No
[01:24] <StevenK> Oh, missing a break
[01:25] <wgrant> It's also wrong :)
[01:25] <wgrant> That'll decode as utf-8 with replace if any decoding fails
[01:25] <wgrant> You want to do it if *all* decodings fail
[01:25] <wgrant> So perhaps you want to
[01:25] <wgrant> def _decode(self, text):
[01:25] <wgrant>     text = super(LaunchpadBrowserRequest, self)._decode(text)
[01:26] <wgrant>     if isinstance(text, str):
[01:26] <wgrant>         text = test.decode('utf-8', 'replace')
[01:26] <wgrant>     return text
[01:26] <wgrant> s/test/text/
[01:26] <StevenK> Heh
[01:28] <StevenK> wgrant: That sounds good. Even with an explanatory comment.
[01:29] <StevenK> BrowserRequest does not love adapting LBR
[01:29] <StevenK> So I'll call it directly
[01:29] <wgrant> ?
[01:29] <wgrant> Oh, is it not new-style?
[01:30] <StevenK>     envadapter = IUserPreferredCharsets(self)
[01:30] <StevenK> TypeError: ('Could not adapt', <lp.services.webapp.servers.LaunchpadBrowserRequest instance URL=http:/>, <InterfaceClass zope.i18n.interfaces.IUserPreferredCharsets>)
[01:30] <wgrant> Ah
[01:30] <wgrant> That's odd...
[01:30] <StevenK> We don't implment IBrowserRequest
[01:30] <StevenK> That might be it
[01:31] <wgrant> Except that we inherit that method and it works fine
[01:32] <StevenK> When I copied and pasted it, it was failing with the IUserPreferredCharsets line, but I just removed it rather than looking for the import
[01:32] <wgrant> Sure, but _decode is called today and seems to work fine, right?
[01:34] <StevenK> LBR doesn't have a _decode today
[01:34] <StevenK> It will fall to the subclasses
[01:34] <wgrant> Exactly
[01:34] <wgrant> Which have the same self
[01:34] <wgrant> But work fine
[01:34] <StevenK> Ah, hm
[01:34] <StevenK> implementing IBrowserRequest helps not
[01:36] <StevenK> Neither does calling text = BrowserRequest._decode(self, text)
[01:38] <wgrant> StevenK: So you're getting that crash in a browser?
[01:38] <StevenK> That's from my test
[01:38] <StevenK> Let me try the browser
[01:39] <wgrant> Oh
[01:39] <wgrant> You might not even be in the right layer
[01:40] <StevenK> TestBasicLaunchpadRequest has no layer
[01:40] <wgrant> That would be a problem for a test that desires to make use of the Component Architecture.
[01:40] <StevenK> TestLaunchpadBrowserRequest doesn't either
[01:41] <StevenK> wgrant: It works in the browser, so yeah, layers
[01:42] <StevenK> None of the testcases in services/webapp/tests/test_servers use layers at all
[01:43] <wgrant> Right, none of them need to at present
[01:43] <StevenK> LFLayer, or is that too high?
[01:44] <wgrant> FunctionalLayer should be fine
[01:44] <wgrant> Don't even need DatabaseFunctionalLayer
[01:46] <StevenK> wgrant: http://pastebin.ubuntu.com/1595398/
[01:47] <wgrant> StevenK: Might want to extend the comment to state that we always want unicode, dammit.
[01:49] <StevenK> wgrant: http://pastebin.ubuntu.com/1595412/
[01:51] <wgrant> StevenK: Seems reasonable.
[01:51] <wgrant> Checked that it fixes the crash?
[01:51] <StevenK> It renders the page with the replaced string in the widget
[01:51] <StevenK> So 'good enough'
[01:52] <wgrant> Yep
[01:58] <wgrant> StevenK: I'll have ~3600 lines of diff for you soon :)
[01:58] <wgrant> Over 6 branches, though
[01:58] <StevenK> Whimper
[02:05] <wgrant> :)
[02:17] <wgrant> StevenK: So, do you understand what I'm doing?
[02:36] <wgrant> https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-1-populate/+merge/145541 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-2-garbo/+merge/145542 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3-query/+merge/145543 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3.5-more-query/+merge/145819 https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-4-app-eliminate/+merge/145820
[02:37] <wgrant> StevenK: They're ready for you to review at your leisure
[02:55] <StevenK> wgrant: You never explained your dastardly plan
[03:04] <wgrant> StevenK: I've outlined it in the MP descs
[03:04] <wgrant> But can go into more detail if you desire
[03:05] <StevenK> wgrant: Yeah
[03:05] <wgrant> To which? :)
[03:06] <StevenK> The first comment
[03:06] <wgrant> Ah, good :)
[03:06] <wgrant> It's conceptually simple, there's just a lot of code to change
[03:06] <StevenK> wgrant: I've approved -1-populate with one niggle, but it took me a few minutes to figure out the the _new_* gubbins
[03:06] <StevenK> Hopefully they lose their _new_ness
[03:06] <wgrant> Yes
[03:07] <wgrant> They're just there so they don't override the properties which delegate to PB/BFJ
[03:07] <wgrant> So all the other callsites don't have to care
[03:07] <wgrant> (since the _new_ cols obviously won't be populated when the appservers first start up with that code)
[03:07] <wgrant> They'll be renamed in -5, I suspect
[03:07] <StevenK> Yeah
[03:08] <StevenK> -5-scorched-earth ? :-)
[03:29]  * StevenK hits line of 525 of -3.5 and vomits
[03:30] <wgrant> Mmm?
[03:30] <StevenK> 520	+ BinaryPackageBuild, Archive).find(
[03:30] <StevenK> 521	+ BinaryPackageBuild,
[03:30] <StevenK> 522	SQL(query))
[03:30] <StevenK> 523	resultset.order_by(
[03:31] <StevenK> It's sort of disgusting
[03:31] <StevenK> And needs a rewrite
[03:31] <wgrant> Ah yeah, a bit, but not in this branch :)
[03:31] <wgrant> It needs Stormification
[03:31] <wgrant> Which should come as part of the search rewrite in -6
[03:31] <StevenK> Heh
[03:32] <StevenK> Which branch does DROP TABLE PackageBuild, then?
[03:32] <wgrant> -7 or so, because it's not quite so urgent :)
[03:33] <StevenK> Maybe -8 can make retry-depwait a garbo-frequently job
[03:33]  * StevenK hides
[03:33] <wgrant> No
[03:33] <wgrant> It takes too long
[03:34] <wgrant> It's already a tunable loop, and could maybe be in -hourly
[03:34] <StevenK> Even with this change it will be too slow?
[03:34] <wgrant> Yes
[03:34] <wgrant> This won't affect it in any significant fashion
[03:36] <StevenK> wgrant: Up to -4
[03:39] <wgrant> StevenK: Right, I originally considered having a common garbo base, but the column lists and joins for each are somewhat different, and the code will be on prod for just hours
[03:39] <StevenK> Right, exactly why I ended up with 'eh'
[03:40] <StevenK> wgrant: I'm done, all approved. -3.5 has the most niggles
[03:40] <wgrant> Thanks
[03:54] <wgrant> StevenK: Can you reapprove https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-3-query/+merge/146035 (no changes other than a merge from a garbo-dropping branch, which required a resubmit)
[03:55] <wgrant> Your first comment will be resolved in a later branch that rewrites the search stuff, and your second is invalid (see the next couple of lines)
[03:55] <StevenK> 1013+ find_spec = find_spec + (order_by_table,)
[03:55] <StevenK> OH
[03:56] <StevenK> That's hideous
[03:56] <wgrant> Quite!
[03:56] <StevenK> wgrant: Re-approved
[03:56] <wgrant> Thanks
[04:04] <StevenK> wgrant: Blink. My test failed on buildbot, but passes locally.
[04:04] <StevenK> 2.7 versus 2.6, at a guess?
[04:05] <wgrant> StevenK: Yeah
[04:06] <wgrant> 2.6 eats the whole character
[04:06] <wgrant> It assumes that the size indicated by the first byte is correct.
[04:07] <StevenK> Hm, not sure how to deal with this test for both 2.6 and 2.7, then. :-(
[04:07] <wgrant> http://bugs.python.org/issue8271
[04:12] <StevenK> wgrant: Ouch
[04:12] <StevenK> wgrant: assertTrue(...['field.title'].startswith('...')) ?
[04:12] <wgrant> StevenK: I'd just check if it's one of the two known values
[04:13] <wgrant> With an XXX
[04:13] <StevenK> Right
[04:19] <StevenK> wgrant: http://pastebin.ubuntu.com/1595628/
[04:21] <wgrant> StevenK: Looks good
[04:26] <StevenK> wgrant: -0 is waiting for stub, and I guess -1 can't land until after a FDT?
[04:26] <wgrant> StevenK: Right.
[04:26] <wgrant> Most of the fun will happen after an FDT at 1pm on Monday, I suspect
[04:27] <wgrant> They're all in ec2 now
[04:27] <StevenK> How many indicies do you add?
[04:27] <wgrant> (the runs are condemned due to your failure, though)
[04:27] <wgrant> Um, not sure at this point
[04:27] <wgrant> That's for working on between 2.5 and 3 on Monday
[04:27] <wgrant> Since I can approve them myself and get ops to apply them now
[04:27] <StevenK> Last time I looked, your DB patch said TODO: add indicies
[04:27] <wgrant> I removed that while you were reviewing the rest, I think
[04:28] <StevenK> Ah
[04:28] <wgrant> There's no point creating them at that stage
[04:28] <wgrant> Quicker to create them at the end when all the data's there
[04:28] <StevenK> Indeed
[04:28] <StevenK> And it's not my failure, it's all 2.6's fault.
[04:28] <wgrant> True
[04:29] <StevenK> wgrant: Shall we deploy in about 70 minutes?
[04:29] <StevenK> Might be closer to 80, but eh
[04:30] <wgrant> So, remaining changes: work out indices, clean up all the _new crap, drop PackageBuild itself, drop the old DB columns/table, apply various NOT NULL constraints, work out indices for the new D/DS/SPN/i_d_a queries, integrate the new D/DS/SPN/i_d_a queries
[04:30] <wgrant> And that should be that
[04:30] <wgrant> And yes, we should deploy tonight
[04:30] <wgrant> Will close 3 criticals?
[04:31] <StevenK> Yah
[04:31] <StevenK> I need to find another
[04:40] <StevenK> wgrant: How can I pull apart this checkwatches core ?
[04:41] <wgrant> You may not have much luck pygdbing it post-portem
[04:42] <wgrant> post-mortem
[04:43] <wgrant> Ideally we'd do it in-place
[04:45] <StevenK> On loganberry?
[04:46] <wgrant> Yes
[06:45] <wgrant> stub: Thanks. Those indices were indeed planned for a quick followup, but the DEFAULT thing slip my mind this time.
[07:16] <stub> yup, I assumed the indexes would be landing soon. Just making sure those particular ones don't get lost in case you were mainly thinking about performance tuning.
[07:17] <wgrant> stub: Though it doesn't matter much for librarian-gc anyway
[07:17] <wgrant> As it basically seqscans everything
[07:17] <wgrant> But still useful
[07:18] <wgrant> It's person merges that really matter, as they are selective
[07:18] <stub> mmm...
[07:18] <stub> I haven't looked for ages. I was thinking there was some selectivity in there.
[07:19] <wgrant> Well, consider what it has to do :)
[07:19] <wgrant> It needs to find LFAs that are unreferenced
[07:19] <wgrant> Which means finding a list of everything that is referenced
[07:20] <wgrant> The index only helps a lot if the column is relatively sparse
[07:32] <stub> That is one part of the algorithm. There used to be parts that benefited from the indexes. But TBO, I don't really know if that is still the case after a few years of tweaking.
[07:33] <stub> If nothing else, deleting a single row from LFA requires looking up if that row is referenced anywhere - index lookups or table scans if the indexes don't exist.
[07:34] <stub> Which is hundreds or thousands each gc run
[07:39] <wgrant> Oh yeah, that bit is a good point.
[07:39] <wgrant> Duh


[00:00] <haasn> Weird. Destroying the VM and re-creating it and now everything seems to work. Must have been some weird failure due to the way I batch-created the VMs
[00:00] <haasn> Have to go through the VMs all and recreated them manually I guess :/
[00:20] <haasn> 2016-02-09 00:18:31 ERROR juju-log FATAL ERROR: Could not determine OpenStack codename for version 7.0.1
[00:20] <haasn> Huh?
[06:03] <stub> marcoceppi: ETIMEZONE
[06:32] <haasn> What does “incomplete relations” mean?
[06:32] <haasn> It's obviously different from “missing relations” in some sense
[09:49] <haasn> Revelation: Writing configs by hand is faster, easier, more efficient, more robust and more scaleable than attempting to use juju for anything other than setting up a basic wordpress site
[10:34] <apuimedo> jamespage: did you see the merge proposal I sent last night for fixing liberty support?
[10:35] <jamespage> apuimedo, I saw the charm mp - is there a charm-helpers proposal as well?
[10:35] <jamespage> I've not looked yet...
[10:35] <apuimedo> heh
[10:35] <apuimedo> lack of sleep
[10:36] <apuimedo> Totally forgot about updating it in charm-helpers
[10:36] <apuimedo> I'll send it now
[10:41] <apuimedo> jamespage: https://code.launchpad.net/~celebdor/charm-helpers/plugin_pkg_fix/+merge/285458
[13:16] <marcoceppi> stub: ping
[13:26] <stub> marcoceppi: pong
[13:27] <marcoceppi> stub: love the apt layer, but have some concerns symlinking the reactive directory into lib. I feel it'd be better to instead move the 4 or 5 methods you want to expose to other layers as a charms.apt module
[13:28] <marcoceppi> which is the pattern a lot of other layers are starting to use
[13:28] <stub> marcoceppi: That is a hack until I can get absolute imports working with charms.reactive (I've got a pull request up for that)
[13:28] <marcoceppi> what do you mean?
[13:29] <stub> https://github.com/juju-solutions/charms.reactive/pull/51
[13:29] <stub> So if that gets rejected, yeah, I'll need to split things into $CHARM_DIR/reactive and $CHARM_DIR/lib
[13:30] <stub> The branch fixes absolute imports, relative imports, and other import weirdness I've seen.
[13:31] <marcoceppi> To me, it seems that reative/* files are basically main() methods for dispatching. i wouldn't want people importing or relying on them. whereas things in lib/ are the public apis I'm exporting
[13:33] <stub> I've got reactive stuff as my charm specific stuff, and lib for non charm/non juju stuff.
[13:34] <marcoceppi> right, but I think putting reactive stuff would be okay in lib/charms/ since this prefaced as a charm thing. I wouldn't want people importing my reactive/ files because they're basically just glue for managing states
[13:34] <stub> But in any case, it would be nice to get imports in reactive and hooks/{reactive,relations} working as expected.
[13:35] <marcoceppi> if cory_fu is around today I'll chat with him about it
[13:35] <stub> Yes, it could go in there. In my case, reactive *isn't* just glue and is documented that way. But I can change that.
[13:36] <marcoceppi> I'll chat with cory on goals and vision
[13:36] <stub> It was all working fine for me until I switched to the standard hook stubs and lost $CHARM_DIR from my sys.path ;)
[13:37] <stub> You want files containing handlers to be able to import other files containing handlers in any case, as sometimes they are triggered by state and sometimes you want to invoke them directly
[13:44] <stub> marcoceppi: I'll still shuffle things around to $CHARM_DIR/lib/apt.py if that is where things like this should go - no point being unnecessarily different
[13:44] <stub> marcoceppi: The leadership layer will have the same thing, and the coordinator layer (which I was blocking announcing until that pull request got commented on)
[13:45] <marcoceppi> stub: I'd appreciate it, at least for the apt layer, as it'll make integration easier for some of the other layers. As for the others coordinator and leadership there may be a use case there for them to import reactive directly, I'll let cory_fu judge that from a library maintainer perspective
[13:47] <stub> I've got gpg keys, json data files, and a few small Python helpers lurking in lib.  In particular for the apt layer. 'import apt' will get the system apt module. I'd need to stick it in charms/reactive/apt since this is specificly reactive framework stuff.
[13:49] <marcoceppi> stub: we've been prefacing modules by placing them in lib/charms/
[13:50] <stub> marcoceppi: at which point I'm stomping around in cory's namespace.
[13:50] <marcoceppi> that way it's from charms import apt
[13:50] <marcoceppi> that was the guidance I got from him originally
[13:50] <stub> Right. Not as reactive specific as I'd like, but it will do in a pinch.
[13:50] <stub> I guess reactive *is* the new charms
[13:51] <marcoceppi> stub: maybe we should namespace further in the charms module to be like charms.layers or possibly a lib/reactive/ ?
[13:51] <marcoceppi> something work discussing
[13:51] <stub> that is what I did with the symlink hack ;)
[13:51] <marcoceppi> yeah, but I think it went a little too far with the symlink to reactive dir
[13:51] <marcoceppi> either way
[13:52] <marcoceppi> I'll ping cory to chat about it either today or tomorrow
[13:52] <stub> ta
[13:52] <marcoceppi> I think he's still taking vacation after last week
[13:52] <marcoceppi> will mail the list with the discussion
[14:00] <stub> marcoceppi: Have you noticed the potential migration path for charmhelpers/core/hookenv.py yet? ;)
[14:03] <marcoceppi> stub: I've been playing with a few ideas
[14:03] <stub> marcoceppi: Was thinking if these layers and similar get accepted, the code they wrap could move directly into the layer.
[14:04] <stub> Old functionality, new, consistent api.
[14:24] <Shruthima> Hi Mbruzek, IBM installation manager is a prerequisite tool for many IBM products installation such as WAS, DB2, HTTP Server.  So, it doesn't have database relation or web interface. Can we charm without using any interface ? Could you please suggest me which interface i can use for IBM-Installation manager charm..?
[14:25] <mbruzek> Hello Shruthima
[14:28] <mbruzek> Shruthima: If IBM IM is a pre-requisite that tells me that is should be a layer that other charms could include.
[14:31] <mbruzek> Shruthima: https://jujucharms.com/docs/devel/developer-layers
[14:32] <Shruthima> ok thanks
[14:32] <mbruzek> Shruthima: So to answer your question, if software X is a pre-requisite and has no known relations that is the perfect reason to make a layer. The trick is to make it useful so that ALL the other IBM charms can use that layer, and they would not have to have any IBM IM code in their charms.
[14:33] <mbruzek> I wrote a tls layer for one charm, that is now used in 2 charms.  https://github.com/mbruzek/layer-tls
[14:34] <mbruzek> Shruthima: Although that layer is quite different than IBM IM, you may be able to use that as an example
[14:34] <Shruthima> yes ,i feel it right . will check on layers and try to do it is a layer.
[14:34] <mbruzek> Shruthima: You _can_ write the layers in bash, but it may be easier to do in Python
[14:35] <mbruzek> (less code, easier to maintain, etc)
[14:36] <Shruthima> oh k thank you if any queries will check with you.
[14:37] <mbruzek> Shruthima: Good luck!
[15:20] <cory_fu> stub, marcoceppi: Sorry for the late reply.  Got a late start today because I'm sick following the summit.  I'm torn on the issue of importing within reactive/.  On the one hand, I like the idea of cleaning up the import code.  On the other, I'm leaning strongly against reactive handlers being imported directly for anything other than tests.
[15:21] <cory_fu> I prefer to think of files under reactive/ as executables and thus anything that is common to multiple handler files should be factored up into a lib/charms/* location
[15:27] <cory_fu> Maybe we could reserve a namespace specifically for helpers that a given layer provides?  We currently have lib/charms/layer.py used in the base layer for the layer.yaml options support, but maybe we could restructure that and reserve lib/charms/layer/<layer-name> for each layer to put its own helpers?  So, the apt layer would have helpers you would access via "import charms.layer.apt"
[15:37] <marcoceppi> cory_fu: I think an explicit namespace for helpers that layers provide would be good
[15:37] <marcoceppi> in this case, the layer.py would just be __init__.py with those few methods?
[15:37] <marcoceppi> or possibly charms.layers.config for the base layer stuff?
[15:49] <jeiworth> hi all
[15:51] <jeiworth> quick question, i am using juju deployment in aws and have the landscape-client charm deployed and connected to my instances. my landscape i have standalone in another environment. first, i configured the landscape client from ssh cli and all was good, i later adapted the same configuration through the juju-gui of the charm and since then it apparently does't recognize reboots? i can still update packages through landscape and if i send t
[16:01] <cory_fu> marcoceppi: Yeah, I'm fine w/ an __init__.py for the options helpers
[16:03] <jeiworth> ...sooo any ideas welcome... :-)
[16:17] <marcoceppi> jeiworth: I will take a look in a min!
[16:18] <jeiworth> marcoceppi: thanks!
[18:34] <bdx> Hows it going everyone? Does anyone know how to switch the source of a deployed charm?
[18:35] <marcoceppi> bdx: the charm source?
[20:07] <stokachu> http://paste.ubuntu.com/15004365/, anyone else seeing this issue with juju from master?
[20:08] <stokachu> i see the Deploy function under the Service api type though
[20:10] <bdx> marcoceppi: say you deploy local:trusty/nova-compute, following which you want to switch to cs:trusty/nova-compute
[20:10] <marcoceppi> bdx: juju upgrade-charm --switch cs:trusty/nova-compute nova-compute
[20:12] <bdx> marcoceppi: exactly
[20:12] <bdx> thanks mon!


[00:08] <cjwatson> doko: meh.  I'd sort of like to be in sync
[00:08] <cjwatson> otherwise we'll waste time diagnosing weird stuff
[00:08] <cjwatson> bleh, who NEWed linux?  it's all gone to universe
[00:09] <cjwatson> use kernel-overrides
[00:10]  * cjwatson fixes it up with security-kernel-overrides
[00:11] <cjwatson> or I would if LP hadn't apparently exploded
[00:13] <cjwatson> ... downtime, I guess
[00:14] <apw> cjwatson, yeah was some downtime
[00:14] <cjwatson> 2200-0000 UTC, so that would be now
[00:14] <apw> yeah ... bah
[00:15] <cjwatson> any luck with the problem at hand?
[00:16] <apw> i think i've sorted it out, am trying get a test build started to confirm
[00:18] <cjwatson> I'd like to try test-building something on !powerpc to make sure that the new linux-libc-dev works, but I can try that in a chroot locally
[00:20] <apw> cjwatson, good plan, before it polutes the chroots
[00:35] <cjwatson> a not very randomly chosen sample of anna and man-db still compile
[00:36] <cjwatson> which includes man-db's rather rudimentary test suite so binaries also still run
[01:01] <cjwatson> LP's back up sufficiently to run change-override, so have moved things back to main where they belong
[01:01] <apw> cjwatson, thats good news.  the build is looking plausable on ppc, not quiet sure how long it'll run yet
[01:02] <apw> am inclined to upload it so you can new, and we can sleep
[01:02] <cjwatson> sounds good
[01:03] <cjwatson> need sleep myself, have to handle the kids tomorrow morning
[01:05] <apw> building the package now
[01:10] <apw> cjwatson, ok its uploaded, should be on the queue as soon as the queue runner finds it
[01:12] <apw> ok it's there
[01:14] <cjwatson> accepted, thanks
[01:14] <cjwatson> just looking at that queuebot bug
[01:14] <apw> cjwatson, heh it'll wait till tommorrow
[01:15] <cjwatson> if I do that I'll forget
[01:15] <cjwatson> (it's a one-liner anyway)
[01:18] <cjwatson> (slightly too late to demonstrate the fix, unfortunately)
[01:24] <stgraber> auto reconnect ?
[01:24] <cjwatson> stgraber: no, code upgrade
[01:25] <cjwatson> I'll add a "don't report initial queue" option for next time
[08:43] <cjwatson> apw: hm, still broken on powerpc
[08:44] <apw> cjwatson, ok that overnighter also failed to build for a new error, i have a fix for the error it hit, but am flying blind fixing it as i cannot do a full build on the porters due to chroot issues... do we want to hope this fixes it en-toto or wait for the porters to be fixed
[08:44] <apw> (from -devel)
[08:44] <apw> flying blind testing it
[08:53] <cjwatson> hm, it got quite a distance through didn't it?
[08:53] <apw> yeah i have fixed the build failure in that flavour
[08:53] <cjwatson> I'd say upload blind but keep going on davis in parallel
[08:53] <apw> ack
[08:53] <apw> what is odd is the build seems to progress in a different order on a buildd than a full build with dpkg-buildpkg -B seems to
[08:53] <apw> cjwatson, who owns the porters is that #is ?
[13:29] <apw> cjwatson, ok porters fixed and testing done, sadly failed, another build failure in perf.  I have fixed that and have built all the components on the porter successfully
[13:30] <apw> so i believe i now have a fixed source package, a full test is building as belt-and-braces
[13:32] <apw> i beleive this should be the final version, and i suspect I should just upload it
[13:40] <cjwatson> apw: I suspect so, from the sound of it
[13:41] <cjwatson> interesting ride, this
[13:41] <apw> cjwatson, ports can be a major pain at this stage, normally we can let them drift
[13:41] <apw> i am not sure the kernel has gated the release before
[13:44] <cjwatson> I don't mind letting them drift if they've built once, but I'm concerned about having the architectures out of sync for major toolchain components right at the start - the point of splitting off ports is to make them consume less developer time, and while I realise this is a bit of extra time at the start I think that having things too out-of-sync would consume more developer time in the long run
[13:45] <cjwatson> and we're not behind schedule or anything so it seems worth spending a bit of time now for less hassle later
[13:45] <apw> cjwatson, fair enough.  i am pretty hopeful from the testing i have managed to do that this one should build fine on all arches
[15:00] <apw> cjwatson, we might need to rescore that ppc build
[15:01] <cjwatson> apw: done
[22:26] <apw> cjwatson, ok finally all those builds finished, so once powerpc is new'd we have a full set of linux-libc-dev
[23:12] <cjwatson> looks like somebody's done it
[23:12] <cjwatson> doko: do we need to wait for your new gcc-4.5?  I assume it'll take a while
[23:12] <doko> cjwatson: no
[23:13] <doko> binutils should be built however
[23:13] <cjwatson> doko: did you NEW linux/powerpc?
[23:13] <doko> cjwatson: yes. anything wrong?
[23:13] <doko> did do the same for the other archs
[23:13] <cjwatson> doko: if you could use the kernel-overrides script in future to make sure the overrides are synced up with the last ABI, that would be good
[23:13] <doko> ahh, ok
[23:14] <cjwatson> can fix it up after the fact, though not 'til it's finished publishing
[23:14] <cjwatson> anyway, not urgent, linux-libc-dev will still be in main which is what matters for now
[23:14] <doko> well, I did see that linux-libc-dev did end up in main, and that was good enough for me
[23:14] <cjwatson> (the actual kernel and such has gone to universe)
[23:15] <cjwatson> I guess not much depends on linux-headers any more
[23:15] <cjwatson> binutils has finished building and seems to be published
[23:15] <doko> ok, binutils is in the archive as well, so we can open
[23:15] <cjwatson> we need to wait for linux-libc-dev/powerpc to be published
[23:16] <doko> ahh, ok
[23:16] <doko> another 20min
[23:16] <cjwatson> ok, feel free to ask a LOSA for it, I'm off to bed :-)
[23:16] <doko> will write the announce email tomorrow
[23:16] <cjwatson> I can start an autosync pass tomorrow if you like
[23:17] <doko> cjwatson: on #is or #soyuz?
[23:17] <cjwatson> probably more likely to find somebody on #is
[23:17] <cjwatson> though there's a reasonable number of sysadmins on #soyuz too
[23:19] <doko> cjwatson: see #is
[23:21]  * apw is glad to see that lot finally build


[04:25] <mup> Bug #2024890 changed: Cloud-init is unable to retrieve metadata in MAAS 3.3.4 during deployment <MAAS:Expired> <https://launchpad.net/bugs/2024890>
[04:28] <mup> Bug #2024890 opened: Cloud-init is unable to retrieve metadata in MAAS 3.3.4 during deployment <MAAS:Expired> <https://launchpad.net/bugs/2024890>
[04:31] <mup> Bug #2024890 changed: Cloud-init is unable to retrieve metadata in MAAS 3.3.4 during deployment <MAAS:Expired> <https://launchpad.net/bugs/2024890>


[03:52] <Unit193> pleia2, nhandler and jose should all be at OLF, anyone else from here?
[05:05] <yano> really? awesome
[05:05] <yano> i might try to make it out this year
[15:45] <belkinsa> God, I think that the lamest thing that I said on our mailing-list.
[15:46] <belkinsa> But it's the truth, Adam-M.  And welcome, Adam-M to our LoCo and our IRC home.  Where do you hail from?
[15:46] <Adam-M> Akron
[15:46] <belkinsa> I think Unit193 is in that area also.
[15:47]  * belkinsa hails from West Chester, a place between Ciny and Dayton
[15:48] <belkinsa> Unit193: well, you gave me a reason to come to OLF.
[15:48] <AntonM> Hi
[15:48] <belkinsa> o/ AntonM
[15:48] <belkinsa> Are you two bothers, AntonM and Adam-M?
[15:49] <AntonM> Yes
[15:49] <belkinsa> Ha, I knew it.  :D  Anyways, welcome to our LoCo and our IRC home.
[15:50] <AntonM> Thanks
[15:50] <AntonM> BTW, how were you able to tell?
[15:50] <belkinsa> Not a problem.
[15:50] <belkinsa> Last names when you requested to join.
[15:50]  * belkinsa is one of the leaders
[15:51] <belkinsa> along with Unit193 and jrgifford.
[15:53] <belkinsa> Did you discover Ubuntu recently?
[15:53] <belkinsa> https://wiki.ubuntu.com/belkinsa <--- that's me.
[15:53] <jenni> [ belkinsa - Ubuntu Wiki ] - https://bit.ly/1eqs1VA
[15:55] <Adam-M> I started with Ubuntu 10.04, but I only ran it in a virtual machine until 12.04.
[15:56] <AntonM> ^
[15:57] <belkinsa> I started with 9.10.  So I guess you two want to voluteer in the Community or just support our LoCo and Ubuntu?
[15:58] <Adam-M> How will we volunteer?
[16:00] <belkinsa> It depends on what skills you have.
[16:01] <belkinsa> For example, I don't really have techical skills but I do have people skills that allow me to build community and that's what I focus on.
[16:01] <belkinsa> https://wiki.ubuntu.com/ContributeToUbuntu
[16:01] <jenni> [ ContributeToUbuntu - Ubuntu Wiki ] - https://bit.ly/2bg0z6c
[16:03] <belkinsa> Oh, and Unit193: http://askubuntu.com/questions/811218/failed-to-restart-idmapd-service-unit-idmapd-service-is-masked Can you give me some insight if possible.  Or whoever is the server guy here.
[16:03] <jenni> [ networking - Failed to restart idmapd.service: Unit idmapd.service is masked - Ask Ubuntu ] - https://bit.ly/2bg01gC
[16:04] <belkinsa> Adam-M and AntonM: we always need help in building this LoCo.
[16:04] <AntonM> Ok
[16:05] <belkinsa> But you can go out of our LoCo and help the greater Community if you wish.
[16:05] <AntonM> I'll help this LoCo
[16:06] <belkinsa> :0
[16:06] <belkinsa> :)*
[16:07] <belkinsa> From what I know, I think most of members are from nothern Ohio.  One idea is to restart the idea of the Regional LoCo in that area.
[16:10] <AntonM> How do we get started?
[16:12] <belkinsa> Ask on the mailing-list who is from the area and suggest the idea of doing a meet up.  See if you can get some folks that way.  You can also try Twitter and other social media.
[16:14] <AntonM> Ok
[16:15] <belkinsa> And I do wish you luck, we do need a few active peeps.
[16:15] <AntonM> Thanks
[16:15] <belkinsa> Not a problem.
[16:17] <belkinsa> Anyways, I need to go to work.  If you need me, please feel free to ping me here (and stay of course), PM me, or e-mail me.  Just keep in mind that I might not repsonsd quickly like I did.
[16:17] <AntonM> Ok
[19:56] <Unit193> Wosh, there's backlog here.
[20:08] <Unit193> belkinsa: While it may partially be a "got a life" problem, that's not entirely it.
[21:33] <Unit193> AntonM: Well howdy and welcome back.  I'm not in the Akron area actually, just Mans.
[21:34] <AntonM> Hi
[21:34] <Unit193> Welcome to Freenode.
[21:37] <AntonM> Thanks
[21:37] <Unit193> One of the guys from Ashland was going to the Akron area LUGs, seems they had some good sessions.
[21:38] <Unit193> http://www.meetup.com/Akron-Linux-Users-Group/ this, I think.
[21:38] <jenni> [ Akron Linux Users Group (Akron, OH)- Meetup ] - https://bit.ly/2b55ovx
[21:41] <Unit193> I'd take a guess that you use Ubuntu/Unity?  Doesn't really matter, but I'm an Xfce user myself.


[07:33] <duflu> alf__: Is glmark2 designed to finish in a fixed time or vary according to GPU power?
[09:07] <alf__> duflu: fixed time (test parameter 'duration' default is 10 seconds)
[09:07] <duflu> alf__: Right, so a slow machine won't take it over an hour then
[09:08] <alf__> duflu: right
[09:32] <duflu> Remind me not to try and fix bugs so much. Fixing the fixes takes so much time that the feature development halts :)
[09:33] <alan_g> Just don't put the bugs in to start with
[09:34] <duflu> alan_g: None are mine (?). I'm trying not to victimize their creators
[09:34] <duflu> Mostly not mine
[09:34] <alan_g> Indeed, we all review the MPs
[09:35] <duflu> Oh and then some devious test reboots my phone
[09:36] <duflu> alan_g: I remember you suggested making people responsible, back at the sprint. I had thought the same before. The real issue is the person desiring a fix the most is not usually the person who broke it
[09:41] <alan_g> I think people should be aware of how they broke something so that they can learn. But one can't be made responsible one has to be it.
[09:44] <duflu> OTOH, if someone is a repeat offender, we would be wise to throttle them with bugfix tasks instead of feature development
[09:44] <duflu> But that would be mean too
[09:45] <duflu> More phone testing...
[09:56] <duflu> alan_g: OK I can reproduce the GLMark2Test hang. It's a visible freeze. Will need to continue tomorrow
[09:57] <duflu> Visible on mako
[09:57] <alan_g> duflu: that's great - I couldn't reproduce (admittedly I didn't spend very long on it)
[09:58] <duflu> alan_g: I suspect we're not matching up number of buffer replies with number of requests. Both server and client are starved and idling
[09:59] <alan_g> Then you've got processes to poke around in? Even better.
[10:00] <alan_g> I'll be glad to see that one gone
[10:00] <duflu> alan_g: Yeah. Annoyingly seems related to what I'm fixing, but more needs fixing obviously
[10:02] <alan_g> duflu: hopefully that means there will be a unified fix that will be obviously correct. (Once you've thought of it.)
[10:02] <duflu> alan_g: Or many
[10:02]  * alan_g hopes not
[10:03] <duflu> Oh it's going to be a bug fix week
[10:05] <duflu> alan_g: Can you track down any more MPs that made it worse?
[10:06] <duflu> Although I've got two that do it reliably
[10:07] <alan_g> I've not noticed any others. But I'll keep track.
[10:08] <duflu> Hmm, framedropping policy has moved into GlibMainLoop recently
[14:22] <AlbertA> ogra_: the mir release is stuck in proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:22] <AlbertA> http://pastebin.ubuntu.com/9250453/
[14:23] <AlbertA> ogra_: it looks like ubuntu-touch package has a dep on  libmirplatform3driver-android
[14:23] <AlbertA> ogra_: and looking at the README it seems it is based on the seeds: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/ubuntu-touch-meta/vivid/view/head:/README
[14:24] <AlbertA> ogra_: any ideas on how to move forward?
[14:25] <ogra_> by dropping it ;)
[14:26] <ogra_> its a bit awkward that we have to update the seeds for such a change ... that means new -meta packages for every ABI bump you guys do
[14:26] <ogra_> would be nicer to have a higher level libmir meta package that the seed could depend on
[14:27] <AlbertA> ogra_: right that's why this new mir release introduces mir-graphics-drivers-android
[14:27] <ogra_> (similar to linux vs linux-image vs linux-image-$(uname -r)
[14:27] <ogra_> ah, right, so lets land this then :)
[14:29] <AlbertA> so do we manually modify the dep lists for ubuntu-touch and land it together with the mir release?
[14:30] <AlbertA> ogra_:^
[14:30] <ogra_> no
[14:30] <ogra_> ubuntu-touch-meta gets generated from the seeds ;)
[14:31] <AlbertA> ogra_: ok
[14:31] <ogra_> i just merged your seed change ... takes a bit to generate the package
[14:31] <ogra_> i'll upload asap
[14:31] <AlbertA> ogra_: ok thanks!
[15:24] <alan_g> alf__: I'm looking at MirScreencastTest and thinking that the tests that depend on the mock_screencast are really integration tests. (And that the remaining tests don't really prove the feature.) Do you concur?
[15:24] <alf__> alan_g: looking
[15:31] <alf__> alan_g: I mostly agree. This (like other tests) would like to be true end-to-end tests, but unfortunately that's not possible with our current CI infrastructure.
[15:33] <alan_g> yes
[15:34] <alf__> alan_g: Also what is an acceptance vs integration tests in our current architectur is somewhat fuzzy. The "hexagonal architecture" definition of acceptance vs integration is the clearest I have encountered.
[15:34]  * alan_g goes to google
[15:36] <alf__> (hexagonal == ports and adapters)
[15:37] <alan_g> From a quick skim this looks like what I intended to describe at the initiation sprint
[15:42] <alf__> alan_g: Makes sense. It's also what the example in the GOOS book finally organically ends up with. Here are some nice diagrams from one of the authors: http://www.natpryce.com/articles/000772.html
[15:43] <alan_g> yep
[15:44] <alf__> alan_g: I like that acceptance tests (tests again the domain model) are different from end-to-end (system) tests.
[15:47] <alan_g> Sure. And it does fit with our classification. (What system tests we have are in benchmarks or examples and are not very good at reporting pass/fail)
[15:48] <alan_g> Anyway, for the current instance, you're happy if I shuffle most of the tests over to integration tests?
[15:50] <alf__> alan_g: Sure. If we can easily change some of them to remain in the acceptance tests (and it makes sense to do so), then I would prefer that of course.
[15:52] <alan_g> I'm taking reliance on mock_screencast (as opposed to having it around by accident) as the discriminator.
[15:53] <alf__> alan_g: Moving them will create some acceptance test gaps (e.g. for the mir_screencast api), but let's fix them properly.
[15:54] <alan_g> It just makes the gap more visible
[16:01] <alf__> alan_g: The MirScreencast test in particular could be probably made to work as acceptance test, if we use our MockGL/EGL infrastructure, which makes sense since EGL/GL is our integration point. We don't have an interface for GL/GLES but we can just use the link-time seam as usual.
[16:02] <alf__> alan_g: ... or introduce an interface for it
[16:03] <alan_g> Yes, but I don't want to take that on right now
[16:05] <alf__> alan_g: Understood.
[17:09] <AlbertA> greyback_: mir has released, so no lock on qtmir anymore :)
[17:09] <greyback_> AlbertA: yay, thanks
[19:49]  * DalekSec waves to olli_.
[19:52] <olli_> camako, DalekSec is representing xubuntu and was helping to gather some xmir compatibility test results back in the day
[19:52] <olli_> camako, he had a question if http://unit193.net/wiki/doku.php?id=wiki:mir is still of help
[21:06] <camako> olli_, first time I'm seeing it... It could be useful if it were up to date.


[09:27] -SwissBot:#ubuntu-news- ::Planet:: Jonathan Carter: Free Software Activities 2021-02 @ https://jonathancarter.org/2021/03/17/free-software-activities-2021-02/
[13:00] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Vivaldi Browser Gets Major Speed Boost @ https://www.omgubuntu.co.uk/2021/03/vivaldi-browser-now-even-faster (by Joey Sneddon)
[17:22] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Ask Me Anything: Ubuntu Core 20 @ https://ubuntu.com//blog/ask-me-anything-ubuntu-core-20
[20:57] -SwissBot:#ubuntu-news- ::Planet:: Steven Harms: Software Raid on Ubuntu 20.04 @ https://www.sharms.org/posts/software-raid/?utm_source=atom_feed
[21:41] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Design and Web team summary – 17 March 2012 @ https://ubuntu.com//blog/design-and-web-team-summary-17-march-2012
[22:33] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Ubuntu in the wild – 17th of March 2021 @ https://ubuntu.com//blog/ubuntu-in-the-wild-04
[22:44] -SwissBot:#ubuntu-news- ::Planet:: Alan Pope: Actually Upgrading Ubuntu Server @ https://popey.com/blog/2021/03/actually-upgrading-ubuntu-server/