[00:19] <Larose> I've made a module for linux, I'm trying to create a package. I've followed the instructions on https://wiki.ubuntu.com/PackagingGuide/Basic (debhelper). When I do "sudo pbuilder build ../*.dsc". I've got the following output:
[00:19] <Larose> make[1]: Entering directory `/tmp/buildd/toshlcd-0.1'
[00:19] <Larose> make -C /lib/modules/2.6.22-14-generic/build M=/tmp/buildd/toshlcd-0.1 clean
[00:19] <Larose> make: Entering an unknown directory
[00:19] <Larose> make: *** /lib/modules/2.6.22-14-generic/build: No such file or directory.  Stop.
[00:19] <Larose> make: Leaving an unknown directory
[00:19] <Larose> make[1]: *** [clean] Error 2
[00:19] <Larose> make[1]: Leaving directory `/tmp/buildd/toshlcd-0.1'
[00:19] <Larose> make: [clean] Error 2 (ignored)
[00:21] <crimsun> I presume you're build-depending on the appropriate linux-headers-$(uname -r) package?
[00:21] <Larose> yes
[00:21] <crimsun> (FWIW, you may wish to take a look at how various foo-source packages work; e.g., bin:alsa-source from src:alsa-driver)
[00:26] <Larose> When I do a "make install", (with the source tarball), it works. Is there something special to change to the makefile ?
[00:27] <Larose> http://toshiba-phoenix-lcd.googlecode.com/svn/tags/version-0.1/Makefile
[00:28] <crimsun> I'll take a look when I get home
[00:29] <Larose> ok, thanks :)
[02:07] <imbrandon> wow
[02:07] <imbrandon> gziped irc logs for 2007 are 550mb
[02:08] <nixternal> I am afraid to even see
[02:09] <nixternal> 6% of my hard drive :)
[02:32] <nenolod> right now, src:audacious-plugins contains pulseaudio support in -extra. i will make a debdiff to move it to the main package and also patch up the fixes i have made to audacious' pulseaudio plugin.
[02:33] <nenolod> that's part 2 of fixing pulseaudio in audacious in ubuntu ;p
[03:04] <bddebian> wb persia :-)
[03:08] <persia> hey bddebian
[03:11] <nenolod> https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/164048 -- this is the other part of fixing pulseaudio in audacious -- it needs to be uploaded too.
[03:11] <ubotu> Launchpad bug 164048 in audacious-plugins "[patch] Fix stuttering with large fragments, move Pulse to audacious-plugins" [Undecided,New]
[03:12] <persia> nenolod: When you have multiple patches against multiple packages to address a single issue, consider using multiple bug tasks in a single bug to ease review and testing.
[03:12] <nenolod> persia, noted for the future. :P
[03:12] <persia> nenolod: Thanks :)
[03:12]  * nenolod is used to doing things the Debian way.
[03:12] <nenolod> ;p
[03:17] <Larose> I'm trying to create a .deb for a kernel module. During pbuilder, I've got the following error: "make: *** /lib/modules/2.6.22-14-generic/build: No such file or directory.  Stop.".... Is it because I only have the kernel headers installed (not kernel sources) ?
[03:17] <nenolod> persia, at any rate, that's all i have for now. ;)
[03:18] <persia> nenolod: I'm sure you'll have lots more improvements as the hardy cycle continues,and will want to get audacious in hardy to be the best ever released :)
[03:19] <nenolod> persia, to some extent, yes. because the better the package is, the less people bother upstream
[03:19] <nenolod> ;)
[03:19] <nenolod> although apparently blogging about bugs instead of reporting them is becoming popular
[03:19]  * persia fails to see how that is useful
[03:20]  * nenolod too
[03:21] <nenolod> but at least now the audacious packages in hardy are in sync with the rest of the goals for sound in hardy
[03:31]  * imbrandon yawns
[03:32]  * StevenK tries to get motivated to fix apt-mirror
[03:33] <imbrandon> :)
[03:34] <imbrandon> wanna see a total waste of time parsing 550mb of irc logs ?
[03:34] <imbrandon> ( not perm location or format , just testing phase ) http://people.ubuntuwire.com/~imbrandon/web/ircstats/2007/
[03:36] <imbrandon> hrm actualy 4.2 gb of logs, 550mb gziped
[03:39] <minghua> Judging from imbrandon's statistics, persia is the king of this channel. :-)
[03:39] <imbrandon> minghua: heh yea
[03:39] <imbrandon> seems that way :)
[03:39] <persia> minghua: Look at months like February :P
[03:39] <imbrandon> i made the top 10 except jun and jul iirc
[03:39] <persia> (or september)
[03:41]  * minghua admits only having checked Oct., Nov., and Dec.
[03:41] <DarkMageZ> yay, i even get mentioned 3 times =D
[03:43] <imbrandon> eventualy i'll make it for 2004 to 2007 and all channels that irclogs.u.c loggs
[03:43] <imbrandon> s/loggs/logs
[03:43] <nenolod> brb.
[03:43] <imbrandon> but i wanna tweak it a bit more first, thats about 2 hours of tweakin
[03:44] <imbrandon> i think i'm gonna take the nick url's out though, that will be a monster to maintain and if any are added or changed the whole thing needs to be regenerated
[03:45] <nenolod> imbrandon, nickurls?
[03:45] <imbrandon> see on the stats how my nick points to my LP page, thats a manual config option
[03:45] <imbrandon> for each nick
[03:45] <imbrandon> ( thus only 3 in the testing )
[03:47]  * nenolod waits for launchpad to catch up with his massive bug triage of audacious{-plugins}
[04:12] <nenolod> persia, at any rate, if you could look at the -plugins part, it'd be appreciated. ^_^
[04:13] <nenolod> yuck. i just used an anime smiley.
[04:13] <persia> nenolod: Why me?
[04:14]  * persia doesn't tend to play prerecorded audio, and uses JACK more than pulse
[04:23] <nenolod> persia, well anyone will do. the debdiff is fine.
[04:23] <nenolod> i just need someone to upload it ;p
[04:24] <persia> nenolod: Best for that is the sponsors queue.  Likely to be a bit of the delay between the date and the apache migration currently pending there.
[05:20] <persia> Are there any good free PKI implementations other than newpki?  Am I asking the wrong question?
[05:44] <harrisony> yay revu's back up
[05:46] <persia> harrisony: Be warned that the environmental conditions are such that this may be temporary.
[05:46] <harrisony> hahahah
[05:47] <harrisony> what happened it that made it go down before
[05:47] <imbrandon> server room got too hot
[05:47] <harrisony> poor server
[05:48]  * harrisony wants to know if anyone is in the mood for a quick review of a package
[05:49] <imbrandon> sorry not me, i'm in no mindset to be revuing, i'm barely doing my own pet projects untill after the 25th
[05:49] <persia> harrisony: Chances are low today, but if you said which package and posted a URL, chances would be slightly higher (although still not high).
[05:50] <harrisony> thats why i asked, since i was guessing the chances would be near none - http://revu.tauware.de/details.py?package=ttf-liberation
[05:52] <minghua> Has the licensing situation been cleared up for Liberation fonts?
[05:53] <harrisony> on the launchpad bug for it there was discussion it could get in since the larabie fonts are completly non-free but are still included
[05:55] <crimsun> meaning, multiverse candidate?
[05:56] <harrisony> well i hope not since its got a real good chance for getting into main and getting included by default
[05:58] <minghua> I hope it goes into main/universe too, but it seems Redhat is not interested in licensing discussion (last time I looked).
[05:58] <harrisony> mm
[05:58] <crimsun> if you're referring to ttf-larabie, however, it's in multiverse.
[05:59] <minghua> ... and speaking of fonts, my firefox fonts became horrible after gutsy->hardy upgrade.
[05:59] <harrisony> reinstalls ftw :)
[06:01] <crimsun> minghua: only FF?
[06:02] <minghua> crimsun: Yes.  I have a ~/.fonts.conf, so the "Sans", "Serif", and "Monospace" aliases are okay; it seems just the "Times", "Helvetica", and "Courier" settings got changed (due to the new fontconfig, probably), and many web pages uses those fonts.
[06:05] <persia> Wasn't there an update to fonts hinting that was supposed to make firefox and evince look more similar?
[07:17] <nenolod> i thought the liberation fonts were GPL
[08:00] <joejaxx> nenolod: GPL + exception
[08:00] <joejaxx> iirc
[08:04] <joejaxx> License Exception: http://pastebin.ca/830800 ref: ttf-liberation
[08:07] <joejaxx> persia: yes :P ref: pki
[08:09] <joejaxx> well i am going to retire for the evening
[08:09] <joejaxx> Goodnight All
[10:40] <Kmos> the package: libapache-requestnotes-perl shouldn't be removed ?
[10:40] <Kmos> it depends on libapache-request-perl
[10:40] <Kmos> that doesn't exist
[11:25] <bluekuja> Fujitsu, around?
[11:26] <Fujitsu> bluekuja: Sort of.
[11:26] <bluekuja> Fujitsu, did you upload qtdmm?
[11:27] <bluekuja> Fujitsu, it was assigned to a contributor :)
[11:28] <Fujitsu> Hm, I don't recall doing it recently...
[11:28]  * Fujitsu checks.
[11:30] <bluekuja> Fujitsu, nvm, it seems he doesn't care about it, so I gonna close the bug as far as the package it's already in the archive :)
[11:33] <Fujitsu> bluekuja: Sorry :(
[11:34] <bluekuja> Fujitsu, don't worry :) he didnt answer since days...he disappeared
[11:34] <bluekuja> closing the report
[11:36] <Fujitsu> Thanks.
[11:36] <bluekuja> np
[11:47] <warp10> Hi all!
[11:54] <Kmos> hi warp10 !
[11:54] <Kmos> :)
[11:55] <warp10> morning Kmos! :)
[11:55] <Kmos> morning! :)
[12:30] <\sh> moins
[12:36] <\sh> also to you all...happy holidays, Joyeux Noël, Merry Christmas, Happy Hannukah or whatever you celebrate these days :) Have a peaceful time :)
[12:45] <Super> \sh_away: Merry Christmas
[13:08] <pochu> Icedove is Thunderbird's equivalent, right?
[13:10] <MenZa> sounds like it
[13:15] <Kmos> pochu: http://packages.qa.debian.org/i/icedove/news/20071025T191717Z.html
[13:44]  * Hobbsee waves
[13:45] <Hobbsee> bug 175744
[13:45] <ubotu> Launchpad bug 175744 in compiz "Hardy freezes when using compiz" [Unknown,In progress] https://launchpad.net/bugs/175744
[13:45] <persia> joejaxx: Yes to there being a replacement so the old package can be removed, or yes that I'm asking the wrong question?
[13:47]  * persia wants nouveau soon.  Xid is annoying, bad, and persistent since Dapper.
[13:48] <Hobbsee> wow, that bug is fixed. yya!
[13:48] <Hobbsee> well, so they say
[13:49] <persia> Which bug?  175744?  I can trigger that type of error with lots of different GL stuff, for several different cards.
[13:49] <geser> Hi Hobbsee
[13:49] <bluekuja> Hobbsee, heya :)
[13:50] <bluekuja> Hobbsee, did the equalizator plugin depends/recommends get added to exaile?
[13:51] <Hobbsee> bluekuja: no idea, i don't think so, with somerville32's upload
[13:51] <bluekuja> Hobbsee, let me see
[13:51] <Hobbsee> which i fixed.
[13:51] <Hobbsee> oh grrr
[13:51]  * Hobbsee brb in a sec - no caps lock again
[13:51] <bluekuja> Hobbsee, it seems not
[13:53] <persia> Kmos: re: bug #178424.  Have you tested with all the rdepends of octave2.9?
[13:53] <ubotu> Launchpad bug 178424 in octave2.9 "Please sync octave3.0 3.0.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/178424
[13:54] <Hobbsee> right, back
[13:55] <bluekuja> Hobbsee, what was the name of the plugin?
[13:56] <Hobbsee> bluekuja: equaliser, iirc
[13:56] <bluekuja> Hobbsee, yep, wrong word sorry
[13:57] <bluekuja> Hobbsee, maybe gst-plugin-bad?
[13:57] <bluekuja> Hobbsee, and do you suggest to add it as a direct depend or just a recommend?
[13:57] <bluekuja> Hobbsee, or even suggest
[13:58] <Hobbsee> bluekuja: probably a recommend
[13:58] <Hobbsee> it'll never get to main, if it was wanted, as a depends
[13:58] <Hobbsee> and it's probably of questionable legality, etc, in some countries
[13:58] <bluekuja> Hobbsee, ok perfect, gonna add it as a recommend then
[14:00] <persia> Erm.  Universe can't Recommends: multiverse.  Maybe gst-plugins-bad-multiverse0.10 ?
[14:01] <Kmos> persia: the xmds, octave-epstk and octplot?
[14:02] <persia> Kmos: Also shogun-octave, qtoctave, octave-sp, and maybe octave-forge, if that is a different source (I haven't looked).
[14:03] <Hobbsee> persia: oh, recommends get installed by default soon, don't they?
[14:03] <Hobbsee> bluekuja: suggests then
[14:03] <persia> Hobbsee: even aside from that, debcheck complains
[14:03] <Hobbsee> well, let it :)
[14:04] <bluekuja> persia, yeah, it should be gst-plugins-bad-multiverse0.10
[14:04]  * persia bashes Hobbsee for QA failure
[14:04] <bluekuja> lol
[14:04] <Hobbsee> persia: wait.  it complains about something !universe being a recommends, or a suggests?
[14:04] <Hobbsee> uh oh, mum's up
[14:04] <persia> Hobbsee: Recommends:  I don't care about suggests, even if debcheck does.
[14:04] <Kmos> persia: they work with 2.9.18 and 2.9.19, but I need to check more carefully that ones with 3.0, but they should work.. that bug is in progress.. i'll change it status
[14:05] <bluekuja> persia, I'll add it as a suggests then
[14:05] <Hobbsee> persia: ah right.  i thought you were only talking about suggests there
[14:05] <bluekuja> persia, the package name is gst-plugins-bad-multiverse0.10
[14:05] <bluekuja> as you pointed out before
[14:05] <persia> Kmos: Thanks.  It looked confirmed, and ready for push to the sponsors on review, and I wanted to kick it back before others complained.  Please document your testing carefully: 3.0 would be a nice feature for hardy.
[14:06]  * Hobbsee celebrates the lack of sponsors bugs.
[14:06] <Kmos> persia: yes.. it will =) i
[14:06] <Kmos> ups
[14:06] <persia> bluekuja: Sounds fine to me.  I don't even really know what the subject is: just saw something about questionable legality and Recommends, and wanted to point out the multiverse source :)
[14:06] <Kmos> persia: I'll look at it before set it to confirmed and subscribe my mentors.
[14:08] <bluekuja> persia, the exaile's equaliser requires that plugin to work
[14:08] <bluekuja> persia, that was the subject we were discussing :)
[14:08] <persia> Kmos: Thanks.  Best to look at these things before opening the bug, as many people subscribe to packages or review bug traffic, and may think it is more ready than it is.  If you want to use a bug as a indicator you are investigating, it doesn't hurt to add that in the description: you can always edit it later.
[14:08] <Kmos> the package: libapache-requestnotes-perl shouldn't be removed ? it depends on libapache-request-perl that doesn't exist and it's Apache v1.X
[14:08] <persia> bluekuja: Ah.  OK.  Please fix it (just in multiverse) :)
[14:09] <Kmos> it's also removed from Debian
[14:09] <Kmos> libapache-request-perl doesn't exist even on Gutsy
[14:10] <bluekuja> persia, what do you mean with "just in multiverse"?
[14:10] <bluekuja> persia, exaile is in universe actually
[14:11] <bluekuja> DarkSun88, gonna take of Bug #178440 in a while
[14:11] <ubotu> Launchpad bug 178440 in postgrey "FTBFS: postgrey 1.31-1 on hardy-i386" [Undecided,New] https://launchpad.net/bugs/178440
[14:11] <bluekuja> *care
[14:12] <DarkSun88> bluekuja: Don't worry
[14:13] <bluekuja> DarkSun88, ;)
[14:13] <DarkSun88> The bug is there, doesn't run off :D
[14:14] <bluekuja> ^^ :)
[14:14] <persia> bluekuja: In that case, I don't care.  As I said, I was reacting to "...it's probably of questionable legality, etc, in some countries".  If it's in universe, then I'm not worried, and Recommends is acceptable.
[14:15] <bluekuja> persia, ok perfect, we'll have a universe package recommending that multiverse plugin then
[14:15] <bluekuja> persia, finishing in a while
[14:16] <bluekuja> Hobbsee, setting it as a recommend then
[14:17] <persia> bluekuja: What?  universe can't Recommends: multiverse!  If the plugin is in multiverse, it has to be Suggests:
[14:17] <Kmos> bug 145563
[14:17] <ubotu> Launchpad bug 145563 in libapache-requestnotes-perl "[UNMETDEPS] libapache-requestnotes-perl has unmet dependencies" [Medium,Confirmed] https://launchpad.net/bugs/145563
[14:17] <bluekuja> persia, yes, that's what we said before
[14:17] <Kmos> can someone look at this one ?
[14:17] <bluekuja> persia, I told you the package (exaile) is in universe, the plugin is in multiserve
[14:17] <bluekuja> persia, you misunderstood :)
[14:18] <Hobbsee> bluekuja: yeah, but recommends are getting installed by default soon
[14:18] <persia> bluekuja: I misunderstood.  universe can suggests multiverse, but can't recommends multiverse.
[14:18] <Hobbsee> bluekuja: and you can't have a universe package installing a multiverse package by default
[14:18] <Hobbsee> bluekuja: with the old system, that would have worked.  but nto now
[14:19] <bluekuja> Hobbsee, yeah, right...plus it seems we have a main and a multiverse variant of that package
[14:19] <bluekuja> Hobbsee, e.g gst-plugins-bad-multiverse0.10 and gstreamer0.10-plugins-bad
[14:21] <Hobbsee> yeah - i'm not sure if it's just -bad
[14:21] <Hobbsee> i don't remem;ber anymore
[14:22] <bluekuja> Hobbsee, yeah, it seems its just gstreamer0.10-plugins-bad
[14:22] <bluekuja> Hobbsee, which is in main...
[14:23] <bluekuja> Hobbsee, so we are able to add it as a recommend, what do you think?
[14:23] <bluekuja> persia, any idea?
[14:23] <Hobbsee> bluekuja: recommends is fine, if it's in the right package, and in main
[14:23] <bluekuja> Hobbsee, actually installing gstreamer0.10-plugins-bad package we get the equaliser working
[14:24] <bluekuja> Hobbsee, so it should be the right option
[14:25] <Hobbsee> ah, goody
[14:25] <persia> I thought someone said something about legality and multiverse.  I'm shutting up now, but I'll be unhappy if debcheck complains.
[14:26] <bluekuja> persia, there are two options: 1) gstreamer0.10-plugins-bad (main) and 2) gstreamer-plugins-bad-multiverse0.10 (multiverse)
[14:26] <bluekuja> persia, and it seems the first option installs the right package for exaile
[14:27] <bluekuja> persia, so gonna recommend it :)
[14:28] <persia> bluekuja: universe recommending main is nice and clean.  Thank you :)
[14:28] <bluekuja> persia, yep, np, thanks to you and sorry for bothering
[14:28] <persia> bluekuja: No problem.  Thanks for checking.
[14:28] <bluekuja> :)
[14:41] <jonnymind> hello ppl and Merry Christmas
[14:42] <jonnymind> is REVU still down?
[14:42] <jonnymind> seems not.
[14:42] <persia> jonnymind: Merry Christmas.  Isn't it easier to open a browser than ask on IRC :)
[14:43] <jonnymind> Yes, but I had the xchat win opened and I wanted to hail...
[14:44] <Hobbsee> lazyness is the key to everything, it apperas
[14:44] <jonnymind> so, as it's up, I updated and kindly ask for check on 174470
[14:44] <jonnymind> bug 174470
[14:44] <ubotu> Launchpad bug 174470 in ubuntu "Package for the Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[14:44] <persia> jonnymind: On the other hand, REVU day was cancelled this week.  There's still time to prep for next week, but mid-week reviews will be light, as this is a holiday break in the Hardy calendar.
[14:45] <jonnymind> Ok. No rush anyhow.
[14:45] <jonnymind> Again, Marry Christmas!
[14:45] <manchicken> Let us not forget that laziness is the purpose that software serves ;)
[14:47]  * Hobbsee wonders where revu went
[14:47] <bddebian> Heya gang
[14:51] <bddebian> heh
[15:06] <imbrandon> heya Hobbsee bddebian persia and *
[15:06] <Hobbsee> heya imbrandon
[15:06] <imbrandon> Merry Christmass :)
[15:06] <bddebian> Hi imbrandon and Merry Christmas :)
[15:06] <imbrandon> Hobbsee: it got too hot and shutdown the other day
[15:06] <Hobbsee> ahhh
[15:07] <imbrandon> it was down ~48 hours because sire*tart also happen to be ill when it happened too unfortunately :(
[15:07] <Hobbsee> ahh
[15:07]  * Hobbsee --> bed.  merry christmas all!
[15:07] <imbrandon> gnight Hobbsee
[15:08] <imbrandon> ScottK: round ?
[17:21] <ScottK-palm> imbrandon: U there?
[17:23] <norsetto> oh, well, now I have seen them all, when will we have the honour of ScottK-Cray ?
[17:24] <ScottK-palm> Duuno.  Palm IRC doesn't work so well.
[17:24] <norsetto> ScottK-palm: have a nice xmas you and your family anyway
[17:24] <ScottK-palm> imbrandon and I are attempting to meet for lunch today.
[17:26] <norsetto> Nice, I didn't know brandon lived in the states
[17:27] <ScottK-palm> leonel: I don't have the bug handy, but I set up a bug against all the packages needing rebuilding due to the libclamav transition.
[17:28] <ScottK-palm> norsetto: even better he lives in the city I grew up in.
[17:30] <leonel> ScottK-palm: I'll search for it  and  add my comments there
[17:31] <ScottK-palm> leonel: Good.  Also close that bug in the debian/changelog of any uploads you prepare.
[17:31] <leonel> ScottK-palm: found it   bug 178373
[17:31] <ubotu> Launchpad bug 178373 in python-clamav "Package needs rebuild/fixing for libclamav2/libclamav3 transition" [Medium,Confirmed] https://launchpad.net/bugs/178373
[17:32] <leonel> ScottK-palm: Ok i will
[17:32] <ScottK-palm> leonel: Klamav needed a small patch to build.  the rest I've just rebuilt.
[17:32] <ScottK-palm> Yes.  That's it.
[17:33] <ScottK-palm> You'll see I got a reasonable fraction of them done already.
[17:34] <leonel> I see  I got some time to do that today
[17:35] <ScottK-palm> norsetto: That bug might also be a useful one for one of your hopefuls to work on.  if they do, they can ping me for sponsoring.
[17:35] <ScottK-palm> Great.
[17:36] <ScottK-palm> I need to run.  Chat with you all later.
[17:37]  * norsetto wonders what "one of your hopefuls" means
[17:44] <LaserJock> hi MOTU Land!
[17:45] <effie_jayx> LaserJock: merry christmas
[17:46] <LaserJock> effie_jayx: merry Christmas to you!
[17:50] <bddebian> Heya LaserJock
[17:53] <LaserJock> bddebian!
[17:53] <LaserJock> how are you?
[17:53] <bddebian> Hanging in there thanks.  You?
[17:53] <LaserJock> pretty good
[17:54] <LaserJock> splurged yesterday and bought a new laptop
[17:54] <bddebian> Nice
[17:55] <LaserJock> probably can't afford it
[17:55] <crimsun> you phd candidiates and floating wads of cash, sheesh.
[17:55] <crimsun> the rest of us sods have coal in our stockings!
[17:55] <LaserJock> but it's my "pre PhD ... need new machine to finish PhD" present
[17:55] <bddebian> heh
[17:55] <LaserJock> crimsun: yes, so much cash .... I don't even know what to do with it
[17:56] <LaserJock> my "old" laptop is 4-5 years old and actually my wife's
[17:56] <LaserJock> so I gave back to her ;-)
[17:56] <crimsun> time for u-u-s queue.   I managed to end up with a B in chem! *hugs uncle Jordan*
[18:07] <LaserJock> jdong: \o/
[18:08] <LaserJock> good news
[18:08] <Nafallo> LaserJock == Jordan?
[18:08] <jdong> :)
[18:08] <LaserJock> Nafallo: yes, sorry
[18:08] <Nafallo> thought so :-)
[18:08] <LaserJock> I should change my nick like the rest of the world
[18:08] <jdong> LaserJock: now I'm just waiting for the news fairy to deliver my math and bio grades :)
[18:08] <crimsun> pfft, Nafallo has been around long enough to know that ;)
[18:08] <Nafallo> exactly :-)
[18:08] <jdong> which I don't think will be nearly as bright.
[18:08] <Nafallo> just wanted to make sure ;-)
[18:09] <LaserJock> jdong: I was actually watching gen chem MIT lectures on my ipod not long ago
[18:09] <jdong> sweet
[18:09] <Nafallo> the 'uncle' part confused me a little ;-)
[18:09] <LaserJock> jdong: well, it's MIT, Bs are ok ;-)
[18:09] <jdong> LaserJock: this term I'd just be happy to end up with all C's :)
[18:10] <jdong> never every try to cram all the institute graduation requirements into one term!
[18:10] <LaserJock> heh
[18:10] <jdong> procrastination always beats dying of stress.
[18:10] <LaserJock> hmm
[18:10] <LaserJock> do I have to be running a 64bit Ubuntu to make a 64bit pbuilder?
[18:12] <LaserJock> I managed to get a laptop with core 2 duo, intel graphics, and intel wireless
[18:12] <jdong> LaserJock: yeah you need a 64-bit kernel to do so
[18:12] <jdong> LaserJock: or use VMWare which can virtualize a 64-bit guest from a 32-bit host
[18:13] <LaserJock> jdong: ah, I see
[18:13]  * jdong is surprised this airport wifi is holingng up
[18:13] <jdong> holding*
[18:18] <norsetto> jdong: you may want to check bug 178267 before the wifi gives up ?
[18:18] <ubotu> Launchpad bug 178267 in hardinfo "Hardinfo crashes during processing the Benchmarks." [Medium,Fix released] https://launchpad.net/bugs/178267
 leonel: Good.  Also close that bug in the debian/changelog of any uploads you prepare.  <--   This in the debdiff  ???
