[00:25] <mup> Bug # changed: 1167616, 1292116, 1346597, 1349949, 1383453, 1425808, 1426728, 1453805, 1455627, 1465317, 1466514, 1473069, 1475212, 1480616, 1485781, 1498232, 1501475, 1504658, 1506044, 1509635, 1510688, 1510787, 1513667, 1516150, 1517632, 1518480, 1518482, 1521453, 1530840, 1531444, 1532130,
[00:25] <mup> 1532266, 1534103, 1535838, 1536447, 1538583, 1540301, 1546794, 1548078, 1552274, 1555475, 1555727, 1555808, 1557726, 1557914, 1558185, 1560107, 1560888, 1563015, 1563611, 1563933, 1564026, 1566014, 1566426, 1566583, 1566639, 1566684, 1566791, 1567607, 1567747, 1567934, 1568183, 1568666, 1569802,
[00:25] <mup> 1570216, 1570660, 1571982, 1572116, 1572695, 1572700, 1573407, 1573742, 1576534, 1577524, 1577567, 1577587, 1577589, 1577590, 1577593, 1577638, 1577798, 1578898, 1579887, 1579976, 1580231, 1580423, 1580485, 1580717, 1581894, 1582021, 1582065, 1582463, 1582801, 1584193, 1585878, 1586089, 1586890,
[00:25] <mup> 1587345, 1587503, 1587734, 1588041, 1589641, 1590362, 1591488, 1592613, 1592811, 1593185, 1593350, 1594332, 1594663, 1595600, 1596619, 1596687, 1596688, 1596842, 1596858, 1596888, 1596890, 1596893, 1596906, 1597481, 1597490, 1597601, 1597830, 1598206, 1598290, 1598707, 1599272, 1599570, 1599886,
[00:25] <mup> 1600063, 1600221, 1600453, 1600515, 1600523, 1600546, 1602032, 1602237, 1602416, 1602749, 1602840, 1602885, 1602952, 1603060, 1603176, 1603228, 1603473, 1603640, 1603841, 1604120, 1604817, 1604883, 1604915, 1604961, 1604965, 1604988, 1605241, 1605335, 1605449, 1605653, 1605714, 1605986, 1606282,
[00:25] <mup> 1606308, 1606354, 1606487, 1606506, 1606617, 1606684, 1606917, 1606922, 1607161, 1607170, 1607347, 1607599, 1607601, 1607608, 1607611, 1607855, 1607895, 1607964, 1607971, 1608494, 1608529, 1608597, 1608677, 1608956, 1608959, 1609893, 1610880, 1611067, 1611093, 1611159, 1611391, 1611404, 1611427,
[00:25] <mup> 1611453, 1611514, 1611799, 1611981, 1611990, 1612046, 1612105, 1612110, 1612417, 1612500, 1612624, 1612717, 1612836, 1613150, 1613200, 1613262, 1613300, 1613429, 1613444, 1613459, 1613491, 1613688, 1613782, 1613838, 1613839, 1613855, 1613858, 1613866, 1613892, 1613960, 1613992, 1614010, 1614161,
[00:25] <mup> 1614345, 1614364, 1614559, 1614635, 1614689, 1614948, 1615051, 1615839
[00:28] <perrito666> chill out bot, you will get something
[00:38] <redir> bbiab ~730PDT
[00:39] <anastasiamac> thumper-dogwalk: RB strikes again :D PR behind this RB has been merged but RB is still open.. could u plz close it? http://reviews.vapour.ws/r/5472/
[00:49] <mup> Bug # changed: 1205113, 1334482, 1397201, 1403722, 1444066, 1445066, 1455625, 1468188, 1492530, 1494939, 1536448, 1539156, 1542488, 1545712, 1554116, 1555801, 1556176, 1564168, 1566023, 1569632, 1570651, 1571831, 1571855, 1572350, 1573099, 1574798, 1575245, 1575283, 1575405, 1576184, 1576295,
[00:49] <mup> 1576301, 1576342, 1576359, 1576851, 1579833, 1579836, 1581138, 1581211, 1581612, 1581879, 1582018, 1585289, 1590237, 1591379, 1591499, 1592031, 1592837, 1594440, 1595330, 1596476, 1596593, 1596603, 1596605, 1596607, 1596612, 1596615, 1596616, 1596853, 1604106, 1607303, 1609463, 1609879, 1610007,
[00:49] <mup> 1610254, 1611111, 1611267, 1611269, 1611271, 1611273, 1611275, 1612043, 1612048, 1612478, 1612645, 1612658, 1612687, 1612775, 1612793, 1613537, 1613672, 1614065, 1614230, 1614239, 1614329, 1614330, 1614571, 1614633, 1614732, 1614749, 1614809, 1615108, 1615601
[00:58] <mup> Bug #1615868 opened: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:10] <mup> Bug #1615868 changed: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:16] <mup> Bug #1615868 opened: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:25] <mup> Bug #1615868 changed: interactive bootstrap fails with tools mismatch <juju:Triaged> <https://launchpad.net/bugs/1615868>
[01:36] <wallyworld> thumper-dogwalk: can you ping me, or see last comment in bug 1615051
[01:36] <mup> Bug #1615051: Dubious hook failures deploying trivial charm <ci> <deploy> <hooks> <jujuqa> <regression> <juju:Triaged by thumper> <https://launchpad.net/bugs/1615051>
[01:49] <thumper> wallyworld: seems reasonable
[01:49] <wallyworld> thumper: so you will fix :-)
[01:50] <thumper> wallyworld: you got to blame it on me
[01:50] <thumper> um...
[01:50] <wallyworld> \o/
[01:50] <thumper> they need to fix their tests
[01:50] <wallyworld> but the charm is broken
[01:50] <wallyworld> we have broken the production charm
[01:50] <thumper> so they need to fix their charm
[01:50] <wallyworld> for mediawiki and others
[01:51] <wallyworld> a lot of stuff will just break now
[01:51] <thumper> wallyworld: marcoceppi seemed to think that most charms use charmtools and wouldn't be impacted by this change
[01:51] <wallyworld> does charm tools do the right thing? what does it do?
[01:51] <thumper> it always says --format json
[01:51] <wallyworld> so maybe we just got unlucky
[01:51] <marcoceppi> charmhelpers*
[01:52] <thumper> marcoceppi: sorry
[01:52] <wallyworld> the dummy test charm and the mediawiki one the CI tests use
[01:52] <thumper> marcoceppi: would you expect mediawiki to work?
[01:52] <marcoceppi> it's probalby bash
[01:52] <marcoceppi> because it's garbage
[01:53] <wallyworld> no, ot's python
[01:53] <wallyworld> https://api.jujucharms.com/charmstore/v5/mediawiki/archive/hooks/cache-relation-changed
[01:53] <thumper> wallyworld: it uses --format json
[01:54] <wallyworld> really?
[01:54] <wallyworld> rl = subprocess.Popen("relation-list",stdout=subprocess.PIPE)
[01:54] <wallyworld> no python there that i can see - that's the bit that is causing the failure
[01:54] <wallyworld> unless i am mistaken
[01:54] <marcoceppi> wallyworld: it's not using charmhelpers, it's not a good charm
[01:55] <wallyworld> agreed
[01:55] <thumper> p = subprocess.Popen(["relation-get", "--format", "json", "-", memcached_unit.strip()],
[01:55] <wallyworld> thumper: right but that's not the issue
[01:55] <thumper> ugh
[01:55] <thumper> sabdfl said "fix the charms"
[01:55] <wallyworld> the issue is that the memcahced_unit value has changed
[01:56] <wallyworld> thumper: so for now, i guess we ask CI to set the feature flag
[01:56] <thumper> wallyworld: that would certainly be the easiest solution
[01:57] <thumper> wallyworld: I'll email appropriate people
[01:57] <wallyworld> thumper: can you be the one then to mark the bug as "invalid" or "won't fix" for core :-)
[01:57] <wallyworld> ta
[01:58] <wallyworld> thumper: also cc rick who was the one who the bug passed through
[01:59] <thumper> ack
[02:41] <redir> woah, hot bug action.
[03:01] <katco> thumper: hey, i responded to your review of http://reviews.vapour.ws/r/5485/ can you give me a ship it (or not)?
[03:01] <thumper> sure, I'll look again shortly
[03:01] <katco> thumper: no rush at all. as long as i wake up in 10h or so and something's there :)
[03:01] <thumper> :)
[03:01] <katco> thumper: ta
[03:02]  * katco disappears
[03:02] <redir> poof
[03:03] <natefinch> so I guess juju on launchpad is now what we're using for 2.0 bugs?
[03:04] <natefinch> as opposed to juju-core
[03:04] <mup> Bug #1615095 changed: storage: volumes not supported <landscape> <juju:Triaged> <https://launchpad.net/bugs/1615095>
[03:07] <mup> Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged> <https://launchpad.net/bugs/1615580>
[03:11] <anastasiamac> natefinch: yes. this si the attempt to make sure that we important 2.0 bugs do not disappear in the heap of old 15K bugs.. when I say old, i mean like 2012,2013...:D
[03:19] <mup> Bug #1615580 opened: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged by thumper> <https://launchpad.net/bugs/1615580>
[03:20] <natefinch> anastasiamac: cool.  Hopefully someone will send out an email soon, so we don't add new bugs to the wrong place?
[03:20] <anastasiamac> natefinch: Rcik sent an email couple of weeks ago.
[03:25] <natefinch> anastasiamac: oh. huh.
[03:25] <anastasiamac> Rick* even :D
[03:26] <natefinch> anastasiamac: ahh, I see it.  It's buried at the bottom of a long-ish email about bug cleanup :)
[03:27] <anastasiamac> natefinch: i like the idea of following up to sya "we are done" but i think a redirect from juju-core to juju (or some kind of note that 2.0 bugs do not belong there) would be nice..
[03:31] <natefinch> anastasiamac: so it's on 2.0 bugs that'll get moved over?
[03:31] <natefinch> s/on/only
[03:31] <anastasiamac> natefinch: yes, 2.+
[03:31] <anastasiamac> \o/
[03:32] <natefinch> Oh, I know why I missed it, rick sent it to cloud
[03:33] <anastasiamac> natefinch: yes :D
[03:34] <natefinch> I don't ever look at cloud, because it's so spammy
[03:34] <anastasiamac> natefinch: sorry. want to file a bug? :D
[03:34] <natefinch> haha
[03:34] <mup> Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged> <https://launchpad.net/bugs/1615580>
[03:34] <mup> Bug #1615719 changed: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored <openstack-provider> <juju:Triaged> <https://launchpad.net/bugs/1615719>
[03:34] <natefinch> just wondering if I should add juju-dev to my re-forwarding of the email
[03:35] <natefinch> seems like it would be good for people outside canonical to know, too.  but maybe that was on purpose
[03:55] <wallyworld> thumper: probs not - did we have anything like dave's process info endpoint in 1.25?
[03:55] <thumper> yes
[03:55] <thumper> but it was less easy to access
[03:56] <wallyworld> thumper: oh awesome, i didn't think it was for 1.25, can you point me to docs?
[03:56] <thumper> it landed in 1.25 I think
[03:56] <thumper> https://github.com/juju/juju/wiki/pprof-facility
[03:56] <thumper> 1.25.4
[03:57] <wallyworld> awesome thanks
[04:07] <mup> Bug # changed: 1456659, 1457092, 1457148, 1459300, 1493058, 1507359, 1510651, 1510944, 1512782, 1536230, 1536333, 1554088, 1559299, 1560331, 1568186, 1568189, 1568715, 1578327, 1580221, 1582268, 1588147, 1596559, 1605593, 1606300, 1615121
[04:13] <mup> Bug # changed: 1614599, 1614622, 1614835, 1614992, 1615008
[04:18] <wallyworld> can has small review? http://reviews.vapour.ws/r/5506/
[04:19] <mup> Bug # opened: 1614599, 1614622, 1614835, 1614992, 1615008
[04:25] <redir> wallyworld: looking
[04:25] <wallyworld> \o/
[04:25] <wallyworld> redir: need any help with the config stuff - just let me know
[04:26] <redir> yeah, I have a couple ? in a minute, wallyworld
[04:27] <wallyworld> wow, this is kinda awesome, just saw it in warthogs http://www.boredpanda.com/ive-just-painted-all-25-ubuntu-animals/
[04:33] <wallyworld> axw: it seems that we have Schema() methods on various environ providers but don't call this method anywhere but from tests, and I can't see an interface that declares it either - it's not on the EnvironProvider interface. am i missing something?
[04:33] <menn0> veebers: the big macaroon changes for migrations have landed
[04:34] <axw> wallyworld: I don't think that work was ever completed
[04:34] <axw> wallyworld: I think it'll be obsoleted by natefinch's work
[04:36] <wallyworld> ok, but i need it now :-)
[04:36] <wallyworld> for proper default config management
[04:36] <wallyworld> this week
[04:36] <wallyworld> first in wins :-)
[04:36] <axw> wallyworld: what do you need to do?
[04:37] <wallyworld> when bootstrapping and setting up config defaults, we currently ignore provider specific config - we only handle what's in config/config.go. So juju model-defaults will not show use-floating-ip for example on openstack
[04:37] <mup> Bug # changed: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560618,
[04:37] <mup> 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1578237, 1580714, 1582264, 1583304, 1585300, 1589628, 1603221, 1604959, 1605767, 1605769, 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313,
[04:37] <mup> 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405, 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764, 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824,
[04:37] <mup> 1613829, 1613882, 1613888, 1614256, 1614599, 1614622, 1614835, 1614992, 1615008, 1615118
[04:37] <veebers> menn0: awesome, I'll build and fire off a run shortly :-)
[04:38] <wallyworld> and when a user sets or resets a value, they get a bullshit warning because those provider config items are not in the vocab
[04:38] <wallyworld> so i can easily solve the issue by processing the provider schema at bootstrap time
[04:39] <axw> wallyworld: ok, sounds like adding Schema to EnvironProvider is reasonable. please let natefinch know your requirements so he can work that into what he's doing
[04:39] <wallyworld> will do
[04:40] <wallyworld> he may even be lurking here now :-)
[04:40] <mup> Bug # opened: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560618,
[04:40] <mup> 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1578237, 1580714, 1582264, 1583304, 1585300, 1589628, 1603221, 1604959, 1605767, 1605769, 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313,
[04:40] <mup> 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405,
[04:40] <mup> 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764, 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118
[04:43] <mup> Bug # changed: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560593,
[04:43] <mup> 1560618, 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1563888, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1575400, 1578237, 1580714, 1582264, 1583304, 1585300, 1585361, 1589628, 1589890, 1590239, 1596071, 1603221, 1604959, 1605767, 1605769,
[04:43] <mup> 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313, 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405, 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764,
[04:43] <mup> 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118
[04:44] <redir> wallyworld: sooo for passing params to the ComposeNewModelConfig from apiserver/modelmanager were you thinking params that live in apiserver/params/... or somewhere else?
[04:45] <wallyworld> redir: let me look at the code
[04:46] <redir> wallyworld: I'll put it there and make a PR, so I wrap and have feedback for tomorrow, whence I can also get the modeldefaults done and move on to get/set
[04:47] <wallyworld> redir: ok. with regards to ComposeNewModelConfig, you are talking about weaving in the region defaults right?
[04:49] <wallyworld> if so, there's nothing to pass across the wire for that, so nothing from params
[04:49] <redir> wallyworld: yes, currently just passing cloudSpec
[04:49] <redir> but only need cloud and region
[04:49] <redir> wallyworld: right nothing for the wire.
[04:49] <redir> internal?
[04:50] <wallyworld> no, stuff in those dirs is just for on the wire data
[04:50] <redir> wallyworld: in internal is only for wire data?
[04:51] <wallyworld> yes, internal api calls
[04:51] <wallyworld> from workes to state etc
[04:51] <redir> OK.
[04:51] <wallyworld> everything in apiserver should be about pulling stuff of the wire for remote calls and composing into business objects for use elsewhere, but sadly we have put a lot of business logic in apiserver
[04:51] <wallyworld> which should really be elsewhere
[04:52] <wallyworld> there needs to be a separate business service layer
[04:52] <wallyworld> but we have conflated apiserver for that
[04:53] <axw> wallyworld: I'm going to pause on azure stuff and look at removing the remaining model config from the lxd provider
[04:53] <wallyworld> awesome^100
[04:54] <wallyworld> i'd love to get all this sorted this week
[04:54] <menn0> thumper: blocking of user API requests to a model while it is being imported http://reviews.vapour.ws/r/5508/
[04:54] <axw> wallyworld: I have a PR up for azure that reduces the number of API calls made.  I'm off for the night. If that is close I should be able to move on to the defaults output and then the get/set bits
[05:49] <redir> night juju-dev
[05:49] <wallyworld> thaks reed
[05:49] <wallyworld> ttyl
[05:49] <mup> Bug # opened: 1463608, 1536885, 1543404, 1543408, 1564157, 1564500, 1566268, 1567952, 1593274, 1598127, 1600600
[05:53] <mup> Bug # changed: 1463608, 1536885, 1543404, 1543408, 1557540, 1563117, 1564157, 1564500, 1564677, 1566268, 1567952, 1593274, 1598127, 1600600
[06:11] <mup> Bug #1557540 opened: Missing help for payloads <docs> <payloads> <juju:Triaged> <https://launchpad.net/bugs/1557540>
[06:11] <mup> Bug #1563117 opened: api: data race adding local charm. <race-condition> <unit-tests> <juju:Triaged> <https://launchpad.net/bugs/1563117>
[06:11] <mup> Bug #1564677 opened: Create one binary for juju and all plugins <osx> <packaging> <juju:Triaged> <https://launchpad.net/bugs/1564677>
[06:14] <mup> Bug # changed: 1512569, 1557540, 1563117, 1564677
[06:22] <axw> wallyworld: can you please see my comments on http://reviews.vapour.ws/r/5502/, make sure I'm not leading anastasiamac up the garden path again
[06:24] <wallyworld> ok
[06:24] <wallyworld> axw: could you take look at my small pr that reed looked at? just to give sign off?
[06:24] <axw> wallyworld: sure, looking
[06:49] <wallyworld> axw: fmt.Fprintf(ctx.Stderr) vs logger.Warning - i was hoping to avoid the logger extras and keep the output clean. was your issue that we should be showing a WARNING text?
[06:54] <axw> wallyworld: I was thinking that yeah
[06:55] <axw> wallyworld: not too concerned
[06:55] <wallyworld> axw: ok, i'll add warning to the text
[06:57] <wallyworld> axw: axctually, i meant that you look at this one http://reviews.vapour.ws/r/5506/
[06:57] <axw> wallyworld: heh whoops
[06:57] <wallyworld> the other one may need to have other changes added
[06:57] <axw> looking :)
[06:57] <wallyworld> ta
[06:59] <axw> wallyworld: LGTM
[06:59] <wallyworld> ta
[07:37] <anastasiamac> axw: wallyworld: re: defaults for image metadata, want to discuss tomorrow after standup? i think we are all pretty much in agreement but i;d rather minimise the churn on PR \o/
[07:38] <axw> anastasiamac: sure
[07:38] <anastasiamac> axw: \o/
[07:38] <axw> anastasiamac: I have a meeting at 8am, so may have to be short or after that
[07:39] <anastasiamac> axw: that's k. as long as it's sometime tomorrow :) i have a meeting at 11am my time =9am urs? :) so maybe early afternoon :D
[07:40] <axw> anastasiamac: and I plan to be out between 9:30 and don't-know-when looking at cars (again)
[07:42] <anastasiamac> axw: that's exciting :D know what u want?
[07:42] <axw> anastasiamac: there's a couple that are ok. I'm not too bothered, as long as I don't get ripped off
[07:43] <anastasiamac> axw: well, actually, i'll remove the method and will ensure that data is populated at the right spots so it may be just the matter of re-viewing changes ;)
[07:43] <axw> anastasiamac: ok, sounds good
[07:43] <anastasiamac> axw: i love shopping for cars :)
[07:44] <mup> Bug #1615958 opened: Switch to model name does't work anymore, admin should not be allowed to switch to users model <juju-core:New> <https://launchpad.net/bugs/1615958>
[07:44] <mup> Bug #1615960 opened: remove-machine and remove-application don't work on google cloud <juju-core:New> <https://launchpad.net/bugs/1615960>
[08:27] <voidspace> fwereade: ping
[08:30] <voidspace> dimitern: land your lxd fix and let mgz handle the packaging mess when he returns ;-)
[08:30]  * voidspace wants lxd working again
[08:30] <dimitern> voidspace: :)
[08:30] <voidspace> I might try one more time to go back to 2.0
[08:31] <dimitern> voidspace: yeah, and I'm not convinced there is any packaging issue anyway
[08:31] <voidspace> I burned at least two hours on it yesterday
[08:31] <voidspace> dimitern: it seems odd
[08:31] <voidspace> dimitern: however I'm sure frobware wouldn't invent it - so there must be some issue
[08:31] <voidspace> dimitern: maybe a trusty thing?
[08:31] <voidspace> but still can't see how
[08:31] <voidspace> I'm sure mgz will explain :-(
[08:33] <dimitern> voidspace: it was something about building .debs that includes building the lxd source and running into conflicts
[08:33] <dimitern> but I don't believe this is avoidable at all
[08:34] <dimitern> it'll break if lxd changes binary compatibility, like adding an extra arg to Init()
[08:44] <babbageclunk> Hey fwereade, could you take another look at http://reviews.vapour.ws/r/5495/? I really think I've got it this time! :)
[08:47] <fwereade> voidspace, babbageclunk: heyhey, I'm off today but you're in luck, everybody else is still asleep for the moment
[08:48] <voidspace> fwereade: hehe
[08:48] <voidspace> fwereade: I'm making some progress code spelunking on my own
[08:48] <fwereade> voidspace, excellent
[08:48] <voidspace> fwereade: but it's unfamiliar code so I'm sure you can help with some quick pointers
[08:48] <voidspace> fwereade: IRC or hangout?
[08:49] <fwereade> voidspace, irc probably better
[08:56] <babbageclunk> fwereade: Yay thanks! Hope your day off gets better once voidspace stops bothering you. So rude!
[08:56]  * babbageclunk does a big wink.
[08:57] <voidspace> babbageclunk: always
[08:57] <voidspace> babbageclunk: and stop winking
[08:58] <babbageclunk> voidspace: oh, that's involuntary - I think it's my meds.
[08:58] <voidspace> babbageclunk: :-)
[08:59] <fwereade> babbageclunk, hahaha
[09:08] <thumper> o/
[09:08] <thumper> fwiw I'm fixing my fubar
[09:08] <thumper> will need some reviewers soon
[09:08] <dimitern> mgz, frobware, voidspace, babbageclunk: I'm about to push https://github.com/juju/juju/pull/6054 for landing, unless anyone is strongly against it.
[09:09] <dimitern> \o thumper
[09:14] <voidspace> dimitern: sounds good to me
[09:14] <voidspace> thumper: o/
[09:14] <thumper> o/
[09:14] <babbageclunk> thumper: o/
[09:14] <thumper> babbageclunk: how's the laptop?
[09:16] <babbageclunk> thumper: :( I'm using a loaner at the moment.
[09:17] <babbageclunk> thumper: But it's super chunky - 8 cores & 32 Gb!
[09:17] <babbageclunk> thumper: (the loaner, I mean)
[09:17] <thumper> babbageclunk: so fucked then?
[09:18] <babbageclunk> thumper: And it was a pretty good test of my ansible setup scripts.
[09:18] <babbageclunk> thumper: yup - just the drive, though
[09:18] <babbageclunk> thumper: need to order a new ssd
[09:18]  * thumper nods
[09:18] <thumper> lose much?
[09:18] <thumper> here is the first branch: http://reviews.vapour.ws/r/5511/
[09:19] <babbageclunk> thumper: a couple days' work - although lots of that was working out time rather than typing time, so it wasn't too bad. Definitely pushing a lot more frequently now though!
[09:25] <thumper> :)
[09:34] <macgreagoir> dimitern: I want to retry a merge, but I can wait if you're about to queue-up the LXD fix.
[09:35] <dimitern> macgreagoir: I've just sent the merge comment on mine
[09:36] <macgreagoir> Cool
[09:43]  * thumper runs all tests
[09:46] <thumper> prelim review anyone? http://reviews.vapour.ws/r/5512/
[09:46] <thumper> I'm running all the tests now to make sure I didn't miss something
[09:47] <dimitern> thumper: looking at both, in order
[09:47] <thumper> dimitern: first one has landed already
[09:47] <thumper> :)
[09:47] <thumper> it is a juju/cmd change
[09:47] <thumper> which the second needs
[09:48] <dimitern> oh
[09:48] <dimitern> ok
[09:52] <thumper> so far, so good
[09:52] <thumper> up to featuretests
[09:52] <thumper> worker/uniter was the other big failure
[09:52] <macgreagoir> You just jinxed it! :-)
[09:52] <thumper> perhaps
[10:14] <thumper> oh poop
[10:21] <thumper> anyone ? http://reviews.vapour.ws/r/5513/
[10:22] <thumper> real fix waiting now for the above cmd fix
[10:23] <thumper> babbageclunk ? ^^
[10:24] <babbageclunk> thumper: I started looking but it was longer than my attention span! I'll take another run at it.
[10:24] <thumper> the one above is a missed behaviour change in juju/cmd
[10:25] <thumper> I have an update for the big branch once that has landed
[10:25] <babbageclunk> thumper: Oh, right - looking at that now
[10:25] <thumper> babbageclunk: thanks
[10:26] <babbageclunk> thumper: LGTM
[10:27] <babbageclunk> thumper: How are you verifying these?
[10:27] <babbageclunk> thumper: (I mean against the old one.)
[10:28] <thumper> I have been looking at the test changes I did on my friday branch
[10:28] <thumper> and making the code like that again
[10:28] <thumper> then fixing other things that need fixing
[10:28] <babbageclunk> gotch
[10:28] <macgreagoir> thumper: 5512 lgtm, fwiw
[10:29] <babbageclunk> a
[10:29] <babbageclunk> wow macgreagoir, how'd you do that? sharp packets?
[10:31] <macgreagoir> babbageclunk: gotch...a ? I'd been reviewing 5512 much longer than that :-)
[10:34] <thumper> babbageclunk, macgreagoir: 5512 just got a fresh push
[10:34]  * thumper runs another complete test run just to be sure
[10:39] <babbageclunk> frobware: Have you got your hacked trusty image around? Need to recreate my kvm-maases.
[10:39]  * thumper is still hoping for a +1 from babbageclunk
[10:39]  * babbageclunk sighs.
[10:40] <babbageclunk> ok looking for reals now
[10:44] <thumper> babbageclunk: thanks, I appreciate it
[10:44] <thumper> babbageclunk: FWIW, it isn't very exciting
[10:48] <babbageclunk> thumper: Ok, done - LGTM!
[10:48] <babbageclunk> thumper: It wasn't very exciting though. :)
[10:55] <thumper> thanks
[10:55] <thumper> tests all good this side
[10:55] <thumper> I'm submitting and signing off
[10:55] <thumper> laters
[10:56] <macgreagoir> \o
[11:02] <rick_h_> macgreagoir: adding one more item for that list for the card you're working on please, controller version
[11:04] <macgreagoir> rick_h_: ack
[11:04] <rick_h_> ty macgreagoir
[11:04] <rick_h_> dimitern: around to chat?
[11:07] <dimitern> rick_h_: yeah, sorry - joining our 1:1 now
[11:11]  * babbageclunk has to reboot to enable on virtualisation!
[11:17] <rick_h_> mgz: ping
[11:29] <babbageclunk> frobware: ping?
[11:30] <babbageclunk> voidspace: Are you around? Do you have frobware's hacked xenial image with the fixed cloud-init?
[11:30] <babbageclunk> voidspace: I'm sorry about those mean things I said this morning.
[11:30] <babbageclunk> voidspace: That was before I realised I needed something from you.
[11:31] <voidspace> babbageclunk: haha
[11:31] <voidspace> babbageclunk: I don't - I thought cloud-init was fixed in the standard images now
[11:31] <voidspace> babbageclunk: that's all I've been using
[11:31] <babbageclunk> voidspace: hmm - my xenial instance won't start
[11:34] <babbageclunk> voidspace: just hangs during startup. although at a different point than the cloud-init problem did, now that I look harder at it.
[11:34] <voidspace> babbageclunk: oh, weird
[11:34] <voidspace> babbageclunk: maas?
[11:34] <voidspace> pretty sure I've had it working fine
[11:37] <babbageclunk> voidspace: Well, I haven't got to the point of installing maas yet - this is just starting the controller.
[11:38] <babbageclunk> voidspace: I'm using the daily build - maybe I should use something else?
[11:38] <frobware> babbageclunk: http://<IP_ADDRESS>/~aim/xenial-server-cloudimg-amd64-disk1.img
[11:38] <babbageclunk> frobware: Thanks, I'll try that instead.
[11:38]  * frobware is unexpedtedly out of office today dealing with leaking pipes :(
[11:39] <babbageclunk> frobware: good luck!
[11:52] <babbageclunk> frobware: That worked, thanks.
[12:46] <mup> Bug #1616059 opened: Unit test failure in github.com/juju/juju/cmd/juju/application	 <juju-core:Triaged> <https://launchpad.net/bugs/1616059>
[13:11] <mgz> rick_h_: late pong
[13:16] <mup> Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:New> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:31] <mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:31] <mup> Bug # opened: 1425808, 1457575, 1474607, 1510651, 1513165, 1534643, 1538583, 1573136, 1580221, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633
[13:43] <mup> Bug # changed: 1425808, 1457575, 1474607, 1510651, 1513165, 1534643, 1538583, 1573136, 1580221, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633
[13:43] <mup> Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:46] <mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:46] <mup> Bug # opened: 1425808, 1457575, 1474607, 1493058, 1510651, 1513165, 1534643, 1538583, 1554088, 1573136, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633, 1615118
[13:51] <babbageclunk> voidspace: Did you have any trouble commissioning nodes in maas19?
[13:57] <natefinch> rick_h_: btw, that email you sent about moving bugs from juju-core to juju was only sent to cloud@canonical - should it have been sent to juju and juju-dev@ubuntu also?  Seems like it's pretty important for everyone to see it.
[13:58] <rick_h_> natefinch: yea, I guess I assumed folks are on the wider distribution lists
[13:58] <rick_h_> natefinch: we're going to send a new email today focusing on how to file bugs and to confirm the move and such
[13:58] <voidspace> babbageclunk: I didn't
[13:58] <babbageclunk> voidspace: No worries, worked it out - missed a step in DHCP setup.
[13:58] <voidspace> ah
[13:59] <natefinch> rick_h_: cool.  Yeah, I honestly rarely look at the cloud list, because it's fairly spammy, and obviously people outside canonical aren't on that list
[14:02] <rick_h_> katco: dimitern ping for standup
[14:17] <mup> Bug #1616098 opened: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <cpec> <juju-core:New> <https://launchpad.net/bugs/1616098>
[14:18] <mgz> rick_h_: mini thing, should I add cards to the board for the random tasks I end up picking up? (like changing the release tools behaviour with patches and such)
[14:19] <rick_h_> mgz: yes please
[14:20] <rick_h_> mgz: anything that's more than a couple of hours to jfdi
[14:20] <mgz> okay, thanks
[14:20] <mgz> that one was actually pretty short, but I'll make sure to add anything meatier
[14:24] <babbageclunk> Oh, of course trying to bootstrap to two maases at once gets all confused.
[14:25] <natefinch> rick_h_: so, should I continue working on the add-cloud stuff or... ?
[14:25] <rick_h_> natefinch: no, please grab a critical
[14:26] <natefinch> rick_h_: will do
[14:29] <mup> Bug #1616098 changed: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <cpec> <juju-core:New> <https://launchpad.net/bugs/1616098>
[14:55] <babbageclunk> dimitern: around?
[15:05] <dimitern> babbageclunk: yeah
[15:06] <babbageclunk> dimitern: hey! I'm just doing some manual testing of my machine undertaker worker (it works yay), but I want to try it with multi-nic containers.
[15:07] <babbageclunk> dimitern: Is that just a matter of setting up the hosts with multiple nics and those will show up bridged in the containers?
[15:10] <rick_h_> katco: ping, got a sec?
[15:10] <katco> rick_h_: yep
[15:10] <rick_h_> can you jump in https://hangouts.google.com/hangouts/_/canonical.com/developer?authuser=1 please?
[15:11] <dimitern> babbageclunk: you need to also use maas
[15:11] <natefinch> https://hangouts.google.com/hangouts/_/canonical.com/sorry-you're-fired?authuser=1
[15:11] <babbageclunk> dimitern: yeah, sorry, should have said that - that's what I'm testing on.
[15:12] <dimitern> babbageclunk: and all top-level nics that have children you want to bridge need addresses\
[15:12] <dimitern> babbageclunk: but having that should give you multi-nic containers
[15:16] <babbageclunk> dimitern: Awesome. And giving them addresses is just a matter of setting the nics to auto-assign in maas, right? Does it matter if they're all on the same subnet?
[15:17] <dimitern> babbageclunk: auto assign or static assign should work - dhcp or unconfigured won't (the latter set on a parent NIC will lead to br-parent not getting created)
[15:26] <babbageclunk> dimitern: Cool, it totally just works!
[15:26] <babbageclunk> dimitern: This juju thing's pretty neat.
[15:31] <dimitern> babbageclunk: awesome! :) when it works..
[16:44] <mup> Bug #1536477 changed: utils/debugstatus: test failure <juju-core:Fix Released> <https://launchpad.net/bugs/1536477>
[16:44] <mup> Bug #1538583 changed: manual provider add-machine fails immediately after bootstrap <add-machine> <ci> <manual-provider> <regression> <juju:Triaged> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1538583>
[16:44] <mup> Bug #1590161 changed: apiserver/client: panic: Session already closed <juju-core:Fix Released> <https://launchpad.net/bugs/1590161>
[17:28] <natefinch> rick_h_: did you get the logs for this bug? https://bugs.launchpad.net/juju/+bug/1610880
[17:28] <mup> Bug #1610880: Downloading container templates fails in manual environment <juju:Triaged by rharding> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1610880>
[17:29] <rick_h_> natefinch: yes, sec. Let me find that email
[17:32] <siv> Hi. I want to develop a juju charm which will go and  change the Openstack cinder service configuration file. created charm will perform this action post Openstack juju deployment. can I create a charm like this?
[17:34] <rick_h_> siv: yes, look into https://jujucharms.com/docs/2.0/authors-subordinate-services to help do something like that
[17:41] <siv> rich_h: Hi. I have an Ubuntu OpenStack autopilot setup. After the regular OpenStack install using AutoPilot, my created juju charm used to modify cinder driver settings. This is my intension.
[17:49] <siv> Can I modify the cinder driver settings post autopilot openstack deployment using my created charm?
[17:50] <mup> Bug #1616149 opened: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1616149>
[17:57] <siv> How do a newly created juju charm get certified? what is the procedure for that? how many days that it will take to get certify the newly created juju charm?
[18:11] <rick_h_> siv: check out https://jujucharms.com/docs/stable/authors-charm-store and https://jujucharms.com/docs/stable/charm-review-process
[18:13] <siv> rich_h : thank you
[18:26] <mup> Bug #1615958 changed: Switch to model name does't work anymore, admin should not be allowed to switch to users model <juju:New> <https://launchpad.net/bugs/1615958>
[18:26] <mup> Bug #1615960 changed: remove-machine and remove-application don't work on google cloud <juju:New> <https://launchpad.net/bugs/1615960>
[18:26] <mup> Bug #1616059 changed: Unit test failure in github.com/juju/juju/cmd/juju/application	 <juju:Triaged> <https://launchpad.net/bugs/1616059>
[18:26] <mup> Bug #1615986 opened: Agents failing, blocked by upgrade but no upgrade performed <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1615986>
[18:57] <bdx> postgresql-peeps: say I have an application that needs to connect to 2 separate postgresql applications
[18:58] <bdx> postgresql-peeps: is there a way to react to the states of the same service under a different name? Is this done by providing service sensitive interface names?
[18:59] <bdx> charmers:^
[19:04] <bdx> eeeh, s/postgresql applications/postgresql db instances/
[19:04] <marcoceppi> bdx: hey
[19:05] <marcoceppi> bdx: might be better to ask in #juju
[19:05] <marcoceppi> bdx: but you can define two different relations with the same interface
[19:05] <marcoceppi> and that way have a scope of reacting to each relation name
[19:14] <bdx> my bad, thought I was on #juju ... grr
[19:14] <marcoceppi> bdx: no worries! does my reply make sense?
[19:15] <bdx> yes, can you give more context in #juju though?
[19:37] <natefinch> sigh... the instructions for bootstrapping to manual don't actually work :/ https://jujucharms.com/docs/stable/clouds-manual
[19:50] <mup> Bug #1474607 changed: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure <ci> <go1.5> <go1.6> <regression> <windows> <juju:Fix Released by axwalk> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1474607>
[19:50] <mup> Bug #1616197 opened: juju restore-backup error <juju-core:New> <https://launchpad.net/bugs/1616197>
[20:08] <bdx> marcoceppi: i see now
[20:08] <bdx> marcoceppi: thx
[20:08] <bdx> exactly what I was thinking
[20:31] <alexisb_> thumper, ping
[20:32] <thumper> alexisb_: hey
[20:33] <alexisb_> thumper, can you take a look at htis bug: https://bugs.launchpad.net/juju/+bug/1616158
[20:33] <mup> Bug #1616158: Int overflow during build for Windows <blocker> <ci> <regression> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1616158>
[20:33]  * thumper looks
[20:33] <alexisb_> https://github.com/juju/juju/commit/5ac0e259560382ea0c0e2a4120e028f2613ed857
[20:33] <alexisb_> ^^ this is the suspect commit
[20:36] <natefinch> we don't build x86 anymore, do we?
[20:36] <thumper> alexisb_: poo
[20:36] <thumper> alexisb_: mgo is assuming a 64 bit int
[20:36] <thumper> seems that windows still specifies 32?
[20:36] <natefinch> thumper: only if we're specifying a 32 bit architecture
[20:37] <thumper> natefinch: thoughts on the bug https://bugs.launchpad.net/juju/+bug/1616158
[20:37] <mup> Bug #1616158: Int overflow during build for Windows <blocker> <ci> <regression> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1616158>
[20:37] <thumper> mgo.v2/bson/json.go:320: constant<PHONE_NUMBER>740992 overflows int
[20:37] <natefinch> thumper: yeah, I was just looking at it.
[20:38] <thumper> int is a signed integer type that is at least 32 bits in size
[20:38] <thumper> ^^ language spec
[20:38] <thumper> how can we find out how many bits the int uses?
[20:40] <natefinch> thumper: if you build with GOOS=windows GOARCH=amd64 it works fine  if you build with GOARCH=386 regardless of OS (windows or linux) it fails
[20:40] <natefinch> so... let's not build with GOARCH=386
[20:41] <natefinch> there's something tickling inside my head that says we were doing that on purpose for some reason... but I can't remember why now
[20:41] <natefinch> sinzui: do you know why we're building juju for windows as 32 bit?
[20:41] <mup> Bug #1616149 changed: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Won't Fix> <https://launchpad.net/bugs/1616149>
[20:42] <thumper> natefinch: can you try replacing line 320 with this:
[20:42] <thumper> if int64(n) <= 1<<53 {
[20:43] <thumper> and then test the 386
[20:44] <natefinch> sure.. you can do it too (just sayin').  cross compile in go 1.5 and up is just "GOOS=windows GOARCH=386 go build ./..."
[20:44] <thumper> hmm...
[20:44] <thumper> ok
[20:45] <thumper> ok that works
[20:45] <thumper> alexisb_: we have two choices
[20:45] <thumper> alexisb_: stop building the windows client with GOARCH=386
[20:45] <thumper> alexisb_: or patch mgo
[20:47] <natefinch> either way, we should file a bug against mgo... I'm sure it was not intentional to break 386
[20:47] <sinzui> natefinch: yes, *you* explained we should because Windows 64 bit is not common. We never chnged the rules you wrote.
[20:47] <thumper> heh
[20:48] <sinzui> natefinch: If you believe 64bit clients are good for windows, we can change the build script in a few hours
[20:49] <thumper> apparently 32 bit versions stopped with windows 7 and vista
[20:49] <thumper> oh
[20:49] <thumper> no
[20:49] <thumper> 8.1 can still be in 32 bit
[20:50] <thumper> we should support 32 bit still
[20:50] <thumper> so... patch mgo
[20:50] <thumper> and file a bug etc etc
[20:50] <natefinch> I guess so.  honestly, I doubt anyone actually runs 32 bit windows anymore, but if 8.1 supports it, we probably should too
[20:51] <alexisb_> we dont support 32 bit linux
[20:51] <natefinch> and yes, 32 bit applications run on both 32 bit and 64 bit windows... the reverse is not true.
[20:51] <alexisb_> why would we do that for windows?
[20:51] <sinzui> thumper: natefinch : I the client is needs about 5 lines of change to switch to 64 bit when you are ready. We just match the rules of the win agent
[20:51] <natefinch> alexisb_: previously, presumably because it was free
[20:51] <perrito666> alexisb_: I believe that is because ubuntu no longer builds for 32
[20:51] <natefinch> alexisb_: i.e. no extra work
[20:52] <thumper> well... how many people likely to be using juju will be using 32 bit windows?
[20:52] <thumper> perhaps we just make it 64 bit and see who screams?
[20:53] <thumper> alexisb_: who makes this call?
[20:53] <alexisb_> sinzui, do we have stats on 32 bit windows client downloads
[20:53] <sinzui> alexisb_:  to be clear, agents cannot be 32 bit in clouds. and Ubuntu doesn't support 32 bit server anywhere. Clients are in a grey area. Ubuntu makes 32 bit clients and we don't say no.
[20:54] <sinzui> alexisb_: I can get them from the milestone pages
[20:56] <natefinch> alexisb_:  the problem is, we can't tell if people downloading have 32 or 64 bit windows, since the 32 bit download is all we offer.
[20:57] <natefinch> pretty sure you haven't been able to buy a machine with 32 bit windows in several years.... so the only people with 32 bit would be those who upgraded an old machine
[20:58] <thumper> Given today's hardware and defaults, I think we'd be fine saying 64 bit only windows...
[20:58] <thumper> I'll file a bug on mgo though
[21:01] <natefinch> gotta run to dinner, back in a bit
[21:02] <thumper> https://github.com/go-mgo/mgo/issues/325
[21:26] <thumper> simple review for someone: http://reviews.vapour.ws/r/5516/
[21:34] <perrito666> thumper: shipit, btw, you used the wrong dialect of markup
[21:34] <thumper> :)
[21:40] <thumper> w00t, current master lets me do this: `juju debug-log --replay --color --location | less -R`
[21:40] <thumper> for show me the log in color, no tail
[21:40] <thumper> marcoceppi, jcastro: ^^
[21:45] <mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <cdo-qa-blocker> <sts> <sts-needs-review> <juju:Fix Released by thumper> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1513165>
[22:21] <mup> Bug #1421270 changed: juju deploy failure WebSocketConnection closed <api> <oil> <oil-bug-1372407> <juju-core:Won't Fix> <juju-deployer:Invalid> <https://launchpad.net/bugs/1421270>
[22:32] <wallyworld> redir: did you want to chat?
[22:32] <redir> y
[22:32] <redir> brt
[22:33] <marcoceppi> thumper: --color isn't default ;)
[22:33] <thumper> marcoceppi: yes it is
[22:34] <marcoceppi> oh, well I saw it explicitly called out
[22:34] <thumper> marcoceppi: but just like ls, if it isn't a terminal, it isn't there by default
[22:34] <marcoceppi> oh, because of the detection stuff, nvm
[22:34] <thumper> :)
[22:57] <perrito666> meh, squid never comes ok out of a reboot
[23:11] <thumper> perrito666: oh, is that what does it?
[23:11] <thumper> hadn't worked that out
[23:11] <perrito666> thumper: at least for me, needs to restart squid-deb-proxy
[23:11] <thumper> do you clear out the cache as well?
[23:11] <thumper> I had always assumed that was necessary
[23:14] <perrito666> thumper: I find it empty, I assume it empties on reboot?
[23:14]  * thumper shrugs
[23:14] <perrito666> nah, that is not the cache, my bad
[23:14] <perrito666> was looking at wrong dir
[23:14] <perrito666> I dont clean it
[23:18] <wallyworld> alexisb_: standup? we miss you
[23:32] <babbageclunk> Hey thumper! Long time no see.
[23:32] <thumper> o/
[23:32] <babbageclunk> Could you review this for me? https://github.com/juju/gomaasapi/pull/56
[23:37] <babbageclunk> thumper: ^^
[23:38]  * thumper looks
[23:41] <thumper> babbageclunk: LGTM
[23:41] <babbageclunk> thumper: Awse. Thanks!
[23:48] <perrito666> is it me or we all sound like daft punk songs in this call?


