[00:41] <waigani> wallyworld: fix: http://reviews.vapour.ws/r/2603/
[00:41] <wallyworld> ty, looking
[00:42] <wallyworld> waigani: we need a test also
[00:42] <waigani> wallyworld: okay, I'll add that now
[00:42] <wallyworld> in general, any bug fix should be accompanied by a test
[00:42] <wallyworld> ty
[00:56] <waigani> wallyworld: test added
[00:56] <wallyworld> looking
[00:59] <axw> wallyworld: so just so I understand the status history change: previously we didn't store the latest status in history, and now we do? and because of that, returning history would duplicate the latest?
[00:59] <wallyworld> waigani: lgtm but are there any call sites to update (see comment in review)
[01:00] <waigani> looking
[01:00] <wallyworld> axw: yes - william did a whole lot of refactoring there and changed how status history was recorded, but the retrieval method wasn't unit tested nor updated to match
[01:01] <axw> wallyworld: ok
[01:01] <wallyworld> axw: tested live, works nicely
[01:02] <wallyworld> waigani: actually, how do we handle the "never logged in" case now in a new 1.26 install?
[01:12] <waigani> wallyworld: so user.LastLogin() will return a time.Time{} but the API server will still return a nil. See checkCreds func in apiserver/admin.go for example.
[01:12] <waigani> wallyworld: there is also a feature test to ensure we display the correct "never connected" message, e.g. TestSystemEnvironmentsCommand
[01:14] <axw> wallyworld: reviewed
[01:15] <wallyworld> waigani: without being overly familar with the code, would it be better to return a NeverLoggedInError ? ie is there a record that we just should not write out during the upgrade if last login is nil
[01:16] <wallyworld> axw: thanks, looking
[01:20] <wallyworld> axw: with HistoricalUnit, I think I ran into the same issues as in the uniter work recently - too much existing code being called back into. i'll double check though if i can rework it
[01:20] <axw> wallyworld: thanks
[01:21] <waigani> wallyworld: you're talking about the upgrade step? If user has never logged in, skip creating a lastLoginDoc? Actually, yes that makes more sense.  As user.LastLogin() returns neverConnectedErr for a missing lastLoginDoc.
[01:21] <wallyworld> waigani: exactly
[01:21] <waigani> wallyworld: I'll redo fix
[01:21] <wallyworld> ta
[01:22] <wallyworld> i was a bit hastely with my shipit :-)
[01:42] <davechen1y> https://github.com/juju/juju/pull/3226
[01:42] <davechen1y> here is an easy one
[01:46] <waigani> wallyworld: third time lucky: http://reviews.vapour.ws/r/2603/
[01:46] <wallyworld> looking
[02:48] <davechen1y> waigani: your branch failed to merge
[02:49] <waigani> davechen1y: I saw. I can't see how the panics are related to my changes. I'm halfway through running all unit tests locally.
[03:08] <davechen1y> usual background test failures i'd say
[03:34] <waigani> davechen1y, wallyworld: fix merged. updating bug...
[03:34] <wallyworld> awesome, ty
[03:58] <wallyworld> jam: i got a surprise - i looked at juju/charm.v5 and see that there's already a Series metadata attribute which contains a single series. But I can see any charms which use it (I didn't look hard). So I think we could attempt to parse both a scalar and a list maybe and if a scalar, emit a deprecation warning and make it a single value list. What do you think?
[03:58] <jam> wallyworld: it should be "serieses", clearly :)
[03:59] <wallyworld> barf
[04:00] <davechen1y> series is an irregular noun
[04:00] <davechen1y> like sheep
[04:00] <jam> yes, I realize that the plural of series is series, it is just fun to be silly.
[04:00] <jam> hence the smiley
[04:00] <wallyworld> indeed
[04:01] <jam> wallyworld: Sounds fine to me to go with a single-or-list sort of parsing, though it probably complicates our internal structure.
[04:01] <wallyworld> i'll mark the parsing tolerant
[04:01] <wallyworld> i'll also asl eco who uses it
[04:02] <jam> wallyworld: I wonder if we actually have it there because we use that spot internally to store what we cached the charm for
[04:02] <jam> as in, it isn't for the data in charm's metadata file, but instead for what we store in the DB
[04:02] <jam> Looking at: https://github.com/juju/charm/blob/v5/meta.go that only has "bson" notation, which means its for the DB, right?
[04:02] <wallyworld> i couldn't see any obvious usages in juju code, but will look harder
[04:03] <wallyworld> yeah, that could be right actually
[04:03] <wallyworld> makes sense
[04:03] <wallyworld> but that sure now complicates it
[04:03] <wallyworld> might have to go with "os-series"
[04:04] <wallyworld> that's what mark changed it to in the spec originally
[04:05] <wallyworld> jam: also, i need to get the resources spec moving again. are you able to schedule some time to have another look before it goes to mark?
[04:05] <jam> wallyworld: so IIRC it seemed good enough before I left, but if you want me to look at it again, I can.
[04:06] <wallyworld> jam: i added stuff to the vcs and web source bits, mainly around authentication etc
[04:06] <wallyworld> i think those are well enough defined for a mvp
[04:06] <wallyworld> since i added material after you last looked, a once over would be great
[04:16] <wallyworld> jam: i looked harder at meta.go, and there is a yaml serialisation tag for Series. so seems like it can be defined in metadata.yaml
[06:35]  * fwereade has just discovered it's a public holiday today
[06:51]  * fwereade has *also* been being a terrible person and failing to look at reviews he should
[06:52] <fwereade> axw, don't suppose you're free to take a very quick look at the uniter interactions in http://reviews.vapour.ws/r/2593/ ?
[08:11] <axw> fwereade: sorry was out. I'll take a look
[08:26] <axw> fwereade: seems fine, apart from growing complexity.
[08:27] <fwereade> axw, I was mainly thinking about "how does it interact with the maltese-falcon changes"
[08:59] <axw> fwereade: I see. still looks fine.
[09:03] <rogpeppe> fwereade: aargh, i just made a bunch of replies to http://reviews.vapour.ws/r/2597 and reviewboard seems to have lost them all. doesn't it save replies as drafts?
[09:03] <fwereade> rogpeppe, I thought it did
[09:04] <rogpeppe> fwereade: ah, false alarm. for some reason they just weren't showing for me.
[11:59] <jam> wallyworld: hey, I'm not feeling great. Since rick can't be at the meeting anyway, can we just do it tomorrow, more around 6UTC ?
[12:00] <wallyworld> jam: sure, works for me
[12:00] <wallyworld> hope you're feeling btter
[12:00] <jam> thanks. I started some antibiotics today, so I expect to be doing better
[12:01] <wallyworld> we can move on resources also
[12:03] <rogpeppe> wallyworld, anyone else: http://reviews.vapour.ws/r/2606/ move to using charm.v6-unstable
[12:03] <wallyworld> rogpeppe: looking
[12:03] <rogpeppe> wallyworld: thanks
[12:04] <wallyworld> rogpeppe: says there are conflicts, were you aware?
[12:04] <rogpeppe> wallyworld: i resolved them
[12:05] <rogpeppe> wallyworld: perhaps i should take the conflict messages out of the PR description
[12:05] <wallyworld> tis ok, i now know, but yeah
[12:06] <rogpeppe> wallyworld: done (well, I edited the PR description in github - i'm hoping that's sufficient)
[12:06] <wallyworld> np :-)
[12:09] <wallyworld> rogpeppe: just started looking - are all those dependencies.tsv changes deliberate?
[12:09] <rogpeppe> wallyworld: yes
[12:09] <rogpeppe> wallyworld: i tried to make them as minimal as possible
[12:09] <wallyworld> np, ty
[12:09] <rogpeppe> wallyworld: new deps are on the latest version
[12:10] <wallyworld> rogpeppe: and the new deps has charm.v5-unstable?
[12:10] <rogpeppe> wallyworld: ues
[12:10] <rogpeppe> yes
[12:10] <wallyworld> not v6?
[12:10] <rogpeppe> ah, no
[12:10] <rogpeppe> it *should* have v6-unstable
[12:10] <rogpeppe> let me check
[12:11] <rogpeppe> wallyworld: looks right to me
[12:12] <rogpeppe> wallyworld: uses charm.v6-unstable
[12:13] <wallyworld> rogpeppe: gopkg.in/juju/charmstore.v5-unstable	git	a921c6c69d74361c38a99a95d2aceec76533038d	2015-08-27T20:19:40Z
[12:13] <wallyworld> i copied that from the review board diff
[12:13] <rogpeppe> wallyworld: that's charmstore, not charm
[12:13] <wallyworld> oh ffs
[12:14] <wallyworld> sorry, is late here
[12:14] <rogpeppe> wallyworld: np
[12:14] <wallyworld> sigh
[12:14] <rogpeppe> wallyworld: i've made that mistake several times before :)
[12:20] <wallyworld> rogpeppe: wow. so much churn. i miss python where you could update *one* file to change a dep. that's what i was refering to before in the email :-)
[12:20] <wallyworld> it's a hell of a lot to look over for a dep change. imo churn should be avoided :-)
[12:21] <rogpeppe> wallyworld: yeah, i have to say i think there should be a better way. haven't found one yet though.
[12:21] <perrito666> wallyworld: all is fun and games until you return an object from the wrong version of a lib :p
[12:21] <wallyworld> use python :-D
[12:23] <wallyworld> also maks me wonder if we've done the right thing threading charm store dependency through so many of our files
[12:23] <rogpeppe> wallyworld: charm store dependency != charm dependency
[12:23] <wallyworld> s/charmstore/charm
[12:23] <wallyworld> sorry, mistyped
[12:24] <rogpeppe> wallyworld: it's not that surprising - charms are at the heart of what juju does
[12:25] <wallyworld> true, was musing out loud maybe it could be encapsulated in some helpers
[12:25] <wallyworld> but probably a crap iea
[12:25] <wallyworld> just annoyed by the churn and trying to think of how to isolate it :-)
[12:26] <rogpeppe> wallyworld: it would be nice if there was a way to view diffs without showing changes that were just import path changes
[12:27] <wallyworld> yeah, that would be nice
[12:29] <rogpeppe> wallyworld: at least with the change from v6-unstable to v6, the change will be *entirely* automatic - you won't even need to look through the diff
[12:30] <wallyworld> true
[12:33] <wallyworld> rogpeppe: +1 but i dislike the error message changes :-)
[12:34] <rogpeppe> wallyworld: thing is that now those URLs can refer to both charms and bundles
[12:34] <rogpeppe> wallyworld: so "charm URL" is technically wrong
[12:34] <wallyworld> so "charm or bundle" then ?
[12:34] <wallyworld> entity has no meaning for an end user
[12:36] <rogpeppe> wallyworld: yeah. i'm not keen on "entity" either
[12:36] <rogpeppe> wallyworld: but "charm or bundle" seems clumsy
[12:36] <wallyworld> can it be changed?
[12:36] <wallyworld> accurate and clear
[12:36] <wallyworld> though
[12:36] <wallyworld> or even "charm/bundle not found" works
[12:37] <wallyworld> maybe not with the / as that could be confusing
[12:37] <wallyworld> but still "entity" kinda sucks
[12:37] <rogpeppe> wallyworld: i'd prefer to change it in another PR if that's OK
[12:38] <wallyworld> sure, that's why i didn;t mark it a blocker, just a whine :-)
[12:38] <rogpeppe> wallyworld: :)
[12:38] <wallyworld> right, i better get sleep before i confuse charm and charmstore again
[12:41] <rogpeppe> hmm, if this bug https://bugs.launchpad.net/juju-core/+bug/1493016 is marked as fix-committed, why is master still blocked? http://juju.fail/
[12:41] <mup> Bug #1493016: Panic on upgrade from 1.22 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Committed by waigani> <https://launchpad.net/bugs/1493016>
[13:04] <frobware> dimitern, you joining the MAAS HO?
[13:12] <dimitern> frobware, yeah, omw
[13:12] <frobware> dimitern, too late. Call just dropped. :)
[13:12] <dimitern> frobware, oh :/ too bad
[13:12] <frobware> dimitern, 10 minutes and you're out!
[13:12] <frobware> :)
[13:12] <dimitern> frobware, I was fighting until a few minutes ago to fix my config here
[13:13] <frobware> dimitern, want to HO around the SubnetsAvailabilityZoneNames card?
[13:13] <dimitern> frobware, I managed to break bash, unity, emacs and dbus with just a few edits in the wrong places :)
[13:13] <dimitern> frobware, all fixed now though ..
[13:13] <frobware> dimitern, well the Emacs is obviously bad; the rest? meh... :)
[13:14] <dimitern> frobware, sure, but as I need to go to the store now, how about to do it in ~30m?
[13:14] <frobware> dimitern, yep np
[13:47] <dimitern> frobware, hey, I'm back
[13:48] <frobware> dimitern, want to use the standup HO?
[13:48] <dimitern> frobware, joining our 1:1 HO
[13:48] <dimitern> frobware, :)
[14:01] <voidspace> dimitern: ping
[14:13]  * perrito666 returns from the mecanic and figures he chose the wrong career
[14:31] <natefinch> perrito666: lol that is what I think every time I have to pay someone to do something for me.
[14:32] <perrito666> natefinch: well, he had to rebuild the whole engine cooling system, Its not like I can complain
[14:42] <mgz> perrito666: well I'm glad the mechanic could fix you
[14:42] <mgz> would be a shame to have to sell you for scrap
[14:45] <voidspace> frobware: ping
[14:48] <perrito666> mgz: lol
[15:15] <frobware> voidspace, pong; in a HO with dimitern
[15:27] <voidspace> frobware: ok
[15:30] <mup> Bug #1493016 changed: Panic on upgrade from 1.22 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1493016>
[16:22] <mup> Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:25] <mup> Bug #1493444 changed: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:27] <mramm> Could someone respond to this bug: https://bugs.launchpad.net/juju-core/+bug/1490865
[16:27] <mup> Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes <cloud-installer> <oil> <juju-core:New> <MAAS:Triaged> <https://launchpad.net/bugs/1490865>
[16:31] <mup> Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:31] <marcoceppi> who did the status-history stuff?
[16:31] <mgz> what's the new way of connecting directly to mongodb on the state server?
[16:31] <mgz> marcoceppi: perrito666 mostly
[16:32] <marcoceppi> perrito666: you around? I'm trying to figure out the API endpoint for status-history
[16:33] <mramm> For bug #1490865 I am interested in people's opinion
[16:33] <mup> Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes <cloud-installer> <oil> <juju-core:New> <MAAS:Triaged> <https://launchpad.net/bugs/1490865>
[16:35] <marcoceppi> Is there a list of the API endpoints? or doc on that?
[16:36] <mramm> that bug reportedly has juju destroying nodes it didn't create
[16:36] <mramm> and it is reproducable
[16:36] <mramm> BUT it does require passing --force --yes  to destroy environment on an non-existent environment.
[16:39] <marcoceppi> mramm: having been bitten by this, it's a huge problem
[16:39] <mramm> were you bit by this recently?
[16:40] <marcoceppi> I had a similar issue 10 months ago on MAAS
[16:40] <marcoceppi> issue/experience
[16:40] <mramm> that was a separate issue IIRC
[16:40] <mramm> we added behavior to juju to not kill things it doesn't know about in MAAS
[16:40] <mramm> even if they are by the same user
[16:40] <marcoceppi> ack
[16:41] <mramm> BUT in this case, we can't know about anything as there is no juju server to talk to
[16:42] <mramm> I expect that calling "destroy-environment --force --yes maas" on a non-existent environment to be dangerous
[16:42] <mgz> mramm: this would not be an issue were it not for the fact ever tearing down juju properly requires --force --really --super-hard
[16:43] <mgz> destroy-environment without flags just leaves stuff half-torn down too much of the time to do anything else...
[16:44] <mramm> to fix this we would need to know how to reliably differentiate juju deployed maas instances from those that are not juju deployed.
[16:45] <mramm> the current implication does this -- but requires an active juju state server to talk to (since it knows)
[16:45] <mramm> possibly we could just include maas-agent-name in the config even before we bootstrap
[16:46] <mramm> which isn't 100% reliable (unless we use a GUID for the name)
[17:10] <mup> Bug #1493458 opened: backups restore: fails when machine number differs <juju-core:New> <https://launchpad.net/bugs/1493458>
[17:28] <mup> Bug #1489087 changed: certificate verify failed <juju-quickstart:New> <https://launchpad.net/bugs/1489087>
[17:28] <mup> Bug #1490552 changed: local hostname not in /etc/hosts <juju-core:New> <https://launchpad.net/bugs/1490552>
[17:28] <perrito666> marcoceppi: back, UnitStatusHistory
[17:28] <marcoceppi> thanks perrito666
[17:35] <perrito666> marcoceppi: sorry for the delay
[18:47] <ericsnow> perrito666: could you take a look at http://reviews.vapour.ws/r/2610/?
[18:47] <ericsnow> perrito666: it relates to one of your recent merges
[18:48] <perrito666> ericsnow: did I remove the tests? :|
[18:48] <perrito666> no, that seems like my patch :p did you?
[18:49] <ericsnow> perrito666: I accidentally disabled them in June
[18:49] <perrito666> ericsnow: june? some of the things you are adding are from status-available which is fairly recent
[18:49] <ericsnow> perrito666: your recent patch would not have passed the tests on 1.25 otherwise
[18:49] <perrito666> oh
[18:49] <perrito666> ok
[18:50] <perrito666> ericsnow: can it wait about 1h need to run an errand (bad day for my concentration)
[18:50] <ericsnow> perrito666: right, when you merged from 1.25 you had conflicts and appear to have removed the changes rather than fixing them <wink>
[18:50] <ericsnow> s/from 1.25/to 1.25/
[18:50] <perrito666> ericsnow: In the meantime, is the removal of the huge block from dimitern to begin with?
[18:50] <perrito666> ericsnow: mm damn, ill have to review master too then, thanks for that
[18:51] <perrito666> anyway gtg, bbl
[18:51] <ericsnow> perrito666: don't worry, I'll fix master too
[19:07] <natefinch> you know what bugs the hell out of me?
[19:07] <natefinch> func (c *Settings) <something>
[19:07] <natefinch> c? Really?
[19:15] <perrito666> Ce-tings works in Spanish :p
[19:15] <perrito666> Ericsnow
[19:16] <ericsnow> perrito666: yep
[19:16] <perrito666> So the only thing troubling me is the big chunk from network being removed
[19:16] <ericsnow> perrito666: what is removed?
[19:16] <ericsnow> perrito666: keep in mind that apiserver/params/status.go has everything
[19:20] <perrito666> Ok re reviewed the patch
[19:21] <perrito666> Ericsnow so this patch looks as if re applying the agentversion work for tests can you expand on what happened?
[19:22] <perrito666> And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4
[19:22] <ericsnow> perrito666: your forward-port from 1.24 was missing several changes due to merge conflicts so I added them back in
[19:23] <perrito666> Ahhh duh I see it now, sad
[19:24] <perrito666> And re http://reviews.vapour.ws/r/2610/diff/#4
[19:26] <xwwt__> jog: I will likely miss the meeting today.  Are you cool with running that?
[19:26] <jog> sure
[19:27] <jog> I'm planning to use this sheet as a discussion point: https://docs.google.com/spreadsheets/d/1CWq1CAIYjJLetnageShXVU0-0etxAE2O0KtRgc3-D_8/edit#gid=0
[19:27] <xwwt__> kk
[19:27] <jog> Example of the various issues we see with the charm tests
[19:28] <jog> The point I want to make is that there are many charm related failures that need investigation. Most of these look like charm issues (not infrastructure)
[19:32] <natefinch> you know your tests aren't isolated enough when you change the signature of a method and find 1 place in production code that calls it, and 30 in test helpers.
[19:36]  * TheMue is grumpy about his current network status. from fri to sat total breakdown and today every few minutes *hmpf*
[20:16] <natefinch> man, I hate that juju deploy can't just take config options on the command line, and that if you pass a file to --config, you have to put the charm name in the file, like mysql:  option:value
[20:19] <perrito666> ericsnow: ?
[20:19] <ericsnow> perrito666: yeah
[20:19] <perrito666> ericsnow: sorry I was chatting on a phone, now back to the computer: "And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4"
[20:20] <ericsnow> perrito666: all that code is superflous; it was moved over to apiserver/params/status.go in June
[20:21] <ericsnow> perrito666: looks like you accidentally pulled it back in during a merge
[20:21] <perrito666> ericsnow: then lgtm
[20:21] <ericsnow> perrito666: k
[20:27] <ericsnow> natefinch, katco: could I get a quick review of http://reviews.vapour.ws/r/2610/?
[20:28] <katco> ericsnow: will review before EOD, trying to get tests passing before release standup
[20:28] <ericsnow> katco: k
[20:28] <mup> Bug #1491132 changed: TestNetworkInterfaces fails <juju-core:New> <https://launchpad.net/bugs/1491132>
[20:40] <mup> Bug #1491547 changed: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:42] <natefinch> state's export_test is 443 lines long
[20:43] <mup> Bug #1491547 opened: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:59] <mup> Bug #1491547 changed: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:59] <perrito666> mm, that last one seems to be duplicated
[21:02] <mup> Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:02] <mup> Bug #1325040 changed: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:02] <mup> Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:05] <mup> Bug #1178312 opened: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:05] <mup> Bug #1325040 opened: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:05] <mup> Bug #1492241 opened: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:08] <mup> Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:08] <mup> Bug #1325040 changed: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:08] <mup> Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:32] <xwwt__> sinzui: are you able to join standup?
[22:07] <thumper> wallyworld: holy shit...
[22:07] <thumper> wallyworld: that uniter branch is quite far reaching
[22:07] <wallyworld> it is
[22:08] <wallyworld> doc being worked on now
[22:20] <perrito666> do all worker facades need to be nouns?
[22:20]  * perrito666 thinks we are being a bit exagerated with that
[22:50] <thumper>  wallyworld got time for a quick chat?
[22:51] <wallyworld> sure
[22:54] <wallyworld> thumper: in 1:1


