[00:00] <davecheney> http://paste.ubuntu.com/6840930/
[00:00] <davecheney> great, how am I supposed to shut down this environment ?
[00:18] <wallyworld_> i would kill the machines by hand and delete the control container, then delete the jenv
[00:21] <thumper> davecheney: really, WTF?
[00:22] <thumper> how do I remove the govet check?
[00:22] <thumper> wallyworld_: I upgraded to trusty last night
[00:22] <thumper> trunk starts the local provider
[00:22] <wallyworld_> hmmm
[00:22] <thumper> although my http-proxy wasn't on the right port
[00:23] <thumper> trunk mind, not release
[00:23] <thumper> release is all fubared
[00:23] <wallyworld_> when i tried on friday, the agent ran, but no lxc container would start
[00:23] <thumper> for some reason I've lost the all-machines.log
[00:23] <wallyworld_> yeah, me too
[00:23] <thumper> need to figure that out
[00:23] <thumper> I have a branch to submit for destroy
[00:23] <wallyworld_> \o/
[00:24] <thumper> if I can get lbox shite working
[00:24] <wallyworld_> thumper: with go vet, i installed from source and got it to work that way
[00:24] <thumper> wallyworld_: you installed go from source?
[00:24]  * wallyworld_ tries to remember
[00:24] <wallyworld_> go get -u ...something
[00:24] <wallyworld_> let me see if my history shows it
[00:25] <wallyworld_> i think the error message gave a hint
[00:25] <thumper> it tries to open the /usr/lib/go pkg dir
[00:25] <thumper> for some reason it isn't honouring the GOPATH
[00:26] <thumper> davecheney: can I just change an environment variable?
[00:26] <wallyworld_> not sure if this was the attempt that worked
[00:26] <wallyworld_> sudo bash -c "export GOPATH=/usr/lib/go; go get code.google.com/p/go.tools/cmd/vet"
[00:26] <wallyworld_> something like that was necessary
[00:26] <wallyworld_> i just assumed it was my fucked up set up
[00:26] <wallyworld_> didn't realise it was a general issue for trusty
[00:27] <thumper> hmm...
[00:28] <thumper> yeah, that looks weird to the extent I don't want to do that
[00:28] <wallyworld_> i may have had to do it with a GOPATH pointing to a dir off my home, not usr/lib
[00:28] <wallyworld_> but i recall sudo and messing with GOPATH was necessary
[00:28] <thumper> a fuck it...
[00:30] <thumper> nah, that doesn't work
[00:31] <wallyworld_> hmmm sorry. i can't recall exactly what worked. i *think* i had to point GOPATH to a local src dir, but use sudo. not sure thpugh
[00:33]  * thumper stabs .lbox.check
[00:34] <thumper> FARK
[00:34] <thumper> can't propose with a dirty branch
[00:35] <thumper> so either I commit the lack of vet
[00:35] <thumper> or don't use lbox
[00:35]  * thumper decides to skip lbox
[00:36] <wallyworld_> \o/
[00:39] <thumper> wallyworld_: https://code.launchpad.net/~thumper/juju-core/fix-lxc-destroy/+merge/203861
[00:39] <wallyworld_> looking
[00:42] <wallyworld_> thumper: done. btw did you see google offloaded motorola to lenovo. those lenovo guys are really going on a shopping spree
[00:42] <thumper> no I didn't know that
[00:43] <thumper> wallyworld_: did google keep all the patents?
[00:43] <wallyworld_> yep :-)
[00:43] <wallyworld_> of course
[00:43] <thumper> heh
[00:43] <wallyworld_> they licenced them to lenovo
[00:43] <thumper> wallyworld_: I can't land it yet, it didn't fix the problem
[00:43] <wallyworld_> so they paied $12bil, sold for $3bil
[00:46] <thumper> ah...
[00:46] <thumper> hang on
[00:46] <thumper> I see what's happened now
[00:46] <thumper> I have a running juju machine agent for zero
[00:46] <thumper> rebuilding a local juju doesn't help destroy environment
[00:47] <thumper> because the environment is already running
[00:47] <thumper> and using an old jujud
[00:47] <thumper> which doesn't have my fix
[00:47] <thumper> FFS
[00:52] <thumper> manual hackery FTW
[00:53] <wallyworld_> i've done the same thing before too
[00:57] <thumper> ok, at least that is the local provider starting and stopping in trusty
[00:57] <thumper> now to poke and see why we have no all-machines.log
[00:58] <thumper> hmm... I think I may see
[01:00] <axw> thumper: I looked into that the other day, it was permissions
[01:00] <thumper> yeah, I saw that too
[01:01] <thumper> axw: have you a fix ready?
[01:01] <thumper> if not, I'll do it
[01:01] <axw> thumper: I think we may have to do something yucky, like symlinking to /var/log/juju
[01:01] <axw> no
[01:01] <axw> it passed out of my memory on the flight back
[01:07] <thumper> wallyworld_: I'm witting in our weekly hangout...
[01:07] <wallyworld_> oh yeah
[01:12] <hazmat> thumper, how's proxy support coming?
[01:12] <thumper> hazmat: trunk is almost feature complete
[01:13] <thumper> there are a few things outstanding
[01:13] <thumper> - remove old apt proxy cruft in container setup
[01:13] <thumper> - make sure containers get the proxy info for the container providers
[01:13] <thumper> - some upgrade code
[01:16] <hazmat> hmm.. that sounds pretty good... does that include things like the cli respecting std http_proxy env vars for tool lookup?
[01:16] <thumper> hazmat: in a hangout just now
[01:16] <thumper> hazmat: how long have you got?
[01:17] <hazmat> thumper, i'll make some time.. i'm pushing through on a late night
[01:32] <thumper> waigani: hangout? standup
[01:32] <waigani> yep
[01:33] <davecheney> cap
[01:33] <davecheney> crap
[01:33] <davecheney> now destroy-environment cannot save me
[01:33] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1274355
[02:01] <thumper> school run
[02:01] <thumper> bbs
[02:04]  * axw rejoices and promptly stops thinking about windows cli
[02:05] <axw> davecheney: try destroy-environment --force
[02:05] <axw> davecheney: actually... what version are you on?
[02:05] <davecheney> trunk
[02:06] <davecheney> axw: yup
[02:06] <davecheney> that worked
[02:06] <axw> davecheney: destroy-environment now goes and talks to the API server to destroy the environment "cleanly"
[02:06] <axw> if it's borked, --force is required
[02:07] <axw> we just had a chat on our scrum, and figured we should probably tell that to the user if it fails and --force wasn't specified
[02:13] <davecheney> couldn't hurt
[02:51]  * thumper sighs
[02:52]  * thumper created a broken local provider
[02:52]  * thumper deletes things
[03:31] <thumper> fark!!!
[03:31] <thumper> I think it is apparmour
[03:32] <axw> thumper: doing what?
[03:32] <thumper> stopping writing to ~/.juju/log/all-machines.log
[03:32] <axw> hm ok
[03:33]  * thumper pokes and tweaks
[03:36]  * thumper does something icky
[03:46]  * axw goes out for lunch
[03:46] <axw> bbl
[03:47] <axw> if I don't return, the heat has claimed me
[03:47] <thumper> wallyworld_: ping
[03:47] <thumper> wallyworld_: who owns your /var/log/syslog file?
[03:48] <axw> thumper: mine is syslog:adm
[03:48] <thumper> hmm...
[03:48] <thumper> mine is messagebus:adm
[03:48] <thumper> no idea where that came from
[04:14] <wallyworld_> thumper: um, let me check
[04:14] <thumper> wallyworld_: that's ok
[04:15] <wallyworld_> i don't have one right now
[04:15] <thumper> all these permission problems are due to rsyslog apparmor profiles
[04:15] <wallyworld_> ah
[04:15] <thumper> I've got a work-around
[04:15] <thumper> but I need to go make dinner
[04:15] <thumper> so it'll have to wait
[04:15] <wallyworld_> f*cking apparmor
[04:15] <wallyworld_> :-)
[04:15] <thumper> waigani: is there a bug for the "no all-machines.log for the local provider"?
[04:16] <waigani> thumper: I have not created on
[04:16] <waigani> *one
[06:16] <axw> wallyworld_: when you're not busy, can you please poke the bot?
[06:16] <wallyworld_> sure
[06:16] <wallyworld_> will do it now
[06:17] <wallyworld_> axw: poked
[06:17] <axw> thanks
[06:38] <axw> wallyworld_: I thought there was a reason we needed FullPath for the manual bootstrap - the reason eludes me though
[06:42] <wallyworld_> axw: FullPath is filled in when the particular tools are read from simplestreams. but is was unnecessary to fill in that value when writing metadata files caused it is ignored then
[06:43] <wallyworld_> we just store ralative path in the json
[06:43] <wallyworld_> and construct fullpath when needed as the metadata is loaded
[06:43] <axw> yeah, I thought it was used in-memory... my memory may just be faulty though
[06:44] <axw> welp, seems to work anyway
[06:44] <wallyworld_> yay
[06:53] <axw> wallyworld_: in provider/maas/storage.go, there's talk about 404 and IsNotFoundError
[06:53] <axw> does this not work?
[06:53] <wallyworld_> um
[06:54] <wallyworld_> that works
[06:54] <wallyworld_> but the issues is URL()
[06:54] <axw> ah sorry
[06:54] <axw> URL, not Get
[06:54] <wallyworld_> yeah, maas is the only one that can't give a url for a non existent fle
[06:54] <wallyworld_> so i changed dummy storagr to match that
[06:54] <axw> wallyworld_: ahh, so MAAS 404s even for URL
[06:55] <axw> got it
[06:55] <wallyworld_> yeah :-(
[06:55] <wallyworld_> sadly yes
[07:00] <axw> wallyworld_: why do we no longer set imagemetadata.DefaultBaseURL in bootstrap? and does tools.DefaultBaseURL continue to be updated?
[07:00] <axw> (sorry for dumb questions, just trying to be thorough...)
[07:00] <wallyworld_> axw: np. the image metadata is uploaded from a local dir to cloud storage
[07:00] <wallyworld_> it was a mistake to set th default url
[07:00] <wallyworld_> in the cloud storage, the uploaded metadata is in the search path
[07:01] <wallyworld_> and keeping default url unchanged means we fall back
[07:01] <wallyworld_> if no images found in user metadata
[07:01] <axw> ok
[07:01] <axw> whereas if we change it, it'll try to look in cloud storage and in the local dir
[07:02] <axw> right?
[07:02] <wallyworld_> yeah, but it will error out later in the boot process
[07:02] <wallyworld_> i didn't look into why
[07:02] <axw> mk
[07:02] <wallyworld_> i decided it was wrong to change the default url
[07:03] <wallyworld_> tools url is changed cause that's what sync tools needs
[07:03] <wallyworld_> end result - tools and image metadata is uploaded to cloud storage if local dir is used
[07:04] <axw> thanks
[07:04] <wallyworld_> and cloud storage is in simplestreams search path, behind config urs and ahead of default locations
[07:04] <axw> got it
[07:04] <axw> I remember why FullPath/URL was required before: we used to do a URL fetch, rather than go through storage
[07:05] <axw> so we previously had to keep the URL in memory to pass along to the merging bit
[07:32] <wallyworld_> axw: just to check - i'm pretty sure that we don't need full url now right
[07:32] <axw> wallyworld_: right
[07:33] <wallyworld_> cool, that matches my understanding too
[07:33] <axw> since we use the path & storage now
[07:33] <wallyworld_> yep
[07:33] <wallyworld_> just wanted to be 1000% sure :-)
[07:33] <axw> :)
[07:34] <wallyworld_> axw: with the abs(), i thought it better to report the whole dir to the user to avoid confusion
[07:35] <axw> okey dokey
[08:41] <jam> axw: do we actually have a solution for people trying to use juju-core with Canonistack and setting up 'sshuttle' while they are trying to bootstrap?
[08:42] <jam> or does bootstrap itself complete because it uses the SSH redirection, (I thought one of the steps was to directly connect to the API to know that it is up, so now that step will fail)
[08:42] <axw> jam: bootstrap works because it goes through SSH, sshuttle is still required as it was before post-bootstrap
[08:43] <axw> there's no API interaction during bootstrap
[08:43] <jam> axw: so "before" you could use sshuttle to the bootstrap node once it came up, and then everything else would go direct to the API, that stil works?
[08:43] <axw> we did talk about that during SFO - juju status at the end - but it hasn't been implemented
[08:43] <jam> ah, k
[08:43] <axw> jam: yep
[08:44] <axw> sshuttle -r ubuntu@bootstrap-node subnet/cidr
[08:45] <axw> I would kinda of like it if API connections did some magical tunnelling as a fallback, but it's probably too messy
[08:46] <jam> axw: It would be helpful for people at Canonical, I'm not sure that it is a general solution.
[08:47] <jam> Saying "you need public access to the cloud machines you are using" doesn't seem like a particularly bad thing to me.
[08:47] <axw> yeah I guess so. I don't really know how many of our private cloud users will have the same issues
[08:48] <axw> probably not that many
[08:49] <mgz> morning
[08:49] <axw> morning mgz
[09:01] <jam> axw: I think you'll generally need some-sort-of-VPN but we actually have 2 different ones inside Canonical. (the Server Stack needs OpenVPN to access, and doesn't work via SSH at all)
[09:02] <axw> true, though our bootstrap won't even work without ssh access
[09:03] <axw> I was just thinking it'd be nice to have guaranteed API access if bootstrap succeeds
[09:03] <axw> it's not a big deal to have to sshuttle though, really
[09:06] <mgz> I may be a min or two late for meeting later
[09:33] <rogpeppe> wallyworld_: ping
[09:36] <rogpeppe> axw: you reviewed this branch, i think: https://codereview.appspot.com/58510044
[09:37] <rogpeppe> axw: i'm having difficulty understanding how it works - did you work it out?
[09:52] <axw> rogpeppe: sorry, which part?
[09:53] <axw> doh, good catch on the dummy storage boolean...
[09:54] <axw> rogpeppe: re "How does the URL get into the metadata now?" -- simplestreams metadata doesn't encode the URL
[09:55] <axw> we used to store it in the in-memory object when tools metadat was fetched by URL
[09:55] <axw> but now we use the path, and go through storage
[09:56] <axw> rogpeppe: and the fact taht we were calling the environment storage'URL
[09:56] <axw> oops
[09:56] <axw> storage's URL method, caused an error wtih MAAS
[09:59] <thumper> where's wallyworld_
[09:59] <wallyworld_> here
[10:04] <wallyworld_> on the juju call. yay. will look in a bit. i'm also 3/4 drunk :-D
[10:05] <bigjools> wallyworld_: ROFL
[10:41] <thumper> wallyworld_: 3/4 drunk and working on maas fixes \o/
[10:41] <wallyworld_> no, i'm ok now :-)
[10:41] <bigjools> haha
[10:41] <wallyworld_> it's been an hour or more since my last wine, i was exagerating :-)
[10:42] <wallyworld_> a man can drink a glass of wine with dinner :-)
[10:42] <bigjools> digging more like
[10:42] <bigjools> a single glass has been known to get you blotto
[11:03] <fwereade> right, I'm not interviewing horacio right now because we need to turn the power off here to investigate scary burning smells
[11:03] <fwereade> hopefully I will be back shortly
[11:04] <natefinch> fwereade: good luck
[11:04] <fwereade> cheers
[11:08] <jam> mgz: are you available to just hang out?
[11:12] <rogpeppe> axw, wallyworld_: what's the purpose of ToolsMetadata.FullPath? are we actually setting it now?
[11:12] <rogpeppe> ah! it's ignored
[11:12] <wallyworld_> rogpeppe: it's used when wget fetches the tools
[11:13] <wallyworld_> it's ignore writing out
[11:13] <rogpeppe> wallyworld_: ok
[11:13] <wallyworld_> it is composed from the relative path stored in the json
[11:13] <wallyworld_> composed when needed
[11:15] <wallyworld_> rogpeppe: is trunk working?
[11:15] <rogpeppe> wallyworld_: i'm going to try it in a mo
[11:15]  * wallyworld_ crosses his fingers
[11:16] <mgz> jam: sure
[11:16] <jam> mgz: I'm just going to grab a snack, mumble or g+?
[11:17] <mgz> lets try mumble first, I'll be on there
[11:26] <jam> yeah, I can't understand you at all, which means it is messed up, I'll reconnect 1 more time
[11:27] <mgz> jam: we'll have to just fall back to hangout
[11:27] <mgz> use the daily standup  one?
[11:29] <rogpeppe> wallyworld_: sorry, it appears that there are no spare boxes currently, so testing it will have to wait for a little bit
[11:29] <wallyworld_> ok, np
[11:29] <jam> mgz: now ff is freaking out again... just a sec
[11:29] <mgz> :)
[11:30] <wallyworld_> rogpeppe: i'm quietly confident it will work :-)
[11:30] <jam> mgz: I'm in the "juju core team" one from earlier today
[11:30] <rogpeppe> wallyworld_: did you see my remarks on your CL?
[11:31] <wallyworld_> no, i'll look
[11:35] <wallyworld_> rogpeppe: tomorrow i'll fix the remaining issues, thanks
[11:35] <rogpeppe> wallyworld_: thanks
[11:36] <wallyworld_> rogpeppe: it seems that we're still not quite universally consistent with converting relative paths to absolute when running commands
[11:36] <rogpeppe> wallyworld_: yeah, we should probably use Context.AbsPath throughout
[11:37] <wallyworld_> yeah, i didn't realise we had that method
[12:07] <dimitern> rogpeppe, i'm trying to debug this missing GOPATH issue that cause uniter tests to fail in an install hook
[12:07] <dimitern> rogpeppe, so i'm using your debug.Callers() thing to dump the stack when I detect GOPATH is empty in testing/charms.go:init()
[12:08] <rogpeppe> dimitern: ok
[12:08] <dimitern> rogpeppe, but what I'm getting is a bunch of files, and the line number for each one is always the last line in the file
[12:08] <dimitern> rogpeppe, what does that mean?
[12:08] <rogpeppe> dimitern: paste?
[12:08] <jam> rogpeppe: so if you *don't* supply -test.timeout, then when it times out it just says "test took to long" if you *do* supply a value (like 10s in my testing) then you get a panic
[12:09] <dimitern> rogpeppe, http://paste.ubuntu.com/6843438/
[12:10] <dimitern> rogpeppe, and my changes to init(): http://paste.ubuntu.com/6843442/
[12:11] <dimitern> rogpeppe, for some reason during the install hook the environment gets reset or something and GOPATH is lost
[12:15] <jam> rogpeppe: it looks like '-test.timeout' is for each individual test triggering a panic, vs the global timeout being run by the meta-process when running multiple packages
[12:19] <rogpeppe> jam: interesting
[12:20] <rogpeppe> dimitern: sorry, i got waylaid by insanity. i have to go to lunch now, sorry, otherwise i won't make it to the discussion in 40 mins. will look when i can.
[12:21] <dimitern> rogpeppe, ok
[13:06] <dimitern> rogpeppe, I found a solution: http://paste.ubuntu.com/6843674/ adding GOPATH to the list of env vars a hook gets
[13:06] <rogpeppe> dimitern: yeah, i thought that might be the problem
[13:07] <dimitern> rogpeppe, what i don't get is why it wasn't a problem before?
[13:07] <rogpeppe> axw: are you around?
[13:12] <rogpeppe> dimitern: agreed - i'm not sure either
[13:12] <rogpeppe> dimitern: there's a perhaps-better solution
[13:12] <dimitern> rogpeppe, what's that?
[13:12] <rogpeppe> dimitern: just make it so init doesn't panic
[13:13] <dimitern> rogpeppe, but it won't solve the issue - it won't find the repo path still
[13:13] <rogpeppe> dimitern: it doesn't need the repo path
[13:13] <rogpeppe> dimitern: it's just re-running the test binary as a hook, right?
[13:13] <dimitern> rogpeppe, why don't remove init() altogether then?
[13:15] <dimitern> rogpeppe, it seems better to get the absolute path of the charms.go in testing and infer the path from there
[13:15] <dimitern> rogpeppe, is that possible?
[13:16] <rogpeppe> dimitern: how would you do that?
[13:16] <rogpeppe> dimitern: i think that removing the init altogether is reasonable though
[13:16] <dimitern> rogpeppe, well, in python i'll do it with os.path.realpath(".") or something
[13:16] <rogpeppe> dimitern: the current directory isn't related to where charms.go is
[13:17] <dimitern> rogpeppe, no, sorry - i'll use the __file__ magic const that contains the full path to the current file
[13:17] <dimitern> rogpeppe, kind of like $0 in bash
[13:17] <rogpeppe> dimitern: define testing.Charms as a function, say func() *charms.Repo
[13:17] <rogpeppe> dimitern: no such thing in Go
[13:17] <jam> there is some 'build' runtime magic stuff
[13:18] <rogpeppe> dimitern: (and probably a good thing too, as we'd be tempted to do this, and it would be a bad idea :-])
[13:18] <rogpeppe> jam: we're already doing that
[13:18] <jam> we use it in testing/charms.go ? something ilke that
[13:18] <rogpeppe> jam: but GOPATH isn't set if we re-exec the binary
[13:20] <rogpeppe> dimitern: something like this perhaps? http://paste.ubuntu.com/6843741/
[13:21] <rogpeppe> dimitern: that actually makes tests that don't use testing charms slightly faster
[13:21] <rogpeppe> s/tests/suites/
[13:21] <axw> rogpeppe: sort of around, what's up?
[13:22] <rogpeppe> axw: just wondering whether it's currently possible to manually bootstrap on a node, but not use the manual/null provider
[13:23] <axw> rogpeppe: bootstrap or "provision"?
[13:23] <axw> add-machine?
[13:23] <rogpeppe> axw: bootstrap
[13:23] <axw> no
[13:23] <TheMue> rogpeppe: interested in reviewing https://codereview.appspot.com/58510045/? it still misses tests (have to think about it and how to do best), but it works live.
[13:23] <rogpeppe> axw: right, i thought so
[13:23] <rogpeppe> axw: but needed to check
[13:23] <axw> rogpeppe: nps. who wants that and why?
[13:24] <rogpeppe> axw: there are currently some people who have duplicated the entire bootstrap logic in shell (and it works... kinda)
[13:24] <rogpeppe> axw: just to get this behaviour
[13:24] <rogpeppe> axw: the specific reason is that they want to bootstrap juju onto a maas controller node
[13:24] <dimitern> rogpeppe, it doesn't work
[13:24] <axw> oh, the installer thing
[13:24] <dimitern> rogpeppe, it still fails if GOPATH is not set
[13:25] <rogpeppe> dimitern: doesn't matter
[13:25] <rogpeppe> dimitern: why would that hook code be calling testing.Repo ?
[13:25] <axw> rogpeppe: why do they not just use the manual provider...?
[13:25] <axw> no ssh?
[13:25] <rogpeppe> axw: because they want the environment to be using the maas provider
[13:25] <axw> oh yeah, right
[13:26] <dimitern> rogpeppe, it doesn't, it just imports stuff from testing
[13:26] <rogpeppe> dimitern: right, so it's ok then
[13:27] <dimitern> rogpeppe, adding GOPATH to that list of vars fixes the issue, i don't want to make it any more intrusive, and i want to land this already
[13:27] <rogpeppe> dimitern: that actually makes it *more* intrusive, no?
[13:27] <rogpeppe> dimitern: because that list of vars is in production code, no?
[13:28] <dimitern> rogpeppe, so what - in production it will be empty if you don't have go installed, and even if you do, it won't affect anything
[13:29] <rogpeppe> dimitern: we should not be changing production code for this kind of reason - it's a testing bug and it should be fixed in the testing code
[13:29] <rogpeppe> dimitern: there might even be a less intrusive way, one mo
[13:31] <dimitern> rogpeppe, what you proposed with making Repo a func doesn't work, because it's a type and it's exported
[13:31] <dimitern> rogpeppe, I have to refactor the whole thing
[13:32] <rogpeppe> dimitern: sorry, i meant Charms
[13:32] <rogpeppe> dimitern: but, i'm pretty sure there's a much less intrusive way
[13:32] <rogpeppe> dimitern: just checking
[13:33] <dimitern> rogpeppe, in every test that uses testing.Charms.xxx I have to go and change it so it reads testing.Charms().xxx
[13:34] <rogpeppe> dimitern: sure, but that's one trivial global change: gofmt -r -w 'testing.Charms -> testing.Charms()'
[13:34] <rogpeppe> dimitern: but, again, i think there's a better way
[13:34] <dimitern> rogpeppe, I'm listening
[13:34] <rogpeppe> dimitern: i'm still testing whether it's viable
[13:40] <rogpeppe> dimitern: something like this: http://paste.ubuntu.com/6843805/
[13:40] <rogpeppe> dimitern: those are the only changes necessary, i think
[13:41] <dimitern> rogpeppe, I'll try it
[13:41] <TheMue> rogpeppe: your last hint to me works fine and can be reviewed ;)
[13:41] <rogpeppe> TheMue: i'll have a look
[13:42] <TheMue> rogpeppe: thx. unit tests are still missing, have to think how to do it best
[13:43] <rogpeppe> TheMue: what's the backward compatibility issue you mention w.r.t. environtag/
[13:43] <rogpeppe> ?
[13:44] <rogpeppe> TheMue: oh, i see
[13:44] <rogpeppe> TheMue: why not just do that behaviour server side, i.e. no tags means everything?
[13:44] <TheMue> rogpeppe: ah, fine. yes, today the command doesn't need an argument. william wanted, that always a tag has to be passed
[13:44] <rogpeppe> TheMue: then you won't need any special casing for the environment tag at all
[13:45] <rogpeppe> TheMue: really?
[13:45] <TheMue> rogpeppe: but i have to add an error replay from server-side w/o a tag
[13:45] <rogpeppe> TheMue: seems odd to me
[13:45] <TheMue> rogpeppe: yes, really ;)
[13:45] <rogpeppe> TheMue: i don't understand the "error replay" thing
[13:45] <TheMue> rogpeppe: I could live with a default choosing the environment too, would make it simpler
[13:45] <TheMue> rogpeppe: eh, reply
[13:46] <rogpeppe> TheMue: yeah
[13:46] <TheMue> rogpeppe: if you initially call w/o entities or later set empty entities
[13:46] <rogpeppe> TheMue: it simplifies things
[13:46] <dimitern> rogpeppe, this works yes, tyvm
[13:46] <rogpeppe> dimitern: np
[13:46] <TheMue> rogpeppe: definitely, please add a comment regarding this point
[13:47] <rogpeppe> dimitern: sorry for the pushback, but the GOPATH thing sounded like creeping dependencies, fixing things far away from where the actual problem was
[13:47] <rogpeppe> TheMue: will do
[13:47] <dimitern> rogpeppe, yeah, I agree - sorry, but I was trying to land this for a day now and getting really frustrated
[13:47] <TheMue> rogpeppe: but filtering is really nice ;) tested it with one and multiple tags
[13:47] <rogpeppe> TheMue: cool
[13:48] <rogpeppe> dimitern: i know the feeling
[13:53] <jam> rogpeppe: we had a gecko show up inside, which my wife made quite clear that it had to go :)
[13:53] <rogpeppe> jam: lol
[13:54] <rogpeppe> jam: from a position firmly on top of a table?
[13:54] <jam> they're a bit harder to deal with than mice, as mice don't climb 2m up the wall
[13:54] <jam> rogpeppe: not quite so bad, but certainly back off a ways and quite vocal
[13:54] <mgz> geckos sound fun
[13:54] <rogpeppe> mgz: +1
[13:56] <jam> mgz: they're actually really quite cute (IMO) but I can understand not wanting to catch unexpected motion out of the corner of your eye. It can be a bit disturbing.
[13:57] <mgz> okay, lunch for me, hae proposed a much simplified https://codereview.appspot.com/56560043 along the lines you suggested jam (previous rev has the real cert stuff in)
[14:18] <mramm> so anybody got an update for me on the 1.17.2 world
[14:19] <mramm> as in, are we able to do a 1.17.2 release anytime soon (as measured in hours)
[14:19] <mramm> sinzui: ^^^?
[14:21] <marcoceppi> mgz: are you still going to be able to make it to cfgmgmt camp?
[14:22] <mgz> marcoceppi: yeah, I'll give you and rbasak my travel details
[14:22] <marcoceppi> mgz: cool, robbie will be at fossdem but not cfgmgmt camp, that'll just be us
[14:26] <mramm> arosales: you around?
[14:26] <sinzui> mramm, local provider is very broken in trunk. It is not releasable.
[14:26] <sinzui> mramm, but when we have a blessed revision, a release takes 4 hours
[14:27] <mramm> juju dev team, is there a way to get just 1.17.1 plus the MAAS bootstrap fix as a branch that we could release as 1.17.2?
[14:27] <mgz> sinzui: so, in the meeting this morning our antipodes were under the impression the only remaining broken things were misunderstandings/script things to fix
[14:27] <mgz> sinzui: from the mailing list thread, I'm not clear what's still borked
[14:29] <sinzui> mgz, maybe one thing needs to be fixed. local deploys of 1.17.1/2 have not worked since last Friday, so I have nothing to give me confidence that there is only one thing blocking the fix
[14:31] <sinzui> mgz, though We can see that changes to trunk are fixing things. Since yesterday, local deploy fails because wordpress fails to start: http://<IP_ADDRESS>:8080/job/local-deploy/
[14:32] <sinzui> We also see this in some of the failing azure tests
[14:34] <rogpeppe> TheMue: you have a review
[14:36] <mramm> mgz: sinzui: who do we need to get into a hangout to sort out these issues?
[14:36] <mgz> mramm: I think ideally the US/AUS overlap time
[14:37] <mramm> well, that is quite a bit from now...
[14:37] <mramm> but if that's where we need a meeting, we can do it
[14:37] <arosales> mramm, hello
[14:37] <mramm> but I'd like to have everything we can sorted out by then
[14:38] <mramm> arosales: saw your message regarding MAAS for the charmers -- I have one priority over that which is MAAS for CI
[14:38] <mramm> I think we can use the MAAS testing lab for that
[14:38] <mramm> james page and I were just talking about it
[14:38] <arosales> sinzui, are you available for the juju cross team?
[14:38] <mramm> is that now?
[14:38] <mramm> joining
[14:38] <mramm> sorry lost track of time here
[14:38] <sinzui> arosales, now? me in standup
[14:39] <arosales> sinzui, ah ok. I think the cross team meeting is an hour early than it was in 2013
[14:39] <arosales> mramm, ^
[14:39] <TheMue> rogpeppe: thank you
[14:40] <mramm> arosales: we can move it later
[14:40] <arosales> sinzui, and simple stream workflow is still in progress or waiting on utlemming
[14:50] <TheMue> rogpeppe: I like the idea with the regex, it is more powerful. will change it.
[14:50] <TheMue> rogpeppe: and also to no-filter-means-show-everything
[14:51] <rogpeppe> TheMue: thanks
[14:56] <sinzui> mgz, I consistently see a mysql error in local deploy http://<IP_ADDRESS>:8080/job/local-deploy/767/console
[14:57] <sinzui> mgz, We are not getting logs though...
[14:57] <sinzui> mgz, do I dare increase the memory constraints as we did for HP
[14:58]  * sinzui accidentally deployed juju on 512m this week and was surprised to see the tests pass...juju's memory requirements probably shrank
[14:59] <mgz> yeah, juju itself is generally good
[14:59] <hatch> I am trying to determine which version of juju-core actually removes the requirement for sudo on local deployments? 1.17.1 seems to require it but I'm hearing reports that 1.17.2 does not
[14:59] <mgz> mysql still does that "allocate 80% of machine's memory" thing though
[14:59] <mgz> which is probably not good if there's anything else on the box at all
[14:59] <sinzui> hatch, trusty + 1.17.2 (which I have not released
[15:00] <hatch> sinzui what about precise?
[15:00] <hatch> do you guys consider the 1.17.x release to be a non-stable release? Should quickstart use sudo up to 1.18 ?
[15:00] <sinzui> hatch, precise version will still ask for sudo on demand
[15:01] <hatch> even in 1.18?
[15:01] <sinzui> 1.18 will request sudo passwords on demand
[15:02] <hatch> ok so trusty with 1.17.2 or greater will not require sudo, everything else does
[15:02] <hatch> sinzui: sorry that was a question :)
[15:04] <sinzui> hatch, yes. In general, juju will will ask for input as needed. That means your scripts need to provide sudo passwords after they call bootstrap, or do a trivial sudo op before bootstrapping so that the op is not paused for a password
[15:06] <hatch> sinzui right, but we also don't want to run it as sudo when it's not required to so I was hoping for something we could programatically check for to see if sudo will be required
[15:07] <mgz> hatch: basically it depends on juju version and lxc version
[15:07] <sinzui> okay, hatch, I understand. "juju version" will return 1.XX.X. if the dotted numbers are greater than 1.17.1, don't use sudo
[15:07] <hatch> mgz, well, apparently also the ubuntu series
[15:08] <hatch> sinzui even on precise?
[15:08] <mgz> that's only an indication oflxc version
[15:08] <sinzui> hatch lxc version is implicit with series
[15:08] <sinzui> hatch, yes, even precise that I test
[15:08] <sinzui> This is was ran 10 minutes ago
[15:08] <sinzui> juju --show-log bootstrap -e local --constraints mem=2G
[15:09] <sinzui> on precise local
[15:09] <hatch> ok perfect, haha wow that was confusing for a bit :)
[15:09] <hatch> version > 1.17.1 ! require sudo :D
[15:10] <sinzui> bingo
[15:10] <hatch> ok on it!
[15:11] <hatch> sinzui will 1.17.x be released to the stable ppa or is it just a development version?
[15:12] <sinzui> hatch, odd numbers are always unstable and not subtle for production
[15:13] <sinzui> hatch, when we think the 17 changes are complete, we will call them 1.18.0
[15:13] <hatch> ahh ok gotcha
[15:13] <hatch> doing the node.js like version releases :)
[15:22] <frankban> sinzui: can we assume odd numbers are never published on the stable ppa or on main/universe?
[15:22] <sinzui> frankban, The answer should be yes and yes...
[15:22] <frankban> sinzui: cool thanks
[15:23] <sinzui> frankban, BUT
[15:25] <frankban> sinzui: I feel like there is a BUT
[15:27] <sinzui> frankban, I had no intention of letting odd numbers into the ubuntu devel (trusty), but jamespage wanted it in trusty to test gccgo
[15:28] <bac> rogpeppe: i'm getting a mongo error from juju 1.17.1 when trying to deploy a charm.  was wondering if you've seen it before.  https://pastebin.canonical.com/103823/plain/
[15:28] <bac> rogpeppe: on trusty with local provider
[15:28] <frankban> sinzui: so 1.17.1 is in trusty?
[15:28] <rogpeppe> bac: 1.17.1 is broken
[15:29] <rogpeppe> bac: i can't see your paste, but i know what it's gonna look like
[15:29] <bac> rogpeppe: good parts: E11000 duplicate key error index: juju.charms.$_id_ dup key:
[15:31] <frankban> sinzui: yes it is, thank you
[15:34] <mramm> frankban: yes it is in trusty
[15:35] <mramm> 1.17 is the last time we will push a dev release into trusty though
[15:36] <mramm> we need to get better at releasing stable versions on a regular schedule
[15:36] <mramm> that will eliminate the felt need to push devel releases into the release
[15:36] <rogpeppe> bac: ah, that's a different issue
[15:36] <mramm> but we needed to get that process running, due to the main inclusion process that we need to go through this cycle
[15:36] <rogpeppe> bac: dimitern knows about that, i believe
[15:37] <rogpeppe> bac: it's something to do with charm uploads - were you running deploy twice, or something?
[15:37] <rogpeppe> bac: (twice concurrently, i mean)
[15:38] <bac> rogpeppe: no.  tried one deploy from juju-gui and got the error
[15:38] <rogpeppe> bac: hmm.
[15:38] <dimitern> bac, I'm trying to land a fix for bug 1067979 since yesterday - hopefully not long now
[15:38] <_mup_> Bug #1067979: race: concurrent charm deployments corrupts deployments <deploy> <race-condition> <test-needed> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1067979>
[15:38] <rogpeppe> bac: can you reproduce?
[15:38] <bac> rogpeppe: yes, could yesterday via the gui.  was going to spin up an env by hand and see if i can reproduce
[15:39] <bac> rogpeppe: was just checking first to see if it was a known issue that could be waved off.  glad to help with reproducing if needed
[15:41] <rogpeppe> bac: once dimitern has landed his fix, perhaps you could try to see if you could reproduce the problem from trunk tip
[15:41] <bac> will do, rogpeppe
[16:39] <TheMue> rogpeppe1: take a look: http://paste.ubuntu.com/6844672/
[16:39] <TheMue> rogpeppe1: ;)
[16:53] <dimitern> bac, the fix for bug 1067979 landed, btw
[16:53] <_mup_> Bug #1067979: race: concurrent charm deployments corrupts deployments <deploy> <race-condition> <test-needed> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1067979>
[16:57] <natefinch-afk> rogpeppe1: When you get a chance, I'd like to talk about the machine agent stuff again.  The API code has me mystified as to where the info is that I'm supposed to be watching
[16:58] <rogpeppe1> natefinch-afk: ok, perhaps soon?
[16:59] <natefinch> rogpeppe1: sure thing
[16:59] <natefinch> rogpeppe1: just wasn't sure how late you'd be there today
[17:02] <dimitern> natefinch, a quick review? https://codereview.appspot.com/54680045
[17:04] <dimitern> rogpeppe1, fwereade, https://codereview.appspot.com/54680045 ?
[17:05]  * dimitern bbiab
[17:07] <rogpeppe1> natefinch: i'm here for another hour, but currently in a discussion
[17:07] <arosales> mgz, fwereade using the conf call today for the joyent provider sync
[17:10] <natefinch> rogpeppe1: ok, I know that takes precedence
[17:10] <natefinch> dimitern: I can review
[17:13] <mgz> I'll need to read the wiki about conf call things
[17:15] <mgz> arosales: I actually don't have a pin, if I need one, and getting one seems to involve an rt
[17:15] <dimitern> natefinch, thanks
[17:15] <arosales> mgz sent you the callin details and updated the invite
[17:40] <mgz> dstroppa: so, first thing to try with the amulet tests is adding sentries=False when constructing amulet.Deployment()
[17:41] <mgz> then just remove the d.sentry.wait() call below, it's not strictly needed
[17:42] <mgz> it gives you fewer hooks to actually inspect your charms and hooks, but can be changed back later when you need them
[17:43] <dstroppa> mgz: tried that, this is what I'm getting now http://paste.ubuntu.com/6844982/
[17:52] <mgz> dstroppa: much better
[17:54] <mgz> dstroppa: get lp:juju-deployer and put the script on your path
[17:55] <dimitern> natefinch, review poke?
[17:56] <natefinch> dimitern: yeah, sorry, had to do one thing in the meantime, but working on it now
[17:56] <dimitern> natefinch, cheers
[18:11] <dstroppa> mgz: I'm getting syntax errors when installing juju-deployer
[18:12] <rogpeppe1> natefinch: hangout?
[18:12] <natefinch> rogpeppe1: yeah, standup one?
[18:13] <rogpeppe1> natefinch: ok
[18:13] <rogpeppe1> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[18:14] <rogpeppe1> TheMue: cool
[18:16] <natefinch> rogpeppe1: you're frozen in the hangout?
[18:29] <dpb1> Hi, is this a bug?  I'm trying to do juju terminate-machine, and I'm in this weird state.  I think that this instance launched in an 'ERROR' state, fwiw:  http://paste.ubuntu.com/6845201/
[18:37] <fwereade> dpb1, you should be able to --force it
[18:39] <dpb1> fwereade: nice.  I suppose it will not clean up the instance in the "ERROR" state, though?
[18:40] <dpb1> --force appears to at least removed it from juju's brain, which is what I needed.
[18:43] <fwereade> dpb1, afraid not, it's just a way to get it out of juju's hair
[18:43] <dpb1> fwereade: k, thx
[18:44] <rogpeppe1> g'night all
[18:56] <natefinch> dimitern: reviewed, sorry for the delay
[19:08] <marcoceppi> got a question about api stuff?
[19:09] <marcoceppi> that was a astatement
[19:09] <natefinch> marcoceppi: I'll answer if I can
[19:11] <marcoceppi> natefinch: nvm, sorted as maas sadness
[19:12] <natefinch> marcoceppi: heh ok
[20:07]  * thumper has a few errands in town to prep for the trip
[20:07] <thumper> will be back soonish
[20:28] <bac> dimitern: you still around?
[21:21]  * thumper wants to stab something
[21:21] <thumper> ffs
[21:22] <thumper> natefinch: you around?
[21:22] <natefinch> thumper: yep
[21:22] <natefinch> thumper: please don't stab me
[21:22] <thumper> natefinch: have you tried the ec2 provider recently
[21:22] <thumper> mine won't start
[21:22] <natefinch> thumper: nope, I can try it
[21:22] <thumper> ERROR cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[21:22] <thumper> I'm trying to try out my all-machines fix for the local provider
[21:23] <thumper> and want to confirm it doesn't break others
[21:23] <thumper> hmm... seems to be working now
[21:23] <thumper> after failing twice
[21:24] <thumper> wonder if it was an amazon glitch
[21:24] <natefinch> thumper: yeah weird
[21:31] <thumper> natefinch: lbox still hates me (no go vet), can you review on LP? https://code.launchpad.net/~thumper/juju-core/all-machines-trusty/+merge/204106
[21:31]  * thumper also wants to get waigani to test it
[21:31] <thumper> as I know he is on saucy still and had a similar problem with no all-machines.log
[21:31] <thumper> I'm pretty sure this will fix it, but always good to get confirmation.
[21:33] <natefinch> thumper: at least it's a small change, so not so bad w/o side by side diffs
[21:33] <thumper> yeah
[21:34] <thumper> uh oh
[21:34]  * thumper has a bad feeling
[21:35] <thumper> poo
[21:35] <thumper> doesn't work on precise
[21:36]  * thumper hangs head
[21:37] <thumper> FARRRRKKK!!!!!
[21:38] <natefinch> thumper: my wife knows the guy that owns fark, actually.
[21:39]  * thumper resists the urge to have series specific rsyslog rendering
[21:44] <natefinch> thumper: still want a review on that code, or...
[21:44] <thumper> not just yet
[21:47] <thumper> stabby stabby stabby
[21:57] <thumper> natefinch: care to take a look now?
[21:57] <thumper> just confirming on ec2
[21:57] <thumper> works for local
[21:57]  * thumper looks for someone not on trusty
[21:59] <natefinch> thumper: looking
[22:03] <thumper> hoo fucking ray
[22:03] <thumper> seems to work on precise
[22:03] <natefinch> thumper: maybe other people more familiar with rsyslog and bash would understand it, but personally, I'd like a comment about why you have to set and reset FileCreateMode like you do.
[22:03] <thumper> natefinch: where do you want the comment?
[22:04] <thumper> I thought I had one?
[22:04] <thumper> ah, it is in the description of the merge
[22:04] <thumper> can put it in the code somewhere if you like
[22:05] <natefinch> Yeah, just the first time you do it.
[22:06] <thumper> I'll have it in the block comment for the template itself
[22:06] <thumper> I don't want it rendered in the actual config file
[22:08] <natefinch> right
[22:09] <natefinch> ok, time for me to go.  Have fun in cape town
[22:18] <hazmat> thumper, so i'm using latest trunk, and juju get-env doesn't show proxy config as an option.. how does one go about setting it?
[22:19] <thumper> probably because the default is to Omit it if not set
[22:19] <thumper> juju set-env http-proxy=http://foo
[22:19] <thumper> ya know
[22:20] <thumper> I'm tempted to change it from Omit to default to ""
[22:20] <hazmat> got it.. revno 2224
[22:20] <thumper> what do you think?
[22:20] <thumper> because if you have one set, you can't unset it
[22:20] <thumper> as it won't allow ""
[22:20] <thumper> stupid juju
[22:20] <hazmat> hmm.
[22:20] <hazmat> thumper, a doc merge proposal would do :-)
[22:20] <hazmat> its pretty hard to discover otherwise
[22:20] <thumper> oh for sure
[22:21] <thumper> I want it feature complete before we bang on about it though :)
[22:21] <hazmat> the diff on revno 2224 shows all the options. i needed to find.
[22:21] <hazmat> thumper, i'll have users testing it tonight :-)
[22:21] <thumper> cool
[22:21] <thumper> let me know if there are problems or surprises
[22:21] <thumper> I probably won't see the email until I'm in cape town
[22:21] <thumper> but I will see it
[22:21] <hazmat> thumper, will do.. careful what you wish for :-)
[22:22] <thumper> you going to be there?
[22:22] <hazmat> thumper, yup.. i should be in saturday late
[22:22]  * thumper nods
[22:22] <thumper> I get in 9am ish sunday morning
[22:22]  * thumper has been futzing around with rsyslog configs
[22:23] <hazmat> there's some other fire i'm parachuting in to work on.. which will take up most of the freetime during the sprint week, but this project with proxies will probably still keep kicking and screaming.
[22:28] <sinzui> thumper, lxc is looking better today, upgrade tests work. deploys always fail because of a wordpress agent error. DO you have any ideas about r2282 that would break the agent
[22:29]  * thumper looks at that revno
[22:29] <sinzui> trusting on aws is broken too, but I think that is aws since canonistack's trusty passed
[22:30] <thumper> sinzui: I just used aws with trusty and trunk ok
[22:30] <thumper> I hit a glitch with s3 when I first tried
[22:30] <thumper> but that resolved itself
[22:30] <sinzui> thumper, lucky you. I have many tests and 4 personal runs that cannot bootstrap
[22:30] <thumper> sinzui: no idea
[22:30] <thumper> sinzui: try now
[22:30] <thumper> it was working for me
[22:31] <thumper> sinzui: we should get a real test that looks for the all-machines.log for the local provider
[22:31] <thumper> I have just fixed the bug and merge should be working through tarmc
[22:31] <sinzui> thumper, I add recovery of that log today for lxc
[22:31] <thumper> lxc or local?
[22:32] <thumper> we have containers in other providers remember :)
[22:32] <sinzui> thumper, lxc. since we had no logs and lots of failures, I wrote a hack to find the log in local/log before the machine is torn down.
[22:32] <thumper> I have a horrible feeling that I am missing something important that I should be doing today to prepare for the trip tomorrow
[22:32] <sinzui> http://<IP_ADDRESS>:8080/job/local-deploy/780/ is the last failure
[22:33] <thumper> sinzui: oh, you'll love my last change then
[22:33] <sinzui> thumper, CI scp's the log from the bootstrapped machine, but it has never been able to do that with lxc
[22:33] <thumper> I keep the log file around until you re-bootstrap
[22:33] <thumper> will be in /var/log/juju-<user>-<envname>/all-machines.log
[22:34] <sinzui> thumper, thank you
[22:35] <sinzui> thumper, aws trusty still dies on apt-get upgrade
[22:35] <thumper> hmm
[22:35] <thumper> are you deploying to trusty?
[22:35] <thumper> I'm not doing that
[22:35] <sinzui> thumper, I am just boostrapping on trusty and failing.
[22:36] <sinzui> it worked for CI yesterday
[22:36] <thumper> hmm...
[22:36] <thumper> sorry, but worked for me just an hour ago
[22:36] <sinzui> thumper, I think it is aws.
[22:37] <thumper> waigani_: can I get you to pull trunk, and try a local provider?
[22:37] <thumper> waigani_: see if you get all-machines.log now
[22:37] <thumper> I expect that you should
[22:37] <waigani_> okay
[22:37] <sinzui> the unittests failed when they removed the ami we were using, so I expect to tweak the tests to keep them current with trusty in aws
[22:56] <bigjools> morning wallyworld_ how's the head? :)
[22:56] <wallyworld_> fine
[22:56] <wallyworld_> jeez
[23:12] <sinzui> wallyworld_, I am seeing azure header issues.
[23:12] <wallyworld_> oh
[23:12] <sinzui> wallyworld_, I just started a manual test of stable to reassure myself
[23:13] <wallyworld_> you are seeing issues running trunk?
[23:13] <sinzui> wallyworld_, we are see this with recent revs: http://<IP_ADDRESS>:8080/job/azure-deploy/758/console
[23:17] <sinzui> looking good for the manual bootstrap
[23:17] <wallyworld_> sinzui: i can't think of anything that has changed in juju wrt that error
[23:17] <sinzui> I fear that azure has changed.
[23:18] <wallyworld_> oh joy
[23:18] <sinzui> We find the machines are often left running or stopped in azure after a test.
[23:18] <wallyworld_> in azure but not ec2 or other clouds?
[23:20] <sinzui> wallyworld_, azure and canonistack are leaving machines behind. but in the case of azure, I am seeing the header errors and a lot of 307 temporary redirect errors that state the delete failed
[23:22] <wallyworld_> hmmmm. off hand, i can't offer any useful insight
[23:22] <sinzui> wallyworld_, good news. 1.16.5 on azure is good. I will try to collate the trunk errors into something meaningful
[23:23] <wallyworld_> good or worked when run but might be flakey next time?
[23:25] <wallyworld_> trunk could well be to blame. there have been no azure specific changes to my knowledge but destroy for example has changed and maybe that is indirectly causing issues on azure