[05:33] <thumper> ok peeps
[05:33] <thumper> what is the difference between a driver and a maintainer for a project?
[05:34] <thumper> is it documented anywhere?
[05:35] <micahg> thumper: https://help.launchpad.net/Projects/Registering#Roles_within_projects
[10:01] <benonsoftware> Launchpad downtime now?
[10:01] <benonsoftware> Ah silly me, back up now
[10:01] <wgrant> Was back about a second after you asked :)
[10:02] <benonsoftware> ;)
[15:37] <craiger> is there a way to ascertain a users launchpad ID from their email address?
[15:47] <dobey> craiger: you can find a person on lp by e-mail address, via the API, yes
[15:50]  * craiger was browsing the site
[16:24] <BlessJah> i'm getting (OOPS ID: 2350carambolalaunchpad572) while trying to log in using LPs OpenID
[21:35] <dobey> is there a trick to get lp to stop timing out on bugs with more than about 6 tasks?
[21:35] <dobey> OOPS-ba2632464afeff07697ba1a31339573f
[21:42] <BlessJah> i'm getting (OOPS ID: 2350carambolalaunchpad572) while trying to log in using LPs OpenID
[23:53] <wgrant> BlessJah: Can you file a support request at https://forms.canonical.com/lp-login-support/?


[00:11] <Mizutsuki> hello, I was wondering if there is anything I could do to increase the oddds that a developer might spare some attention for a particular bug that affects me?
[00:12] <Mizutsuki> It's a java swing bug, it probably has something to do with x11, though I'm not sure
[00:27] <bdmurray> nullack: what show stopper bug is this?
[00:27] <nullack> Brian one moment pls
[00:28] <nullack> bdmurray: Bug 261995
[00:28] <james_w> Mizutsuki: hi, if you give the bug number it helps with people giving advice.
[00:29] <Mizutsuki> 240818
[00:29] <james_w> bug 240818
[00:29] <Mizutsuki> james_w: that one's not mine, mines the one set to this one as a duplicate, 'cause there was more interest in this one, it sems
[00:29] <james_w> Mizutsuki: if you can hang on for half an hour I'll have a bit of time
[00:30] <james_w> otherwise someone else might
[00:30] <Mizutsuki> james_w:unfortunately, in half an hour work ends and I'll be out of here ^_^
[00:30] <james_w> you could try
[00:30] <james_w> #ubuntu-java
[00:30] <james_w> but it's a *really* bad time right now
[00:30] <Mizutsuki> why's that?
[00:31] <james_w> there's a freeze in 28 minutes, so it's a bit of a rush
[00:34] <Mizutsuki> ah, the feature freeze for 8.10... I see
[00:34] <Mizutsuki> alright, well then I'll just leave it for tomorrow
[00:38] <ogasawara> bdmurray:  dunno, but the last comment makes it seem to be hal related
[00:38] <ogasawara> bdmurray: sheesh, I didn't expect people to be testing 2.6.27 already!  now I gotta tweak my call for testing script
[00:39] <nullack> Its in Intrepid now mate youll get lots of em using it :)
[00:40] <ogasawara> ah nullack:  can you attach some logs files for debugging hal
[00:40] <nullack> Sure, anything to help. What ones you want?
[00:40] <bdmurray> There should be a DebuggingHal page
[00:40] <ogasawara> nullack: yah, lemme find the link for ya
[00:40] <nullack> ok will take a look
[00:40] <nullack> While were at it, anyone want to look at another one I raised? lesser priority :)
[00:41] <nullack> bug 26027
[00:41] <ogasawara> nullack: https://wiki.ubuntu.com/DebuggingHal
[00:41] <nullack> bug 262027
[00:41] <ogasawara> nullack: additionally dmesg output might be good too
[00:41] <nullack> Im on it, will ping when its attached to LP
[00:42] <ogasawara> nullack: k, thanks
[00:42] <nullack> bug 262027 erked me in particular cos I dont like the system saying its ok when it failed
[02:06] <mrooney> hggdh: I don't know, it is weird
[02:06] <mrooney> It really worked flawlessly with 0 errors when I ran it
[02:13] <qwerty6523> hi
[02:13] <qwerty6523> how to find bugs to help fix
[02:13] <mrooney> qwerty6523: hi
[02:13] <qwerty6523> how do i*
[02:13] <mrooney> well, you want to look in the topic, specifically, http://wiki.ubuntu.com/HelpingWithBugs
[02:14] <qwerty6523> thanks
[02:14] <mrooney> hggdh_: I don't know, it is truly a mystery
[02:15] <hggdh_> mrooney, I will have a look at it tomorrow. This sounds more like some sort of python thing than really network
[02:15] <hggdh_> under the same LAN, same firewall(s), my xchat session usually stays up until I reboot
[02:15] <mrooney> hggdh_: yes, it is strange
[02:15] <hggdh_> indeed...
[02:16] <mrooney> it worked fine on my eeepc and this laptop, but they were both on the same network
[02:16] <bdmurray> Isn't the problem connecting to Launchpad though?
[02:16] <mrooney> so it might be some particular of my network that let it work fine
[02:16] <hggdh_> bddebian, we are not yet sure
[02:16] <hggdh_> maybe LP, maybe freenode
[02:16] <hggdh_> dammit, not bd debian, but bdmurray ^^
[02:17] <bdmurray> I thought it was announcing more than one at time which sounded to me like a connectivity to find out about new bugs issue but...
[02:17] <hggdh_> mrooney, can I su - to your account later on? (on xibiu, I mean)
[02:18] <hggdh_> it seems it loses the connection, and then the python code automatically retries it
[02:18] <hggdh_> mrooney, you are running it under screen, and I do not have a log on disk to look at
[02:18] <mrooney> ooooh
[02:18] <mrooney> it isn't http
[02:19] <mrooney> it is getting an error 110 on sending to the IRC socket
[02:19] <mrooney> hggdh_: sure, you can do whatever you want, it's your machine :D
[02:20] <hggdh_> mrooney, its my machine, but it is your account :-)
[02:20]  * mrooney grants hggdh_ full access :)
[02:20] <mrooney> it is getting a timeout on sending to the socket, how mysterious
[02:21] <hggdh_> yes, but which socket? the LP one, or the freenode?
[02:22] <mrooney> freenode
[02:22] <hggdh_> ah
[02:22] <mrooney> I am using a raw socket for that one, for the http I am using feedparser
[02:22] <mrooney> which seems to be working fine
[02:22]  * hggdh_ wonders about timing
[02:23] <hggdh_> mrooney, how often it gets hit by the timeout? You know?
[02:24] <mrooney> well, every time EeeBotu leaves the channel...unfortunately I didn't put timestamps in the error output
[02:24] <hggdh_> np. I will set it up on a different channel and will monitor it as needed. This is a standard Hardy server, no special drivers/kernel
[02:42] <mrooney> hggdh_: okay it is logging all stdout and stderr to logFile
[02:42] <mrooney> with timestamps, now
[02:44] <mrooney> oh hehe I can't commit, my SSH key isn't on that server :}
[02:47] <mrooney> bdmurray: though even if I logged everything, to be honest, I really feel something odd is going on with that atom feed
[03:00] <mrooney> bdmurray: since the feed constantly changes, here is a snapshot: http://img517.imageshack.us/img517/7879/bugsatomfeedtx4.png , notice the bottom three are in reverse order contrary to the overall chronologically ascending order, though the second to top is also off.
[03:03] <mrooney> okay, bedtime for me, let me know what you think though, I should see it
[06:35] <tuxmaniac> LaserJock: still around? I tried maxima from Debian unstable. Fails to build in intrepid.
[06:36] <LaserJock> yeah, needs newer gcl
[06:36] <LaserJock> it really is too bad that maxima requires gcl. It's such a great app but hard to keep updated
[06:37] <tuxmaniac> so I left it and went off to sleep. Saw your mesage at #u-motu. Now that freeze is over, am not sure whether we will be able to get maxima in :-(
[06:37] <tuxmaniac> good morning everybody btw :-)
[06:38] <dholbach> good morning
[06:39] <LaserJock> hi dholbach
[06:39] <tuxmaniac> dholbach: hi
[06:39] <dholbach> hi LaserJock, hi tuxmaniac
[08:39] <mcas> i have a question about todays bugday
[08:40] <mcas> i am looking for a bug report but this one should be fixed upstream but i still have this problem...
[08:40] <mcas> now i don't know if it is a problem with the german locale
[08:41] <mcas> it's about bug 120672
[09:05] <gnomefreak> mcas: hold on
[09:05] <gnomefreak> i know we didnt fix it yet
[09:06] <gnomefreak> mcas: we cant really fix it in Hardy
[09:06] <gnomefreak> only INtrepid will get it
[09:06] <mcas> ok
[09:06] <mcas> thats why i ask for it ;-)
[09:07] <gnomefreak> mcas: unless asac slips it past but its not a SRU
[09:07] <gnomefreak> mcas: i can always build it for my PPA for hardy
[09:07] <gnomefreak> but i would like to wait to find out what asac plans on doing
[09:08] <mcas> ok than i'll wait, too
[09:08] <gnomefreak> ok i pinged him but hes most likely still sleeping
[09:08] <gnomefreak> he will reply when he gets here
[09:08] <mcas> if there is something new just ping me
[09:09] <gnomefreak> mcas: will do
[09:09] <mcas> thx
[09:12] <mcas> can someone tell me how i can edit the wiki page so that my nick is directly linked?
[09:13] <mcas> is there a special tag?
[09:43] <gnomefreak> mcas: no feature work on 2.0 branch in hardy
[10:07] <mcas> thank you gnomefreak
[10:07] <mcas> i change it to won't fix?
[10:13] <mcas> or better fix commited and a comment that there will no feature work on 2.0 branch in hardy, gnomefreak?
[10:13] <gnomefreak> asac: would you like that tbird bug closed or target for 3.0
[10:14]  * gnomefreak should really keep his pings to one channel
[10:14] <mcas> :-)
[10:16]  * gnomefreak just waits for console-tools to get fixed
[10:16] <asac> which bug in particular?
[10:17] <mcas> bug 120672
[10:17] <mcas> hi asac
[10:19] <asac> unlikely that that gets fixed in 2.0
[10:20] <asac> you should try out 3.0 and if its not there report it upstream
[10:20] <mcas> is there a thunderbird 3.0 version?
[10:20] <mcas> the report looks like it was fixed upstream
[10:33] <geser> thekorn: should py-lp-bugs 0.3 work with edge? because I get an parse error about BugReport.__nickname
[10:45] <thekorn> geser: it should work, but I just found out that things on edge changed again,
[10:45] <thekorn> will look at it in a bit, and run some tests
[10:46] <geser> thanks
[10:47] <geser> do you need the traceback?
[10:51] <thekorn> geser: no, thanks
[10:51] <thekorn> it's enought to know that it fails at parsing the nickname
[11:01] <thekorn> geser: I can reproduce it, filed bug 262192
[11:30] <thekorn> geser: commited fix as revision 158 of the .main branch
[12:32] <slhk> Hi, I need assistance in marking bugs as duplicate
[12:33] <slhk> they have a different "affects" project
[12:34] <slhk> should I add the missing project as  also affected?
[12:36] <knorr> slhk: Well, I guess that depends if the projects affected both are correct?
[12:38] <slhk> knorr: I'm not sure, but I think the one actually present is wrong, and the one on the duplicate bug is the right one
[12:39] <knorr> slhk: What are the bug numbers?
[12:40] <slhk>  Bug 224774 is a duplicate of  Bug 212388
[12:43] <slhk> knorr: Bug 224774 is a duplicate of  Bug 212388
[12:43] <knorr> slhk: It's not the same traceback
[12:44] <slhk> knorr: do you mean different python version?
[12:46] <knorr> slhk: No different DbusExceptions. Look at the last line in both tracebacks. One seems to be a permission/policy issue. The other I don't know.
[12:47] <slhk> knorr: Oh, ok! I'm sorry
[12:48] <knorr> slhk: But that's just my 2 cents. I'm new to the bugsquad.
[12:50] <slhk> knorr: I'm newer than you, thanks for your help
[12:52] <knorr> slhk: Didn't think that was possible. ;) But in general, you should look for the info in the bug report and not just the title when marking duplicates.
[12:53] <slhk> knorr: I looked at the description but I missed the traceback, maybe it could be suggested on the wiki
[13:02] <snadge> has anyone else experienced not being able to finish bootup after installing the new kernel update? :P
[13:02] <snadge> i had to kill some dkms processes for it to continue booting.. and now nvidia driver isnt loading ;)
[13:05] <Hobbsee> snadge: where's your nvidia driver from?
[13:08] <snadge> its the ubuntu restricted nvidia driver
[13:09] <knorr> snadge: I had the same problem, but a simple disable/enable in the Restricted Drivers GUI fixed it.
[13:12] <snadge> the dkms part is hanging, on installing the previous kernel
[13:12] <snadge> and it seems to do that on bootup now as well
[13:15] <popey> does anyone know the name of the program that pops up when you insert a cdrom containing a repository? I'd like to file a bug agsinst it but dont know what it is
[13:15] <popey> and i dont have a cd with a repo on to hand to _make_ it pop up
[13:29] <snadge> ok so now i have nvidia back (by reverting to kernel -20) but sound doesnt work :/
[13:30] <snadge> and dkms still causes the bootup to hang until i kill the dkms_autostart process
[14:12] <snadge> ok, so after latest nvidia driver and kernel update.. -rt kernel fails to load nvidia
[14:13] <snadge> -generic is ok.. but im still getting the strange dkms problem, and also shutdown also hangs.. after stopping samba processes.. have to sysrq sync, unmount, boot
[14:13] <snadge> blows :(
[14:15] <snadge> (hardy proposed)
[14:39] <tuxmaniac> any user of matplotlib around to test bug 246239. If someone could give me the code to test I can do that on my hardy too.
[14:47] <rbrunhuber> Is bug 261147 a duplicate of bug 259278?
[15:06] <bddebian> Boo
[16:35] <mrooney> okay time to get back on the bay!
[17:15] <ckyle> x
[17:24] <bdmurray> pedro_: What do you think of bug 253118?
[17:24] <pedro_> bdmurray: looking
[17:26] <pedro_> well network-manager now has the "edit connections" dialog so i don't see why it should depends on gnome-network-admin...
[17:28] <bdmurray> pedro_: ah, and I don't see "Manual Configuration" as a menu item either
[17:29] <pedro_> bdmurray: that's correct it was removed, network manager (nm-connection-editor)  handle those now
[17:29] <bdmurray> pedro_: Okay, they probably just saw it at an odd time, I'll follow up with them
[17:30] <james_w> yeah, check they've got nm 0.7 installed
[17:30] <pedro_> bdmurray: yup, rock thanks
[17:34]  * pedro_ editing his location on launchpad
[17:35] <bdmurray> pedro_: hmm?
[17:35] <pedro_> that's a pretty neat new feature
[17:35] <pedro_> bdmurray: look at your profile
[17:35] <pedro_> now launchpad has an integration with google maps
[17:36] <pedro_> edge only i guess
[17:36] <bdmurray> ah! I see now
[17:43] <Ampelbein> hi! could some member of bug-control please check on bug #260910 ? I added the upstream-bugwatch and think the bug could be set to triaged.
[17:43] <Ampelbein> Thanks.
[17:47] <pedro_> Ampelbein: done, thanks you
[17:48] <Ampelbein> pedro_: thanks.
[18:04] <Ampelbein> Now, I have a question on bug #105818 . First of all I think it could be set to triaged/low, now the questions: 1. Is the tag "packaging" correct, since a change in "debian/control" would fix the problem? 2. Is there any team/person to subscribe the bug to?
[18:05] <Ampelbein> Oh and 3. Should this also be reported to debian?
[18:07] <techno_freak> Ampelbein, if you know how to fix it, you can volunteer to make a debdiff for the same and attach it  ;)
[18:09] <Ampelbein> techno_freak: ok, i'll try that. i guess ubuntu-main-sponsors is then to be subscribed since it is published in main?
[18:11] <techno_freak> Ampelbein, righto
[18:11] <Ampelbein> techno_freak: ok, thanks.
[18:11] <techno_freak> Ampelbein, thanks for trying to help us :)
[18:16] <Ampelbein> And another one ;-) : Bug #155765 - I think it could be set to status triaged, but i'm unsure what importance to suggest. I tend to "low" since the loss of usability is not severe.
[18:19] <chrisccoulson> i've just reported a compiz crash using Apport. It's assigned to Compiz at the moment, but I think the problem is my video driver (it started happening after fitting a brand new nvidia card yesterday). could someone take a quick look and tell me what they think? I'll reassign it to the correct package then
[18:19] <chrisccoulson> bug 262334
[18:19] <chrisccoulson> seems its already been re-assigned!
[18:20] <james_w> Ampelbein: "packaging" is right I think. "bitesize" may be appropriate if it looks easy
[18:21] <james_w> Ampelbein: but in this case I'm not sure a conflict is appropriate.
[18:23] <Ampelbein> james_w: why not? seahorse and gnupg-agent provide the same functionality and i see no need for having both of them installed.
[18:23] <james_w> but no reason is not justification for a conflict
[18:24] <james_w> perhaps they shouldn't be installed together, but I imagine it's more likely there is just a bug to fix
[18:26] <Ampelbein> james_w: ok, then i will report the issue upstream. it just seemed as the easiest way to avoid having this issue.
[18:32] <Ampelbein> Ok, now i added the upstream-report and removed the packaging tag. Now i think it could be set to triaged/low? (bug #105818)
[19:42] <mattik> Hello, I have Asus Laptop with Finnish keyboard and arrow keys doesn't work in Kubuntu Intrepid. I have tried keyboard layouts as Asus Laptop and 105-buttons keyboard. Is this reported bug?
[19:43] <mattik> and at-character diesn't work, too
[19:43] <mattik> doesn't
[19:43] <knorr1> mattik: There was a reported issue some while ago about the up-arrow being mapped as printscreen. I had it as well, but it have been resolved.
[19:44] <mattik> knorr1: do you use KDE4?
[19:45] <Knorr> mattik: Nope, that was in Gnome. Sorry, didn't see the (K)ubuntu. ;)
[19:45] <mattik> Ubuntu keyboard works right
[19:47] <mattik> In Kubuntu I selected Finnish for Keyboard language and after this it doesn't work
[19:48] <Knorr> Okay, so it's layout specific. Well I don't really know anything about that I'm sorry. But haven't seen any bugs about it. Not the same as saying there isn't one.
[19:48] <yuriy> mattik: I have run into that before and it went away. somebody else has reported a bug on it, check launchpad
[19:49] <mattik> Knorr: Thank you. It is reported that firefox crashed in paypal-page?
[19:50] <mattik> yuriy: thank you :) Do you get a crash
[19:51] <yuriy> what crash?
[19:51] <mattik> firefox in paypal.com
[19:52] <yuriy> mattik: do you know about lanuchpad, the bug tracker?
[19:52] <yuriy> mattik: no, haven't had any such problem
[19:52] <yuriy> *launchpad
[19:52] <mattik> yes, I know but I have reported really much bugs what are duplicate and I don't trust myself
[19:53] <yuriy> mattik: use the search...
[19:53] <mattik> I have tried
[19:53] <yuriy> mattik: https://bugs.launchpad.net/ubuntu/+bug/255861
[19:54] <mattik> yuriy: thank you :)
[20:08] <mattik> yuriy: I found it paypal error what is founded in Hardy first
[20:09] <mattik> has found
[20:10] <mattik> I try will it crash on Gnome. Thank you :)
[20:57] <CarlFK> how can I see what files are in a .deb?
[20:57] <jpds> CarlFK: dpkg -L
[20:57] <CarlFK> guessing it is some kind of archive - tar and zip didn't like it
[20:59] <jpds> CarlFK: No, wait, it's dpkg-deb --contents filename.deb
[20:59] <CarlFK> bingo.  thanks
[21:07] <mouz> I just marked 4 bugs as duplicates of bug 150252. Is there anything else I can do for the bug? Should I for instance nominate it for releases?
[21:08] <mouz> https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/150252
[21:29] <CarlFK>  dpkg-deb --contents linux-restricted-modules-2.6.27-1-generic_2.6.27-1.1_i386.deb|grep ath_pci
[21:29] <CarlFK>  -rw-r--r-- root/root     20304 2008-08-27 08:37 ./lib/linux-restricted-modules/2.6.27-1-generic/ath_pci/ath_pci.mod.o
[21:29] <CarlFK> that may be a mistake
[21:44] <Knorr> Just got bug 260931 marked as a duplicate of bug 257376 based on the traces being similar. Am I the only one who finds those traces nothing like each other?
[21:45] <Knorr> https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/260931
[21:45] <Knorr> https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/257376
[21:48] <pedro_> Knorr: may you reply on the bug then?
[21:50] <Knorr> pedro_: Is that a trick question? (If you mean I should just ask in the bug, the answer would be that I just wanted a second opinion before doing so)
[21:50] <pedro_> Knorr: no is not
[22:03] <james_w> bdmurray: hi, are you around? I need the bugmaster.
[22:03] <bdmurray> james_w: Here I come to save the day!
[22:03] <bdmurray> ;-)
[22:04] <james_w> calm down everyone, bdmurray is here.
[22:05] <james_w> bdmurray: we're going to have to be paying more attention to escalating bugs and adding them to the RC list as we get closer to release. Do we have guidelines on the best way to do this?
[22:05] <james_w> are people asked to nominate bugs as they see fit, and then the list of nominations will be processed accordingly?
[22:06] <bdmurray> james_w: the list of nominations is a bit long at the moment, ~300ish, and the number of people who review the nominations is quite small
[22:07] <james_w> is it small as we want it to be small, because there aren't many people qualified, or because we haven't added anyone recently?
[22:07] <bdmurray> james_w: One thing we'd talked about at UDS was using the bugsquad mailing list
[22:07] <bdmurray> after establishing criteria for escalation
[22:08] <bdmurray> the group is small due to Launchpad organization
[22:09] <bdmurray> The group that can manage nominations includes Uploaders and Drivers
[22:09] <james_w> I can see the benefits of using the mailing list, but it's a bit of a concern that it would be more work than just nominating, and so we would punish the people that were doing it properly
[22:10] <james_w> and lots of users nominate just in an effort to get their bug looked at or worked on
[22:11] <james_w> when is the next QA meeting?
[22:12] <bdmurray> I believe that nomination would be the ideal process however, from a practical standpoint only 4 people could be said to regularly reviewing those
[22:13] <bdmurray> The QA meetings are every Wednesday
[22:14] <james_w> would this be a suitable agenda item for the next one?
[22:14] <james_w> it may be that this is all pretty clear, and so a meeting wouldn't really help.
[22:16] <Ampelbein> Sorry to interrupt. Could some member of bug-control please check on bug #257415 ? I think it could be set to triaged/low importance.
[22:16] <bdmurray> I think talking about it could help.  To me it seems that there may be 2 separate issues though.  1) how to escalate bugs and 2) how to deal with the quantity of nominations
[22:17] <Knorr> Ampelbein: It's already tagged as Confirmed and filed upstream?
[22:18] <Ampelbein> Knorr: yes.
[22:18] <Ampelbein> Knorr: did confirm it and filed upstream
[22:18] <Knorr> Ampelbein: No need to tag it as triaged then. ;)
[22:19] <Knorr> Ampelbein: Actually it's already fixed upstream it seems. Could be tagged as Fix Released then
[22:19] <hggdh> bug 257415
[22:20] <hggdh> Knorr, only if the fix is already available on our repositories
[22:20] <Knorr> hggdh: Okay, I see.
[22:20] <Ampelbein> Knorr: Hmm. From the wiki: <Triaged> Use this when you are confident that it should be looked at by a developer and has enough information. So I thought this should be the status to set when everything is done and the developers are looking at it.
[22:21] <Ampelbein> ubottu seems dead... https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/257415
[22:21] <bdmurray> james_w: Does that make some sense?
[22:21] <james_w> bdmurray: I agree that there are two issues.
[22:22] <james_w> bdmurray: I think we should have guidelines soon, and make them clear to everyone so that people know what to do. For whether this involves a meeting or not I'll defer to you.
[22:22] <bdmurray> james_w: It'd be interesting to try and find out how frequently bugs are nominated - so if the number of nominations became 0 how many there would be to deal with.
[22:23] <james_w> bdmurray: if you think so then can I suggest dropping a mail to -devel inviting the release team and other interested parties to the next meeting to discuss it?
[22:23] <james_w> bdmurray: yeah, do you know of a way of doing that?
[22:23] <hggdh> Ampelbein, as soon as we are guaranteed the fix has made it to SVN, we can mark fix committed
[22:24] <Ampelbein> hggdh: ups. just marked it fix commited because upstream-developer said it was fixed.
[22:24] <bdmurray> james_w: I imagine its in the db somewhere but I don't recall looking at nomination dates before
[22:24] <Knorr> Ampelbein: My mistake. I ment ofcourse Fix Committed instead of Fix Released
[22:25] <Ampelbein> Knorr: you were right, i didn't notice before that upstream already took care of it.#
[22:25] <james_w> bdmurray: as for the question about how to deal with the quantity I think we should have a discussion at some point, and then work with lp to get what we want implemented for the next freeze.
[22:25] <Ampelbein> Knorr, hggdh: and its already in the trunk-changelog.
[22:26] <Ampelbein> http://svn.gnome.org/viewvc/seahorse/trunk/ChangeLog?view=log
[22:26] <bdmurray> james_w: the quantity of nominations or the quantity of reviewers?
[22:26] <james_w> bdmurray: cool, that will be useful information. Can you also get the percentage accepted?
[22:26] <hggdh> Ampelbein, good!
[22:27] <james_w> bdmurray: well, deal with the quantity of nominations, which may involve increasing the number of reviewers.
[22:27] <bdmurray> james_w: for Intrepid? probably
[22:28] <james_w> bdmurray: focusing on nominations for the development release is important I think, SRUs are a different thing in this case I think.
[22:30] <bdmurray> so any information about the rate of nominations could be misleading if more people start using it
[23:38] <CarlFK> what is the package name for the .27 kernel?
[23:40] <hggdh> linux-image-2.6.27-1-*
[23:40] <CarlFK> kernel-image-2.6.27-2-generic-di  what is the -di ?
[23:41] <CarlFK> linux-image-2.6.27-1-generic  there we go.
[23:41] <hggdh> I do not know about this package