[00:54] <bodhi_zazen> package management 10 min ?
[00:54] <bodhi_zazen> anyone here for packagemanagemt ?
[00:55] <nhandler> o/
[00:56] <d0htem> :o
[00:56] <bodhi_zazen> nhandler: you could probably do better then I in this discussion, so feel free to add in as the time comes :)
[00:59]  * alexbobp manages Daisuke_Ido's package
[00:59] <WastePotato> Wat.
[01:00] <alexbobp> WastePotato: I'm just getting ready for the class
[01:00] <bodhi_zazen> anyone want to see command line stuff with a shared session ?
[01:00] <bodhi_zazen> will save that for the end :)
[01:00] <d0htem> shared ssh?
[01:00] <bodhi_zazen> yes d0htem :)
[01:00] <bodhi_zazen> ssh + screen
[01:00] <bodhi_zazen> First, thank you all for coming
[01:01] <bodhi_zazen> If you have any suggestions for topics, let me know :)
[01:01] <d0htem> !fix jaunty compiz configuration
[01:01] <ubot2> d0htem: Error: I am only a bot, please don't think I'm intelligent :)
[01:01] <WastePotato> ?
[01:01] <bodhi_zazen> https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Education/Proposals
[01:01] <bodhi_zazen> FYI, the long term goal is to establish Ubuntu Education
[01:02] <bodhi_zazen> We have started the Ubuntu Community Learning Project
[01:02] <bodhi_zazen> https://wiki.ubuntu.com/Learning
[01:03] <bodhi_zazen> :)
[01:03] <bodhi_zazen> OK, package management
[01:03] <bodhi_zazen> this session is aimed at new users, although if it is too basic we can get into the nitty-gritty :)
[01:03] <Joeb454> jacob: way to be late
[01:04] <bodhi_zazen> new users are often overwhelmed, and one of the FAQ is how to install things
[01:04] <jacob> Joeb454: it's how the cool kids roll
[01:04] <bodhi_zazen> Should be obvious, but they get caught up in tar balls fast :)
[01:04] <bodhi_zazen> There are many ways of installing software, known as packages
[01:05] <bodhi_zazen> If you are new to Ubuntu, and even if you are not, use the repositories (which we will cover).
[01:05] <bodhi_zazen> The repositories are pre-built binary packages
[01:06] <bodhi_zazen> reference : https://help.ubuntu.com/community/InstallingSoftware
[01:06] <bodhi_zazen> So let's discuss how to install packages using graphical tools :)
[01:06] <bodhi_zazen> I am a BIG fan of Synpatic
[01:07] <bodhi_zazen> https://help.ubuntu.com/community/SynapticHowto
[01:07] <bodhi_zazen> Alternates include "Add/Remove"
[01:08] <bodhi_zazen> although personally I find Add/Remove is not as good as synaptic, especially when searching for packages.
[01:08] <bodhi_zazen> Kubuntu uses Adept - similar comments :)
[01:08] <bodhi_zazen> Add/Remove is in your menu, lol
[01:09] <bodhi_zazen> OK, brief overview / side track :)
[01:09] <bodhi_zazen> Where do packages come from ?
[01:09] <bodhi_zazen> a question every parent dreads :)
[01:10] <bodhi_zazen> Packages come from source code
[01:10] <bodhi_zazen> the source coed is compiled into binaries by the ubuntu developers and the MOTU (over simplification, sorry)
[01:11] <bodhi_zazen> The binaries are stored in the Repositories, or collections of packages
[01:11] <bodhi_zazen> https://help.ubuntu.com/community/Repositories/Ubuntu
[01:11] <bodhi_zazen> Packages have some housekeeping we will not be discussing in detail at the moment
[01:12] <bodhi_zazen> Developers "sign" the packages (security issues)
[01:12] <bodhi_zazen> https://help.ubuntu.com/community/SecureApt
[01:13] <bodhi_zazen> Apt is the "Back end"
[01:13] <bodhi_zazen> Apt is used to track packages and dependencies
[01:13] <bodhi_zazen> A dependency is requirements
[01:14] <bodhi_zazen> for example, say you wish to run Firestarter
[01:14] <bodhi_zazen> (bad example I know)
[01:14] <bodhi_zazen> You need to have (among other things) iptables and X (a graphcial system) as Firestarter is a graphical system
[01:15] <bodhi_zazen> In the good old days, before package management, you would have to find all these dependencies for yourself
[01:15] <bodhi_zazen> Now Apt, and thus apt-get, aptitude, Synaptic, Adept, Add/Remove track all this for you :)
[01:15] <bodhi_zazen> Major advantage of Ubuntu, especially for new users
[01:16] <bodhi_zazen> With me so far ?
[01:16] <bodhi_zazen> So let us return to installing a package foo
[01:16] <bodhi_zazen> Assuming foo is in the Ubuntu Repositories you can install foo with a graphical front end
[01:17] <bodhi_zazen> And all the dependencies will be installed for you
[01:17] <bodhi_zazen> You can use the graphical front end to manage repositories
[01:17] <bodhi_zazen> And remove the package as well
[01:17] <bodhi_zazen> So ... Where does a package go ?
[01:18] <bodhi_zazen> In Windows programs typically go into Program Files, organized by Program
[01:18] <bodhi_zazen> In Linux the files system is organized differently
[01:18] <bodhi_zazen> so ..
[01:18] <bodhi_zazen> the binary itself goes into /bin (or /usr/bin or /sbin ... )
[01:19] <bodhi_zazen> The config files go in /etc
[01:19] <bodhi_zazen> the user files go in $HOME
[01:19] <bodhi_zazen> the man pages go with the other man pages
[01:19] <bodhi_zazen> So if you understand the basics of the Linux File System / tree you know where packages go :)
[01:20] <bodhi_zazen> Overview of the repositories ?
[01:21] <bodhi_zazen> https://help.ubuntu.com/community/Repositories/Ubuntu
[01:21] <bodhi_zazen> When you first install Ubuntu, not all of the repositories are "acitve"
[01:21] <bodhi_zazen> Typically Main
[01:22] <bodhi_zazen> One then adds Restricted Universe and Multiverse
[01:22] <bodhi_zazen> The exact mechanics of adding a repository vary by the tool you are using and is covered in detail here : https://help.ubuntu.com/community/Repositories/Ubuntu
[01:23] <bodhi_zazen> I mention that as one of the other FAQ new users have is what to do when an application is not found in Add/Remove etc
[01:23] <bodhi_zazen> and the most common reason for that is the Universe / Multivers repositories are not active
[01:24] <bodhi_zazen> One can manually activate repositories by editing /etc/apt/sources.list
[01:24] <bodhi_zazen> and removing # at the front of lines or adding lines
[01:24] <bodhi_zazen> Next installing 3rd party applications .deb etc
[01:25] <bodhi_zazen> First, security - do not install application from untrusted sources :)
[01:25] <nhandler> As a note, if you edit /etc/apt/sources.list by hand, remember to run 'sudo apt-get update' to cause your changes to take effect
[01:25] <bodhi_zazen> Second, just because it is a .deb does NOT mean you can install it on Ubuntu
[01:25] <bodhi_zazen> And third, you can not mix and match repositories at will
[01:26] <bodhi_zazen> by that I mean, although Ubuntu is based on Debian , you can not simply add the debian repositories
[01:26] <bodhi_zazen> likewise you can not mix 9.04 repositories with 8.04 :)
[01:27] <bodhi_zazen> If you mix repositories you can try something like pinning : https://help.ubuntu.com/community/PinningHowto
[01:27] <bodhi_zazen> be warned , you can not simply use pinning either, pinning can cause breakage
[01:28] <bodhi_zazen> IMO, rather then using 3rd party .deb or pinning you are best off building from source
[01:28] <bodhi_zazen> I will leave building from source for another day :)
[01:28] <bodhi_zazen> The good news, with the sheer size of the Ubuntu repositories it is rare you need to build from source
[01:29] <bodhi_zazen> I am going to move to command line next
[01:29] <bodhi_zazen> questions about basic packages / dependencies / graphical front ends ?
[01:29] <bodhi_zazen> If not, do you want a demo on a shared ssh session ?
[01:30] <bodhi_zazen> -- Questions please --
[01:30] <d0htem> how do packages get added to repository
[01:30] <bodhi_zazen> depends on the repository
[01:30] <d0htem> why arent they allways uptodate and how can we help, to do that in example nmap
[01:30] <bodhi_zazen> how general are you asking ?
[01:30] <bodhi_zazen> how do you get a package into the repositories ?
[01:31] <d0htem> yes!
[01:31] <bodhi_zazen> Well, in general , a 3rd party application such as nmap => MOTU :)
[01:31] <kklimonda> nmap is in main
[01:32] <st33med> d0htem, submit the package's lp info to a MOTU person, and he might consider it
[01:32] <bodhi_zazen> If the package is in main then it is the Canonical developers
[01:32] <Daisuke_Ido> then there are personal package archives
[01:32] <bodhi_zazen> In general
[01:32] <bodhi_zazen> A package gose through testing
[01:32] <bodhi_zazen> *goes*
[01:32] <jacob> bodhi_zazen: not necessairily canonical, but ~ubuntu-core-dev
[01:32] <bodhi_zazen> Let us use mother Debian as an example
[01:32] <DasEi> man dpkg is a good hint for checking deb's
[01:32] <bodhi_zazen> you have debian stable
[01:33] <bodhi_zazen> those packages are older, and, as the name implies, stable
[01:33] <bodhi_zazen> bugs have been tested and worked out
[01:33] <bodhi_zazen> A new package or version comes along
[01:33] <bodhi_zazen> It goes first into Unstable
[01:34] <bodhi_zazen> people test it and it then goes into testing
[01:34] <bodhi_zazen> as it is further tested it finds it's way into stable
[01:34] <bodhi_zazen> Is that general enough for everyone ?
[01:34] <d0htem> yes thank you very much
[01:34] <bodhi_zazen> Ubuntu takes a snapshot of testing => fixes bugs => release every 6 months
[01:35] <bodhi_zazen> So if you want to help -> participate in testing and bug reports
[01:35] <bodhi_zazen> or join one of the development teams
[01:35] <bodhi_zazen> but is it no simply compile an updated binary and release it :)
[01:35] <st33med> At the time of the final release candidate, all repositories are 'frozen', meaning no major version updates are applied
[01:36]  * st33med just adding two cents
[01:36] <bodhi_zazen> thanks :)
[01:36] <bodhi_zazen> it is a broad question
[01:36] <bodhi_zazen> In general updated packages go through testing before they make it into the repositories
[01:36] <bodhi_zazen> While we are on that subject :)
[01:37] <bodhi_zazen> How often to update your system ?
[01:37] <bodhi_zazen> New users often update daily
[01:37] <st33med> Every five seconds
[01:37] <st33med> :)
[01:37] <bodhi_zazen> just keep in mind , a chance to update is a chance to break
[01:37]  * st33med shuts up
[01:37] <bodhi_zazen> So, before you update :)
[01:37] <bodhi_zazen> 1. Ask yourself, do you need said updated package ?
[01:38] <bodhi_zazen> 2. i look on the forums, are there threads like "todays update broke X" ?
[01:38] <bodhi_zazen> 3. Look at the list of packages to be updated
[01:38] <bodhi_zazen> I advise security updates daily
[01:38] <bodhi_zazen> The rest I do once a week at most
[01:39] <bodhi_zazen> Sometimes , on servers, once every 3 months
[01:39] <bodhi_zazen> >:)
[01:39] <st33med> bad bodhi_zazen
[01:39] <bodhi_zazen> depends on what will happen if an update breaks a system
[01:39] <bodhi_zazen> Desktops do not matter
[01:39] <bodhi_zazen> Servers sometimes do
[01:39] <bodhi_zazen> LOL statik
[01:40] <bodhi_zazen> st33med: :)
[01:40] <st33med> :D
[01:40] <bodhi_zazen> newer is not always better, and sometimes one trades stability for older packages
[01:40] <bodhi_zazen> Of course I update my test installs in a VM daily
[01:40] <bodhi_zazen> but if a VM breaks, no big deal
[01:40] <bodhi_zazen> OK, command line then ?
[01:41] <st33med> Sure \o/
[01:41] <bodhi_zazen> You can update with
[01:41] <bodhi_zazen> apt-get update
[01:41] <bodhi_zazen> apt-get upgrade
[01:41] <bodhi_zazen> If a package is held back, try
[01:41] <bodhi_zazen> apt-get dist-upgrade
[01:41] <Daisuke_Ido> just make sure to cover apt-cache - the single easiest way to search for and get info on packages
[01:42] <bodhi_zazen> You can install a .deb, like say virtualbox, with dpkg
[01:42] <bodhi_zazen> dpkg -i Virtualbox.bed
[01:42] <bodhi_zazen> *deb
[01:42] <bodhi_zazen> That will fail if you have unmet dependencies ...
[01:42] <bodhi_zazen> so ...
[01:42] <bodhi_zazen> apt-get -f
[01:42] <st33med> Usually, the only time you have a held back package is a pinned package or you are in a pre-RC version of Ubuntu
[01:42] <bodhi_zazen> apt-get -f install
[01:42] <bodhi_zazen> will install dependencies , then finish installing VirtualBox
[01:43] <bodhi_zazen> apt-get must of course be run as root , so sudo apt-get ...
[01:43] <bodhi_zazen> or sudo -i
[01:43] <bodhi_zazen> or make an alias :)
[01:44] <bodhi_zazen> For information on packages you have apt-cache (which can be run as a regular user)
[01:44] <bodhi_zazen> apt-cache search foo
[01:44] <bodhi_zazen> will tell you all about package foo
[01:44] <bodhi_zazen> and then there is also dpkg
[01:44] <bodhi_zazen> dpkg -l
[01:44] <bodhi_zazen> will list all installed packages :)
[01:45] <bodhi_zazen> you can also use aptitude, similar to apt-get
[01:45] <bodhi_zazen> aptitude install foo
[01:47] <bodhi_zazen> you can use apt-get to build from source if you like as well :)
[01:47] <bodhi_zazen> it will use the Ubuntu source code, in the deb-src repositories
[01:47] <bodhi_zazen> teh ubuntu source code is often patched :)
[01:48] <bodhi_zazen> apt-get will even handle dependencies for that as will
[01:48] <franki^> is there any advantage to doing that?
[01:49] <bodhi_zazen> In general no franki^
[01:49] <bodhi_zazen> BUT sometimes you need or want to say apply a patch
[01:49] <bodhi_zazen> or modify the source code yourself
[01:50] <bodhi_zazen> nhandler: ??
[01:50] <bodhi_zazen> anything to add ?
[01:50] <st33med> apt-get moo
[01:50] <st33med> :)
[01:50] <bodhi_zazen> We have 10 minutes left and I would like to stop to answer questions ...
[01:51] <bodhi_zazen> This was kind of a lightning overview of package management , lol
[01:51] <st33med> --- QUESTIONS ---
[01:52] <jacob> one thing i would like to point out, universe + restricted are enabled by default on new installs (not sure if multiverse is or not)
[01:52] <wirechief> bodhi_zazen: can you discuss the use of  sudo dpkg --remove --force-depends bar
[01:53] <wirechief> bodhi_zazen: for fixing broken packages
[01:53] <bodhi_zazen> Well, first, when removing a package
[01:53] <bodhi_zazen> you
[01:53] <bodhi_zazen> apt-get remove foo
[01:53] <bodhi_zazen> That *should* remove dependencies
[01:53] <bodhi_zazen> apt-get remove --purge foo
[01:53] <bodhi_zazen> removes foo and config files
[01:54] <bodhi_zazen> but NOT config files in $HOME
[01:54] <bodhi_zazen> Sometimes not all the dependencies are removed
[01:54] <bodhi_zazen> your system will notify you, in which case
[01:54] <bodhi_zazen> apt-get autoremove
[01:55] <bodhi_zazen> Fixing broken packages can be tough :)
[01:55] <d0htem> doesnt apt-get -f do the same as dpkg --remove
[01:55] <bodhi_zazen> I do not think so d0htem
[01:55] <bodhi_zazen> apt-get -f = force or fix broken
[01:56] <DasEi> how do I get the *deb name of a package, let's say firefox ?
[01:56] <bodhi_zazen> apt-cache serarch firefox
[01:56] <st33med> DasEi, it usually has a .deb at the end or some version numbers at the end + a deb
[01:56] <bodhi_zazen> dpkg --remove --force-depends will remove foo and it's depencencies
[01:57] <DasEi> I try to list ff's dependencies, like in this (outdated) sample : dpkg-deb -I packages/firefox_1.5.dfsg+<IP_ADDRESS>-1ubuntu12_i386.deb
[01:57] <bodhi_zazen> apt-cache showpackage firefox
[01:58] <DasEi> ah..
[01:58] <wirechief> i had to use this; alternating with dpkg- --force-depends  packagename  then apt-get -f install  until i finally got all the broken packages removed
[01:58] <d0htem> showpkg?
[01:58] <bodhi_zazen> yes
[01:58] <bodhi_zazen> sorry
[01:58] <bodhi_zazen> apt-cache showpkg firefox                      05/14/09  6:58 PM Package: firefox Versions:  Reverse Depends:   xfig-doc,firefox   webhttrack,firefox   screenlets,firefox   openoffice.org,firefox   nip2,firefox   mozilla-plugin-pcmanx,firefox   mozilla-openoffice.org,firefox   mozilla-nukeimage,firefox   mozilla-noscript,firefox   mozilla-imagezoom,firefox
[01:59] <DasEi> thatdid the trick, thx
[01:59] <bodhi_zazen> Well, if you have broken packages you can be in serious trouble
[02:00] <bodhi_zazen> usually happens when installing 3rd party .deb
[02:00]  * wirechief had a package of bandaids with me
[02:00] <bodhi_zazen> Which gets back to , just because it is a .deb does not mean you should install it :)
[02:00] <wirechief> bodhi_zazen: well this was with using karmic (it will break things atm)
[02:01] <st33med> It could be a Debian .deb and break the system
[02:01] <bodhi_zazen> lol wirechief :)
[02:01] <bodhi_zazen> mixed repositories or pinning ?
[02:01] <bodhi_zazen> Our time is up :(
[02:02] <bodhi_zazen> I hope this was not too fast of an overview
[02:02] <wirechief> bodhi_zazen: actually have done the update-manager -d to get karmic, i am trying to get the leading edge fix
[02:02] <wirechief> for my intel
[02:02] <bodhi_zazen> package management can get complicated fast
[02:02] <bodhi_zazen> Ah :)
[02:02] <DasEi> was more then that, nice
[02:03] <wirechief> bodhi_zazen: i am basically testing freeze issues with intel and giving as much feedback to the people who are tracking the bug
[02:04] <bodhi_zazen> The intention of these sessions is education and if you all have a topic please add it to the list
[02:04] <bodhi_zazen> https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Education/Proposals
[02:04] <wirechief> bodhi_zazen: thank you for your classroom session i plan on saving if for future references..
[02:04] <bodhi_zazen> Obviously we can talk a whole hour on some of these topics :)
[02:05] <bodhi_zazen> we could do a session on installing from source :)
[02:05] <wirechief> ;)
[02:05] <bodhi_zazen> a whole session on testing / adding packages to Ubuntu , etc
[02:05] <st33med> bodhi_zazen, from a .tar or repository? Or both?
[02:06] <bodhi_zazen> i was thinking both statik
[02:06] <bodhi_zazen> st33med: :)
[02:06] <st33med> :D
[02:06] <d0htem> auto-complete for the lose :p
[02:06] <bodhi_zazen> first from repositories
[02:06] <bodhi_zazen> then resolving dependencies
[02:06] <bodhi_zazen> foo-dev
[02:06] <bodhi_zazen> build-essential
[02:06] <bodhi_zazen> and then .tar.gz
[02:07] <bodhi_zazen> of course that leads to things like gcc ... >:)
[02:07] <bodhi_zazen> OK, meet again in 2 weeks
[02:07] <bodhi_zazen> I shall consider installing form source unless there are other suggestions :)
[02:08] <bodhi_zazen> nhandler: sorry if I botched package management too much :)
[02:08] <nhandler> No, you did a very nice job bodhi_zazen
[02:08] <st33med> It's my fault XD
[02:08] <d0htem> installing from source!! plz
[02:08] <wirechief> bodhi_zazen:  i would like to see a course on compiling alsa driver  for sound, many need updated drivers for their sound to work after upgrading or installing ubuntu new.
[02:08] <nhandler> It is difficult explaining package management in simple language
[02:09] <bodhi_zazen> OK next session - to the source :)
[02:09] <bodhi_zazen> I have to run, family time :)
[02:09] <bodhi_zazen> thank you everyone
[02:10] <wirechief> thanks bodhi_zazen
[02:10] <st33med> Say hey to the kiddos :D
[02:10] <bodhi_zazen> I think I need to bite off smaller topics and leave more time for questions :p
[02:10] <wirechief> ;)
[02:10]  * st33med thinks about setting up a Python tutorial again...
[02:10] <d0htem> to hell with py!
[02:10] <st33med> HISSS
[02:11] <d0htem> .rb for the win
[02:11] <st33med> .py ftw
[02:11] <d0htem> die
[02:11] <st33med> no u
[02:17] <Daisuke_Ido> nice one st33med, you killed him.
[02:17] <st33med> yay
[02:50] <witcher> what is this room for? classes or queations
[02:50] <perlluver> classes mainly, I believe
[02:50] <witcher> oh ok ty
[02:50] <perlluver> yw
[02:50] <witcher> do you know what kind of classes
[02:51] <perlluver> a little bit of everything
[02:51] <perlluver> https://wiki.ubuntu.com/Classroom
[02:51] <witcher> kk
[02:51] <perlluver> that might explain it better
[02:51] <witcher> k ty again
[02:51] <perlluver> no problem
[02:51] <witcher>  i just installed ubuntu 2 days ago lol
[02:52] <perlluver> ah, congrats
[02:52] <witcher> so far i like it better than xp
[02:52] <witcher> ty
[02:52] <witcher> its just so differant
[02:52] <perlluver> it is
[02:52] <perlluver> you will get used to it eventually
[02:52] <witcher> i am running dual OS
[02:52] <witcher> i hope so
[02:52] <perlluver> that is good
[02:53] <witcher> i run xp for gamming lol
[02:53] <perlluver> if you don't like it you can always go back
[02:53] <witcher> true
[02:53] <perlluver> I used to, but I have been all Linux for about 3 years now
[02:53] <witcher> wow
[02:53] <perlluver> yeah it has been a fun ride
[02:53] <witcher> this installing is mostly waht gets me stuck
[02:54] <witcher> its differant
[02:54] <perlluver> it got me at first, but I have tried so many systems, that I can install without blinking now
[02:54] <nhandler> You guys might want to move this conversation to a different channel
[02:54] <perlluver> sorry nhandler
[02:54] <witcher> sorry
[02:55] <witcher> ty for the link perl
[02:55] <perlluver> yw


