[10:11] <gnuoy> jamespage, would you agree that the charms pep8 tests shouldn't cover charmhelpers?
[10:11] <jamespage> gnuoy, yes its normally excluded
[10:11] <jamespage> see tox.ini
[10:47] <gnuoy> beisner, I don't understand my -1 from https://review.openstack.org/#/c/289229/ . Is that Openstack CI failing to initiate tests remotely?
[10:57] <gnuoy> jamespage, beisner, I want to run a mojo spec using my branch which is up for review at review.openstack.org. I'm following the workflow where the only remote location of the wip branch is whereever gerrit stores it when the mp is created. So, I need to tell mojo where to check out my wip branch from. I see no reference to my wip branch on gerrit. Any ideas?
[10:57] <jamespage> gnuoy, one sec yes
[11:02] <jamespage> gnuoy, ok
[11:02] <jamespage> so for you current review:
[11:02] <jamespage> git clone https://review.openstack.org/openstack/charm-keystone
[11:02] <jamespage> cd charm-keystone
[11:03] <jamespage> git fetch https://review.openstack.org/openstack/charm-keystone refs/changes/29/289229/2
[11:03] <jamespage> git checkout FETCH_HEAD
[11:04] <gnuoy> jamespage, thanks but I don't see how that is going to work with mojo
[11:05] <jamespage> gnuoy, if you want a straigh branch to ref, the maybe just fork on github and push the branch to the fork for wip testing
[11:05] <gnuoy> ack
[11:06] <jamespage> gnuoy, that's what I'm doing for https://github.com/javacruft/charm-ceph/tree/network-spaces
[11:06] <jamespage> for example
[11:06] <jamespage> want to smoke it before staring to consume ci cycles for testing
[11:07] <jamespage> gnuoy, do you know had to add additional remotes to your local repo?
[11:07] <gnuoy> yep
[11:08] <jamespage> good-oh
[11:28] <gnuoy> jamespage, that's working, thanks
[12:19] <jamespage> dosaboy, thedac, gnuoy: http://paste.ubuntu.com/15320377/ well that works...
[12:19] <jamespage> maas-spaces2 branch + MAAS 1.9
[12:22] <dosaboy> jamespage: congratz
[12:22] <jamespage> dosaboy, containers support is just around the corner, and then we can flesh out a openstack-base bundle
[12:57] <jamespage> thedac, gnuoy: https://code.launchpad.net/~james-page/charm-helpers/network-spaces/+merge/288285
[12:58] <jamespage> that's what we're getting for Juju 2.0 re network-spaces...
[14:11] <marcoceppi> nagyz: the MAAS CLI drives an API directly. You could script something directly against that if you were looking to simplify/automate something
[14:28] <beisner> hi gnuoy, re: that initial -1, looks like it was an interwebs glitch http://pastebin.ubuntu.com/15321038/
[15:01] <lazyPower> jamespage -its simple. I like it
[15:02] <jamespage> lazyPower, ?
[15:02] <jamespage> oh network-spaces
[15:02] <lazyPower> the network-spaces mp you linked above
[15:02] <jamespage> yes
[15:02] <jamespage> I agree it is simple
[15:02] <lazyPower> so instead of relation-get, we network-get and it hands back the IP address it should bind to?
[15:03] <beisner> jamespage, our mojo specs define the neutron-gateway:mysql shared-db relation.  that relation found retirement last wk, so we'll need to update all next topologies in spec tests, yah?
[15:03] <beisner> o-c-t as well, if it's there
[15:04] <jamespage> beisner, oh I fixed o-c-t already
[15:04] <jamespage> needs dropping everywhere....
[15:04] <jamespage> lazyPower, yeah I think so
[15:05] <beisner> jamespage, ok cool, thx for the o-c-t updates.  i'll work on the mojo spec updates.
[15:06] <jamespage> lazyPower, you always need the name...
[15:12] <jamespage> lazyPower, "<dimitern> jamespage, looking
[15:12] <jamespage>  jamespage, LGTM"
[15:12] <jamespage> lazyPower, wanna give me a charmers +1 so I can land that?
[15:12] <magicaltrout> thought i'd missed the deadline for a talk submission then realised March comes before April.....
[15:13] <lazyPower> sure, where does teh binding param come from? is it just the name of the relation?
[15:14] <dimitern> lazyPower, it can be a relation or extra-binding name
[15:15] <jamespage> lazyPower, relation or 'extra-binding' which is a relation-less network binding mechnism
[15:15] <jamespage> ha
[15:15] <jamespage> sorry - dobuled up where
[15:15] <jamespage> there
[15:15] <jamespage> can't type...
[15:15] <lazyPower> It happens to me all the time :D i'm contageous
[15:17] <jamespage> dimitern, I really really want to play with the containers support now :-)
[15:18] <dimitern> jamespage, I know :) as soon as that's in a testable state will let you know - should be within the next week or so
[15:19] <lazyPower> jamespage - +1'd
[15:19] <jamespage> lazyPower, lovely thanks...
[15:34] <magicaltrout> i want to test leader election in amulet
[15:34] <magicaltrout> is there a way of asking juju which unit is the leader?
[15:35] <lazyPower> magicaltrout  - `is-leader`
[15:36] <magicaltrout> er
[15:38] <marcoceppi> magicaltrout: not easily, at least easily atm
[15:38] <magicaltrout> thats fine i set it in a status message anyway
[15:38] <magicaltrout> so I'll grep the status
[15:38] <magicaltrout> just wondered if there was an official way
[15:39] <marcoceppi> juju doesn't really expose who the leader is externally, so we could make a d.service['service'].leader property, or something similar, where we abstract the testing of that away
[15:39] <marcoceppi> magicaltrout: I'll open a bug to track
[15:40] <magicaltrout> yeah i looked at juju status yaml and didn't see anything of note
[15:41] <lazyPower> unless you status-set something of value wrt leadership, there is none
[15:41] <magicaltrout> yeah thats what i do
[15:41] <magicaltrout> jam's LXD patch is f***ing rocking. Back to LXD Local \o/
[15:42] <marcoceppi> heck yeah! happy to hear that
[15:43] <marcoceppi> it should squeak into beta2 due out this weekish
[15:44]  * magicaltrout lives in the land of adhoc patching and trunk builds, beta's have no meaning on this server.......
[15:48] <marcoceppi> hah
[15:52] <jrwren> magicaltrout: bonus if its production.
[15:53] <magicaltrout> jrwren: hehe, no, i'm not that crazy...........
[15:53] <magicaltrout> my prod server is 2.0 Alpha1.....! ;)
[16:08] <magicaltrout> marcoceppi: i'm clearly just not grepping amulet properly
[16:08] <magicaltrout> i know about wait for status
[16:08] <magicaltrout> how do i just get the status?
[16:09] <magicaltrout> or the message, to be more precise
[16:12] <marcoceppi> magicaltrout: I don't remember, let me check
[16:12] <marcoceppi> magicaltrout: ['workload-status'].get('message')
[16:13] <magicaltrout> thanks, i was just in the process of getting amulet to print me the contents of the unit object
[16:14] <marcoceppi> magicaltrout: basically, unit is the contents of the yaml output of juju status for that unit
[16:14] <marcoceppi> so workload-status and message dict key from that
[16:28] <larrymi> marcoceppi:  hi, trying to figure out the syntax for the placement stuff from what you suggested. Any pointers as to constraint to use for machine name?
[16:28] <marcoceppi> larrymi: I'm not sure, that used to be a secret constraint in juju but it may have been removed. If you use tags in MAAS though it'd have the same effect
[16:33] <larrymi> marcoceppi: I see thanks. I tried the tags for 5 machines but getting "ERROR cannot deploy bundle: machine "0" is not referred to by a placement directive (and 4 more errors)"
[16:49] <aisrael> tvansteenburgh: There's several charms showing up in the review queue but have been merged: 2433, 2430, 2432, 2299
[16:53] <magicaltrout> https://gist.github.com/buggtb/ec2b9d5abb77c058b46e marcoceppi unleash your python-fu and spot the mistake please :)
[16:54] <magicaltrout> well, i get the error, but I can't figure out the correct syntax :)
[16:56] <aisrael> line 2 is missing a closing )
[16:56] <marcoceppi> magicaltrout: https://gist.github.com/marcoceppi/298d7db8b409900b2a99
[16:56] <magicaltrout> aisrael: i had to type it, ignore the typos the code compiles :)
[16:56] <aisrael> also, I think this: self.d.sentry.unit['pdi/0'] should be: self.d.sentry.unit['pdi'][0], but don't hold me to that
[16:57] <marcoceppi> aisrael: ^ ;)
[16:57] <magicaltrout> booo
[16:57] <marcoceppi> .unit is pretty outdated at this point. self.d.sentry['service'][#] is better
[16:57] <magicaltrout> the amount of different variations i tried
[16:57] <magicaltrout> I dint use .unit initially but they both returned the same error anyway :)
[16:59] <marcoceppi> magicaltrout: yeah, .info isn't really that obvious, but because self.d.sentry['service'][#] is a UnitSentry class, it wasn't originally made to be subscriptable, https://github.com/juju/amulet/blob/master/amulet/sentry.py#L63 so we placed the data in .info - that's a design decision from 3 years ago. Obiviously self.d.sentry['service'][#]['workload-status'] should just work
[17:00] <magicaltrout> yeah i would have taken about 3 hours to guess that I reckon
[17:01] <magicaltrout> works though... thanks a lot!
[17:03] <tvansteenburgh> aisrael: updated those reviews, thanks
[17:03] <tvansteenburgh> magicaltrout: i am working on api docs for amulet as we speak - hopefully that will help
[17:40] <beisner> hi thedac, can you have a look over this mojo spec review?:  https://code.launchpad.net/~1chb1n/openstack-mojo-specs/mojo-openstack-specs-juju-wait-for-workload-status/+merge/288302
[17:40] <thedac> beisner: sure
[17:43] <thedac> beisner: the resyncs from gerrit to lp, are they at next still or somewhere else?
[17:44] <beisner> thedac, @ next
[17:44] <thedac> thanks
[17:44] <beisner> ditto :-)
[17:48] <cholcombe> charmers: anyone willing to take a look at a quick bugfix? :)  https://code.launchpad.net/~xfactor973/charm-helpers/ceph-configkey-bugfix/+merge/288146
[17:48] <cholcombe> 8 liner :D
[17:54] <lazyPower> cholcombe +1'd
[17:54] <cholcombe> lazyPower, thanks!
[17:55] <thedac> beisner: so, ceph-radosgw has not synced since Mar 2. Can you take a look?
[17:57] <beisner> thedac, let me make sure we're on the same page(s).  it looks in sync to me:
[17:57] <beisner> https://github.com/openstack/charm-ceph-radosgw/commits/master
[17:57] <beisner> to:   https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-radosgw/next
[17:58] <thedac> Let me double check but the bzr log in the next version has a last commit of Mar 2
[17:58] <magicaltrout> thanks tvansteenburgh looking forward to them! :)
[17:59] <thedac> beisner: ignore me. I had reverse on the bzr log ;)
[18:00] <marcoceppi> aisrael: I've got an MP for charmhelpers that adds resource-get
[18:00] <beisner> thedac, woot :)
[18:04] <marcoceppi> aisrael charmers https://code.launchpad.net/~marcoceppi/charm-helpers/resource-get/+merge/288328
[18:09] <jamespage> beisner, thedac: I have a glance and ceilometer review in the queue which fix from bits of mitaka support - any chance you can review?
[18:09] <jamespage> they both full smoke OK
[18:09] <beisner> o/ jamespage - sure
[18:10] <thedac> jamespage: yes, I am having issues logging into review.openstack.org. Trying to figure out what I am missing
[18:10] <jamespage> thedac, hmm
[18:10] <jamespage> sso matching maybe
[18:10] <thedac> Yeah, I get into a loop with sso
[18:12] <beisner> fyi jamespage, thedac, gnuoy - added [uosci-crit] failure email nag on the github-to-launchpad sync job
[18:14] <thedac> beisner: jamespage: is there an LP team we need to be in to log into gerrit?
[18:14] <thedac> I notice sso is not passing any teams
[18:15] <beisner> thedac, not afaik
[18:21] <cholcombe> beisner, here's the debug log: https://gist.github.com/cholcombe973/11f017456581397664f4 :)
[18:21] <cholcombe> beisner, rolling upgrade in action
[18:21] <cholcombe> it's noisy
[18:56] <aisrael> marcoceppi: awesome, I'll check it shortly
[20:33] <metsuke_> is there any documentation we can look at to add MAAS to juju 2 ?  all the docs we find and even the cli help is old
[20:35] <lazyPower> metsuke_ - there was a section about this on the release notes, one sec while i fetch you a link
[20:35] <lazyPower> metsuke_ - https://lists.ubuntu.com/archives/juju/2016-February/006618.html    under private clouds
[20:39] <metsuke_> lazyPower: thanks
[20:39] <metsuke_> will juju 2 have multi-user authentication and management?
[20:40] <rick_h__> metsuke_: yes
[20:42] <metsuke_> rick_h__: cool, thanks!  I saw the last on-air and the subject was kind of touched on.  Specifically, can we link users in juju to openstack tenants or users?
[20:42] <rick_h__> metsuke_: ah not so much there
[20:42] <rick_h__> metsuke_: that the admin that bootstraps a controller can share/add other users to that controller
[20:45] <metsuke_> ok, how about models in juju lining up with openstack tenants?  if that's not a think then how about imposing quotas on models to act like quotas on nova tenants?
[20:46] <rick_h__> metsuke_: so when you create a model you can specify cloud credentials to use
[20:46] <rick_h__> metsuke_: and those could be different tenants on OS and you could do things like enforce OS quotas I think
[20:47] <metsuke_> oh, so it is per model that we can specify the credentials.  That would work just fine!
[20:47] <rick_h__> yea, it'll have a sane defautl, but be tweakable
[20:49] <metsuke_> Do you happen to know if there is a way to share volumes in juju or is that left up to your back-end (like Openstack Manila)?
[20:51] <rick_h__> so there's a roadmap feature for adding shared filessystems to the storage modeling Juju does
[20:51] <rick_h__> but yes, at the moment that's not available in juju itself
[20:52] <metsuke_> nice!  In that case, I'll have to find someone to make a Manila charm
[20:54] <rick_h__> marcoceppi: I see a new charm on the horizon http://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
[20:54] <marcoceppi> rick_h__: we already have sql-server for windows ;)
[20:54] <magicaltrout> sql server, the platform that makes grown men cry
[20:54] <rick_h__> marcoceppi: true enough
[20:57] <stokachu> will the auto credential detection still require us to manually create a credentials file for MAAS?
[20:59] <rick_h__> stokachu: it looks at local files. wallyworld is there a list of what's supported? not seeing a list of paths in the release notes
[21:00] <stokachu> i saw one for checking .novarc for openstack, so curious if there is one for maas
[21:01] <rick_h__> stokachu: don't see it but if there's a path please let us know and we can look to add https://github.com/juju/juju/blob/af8944dd5a0d6cfe65a1f0e6bd5116a479270a91/cmd/juju/cloud/detectcredentials.go
[21:01] <stokachu> hmm that may need a feature request for maas guys
[21:01] <wallyworld> rick_h__: the release notes do list what's supported
[21:02] <wallyworld> i updated them last week
[21:02] <rick_h__> wallyworld: in the google doc?
[21:02] <wallyworld> yep
[21:02] <wallyworld> aws, google, openstack/rackspace
[21:03] <stokachu> can i get access to that google doc?
[21:03] <stokachu> just to read it
[21:03] <wallyworld> sure
[21:09] <aisrael> re charm promulgate, it's throwing "ValueError: Series can not be None" when I run it inside the charmdir I want to promulgate. Is there more to the command?
[21:09] <aisrael> marcoceppi: lazyPower ^
[21:10] <lazyPower> aisrael charm promulgate -s trusty
[21:10] <aisrael> lazyPower: mucho gracias
[21:11] <wallyworld> rick_h__: do the release notes answer your question? did you see the material?
[21:12] <rick_h__> wallyworld: looking at https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit under "autoload-credentials" it'd be good to list what clouds/paths it looks for
[21:13] <wallyworld> rick_h__: it does in the Credentials Management section
[21:13] <rick_h__> wallyworld: maybe a reference from that section to the other?
[21:13] <wallyworld> ok
[21:13] <rick_h__> ty
[21:15] <wallyworld> rick_h__: the info is a few lines above
[21:15] <wallyworld> ie the autoload feature is described in the credentials management section
[21:15] <wallyworld> where it looks is described just before the autoload command is talked about
[21:16] <wallyworld> there's no need for a link then is there?
[21:16] <wallyworld> ie all the info is together
[21:22] <mattyw> cmars, menn0 http://reviews.vapour.ws/r/4085/
[21:22] <menn0> mattyw: looking
[21:23] <mattyw> menn0, thanks, I *think* it's what you suggested
[21:25] <menn0> mattyw: it is, but I've suggested further changes on the review
[21:27] <mattyw> menn0, we still want to keep the DocID filed right? because we want to choose which field mongo wants to have as _id (our static key)
[21:28] <menn0> mattyw: when the document struct doesn't have an _id field, the "Id" on the txn.Op that inserts it is used
[21:29] <menn0> mattyw: given that you don't care about the _id when you read the doc out (it's fixed after all), there's no reason to have it on the struct.
[21:29] <menn0> mattyw: leaving it off the struct just avoids some clutter
[21:31] <mattyw> menn0, I see it now, thanks for pointing it out
[21:31] <mattyw> menn0, I'm going to have a pr with many more deletions than additions :)
[21:31] <menn0> mattyw: that's often a very satisfying kind of PR :)
[21:32] <mattyw> menn0, just pushing the changes
[21:36] <mattyw> menn0, PTAL http://reviews.vapour.ws/r/4085/
[21:44] <rick_h__> wallyworld: hmm, ok yea it reads backwards to my brain but understand. I did a "find on page" for autoload and read down and so I never saw the stuff above it.
[21:52] <lborda> guys can you point me to a charm where I can learn (in python) how to change the variables for a given config template file ?  or point me to a commit where a parameter was added to an existent charm ?
[22:10] <magicaltrout> lborda: https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py#L124 or something more?
[22:14] <lborda> humm... magicaltrout you're using the render function directly... cool how does that work if you have to juju service set <service> var=bla ?
[22:16] <magicaltrout> so if you look around line 58
[22:16] <magicaltrout> 61 etc
[22:16] <magicaltrout> there are a bunch of data_changed hooks
[22:16] <magicaltrout> to reprocess stuff if you change a charm setting
[22:16] <magicaltrout> so I'd just use on of them and the render call
[22:16] <magicaltrout> (I believe, i'm no expert but i'm pretty sure that would work fine)
[22:17] <magicaltrout> the render calls down the bottom are triggered by leader election
[22:17] <magicaltrout> which is pretty similar
[22:21] <lborda> magicaltrout, humm... lines 61..64 look like what I am looking for... :) thanks... it's actually for the keystone charm so I will probably have to use a variance of the logic ... but it helps a lot tks
[22:24] <magicaltrout> no probs
[22:24] <lborda> magicaltrout, using charms.reactive is much easier...
[22:26] <magicaltrout> hehe
[22:26] <magicaltrout> well i got a very helpful double team training session from kevin and cory_fu in Ghent which helped a lot with picking the right stuff
[22:26] <magicaltrout> especially as I knew no python
[22:27] <magicaltrout> the only reason we wrote that layer in python is because i was stubborn and wanted to learn some python ;)
[22:27] <magicaltrout> but its serving as a good place for me to refer to as its got a bit of everything
[22:29] <lborda> magicaltrout, doing it for learning python is a good excuse! :) tks
[23:08] <magicaltrout> evening all
[23:08] <aisrael> o/
[23:08] <magicaltrout> is there a way to tell a test to wait until the next leader election routine has run?
[23:09] <magicaltrout> or do I  just tell it to chill out for 5 minutes and check again
[23:18] <aisrael> Hm. You could watch the status for the next leader election to run, and then wait for that to finish