[05:30] <ahoneybun> hey valorie
[05:34] <valorie> hi ahoneybun
[05:34] <valorie> how was your xmas?
[05:34] <ahoneybun> how are you doing?
[05:34] <ahoneybun> good
[05:34] <valorie> oh excellent, I just ate some of the chocolate Santa left for me
[05:34] <valorie> :-)
[05:34] <valorie> plus, I got the coffee grinder I wanted
[05:34] <valorie> and other cool stuff
[05:35] <ahoneybun> sweet
[05:35] <valorie> you still liking your htc one?
[05:35] <ahoneybun> yep
[05:36] <valorie> did you root it?
[05:36] <ahoneybun> trying AOKP nightly so yea
[05:36] <valorie> wowzers
[05:36] <valorie> I don't mind sense
[05:37] <ahoneybun> they released a build for my phone on xmas
[05:37] <valorie> I did move that feed thing off the home screen
[05:37] <ahoneybun> so I was like "OHHHH YEAAA"
[05:37] <ahoneybun> I liked Sense
[05:37] <ahoneybun> made a back up of Stock just in case
[05:39] <valorie> hahahah, I'm watching the Rachel Maddow show, and they are doing a recap of "The Best New Thing" bits -- did you see the Ukrainian dog that looks like Putin?
[05:39] <valorie> such a nice way to look back over last year
[05:40] <ahoneybun> lol nope
[05:41] <valorie> http://nymag.com/daily/intelligencer/2013/09/putin-dog-photo-looks-like-russia.html
[05:41] <valorie> http://www.youtube.com/watch?v=wiKKU3rU5oM
[05:43] <ahoneybun> lol
[05:45] <valorie> it's an amazing resemblance
[05:45] <ahoneybun> yea
[05:46] <valorie> this is the best hour of year, lol
[05:47] <ahoneybun> I got my 23 inch monitor up
[05:50]  * valorie sticks with the lappy
[05:57] <ahoneybun> yea
[05:59] <ahoneybun> i have my laptop as well
[05:59] <valorie> I prefer laptops, and have no desktop box
[06:01] <ahoneybun> only thing I have right now
[06:07]  * ahoneybun is waiting for people to review the docs
[06:09]  * valorie is waiting for the contractors to finally arrive
[06:09] <valorie> supposedly 8am tomorrow
[06:09] <ahoneybun> ok
[06:09] <ahoneybun> nice'
[06:10] <valorie> after the demolition, it will be
[06:10] <valorie> I hope
[06:23] <ahoneybun> yea
[06:28] <ahoneybun> oh docs
[07:14] <soee> good morning
[07:22] <soee> someone else has lately: kded4 PID: 7410 Signal: Segmentation fault (11)
[07:22] <soee> *Trusty
[07:33] <ahoneybun> soee: hey
[07:33] <soee> hi ahoneybun
[09:07] <lordievader> Good morning.
[10:26] <Riddell> happy 27th
[10:26] <Riddell> feels wrong to have a day without a name now
[10:27] <Odur> thirdmas?
[10:27] <Odur> :)
[10:31] <Riddell> Boxed In Day?
[10:48]  * Riddell blogs http://blogs.kde.org/2013/12/27/photo-retrospective-ubuntu
[12:24] <BluesKaj> Hiyas all
[14:57] <drx_> hello. Anyone knows where I need to look into when after upgrading from 12.10 to 13.10 (via 13.04) in a dual screen setup suddenly there are 2 screensavers running (one on each screen) instead of one spanning both? While in System Settings / Screen Locker clicking test it works as expected (spanning one screen) but once it activates due to idle time, there are two independent ones.
[15:18] <BluesKaj> drx_, kubuntu i assume , perhaps yourgrphics card settings need some diting
[15:18] <BluesKaj> editing
[15:33] <drx_> BluesKaj there's pretty much no option to set anything unless you mean manually editing xorg.conf
[15:35] <BluesKaj> drx_, ok , I was thinking dual outs on the graphics card could have separate settings ...dunno much about multiple monotors anyway
[15:36] <BluesKaj> including the spelling of monitors :)
[15:36] <Peace-> happy new year !
[15:36] <Peace-> and bye bye
[15:37] <soee> ;]
[15:40] <drx_> hehe. Yeah the weird thing is that it works as expected when I click the "test" button in the setup screen. I just doesn't work correctly when it actually fires. When the screensaver is active and I move the mouse, I get the pw dialog on the screen the mouse was moved but on the second screen the screen saver there is still running. If I move the mouse over there to the second screen I get the pw dialog there too...
[15:40] <drx_> it's as if the dual-screen mode is only active for the kde-wm