[06:50] <Flohack> Unit193: Yes I pinged but no response =) Give me 1, 2 days for that, we are swamped with things to do...
[06:52] <Unit193> OK, great.  Will do. :)


[06:40] <jam> morning all
[08:15] <gnuoy> Hi, I'd like charmcraft to include the charms readme in the built charm, which it doesn't seem to do at the moment. Is there anyway to do that ?
[08:18] <gnuoy> hmm, looking at the code that looks like a 'no'
[08:47] <jam> gnuoy, currently no, we are working on a patch that will change charmcraft to use '.jujuignore' to figure out what it will omit, and include everything else (matching the way 'juju deploy' does it today)
[08:47] <jam> gnuoy, so in the next release, that would change, but currently there isn't a way to tweak it
[08:48] <gnuoy> jam, ack, thanks. I raised https://github.com/canonical/charmcraft/issues/108 to track it
[08:51] <jam> morning Chipaca
[08:54] <Chipaca> jam: 節뉛퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐦節륅퐚  節랃퐦節믭퐥節됵퐥節뉛펯
[08:54] <Chipaca> :)
[08:54] <jam> Chipaca, that's a very good morning
[08:55] <Chipaca> jam: you have been blessed by the gods of $RANDOM
[08:55] <jam> Chipaca, ahh
[08:56] <bthomas> morning all
[08:56]  * bthomas wondering how Chipaca types all those unicode fonts
[08:57] <jam> bthomas, I'm sure its a script, but I like to think he has a second keyboard
[08:57] <bthomas> or a spare set of fingers
[08:58] <Chipaca> jam: indeed, https://github.com/chipaca/bin/blob/master/beuno
[08:58] <Chipaca> if it's the unicode side of that that you found interesting though, snap install unifonter
[08:58] <bthomas> ah
[08:59] <jam> Chipaca, 2-512, thats... aggressive
[08:59] <Chipaca> nah, $RANDOM only goes to 32767
[08:59] <Chipaca> so it's to 63
[09:19] <jam> Chipaca, just checking that you're aware of the meeting in 30min. It showed up on my calendar earlier today.
[09:20] <Chipaca> jam: ack
[11:02] <facubatista> 징Muy buenos d챠as a todos!
[11:28] <jam> hi facubatista
[11:29] <jam> I think one of the release changes are that test suites should probably start calling Harness.cleanup()
[11:29] <facubatista> hola jam
[13:32] <Chipaca> jam: standup?
[14:08] <Chipaca> bthomas: fixed unifonter, thanks for the report
[14:09] <bthomas> Awesome Chipaca, will redownload and flood this place with unicode goodness
[14:14] <jam> Chipaca, reviewde
[14:16] <Chipaca> bthomas: actually, that was a mistake. Now _really_ fixed :)
[14:17] <bthomas> :-) lucky I haven't checked it yet.
[14:17] <Chipaca> jam: thanks!
[14:22] <jam> Chipaca, I sent you some thoughts on how to have the docs for 0.8 changes.
[14:22] <jam> The examples are a bit weak, so if you feel it is better to omit them, feel free
[14:23] <Chipaca> weak > none, most of the time
[14:23] <Chipaca> bah; weak > none for strong values of weak
[14:25] <jam> :)
[14:38] <facubatista> Chipaca, meeting?
[14:44] <Chipaca> facubatista: nah
[14:44] <facubatista> :)
[14:45]  * Chipaca pats ChanServ
[15:39] <mup> Issue operator#362 closed: Create symlinks when Juju version doesn't support dispatch <Created by gnuoy> <Closed by chipaca> <https://github.com/canonical/operator/issues/362>
[15:39] <mup> PR operator#366 closed: version-check to determine dispatch support <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/366>
[16:51] <mup> Issue operator#367 opened: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/367>
[17:36] <facubatista> charmcraft 0.3.1 released!
[17:36] <facubatista> jam, Chipaca, https://github.com/canonical/charmcraft/pull/110
[17:36] <mup> PR charmcraft#110: Release 0.3.1, and improvements in the procedure <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/110>
[18:09] <mup> Issue operator#111 closed: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/111>
[18:38] <Chipaca> 0.8.0 is out :-)
[20:33]  * facubatista eods
[21:26] <alejdg> Hey folks, is there a way to block relation-broken or relation-departed when a pod/unit is replaced?