[01:20] <asac_the_2nd> ok i am out for today ... good night!
[10:26] <asac> damn ... getting up at 7 to visit public offices isn't fun if you went to bed at 3am :)
[11:01] <bluekuja> asac: :)
[11:01] <asac> hey
[11:02] <bluekuja> how is life going around here?
[11:02] <asac> did the police take your drivers license :)
[11:02] <asac> ?
[11:02] <bluekuja> lol
[11:02] <asac> for me things are fine.
[11:03] <bluekuja> I was lucky they didnt find me
[11:03] <bluekuja> :P
[11:03] <bluekuja> anyway everything went fine
[11:04] <bluekuja> asac: did you see this mail:
[11:04] <bluekuja> https://lists.ubuntu.com/archives/motu-council/2007-August/000314.html
[11:04] <bluekuja> this make me crazy
[11:05] <bluekuja> asac: usually ppl on august leave for vacation
[11:05] <bluekuja> so does not do any activity
[11:05] <bluekuja> but maybe it's not clear for everyone
[11:06] <asac> well ... he cannot know
[11:06] <bluekuja> so he shouldnt talk
[11:06] <asac> we usually don't do much holiday
[11:06] <bluekuja> yeah, because you're one of the project managers
[11:07] <bluekuja> and you follows mozilla directly
[11:07] <asac> i don't see anything offending in it
[11:07] <asac> really
[11:07] <asac> its just that so many people vanish and just stop
[11:07] <asac> that its a valid question to ask
[11:07] <bluekuja> in my opinion he loves to talk too much
[11:08] <bluekuja> I never put any word in others stuff
[11:08] <asac> keybuk is a reasonable person ... everybody has his weaknes though
[11:08] <bluekuja> I speak only for me and for open discussions
[11:08] <bluekuja> asac: he was scottk
[11:08] <asac> ah
[11:08] <asac> ok
[11:08] <asac> sorry misread
[11:09] <bluekuja> asac: he did it already with:
[11:09] <asac> well just answer and get over it ... its a public mailing list so nobody can really stop others from posting things
[11:10] <bluekuja> https://lists.ubuntu.com/archives/motu-council/2007-July/000240.html
[11:10] <bluekuja> and
[11:10] <bluekuja> https://lists.ubuntu.com/archives/motu-council/2007-July/000244.html
[11:10] <asac> yeah ... but he has no word ... some people just want to be over-critical
[11:11] <bluekuja> yeah, but you know how I'm done
[11:11] <bluekuja> I get crazy when I see stuff like that
[11:11] <asac> you cannot prevent technical hybris people to be in a project
[11:11] <bluekuja> true thing
[11:11] <asac> think about this as a challenge ... you really have to learn how real life is
[11:11] <bluekuja> ye, nice hint
[11:12] <bluekuja> I hope this will end up in a good way
[11:12] <bluekuja> too many noise
[11:12] <asac> there are always people that are assholes or want to piss at you ... the average in ubuntu is on top of the world though
[11:12] <asac> yes ... i cannot tell why this noise happened ... i think its because you peered with a lot of people in the past
[11:13] <bluekuja> yea
[11:13] <bluekuja> only because a +0.5
[11:13] <asac> and if peer with lots of people chances are high that you bump into someone who has an attitude that isn't really what you want
[11:14] <asac> yeah ... which wasn't good as well ...  i mean ... i think matt (or someone) asked to give clear + 1 or -1 ... and then he answered well "i give 0.5"
[11:14] <bluekuja> yea
[11:14] <asac> a bit childish ... either he should stand up to his opinion and give a -1
[11:14] <asac> or a +1
[11:14] <bluekuja> in fact
[11:14] <bluekuja> he had no motivation for a -1
[11:14] <bluekuja> he asked me in pm
[11:15] <asac> maybe he hat ... but didn't have the guts to publicly state his opinion
[11:15] <bluekuja> to have lionel's mail
[11:15] <asac> s/hat/had/
[11:15] <bluekuja> with his response, lionel sent a +1
[11:15] <bluekuja> so he had no more chance
[11:15] <bluekuja> but he gave a +0.5 after 1 month of inactivity
[11:17] <bluekuja> I don't more mind about this really
[11:18] <asac> i would just answer to that mail with "i was on vacation" ... and get back to normal life
[11:19] <bluekuja> a friend sent a mail already
[11:19] <bluekuja> :)
[11:19] <bluekuja> when I was away
[11:20] <asac> then its already clarified ... no need to put time into answering his email
[11:20] <asac> just ignore it then
[11:20] <bluekuja> yea
[11:21] <bluekuja> asac: I will finish vacations on this sunday
[11:21] <bluekuja> then I restart school
[11:21] <bluekuja> and I will have really less time to be here
[11:21] <bluekuja> but I guess one hour per day
[11:22] <asac> thats good
[11:22] <bluekuja> yea, at least I can check/answer mails
[11:22] <bluekuja> fix bugs on my packages
[11:23] <bluekuja> and nothing more
[11:23] <asac> how is your new relationship going?
[11:24] <bluekuja> asac: is not going good with the new gf
[11:24] <bluekuja> ^^
[11:24] <bluekuja> lol
[11:24] <bluekuja> you had the same idea
[11:24] <bluekuja> and I posted a msg about it just before you
[11:24] <bluekuja> :D
[11:24] <asac> hmm ... i am sorry ... but you are young ... so plenty of time to find the right one
[11:24] <asac> hehe
[11:24] <asac> yeah funny
[11:25] <bluekuja> yeah
[11:25] <bluekuja> but I hope everything will return to its right placer
[11:25] <bluekuja> *place
[11:25] <asac> you will see ... there are times of dark ... and times that are bright
[11:26] <bluekuja> yeah true, you have tons of experience
[11:26] <asac> at some point you will wonder "why the hell is everything going so well"
[11:26] <bluekuja> lol
[11:26] <bluekuja> I hope it will happen
[11:27] <asac> bluekuja: school ... last year?
[11:28] <bluekuja> asac: should be last year
[11:28] <bluekuja> :/
[11:28] <bluekuja> got some problems this year
[11:28] <bluekuja> e.g I stopped to study
[11:29] <bluekuja> not really stopped
[11:29] <bluekuja> but I didnt want to spend hours on books
[11:29] <bluekuja> a great error
[11:30] <bluekuja> now I'm 18 and will have 2 more years of school
[11:30] <bluekuja> damn me
[11:32] <bluekuja> asac: you know, when you're young, you love to spend time with friends et all instead of books hehe :)
[11:34] <asac> yes i know
[11:35] <asac> i didn't do anything at home ... anyway i managed to be one of the best
[11:35] <asac> the trick is: use the time you are in school
[11:35] <asac> contribute to classes ...
[11:35] <bluekuja> yeah
[11:36] <bluekuja> that's important
[11:36] <asac> the time in school is wasted otherwise ... and chatting with friends during classes isn't really that great either
[11:36] <bluekuja> lol
[11:36] <bluekuja> chatting with friends is really common here
[11:36] <asac> better do a lot of things in school ... you won't need to do homework then
[11:37] <asac> bluekuja: its common everywhere
[11:37] <bluekuja> yup
[11:37] <asac> you can even do it ... but contribute to the classes ... listen ... try to find it interesting ... then learning is much easier
[11:38] <asac> its not easy ... but being able to find something interesting even though its boring is really a great advantage
[11:39] <asac> ok working on something ;)
[11:39] <bluekuja> asac: have fun :) I'm leaving for the sea
[11:39] <bluekuja> will be back on sunday
[11:40] <bluekuja> (sunday --> vacations end)
[11:40] <bluekuja> take care alex
[11:40] <bluekuja> ;)
[11:40] <gnomefreak> everything under code tag in your LP home page is borked (your == im sure everyone but atleast for me this happens)
[11:40] <bluekuja> gnomefreak, huh?
[11:41] <asac> bluekuja: yeah ... just one more thing about school: there is a way to be good in school but still be the coolest guy in your class
[11:41] <asac> :)
[11:41] <bluekuja> asac: :D
[11:41] <bluekuja> you're a pro man
[11:41] <bluekuja> :)
[11:41] <gnomefreak> bluekuja: go to your code tag in LP than click on one of the branches it will oops
[11:41] <asac> gnomefreak: they probably roll-out a new lp build
[11:42] <gnomefreak> asac: i just asked if it was known but yes that is most likely the cause
[11:42] <bluekuja> gnomefreak, yup
[11:42] <bluekuja> confirmed here
[11:43] <bluekuja> gnomefreak, is for build build 4759
[11:43] <bluekuja> out this night
[11:44] <bluekuja> 22-23 august
[11:44] <gnomefreak> huh?
[11:44] <bluekuja> with ppa support
[11:44] <bluekuja> et all
[11:44] <asac> bluekuja: where do you see that its out this night?
[11:44] <bluekuja> asac: was reading a friend's blog
[11:44] <bluekuja> who follows it
[11:44] <asac> url?
[11:44] <bluekuja> asac: is italian
[11:44] <bluekuja> :)
[11:44] <bluekuja> italian planet
[11:45] <bluekuja> http://planet.ubuntu-it.org/
[11:45] <bluekuja> first post
[11:45] <bluekuja> maybe rewell posted a mail
[11:46] <bluekuja> in launchpad beta testers
[11:46] <bluekuja> I forget to check mail
[11:46] <asac> gnomefreak: do you see personal package archives in mozillateam?
[11:46] <bluekuja> but I guess that's it
[11:46] <asac> gnomefreak: https://launchpad.net/~mozillateam
[11:46] <asac> i won't see it as i am not admin afaik
[11:47] <bluekuja> asac: who is dfarning?
[11:47] <gnomefreak> asac: yes its called active personal package archive
[11:47] <asac> bluekuja: dfarning became ubuntu-member and then just left and was never seen again
[11:47] <bluekuja> oh^^
[11:47] <asac> bluekuja: e.g. just to show you that things that scottk claims really happen
[11:48] <bluekuja> yeah
[11:48] <asac> gnomefreak: please set one up for us then
[11:48] <asac> cool ... on ~asac i can see it as well
[11:48] <asac> nice
[11:48] <bluekuja> asac: yeah
[11:49] <bluekuja> is for everyone
[11:49] <bluekuja> I tested it on beta
[11:49] <bluekuja> before
[11:49] <bluekuja> and it rocks
[11:49] <asac> yes ... i know ... wasn't sure if its all set up alrady
[11:49] <bluekuja> it builds packages for amd64 and i386
[11:49] <gnomefreak> hmmmmmmm
[11:50] <bluekuja> gnomefreak, ?
[11:50] <asac> i think the https://help.launchpad.net/PPAQuickStart is still outdated as it still refers to beta et al
[11:50] <gnomefreak> asac: what would sound good for an explaination for it
[11:51] <asac> mozillateam testing/preview and bleeding-edge packages :)
[11:51] <gnomefreak> k
[11:51] <bluekuja> asac: https://lists.ubuntu.com/archives/launchpad-users/2007-August/001998.html
[11:51] <asac> gnomefreak: we can change description later ;)
[11:52] <gnomefreak> https://launchpad.net/~mozillateam/+archive
[11:52] <asac> bluekuja: hmm so its still beta?
[11:52] <bluekuja> asac: yup
[11:52] <asac> gnomefreak: ok ... we just have to remember not to upload anything that we don't have a bzr branch
[11:52] <asac> because it might be wiped at some point
[11:53] <bluekuja> I think every team member
[11:53] <bluekuja> will be notified
[11:53] <bluekuja> with uploads
[11:53] <bluekuja> asac: you'll receive an ACCEPTED mail
[11:53] <asac> bluekuja: yeah ... lets see how it works out
[11:53] <bluekuja> as alwais
[11:53] <asac> gnomefreak: wanna try?
[11:53] <gnomefreak> yes i will
[11:53] <asac> push -trunk ?
[11:54] <bluekuja> :D
[11:54] <gnomefreak> asac: is it up to date
[11:54] <asac> Ubulette: is your branch in a decent state or shall we cherry-pick things to mozillateam branch and upload that to ppa ?
[11:54] <asac> Ubulette: trunk branch
[11:55] <asac> gnomefreak: let me see if Ubulette pushed something to mt branch
[11:55] <asac> yesterady
[11:55] <asac> oh code.lp.net is broken :)
[11:55] <gnomefreak> i cant see them
[11:55] <gnomefreak> asac: read above :)
[11:55] <asac> yeah... now i see the point ;)
[11:56] <asac>  gnomefreak: ok ... lets push something small to test
[11:56] <asac> https://code.launchpad.net/~fta/nspr/nspr.ubuntu.trunk
[11:57] <asac> gnomefreak: http://www.sofaraway.org/ubuntu/tarballs/ ... tarballs are there
[11:58] <gnomefreak> ok give me a few
[11:58] <asac> branching still works ... apparently only web-frontend is broken
[11:59] <bluekuja> asac: I think package removal is active now
[11:59] <bluekuja> e.g removing a package inside a ppa archive
[11:59] <asac> gnomefreak: maybe fix version ... append ~mt1 ... and target for gutsy for now
[11:59] <asac> bluekuja: yeah ... good to know ;)
[11:59] <bluekuja> yup
[11:59] <bluekuja> )
[11:59] <bluekuja> :)
[11:59] <asac> at least one can wipe broken things
[11:59] <gnomefreak> is this tarball set to use bzr-build?
[11:59] <bluekuja> yup
[11:59] <asac> yes
[11:59] <gnomefreak> damn
[12:00] <gnomefreak> k
[12:00] <bluekuja> :D
[12:00] <asac> just branch ... fix changelog (commit)
[12:00] <bluekuja> asac: how is weather there?
[12:00] <asac> 20 degree ... partly cloudy ... in short: semi-sucks
[12:00] <bluekuja> I went to cracow and bratislava some days ago
[12:00] <bluekuja> and was pretty good
[12:00] <bluekuja> here is bad
[12:01] <bluekuja> raining now
[12:01] <bluekuja> :/
[12:01] <asac> yeah ... cracow is poland nowadays
[12:01] <bluekuja> yup
[12:01] <asac> they are not that close to the see ... so they have dryer summer ... and colder winters
[12:01] <asac> s/see/sea/
[12:01] <bluekuja> I'll come to hamburg
[12:01] <bluekuja> so we can meet up
[12:01] <asac> bratislava is slovakai?
[12:01] <bluekuja> yup
[12:02] <asac> ok ... how is the city?
[12:02] <asac> worth visiting?
[12:02] <bluekuja> central part of the city is really nice (old castle et all), other parts sux (people have no money there)
[12:02] <asac> wanted to go to prague at some point ... but maybe thats already too mainstream and so i consider bratislava
[12:03] <asac> yeah ... just want to look at the old central city
[12:03] <bluekuja> that's nice
[12:03] <bluekuja> the
[12:03] <bluekuja> *then
[12:03] <bluekuja> :)
[12:03] <bluekuja> prague rocks too much
[12:03] <bluekuja> I went there 2 years ago
[12:03] <asac> well ... i think i will do both
[12:03] <asac> maybe one can stay longer in prague
[12:04] <asac> just have been there switching trains ...
[12:04] <bluekuja> asac: I was talking with a slovakian friend about money/month for works there
[12:04] <asac> yeah probably 500 EUR if you are lucky :)
[12:04] <bluekuja> 300 euroes
[12:04] <bluekuja> *euros
[12:04] <bluekuja> per month
[12:04] <asac> yes ... thats less
[12:05] <bluekuja> it's nothing
[12:05] <asac> however if you have 1k you can probably live pretty well there
[12:05] <asac> while you would die here
[12:05] <bluekuja> yup
[12:05] <bluekuja> anyway stay longer in prague
[12:05] <bluekuja> it's the best
[12:05] <asac> go to romania ... they have even less
[12:05] <bluekuja> yup
[12:05] <bluekuja> asac: girls there are the nicest ever
[12:06] <asac> right ;)
[12:06] <asac> though its dangerous that way :)
[12:06] <bluekuja> yup
[12:06] <gnomefreak> asac: Step 4: As there is no override system, you have to upload you package to the right/desired component. In debian/control, use this syntax Section: universe/devel.  does that mean i have to use universe/devel? or can i use anything
[12:06] <bluekuja> gnomefreak, use every section
[12:06] <bluekuja> you assume is good
[12:06] <bluekuja> e.g universe/sound
[12:06] <bluekuja> just use that syntax
[12:07] <asac> gnomefreak: no idea where nspr belongs to
[12:07] <gnomefreak> so it has to be universe?
[12:07] <asac> maybe look what apt-cache show shows you
[12:07] <asac> gnomefreak: probably
[12:07] <bluekuja> gnomefreak, yea
[12:07] <gnomefreak> asac: libs
[12:07] <asac> though unsure
[12:07] <gnomefreak> ok
[12:07] <bluekuja> it doesnt matter
[12:07] <asac> gnomefreak: you can try
[12:07] <asac> gnomefreak: but stick to universe for mozillateam packages
[12:07] <asac> i don't want to pretend that they are suppported ;)
[12:08] <asac> gnomefreak: what does howto say ... how to upload? dput ... dupload ?
[12:09] <bluekuja> asac: dput
[12:09] <bluekuja> or dupload
[12:09] <bluekuja> same
[12:09] <bluekuja> for ppa
[12:09] <gnomefreak> dput i think
[12:09] <asac> yes was just curious what is named in howto
[12:09] <bluekuja> got no name
[12:09] <bluekuja> they say "upload"
[12:09] <asac> ok
[12:09] <bluekuja> so you have to use your personal uploader
[12:09] <bluekuja> I guess
[12:09] <asac> right
[12:10] <asac> bluekuja: is upload through anonymous ftp ... or authenticated ssh/sftp ?
[12:11] <bluekuja> asac: mm
[12:11] <bluekuja> I really don't know
[12:11] <asac> bluekuja: how did you upload?
[12:11] <bluekuja> I added a new host on dput.cf
[12:11] <asac> (you told you tested on dogfood)
[12:11] <bluekuja> and pushed
[12:12] <asac> bluekuja: you still have the dput.cf entry?
[12:12] <bluekuja> yea
[12:12] <asac> i guess its anonymous ftp if you don't know though
[12:12] <bluekuja> [ppa]
[12:12] <bluekuja> fqdn = upload.dogfood.launchpad.net
[12:12] <bluekuja> incoming = ~bluekuja/ubuntu/
[12:12] <bluekuja> login = anonymous
[12:12] <bluekuja> anonymous
[12:12] <bluekuja> yea
[12:12] <bluekuja> :)
[12:13] <bluekuja> asac: I'm leaving
[12:13] <asac> gnomefreak: good thing is that you can push with distribution "dapper" -> it will be build for dapper ...
[12:13] <bluekuja> yup
[12:13] <asac> bluekuja: ok bye
[12:13] <asac> cu
[12:13] <bluekuja> asac: cu on sunday!
[12:13] <bluekuja> have fun with ppa
[12:13] <bluekuja> :)
[12:14] <asac> gnomefreak: you can take the above dput entry and adapt it
[12:14] <gnomefreak> asac: UNRELEASED; change that to?
[12:14] <asac> e.g. s/bluekuja/mozillateam/
[12:14] <asac> gnomefreak: thats the distribution i was talking about
[12:14] <asac> so if the package is ment for gutsy ... use gutsy
[12:14] <asac> feisty ... feisty
[12:14] <gnomefreak> k
[12:14] <asac> and so on
[12:14] <asac> lets build nspr for gutsy though
[12:15] <asac> gnomefreak: append ~mt1 to the version ubulette choose
[12:15] <asac> then commit changelog with: debian/changelog: upload of version XXXX to gutsy ppa
[12:16] <asac> however lets wait for Ubulette to tell us if its ok to push to mt branch
[12:16] <asac> but i think it its
[12:17] <asac> gnomefreak: is there a way so we can recover what was in the old archive?
[12:17] <gnomefreak> that entry is wrong
[12:17] <gnomefreak> asac: no
[12:17] <asac> e.g. all the dapper packages we did once?
[12:17] <asac> damn
[12:17] <asac> not a big problem because so far 1.5.0.x security maintenance appears to work out well
[12:18] <asac> gnomefreak: which entry is wrong?
[12:18] <asac> 12:12 < bluekuja> [ppa]
[12:18] <asac> 12:12 < bluekuja> fqdn = upload.dogfood.launchpad.net
[12:18] <asac> 12:12 < bluekuja> incoming = ~bluekuja/ubuntu/
[12:18] <asac> 12:12 < bluekuja> login = anonymous
[12:18] <asac> 12:12 < bluekuja> anonymous
[12:18] <asac> that one?
[12:18] <asac> ups
[12:18] <asac> its just
[12:18] <asac> 12:18 < asac> 12:12 < bluekuja> [ppa]
[12:18] <asac> 12:18 < asac> 12:12 < bluekuja> fqdn = upload.dogfood.launchpad.net
[12:18] <asac> 12:18 < asac> 12:12 < bluekuja> incoming = ~bluekuja/ubuntu/
[12:18] <asac> 12:18 < asac> 12:12 < bluekuja> login = anonymous
[12:18] <asac> gnomefreak: but i think the server is different now
[12:19] <gnomefreak> it is that is why i said the entry is wrong
[12:19] <gnomefreak> im looking for correct info
[12:19] <asac> ok fine
[12:22] <gnomefreak> ppa.launchpad.net is where you upload
[12:22] <asac_the_2nd> ok thanks
[12:22] <gnomefreak> atleas that is how i see it
[12:22] <asac_the_2nd> yeah ... just try
[12:23] <asac_the_2nd> you probably cannot do anything seriously wrong
[12:23] <asac_the_2nd> otherwise its a bug in ppa
[12:25] <gnomefreak> asac: do you have command for bzr bd to sign and just build source?
[12:25] <asac_the_2nd> yes
[12:25] <asac_the_2nd> bzr bd --merge --builder='debuild -S -sa'
[12:25] <asac_the_2nd> (personally i use dpkg-buildpackage -rfakeroot -S -sa'
[12:26] <asac_the_2nd> )
[12:26] <asac_the_2nd> but debuild should be better
[12:26] <asac_the_2nd> gnomefreak: if its not you in changelog you have to provide -k as well
[12:26] <asac_the_2nd> bzr bd --merge --builder='debuild -S -sa -kgnomefreak'
[12:27] <gnomefreak> bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -S -sa -k3C1C3C2A' .
[12:27] <asac_the_2nd> this bcm43xx wifi chip is stable as well ... the stress test is still running ... 6GB traffic through WPA2 ... just using network-manager
[12:28] <asac_the_2nd> gnomefreak: looks good
[12:28] <asac_the_2nd> gnomefreak: you can provide your email as well instead of your keyid
[12:28] <gnomefreak> we shall see brb need more tea
[12:28] <asac_the_2nd> basically if it shows up with
[12:28] <asac_the_2nd> gpg --list-keys gnomefreak
[12:28] <gnomefreak> oh wtf
[12:28] <asac_the_2nd> then you can just use gnomefreak
[12:28] <asac_the_2nd> i can just use -kasac@d
[12:28] <asac_the_2nd> or -k<EMAIL_ADDRESS>[12:29] <asac_the_2nd> as long as list-keys has a distinct match with what you provide as -k ... it should work
[12:29] <gnomefreak> it doesnt matter its already failed
[12:30] <asac_the_2nd> like?
[12:30] <gnomefreak> http://pastebin.mozilla.org/188439
[12:30] <gnomefreak> looks like tarball
[12:30] <gnomefreak> but i could be off
[12:31] <asac_the_2nd> yes ... be sure the tarball is in tarballs
[12:31] <asac_the_2nd> next to your branch
[12:31] <asac_the_2nd> did you download it?
[12:31] <asac_the_2nd> Looking for ../tarballs/nspr-trunk_4.7.0~cvs20070713.orig.tar.gz
[12:31] <asac_the_2nd> that should exist
[12:32] <asac_the_2nd> http://www.sofaraway.org/ubuntu/tarballs/
[12:32] <gnomefreak> oh i think i forgot the s on tarballs
[12:32] <asac_the_2nd> hehe
[12:33] <gnomefreak> nope
[12:33] <asac_the_2nd> well the tiny details that bite us day in day out
[12:33] <gnomefreak> thats fine
[12:33] <asac_the_2nd> if you are in branch
[12:33] <asac_the_2nd> does
[12:33] <asac_the_2nd> ls ../tarballs/nspr-trunk_4.7.0~cvs20070713.orig.tar.gz
[12:33] <asac_the_2nd> show up the tarball?
[12:34] <gnomefreak> i know i put it in there
[12:35] <gnomefreak> gnomefreak@GutsyGibbon:~/nspr/tarballs$ ls
[12:35] <gnomefreak> nspr-trunk_4.7.0~cvs20070713.orig.tar.gz
[12:35] <asac_the_2nd> what is nspr?
[12:35] <asac_the_2nd> just a dir ... or the branch?
[12:35] <gnomefreak> just a fir
[12:35] <gnomefreak> dir
[12:35] <gnomefreak> so im not building it in my home dir
[12:35] <asac_the_2nd> well .. try the ls in the branch
[12:35] <gnomefreak> ls in the branch?
[12:36] <asac_the_2nd> you cd in the branch
[12:36] <asac_the_2nd> then try ls as above
[12:36] <asac_the_2nd> (12:33:23 PM) asac_the_2nd: ls ../tarballs/nspr-trunk_4.7.0~cvs20070713.orig.tar.gz
[12:36] <gnomefreak> gnomefreak@GutsyGibbon:~/nspr/work/nspr.ubuntu.trunk$ ../tarballs/nspr-trunk_4.7.0~cvs20070713.orig.tar.gz
[12:36] <gnomefreak> bash: ../tarballs/nspr-trunk_4.7.0~cvs20070713.orig.tar.gz: No such file or directory
[12:36] <asac_the_2nd> yes
[12:36] <asac_the_2nd> you are too deep
[12:36] <asac_the_2nd> do you see that?
[12:36] <asac_the_2nd> work?
[12:36] <asac_the_2nd> you need the branch next to the tarballs dir
[12:36] <gnomefreak> ah ok
[12:36] <asac_the_2nd> ;)
[12:37] <jeromeg> hello
[12:37] <asac_the_2nd> hi
[12:38] <asac_the_2nd> jeromeg: how did it work out?
[12:38] <jeromeg> asac_the_2nd: i builded the package without the patch
[12:38] <asac_the_2nd> you just left without letting us know
[12:38] <gnomefreak> i put tarballs outside of work and it should go inside it
[12:38] <jeromeg> asac_the_2nd: yep I was borred cause I had forgot to debuild -S -sa ...
[12:38] <asac_the_2nd> gnomefreak: i have all my branches in ~/ubuntu_bzr/
[12:38] <jeromeg> asac_the_2nd: but the bug is still here without the patch
[12:39] <asac_the_2nd> and a tarballs like ~/ubuntu_bzr/tarballs/
[12:39] <asac_the_2nd> gnomefreak: so either move your branch one level up ... or move tarballs one level down (inside worK)
[12:39] <asac_the_2nd> jeromeg: strange
[12:39] <gnomefreak> i did already let me work on this other error now
[12:39] <asac_the_2nd> jeromeg: you still have the build-tree ?
[12:40] <jeromeg> asac_the_2nd: yep
[12:40] <asac_the_2nd> please go to build-tree/mozilla
[12:40] <asac_the_2nd> and post output of: quilt applied
[12:41] <jeromeg> in fact I don't know exactly what you mean by build-tree
[12:41] <jeromeg> I build with pbuilde
[12:41] <jeromeg> rr
[12:41] <asac_the_2nd> well is your pbuilder chroot wiped now?
[12:42] <asac_the_2nd> then you cannot look ... build tree is the source tree after the build has finished
[12:42] <jeromeg> I think it's automatically cleaned after each build
[12:42] <jeromeg> to keep it clean
[12:42] <asac_the_2nd> yes ... then we cannot look ;)
[12:42] <asac_the_2nd> for testing you should pass the option to not delete it after build
[12:42] <jeromeg> I've just commented the patch in debian/patches/series
[12:42] <asac_the_2nd> or don't buld in pbuilder at all
[12:42] <jeromeg> debuild -S -sa
[12:43] <jeromeg> and build
[12:43] <jeromeg> and test
[12:43] <asac_the_2nd> yes ... but i want to double check ... as the patch is almost certainly the problem
[12:43] <jeromeg> asac_the_2nd: I can give you the .deb or .dsc ?
[12:43] <asac_the_2nd> jeromeg ... the diff.gz
[12:44] <jeromeg> asac_the_2nd: ok I'll put everything on line
[12:44] <asac_the_2nd> jeromeg: i just need the diff.gz and the dsc+changes
[12:45] <asac_the_2nd> jeromeg: i think we forgot to drop bz343360-feed-flat-chrome-fix.patch
[12:46] <jeromeg> asac_the_2nd: http://vv.guelf.free.fr/ubuntu/firefox/
[12:46] <asac_the_2nd> sorry for that
[12:46] <asac_the_2nd> i was confused by my own confusing patch naming
[12:46] <jeromeg> I think I dropped this one
[12:46] <jeromeg> going to check
[12:47] <asac_the_2nd> +flat-chrome-fix.patch
[12:47] <asac_the_2nd> then thats the missing?
[12:48] <jeromeg> ok I should have dropped the two patches ?
[12:48] <asac_the_2nd> no idea ... i am testing now
[12:49] <jeromeg> I can do it if you want
[12:49] <jeromeg> I have some time
[12:50] <asac_the_2nd> yes maybe try to drop that as well
[12:50] <jeromeg> ok
[12:50] <jeromeg> i'm on it
[12:50] <asac_the_2nd> at best keep your pbuilder so you can later test more easily
[12:50] <asac_the_2nd> e.g. without a rebuild
[12:50] <jeromeg> ok
[12:51] <asac_the_2nd> jeromeg: while you build
[12:52] <asac_the_2nd> please clean error console in firefox (Tools -> Error Console)
[12:52] <asac_the_2nd> then reproduce the bug
[12:52] <asac_the_2nd> and see what shows up there
[12:52] <asac_the_2nd> please post it
[12:52] <jeromeg> here or to the bug report ?
[12:52] <asac_the_2nd> for now here
[12:53] <asac_the_2nd> jeromeg: in the error there should be a link to the source line that failed
[12:53] <asac_the_2nd> when you click on it you should get there
[12:53] <asac_the_2nd> maybe post that as well (e.g. -5 + 5 lines
[12:53] <jeromeg> ok
[12:53] <asac_the_2nd> but please to pastebin :)
[12:55] <jeromeg> yep
[01:00] <jeromeg> asac_the_2nd: I was thinking, after that do you want me to test with only the second patch dropped ?
[01:01] <asac_the_2nd> no ... both
[01:02] <gnomefreak> asac_the_2nd: how will dput decide to upload to PPA instead of revu. ~/.dput.cf isnt used for revu but ther eis a dput config that has revu as default
[01:02] <asac_the_2nd> actually i hope that the first patch can be applied in the end ... but to track down we can drop both
[01:02] <asac_the_2nd> dput NAME file.changes
[01:02] <asac_the_2nd> e.g. NAME == ppa
[01:02] <asac_the_2nd> or whatever you put i []  brackets in dput.cf
[01:04] <gnomefreak> Uploading to ubuntu (via ftp to upload.ubuntu.com):
[01:05] <gnomefreak> but i dont understand why it didnt default to revu since the main dput config file has revu as default
[01:06] <gnomefreak> well it says it was uploaded
[01:07] <gnomefreak> waiting for LP page to update with this info to see if it is correct
[01:07] <gnomefreak> thought it should have used ppa.launchpad.net instead of uload.ubuntu.com
[01:09] <asac_the_2nd> yeah
[01:10] <asac_the_2nd> shouldn't do any harm ... as your key is not in the MOTU/main keyring yet
[01:19] <jeromeg> asac_the_2nd: http://pastebin.com/m4f5568a9
[01:22] <asac_the_2nd> yes its still the same
[01:22] <asac_the_2nd> maybe dropping the other patch fixes it
[01:22] <asac_the_2nd> otherwise i would have to look more closeyly ... .e.g where is the shorthand 'Cc' defined?
[01:23] <asac_the_2nd> why isn't it defined for us
[01:25] <jeromeg> ok
[01:26] <jeromeg> can I do anything else ?
[01:26] <asac> wait till the build finishes for now
[01:26] <asac> if the build tree is still there we can take a closer look
[01:30] <jeromeg> ok
[01:38] <gnomefreak> i hate dput now
[01:39] <gnomefreak> asac: it seems with ppa.launch[ad.net when using dput it uploads it to ubuntu archive
[01:39] <gnomefreak> i asked in #launchpad waiting for answer on why
[01:41] <asac> wierd
[01:42] <gnomefreak> changing the ppa.lp.net to dogfood it tells me its already been uploaded
[01:42] <gnomefreak> * "upload.dogfood.launchpad.net" becomes "ppa.launchpad.net".
[01:43] <asac> gnomefreak: hey its hot ... its beta ... dont be pissed. Lets be happy that ppa will work soonish :) ... i am out for lunch though :) ... catching the a bit sun available atm.
[01:43] <gnomefreak> so i assumed it was correct
[01:43] <gnomefreak> asac: have fun
[01:43] <asac> gnomefreak: thanks let me know what #launchpad answers
[01:43] <asac> maybe its correct?
[01:43] <gnomefreak> dont know what i pasted was from lp list though
[01:48] <gnomefreak> asac: seems to be a bug
[02:13] <gnomefreak> asac: ok looks like its uploaded but LP hasnt refreshed the team ppa page nor the build page
[02:14] <gnomefreak> oh and once PPA is stable it will drop all packages that are uploaded atm
[02:14] <gnomefreak> i also have a personal PPA ;)
[02:17] <asac> yah
[02:22] <gnomefreak> ill be back a bit later have some things to attend to
[02:25] <jeromeg> asac : bad news, still doesn't work with the two patches dropped
[02:28] <asac> crazy
[02:29] <jeromeg> maybe the patch has to be modified ?
[02:31] <jeromeg> the packages/dsc/diff/changes are at the same adress
[02:36] <asac> jeromeg: no ... its completely open to me why this happens then
[02:37] <asac> please try something
[02:37] <asac> let me look it up first though
[02:38] <asac> jeromeg: where was your error paste?
[02:38] <asac> nm ... found it
[02:39] <asac> jeromeg: can you please open error console ... clear (so you see what happens)
[02:39] <asac> and then in the textbox put:
[02:39] <asac> Components.classes["@mozilla.org/browser/shell-service;1"] .getService(Components.interfaces.nsIShellService_MOZILLA_1_8_BRANCH)
[02:39] <asac> and hit return ... or press evaluate
[02:39] <asac> what happens?
[02:40] <asac> jeromeg: is it still the same error at all now?
[02:41] <jeromeg> I'm having a look
[02:42] <jeromeg> asac : same error message
[02:44] <asac> ok try above
[02:45] <jeromeg> an error message results
[02:45] <asac> you should get  [xpconnect wrapped nsIShell...]
[02:45] <asac> as output
[02:45] <jeromeg> but it won't let me copy it
[02:45] <asac> are you sure you didn't miss a thing?
[02:46] <asac> e.g. a typo or something?
[02:46] <asac> let me try
[02:46] <jeromeg> doesn't seem to be a typo
[02:47] <asac_the_2nd> yes
[02:47] <asac_the_2nd> i see it as well
[02:47] <jeromeg> the error message ?
[02:48] <asac_the_2nd> yes ... that the shell service component doesn't exist somehow
[02:48] <jeromeg> it could explain the bug ?
[02:48] <asac_the_2nd> for sure
[02:49] <jeromeg> do you want me to do something else ,
[02:49] <jeromeg> ?
[02:50] <asac_the_2nd> no ... just post to the bug that the @mozilla.org/browser/shell-service;1 apparently is not resolvable and copy the statement above ... say that it fails
[02:51] <jeromeg> ok
[02:51] <jeromeg> and I add the first error message or no ?
[02:53] <asac_the_2nd> yes thats good as well
[02:54] <asac_the_2nd> jeromeg: when i get an idea whatelse it might be i will let you know
[02:55] <jeromeg> asac_the_2nd: ok thx for your help
[02:59] <jeromeg> asac_the_2nd: is that ok : bug 131743 ?
[02:59] <ubotu> Launchpad bug 131743 in liferea "liferea-add-feed does nothing in firefox" [Low,Invalid]  https://launchpad.net/bugs/131743
[03:06] <asac> jeromeg: "Thank you for your bug report. I can reproduce this, I'm marking this as triaged."
[03:06] <asac> --> triaged would mean that we already have an evaluation on how to fix the problem
[03:06] <asac> :)
[03:07] <jeromeg> asac : this was for the liferea bug
[03:07] <asac> interesting the triaged state was dropped
[03:08] <asac> stupid me ... got confused by new interface
[03:08] <jeromeg> asac : then I put liferea to Invalid as it was a problem with firefox, and added a firefox bug task
[03:08] <asac> right
[03:08] <jeromeg> asac : ah ok :)
[03:08] <asac> but liferea isn't invalid :)
[03:08] <asac> atm
[03:08] <asac> there is a second target (on top)
[03:08] <asac> fixed
[03:09] <asac> jeromeg: fix the upstream bug as well
[03:09] <asac> aeh invalidate i mean ;)
[03:09] <jeromeg> asac : yeah ok, as it had been invalidated upstream I thought it would be automatic
[03:09] <asac> ah
[03:09] <asac> no idea
[03:09] <asac> :)
[03:10] <asac> i did it explicitly now
[03:10] <asac> sorry for confusion ;)
[03:10] <jeromeg> no problem
[03:10] <jeromeg> I got to go now
[03:10] <jeromeg> see you
[03:10] <asac> cu
[03:10] <asac> stay tuned
[03:10] <asac> jeromeg: ^^
[03:10] <jeromeg> ok
[03:10] <asac> bye
[03:11] <jeromeg> byze
[03:11] <jeromeg> *bye
[03:12] <asac> gnomefreak: ppa still broken?
[03:12] <asac> i guess we have to wait until ppa dev returns
[03:12] <gnomefreak> asac: not sure i got reject email so im trying to fix it atm
[03:12] <asac> gnomefreak: what does reject tell you?
[03:12] <gnomefreak> asac: we are talking about it in #launchpad
[03:12] <asac> k
[03:13] <gnomefreak> asac: tells me cant find mozillateam in Lp but i think i have a clue
[03:13] <asac> i am not in there ... and i better keep it that way ... I already get soaked in too much discussions
[03:13] <asac> gnomefreak: clue ... good news ;)
[03:14] <gnomefreak> i will let you know if i fix it
[03:15] <asac> thanks ... i will not look in the channel for an hour or so ;) ... i have to get something done
[03:19] <gnomefreak> thats fine it may be a while before i know if it works anyway
[03:40] <gnomefreak> ok think i figured it out with a bit of help uploaded once again lets see how it goes :)
[03:52] <gnomefreak> asac: https://dogfood.launchpad.net/~mozillateam/+archive
[03:52] <gnomefreak> they are building binaries atm use view build records to see them
[03:58] <asac> gnomefreak: rock ... do the same for nss :)
[03:59] <gnomefreak> k but you know next week we will have to redo everything
[04:01] <gnomefreak> ok i need links for nss not for tar but for the bzr files
[04:01] <asac> look at ~fta code.lp.net
[04:01] <asac> there is nss-trunk
[04:02] <asac> gnomefreak: ok forgot that it is so soon
[04:02] <asac> @schedule berlin
[04:03] <ubotu> Schedule for Europe/Berlin: 23 Aug 17:00: Ubuntu Development Team | 24 Aug 14:00: MOTU Team | 27 Aug 17:00: Screencast Team | 28 Aug 17:00: Ubuntu Server Team meeting | 28 Aug 21:00: Technical Board | 29 Aug 22:00: Edubuntu
[06:27] <shirish> hey guys, what's up?
[06:48] <shirish> Ubulette: you up m8?
[07:42] <gnomefreak> asac_the_2n1: nss and nspr are complete what else did you want up therE?
[07:42] <asac> gnomefreak: well for now ... just those ... and maybe try a thunderbird 2.0 backport for feisty
[07:42] <asac> :)
[07:43] <gnomefreak> asac: one problem with that
[07:43] <asac> i am not sure if we had standalone nss/nspr in our preview archive though
[07:43] <gnomefreak> can we mix feisty and gutsy for same repo?
[07:43] <gnomefreak> we did
[07:44] <gnomefreak> if not we need to make another team for feisty
[07:52] <gnomefreak> i cant keep a frigging connection :(
[07:54] <gnomefreak> although what we could do is use my personal PPA for feisty, i can try to build the new nss nspr that we just did for gutsy on feisty(if possible) than build tbird2 off that unless you have better idea
[08:07] <asac> gnomefreak: no we can
[08:07] <asac> its not mixing
[08:07] <asac> the apt archive can deal with multiple distributions
[08:07] <asac> (at least from what i know)
[08:10] <gnomefreak> if all else fails ask :)
[08:11] <gnomefreak> ill let you know the outcome
[08:14] <Ubulette_> hmm, was i talking alone ?
[08:16] <gnomefreak> i didnt see you talking
[08:21] <gnomefreak> asac: ok tbird2 for feisty built on what version of nss nspr?
 hi
 oh, you experimented ppa
 great
 and with nss/nspr :)
 there's a flaw though...
 i need to rename both source pkgs as src endup in universe, and debs in main