[16:18] <SoundKid> some hardware geeks online!
[16:19] <SoundKid> Nvidia Fan Control ! new help !  adding coolbits option ! was fail! system did not boot after that
[16:19] <SoundKid> can somebody please tell me how its done in proper way
[16:19] <SoundKid> greeting from austria


[11:18] <magicaltrout> is it me
[11:18] <magicaltrout> or is the jujucharm store borked?
[11:19] <magicaltrout> oh no
[11:19] <magicaltrout> its me :)
[17:24] <bdx> gsamfira: I think my bug is your bug too
[17:24] <bdx> aha
[17:24] <bdx> I didn't realize it yesterday
[17:28] <gsamfira> bdx: looks like it :D
[17:34] <bdx> gsamfira: does the fix in proposed work for you?
[17:34] <bdx> testing it now
[17:38] <gsamfira> bdx: we went with 2.2.6 for now. If it helps you out, I can test it as well, but for the moment we're good to go
[17:39] <ybaumy> i just wanted to say great job on the current vsphere support
[17:40] <bdx> gsamfira: I just added the proposed repo, deploying a few nodes now
[17:40] <ybaumy> if anyone wants to hear that .. kubernetes and juju has now a chance again in our company
[17:41] <bdx> ybaumy: 2.3.1 got some vsphere love eh?
[17:41] <ybaumy> bdx i love it so far. we are currently using openshift from redhat but i want to push ubuntu and juju
[17:42] <bdx> ybaumy: awesome. srry I'm a bit behind on the vsphere provider .... what changed?
[17:44] <ybaumy> bdx last time it was not working at all for me :D so that changed .. i was using maas as cloud provider with vsphere and then juju to deploy kubernetes... i dont need maas anymore
[17:47] <bdx> ybaumy: sweet!
[17:52] <ybaumy> bdx its so easy to scale and roll out a cluster
[17:53] <ybaumy> bdx: you should try it
[17:54] <bdx> ybaumy: I can't think of any reason to use the vmware provider
[17:55] <bdx> but if I ever do have a use case for it
[17:55] <bdx> I'll ping you and get the dl
[17:55] <bdx> glad to hear its purring along for you though
[17:56] <bdx> ybaumy: on second thought I may have some deploys that will require esxi in the next year
[17:56] <bdx> totally spaced it
[17:56] <bdx> so yeah, really good to know
[18:05] <bdx> gsamfira: http://paste.ubuntu.com/26178059/
[18:05] <bdx> :) :) :) :)
[18:21] <gsamfira> bdx: outstanding! that was a quick fix :D
[18:21] <gsamfira> hopefully there was a CI test added for this case :P
[18:32] <rick_h> gsamfira: looks like it was something that changed in the fan package used. definitely some room to make sure that the new versions of the fan are tested out
[18:37] <gnuoy> has JUJU_REMOTE_UNIT gone ?
[18:38] <gnuoy> http://paste.ubuntu.com/26178222/ <- I'm seeing this in a debug hooks session
[18:38] <gnuoy> JUJU_VERSION=2.3.1
[18:38]  * gnuoy looks for release notes
[18:41] <gnuoy> argh thedac just put me right, I'm not in a relation hook
[19:22] <McL0v1n_> Greetings! When i deploy to a host and lxc (im deploying the openstack bundle) my containers dont start up. Ive waited for hours thinking it was the image download but the only way i can get them to start up is if i log into each host and run lxd init. Shouldnt juju be starting them up on its own?
[19:56] <McL0v1n_> Anyone around?
[19:59] <thedac> I am seeing something similar: http://pastebin.ubuntu.com/26178643/
[19:59] <thedac> McL0v1n_: what version are you running?
[20:00] <thedac> I have 2.4-beta1-artful-amd64 snap installed but the controller is on 2.3-rc2. I am going to try with a new controller
[20:05] <McL0v1n_> Im using the stable from the repo, not the snap
[20:06] <McL0v1n_> Im at a clients office 2 hours away from my cabinet, so i cant look at it and im using IRC on my phone
[20:07] <thedac> McL0v1n_: no worries, I'll try this new controller and file a bug
[20:07] <McL0v1n_> Essentially maas from apt repo, juju from apt repo, ubuntu 16.04 image from maas
[20:07] <McL0v1n_> Thanks, this have been bothering me for months now and i cant find anything that relates to it
[20:09] <hml> i’m able run a container with openstack using 2.3.2
[20:10] <McL0v1n_> Im not doing anything different from a standard deploy: a bunch of bare metal servers and maas
[20:11] <McL0v1n_> Using openstack-base bundle #50 and now #51
[20:13] <McL0v1n_> I can check the actual versions when i get back to my office
[20:16] <McL0v1n_> This has been happening from back when i tried to do it all based of the exact instructions for autopilot. Exact same issue. So it has to be a juju thing
[20:17] <zeestrat> McL0v1n_: you mentioned bridge activation issues? Something like this? https://bugs.launchpad.net/maas/+bug/1736022
[20:17] <mup> Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process <juju> <juju:Incomplete> <MAAS:Incomplete> <https://launchpad.net/bugs/1736022>
[20:18] <McL0v1n_> Different issue, but i ONLY get that when i manually log into each host and run lxd init
[20:18] <McL0v1n_> If i dont the container never starts up