[00:53] <theunixgeek> When's the next meeting?
[00:54] <somerville32> @schedule
[00:54] <ubotu> Schedule for Etc/UTC: 20 Dec 14:00: Desktop Team Development | 21 Dec 12:00: MOTU meeting | 02 Jan 12:00: Edubuntu meeting | 09 Jan 20:00: Edubuntu meeting | 10 Jan 14:00: Desktop Team Development | 16 Jan 12:00: Edubuntu meeting
[00:54] <theunixgeek> what's the current UTC time?
[00:56] <The-Kernel> 23:58
[00:56] <The-Kernel> I think
[00:56] <The-Kernel> not sure
[00:57] <somerville32> Pretty sure it is 00:58
[01:00] <pochu> @now
[01:00] <ubotu> Current time in Etc/UTC: December 20 2007, 01:00:31 - Next meeting: Desktop Team Development in 12 hours 59 minutes
[01:03] <theunixgeek> thanks
[09:28] <kraut> moin
[13:56] <Keybuk> tedg: morning
[13:57] <tedg> Keybuk: good afternoon.
[14:00] <Keybuk> mvo_, Riddell: ping
[14:00] <Riddell> hi Keybuk
[14:02] <pitti> hi
[14:02] <pitti> argh, sorry
[14:03] <Keybuk> ok, let's get going
[14:03] <Keybuk> mvo's client is here, but no life there yet
[14:03] <MacSlow> :)
[14:04] <Keybuk> did I miss any agenda items?
[14:04] <Keybuk> I didn't see any
[14:04] <pitti> I read the reports so far, didn't see any either
[14:05] <MacSlow> same here
[14:05] <Keybuk> does anyone have anything they want to discuss? :)
[14:05] <Keybuk> no?
[14:05] <pitti> we still have some merges left
[14:06] <MacSlow> nope
[14:06] <Keybuk> pitti: there's always some left ;)
[14:06] <pitti> but they are all pretty platformish
[14:06] <Keybuk> Debian won't stop changing things
[14:07] <seb128> hey
[14:07] <Keybuk> in that case, let me just wish you all a happy holidays
[14:07] <pitti> hey seb128
[14:07] <MacSlow> hi seb128
[14:07] <Keybuk> there's a button on your computer you may not have used before
[14:07] <seb128> oh, was a short meeting apparently? ;-)
[14:07] <Keybuk> it's marked "OFF" or maybe "Power"
[14:07] <pitti> seb128: do you know whether the remaining 20 merges have an assignee, or are they fair game?
[14:07] <seb128> pitti: let me look to the list
[14:07] <Keybuk> pitti: we're after freeze now, so they need RM approval, no?
[14:08] <pitti> Keybuk: no, why that?
[14:08] <pitti> we can continue merging and introduce new versions until FF
[14:08] <tedg> Oh, from people commenting on "exit-strategy" I know that no one uses that button, they expect them all to be in menus ;)
[14:08] <seb128> pitti: not sure about all of those, libgnomemm2.6 has been synced, libbtctl has a sync request open I think, python-distutils-extra should not be listed
[14:08] <Keybuk> Just a brief note to remind you all that the DebianImportFreeze[1] for Hardy
[14:08] <Keybuk> is two days away[2].  This is the deadline for initial merges of packages
[14:08] <Keybuk> for Hardy; after Thursday, December 13, merging packages is a freeze
[14:08] <Keybuk> exception, so please have your remaining merges for hardy finished before
[14:08] <Keybuk> this point.
[14:08] <seb128> not sure about the other ones
[14:08] <pitti> hm, that's not our usual definition of DIF
[14:09] <pitti> 'deadline for initial merges' is correct, of course
[14:09] <pitti> but DIF is just about stopping the autosyncs
[14:09] <Keybuk> it may be that steve is trying something different
[14:09] <seb128> tedg: hi, will you do the gnome-power-manager 2.21.1 update?
[14:10] <pitti> Keybuk: hm, we better ask him about that then; https://help.ubuntu.com/community/DebianImportFreeze should be updated if there are policy changes
[14:10] <tedg> seb128: Yes.  I was going to do 2.20.2 also, or no point?
[14:10] <seb128> pitti: when is UVF now? at the same time as UVF or DIF?
[14:10] <seb128> tedg: no point, we can have only 1 version in hardy
[14:10] <seb128> tedg: and we don't do GNOME 2.20.2 updates to gutsy
[14:11] <pitti> seb128: UVF doesn't exist any more; it's just FF now
[14:11] <tedg> seb128: Okay.
[14:11] <pitti> https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess#head-e10e11c208ca4b6fda2649cd18e983ba6dac635d
[14:11] <seb128> pitti: right, I would not have asked otherwise :-P Ok, my question was "can we still upload new version", and you replied, thanks ;-)
[14:11] <tedg> There's an odd battery problem that bdmurray and others are reporting.  Apparently HAL is reporting on more batteries now, I think they might be BIOS batteries.
[14:12] <seb128> pitti: this page is confusing because nothing mention "no new version"
[14:12] <pitti> seb128: deliberately
[14:12] <seb128> pitti: which means there is no point we stop updates or need an approval?
[14:12] <pitti> seb128: in fact new upstream versions are ok until release freeze as long as they just fix bugs
[14:13] <pitti> seb128: well, it is ok according to the currently documented policy
[14:13] <pitti> if Steve wants to change that, we should talk to him about announcing it and changing the docs
[14:13] <seb128> ok
[14:13] <seb128> I'm fine with that
[14:13] <seb128> less work for me -;)
[14:13] <Keybuk> tedg: it also reports on batteries of things like mice and phones
[14:14] <Keybuk> when I connect to my phone with gnome-phone-manager, gnome-power-manager tells me what it's battery state is
[14:14] <Keybuk> (arguably these should be different icons, but meh -> Ubuntu 10.04)
[14:15] <tedg> Yeah, but it's a little odd that gutsy wouldn't have it and hardy would.
[14:16] <Keybuk> gutsy did that too, no?
[14:16] <Keybuk> anyway, let's officially adjourn the meeting and carry on conversations if we want ;)
[14:16] <tedg> Gutsy did it, but the bug report is that people had one battery in gutsy and two in hardy.
[14:17]  * mvo_ coughs
[14:17] <pitti> tedg: since our hal didn't change significantly, this might be due to the new kernel now reporting those batteries in /sys, too?
[14:18] <tedg> pitti: Good to know, they're not in /proc under ACPI.  So I'm thinking they're hiding somewhere else.
[14:18] <pitti> oh, or /proc; not sure
[14:19] <tedg> I think it's funny, I don't know why people are complaining about us adding batteries for them ;)
[14:20] <cjwatson> Keybuk: I checked with Steve about that DIF mail
[14:20] <cjwatson> he misspoke
[14:20] <cjwatson> he didn't intend to change the existing practice; read it as "merging packages that have not been merged yet is a freeze exception"
[14:20] <cjwatson> pitti,seb128: ^--
[14:21] <Keybuk> cjwatson: ah, thanks for the clarification
[14:21]  * mvo_ appologizes for not responding at the start of the meeting, he was reshuffling his harddisks in the upgrade test machine for better cooling
[14:21] <cjwatson> "Yes, sorry for failing to convey this nuance.  I'm not meaning to propose
[14:21] <cjwatson> any changes to this policy.
[14:21] <pitti> cjwatson: so merging one the first time is an exception, and a further merge isn't?
[14:21] <Keybuk> tedg: the extra battery status is a new feature, no? :)
[14:21] <cjwatson> "
[14:21] <cjwatson> pitti: as before
[14:21] <cjwatson> pitti: otherwise "all initial merges must be completed by DIF" would have no force :)
[14:22] <pitti> it just doesn't seem to be encouraging to finish them off
[14:22] <pitti> but good to know, I wasn't aware of that interpretation
[14:22] <cjwatson> they should have been finished before the deadline; if they aren't done, then we need to consider whether it's worthwhile to bother
[14:22] <cjwatson> -> freeze exception
[14:22] <pitti> ok
[14:23] <cjwatson> Keybuk: turning off the computer during holidays would interfere with playing nethack
[14:23] <Keybuk> playing nethack would interfere with your marriage ;)
[14:24] <cjwatson> :-)
[14:24] <cjwatson> (mind you, hasn't done that much yet)
[14:27] <mhb> hello, it is a bit silent now, could I please ask a question? I have heard about a decision on Kubuntu not being a LTS. Who did make such a decision and are we going to read any official information about this? Sorry if I am bothering.
[14:30] <MacSlow> mhb, really? If that's true, I did miss that.
[14:31] <MacSlow> mhb, Riddell should know I think
[14:31] <mhb> MacSlow: he suggested me to ask here. He does not have much information either, it seems.
[14:31] <MacSlow> *shrugg*
[14:35] <MacSlow> mhb, that question seemed to have "killed" the meeting :)
[14:35]  * mvo_ has no idea about this
[14:36] <seb128> I know there was some discussions about KDE4
[14:36] <seb128> it'll not be lts quality
[14:36] <seb128> but I don't know if they decided anything there
[14:37] <mvo> I will try to make sure that dapper->hardy upgrades (with text/gtk frontend) will work for kubuntu
[14:37] <mvo> but I guess that is not really related :)
[14:38] <mhb> seb128: we have not planned to ship KDE4 as default.
[14:39] <mhb> mvo: it is not really related, but definitely appreciated!
[14:41] <pitti> Keybuk: do you know something about the LTSishness decision?
[14:41] <Keybuk> I know lots of things
[14:42] <Keybuk> which thing that I know would you like to know?
[14:42] <Keybuk> :-)
[14:42] <Keybuk> ah, Kubuntu LTS
[14:42] <Keybuk> Riddell: have you announced anything there yet?
[14:43] <Riddell> I have not
[14:43] <Keybuk> ok; when are you planning on sending something out?
[14:44]  * Hobbsee thinks people have already found out
[14:45] <Riddell> Keybuk: I have no plans
[14:45] <Keybuk> Riddell: since people are asking, soon might be a good time :-)
[14:46] <Riddell> Keybuk: I don't really have anything to say
[14:47] <Hobbsee> Riddell: it's therefore the kubuntu council's decision on where to go from here, w.r.t kubuntu hardy, then?
[14:47]  * Hobbsee would ahve thought that was worth saying
[21:35] <theunixgeek> @now
[21:35] <ubotu> Current time in Etc/UTC: December 20 2007, 21:35:18 - Next meeting: MOTU meeting in 14 hours 24 minutes
[21:35] <theunixgeek> Why is every meeting in a bad time for me :(
[21:35] <theunixgeek> lol just kidding
[21:38] <somerville32> lol


[03:01] <lotuspsychje> good morning
[07:15] <ducasse> good morning
[07:22] <lordievader> Good morning


[00:04] <xnox> tjaalton:  Laney: i have no idea! also weird! and thank you for the reject.
[00:04] <xnox> will re-upload.
[08:05] <juliank> Laney, sil2100 Seems we're still hitting the issue where autopkgtest installs unattended-upgrades from release rather than updates.
[08:06] <juliank> It triggered 0.90 for python-apt/1.1.0~beta1ubuntu<IP_ADDRESS>
[08:06] <juliank> last known good was May 6; python-apt/1.1.0~beta1ubuntu<IP_ADDRESS> triggering 1.1ubuntu<IP_ADDRESS>~16.04.2
[08:06] <juliank> rbalint: ^
[08:09] <Laney> juliank: sorry, what is the problem in more detail?
[08:10] <juliank> Laney: unattended-upgrades in xenial is 0.90, xenial-updates has  1.1ubuntu<IP_ADDRESS>~16.04.3
[08:10] <juliank> Laney: All new tests are triggering 0.90
[08:10] <juliank> That makes no sense, as it does not happen for other stuff
[08:10] <juliank> AFAICT
[08:11] <juliank> even security has 0.90ubuntu0.10
[08:13] <juliank> autopkgtest [17:04:49]: @@@@@@@@@@@@@@@@@@@@ apt-source unattended-upgrades
[08:13] <juliank> Get:1 http://ftpmaster.internal/ubuntu xenial/main unattended-upgrades 0.90 (dsc) [1,766 B]
[08:13] <juliank> like, this should already be pulling from -updates
[08:14] <Laney> yeah OK, and there is other stuff being fetched from -updates in there
[08:14] <juliank> Hang on a sec
[08:15] <juliank> cjwatson: xenial-updates is broken
[08:15] <juliank> cjwatson: Packages that should be in there are not
[08:16] <juliank> Laney: Do we have -security disabled on autopkgtest?
[08:16] <juliank> That + broken -updates pocket would explain why it fetches from release
[08:17] <juliank> cjwatson: So, rmadison unattended-upgrades:  unattended-upgrades | 1.1ubuntu<IP_ADDRESS>~16.04.3 | xenial-updates   | source
[08:17] <juliank> no binary in archive
[08:17] <juliank> Seems like we probably have more issues with apt-ftparchvie than we realized, and need to regenerate all the dbs
[08:18] <juliank> as that's across all architectures
[08:18] <Laney> https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades/
[08:19] <juliank> Huh
[08:19] <juliank> hmm
[08:19] <Laney> not sure re: security, that's not my intention but it could be
[08:20] <juliank> rbalint: the unattended-upgrades binary in xenial-updates was removed on may 7th
[08:20] <juliank> um may 8th
[08:21] <juliank> Laney: But do we know why it was removed, or who removed it?
[08:21] <apw> Laney, its not showing removed in the primary publishing list
[08:21] <juliank> Laney: Log says it superseded itself?
[08:22] <juliank> This is very odd
[08:22] <Laney> sorry, I can't decipher all of this stuff
[08:23] <juliank> apw: only binary was removed, not source
[08:23] <apw> but only the source is published
[08:23] <Laney> there is a bug where binaries eat themselves if something is copied twice in the same publisher run, not sure if that manifests itself in the publishing history like this
[08:24] <juliank> apw: Can you fix that up and like copy back the binary into updates?
[08:24] <Laney> copy-package --from=ubuntu --from-suite=xenial-updates --to=ubuntu --to-suite=xenial-updates --version=1.1ubuntu<IP_ADDRESS>~16.04.3 --include-binaries --force-same-destination unattended-upgrades
[08:24] <apw> Laney, yeah, that could be, i think a copy over self is worth a try here and let cj-watson et al work out if there are any others
[08:24] <Laney> probably something like that would recover it
[08:24]  * apw will give it a go
[08:25] <juliank> thanks Laney, apw
[08:25] <juliank> Makes me wonder how we can ensure this does not happen again
[08:26] <Laney> if it's that LP bug then it's well known
[08:26] <juliank> or well, a better way to discover it
[08:26] <apw> normally when these things are suspected log magic is applied
[08:26] <juliank> I guess I could write a cron job that goes through -updates and looks for missing builds
[08:26] <juliank> run that once a day and have it send an email
[08:27] <juliank> s/missing builds/built packages missing/
[08:29] <apw> juliank, perhaps, or i wonder if teh superceeded by self is an indicator here
[08:29] <Laney> juliank: as for missing -security, it's probably https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
[08:29] <juliank> ack
[08:29] <apw> juliank, or actually the 'latest' status being superceeded which seems impossible in and of itself
[08:30] <juliank> apw: Yeah, that makes sense I guess. I guess with access to the database, it should be easy to write up a report for all binaries whose latest state is superseded
[08:31] <juliank> but it's probably hilariously slow as I guess there's no index on the status field :)
[08:31] <apw> i suspect it can be done via the api all be it slowly
[08:32] <juliank> Well, one query per binary is a ton of queries
[08:33] <juliank> but I guess it's only problematic on the first run
[08:33] <juliank> like we can cache status for a random time so we re-check versions we've seen before eventually but not all the time
[08:34] <apw> juliank, you can get all binaries together for a source, and in the right order that the first should always be published or deleted i believe
[08:35] <apw> (well or pending, or no records all being good in this context)
[08:37] <juliank> I wonder if it's faster to just load Sources and Packages files and then look if a given source package has binaries in the Packages file. The only API calls we then need are "which architectures did this build on?"
[08:38] <juliank> and we can indefinitely cache those API calls
[08:38] <cjwatson> I'll look after meetings
[08:39] <cjwatson> no index on the status field> what planet do you think we live on
[08:40] <apw> the publisher presumably uses that field rather heavily
[08:40] <juliank> ok
[08:40] <juliank> hey, I was just guessing, I don't have a launchpad checkout handy
[08:41] <juliank> Oh, I do have one
[08:41] <juliank> silly me
[08:42] <juliank> I should continue my Valid-Until branch
[08:44] <cjwatson> Looks like phased updates ate it in this case
[08:46] <apw> juliank, ok the re-copy has published; so the binaries ought to be back
[08:47] <juliank> $ curl -s http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.xz | xzcat  | grep-dctrl -P unattended-upgrades | wc -l
[08:47] <juliank> 0
[08:47] <juliank> unattended-upgrades | 1.1ubuntu<IP_ADDRESS>~16.04.3 | xenial-updates   | source
[08:48] <juliank> rmadison and archive.u.c don't know about it yet
[08:48] <cjwatson> Packages/Sources queries will be fatally flawed because deliberate removals are sometimes a thing
[08:49] <apw> cjwatson, removals would express as deleted though right?  and this was expressing as Superceeded
[08:49] <juliank> cjwatson: Oh right, I was thinking if we remove the SRU, we'd copy back the security one; but I'm not sure we do, and there's not always one available.
[08:49] <cjwatson> Superseded
[08:49] <cjwatson> please
[08:50] <cjwatson> apw: Right, but that distinction does not show up in Packages/Sources files which is what juliank was talking about querying in isolation
[08:50] <juliank> apw: Yes, but you don't see that in Packages files, which I was considering as a faster alternative to API calls
[08:50] <apw> juliank, ahh but might it give you a subset to then check via the api
[08:50] <cjwatson> juliank: I don't know why you would consider this problem for <stable>-updates and nowhere else
[08:51] <juliank> cjwatson: Oh, I do consider it a problem elsewhere, but that's harder to solve efficiently
[08:51] <cjwatson> And anyway I'm not talking about removing the entire source, but about removing individual binaries from it, which happens
[08:52] <juliank> So yeah, I guess we do need to check the launchpad status
[08:52] <juliank> * publisher status
[08:52] <apw> cjwatson, in this case the binary itself was showing superseded
[08:52] <cjwatson> Yes, I know
[08:52]  * apw shuts up :)
[08:52] <cjwatson> I'm saying that you can't spot the vanished-binary problem just from published indexes, because individual binaries from a source can be deliberately deleted
[08:53] <cjwatson> (And it would be incorrect to make the assumption that *all* binaries from a given source vanish when this bug is triggered)
[08:54] <juliank> So should we wait more or is it safe to conclude that copying it back did not work?
[08:54] <cjwatson> I'm afraid grepping logs in this case is not going to be useful, because it was a double-override and overrides aren't well-logged
[08:54] <cjwatson> juliank: copying works
[08:54] <cjwatson> You can see it in https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades
[08:54] <apw> juliank, the launchpad side says it is back
[08:55] <juliank> I see it there, sure, I'm just waiting for it to be back in rmadison :)
[08:56] <cjwatson> Publishing is not terribly instant
[08:56] <cjwatson> It'll get there
[08:57]  * juliank adds a watch -n60
[08:57] <juliank> Gotta retry some autopkgtests once it's there :)
[08:58] <cjwatson> apw: Superseded-by-self is valid because that's how overrides work
[08:58] <apw> cjwatson, would there then not be a further Pending/Published record after ?
[08:58] <cjwatson> Sure, but that's harder to check :)
[08:59] <cjwatson> If we can work out the correct logic then we might just as well fix the actual dominator bug rather than writing complicated workaround monitoring scripts
[09:01] <juliank> it has arrived :)
[09:26] <apw> i think i just had unattended-upgrades try and upgrade itself; and it did not go well
[09:45]  * cjwatson tries to understand the dominator
[09:46] <cjwatson> It looks correct ...
[09:46] <cjwatson> I guess I could try setting up a matching situation in the test suite though
[09:51] <LocutusOfBorg> anybody, please hit gazebo! autopkgtest for gazebo/9.6.0-1build1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Pass, ppc64el: Regression ♻ , s390x: Always failed
[09:51] <LocutusOfBorg> it fails on arm64, armhf, ppc64el because the binary doesn't exist there anymore...
[09:51] <LocutusOfBorg> (and it won't exist for long time, hopefully never)
[10:25] <cjwatson> Oh
[10:25] <cjwatson> Is it that easy
[10:37] <LocutusOfBorg> isn't it?
[10:37] <cjwatson> I mean the double-override bug
[10:38] <apw> cjwatson, oh cornered it by accident ?
[10:38] <cjwatson> Well not so much by accident, I was aiming at it
[10:39] <cjwatson> But it actually looks quite easy now that I've narrowed it down
[10:40] <cjwatson> I'll run some more tests though
[10:41]  * apw hands cjwatson a snap-trap ...
[10:41] <cjwatson> We've only ever seen this on arch: all binaries, right?
[10:41] <cjwatson> Those are all the examples I can find in remotely-recent IRC history, at least
[10:44] <apw> cjwatson, i don't think i remember in enough detail
[10:50] <LocutusOfBorg> oh... it wasn't an answer to me lol, I just figured it out
[10:52] <cjwatson> Yeah, sorry, overlapping conversations
[12:15] <LocutusOfBorg> its me being sorry, I thought the conversation was over, after some minutes of idling :)
[12:16] <LocutusOfBorg> force-badtest gazebo/all/arm64 gazebo/all/armhf gazebo/all/ppc64el <-- please because NBS there
[17:35] <bdmurray> cpaelzer: bug 1819207 is in the Launchpad-Bugs-Fixed for open-vm-tools in the cosmic unapproved queue so that bug will get modified. Is that what you want?
[17:46] <bdmurray> tsimonq2: Can you add ubuntu package tasks and test cases for bug 1530697, bug 1744861, bug 1789059, bug 1805559
[17:55] <vorlon> Laney: nothing's been done that would turn off updating of autopkgtest indices for trusty, has it?  I was looking for new test results on http://autopkgtest.ubuntu.com/packages/l/lxc/trusty/ppc64el and http://autopkgtest.ubuntu.com/packages/g/glib-networking/trusty/ppc64el (et al) to see what gnutls26's state actually is
[17:55] <vorlon> and the test results haven't shown
[19:44] <Trevinho> hey, bdmurray could you have a look at the mutter/gnome-shell SRU, as it's waiting for some weeks now (as previous package was there before than the re-upload). Thanks :)
[19:46] <bdmurray> Trevinho: For what release?
[19:46] <Trevinho> bionic
[19:46] <bdmurray> I'll have a look
[20:25] <bdmurray> Trevinho: bug 1827029 is missing mutter tasks
[20:25] <Trevinho> bdmurray: fixed
[20:25] <Trevinho> and thanks for looking into this
[20:26] <bdmurray> Trevinho: was d/p/clutter-Smooth-out-master-clock-to-smooth-visuals.patch superseded by daniel's other changes?
[20:27] <Trevinho> bdmurray: yes
[20:28] <Trevinho> bdmurray: here's the rationale https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=05baba0d0a78775f18d9e16e8f7d074bcbe86cf5
[20:38] <bdmurray> Trevinho: also the NEWS file lists a fair number of changes were those part of 3.28.3+git20190124?
[20:39] <Trevinho> bdmurray: yes, basically is almost the same. However since upstream did a new release, we decided to merge with it
[20:41] <Trevinho> bdmurray: these are the changes from git version to 3.28.4 in mutter https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=becbb8ffd09d9fd6b1ee38505ad21560c5fdb226 and shell https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell/commit/?h=ubuntu/bionic&id=c04b315d13b603743f2ae84a009cc900568674ed
[20:41] <Trevinho> as you can see, a part the autotools stuff there's not much change