[08:21] <Ubulette_> * Disconnected (Connection timed out).
[08:22] <Ubulette_> too bad ppa are limited to i386 and amd64 :(
[08:22] <gnomefreak> the names would need to be changed if officially released but not as of now
[08:22] <Ubulette> look at the ppa, it's already messed up
[08:23] <gnomefreak> Ubulette: it will be more important for next week since the uploads to PPA will be gone when PPA is released
[08:23] <gnomefreak> Ubulette: im looking at it what is wrong with it?
[08:24] <Ubulette> https://dogfood.launchpad.net/~mozillateam/+archive
[08:24] <gnomefreak> hmmmmm
[08:24] <gnomefreak> why did debs end up in main
[08:24] <Ubulette> there's main and universe
[08:25] <Ubulette> i guess it's because of the name
[08:25] <gnomefreak> i doubt it
[08:25] <gnomefreak> how would name do it
[08:26] <gnomefreak> i see it
[08:26] <gnomefreak> i forgot to add universe/libs to the binaries when i changed it for source
[08:26] <gnomefreak> Source: nspr-trunk
[08:26] <gnomefreak> Section: universe/libs
[08:26] <gnomefreak> ackage: libnspr4-0d
[08:26] <gnomefreak> Section: libs
[08:27] <Ubulette> oh
[08:27] <gnomefreak> fixing it now
[08:29] <asac_the_2n1> Hi Ubulette
[08:29] <Ubulette> asac_the_2n1, hi
[08:30] <asac_the_2n1> is the main / universe thing fixed now?
[08:30] <asac_the_2n1> i see them in universe
[08:32] <Ubulette> btw, mozilla bug 393281 is a wontfix
[08:33] <ubotu> Mozilla bug 393281 in HTML: Parser "blank page when visiting a page with a syntax error in it" [Normal,Resolved: wontfix]  http://bugzilla.mozilla.org/show_bug.cgi?id=393281
[08:34] <gnomefreak> asac: it will bewhen im done
[08:34] <asac_the_2n1> Ubulette: yes ... appears to be non-trivial
[08:35] <Ubulette> don't really care about this page, it's broken anyway.
[08:36] <asac> :)
[08:36] <Ubulette> went there as it's the "Seine" river crossing paris that overflowed (?) every century
[08:36] <Ubulette> last time was in 1910.. and it's raining everyday
[08:37] <Ubulette> getting close to the next flood...
[08:43] <asac> well seine appears to be a really quite river then
[08:45] <Ubulette> at the moment, yes ;)
[08:46] <Ubulette> do you want me to push my nss/nspr trees to m-t ?
[08:50] <asac> Ubulette: have i really been such a moron to push those branches to firefox instead of nspr and nss projects?
[08:50] <asac> oh i haven't pushed them at alll ... yes please do
[08:50] <Ubulette> ok
[08:51] <Ubulette> what name should I give them ?
[08:51] <Ubulette> i renamed all my branches as it was a mess
[08:51] <asac> just ubuntu.trunk ?
[08:51] <asac> common practice is not to repeat the project name in the branch name
[08:52] <gnomefreak> this is getting old
[08:52] <gnomefreak> anyway nspr fix is uploading
[08:52] <asac> so nspr.ubuntu.trunk is redundant because its maintained in the nspr project anyway
[08:52] <Ubulette> would be nice to have project name as a 1st column on lp code.
[08:52] <asac> same for nss
[08:52] <asac> right ... for the way ubuntu uses it that might be better
[08:52] <Ubulette> I know that but read the whole page.. you'll end up with several ubuntu.trunk
[08:52] <gnomefreak> why do you come up with this stuff after i upload
[08:52] <asac> but lp is designed for upstream projects as well ... which probably use a more distinct name
[08:53] <asac> gnomefreak: he?
[08:54] <gnomefreak> name not being right for what i can tell (i was disconnected for the first half)
[08:54] <asac> gnomefreak: we could say that the upload today was an upload and deserves a changelog entry ... however, since it gets wiped anyway from ppa next week, we still have the option to just keep branch open without checkpointing the changelog entry
[08:54] <gnomefreak> correct
[08:54] <asac> gnomefreak: Ubulette wasn't here today when we did the upload
[08:54] <asac> gnomefreak: if you want your changelog entry in, you could push as well
[08:54] <asac> i am fine with any way ;)
[08:54] <gnomefreak> i had to add changelog entries
[08:55] <gnomefreak> that wasnt a choice i had
[08:55] <Ubulette> ?
[08:55] <asac> gnomefreak: you had to target the then topmost entry
[08:55] <asac> it was still set to UNRELEASED
[08:55] <Ubulette> why did had to add anything ?
[08:55] <Ubulette> oh
[08:55] <gnomefreak> i set them both to gutsy i thought
[08:55] <asac> yes you should have just documented all in the currentl UNRELEASED changelog entry ... which exists to fill it up during development
[08:56] <Ubulette> ppa is not supposed to end up in gutsy, right ?
[08:56] <asac> then on upload you close that dev cycle by committing it with distribution you upload to
[08:56] <asac> Ubulette: what do you mean?
[08:56] <Ubulette> it's just populating a personal repo
[08:56] <asac> yes
[08:56] <gnomefreak> asac: that would have worked with first upload but none after that
[08:56] <asac> gnomefreak: yes right
[08:56] <asac> or maybe it would have worked
[08:56] <gnomefreak> too late now that can be fixed next week
[08:56] <asac> you would have to remove the .upload file and hope that launchpad didn't see the last upload
[08:57] <gnomefreak> this week is pretty much play with it and see it work
[08:57] <asac> yes ... so letss just push Ubulette's branch ... then do it proper next week ;)
[08:57] <gnomefreak> right
[08:57] <asac> e.g. add all changelog info ... target, commit upload
[08:57] <asac> Ubulette: so just push your branches ;)
[08:58] <asac> to mt
[08:58] <Ubulette> i wanted to get rid of -trunk in src name (as it's not used in deb names)...
[08:58] <asac> code
[08:58] <asac> Ubulette: thats a bad idea
[08:58] <asac> Ubulette: it will finally prevent us to have two versions in the archive at the same time
[08:58] <Ubulette> current state is bad anyway
[08:58] <gnomefreak> current state isnt bad afaict
[08:58] <gnomefreak> what is bad about it
[08:59] <asac> yes ... in fact its pretty good ... you can just upgrade to new libnspr and ffox2 still work
[08:59] <Ubulette> section doesn't matter. better version will be prefered, no ?
[08:59] <asac> what is better?
[08:59] <asac> higher?
[08:59] <Ubulette> y
[08:59] <asac> then yes.
[09:00] <asac> until we upload to real universe this isn't a big problem ... isn't it?
[09:00] <Ubulette> right
[09:00] <asac> and then we can maybe trick apt by just using a lower version :)
[09:00] <gnomefreak> everything atm are little changes to make nothing big
[09:00] <asac> and making firefox-trunk/paradiso directly depend on that lib with =
[09:01] <Ubulette> hmm
[09:01] <asac> Ubulette: no idea if apt-get will downgrade the lib though when you explicitly install firefox-granparadiso
[09:01] <asac> but i thin it will
[09:01] <asac> only open point is how gnome-app-insatll will behave
[09:01] <asac> will it always remove paradiso?
[09:01] <asac> on each and every upgrade?
[09:01] <asac> thats an open point to figure out
[09:02] <gnomefreak> shit
[09:03] <gnomefreak> oh nevermind
[09:03] <Ubulette> I really think it's too early for next week.
[09:03] <gnomefreak> not really it works fairly well
[09:04] <asac> Ubulette: what is too early for next week? what happens next week?
[09:04] <Ubulette> so far, it seems ff2 and ff3 are happy, what about other stuff using those two ?
[09:04] <asac> Ubulette: new libnspr and libnss should not break abi as you know :)
[09:04] <asac> otherwise its upstream grave bug we should communicate
[09:04] <gnomefreak> fairly well == as expected
[09:04] <asac> gnomefreak: what did you test?
[09:05] <gnomefreak> asac: what did i test?
[09:05] <asac> 21:03 < gnomefreak> not really it works fairly well
[09:05] <asac> 21:04 < gnomefreak> fairly well == as expected
[09:05] <gnomefreak> PPA
[09:05] <asac> ah
[09:05] <Ubulette> though it was a tribe thing... maybe not
[09:05] <Ubulette> t
[09:05] <Ubulette> thought
[09:06] <asac> what has tribe todo with what we try in ppa ?
[09:06] <asac> or do you mean we should upload trunk packages for real next week already?
[09:08] <gnomefreak> they are uploaded waiting for build to start
[09:08] <Ubulette> ppa is okay as it's isolated anyway (now and later too). tribe is different, i think we're not ready for system nss/nspr in ff or ff-gp
[09:08] <Ubulette> needs to be tested 1st
[09:09] <Ubulette> as moz guys will probably get mad at us if we do that for ff2
[09:10] <Ubulette> -as+and
[09:11] <asac> Ubulette: right ... needs evaluation + discussion
[09:11] <asac> but in ppa we can do initial evaluation and see how it works out
[09:12] <asac> Ubulette: we use system nss/nspr for firefox2 already (but maybe i just misread)
[09:13] <Ubulette> yes but not cvstag ones
[09:13] <Ubulette> i mean, e use released ones
[09:13] <Ubulette> we
[09:13] <asac> right ... but universe is something unsupported and if users only get that when the explicitly want paradiso then this might be okay
[09:14] <asac> given that after removing paradiso all cleansup automatically
[09:14] <asac> but i see the point
[09:14] <asac> and i am at least as concerned about that as you are ;)
[09:14] <asac> (i hope)
[09:14] <Ubulette> :)
[09:21] <Ubulette> hmm, ftbs for trunk today.
[09:21] <Ubulette> hmm, ftbs for trunk today.
[09:21] <Ubulette> bz390451_master_password_lost.patch has been rejected. Seems committed, at last :)
[09:21] <Ubulette> I'll give it a try
[09:22] <gnomefreak> hmmmmm they dont even have a source tarball for 2.0
[09:24] <Ubulette> ?
[09:25] <gnomefreak> asac_the_2n1: why doesnt mozilla release source tarballs with nightlys?
[09:26] <Ubulette> I do :)
[09:27] <gnomefreak> how do you make a source tarball without the source
[09:27] <gnomefreak> need upstream source to make upstream source tarball
[09:27] <Ubulette> I fetch cvs
[09:27] <gnomefreak> ah that is one way
[09:44] <asac> yeah
[09:44] <asac> better don't look back
[09:44] <asac> you will run away in tears
[09:47] <Ubulette> asac, did you open a bug for installer_shouldnt_skip_strip_if_disable_strip_configured ?
[09:50] <asac> where?
[09:50] <asac> upstream?
[09:50] <asac> no i wanted to submit a good patch right upon opening the bug
[09:54] <Ubulette> feel free :)
[10:21] <shirish> Ubulette: any update on today's build & do you guys have that PPA now?
[10:22] <Ubulette> hi
 hmm, ftbs for trunk today.
 bz390451_master_password_lost.patch has been rejected. Seems committed, at last :)