[04:39] <MegaBrutal> Hi all! Please triage bug 1428952, as it affects multiple users and have evidences attached.
[10:40] <rbasak> MegaBrutal: "Confirmed" seems like the right status to me. Exact steps to reproduce or at least a breakdown of which package upgrade regressed functionality would help getting it to Triaged state.
[10:41] <rbasak> Not enough information yet for a developer to fix it I don't think.


[03:31] <danderson> Hi folks. I'm trying to write an upstart unit, and when I try to start it with `service starbound start`, all I get is "start: Job failed to start".
[03:32] <danderson> How can I get more verbose information about what upstart doesn't like?
[03:32] <danderson> I can't find any obviously useful logs in /var/log
[03:33] <danderson> ah, seems like it's dropped in dmesg, instead of other logs.


[00:21] <nicklas_> hello, anyone knows why ubuntu extras repos isnt available for (*)buntu 15.04?
[00:35] <Unit193> nicklas_: Because it only really caused issues and wasn't really used.
[00:36] <nicklas_> Unit193: so it wont come back/show, come for 15.04 at all? i dont need to wait for it?
[00:37] <Unit193> Nope, just remove it.  Partner is the useful repo.
[00:38] <nicklas_> ok cool
[00:39] <nicklas_> ive been waiting for it to show up on sources list generator, so i can start working on my fresh 15.04 install
[00:39] <nicklas_> Unit193: thanks alot for your answer, saved me alot of unneccesary waiting
[00:39] <Unit193> Hah, sure thing.
[00:45] <nicklas_> bedtime, babaj
[12:49] <packetprophet> hello
[12:50] <packetprophet> trying to install xubutu 15
[12:50] <packetprophet> when i go to install it it hangs on the circly thing that spins
[12:50] <packetprophet> and i stop hearing the dvd rom
[12:50] <packetprophet> i ran the disk checker with no errors
[12:50] <packetprophet> i deisabled secure boot
[12:50] <packetprophet> installing wih uefi
[12:50] <packetprophet> enabled the cpm
[12:50] <packetprophet> in bios
[12:51] <packetprophet> machine is currently windows 8.1 if that matters
[12:51] <packetprophet> on an asus laptop4
[12:51] <packetprophet> also turned fastboot off
[15:14] <GridCube> for some reason after upgrading to 15.04 xfdesktop wasnt loading with the system, launching it from a terminal seems to have fixed the issue, but i dont know if that will be the case after a reboot :P we weill have to see
[15:18] <krytarik> GridCube: Clear saved sessions.
[15:20] <GridCube> done
[15:20] <GridCube> :)
[15:20] <Finetundra> how would one reinstall libvncserver?
[15:20] <GridCube> sudo apt-get install libvncsercer --reinstall ?
[15:21] <Finetundra> E: Unable to locate package libvncserver
[15:21] <Finetundra> :(
[15:21] <GridCube> !find libvncserver
[15:22] <GridCube> !info libvncserver0
[15:22] <Finetundra> what is the prupose of adding that useless 0?
[15:22] <GridCube> i dont know im not a developer
[15:23] <GridCube> its is what ever the devs want it to be
[15:23] <Finetundra> you've got a point
[15:24] <GridCube> im actually more like a blob, but thanks
[15:24] <Finetundra> hehe
[15:24] <Finetundra> gonna reboot
[15:31] <Finetundra> GridCube: it seems to have worked so oyu have my thanks
[15:31] <Finetundra> *you
[17:07] <lwizardl> hello
[17:09] <Aldebaran> привет
[17:11] <lwizardl> where are the settings to change the keyboard bindings for extra buttons on keyboards. such as media controls, etc
[17:19] <Luminous> how do I configure the settings regarding when the computer turns off/hibernates/logs out when not in use?
[17:21] <Contraband_Onion> hello
[17:22] <krytarik> Contraband_Onion: Using different nicks doesn't help. :)
[17:23] <krytarik> Also, hi.
[17:24] <Contraband_Onion> well, it helped me to answer a question I had
[17:24] <Contraband_Onion> about whether or not I was logged in
[17:25] <krytarik> Ah.
[17:26] <Luminous> so, do you know how to change when the computer logs out?
[17:26] <dreamon> hello there. coming from gnome, mate, cinnamon.. but now I installed xfce. It worked fine. (one day) today I tried to reboot and only mousepointer is left and a little dot in the left upper corner.
[17:27] <krytarik> Luminous: You mean lock the screen? What version are using then?
[17:30] <krytarik> dreamon: How does the Guest session work?
[17:31] <dreamon> It try..
[17:31] <dreamon> -t
[17:31] <Aldebaran> Explain how to get into tty. click Alt+Ctrl+F1 there is a black screen!
[17:32] <Luminous> krytarik: Yes, the lock screen. Version 14.04.2 LTS
[17:33] <krytarik> Luminous: Alright, then try "Settings Manager → Light Locker Settings".
[17:34] <Luminous> krytarik: thanks.
[17:38] <dreamon> krytarik, guest works fine
[17:40] <krytarik> dreamon: Try clearing any saved sessions - "Settings Manager → Session and Startup → Session → Clear saved sessions".
[17:41] <dreamon> krytarik, how can I do.. I have no kind of menus, bars, no terminal during xfce session.
[17:41] <krytarik> Heh, alright. :D
[17:43] <krytarik> dreamon: Then log out, switch to a tty with Ctrl+Alt+F1, log in there, "rm ~/.cache/sessions/*", log out, switch back to login screen with Ctrl+Alt+F7.
[18:07] <dreamon> krytarik, No sorry. still the same.
[18:08] <dreamon> after starting xfce .. went to tty1 and saw, there some xfce parts running..
[18:09] <krytarik> dreamon: Try resetting the display config using the same way: "~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml".
[18:15] <dreamon> krytarik, delete anything inside ~/.config/xfce4/xfconf/xfce-perchannel-xml/* ??
[18:16] <krytarik> No!
[18:16] <dreamon> there is no displays.xml
[18:16] <krytarik> Oh well then.
[18:19] <krytarik> dreamon: Do you see any relevant error messages in "~/.xsession-errors"?
[18:21] <dreamon> krytarik, its a short list .. no errors
[18:22] <dreamon> can I reset xfce, I have nothing special to loos. I only configured yesterday first time. Was so happy with it. next da I rebooted an, got this problem ..
[18:25] <krytarik> dreamon: That'd be what you referred to just before - I'd just move it though.
[18:34] <dreamon> krytarik, sorry. english is not my main language.. what does it mean "I'd just move it though"
[18:38] <krytarik> dreamon: Not delete, just rename or move it someplace else.
[18:40] <dreamon> which folder? "~/.config/xfce4 ?
[18:51] <dreamon> krytarik, Ok, renamed ~/.cache/xfce4 .. now it works!!
[18:53] <krytarik> dreamon: Nice. :)
[18:54] <dreamon> krytarik, Thank you very much
[19:03] <dreamon> krytarik, Is it possible to find a easy theme to install. I think xfce imports some stuff out of gnome.. is this right?
[19:14] <krytarik> dreamon: It's GTK+ theme + Xfwm4 theme.
[19:15] <dreamon> where can I change it, and see what does it change? I rebooted 100 times..
[19:18] <KW4HK> anyone know if mint-x theme work with xubuntu 15.04?
[19:19] <KW4HK> dreamon: have you tried settings -> appearance?
[19:25] <dreamon> KW4HK, yes I did. therefore I have a black background and kannt set it back.. strange thing
[19:38] <lieber> hello guys! I wrote a screensaver/blank inhibitor and tested on my xfce 4.12, seems perfectly fine. If anyone could give it a shot and send me some feedback, I would be pleased, thank you very much -- https://github.com/liebermd/blank-inhibitor
[19:39] <brainwash> lieber: advertising..
[19:41] <brainwash> KW4HK: it only takes some seconds to test if the theme works, no need to ask if anyone tested a specific theme
[19:46] <Aldebaran> how to open the console in 15.04 ???
[19:46] <brainwash> Aldebaran: how did you open it in previous releases?
[19:46] <baizon> Aldebaran: i dont understand this question?
[19:48] <Aldebaran> how to get into tty1-6 ?
[19:48] <Aldebaran> I have there a black screen
[19:50] <bazhang> ctrol alt f1, f7 to get back
[19:51] <Aldebaran> I have there a black screen jast
[19:51] <bazhang> which one
[19:52] <baizon> Aldebaran: ctrl +F1 and then press a key
[19:52] <baizon> Aldebaran: then a login text should appear
[19:52] <bazhang> why not use a regular terminal
[19:53] <brainwash> bazhang: why not focus on his actual problem?
[19:53] <brainwash> tty's not being spawned
[19:54] <Aldebaran> black screen there and nothing happens
[19:56] <brainwash> Aldebaran: did you tweak any systemd related config files?
[19:57] <Aldebaran> not the carriage of any invitation or greeting or login
[19:57] <brainwash> what does the command "journalctl -u<EMAIL_ADDRESS>return?
[19:58] <Aldebaran> No configuration files I did not touch, it can be associated with a video driver
[20:00] <Aldebaran> http://pastebin.com/TTDXJ5wQ
[20:04] <brainwash> mmh, did it work initially after upgrading to 15.04? and did you install a driver for your graphics card?
[20:04] <Aldebaran> :(
[20:05] <bazhang> apologies brainwash
[20:06] <Aldebaran> so I installed the driver separately from the repository, system set to zero
[20:06] <Aldebaran> dont update
[20:07] <brainwash> did it work properly before installing the driver?
[20:07] <Aldebaran> dont upgrade
[20:08] <brainwash> you said that "it can be associated with a video driver"
[20:08] <Aldebaran> I unchecked, the native driver was bad and I immediately put the other
[20:09] <brainwash> and the other one triggers the black screen?
[20:09] <Aldebaran> What about the driver I just assumed ...
[20:10] <Aldebaran> should be checked, check it now!
[20:10] <brainwash> but it's likely that the driver is the cause
[20:10] <brainwash> according to journalctl, tty1 was spawned and it appeared to be functional
[20:11] <brainwash> but it was not visible (black screen)
[20:11] <brainwash> -> video issue
[20:12] <Aldebaran> I goin check it
[20:12] <Aldebaran> 5 sec
[20:27] <Aldebaran> Yes, the whole thing turned into a video driver for AMD\ATI
[20:28] <brainwash> Aldebaran: did you manage to fix it?
[20:30] <Aldebaran> Now I try to boot from fglrx-update version of the driver
[20:35] <Aldebaran> Unfortunately no, I could not fix the problem, sitting without TTY
[20:35] <brainwash> :/
[20:35] <Aldebaran> );


 Hi! I need help with testing Qt WebEngine 5.15.3 packages for Hirsute:
 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4497/+packages
 It's a bit late in the release cycle, but it fixes a remote code execution issue (CVE-2021-21193) so maybe it makes sense to try to push it to Hirsute archive.
 If you use a WebEngine based browser (Falkon, qutebrowser) or have it installed, please give it a try.
 How do we test that, considering that Google are denying permission to view the chromium bug?
 I don't mean the CVE, just test that it works in general and doesn't crash with your favourite browser/site :)
 I can do that, though I avoid WebEngine things normally
 Is there a LP bug to comment on, or just here
 Just here.
 I would prefer to avoid it too. I started work on 5.15.3 on March 7th, and only now I have a semi-ready package. (re @RikMills: I can do that, though I avoid WebEngine things normally)
 Ok. I will try it a little later this afternoon
 Nothing crashed
 Fairly brief tests. ebay, amazon, wikipedia, ubuntu.com etc
 👍 Thank you very much!


[05:31] -queuebot:#ubuntu-release- New binary: golang-github-jellydator-ttlcache [amd64] (mantic-proposed/none) [3.0.1-2] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: go-containerregistry [amd64] (mantic-proposed/none) [0.14.0+ds1-2] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: go-containerregistry [arm64] (mantic-proposed/none) [0.14.0+ds1-2] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: go-containerregistry [ppc64el] (mantic-proposed/none) [0.14.0+ds1-2] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: go-containerregistry [armhf] (mantic-proposed/none) [0.14.0+ds1-2] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: go-containerregistry [s390x] (mantic-proposed/none) [0.14.0+ds1-2] (no packageset)
[06:40] -queuebot:#ubuntu-release- New binary: siconos [amd64] (mantic-proposed/universe) [4.4.0+dfsg-3] (no packageset)
[06:58] -queuebot:#ubuntu-release- New binary: siconos [ppc64el] (mantic-proposed/universe) [4.4.0+dfsg-3] (no packageset)
[07:52] <LocutusOfBorg> hello ubuntu-archive can we please have https://launchpad.net/ubuntu/+source/octave/8.2.0-4 kicked out and 8.2.0-3 copied back for now?
[08:47] -queuebot:#ubuntu-release- Unapproved: linux-firmware (jammy-proposed/main) [20220329.git681281e4-0ubuntu3.15 => 20220329.git681281e4-0ubuntu3.16] (core, kernel)
[08:52] -queuebot:#ubuntu-release- Unapproved: linux-firmware (lunar-proposed/main) [20230323.gitbcdcfbcf-0ubuntu1.3 => 20230323.gitbcdcfbcf-0ubuntu1.4] (core, kernel)
[09:29] -queuebot:#ubuntu-release- New binary: go-containerregistry [riscv64] (mantic-proposed/universe) [0.14.0+ds1-2] (no packageset)
[09:34] -queuebot:#ubuntu-release- New: accepted golang-github-jellydator-ttlcache [amd64] (mantic-proposed) [3.0.1-2]
[09:34] -queuebot:#ubuntu-release- New: accepted siconos [ppc64el] (mantic-proposed) [4.4.0+dfsg-3]
[09:34] -queuebot:#ubuntu-release- New: accepted siconos [amd64] (mantic-proposed) [4.4.0+dfsg-3]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [amd64] (mantic-proposed) [0.14.0+ds1-2]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [armhf] (mantic-proposed) [0.14.0+ds1-2]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [riscv64] (mantic-proposed) [0.14.0+ds1-2]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [arm64] (mantic-proposed) [0.14.0+ds1-2]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [s390x] (mantic-proposed) [0.14.0+ds1-2]
[09:37] -queuebot:#ubuntu-release- New: accepted go-containerregistry [ppc64el] (mantic-proposed) [0.14.0+ds1-2]
[09:56] -queuebot:#ubuntu-release- Unapproved: accepted firmware-sof [source] (jammy-proposed) [2.0-1ubuntu4.2]
[10:23] -queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (focal-proposed) [1:2.0.18-1ubuntu1.1]
[13:26] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (lunar-proposed) [20230323.gitbcdcfbcf-0ubuntu1.4]
[13:27] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (jammy-proposed) [20220329.git681281e4-0ubuntu3.16]
[14:50] <kanashiro[m]> rbasak: not sure if you still have time today but could you please try to take a look at the packages in -unapproved related to LP #2023694 and #2022390 ? This is the container stack backport
[14:50] -ubottu:#ubuntu-release- Launchpad bug 2023694 in golang-1.20 (Ubuntu Jammy) "Backport container stack from Mantic" [Undecided, In Progress] https://launchpad.net/bugs/2023694
[14:51] -ubottu:#ubuntu-release- Launchpad bug 2022390 in docker.io-app (Ubuntu Lunar) "Keep the -dev binary package in sync with Debian" [Undecided, Fix Committed] https://launchpad.net/bugs/2022390
[14:56] <rbasak> kanashiro[m]: sorry that seems unlikely. Most of my time today has been spent dealing with priority SRU interrupts.
[14:57] <rbasak> And it's quite an extensive review I'm guessing?
[16:37] -queuebot:#ubuntu-release- Unapproved: accepted slurm-wlm [source] (lunar-proposed) [22.05.8-3ubuntu0.1]
[16:37] <vorlon> LocutusOfBorg: octave> done
[16:38] <vorlon> rbasak: should be incremental vs what was already accepted, really
[16:39] <kanashiro[m]> rbasak: those are to fix autopkgtest regressions, and the main changes were reviewed already. But I do understand, I can wait for the next vanguard
[16:59] <LocutusOfBorg> vorlon, if you have one minute of spare time LP: #2027852 :)
[16:59] -ubottu:#ubuntu-release- Launchpad bug 2027852 in halide (Ubuntu) "RM halide [riscv64]" [Undecided, New] https://launchpad.net/bugs/2027852
[16:59] <LocutusOfBorg> and also LP: #2024934 it came back due to the fact that proposed pocket wasn't cleanup
[16:59] -ubottu:#ubuntu-release- Launchpad bug 2024934 in eccodes (Ubuntu) "eccodes: RM on armhf and s390x" [Undecided, New] https://launchpad.net/bugs/2024934
[17:18] -queuebot:#ubuntu-release- New binary: gerbera [amd64] (mantic-proposed/universe) [1.12.1+dfsg-0.1~build1] (no packageset)
[17:50] <vorlon> LocutusOfBorg: hi, I saw your ping about this on IRC but then I had questions and you were offline, sorry.  let me context switch back in
[17:51] <vorlon> LocutusOfBorg: I think the issue is, it was unclear to me from the changelog *why* the architectures had been restricted in this fashion - and again, riscv64 is not a Debian release arch, so it is unclear that dropping it is intentional
[19:38] <LocutusOfBorg> vorlon, its the opposite I would say, only amd64 arm64 and i386 are supported upstream
[19:39] <LocutusOfBorg> and also for them we disable a subset of tests just to make them pass
[19:39] <LocutusOfBorg> for riscv64 the tests disable is just too much to be useful
[19:39] <LocutusOfBorg> and in Ubuntu meh, we don't run tests :)
[19:39] <LocutusOfBorg> halide on riscv64 is even crashing the compiler
[19:41] <LocutusOfBorg> upstream claims to support it but meh
[19:41] <LocutusOfBorg> in any case I can ask to re-enable it
[19:42] <LocutusOfBorg> (they claim also powerpc and mips support and arm)
[19:48] <_doko> LocutusOfBorg: unrelated to that, please file an issue about the ICE
[20:57] -queuebot:#ubuntu-release- New binary: rocthrust [amd64] (mantic-proposed/universe) [5.3.3-4] (no packageset)
[21:57] -queuebot:#ubuntu-release- New: accepted rocthrust [amd64] (mantic-proposed) [5.3.3-4]
[22:05] -queuebot:#ubuntu-release- New binary: rocthrust [ppc64el] (mantic-proposed/universe) [5.3.3-4] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: asf-search [amd64] (mantic-proposed/none) [6.6.0-2] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: python-package-smoke-test [amd64] (mantic-proposed/none) [1.0-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: nanosvg [amd64] (mantic-proposed/none) [0.0~git20221204.9da543e-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-struct-patch-derive [amd64] (mantic-proposed/none) [0.3.0-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-mac-address [amd64] (mantic-proposed/none) [1.1.5-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-trackable-derive [amd64] (mantic-proposed/none) [1.0.0-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: rust-rockfile [amd64] (mantic-proposed/none) [0.1.0-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: rust-unicode-truncate [amd64] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: haskell-git-mediate [amd64] (mantic-proposed/none) [<IP_ADDRESS>-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: python-yarg [amd64] (mantic-proposed/none) [0.1.9-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: rust-loom [amd64] (mantic-proposed/none) [0.5.6-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: python-keycloak [amd64] (mantic-proposed/none) [3.3.0+dfsg-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-self-cell [amd64] (mantic-proposed/none) [1.0.1-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-derive-builder-macro [amd64] (mantic-proposed/none) [0.12.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: nanosvg [arm64] (mantic-proposed/none) [0.0~git20221204.9da543e-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: r-cran-exactextractr [amd64] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-self-cell [ppc64el] (mantic-proposed/none) [1.0.1-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: nanosvg [armhf] (mantic-proposed/none) [0.0~git20221204.9da543e-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-unicode-truncate [arm64] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-rockfile [ppc64el] (mantic-proposed/none) [0.1.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: gerbera [amd64] (mantic-proposed/universe) [1.12.1+dfsg-0.1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: nanosvg [ppc64el] (mantic-proposed/none) [0.0~git20221204.9da543e-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-mac-address [arm64] (mantic-proposed/none) [1.1.5-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-rockfile [armhf] (mantic-proposed/none) [0.1.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-self-cell [arm64] (mantic-proposed/none) [1.0.1-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-struct-patch-derive [ppc64el] (mantic-proposed/none) [0.3.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-trackable-derive [armhf] (mantic-proposed/none) [1.0.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-unicode-truncate [armhf] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: haskell-git-mediate [armhf] (mantic-proposed/none) [<IP_ADDRESS>-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-rockfile [arm64] (mantic-proposed/none) [0.1.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-self-cell [s390x] (mantic-proposed/none) [1.0.1-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-trackable-derive [ppc64el] (mantic-proposed/none) [1.0.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: nanosvg [s390x] (mantic-proposed/none) [0.0~git20221204.9da543e-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-struct-patch-derive [s390x] (mantic-proposed/none) [0.3.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-rockfile [s390x] (mantic-proposed/none) [0.1.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-unicode-truncate [ppc64el] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: haskell-git-mediate [ppc64el] (mantic-proposed/none) [<IP_ADDRESS>-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: veryfasttree [ppc64el] (mantic-proposed/none) [4.0.1+dfsg-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-mac-address [ppc64el] (mantic-proposed/none) [1.1.5-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-mac-address [s390x] (mantic-proposed/none) [1.1.5-1] (no packageset)
[23:41] -queuebot:#ubuntu-release- New binary: r-cran-exactextractr [armhf] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:41] -queuebot:#ubuntu-release- New binary: rust-derive-builder-macro [ppc64el] (mantic-proposed/none) [0.12.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-self-cell [armhf] (mantic-proposed/none) [1.0.1-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-trackable-derive [arm64] (mantic-proposed/none) [1.0.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: r-cran-exactextractr [ppc64el] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-struct-patch-derive [armhf] (mantic-proposed/none) [0.3.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-derive-builder-macro [s390x] (mantic-proposed/none) [0.12.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: r-cran-exactextractr [s390x] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-derive-builder-macro [armhf] (mantic-proposed/none) [0.12.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-mac-address [armhf] (mantic-proposed/none) [1.1.5-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-trackable-derive [s390x] (mantic-proposed/none) [1.0.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-derive-builder-macro [arm64] (mantic-proposed/none) [0.12.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-struct-patch-derive [arm64] (mantic-proposed/none) [0.3.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-loom [arm64] (mantic-proposed/none) [0.5.6-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: haskell-git-mediate [arm64] (mantic-proposed/none) [<IP_ADDRESS>-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: veryfasttree [armhf] (mantic-proposed/none) [4.0.1+dfsg-1] (no packageset)
[23:50] -queuebot:#ubuntu-release- New binary: rust-unicode-truncate [s390x] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: veryfasttree [arm64] (mantic-proposed/none) [4.0.1+dfsg-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: veryfasttree [amd64] (mantic-proposed/none) [4.0.1+dfsg-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: haskell-git-mediate [s390x] (mantic-proposed/none) [<IP_ADDRESS>-1] (no packageset)
[23:53] -queuebot:#ubuntu-release- New binary: r-cran-exactextractr [arm64] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:53] -queuebot:#ubuntu-release- New binary: veryfasttree [s390x] (mantic-proposed/none) [4.0.1+dfsg-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New: accepted haskell-git-mediate [arm64] (mantic-proposed) [<IP_ADDRESS>-1]
[23:59] -queuebot:#ubuntu-release- New: accepted haskell-git-mediate [s390x] (mantic-proposed) [<IP_ADDRESS>-1]
[23:59] -queuebot:#ubuntu-release- New: accepted r-cran-exactextractr [armhf] (mantic-proposed) [0.9.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted r-cran-exactextractr [s390x] (mantic-proposed) [0.9.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-derive-builder-macro [armhf] (mantic-proposed) [0.12.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-derive-builder-macro [s390x] (mantic-proposed) [0.12.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-mac-address [armhf] (mantic-proposed) [1.1.5-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-mac-address [s390x] (mantic-proposed) [1.1.5-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-self-cell [armhf] (mantic-proposed) [1.0.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-struct-patch-derive [armhf] (mantic-proposed) [0.3.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted haskell-git-mediate [ppc64el] (mantic-proposed) [<IP_ADDRESS>-1]
[23:59] -queuebot:#ubuntu-release- New: accepted r-cran-exactextractr [ppc64el] (mantic-proposed) [0.9.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-derive-builder-macro [ppc64el] (mantic-proposed) [0.12.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-mac-address [ppc64el] (mantic-proposed) [1.1.5-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-struct-patch-derive [arm64] (mantic-proposed) [0.3.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-trackable-derive [arm64] (mantic-proposed) [1.0.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-trackable-derive [ppc64el] (mantic-proposed) [1.0.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-unicode-truncate [s390x] (mantic-proposed) [0.2.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted veryfasttree [arm64] (mantic-proposed) [4.0.1+dfsg-1]
[23:59] -queuebot:#ubuntu-release- New: accepted veryfasttree [ppc64el] (mantic-proposed) [4.0.1+dfsg-1]
[23:59] -queuebot:#ubuntu-release- New: accepted r-cran-exactextractr [arm64] (mantic-proposed) [0.9.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-loom [arm64] (mantic-proposed) [0.5.6-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-struct-patch-derive [ppc64el] (mantic-proposed) [0.3.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-trackable-derive [s390x] (mantic-proposed) [1.0.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted veryfasttree [armhf] (mantic-proposed) [4.0.1+dfsg-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-derive-builder-macro [arm64] (mantic-proposed) [0.12.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-trackable-derive [armhf] (mantic-proposed) [1.0.0-1]
[23:59] -queuebot:#ubuntu-release- New: accepted veryfasttree [s390x] (mantic-proposed) [4.0.1+dfsg-1]
[23:59] -queuebot:#ubuntu-release- New: accepted rust-self-cell [arm64] (mantic-proposed) [1.0.1-1]
[23:59] -queuebot:#ubuntu-release- New: accepted veryfasttree [amd64] (mantic-proposed) [4.0.1+dfsg-1]


 I only spent 15 there
 @Ivoriesablaze, You have more discipline then I do
 I just got a Google home mini
 nice
 it was such an amazing place
 i actually went because i needed a usb drive for backups for jennifer's computer. her old WD backup drive failed. it was over 5-6 years old and it had smart erros and was causing the OS to act funny trying to read the drive
 Best to replace the drive ASAP
 it wasn't a big deal. just backups. no new data. and it's ok to lose the historical backups
 so i got a new usb, and fired up the backup again
 sadly to say, it's time machine. she had the mac before she met me.
 she now mostly works on a chromebook


[01:00] <psusi> if a bug was mistakenly assigned to two packages instead of being reassigned, is there a way to remove the first task rather than just set its status to invalid?
[01:00] <micahg> psusi: no
[01:01] <micahg> you could remove the package if it's totally inappropriate
[01:01] <psusi> micahg, blast... can't even change the ordering?  if you look up the bug by number it pulls up the first project where it is invalid
[01:02] <psusi> bug #401627 never had anything to do with the GNOME Terminal project, but that's what comes up when you open the bug via  reference that does not specify the shadow package, like the link in the bug mail
[01:03] <psusi> there's no way to fix that?
[01:03] <micahg> psusi: that's a project, you can change it to the null project
[01:03] <psusi> hrm... then it would just come up as a bug in the "Null Project" wouldn't it?
[01:14] <RedSingularity> It seems that the font in launchpad just changed after a page refresh.  Was there something done at the server level recently?
[01:19] <lifeless> yes
[01:19] <lifeless> we just deployed a new version of the code base
[01:19] <lifeless> we're now following the canonical web site style guidelines, which should make it more readable and we shouldn't be changing it as often
[01:20] <RedSingularity> lifeless: ah ok, just checking.  Thanks :)
[01:20] <RedSingularity> looks good!
[01:21] <lifeless> micahg: psusi: you can't fix that [yet] because you cannot delete bugtasks.
[01:21] <lifeless> we're actively discussing how to do something that behaves (mostly) like deletion
[01:23] <psusi> what's wrong with ACTUAL deletion? ;)
[01:24] <lifeless> psusi: its very hard to undo
[01:24] <lifeless> psusi: things that are hard to undo you then need to make hard *to do*
[01:24] <psusi> it is?  doesn't seem any harder than it was to add the task in the first place?
[01:24] <lifeless> psusi: it is
[01:24] <lifeless> consider
[01:25] <lifeless> bug on terminator upstream and linux-kernel in ubuntu
[01:25] <lifeless> someone deletes the linux-kernel task
[01:25] <lifeless> someone else remembers the bug and searches in ubuntu, can' find it.
[01:25] <lifeless> if we don't actually delete, but just don't show, then they can find via advanced search.
[01:26] <lifeless> psusi: and what about deleting the last task?
[01:26] <lifeless> a bug with no tasks can't be shown or search by LP at the moment.
[01:27] <psusi> yea, shouldn't be able to delete the last one obviously ;)
[01:27] <lifeless> well, if the user model is 'they can be deleted', why not ?
[01:28] <psusi> because you have to have at least one
[01:28] <lifeless> well
[01:28] <lifeless> I'm pointing out the discussions that will happen
[01:28] <lifeless> they take time and effort
[01:28] <psusi> hrm... how is this problem any different than reassigning the project to the null project?
[01:28] <lifeless> and the friction makes the product feel less polished
[01:29] <lifeless> better to avoid it by designing something more graceful in the first place
[09:13] <lifeless> quick poll, does lp feel fast or slow at the moment (production, not edge or *staging)
[09:15] <maxb> fast-ish?
[09:18] <lifeless> maxb: fingers crossed
[12:45] <mhr3> hey there, is there any way to disable the "Successfully built" emails from daily builds?
[12:45] <mhr3> i really don't care if it was built successfully
[12:46] <maxb> Unfortunately, no.
[12:47] <bigjools> those emails need to be stopped
[12:47] <maxb> They kinda-sorta serve a purpose
[12:47] <mhr3> hmm.. too bad
[12:47] <maxb> It is mildly interesting knowing the ~bzr daily PPA recipes did someting
[12:48] <bigjools> we could make it opt-in, but now that the service is out of beta and supposedly reliable, it's probably more interesting to only know about failures :)(
[12:48] <mhr3> and another one: can i mark a branch in a recipe to not trigger daily build? ie i merge multiple branches in a recipe and don't want a rebuild everytime any of them changes
[12:49] <mhr3> ...just the primary one
[13:35] <didrocks> hey
[13:35] <didrocks> how long does it take for a dep-wait to be retried automatically in a ppa?
[14:14] <diwic> Hi! According to http://blog.launchpad.net/code/git-branch-imports-now-in-public-beta , importing Linux Kernel (or parts of it?) is not supported by Launchpad's code import. Well, I'd like to do this anyway, is there a workaround somehow?
[14:20] <maxb> diwic: The existence of https://code.launchpad.net/~vcs-imports/linux/trunk would suggest that it is no longer an issue
[14:22] <diwic> maxb, aha, interesting. Although when I try to look at the files present I get an error saying "Sorry, there was a problem connecting to the Launchpad server.
[14:22] <diwic> Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode. "
[14:23] <maxb> Unfortunately the web branch browser is a bit flaky
[14:23] <cjwatson> gmb: it looks like bug 28738 ended up Invalid in error.  It was previously Invalid in launchpad and Confirmed in malone, but I think that when all the Launchpad projects got merged it ended up simply being Invalid
[14:23] <cjwatson> gmb: should it be reopened?
[14:23] <cjwatson> I wonder how many bugs this happened to
[14:24] <maxb> diwic: However this shouldn't affect accessing the branch from a Bazaar client
[14:25] <gmb> cjwatson: Urk. That's slightly concerning. I'll re-triage it anyway.
[14:25] <gmb> sinzui: Do you know if any other bugs have been bitten by this ^^?
[14:25] <gmb> Whoops
[14:25]  * gmb accidentally WONTFIX'd it.
[14:28] <sinzui> gmb: I believe there were about 200 bugs where there were multiple tasks. I reviewed many of conflicting ones, they were fine. I know that some had their status fixed because the guess was wrong
[14:28] <gmb> Ah, right.
[14:29] <sinzui> I think the invalid in Lp is a special case. We (as the authors of this mess) should have known to retarget
[14:32] <cjwatson> gmb: ta muchly.  (not that I *hugely* care about this bug, I just happened to run across a use case for it.)
[15:09] <abentley> sinzui: I'm exposing setPackaging over the API, so that we can update it in-line.  Do I need to export both ProductSeries.setPackaging and SourcePackage.setPackaging, for the permissions to work right?
[15:10] <abentley> sinzui: And do you have a position on whether we should take SourcePackage or Distroseries,SourcePackageName as a parameter?
[15:10] <sinzui> abentley: I do not think so. Any logged in user can do it
[15:11] <abentley> sinzui: That's a bit surprising.  Okay.
[15:12] <sinzui> abentley: are you thinking that if the distroseries is not specified, we choose the current series for the distribution?
[15:12] <abentley> sinzui: No, I just see that some operations use SourcePackageName/DistroSeries, and others use SourcePackage, and I don't know what's The Right Way.
[15:14] <abentley> sinzui: e.g. ProductSeries.setPackaging takes SourcePackageName+DistroSeries, but the inverse operation is SourcePackage.setPackaging, which is a method of SourcePackage.
[15:14] <sinzui> abentley: okay, this related to the surprise in permissions. Lp does not know who is qualified to state what is packaged from where. User have made really stupid mistakes in the past. 1/3 of all packaging links were bogus...
[15:14] <abentley> sinzui: eeps.
[15:16] <abentley> sinzui: I just assumed it was restricted to DistoSeries or ProductSeries admins.
[15:16] <sinzui> ...user could/can link from the PS to a DS in Ubuntu or Debian. We actually do not trust them since 90% of the time project contributors do not understand packaging. The form suggest the current distroseries. They really do not have choice...
[15:18] <sinzui> We believe distro contributors have a better understanding, The SP is badly names. It is a DistributionSeriesSourcePackage. It knows its distro and series. We only need to PS.
[15:18] <abentley> I don't understand "We only need to PS".
[15:19] <abentley> sinzui: Agreed about the poor naming.
[15:20] <sinzui> abentley: Context is SP (disto and distroseries). PS provides product and productseries. We know the user
[15:20] <sinzui> We know the time, so we have the 6 pieces of information
[15:21] <sinzui> abentley: I think some of the underly trouble we have is that if you have an SP or DSP, we know the SPN. we often only know the SPN, so we need the distro and series clarification to know what obj to get
[15:22] <sinzui> abentley: We may be able to factor this out...
[15:23] <sinzui> abentley: User once could create a packaging link with no more than an SPN. We did not care if it was real or if it was ever published. We enforce that now, so maybe we could require an SP in the methods
[15:23] <abentley> sinzui: I think that if we decided to favour SourcePackage over SourcepackageName+DistroSeries, we would be able to work backwards to the point where the SourcePackageName+DistroSeries were retrieved.  But it would take some effort.
[15:24] <abentley> sinzui: Aha!  I did not realize that.
[15:24] <sinzui> yes. since the SP and DSP are mostly virtual, we are always working with an SPN
[15:25] <sinzui> (that is a lie though, DSP does have a schema representation now)
[15:25] <abentley> sinzui: Do you know why?  I've been looking around this area, and it seems that SourcePackage was once a real database object.
[15:26] <sinzui> abentley: packaging links have a sordid history. I should have blogged about the issue when I started fixing the bugs because people did not realise that we had started bridging-the-gap the same we were assigned it
[15:28] <abentley> sinzui: Anyhow, ISTM that SourcePackageName is not a good identifier of a SourcePackage, because it's not required to provide the same software across all distroseries.
[15:28] <sinzui> abentley: the sp and dsp is really a pointer to a place and a moment in time. The real data is an SPR that can be in several distros and series. We use the dsp and sp to look up what is this moment.
[15:29] <sinzui> abentley: that is very true
[15:30] <abentley> sinzui: Though I suppose the problem is more that packages get renamed from time to time and so we miss associations.
[15:30] <sinzui> abentley: so we removed the DB backing to normalise the data. we put some dsp back in the db because denormalised data can be fast
[15:30] <sinzui> abentley: yes that too has happend. gaim -> pidgin
[15:31] <abentley> sinzui: bazaar -> baz
[15:33] <abentley> sinzui: Okay, so I think we should favour SourcePackage when writing new functionality.  Client that have DistroSeries+SourcePackageName can easily acquire a SourcePackage.
[15:34] <sinzui> agreed.
[15:34] <abentley> sinzui: The reason why it mattered this morning was because I was going to expose ProductSeries.setPackaging over the API, but now I think SourcePackage.setPackaging will be enough.
[15:35] <sinzui> abentley: oh, sorry that I misunderstood the point from the start. I prefer SourcePackage.setPackaging when I write tests. ProductSeries.setPackaging could be factored out at this time.
[15:36] <sinzui> abentley: I think PackagingType was the historical reason they were different
[15:36] <abentley> sinzui: Sure.  Going into this, I assumed that they would have different permissions, so both might be needed.
[15:36] <sinzui> We are ignoring that at this time
[15:37] <abentley> sinzui: right.
[15:40] <exarkun> Launchpad bug imports use some xml format
[15:40] <exarkun> What should I do with a bug comment that includes \x1b?
[15:41] <sinzui> exarkun: maybe convert non-unicode to the (?) character
[15:41]  * sinzui looks for code
[15:42] <exarkun> it's only a couple places, I can do it manually
[15:42] <exarkun> let's call that the "destroy some data" option
[15:42] <exarkun> are there other options?
[15:43] <sinzui> exarkun: deduce the charset that was used, look up the character, replace it with the unicode char
[15:43] <daenney> did someone just nuke launchapd?
[15:44] <daenney> I'm getting a strange amount of 503's and the Please Try Again page
[15:44] <exarkun> sinzui: It's really \x1b
[15:44] <nigelb> Is loggerhead down?
[15:44] <CoffeeIV> I'm getting the "Try Again" message that says "Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad".  It is in trying to view a merge proposal and it has been happening for at least 10 minutes.  The project is private, but for what it's worth here is the url: https://bazaar.launchpad.net/~economist-magic/economist-magic/austin-janus-210-pretty-up-search-results/revision/3492
[15:44] <daenney> CoffeeIV: same here
[15:44] <exarkun> sinzui: ie, it's not character data
[15:45] <sinzui> oh escape
[15:51] <sinzui> exarkun: I would replace the instances with ESC or <ESC>
[15:52] <daenney> and launchpad is still 503'ing :|
[15:52] <nigelb> Is it launchpad or codebrowse that's 503-ing/
[15:52] <exarkun> sinzui: okay, thanks
[15:55] <daenney> nigelb: bazaar. so I'm guessing codebrowser
[15:56] <nigelb> yeah, loggerhead (the code browse thingy) has been crashing for me too.
[16:20] <MTecknology> File tdc_1.0.orig.tar.gz already exists in TDC PPA, but uploaded version has different contents.  <-- GRRR!!
[16:20] <MTecknology> I almost feel like this is a bug more than a feature..
[16:21] <MTecknology> I know the contents changes.. I changed it. Now I need to somehow figure out how to grab the original and do the changes as a patch.. or idk.. unless I change version numbers and I don't want to go to 1.1
[16:25] <MTecknology> Actually... the only change was a couple man page fixes and adding a changes file.
[16:30] <maxb> Change == new version
[16:31] <maxb> Don't lie to yourself about that and you'll never hit this error :-)
[16:31] <maxb> Just picture yourself having to ask someone "Do you have the first 1.0 or the second 1.0 version?" and it should be easy to see why this constraint is made
[16:45] <bigjools> maxb: that's one of the best ways of explaining it I've ever seen
[16:46] <maxb> :-)
[16:47] <MTecknology> makes sense
[16:47] <MTecknology> I still don't like it :P
[16:48] <bigjools> your apt client will also barf if it sees the same file with different contents
[16:48] <maxb> s/barf/silently do wrong stuff/
[16:48] <bigjools> heh
[16:49] <maxb> barfing would be preferable
[16:49] <maxb> (Not something I thought I'd ever say :-) )
[16:49] <bigjools> I've often felt that way :)
[16:51] <MTecknology> I wonder if this thing will ever make it to a 1.1 release..
[16:52] <MTecknology> This will be 1.0.1
[19:10] <Meths> I'm getting duplicate emails from LP at the moment - is this a known issue?
[19:15] <abentley> Meths: I don't believe so.  The most common cause of this is mailing lists that receive the same email as you.
[19:15] <abentley> Meths: can you post full headers of two duplicate emails?
[19:21] <Meths> Two emails here: http://pastie.org/private/qgzyjuaozlpvgiklfrcea
[19:24] <Meths> Seems LP has suddenly started including me separately.  Before I got emails with just the<EMAIL_ADDRESS>in the To field.
[19:28] <Meths> That first post seems a bad example of that.  This is the example of the new, duplicated merge message I'm getting with the two entries in the To field: http://pastie.org/private/jcldgzspbnxsrrpivb2zw
[19:29] <abentley> Meths: That is nuts.  Tim Bentley is my father's name.
[19:30] <Meths> Ah, so it's worse than duplication - it's cloning! ;)
[19:34] <abentley> Meths: This is more of a duplicate than I was expecting.  The only differences I can see are timestamps.
[19:36] <Meths> Does that mean you want a bug filed or if I told you it's only been happening as far as I can see for about the last 1.5 hours has anyone made changes that it could be linked to?
[19:38] <Meths> I've also got 3 OOPS IDs for failing to email a code review comment
[19:39] <abentley> Meths: I probably want a bug filed.  This has been consistent for the last 1.5 hours?  Is it all code review mail?
[19:40] <abentley> Meths: I expect the oopses are unrelated.
[19:43] <Meths> Yes it's all code review email, yes all code review email for the last 1.5 hours is duplicated but on closer inspection I hadn't got any code review email for quite a while before then so couldn't pin the time.  Bug email seems fine but unhelpfully I don't have any bug emails during the time period I have duped code emails!
[19:43] <Meths> I'll file the bug and let you guys ponder it.
[19:44] <Meths> Ah, just got bug email (non-duped) and code email (duped) so it's definitely just the code emails.
[19:45] <abentley> Meths: okay.  Please tag it "code-review".
[19:49] <Meths> Do you want me to include the contents of the pastebins?
[19:53] <abentley> Meths: yes please.
[19:59] <Meths> abentley: Done. Bug #728659
[19:59] <ubot5`> Launchpad bug 728659 in Launchpad itself "Getting duplicate code review emails" [Undecided,New] https://launchpad.net/bugs/728659
[21:38] <ti4mi> hello?
[21:38] <ti4mi> may someone help me to debug an upload error to a PPA?
[21:38] <ti4mi> I do not understand:
[21:38] <ti4mi> http://launchpadlibrarian.net/65476693/upload_2296710_log.txt
[21:43] <spiv> ti4mi: have you seen the advice on https://help.launchpad.net/Packaging/UploadErrors about that error?
[21:44] <spiv> (search for the phrase "already exists" on that page)
[21:44] <ti4mi> yes, but my error says that the package is already in the PPA but in the PPA there is none
[21:45] <ti4mi> https://code.launchpad.net/~grass/+archive/grass-devel/+packages
[21:46] <ti4mi> Error msg: File grass_7.0.0+0ubuntu1+23002~maverick1.tar.gz already exists in GRASS Development Packages
[21:47] <spiv> Ok, at this point I'm out of my depth... hopefully someone more knowledgable will turn up.
[21:48] <wgrant> ti4mi: You can't have two different files of the same name in a PPA.
[21:48] <wgrant> Well, that was good timing.
[21:49] <ti4mi> so I will put this question to launchpad QA
[21:49] <spiv> ti4mi: You just missed: <wgrant> ti4mi: You can't have two different files of the same name in a PPA.
[22:00] <ti4mi> ok got it. there were hidden super seeded files from previous uploads that failed to build
[22:00] <ti4mi> i increased the ~ubunutX version number in the recipie


[01:48] <Rombulas> hola!
[01:49] <Rombulas> Sorry, this is _totally_ offtopic, but I need help.  Could somebody who speaks Spanish _please_ call "Iberia" (the airline) and ask them,  if people can travel to Spain _without_ a COVID test if they stay in the TRANSIT area and continue going to Mexico ?
[01:50] <Rombulas> According to the government website of Spain, a negative Covid test is _not_ required to enter.
[01:50] <Rombulas> But if the Airline (IBERIA) sees it differently, I will be denied boarding.
[17:33]  * acaceo ola
[17:36] <GridCube> hi


[00:30] <telexicon> How on earth do I disable gdm?
[00:31] <MenZa> As in... stop gdm?
[00:31] <telexicon> yes.. /etc/init.d/gdm stop doesnt work anymore
[01:46] <fruitbag> Hey
[01:47] <MenZa> Herro.
[01:47] <fruitbag> I have a problem: whenever I boot Ubuntu from disk and run it, I get an out-of-range resolution message from my monitor.
[02:01] <forsaken> i just installed hardy and my mouse when i drag down the right side doesn't scroll, it did in alpha 2, anyone know why this is?
[02:01] <forsaken> dell intel laptop
[02:29] <selckin> choudesh_: needs a stable connection
[02:52] <telexicon> is something wrong with the I/O scheduler in hardy?
[02:53] <telexicon> im on gigabit and trying to copy a file across gigabit over ftp and I can only get 10MB/s
[02:53] <telexicon> on gutsy I was able to get 50MB/s
[02:56] <telexicon> well i dunno if thats IO scheduler.. could be a driver thing.. the system lags out so much while transferring it becomes unusable
[03:01] <kevogod> What kind of success are people having with the latest alpha release?
[03:45] <LimCore> can I use kernel <IP_ADDRESS> with my 7.10 ?  or is it too old?
[03:47] <Hobbsee> LimCore: this is not 7.10 support
[03:47] <LimCore> and for Hardy?
[03:47] <LimCore> well, never mind
[03:49] <Hobbsee> LimCore: you can try, but don't expect support for it
[04:50] <crimsun> right, so alsa* fixed from earlier.  Apologies for the logic snafu.
[04:53] <ryanpg> hey, I've got a weird one. I'm running hardy on a toshiba satellite A215, USB devices work once (I can plug a mouse in and it will be found) but only once, if a device is unplugged USB will be disabled
[04:54] <ryanpg> dmesg won't even report an attached device
[04:54] <ryanpg> BUT
[04:54] <ryanpg> if I run lsusb the device (like a mouse) will be found!
[04:54] <ryanpg> it has to be attached when I run lsusb however
[05:20] <ryanpg> it doesn't appear in /proc/bus/usb either
[05:23] <blkorpheus> ?
[06:00] <richard_> I want to help out more with ubuntu where should I start?
[06:00] <DanaG> Oh yeah, something new with ALSA?
[06:01] <teethdood> totem is beyond stuttering...it's crawling frame by frame. I used to edit the preferences and changed the video plugin to something else
[06:01] <teethdood> but the preferences menu is gone!
[06:01] <DanaG> Oh, and here's a novel use of PulseAudio: allow people to use the Dolby Digital encoding on nvidia's ancient, abandoned nvsound / nvaudio OSS drivers with ALSAapps.
[06:02] <crimsun> bypass ALSA altogether and just use OSSv4 (or newer) as the backend.
[06:02] <DanaG> Doesn't do the Dolby Digital ENcoding.  I don't need it, but some people do.
[06:03] <DanaG> Unless I'm misinterpreting your response.
[06:03] <DanaG> http://ubuntuforums.org/showthread.php?t=253725&page=16
[06:04] <DanaG> oopsie, wrong page of the thread, but whatever.
[07:26] <sparr_> do -backports questions belong here?
[09:53] <Oli``> Does X lock (for a second or two) up intermittently for anybody here when you use the main menu (notably Places, for me)?
[11:04] <mlpug> I took hardy test 3, downloaded sources and compiled dvb/dvb-usb modules. outputted .ko files are roughly ten times as big as the corresponding .ko files under /lib/modules. Any idea why is this? Is this OK?
[11:05] <DarkMageZ> debugging symbols could be part of it.
[12:22] <picard_pwns_kirk> how do I configure my touchpad?
[12:22] <picard_pwns_kirk> I want to enable edge scrolling, and disable the tap to click, but there's no xorg.conf file
[12:29] <picard_pwns_kirk> is there any way I can set this?
[12:44] <Tomcat_> picard_pwns_kirk: You can try gsynaptics
[12:44] <picard_pwns_kirk> already did
[12:44] <picard_pwns_kirk> needs a setting in the xorg.conf file
[12:46] <Tomcat_> picard_pwns_kirk: man synaptics
[12:48] <picard_pwns_kirk> it refers me to a bunch of settings in the xorg.conf
[12:48] <picard_pwns_kirk> and I've already tried creating one by hand
[12:49] <Tomcat_> picard_pwns_kirk: Well, that's about how you configure your touchpad. ;)
[12:49]  * Hobbsee suspects picard_pwns_kirk was looking in the wrong place, or did a typo, or something
[12:49] <Hobbsee> xorg.conf's usually get generated, unless they get deleted
[12:49] <picard_pwns_kirk> new version of xrog
[12:49] <picard_pwns_kirk> xorg**
[12:50] <picard_pwns_kirk> read the release notes
[12:50] <Tomcat_> picard_pwns_kirk: http://www.compass.com/synaptics/ <- That's the only other thing I can suggest.
[12:51] <Hobbsee> picard_pwns_kirk: sure, but i thought they still generated an xorg.conf by default anyway
[12:51] <picard_pwns_kirk> hopefully it gets fixed, I'll subscribe to any bugs
[12:51] <Tomcat_> Well, in Alpha 3 there is one. ;)
[12:51] <Tomcat_> It's just... barely empty.
[12:54] <Tomcat_> Eh, almost empty.
[13:00] <mlpug> where is information about the role of the files in /lib/firmware? when are they used and what triggers their use? do drivers have "pointer" to corresponding .fw and when driver is loaded then .fw is loaded to the device or what is this?
[13:07] <Tomcat_> mlpug: See /etc/udev/rules.d/80-programs.rules ... seems udev is doing that when a driver is loaded.
[13:08] <Tomcat_> mlpug: Some (sparse) info is available in /usr/share/doc/udev
[13:11] <Tomcat_> mlpug: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=extras/firmware/firmware.sh;hb=HEAD <--- See this for what the firmware_helper does
[14:02] <Enselic> I have just upgrade from Gutsy to Hardy Alpha 3, and gnome-panel crashes for me because of this: gnome-panel: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: glib_gettext. Any clues? libglib2.0-0 seems to be up to date
[14:03] <Enselic> Ah right, I have my own versino of gnome-panel in /usr/local...
[16:00] <Enselic> Um what password should I use to unlock id_rsa? Neither login or key pass works
[16:00] <Enselic> nor*
[16:07] <selckin> the one you used to create it
[16:12] <Enselic> that's the "key pass" and I have tried that
[16:12] <Enselic> I discovered that if I take Deny, ssh will still be able to use the key..
[16:19] <LjL> NOTICE - KDE 4.0 support is to be obtained in #kubuntu-kde4
[16:24] <_stress_> do you know any good "webpage creator" for linux that does the same work as dreamwave?
[18:02] <DanaG> That's odd: you can no longer set the brightness of the LCD when on battery.
[18:02] <DanaG> Now it's just "Reduce Backlight Brightness".
[18:06] <DanaG> And the logic of "Brightness when on battery" in gconf is BACKWARDS.
[18:06] <DanaG> I set it to 63%, I get 37% brightness, and vice versa.
[18:47] <nwps> can anyone help; i just moved from gentoo to hardy alpha 3. i have a encrypted partition from gentoo that uses cryptoloop, but i can't seem to be able to mount it on kubuntu. cryptoloop and aes-generic modules are loaded, but i still get "mount: you must specify the filesystem type". any ideas?
[18:49] <DanaG> Perhaps there's a package you need to install to get crypto support.
[18:49] <DanaG> (I'm just guessing; I've never used cryptoloop.)
[18:50] <DanaG> search for 'crypt' in the package manager (such as aptitude).
[18:50] <nwps> i always thought you just needed util-linux with "crypto" support (USE="crypt" on gentoo) and the kernel modules.
[18:50] <blkorpheus> where is the key?
[18:51] <blkorpheus> probably still on the gentoo box?
[18:51] <blkorpheus> what used to be gentoo?
[18:52] <nwps> no, i don't think cryptoloop even uses separete key files? i have done re-installs before and the encrypted partition always worked after that.
[18:53] <DanaG> !info cryptsetup
[18:53] <ubotu> cryptsetup: configures encrypted block devices. In component main, is optional. Version 2:1.0.5-2ubuntu8 (hardy), package size 86 kB, installed size 404 kB
[18:55] <nwps> i have had the same kind of problem before on gentoo. then i had to re-emerge util-linux with "old-crypt" use-flag, but that was probably 2 years ago, when something big was changed in util-linux (i think).
[19:57] <WorkingOnWise> any ideas why the built in media reader doesnt see any cards? the reader is seen by Ubuntu. I tied 2 differant media cards (memory stick (256mb) and sd card (128mb) Both cards do read/write fine in another machine.
[19:59] <WorkingOnWise>  if i boot up with the card in the reader, or if i insert it after i am logged in, still nothing
[20:31] <h3sp4wn> Anyone know of a window manager I can get from the repos with proper xrandr 1.2 support
[20:32] <crdlb> hmm? I didn't know window managers had to care about that
[20:34] <crdlb> I know that most (if not all) video drivers can't do rotation with compiz running, but that's not compiz's fault
[20:37] <h3sp4wn> Well otherwise how do you switch the primary screen
[20:37] <h3sp4wn> i.e to set which screen you want apps to open onto etc
[20:38] <crdlb> oh, no idea
[21:26] <vinicius_> after I did the upgrade from Gutsy to Hardy (and a few installations and configurations), every time I login, after typing username and password on GDM, the system popups a window saying in portuguese "no language pt_BR available", or something like that... how can I know wich program is popping up this window? it does not really deny me of using everything normally, but it's annoying...
[21:30] <nanonyme> vinicius_, what does locale tell you when you run it in terminal?
[21:35] <Javid> Is there even a beta yet?
[21:36] <UnNaturalHigh> Javid, www.google.com
[21:37] <Javid> I see avoiding being actually helpful is still the preferred approach.
[21:37] <UnNaturalHigh> Javid, no, but catering to people who lack the intelligence to look before they ask is not what this channel is about
[21:38] <UnNaturalHigh> simple google searches such as "ubuntu hardy heron" or "ubuntu 8.04" are far from difficult to conceive and execute
[21:38] <Javid> If you supplied a "yes" or a "no" we'd be entirely done with this conversation already
[21:39] <Javid> I can only conclude that you don't know either and are being a dick for your own amusement.
[21:39] <crdlb> let's cut that out now
[21:39] <crdlb> there is not a beta yet
[21:39] <crdlb> the beta comes out approximately a month before release
[21:39] <Javid> That's what I was after, thanks
[22:01] <serios> meh it really sucks that mac -> linux filesystem compatabilty is about nil
[22:01] <serios> :|
[22:01] <serios> sharing 2 hfs+ journaled drives on the network via ubuntu is going to be a sucky affair
[22:02] <vinicius_> nanonyme, says I have pt_BR language
[22:08] <BluesKaj> ok folks what's the recomendation for the konq flash plugin , or is it still broken for kubuntu 8.04 users ?
[22:18] <GuyFromHell> anyone got a solution for dependancies ultimate-failure when trying to get kde4 installed?
[22:30] <Adlai> aptitude just segfaulted when I marked a package 'to be upgraded'
[22:30] <Adlai> this hopefuly isn't common
[22:30] <Adlai> s/l/ll
[22:42] <BluesKaj> hey what's the fix for orphaned modules? I can't understand why there would be such a problem after a clean install .
[23:34] <MGrunde_> !apparmor
[23:34] <ubotu> For information about the AppArmor security framework employed in Ubuntu (since Gutsy Gibbon), see https://help.ubuntu.com/community/AppArmor
[23:34] <MGrunde_> Is there a still a problem with AppArmor in alpha three?
[23:49] <twb> Are release candidates for the live .iso's publicly accessible?  If so, from where?
[23:50] <twb> If they will be, but aren't yet, what is the time scale for same?