[22:34] <doctormo> highvoltage: Yep, everything is great, nothing to worry about. Just artwork.
[22:39] <highvoltage> doctormo: wow that's some latency you got there :)
[22:39] <doctormo> highvoltage: Sorry my friend, riding on high
[22:40] <highvoltage> np!
[23:25] <doctormo> highvoltage: How have you been?
[23:35] <highvoltage> doctormo: good! had some toothache but nothin the dentist couldn't sort out :)
[23:35] <doctormo> highvoltage: Want to see something sweet? http://doctormo.deviantart.com/art/Computers-are-Magic-Too-212790815
[23:36] <highvoltage> heh, nice


[00:48] <pleia2> send uwn doc off to summary writers
[19:04] <imnichol> Whoa, someone really hammered the UWN
[19:05] <imnichol> I was so excited to write some summaries, but I got beat to the punch ;)
[19:07] <PaulW2U> and the most difficult ones get left to last :)
[19:10] <imnichol> PaulW2U, That's my strategy hahah
[19:11] <imnichol> Actually, do you know if the google doc is available before Fridays?  Friday/Saturday/Sunday is my prime drinking/cleaning time.  I think I'd be much more effective if I could sit down and write a summary a night all week
[19:11] <imnichol> As opposed to trying to do it hung over on Saturdays ;)
[19:12] <PaulW2U> Yes, it's available all week but anything written before pleia2's email may be deleted
[19:13] <PaulW2U> We may have to amalgamate articles into a list if there are too many - like the phone this week