[10:22] <Ubulette> rebuilding now
[10:22] <Ubulette> lol
[10:51] <shirish> asac, asac_the_2n1 Ubulette anybody has any idea when today's build would be out?
[10:52] <Ubulette> 2nd try:
 <Ubulette> hmm, ftbs for trunk today.
 <Ubulette> bz390451_master_password_lost.patch has been rejected. Seems committed, at last :)
 rebuilding now
[10:52] <Ubulette> should be done soon
[10:53] <Ubulette> shirish, got my answer for pidgin ?
[10:53] <shirish> Ubulette, yup about the monotone, I had played with monotone
[10:54] <shirish> the only problem or stuff is you need to make a database before, a little bit of groundwork, not too hard but also not so easy for noobs
[10:54] <shirish> in that respect svn is very noob-friendly.
[10:56] <Ubulette> as i said, it's not something my bot is ready for. maybe later
[10:56] <Ubulette> I'll think about it but if it's only for 1 project, I'm not sure
[10:57] <Ubulette> btw, I've modify my mini dists, ddebs are now fully integrated
[10:57] <Ubulette> -y+ied
[10:57] <shirish> Ubulette,: understood, would be looking forward for that, it would be very nice if it also understood montone :)
[10:57] <shirish> ah, cool
[10:58] <Ubulette> trunk built.. pushing to repo
[10:58] <Ubulette> 3.0a8pre+cvs20070823t1203+bbot
[10:59] <shirish> Ubulette: thanx
[11:01] <Ubulette> done in 3562 sec
[11:01] <Ubulette> woow. 1h
[11:03] <shirish> wtf adium is not in the repos, isn't it one of the good ones (multi-protocol IM) apart from pidgin?
[11:04] <shirish> ubotu Adium
[11:04] <ubotu> Sorry, I don't know anything about adium - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[11:08] <shirish> bah, me bad it seems Adium is a good IM but only for Macs :(
[11:08] <Ubulette> lol
[11:09] <shirish> http://www.adiumx.com/blog/2007/05/pidgin-200.php
[11:10] <shirish> there is also centericq but the interface isn't appealing at all, guess have to struggle on pidgin in reduced functionality way as well as on xchat
[11:11] <Ubulette> i kind of like xchat
[11:11] <bnovc> looking for an irc or aim client
[11:12] <shirish> bnovc: looking for multi-protocol IM client, like pidgin, pidgin has been behaving badly after some updates
[11:12] <bnovc> shirish: i see. what kind of problems in pidgin?
[11:12] <shirish> bnovc, https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/134347
[11:12] <ubotu> Launchpad bug 134347 in pidgin "[Gutsy]  pidgin doesn't shutdown gracefully" [Undecided,New]
[11:13] <shirish> as well as https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/134366 mores serious than the other.
[11:13] <ubotu> Launchpad bug 134366 in pidgin "[Gutsy]  Pidgin freezes" [Undecided,New]
[11:13] <asac> shirish: why would one shutdown pidgin?
[11:13] <asac> ok
[11:13] <shirish> asac: shutdown as in quit I meant
[11:13] <asac> for me it works well
[11:13] <asac> should be protocol specific
[11:13] <asac> have you tried to not use some protocols to see?
[11:13] <asac> or maybe you have some spurious extension enabled?
[11:14] <shirish> asac: no all by the book, I did do pidgin-dbgsym maybe that could be the reason?
[11:14] <bnovc> pidgin works really well for me
[11:14] <bnovc> asac: sorry i kind of disappeared after asking about helping earlier this week, got more busy than i expected but will try to contribute something this wkend
[11:15] <asac> no  problem :)
[11:15] <asac> do as much as you can do
[11:15] <shirish> does installing -dbgsym make the application more heavier (in a sense they get called all the time) or only when one uses gdb or something like that?
[11:15] <asac> not more ... otherwise your contribution is more likely to not last long :)
[11:16] <shirish> asac: any ideas?
[11:16] <asac> ... howevr .. some contribution is needed to let you feel the fun of all this ;)
[11:17] <asac> shirish: only when you run with debug
[11:17] <asac> shirish: its not that the mozillla is build with --enable-debug ... which would make things slower as more checks are performed and debug output is dumped to console
[11:17] <asac> but with just dbgsym installed ... shouldn't make a difference
[11:18] <shirish> asac: then have no idea, both these bugs were happening before but as a one off thing, but now consistently.  :(
[11:19] <asac> maybe just coincident
[11:19] <shirish> asac: the pidgin --d I did deliberately so could catch whatever was happening, after it didn't respond 3-4 times in a same/similar fashion. Then used -d flag/swithc
[11:19] <shirish> switch
[11:20] <asac> i really have no idea about pidgin
[11:20] <asac> only thing i can say is that you should try to disable all extensions you use
[11:20] <asac> and if that doesn't help try t disable accounts until you find the problem
[11:21] <shirish> asac: will try, maybe i can isolate the problem area, but not right now, its 3 a.m. maybe tomorrow morning with a strong cup of chai/tea ;)
[11:21] <shirish> take care everybody, asac Ubulette bnovc
[12:29] <asac_the_2n1> Ubulette: still awake?
[12:30] <asac_the_2n1> asac_the_2n1: just wondered if you managed to do a simple make install with trunk xulrunner ... so we can evaluate upstreams intentions
[12:42] <Ubulette> with trunk ? not yet
[12:50] <asac_the_2n1> ok
[01:11] <Ubulette> in fact, i can as i've already prepared both the chroot and orig.tgz
[01:14] <asac> Ubulette: just take a glance how the structure produced by current upstream make install looks like ... so not even a to really package it ;)


[16:12] <hggdh>  *** we will not have our weekly QA meeting today (1800 UCT) *** We will return to the normal schedulling next week. Sorry for the late notice.