[18:19] <LaserJock> leonel: that should be in the debdiff
[18:20] <LaserJock> man, this 12cell battery is huge, but it sure lasts a while
[18:30] <leonel> LaserJock: ok
[18:42] <crimsun> ember_: I've fixed the get-orig-source rule (use of .. in symlink)
[19:15] <groo> hi/2 all...
[19:16] <groo> could anyone help me with a reject from the PPA server?
[19:17] <Kmos> groo: what it says in the mail ?
[19:18] <groo> Rejected:
[19:18] <groo> MD5 sum of uploaded file does not match existing file in archive
[19:18] <groo> Files specified in DSC are broken or missing, skipping package unpack verification.
[19:19] <groo> Kmos: the problem is that the orig.tar and the packages uploaded match the MD5.. i suspect that a orig.tar.gz from the original (first) upload, wasnt deleted after the forced upload, ence the md5 mismatch
[19:20] <groo> i?  not a newbie to dput or ppa... i have a lot of packages there, and always worked.. today i got rejects for two diferente packages.. don't know what's wrong, since the md5s that i run by hand mtach the ones in .dsc
[19:20] <groo> Kmos: any ideas?
[19:22] <groo> Kmos: how much time does is take for the ppa server to delete a reject orig.tar.gz?
[19:28] <Kmos> groo: you can forget the upload.. dput -f *.changes
[19:28] <Kmos> *force
[19:39] <groo> Kmos: tried that.. same error
[20:26] <Gunner_Sr> hi persia
[20:45] <totopalma> RainCT, hi :)
[21:19] <imbrandon> norsetto: yup I'm in the USA ( Kansas City, Missouri to be exact ) :P
[21:20] <norsetto> imbrandon: right!
[21:20] <norsetto> imbrandon: have you guys had launch already?
[21:21] <imbrandon> yup just got back
[21:21] <imbrandon> walked back in the door aobut ~10 minutes ago
[21:22]  * Fujitsu appears.
[21:22] <imbrandon> Gates BBQ ftw :)
[21:22] <imbrandon> heya Fujitsu
[21:23] <Fujitsu> imbrandon: What are you doing up?
[21:23] <imbrandon> Fujitsu: i was about to ask you the same thing :)
[21:23] <imbrandon> i just met ScottK for lunch
[21:23] <imbrandon> so i had to be up early today :)
[21:23] <Fujitsu> It's 0823 here, so I'm allowed to be up.
[21:23] <Fujitsu> Ahh.
[21:23] <norsetto> merry xmas fujitsu
[21:24] <Fujitsu> You too, norsetto.
[21:24] <imbrandon> Fujitsu: i never rember is it the 25th there now i guess ? get any new toys ? hehe
[21:24] <Fujitsu> imbrandon: It is, yes.
[21:25] <Fujitsu> No, no.
[21:25] <imbrandon> :)
[21:34] <RainCT> hi totopalma
[21:40] <Kmos> merry xmas!
[21:41] <bddebian> Merry Christmas km
[21:41] <bddebian> E...
[21:41] <Fujitsu> Hm, have we had a mass-giveback? Looks like it.
[21:42]  * persia believes this to be further evidence of Santa Claus
[21:43] <Fujitsu> Definitely.
[21:43]  * Fujitsu kicks kohnen
[21:43] <Fujitsu> It gets a Christmas kick from me :)
[21:52] <Fujitsu> Yay, the give-back killed 2/3 of the i386 FTBFSes.
[21:53] <nxvl> norsetto: hi!
[21:53] <nxvl> norsetto: how are you doing?
[21:53] <norsetto> hi nxvl, fine and you?
[21:53] <nxvl> fine, waiting for the night to get dinner with my family
[21:54] <bddebian> persia: I was trucking along with jugglemaster, now I just broke a Debian patch.. :(
[21:54] <norsetto> nxvl: its a special dinner tonight?
[21:54] <nxvl> norsetto: christmas dinner
[21:54] <persia> bddebian: What did you break?
[21:54] <norsetto> nxvl: yes, so you eat special food ?
[21:55] <bddebian> some patch to src/jmdlx/newsemaphores.cpp
[21:55]  * Fujitsu thought he was ahead of most of the rest of the planet.
[21:55] <nxvl> norsetto: turnkey
[21:55] <Fujitsu> Or do you crazy people celebrate a day early?
[21:55] <nxvl> norsetto: and some other christmas stuff
[21:55] <nxvl> norsetto: well i need to go, i only wanted to wish you a very nice christmas
[21:56] <norsetto> nxvl: you and your family too. Have a fun xmas!
[21:56] <persia> bddebian: You know that you're supposed to be editing the files in a patched environment, right :)  Anyway, it's just an if wrapper: should be simple to reapply.
[21:57] <persia> Did you get it from wxT("Semaphore") ?
[21:57]  * Fujitsu sees `wx' and runs away.
[21:59]  * persia notes the date in Victoria, and suggests not even wx should be shunned :)
[22:02] <bddebian> persia: Aye, I've fixed quite a bit already.  There's a guy in #wxWidgets that has been super helpful
[22:02] <bddebian> Anyway, gotta jump in the shower, bbl
[22:03] <Fujitsu> persia: Bah, humbug.
[22:03] <persia> bddebian: I'll be idle when you return, but don't wrap the constant unless it is being transformed to wxString.  JML_CHAR* takes a C string normally.  (and that upstream is particularly annoying).
[22:30] <RainCT> merry christmas :)
[22:31] <RainCT> and good night
[22:40] <persia> frenchy: congrats on me-tv :)
[22:50] <frenchy> persia: Hi there, yes Me TV has just made its way into sid.  Thanks for archiving.
[22:52] <RzR> hi  i have an issue while uploading to PPA
[22:52] <RzR> it's a 9mb source arvhice
[22:52] <RzR> and fails :
[22:52] <RzR> Error '(22, 'Invalid argument')' during ftp transfer of coccinella_0.96.4.orig.tar.gz
[22:57] <ScottK2> persia: Merry Christmas.
[23:20] <norsetto> g'night all
[23:47] <frenchy> RzR: Still there?
[23:48] <RzR> yea
[23:48] <RzR> oui mr la grenouille
[23:50] <frenchy> RzR: Hahaha, seems like all the people that know stuff aren't here anymore.  Maybe someone at #launchpad might be able to help.
[23:52] <RzR> actually my prolem is fixed
[23:52] <RzR> ii suppose this is a timeoutt issue
[23:53] <frenchy> Oh, ok ... Monsieur Grenouille, out.


[03:42] <stub> fwereade: Still there?
[03:50] <stub> fwereade: I'm not sure exactly what you mean by early departure for peer relations regarding Bug #1192433, but if it stops the unit being listed in relation-list while all the -depart and -broken hooks are running that addresses the bug.
[03:50] <_mup_> Bug #1192433: relation-list reporting dying units <jujud> <relations> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1192433>
[03:52] <stub> fwereade: Ordering of provides/requires actually sounds more interesting to me. For example, it would have addressed Bug #1187508
[03:52] <_mup_> Bug #1187508: adding a unit of a related service to postgresql is racy <postgresql (Juju Charms Collection):In Progress by davidpbritton> <https://launchpad.net/bugs/1187508>
[03:53] <stub> fwereade: If the provider's join hook was run before the requirer's join hook, then I can guarantee that access from the require has been granted by the provider before the requirer attempts to connect. This makes the client charms much easier to write.
[04:17] <marcoceppi> stub: I'd be a slight departure from the current story, not that I don't have a problem with that perse, but the idea I've gotten enstilled as to what each hook means is as follows:
[04:19] <marcoceppi> joined - "handshake" hook, expect to have no data available
[04:19] <marcoceppi> changed - "stuff on the wire", alwasy check values, idempotency
[04:19] <marcoceppi> departed - "waving goodbye", relation values should still be available, do what you need to with these values
[04:19] <marcoceppi> broken - "clean up", make any changes post-mortem
[04:19] <marcoceppi> how does having the clients joined/changed hook run prior to the providers create a race condition? That just seems like non-idempotent hooks to me
[04:20]  * marcoceppi reads bug report
[04:20] <stub> marcoceppi: Lets say you have an existing setup, with a single unit of service A related to a single unit of service B.
[04:20] <stub> marcoceppi: Now add a new unit to service A (the requirer or client).
[04:21] <stub> marcoceppi: It looks at the relation, picks up authentication credentials, and attempts to use them *before B has had a chance to authorize the new unit's IP address*)
[04:21] <marcoceppi> right, I see. db-admin relation data is already set because that unit's done it's thing, but relation-changed needs to run on the postgresql side to complete the setup
[04:22] <marcoceppi> stub: I'm inclined to say this is a bug with juju, from my understanding the data should be unique per unit <-> unit (though core may need to correct my understanding of this)
[04:22] <marcoceppi> In this case, each unit should get it's own credentials, not the credentials cached from the prior units relation
[04:23] <marcoceppi> and should follow the normal hooke execution as if it was a new add-relation
[04:23] <stub> marcoceppi: Yes, you could make that argument. You could even make it somewhat backwards compatible if there was relation->unit and unit->unit data, with the unit->unit data overlayed over the top of the relation->unit data.
[04:24]  * marcoceppi nods
[04:24] <stub> I don't think we would see a change like that until 2.0+ though, even if it was agreed on today.
[04:25] <marcoceppi> I feel like this would resolve your issue and is what the expected behavior of juju, at least the first part of a fresh relation each time
[04:25] <marcoceppi> Possibly
[04:25] <marcoceppi> In the mean time your patch for postgres landed (while not the best answer to the question)
[04:26] <stub> ta :)
[04:27] <marcoceppi> I'd hope this could be documented and solidified either as expected behaviour or fixed in core soon to represent the actual anticipated behaviour
[04:27] <marcoceppi> I'll poke #juju-dev tomorrow
[04:27] <marcoceppi> "tomorrow"
[04:30] <stub> marcoceppi: The documentation certainly needs to be clearer. I think everyone has troubles when they start dealing with more complex charms, and end up writing test cases to work out wtf is actually happening.
[04:31] <marcoceppi> stub: yeah, even during my demo last week I was like "wtf is going on" and had to step through debug-hooks as if it was part of the training, only so I could know understand what was actually going on
[04:31] <stub> marcoceppi: I don't know if the change you propose to relation storage will make things better conceptually or not.
[04:31] <marcoceppi> I'd like to think so, but I may be biased
[04:32] <stub> It means that to retrieve data from a specific bucket in the relation, two units need to be specified rather than one.
[04:34] <stub> I like specifying the ordering of hooks. I don't think it will slow things down much in the real works, and greatly reduces the number of states hooks need to cope with.
[04:34] <stub> c/in the real works/in the real world/
[04:45] <marcoceppi> stub: I don't see how you'd have to specify two units?
[04:46] <marcoceppi> I think relation-get always assumes the current unit, as you technically can't/shouldn't be able to spy on other units
[04:46] <stub> marcoceppi: Right. But how do you retrieve the current units data? The data on its end of the relation? It has one bucket per remote unit.
[04:47] <marcoceppi> stub: in the relation-* hooks $JUJU_REMOTE_UNIT is prefilled and used by the relation-* commands
[04:47] <marcoceppi> it's just pulled from env
[04:47] <stub> ok, so you would make it impossible to access the other buckets
[04:48] <stub> peer relations certainly need to spy on other units data
[04:48] <marcoceppi> stub: With the exception of peer relations, I think the idea is you shouldnt' be able to tap in to other relations that the unit isn't aware of
[04:49] <marcoceppi> peers are a bit different, but still follow the same event cycle, it's just each unit is individuall connected to each other so you could relation-get -r <rel-id> <unit> and get data as you're technically connected to it
[04:51]  * marcoceppi heads to bed
[04:52] <stub> Goodnight
[04:52] <stub> I'll continue chasing race conditions from the hoops I have to jump through because there is no defined order that my hooks get called :)
[04:53] <stub> A maze of twisty hooks, all of them alike.
[07:41] <fwereade> stub, heyhey
[07:41] <stub> fwereade: heya
[07:42] <fwereade> stub, so my current plans are to cause peer units only to (appear to) depart the relation as soon as they're dying
[07:43] <fwereade> stub, because that directly addresses the case in your bug (for which many thanks, btw)
[07:43] <stub> That sounds fine to me.
[07:45] <fwereade> stub, it is not a watertight guarantee of ordering, though -- any given unit might be busy with, say, a long-running config-changed hook while the remote unit is departing
[07:46] <fwereade> stub, and *could* thus still end up only observing the departure after it actually happened
[07:47] <stub> Yes, if other hooks are allowed to run at the same time, then anything that the hook knows may be a lie. It only has a snapshot of the environment from when it started.
[07:48] <stub> I'm just avoiding that whole issue at the moment in places where it is important, such as failover.
[07:48] <fwereade> stub, I don't think that there is much realistic hope of enforcing the sort of lockstep ordering I think you would ideally like to see across the whole system
[07:48] <stub> So if you remove-unit a master, you are going to blow your foot off if you are silly enough to make other changes before it is finished.
[07:49] <stub> fwereade: I agree lockstep accoss the system is probably not a good idea. However, I'm thinking the sequence of relation joined/changed/broken/departed would be helpful to write less buggy charms.
[07:50] <fwereade> stub, however I am very keen to make it *easier* to write charms that are sane and effective
[07:50] <stub> The number of possible states even a simple relationship can be in is very large, and some of those states are rare (eg. a unit is being removed before another units -joined hook has started running).
[07:52] <fwereade> stub, are you familiar with https://juju.ubuntu.com/docs/authors-charms-in-action.html ? I wrote it quite a long time ago but I don't think it's had quite the exposure it should have (I wasn't paying enough attention to the user-facing docs, I kinda threw what I'd written over the wall and didn't follow up)
[08:28] <stub> urgh... proxy seized up
[09:19] <fwereade> stub, sorry, didn't see you come back
[09:20] <fwereade> stub, not sure if you saw; I asked if you'd seen https://juju.ubuntu.com/docs/authors-charms-in-action.html ?
[09:26] <stub> fwereade: yes, I've seen that
[09:28] <stub> absorbed it, maybe not :) I see it is describing the current departed/broken/actually leaves behavior
[09:32] <ehw> hey guys, does ppa:juju/stable (1.12 I think) support completely offline maas+openstack deployment?
[09:35] <stub> fwereade: In case it didn't get through, I said before that my highest priority issue is Bug #1200267 to make my tests reliable. The hook ordering stuff is all complex and tricky, but the charm I'm working on is complex and tricky.
[09:35] <_mup_> Bug #1200267: Have juju status expose running and pending hooks  <juju-core:Triaged> <https://launchpad.net/bugs/1200267>
[09:39] <fwereade> stub, ok, that's interesting... there's a bit of a problem there in that it's impractical to try to track the possible future, but it would be possible for the unit agent to report whether or not it's *currently* idle
[09:40] <fwereade> stub, and knowing that every unit in play is currently idle would probably be sufficient -- *at the moment* -- to determine that the system's in a steady state
[09:40] <jam> ehw: we may have bugs in that area (especially with charms themselves), but with some config, I think stable has enough to work disconnected from the internet. You'll need to do stuff like get tools into the local cloud first, etc.
[09:41] <stub> fwereade: Yes. If no hooks are running, and no hooks are queued, we are steady.
[09:41] <fwereade> stub, I'm just not sure how useful that guarantee is in practice -- there's always the possibility that some other user will add a unit, or change config, or something
[09:41] <stub> fwereade: This is for writing tests.
[09:41] <ehw> jam: is there a way to get the tools in? are they stored in MAAS?
[09:42]  * ehw has seen the FileStorage bits in MAAS, but they don't seem connected to anything
[09:42] <jam> ehw: there is a 'juju sync-tools' command. I believe in the 1.12 stable release it always downloads them from amazon, in 1.13 there is a "--source" flag so you can copy them from your local disk.
[09:42] <jam> ehw: there is also juju:ppa/devel if you find 1.12 d
[09:42] <jam> doesn't work
[09:42] <fwereade> stub, and if in the future we add a juju-run mechanism (ie allowing a unit too feed info back into juju outside of a regularly scheduled hook) it's almost no guarantee at all
[09:43] <fwereade> stub, ok, the test context makes it much saner
[09:44] <ehw> jam: ok, I'll see if I can try this out with 1.12
[09:44] <fwereade> stub, is it very important to know *which* hooks are queued/running, or is a single bit of steadiness info per unit sufficient?
[09:45] <stub> fwereade: A single bit of steadiness is just fine for my use case.
[09:45] <jam> ehw: so I'm pretty sure that for 1.12 the client (the place you are running 'juju *' from) needs at least some internet access. Once you're set up, I don't think the actual MaaS nodes need public internet access (ex
[09:45] <jam> except for some specific charms that talk out the network, etc)
[09:45] <stub> It could even just be 'juju wait', that blocks until a steady state is reached. Then I don't even have to bother with polling juju status.
[09:46] <ehw> jam: have a deployment next week in a secure environment; working on a methodology for this atm
[09:47] <fwereade> stub, that feels like overreaching on juju's part, considering the possibility of juju-run, which prevents us from making that guarantee -- I would be much more comfortable with exposing current steadiness per unit, with the caveat that the information can only be acted upon if you have a lot of specific knowledge about the environment
[09:48] <stub> fwereade: ok
[09:51] <stub> I just need some way to tell that it is ok to proceed with making the test, rather than the current approach of sleep() and hope :)
[09:55] <stub> fwereade: Since we are talking about this only being useful for tests, this might sit better in amulet if there is some way of reaching into juju and inspecting what needs to be inspected.
[09:57] <stub> (the current implementation of wait there just parses the 'juju status' output, similar to my own test harness)
[10:13] <stub> juju-run might fix this horrible bit of code. For a certain operation, I need to block until the database is out of backup mode. It might be in backup mode because backups are being run, or it might be in backup mode because a backup started and failed to complete. The charm currently emits details and instructions how to clear it manually to the log file every few minutes until it is unblocked.
[10:14] <stub> Hmm... I can see this turning into twisted :)
[14:52] <jcastro> Reminder: Charm meeting in ~1 hour!
[14:53] <jcastro> marcoceppi: marcoceppi utlemming arosales ^^^
[15:01] <utlemming> I'm using ppa:juju/devel and looking at "juju debug-log"...
[15:03] <arosales> jcastro, ack and thanks for the reminer
[15:03] <arosales> *reminder
[15:23] <jamespage> jcastro, what time is the charm call?
[15:24] <jcastro> jamespage: top of the hour
[15:24] <jamespage> jcastro, ack
[15:24] <jcastro> ~40 minutes
[15:53] <jcastro> arosales: pad is up to date and ready!
[15:54] <arosales> jcastro, thanks are you setting up the hangout?
[15:54] <jcastro> yep
[15:58] <jcastro> http://ubuntuonair.com/ for those want to follow along in the meeting
[15:58] <jcastro> https://plus.google.com/hangouts/_/96e374b291c31f8310be00593580b52eb8418b02?authuser=0&hl=en if you want to participate
[16:01]  * m_3 having hardware issues with latest nvidia updates :-(
[16:04] <marcoceppi> m_3: yaeh, those killed me last night
[16:23] <m_3> marcoceppi: maybe write that as a full deploy line
[16:24] <arosales> jamespage, jcastro also this bug we need to address in precise https://bugs.launchpad.net/juju-core/+bug/1203795
[16:24] <_mup_> Bug #1203795: mongodb with --ssl not available in precise <doc> <papercut> <juju-core:Confirmed> <https://launchpad.net/bugs/1203795>
[16:25] <arosales> at least figure out the story since if we can't backport mongo and lxc
[16:28] <kurt_> jamespage: must the ceph.yaml go in the .juju directory?
[16:28] <jamespage> kurt_, no
[16:28] <kurt_> where should it go?
[16:28] <jamespage> kurt_, you pass it to juju deploy with the --config flag
[16:28] <kurt_> ah ok
[16:28] <jamespage> juju deploy --config --config
[16:29] <jamespage> juju deploy --config config.yaml
[16:29] <kurt_> its unnecessary after the configuration, correct?
[16:29] <kurt_> sorry, deployment
[16:29] <AskUbuntu> is openstack swift required for juju integration? | http://askubuntu.com/q/335447
[16:35] <kurt_> jamespage: is the ceph.yaml in scuttlemonkeys guide (http://ceph.com/dev-notes/deploying-ceph-with-juju/) up to date? I'm looking specifically at the ceph-osd source and device information and ceph-radosgw source.
[16:35] <arosales> jcastro, jamespage http://bazaar.launchpad.net/~openstack-charmers/+junk/openstack-ha/view/head:/python-redux.json
[16:36] <kurt_> and I'm wondering in the source string for gui for ceph would then be changed to quantal to try it that way?
[16:43] <hazmat> kurt_, precise is fine
[16:43] <hazmat> re source string for gui
[16:43] <hazmat> er default
[16:46] <kurt_> hazmat: default in gui for source string is "cloud:precise-updates/folsom"
[16:47] <hazmat> kurt_, oh sorry you meant for ceph within the gui, not for deploying the gui
[16:47] <kurt_> hazmat: my questions above may seem confusing, sorry - I had separate ones for CLI and gui methods
[16:49] <hazmat> kurt_, if your deploying the precise charm that's a good default .. its the charm that determines which distro release your getting, so you want the source string to match the charm series name.
[16:49] <kurt_> CLI - my questions were on the ceph.yaml and for the gui my question was about the source and now looking at it, the odd-devices string.
[16:51] <kurt_> ok, there appears to be no guide using the gui to deploy ceph.  I can see there is a separate charm for ceph-radosgw, ceph-osd, and ceph
[16:52] <kurt_> i should probably just stick to manual method for now
[16:56] <weblife> Is there any important data stored on ephemeral storage?  Use Case: Stopping AWS bootstrap and staring it again.
[17:04] <jcastro> hazmat: bah I lost the URL, deployer docs are at ... ?
[17:07] <hazmat> http://pythonhosted.org/juju-deployer/
[17:07] <jcastro> ta
[17:08] <jcastro> hazmat: so this doesn't explain how to use it though, no examples in the man page either
[17:08] <jcastro> assuming I have example.yaml as an exported bundle how do I deploy it?
[17:08] <hazmat> jcastro, good point. juju-deployer  -v -W -c example.yaml name_of_bundle
[17:14] <jcastro> hazmat: aha! I get an error when trying to deploy this: http://bazaar.launchpad.net/~openstack-charmers/+junk/openstack-ha/view/head:/python-redux.yaml
[17:14] <hazmat> jcastro, which is? pastebin? on maas?
[17:15] <jcastro> http://pastebin.ubuntu.com/6011028/
[17:16] <kurt_> scuttlemokey: I have some updated instructions for the monitor-key generation section for your ceph documentation
[17:16] <kurt_> http://pastebin.ubuntu.com/6011030/
[17:18] <hazmat> jcastro, that reads like an error in the config file
[17:18] <hazmat> jcastro, ie. its not valid yaml
[17:19] <jcastro> hazmat: ah nm, I found the problem
[17:19] <hazmat> jcastro, html instead of yaml ?
[17:20] <jcastro> yeah so if you wget that page from lp you get the html
[17:20] <jcastro> duh
[17:20] <hazmat> jcastro, yeah.. just verified that the python-redux.yaml is correct
[17:20] <hazmat> er.. is valid yaml
[17:28] <jcastro> heya kurt_ you gotta check this out, you still have maas?
[17:29] <kurt_> yep.
[17:29] <jcastro> snag that yaml file
[17:29] <jcastro> then get juju-deployer from ppa:juju/pkgs
[17:29] <jcastro> http://pastebin.ubuntu.com/6011079/
[17:30] <kurt_> jcastro: will this tear up what I have running currently?
[17:30] <jcastro> It will probably clobber the universe
[17:30] <marcoceppi> jcastro: wait, is juju-deployer in juju/pkgs?
[17:31] <jcastro> actually, I have it in saucy
[17:31] <jcastro> I've seen it in juju/pkgs
[17:31] <hazmat> its in the distro
[17:31] <hazmat> in saucy i think
[17:31] <marcoceppi> jcastro: that's not the right version
[17:31] <marcoceppi> I need to remove that
[17:31] <kurt_> jcastro: shall I wait then?
[17:32] <jcastro> yeah
[17:32] <jcastro> jamespage: it bombed out during this part: http://pastebin.ubuntu.com/6011085/
[17:33] <jcastro> do I need to have a bunch of locally branched stuff?
[17:33] <marcoceppi> I've never heard of switf-storage-z1
[17:33] <hazmat> marcoceppi, 3 swift nodes
[17:34] <hazmat> juju-deployer also in a daily ppa https://launchpad.net/~ahasenack/+archive/juju-deployer-daily with dep https://launchpad.net/~ahasenack/+archive/python-jujuclient or from pypi.. virtualenv --system-site-packages deployer && source deployer/bin/activate && pip install juju-deployer
[17:35] <ahasenack> about swift-storage, the charm is called swift-storage, but the config deploys it as swift-storage-zN
[17:36] <ahasenack> where N is 1, 2 or 3 (if we are talking about the openstack juju-deployer config file)
[17:36] <ahasenack> so I think that config is missing a "charm: swift-storage" entry under swift-storage-z1
[17:36] <ahasenack> 2013-08-21 13:29:48  Deploying service swift-storage-z1 using local:precise/swift-storage-z1 <-- wrong
[17:37] <ahasenack> should be
[17:37] <ahasenack> 2013-08-21 13:29:48  Deploying service swift-storage-z1 using local:precise/swift-storage
[17:39] <marcoceppi> evilnickveitch jcastro: I also found out there's about 25 or so extra undocumented environments.yaml config options for juju-core
[17:40] <marcoceppi> okay, 25 might be an overestimate, but there's a quite a few
[17:43] <kurt_> jamespage: in looking at your cephalopod article - do you have precise instructions instead of quantal?
[17:51] <hazmat> ahasenack, fwiw that's fixed in deployer trunk, charm: becomes optional, it will use the name in the charm md if none is specified
[17:53] <ahasenack> ok
[19:57] <marcoceppi> ahasenack hazmat btw I've got two merge proposals for deployer, once is minor and cosmetic the other is a blocker for amulet:  https://code.launchpad.net/~marcoceppi/juju-deployer/local-branches/+merge/181207 if you could reveiw sometime this week that'd be great!
[19:59] <hazmat> marcoceppi, ack i'll get those merged in this evening.
[19:59] <marcoceppi> hazmat: thank you sir!
[21:10] <sidnei> adam_g: did you have issues with rabbitmq-server 2.7.1? it's failing to start when deploying on precise local provider
[21:11] <adam_g> sidnei, no, its been working fine in non-local deployments for a while
[21:11] <adam_g> sidnei, with the exception of clustering in environments with funny DNS
[21:11] <sidnei> i guess it might be a lxc-specific failure
[21:11] <adam_g> sidnei, what is the failure?
[21:11] <sidnei> there's nothing interesting in the rabbit logs, only 'failed to start'
[21:11] <sidnei> and epmd is left running
[21:12] <adam_g> sidnei, can you resolve your localhost name and IP?
[21:12] <adam_g> er, local hostname
[21:12] <adam_g> :)
[21:12] <sidnei> uhm, hostname is set to ubuntu, it might be resolving to multiple addresses
[21:13] <sidnei> or not
[21:14] <sidnei> well, it's probably that
[21:14] <sidnei> $ ping ubuntu
[21:14] <sidnei> PING ubuntu (<IP_ADDRESS>) 56(84) bytes of data.
[21:14] <sidnei> but local ip is <IP_ADDRESS>
[21:14] <sidnei> will dig further after the break
[22:16] <sidnei> https://code.launchpad.net/~sidnei/charms/precise/haproxy/trunk/+merge/181421 up for review again
[23:08] <kurt_> jamespages: do you have any guides for ceph deployment with cinder and openstack?


[17:10] <simon_weber> Hi all! I'm hoping to copy a build from a ppa into mine. It's an old package and no longer published, so it doesn't show in the "copy packages" interface. Given a link to the build result, what's the easiest way to copy the result to my ppa?
[17:11] <simon_weber> I think I just need the .changes file and the files it references, then I give those to dput?
[17:11] <dobey> you can't dput binary packages to a PPA no
[17:13] <rbasak> Maybe the copy-package tool from ubuntu-archive-tools can do it?
[17:14] <dobey> what ppa are you trying to copy from?
[17:14] <simon_weber> this is the particular build I'm looking to copy: https://launchpad.net/~chris-lea/+archive/ubuntu/redis-server/+build/6654221
[17:14] <simon_weber> (yes, I know it's very old, haha)
[17:16] <simon_weber> this seems relevant, maybe? http://askubuntu.com/a/475298
[17:16] <simon_weber> I wasn't able to find the copy-package tool you referenced, rbasak
[17:17] <cjwatson> the "copy packages" web interface has a drop-down that you can switch from "Published" to "Superseded" or similar to find such things
[17:18] <cjwatson> the askubuntu link you found does not seem appropriate here
[17:18] <simon_weber> oh, excellent
[17:18] <simon_weber> let me try that
[17:19] <simon_weber> cjwatson: beautiful, that's exactly what I needed
[17:19] <simon_weber> thanks!
[17:19] <cjwatson> np
[23:41] <clivejo> hi folks, when you are building a package on LP, is there any way to get internet access whilst building?
[23:42] <clivejo> for example can you setup a python env where pip can install the requirements
[23:42] <tsimonq2> clivejo: Nope, I believe that's against Debian's rules for packages
[23:42] <tsimonq2> clivejo: Which, in turn, is probably ours.
[23:43] <tsimonq2> clivejo: You should probably ask the archive admins in #ubuntu-release what they're comfortable with.
[23:56] <maxb> I believe the idea is that if you need internet access, it means the source code isn't entirely represented by what's in the source packages and installed binary packages for dependencies
[23:57] <maxb> And that would be undesirable, so no internet access, to enforce that people don't do it
[23:58] <wgrant> Right, the restriction is in place mostly to ensure that we can't not build a fix just because some upstream website has gone away, or some version of the dependencies has changed.
[23:58] <wgrant> There are also issues around providing source for licenses that require it (eg. GPL)
[23:58] <wgrant> A Debian package build on Launchpad can only depend on other packages, not external resources.
[23:59] <tsimonq2> maxb: Exactly.