[19:05] <rick_h_> gotta love it http://techcrunch.com/2012/10/06/evolution-and-big-bang-are-lies-says-congressman-from-house-committee-on-science/
[19:58] <noogenesis> https://gist.github.com/3831430
[20:06] <noogenesis> http://rosettacode.org/wiki/Y_combinator#C <devil-laugh>
[20:15] <noogenesis> idea : stack overflow like site, but tweaked instead of "question answer" , to work well for "request for tips" ... like if your question is "what is the best way to ...." and will probably get closed on SE
[20:15] <noogenesis> post-tips
[20:16] <noogenesis> stack overflow overflow
[21:48] <derekv> just looked at some comparitive benchmarks for haskell that makes it much more attractive as a language for practical application
[22:04] <Blazeix> derekv: some of that stack overflow stuff could be covered by: http://codereview.stackexchange.com/
[22:43] <derekv> http://services.sos.state.mi.us/plates/papstep2.asp?plateType=STANDARD&plateID=bluebar&hndCap=false&t1=H&t2=A&t3=X&pcPlt=PPI;HAX&manPlate=HAX%20%20%20%20&vtype=&ptrn=AAA
[22:43] <derekv> my add is on max overdrive today
[22:45] <derekv> Blazeix: codereview ... cool thanks
[22:45] <derekv> yea that would cover some stuff
[23:00] <snap-l> Evemomg
[23:00] <snap-l> evening, too. :)
[23:04] <snap-l> rick_h_: That depresses me (the congressperson as head of science)
[23:39] <derekv> so would the personalized license plate "hax" be cool or does that spelling have paticular negative connotations
[23:40] <derekv> i usually see that spelling in refrence to video game cheating
[23:40] <derekv> which is not something i bother with


[00:04] <StevenK> wgrant: Ha. Hahaha
[00:37] <wgrant> StevenK: Going well?
[00:40] <StevenK> Still making a list of pages to hit up
[00:46] <wgrant> Ah
[00:48] <StevenK> Trying to find a projectgroup on qas that uses blueprints
[00:49] <wgrant> https://qastaging.launchpad.net/heehee
[00:50] <lifeless> !
[00:53] <StevenK> wgrant: So that's Person, Product, ProductSeries, Milestone, Distribution, DistroSeries, and Sprint checked.
[00:53] <StevenK> heehee has no blueprints, and something with private blueprints would be nice.
[00:53] <wgrant> StevenK: It does, you might just not be able to see them
[00:54] <wgrant> prop-auditorclient is in it
[00:54] <wgrant> And I added a private blueprint to it last week to check this exact thing
[00:54] <StevenK> Yeah, I can't view prop-auditorclient
[00:54] <wgrant> I've made it public
[00:55] <wgrant> The project group now correctly shows an empty blueprint list for an anonymous user
[00:55] <wgrant> So it looks fixed
[00:55] <StevenK> I still get the message for me
[00:55] <wgrant> Which message?
[00:55] <StevenK> "... Register the first blueprint in this project! If you have a proposal for a feature ..."
[00:56] <wgrant> That's the empty blueprint list :)
[00:56] <StevenK> Not so much a list as a wall of text
[00:56] <wgrant> I believe it is the largest wall of text in the entire application, indeed
[00:56] <wgrant> (ignoring help popups)
[00:57] <StevenK> I still can't see the blueprint for prop-auditorclient, but eh
[00:58] <StevenK> Oh, projectgroup didn't check for privacy. Right.
[00:58] <StevenK> Now it does, since I made it do so.
[00:59] <wgrant> Exactlyu
[00:59] <wgrant> i've just shared the project with you
[00:59] <wgrant> So you should be able to see the spec
[00:59] <StevenK> And I can
[00:59] <StevenK> Fantastic
[00:59]  * StevenK goes to mark bugs as qa-ok
[00:59] <StevenK> Did you want a deployment?
[00:59] <wgrant> Indeed
[00:59] <wgrant> I'm about to disappear out to lunch, so if you could arrange that...
[01:00] <wgrant> Also, if it happens while I'm gone, do keep an eye on buildd-manager
[01:00] <StevenK> I'll sort it out
[02:58] <StevenK> wgrant: http://pastebin.ubuntu.com/1561501/
[03:00] <wgrant> StevenK: Does it work?
[03:01] <StevenK> The tests pass
[03:01] <StevenK> I fear it doesn't close danilos bug
[03:03] <wgrant> StevenK: H, though the privacy filter should be in the recursive query, not the outer one
[03:03] <wgrant> eg. if we have A->B->C and I can't see B, I think this will do strange things
[03:03] <wgrant> whereas if the filter's in the recursive bit, then I will just see A, not A and C
[03:04] <StevenK> wgrant: Right
[03:06] <StevenK> And both recursive_dependent_query and recursive_blocked_query are just a string
[03:06] <wgrant> Maybe not for long :)
[03:06] <StevenK> Yeah
[03:06] <wgrant> Otherwise you can use that compilation thingy
[03:06] <wgrant> convert_storm_clause_to_string
[03:07] <StevenK> wgrant: The inner SELECT from the UNION requires the privacy check?
[03:07] <wgrant> I haven't actually looked at the recursive query
[03:07]  * wgrant looks
[03:07] <StevenK> Which is on specificationdependency :-/
[03:08] <wgrant> Yeah, so you'll probably want to adjust the second half of each union to do the filtering.
[03:08] <wgrant> I didn't realise it was only over specificationdependency, which makes it a bit awkward
[03:08] <wgrant> But it shouldn't be too bad.
[03:10] <StevenK> So I have to join back to spec and then feed in get_specification_privacy_clause?
[03:18] <wgrant> StevenK: Right.
[03:19] <StevenK> Hmmm, on specification on dependency, though
[03:19] <wgrant> Hm?
[03:19] <StevenK> specificationdependency has specification and dependency, both of which are specification
[03:20] <wgrant> Whichever one it returns
[03:20] <wgrant> Which will be one for blocked, and the other for deps
[03:39] <StevenK> Hm, my query is broken
[04:07] <StevenK> wgrant: http://pastebin.ubuntu.com/1561618/
[04:10]  * wgrant cries
[04:10] <StevenK> wgrant: Hm?
[04:11] <wgrant> StevenK: a) It's illegal to construct SQL with %. Legacy code is permitted as long as it's of the form "% sqlvalues(...)", but nothing else. Try using SQL() instead.
[04:11] <wgrant> b) Have you verified the constructed SQL?
[04:11] <wgrant> What does convert_storm_clause_to_string do when given multiple args?
[04:12] <StevenK> It isn't, it's either an [Or()] or a [In()]
[04:12] <wgrant> Ah
[04:12] <wgrant> Still, examine the constructed SQL
[04:14] <StevenK> wgrant: http://pastebin.ubuntu.com/1561630/
[04:15] <wgrant> StevenK: lolwut
[04:15] <wgrant> Oh, misread
[04:16] <wgrant> StevenK: What doesn't it do?
[04:16] <StevenK> Oh?
[04:16] <wgrant> There's no actual SELECT there
[04:16] <wgrant> Just a WITH RECURSIVE
[04:16] <wgrant> Which is not completely helpful
[04:18] <StevenK> wgrant: http://pastebin.ubuntu.com/1561633/
[04:19] <wgrant> StevenK: and what's broken about it?
[04:19] <wgrant> Other than some possibly missing parens
[04:20] <StevenK> It was broken, I fixed it by reordering the FROM
[04:20] <wgrant> Oh
[04:20] <wgrant> I thought it was still broken :)
[04:20] <StevenK> But I can't use %s
[04:21] <StevenK> Is this a subtle hint that I should Storm-ify it?
[04:21] <wgrant> You should be able to use SQL()
[04:22] <wgrant> I don't think our current Storm With expression supports RECURSIVE
[04:24] <StevenK> wgrant: The callsites do SQL(), the functions are expected to just return a string
[04:24] <wgrant> You might want to rearrange that
[04:25] <wgrant> Given the paucity of callsites that should be quite trivial
[04:28] <StevenK> wgrant: http://pastebin.ubuntu.com/1561643/
[04:29] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1100977/+merge/144432
[04:30] <StevenK> 22if content.find(no_key_message) >= 0:
[04:30] <StevenK> Sadface
[04:30] <wgrant> StevenK: I think your linewrapping violates the UDHR.
[04:31] <StevenK> Which linewrapping?
[04:31] <wgrant> +        )""", params=(spec.id, convert_storm_clause_to_string(
[04:31] <wgrant> +            *get_specification_privacy_filter(user))))
[04:33] <StevenK> wgrant: And you didn't complain that I only fixed one of the methods? Disgraceful.
[04:33] <StevenK> wgrant: http://pastebin.ubuntu.com/1561650/
[04:33] <wgrant> I give up reading un-highlighted diffs easily :)
[04:33] <wgrant> (--syntax=diff is your friend)
[04:34] <wgrant> That's still a criminal offence in most jurisdictions, but less so
[04:35] <StevenK> wgrant: params=(\nspec.id, ... )?
[04:36] <wgrant> StevenK: Right :)
[04:37] <StevenK> wgrant: http://pastebin.ubuntu.com/1561657/
[04:40] <wgrant> StevenK: Actually, I'm surprised that works.
[04:40] <wgrant> Given you're passing a plain string into params
[04:40] <wgrant> But trying to use it as SQL
[04:40] <wgrant> It may work if you wrap it in SQL(), not sure
[04:41] <StevenK> I've not actually tried it ...
[04:41] <wgrant> Heh
[04:42] <wgrant> You might actually be able to properly Stormify it with a bit of a hack
[04:42] <wgrant> With('RECURSIVE dependencies(id)', Union(...))
[04:43] <StevenK> DataError: invalid input syntax for type boolean: "Specification.information_type IN (1, 2)"
[04:43] <StevenK> LINE 8:             WHERE sd.specification = d.id AND (E'Specificati...
[04:43] <StevenK> Hahaha
[04:46] <StevenK> Hmmm
[04:46] <StevenK> ProgrammingError: can't adapt type 'In'
[05:20] <StevenK> wgrant: I'm not sure about the Storm-ified version ...
[05:20] <StevenK> Or indeed if I've done it correctly
[05:25] <StevenK> wgrant: http://pastebin.ubuntu.com/1561722/
[05:26] <wgrant> StevenK: The easiest way to be sure about it and that you've done it correctly is to see if the tests work
[05:28] <wgrant> Bah
[05:28] <wgrant> zeca was tested directly
[05:28] <StevenK> Haha
[05:28] <StevenK> I was about to point that out
[05:29] <StevenK> CompileError: Don't know how to compile type Reference of <storm.references.Reference object at 0x795c850>
[05:29] <StevenK> Thanks for being helpful, Storm.
[05:29] <wgrant> StevenK: Did you do reference == reference?
[05:29] <wgrant> That doesn't work
[05:29] <wgrant> id == id
[05:30] <wgrant> Or reference == id
[05:30] <wgrant> works
[05:32] <StevenK> Specification.id == SpecificationDependency.specificationID
[05:32] <StevenK> That's the only ==, so I'm not sure which reference it's barfing on
[05:33] <wgrant> Is it roughly simialr to the code that you pased?
[05:33] <wgrant> +        'RECURSIVE blocked(id)', Union(Select(
[05:33] <wgrant> +            (SpecificationDependency.specification,),
[05:33] <wgrant> That might not work
[05:33] <wgrant> You probably have to select the ID
[05:34] <StevenK> wgrant: The only change is calling the new function further down
[05:35] <StevenK> wgrant: 'RECURSIVE blocked', Select((id,), Union(... ?
[05:37] <wgrant> StevenK: That'll try to select the builtin function 'id'
[05:37] <wgrant> SpecificationDependency.specificationID
[05:38] <StevenK> Which is already in the inner select?
[05:39] <wgrant> StevenK: Is that a problem?
[05:40] <StevenK> Just ... odd
[05:41] <wgrant> Not sure how
[05:45] <StevenK> Right, RECURSIVE blocked(id) is working because specificationID rather specification
[05:45] <StevenK> Except it doesn't love blocked
[05:45] <StevenK> So I get an actual statement that compiles but postgres doesn't love.
[05:46] <wgrant> What does postgres complain about?
[05:48] <StevenK> wgrant: http://pastebin.ubuntu.com/1561762/
[05:49] <wgrant> StevenK: Ah, you should be able to see the problem there
[05:50] <StevenK> Select((spec.id,), Union(... ?
[05:50] <wgrant> No
[05:50] <wgrant> Look at the first line
[05:50] <StevenK> Oh, quoting RECURSIVE is a bad thing
[05:50] <wgrant> Yes
[05:50] <wgrant> With(SQL("RECURSIVE blocked(id)"), ...) might work
[05:50] <wgrant> Not sure
[05:52] <StevenK> ProgrammingError: syntax error at or near "("
[05:52] <StevenK> LINE 1: WITH (RECURSIVE blocked(id)) AS (SELECT 13 WHERE (SELECT Spe...
[05:52] <StevenK> Let's go with no
[05:55] <wgrant> StevenK: Bah, it's too smart.
[05:55] <StevenK> Heh
[05:55] <wgrant> StevenK: Define your own With expression, I guess.
[05:55] <StevenK> I don't think the Storm-ifying is buying us anything. If anything, it's far uglier
[05:55] <wgrant> (or extend the one in our Storm branch, I guess, would be better0
[05:56] <wgrant> Certainly
[05:56] <wgrant> But it would have been a trivial way to integrate the privacy filter apart from the RECURSIVE issue
[05:56] <StevenK> Toss it as a param is giving me a wierd error too
[05:56] <wgrant> Well, params is for params
[05:57] <StevenK> Oh
[05:57] <StevenK> I feel %s calling, but I'll get stabbed
[05:58] <wgrant> It seems that avoiding it here is somewhat non-trivial
[05:58] <wgrant> So it may be permissible
[05:58] <wgrant> But inserting the id like that as the original code did is strictly forbidden
[05:58] <wgrant> Even in legacy code
[08:52] <adeuring> good morning
[09:00] <jtv> Good morning adeuring!
[09:00] <adeuring> hi jtv!
[10:49] <plomme> hi guys
[14:12] <cjwatson> wgrant: I'd like to have a pre-imp chat about bug 1102870
[14:12] <_mup_> Bug #1102870: Copies use naïve ancestry check to calculate previous version for notifications and bug closures <package-copies> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1102870 >
[14:13] <cjwatson> I *think* a sensible way to approach this is by moving NascentUpload.getSourceAncestry (and probably getBinaryAncestry too, for symmetry) somewhere more sensible
[14:13] <cjwatson> However, it uses the deprecated DS.getPublishedSources method
[14:14] <cjwatson> Rephrasing it in terms of Archive.getPublishedSources isn't too hard, but it means more potato programming since there's then no way to query multiple archives at once
[14:15] <cjwatson> I kind of feel that the method belongs on DS anyway, since it's "give me the current published version of $package in this distroseries, for some set of pockets"
[14:16] <cjwatson> But I'm not sure that there isn't a better place - do you have any strong feelings?
[14:17] <cjwatson> (If I put it on Archive, then I have to do explicit version comparison between the results for each pocket, I think, and the method that does that will still have to live somewhere common - so I don't think putting it on Archive would help)
[14:19] <cjwatson> It might be worth getting rid of one more use of DS.getPublishedSources in any case; something like http://paste.ubuntu.com/1563165/
[15:56] <gmb> benji, bac, if either of you have time today, could you take a look at https://code.launchpad.net/~gmb/lp2kanban/encode-annotations-with-json/+merge/144372? It takes the description annotations work and uses JSON for encoding rather than hand-rolled key=value pairs.
[15:56] <gmb> (per benji's suggestion)
[15:56] <benji> gmb: sure (bac is a bit sickly at the moment)
[15:57] <gmb> benji, Thanks.
[19:54] <joey> dzin: hmm sinzui isn't here
[19:54] <joey> dzin: maybe we need to go to #launchpad! :-)
[19:54] <dzin> ok :)
[19:55] <czajkowski> joey: he doesnt do LP stuff any more
[19:55] <joey> czajkowski: ah ha
[23:59] <cjwatson> wgrant,StevenK: I'd like to get https://code.launchpad.net/~cjwatson/launchpad/avoid-copy-archive-spam/+merge/144611 reviewed reasonably quickly, to ensure we stop spamming its victim


[05:53] <dholbach> good morning
[15:35] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek about to start in 25 minutes in #ubuntu-classroom
[16:56] <osantana> agoliveira: did you see your picture in Info magazine? :)
[16:56] <agoliveira> osantana: Sure did :)
[16:56] <agoliveira> osantana: Am I cute or what?
[16:57] <osantana> humm... nope :)
[17:25] <agoliveira> osantana: Bah, you just can't apreciate beauty...
[21:43] <smagoun_> StevenK: Recent Q1 images don't have network + have the following in xsession-errors. Are you looking at the problem?
[21:44] <smagoun_> ** (nm-applet:5005): WARNING **: <WARN>  nma_dbus_init(): could not acquire its service.  dbus_bus_acquire_service() says: 'Connection ":1.13" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file'