[23:53] <Riddelll> if you want more examples of pyqt and pykde apps you can apt-get source python-qt4 which has a bunch of examples
[23:53] <Riddelll> for something more complex look at printer-applet in kdeutils in KDE's svn
[23:54] <Riddelll> or guidance-power-manager in extragear/utils in KDE's svn
[23:54]  * Sundance wonders if it would be considered unwarranted if he also pointed to his own PyQt4 pet project?
[23:55] <Riddelll> Sundance: what is it?
[23:55] <supert0nes> gotta head out but thanks very much Riddelll, you have given me the kickstart necessary on PyQt
[23:55] <Riddelll> oh and if you're looking for a way to contribute back
[23:55] <Riddelll> techbase.kde.org needs pykde tutorials
[23:55] <Riddelll> so you could convert this web browser to a pykde app
[23:55] <Riddelll> and put it on techbase
[23:56] <fliegenderfrosch> Riddelll: What does pykde provide (on top of pyqt)?
[23:56] <dwidmann> I've got spare time ... I could do that unless someone else is more determined to do that than me
[23:56] <Sundance> Riddelll: Just a small MU* client. Nothing spectacular, except that I try to mind the clarity of my code a lot.
[23:56] <Riddelll> fliegenderfrosch: better integration with KDE
[23:56] <Riddelll> it'll pick up the right KDE widget style, and you can use KDE icons
[23:56] <Riddelll> it works with KDE translations too, which are much nicer than Qt's
[23:57] <Riddelll> here's a basic pyKDE app   http://kubuntu.org/~jriddell/tutorials-day/python/hola2-kde.py
[23:58] <fliegenderfrosch> Riddelll: nice, i've got to look at that for my pyqt apps. and with kde4, you don't even lose windows/osx compatibility, right?
[23:58] <nosrednaekim> fliegenderfrosch: no.... but for those I would still reccomend bare qt4
[23:58] <Riddelll> fliegenderfrosch: shouldn't do, although I'm not sure if pykde is working on windows/mac yet
[23:59] <fliegenderfrosch> Riddelll: that doesn't matter, my programs are not even ready for linux users yet...
[23:59] <Riddelll> ok, time up, it would be great if someone did turn this into a tutorial on techbase, let me know if you want to do that


[15:34] <CIA-62> ubiquity: cjwatson * r5463 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py): Pass bytes rather than text to kdecore.ki18n.
[15:37] <CIA-62> ubiquity: cjwatson * r5464 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py):
[15:37] <CIA-62> ubiquity: Call sip.setapi("QVariant", 1) on KDE frontend startup, pending a more
[15:37] <CIA-62> ubiquity: complete port to the new API.
[15:39] <CIA-62> ubiquity: cjwatson * r5465 trunk/ (debian/changelog ubiquity/plugins/ubi-language.py):
[15:39] <CIA-62> ubiquity: Use boolean tests rather than isNull, to cope with getting ordinary
[15:39] <CIA-62> ubiquity: Python strings rather than QStrings.
[15:46] <CIA-62> ubiquity: cjwatson * r5466 trunk/ (3 files in 2 dirs):
[15:46] <CIA-62> ubiquity: In Python 3, pass strings directly to Qt rather than creating
[15:46] <CIA-62> ubiquity: QStrings.


[20:28] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:28] -queuebot:#ubuntu-quality- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200724)
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Base arm64 [Focal 20.04.1] (20200724) has been added
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200724)
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200724)
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200724)
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200724)
[20:29] -queuebot:#ubuntu-quality- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200724)
[20:30] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:32] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:34] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:39] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:40] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:41] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200724)
[20:42] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200724)
[20:42] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200724)
[20:42] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200724)
[20:42] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200724)
[20:46] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200724)


[04:51] <slangasek> why would subsequent invocations of xvfb-run fail on container-based autopkgtest runners, but not the first invocation?  http://autopkgtest.ubuntu.com/packages/p/pytest-qt/artful/s390x http://autopkgtest.ubuntu.com/packages/p/pytest-qt/artful/armhf
[07:57] <xnox> interesting, i wonder if we can get more logs out of the host as to when this happens - e.g. things closed and cleaned and not allowed to be reopened. but that looks really weird. it does not look like multiple xvfb-run are run in parallel as it should exit first.
[07:58] <xnox> it uses the same TMP directory, maybe something needs to be cleaned up and isn't for the subsequent runs?
[07:58] <xnox> this needs a task opened, adding to trello.
[12:02] -queuebot:#ubuntu-release- New binary: network-manager [amd64] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[12:03] -queuebot:#ubuntu-release- New binary: network-manager [s390x] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[12:04] -queuebot:#ubuntu-release- New binary: network-manager [ppc64el] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[12:06] -queuebot:#ubuntu-release- New binary: network-manager [i386] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[12:11] -queuebot:#ubuntu-release- New binary: network-manager [arm64] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[12:11] -queuebot:#ubuntu-release- New binary: network-manager [armhf] (artful-proposed/main) [1.8.0-3ubuntu1] (kubuntu, ubuntu-desktop)
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [amd64] (artful-proposed) [1.8.0-3ubuntu1]
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [armhf] (artful-proposed) [1.8.0-3ubuntu1]
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [ppc64el] (artful-proposed) [1.8.0-3ubuntu1]
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [arm64] (artful-proposed) [1.8.0-3ubuntu1]
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [s390x] (artful-proposed) [1.8.0-3ubuntu1]
[13:32] -queuebot:#ubuntu-release- New: accepted network-manager [i386] (artful-proposed) [1.8.0-3ubuntu1]
[13:54] <Saviq> hi release team :) can someone please have a look at the mir SRUs into xenial, yakkety, zesty - they've been aging for 8 days in -proposed now - thanks!
[14:09]  * apw looks
[14:16] <apw> Saviq, done
[14:16] <Saviq> apw, fantastic, thank you!
[17:09] -queuebot:#ubuntu-release- New binary: haskell-code-page [ppc64el] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: node-raw-loader [amd64] (artful-proposed/universe) [0.5.1-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: pysodium [amd64] (artful-proposed/universe) [0.6.11-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: ruby-useragent [amd64] (artful-proposed/universe) [0.16.8-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: haskell-say [ppc64el] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: ruby-email-reply-trimmer [amd64] (artful-proposed/universe) [0.1.6-1] (no packageset)
[17:09] -queuebot:#ubuntu-release- New binary: printer-driver-oki [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: apertium-spa-ita [amd64] (artful-proposed/universe) [0.2.0~r78826-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: haskell-code-page [i386] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: haskell-typed-process [ppc64el] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: node-enhanced-resolve [amd64] (artful-proposed/universe) [3.1.0-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: golang-github-puerkitobio-goquery [amd64] (artful-proposed/universe) [1.1.0+git20170324.3.ed7d758-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: humanfriendly [amd64] (artful-proposed/universe) [3.2-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: haskell-code-page [s390x] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: parsley-clojure [amd64] (artful-proposed/universe) [0.9.3-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: haskell-say [i386] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: haskell-code-page [amd64] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: haskell-typed-process [i386] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: haskell-typed-process [amd64] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: node-ajv-keywords [amd64] (artful-proposed/universe) [2.1.0-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: haskell-code-page [arm64] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: haskell-code-page [armhf] (artful-proposed/universe) [0.1.3-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: haskell-say [armhf] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: haskell-say [amd64] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: haskell-typed-process [armhf] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New: accepted apertium-spa-ita [amd64] (artful-proposed) [0.2.0~r78826-1]
[17:20] -queuebot:#ubuntu-release- New: accepted golang-github-puerkitobio-goquery [amd64] (artful-proposed) [1.1.0+git20170324.3.ed7d758-1]
[17:20] -queuebot:#ubuntu-release- New: accepted haskell-code-page [arm64] (artful-proposed) [0.1.3-1]
[17:20] -queuebot:#ubuntu-release- New: accepted haskell-code-page [i386] (artful-proposed) [0.1.3-1]
[17:20] -queuebot:#ubuntu-release- New: accepted haskell-code-page [s390x] (artful-proposed) [0.1.3-1]
[17:21] -queuebot:#ubuntu-release- New: accepted haskell-code-page [amd64] (artful-proposed) [0.1.3-1]
[17:21] -queuebot:#ubuntu-release- New: accepted haskell-code-page [ppc64el] (artful-proposed) [0.1.3-1]
[17:21] -queuebot:#ubuntu-release- New: accepted haskell-code-page [armhf] (artful-proposed) [0.1.3-1]
[17:21] -queuebot:#ubuntu-release- New: accepted humanfriendly [amd64] (artful-proposed) [3.2-1]
[17:21] -queuebot:#ubuntu-release- New: accepted node-enhanced-resolve [amd64] (artful-proposed) [3.1.0-1]
[17:21] -queuebot:#ubuntu-release- New: accepted parsley-clojure [amd64] (artful-proposed) [0.9.3-1]
[17:21] -queuebot:#ubuntu-release- New: accepted pysodium [amd64] (artful-proposed) [0.6.11-1]
[17:21] -queuebot:#ubuntu-release- New: accepted ruby-useragent [amd64] (artful-proposed) [0.16.8-1]
[17:21] -queuebot:#ubuntu-release- New: accepted node-ajv-keywords [amd64] (artful-proposed) [2.1.0-1]
[17:21] -queuebot:#ubuntu-release- New: accepted printer-driver-oki [amd64] (artful-proposed) [1.0.1-1]
[17:21] -queuebot:#ubuntu-release- New: accepted node-raw-loader [amd64] (artful-proposed) [0.5.1-1]
[17:21] -queuebot:#ubuntu-release- New: accepted ruby-email-reply-trimmer [amd64] (artful-proposed) [0.1.6-1]
[17:26] -queuebot:#ubuntu-release- New binary: haskell-lambdahack [amd64] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: haskell-lambdahack [ppc64el] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[17:54] -queuebot:#ubuntu-release- New binary: haskell-lambdahack [i386] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[20:45] <tsimonq2> I'm curious why only one of the s390x builders are running right now when the rest are marked as "Idle"...
[20:46] <tsimonq2> s/running/building a package/
[20:46] <tsimonq2> And there's other packages in the queue.
[21:06] <tsimonq2> And now plasma-workspace is stuck where it is.
[21:06] <tsimonq2> cjwatson, wgrant: ^^^
[21:15] <acheronuk> seems a lot of builds have just froze
[21:16] <acheronuk> or appear to have done at least viewing their status, even if they really have not
[21:18]  * acheronuk wonders if tsimonq2 broke launchpad
[21:18]  * tsimonq2 wonders if acheronuk broke Launchpad
[21:18] <tsimonq2> :P
[21:19]  * acheronuk examines the relative probability there
[21:20] <acheronuk> nah, my bet's still on you :P
[21:20] <santa_> hi
[21:20] <tsimonq2> acheronuk: Your CI uploads thousands of packages in a given week, I'll upload maybe 50 on a good week if I'm lucky :P
[21:20]  * tsimonq2 thinks acheronuk has been throwing things at Launchpad!
[21:21] <acheronuk> not many recently. not midnight yet
[21:22] <tsimonq2> lol
[21:22] <santa_> apw, slangasek: thank you very much for looking into our kubuntu's packages. would be possible to ignore the akonadi test failure, so we can see if the rest of kdepim gets out of -proposed? http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.3_artful_proposed_migration.pdf
[21:24] <santa_> we would upload kde applications 17.04.x but I think it would be nice if we get the current 16.12.3 out of proposed before doing that
[21:26] <acheronuk> santa_: it would, but I fear it may need a lot of deleting of old binaries on architectures where PIM now depwaits due to no qtwebengine
[21:27] <acheronuk> or at least I discussed that with apw, and came to that conclusion
[21:27] <Laney> you DoSed the test queues with a version you knew would be obsolete very shortly? :/
[21:28] <slangasek> santa_: my stock answer for "could we ignore autopkgtest failure for <foo>" is "no".  Who is fixing the akonadi tests?
[21:28] <santa_> Laney: the tests were already completed a while ago. in fact the thing was already uploaded a while ago, but some packages were new and they weren't accepted for a while
[21:30] <Laney> santa_: ok, so not the tests that are still draining out now
[21:37] <acheronuk> tsimonq2: gonna give up for tonight I think. LP builds look stuffed
[21:38] <tsimonq2> acheronuk: Ah ok
[21:39] <santa_> slangasek: right now I can't reproduce the akonadi test failures locally, and I think if there's anything to fix, it would be better to fix it in >= 17.04
[21:39] <slangasek> santa_: are we not talking about 17.04 here?
[21:39] <acheronuk> tsimonq2: as soon as I wander off and do something else, it'll probably all fix itself :P
[21:40] <tsimonq2> acheronuk: lol
[21:40] <slangasek> >= 17.04, I mean (17.10)
[21:40] <tsimonq2> acheronuk: I'll ping on Telegram if it gets unclogged
[21:40] <acheronuk> slangasek: that is KDE applications version 17.04. they use a similar versioning scheme to ubuntu for their apps
[21:40] <tsimonq2> Speaking of that, any archive admin know what's up?
[21:41] <slangasek> eh
[21:41] <acheronuk> slangasek: https://www.kde.org/announcements/announce-applications-17.04.0.php
[21:41] <santa_> slangasek: right now we have kde apps 16.12.3 in the archive, I mean if we are going to touch something wrt akonadi it would be better to work on *akonadi* >= 17.04.x
[21:42] <santa_> because this way we would be able to get help from fellow kde developers
[21:42] <slangasek> santa_, acheronuk: no test is better than a useless and constantly failing test.  uploaders have the means to resolve autopkgtest failures without involving the release team, so for me it's a low priority to investigate and override a failure to let things migrate sooner
[21:43] <santa_> slangasek: we could upload a new package version disabling the test in question as a temporary solution then
[21:45] <santa_> acheronuk: ↑
[21:45] <acheronuk> santa_: perhaps, as long as we are testing somewhere outside ubuntu infra in a sane/valid way to confirm they pass in that
[21:46] <acheronuk> past stuff I tested passed locally, or in lxc adt test envs, but oddly failed on ubuntu infra.
[21:47] <acheronuk> ideally would fix everywhere, but don't have infinite time to spend on this
[23:05] <cjwatson> tsimonq2,acheronuk: forked discussion, only replying on #launchpad
[23:08] <tsimonq2> cjwatson: gracias
[23:11] -queuebot:#ubuntu-release- New binary: haskell-lambdahack [armhf] (artful-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20170523-0ubuntu1~17.04.0]
[23:15] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20170523-0ubuntu1~16.10.0]
[23:17] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20170523-0ubuntu1~16.04.0]
[23:18] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20170523-0ubuntu1~14.04.0]
[23:22] -queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (zesty-proposed) [1.138ubuntu5.1]
[23:25] -queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (yakkety-proposed) [1.138ubuntu2.1]
[23:30] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.4]
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted libepoxy [source] (zesty-proposed) [1.3.1-1ubuntu<IP_ADDRESS>]
[23:38] -queuebot:#ubuntu-release- Unapproved: accepted python-fastimport [source] (zesty-proposed) [0.9.6-2ubuntu17.04.1]
[23:40] -queuebot:#ubuntu-release- New binary: iptables [ppc64el] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:41] -queuebot:#ubuntu-release- New binary: iptables [amd64] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:41] -queuebot:#ubuntu-release- New binary: iptables [s390x] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:41] -queuebot:#ubuntu-release- New binary: iptables [i386] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:42] -queuebot:#ubuntu-release- New binary: iptables [arm64] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:42] -queuebot:#ubuntu-release- New binary: iptables [armhf] (artful-proposed/main) [1.6.0+snapshot20161117-6ubuntu1] (core)
[23:45] -queuebot:#ubuntu-release- Unapproved: accepted btrfs-tools [source] (xenial-proposed) [4.4-1ubuntu1]
[23:51] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20170524.0.ea2fe2b0-0ubuntu<IP_ADDRESS>]


[00:59] <ZonkedZebra> Hey. I'm developing a charm and trying to debug one of the hooks. What is the best to recover a node from an error state. According to the docs error state nodes don't run upgrade hooks.
[01:03] <sarnold> ZonkedZebra: I think ssh to the unit, fix it up, and run juju resolved
[01:03] <davecheney> sarnold: ZonkedZebra
[01:04] <davecheney> juju resolved --retry $UNIT && juju debug-hooks $UNIT
[01:04] <davecheney> will retry the failed unit
[01:04] <sarnold> ooh! --retry :) very nice
[01:04] <davecheney> then immediately (before that is actioned) start debug-hooks so you can run the unit yourself
[01:04] <davecheney> s/unit/hook
[01:05] <ZonkedZebra> in the debug-hooks it appears to drop be right before the script is exacted. Is there something functionality there I am missing? tailing /var/log/juju/unit-* has provided the best feedback so far
[01:06] <davecheney> ZonkedZebra: you get to run the hook, debug the hook
[01:06] <davecheney> the name of the hook will be in the $PS1
[01:06] <davecheney> so, if the hook that failed is config-changed
[01:06] <davecheney> at the prompt, type
[01:06] <davecheney> hooks/config-changed
[01:06] <davecheney> see where it breaks
[01:06] <davecheney> fix it
[01:06] <davecheney> run it again
[01:07] <davecheney> when you're happy that it has worked
[01:07] <davecheney> exit 0
[01:07] <davecheney> will take you to the next hook queued
[01:07] <davecheney> when you've processed all the hooks
[01:07] <davecheney> exit the final shell
[01:07] <ZonkedZebra> those changes will be saved on that node?
[01:08] <davecheney> no
[01:08] <davecheney> you will need to apply those changes to your charm
[01:08] <davecheney> then use something like
[01:08] <ZonkedZebra> Interesting, guess I can copy back out when done. I was just updating locally and then upgrading the charm
[01:08] <davecheney> ZonkedZebra: the best mental model of a chamr is to expect them to avaporate at any second
[01:08] <davecheney> any chanes done on the unit themselves are not saved anywhere
[01:09] <ZonkedZebra> davecheney: I can figure that part out :) thanks
[01:19] <davecheney> ZonkedZebra: sorry mate, it wasn't my intention to talk down to you
[01:21] <cespare> (very new to juju -- about 5 min into the docs) does juju set-constraints just change a configuration file?
[01:21] <cespare> I'm trying to understand how all these settings you're making would be shared with your team
[01:21] <cespare> I guess you keep your whole ~/.juju in version control?
[01:22] <davecheney> cespare: yeah, the .juju directory started simple but now contains a lot of files which all need to be on every client
[01:22] <davecheney> we're trying to address this
[01:22] <davecheney> but it won't happen on a timeframe useful to this discussion
[01:22] <cespare> davecheney: ok thanks
[01:23] <cespare> is there a way to use something other than .juju, perhaps with an env variable or something?
[01:23] <freeflying> does ceph charm need a second disk?
[01:24] <davecheney> cespare: you can move the location of JUJU_HOME with that environment variable
[01:24] <davecheney> freeflying: yes
[01:24] <freeflying> davecheney, any particular reason for the second disk? should only ceph-osd need a second disk?
[01:25] <axw> cespare: davecheney's right in general, but set-constraints in particular goes into the state database
[01:25] <cespare> davecheney: ok neato. So is just keeping JUJU_HOME in VC the recommended way of working as a team? The docs feel like they're addressed to a single dev or something
[01:25] <cespare> axw: oh ok, that makes sense
[01:25] <cespare> axw: that's mongo?
[01:25] <axw> yup
[01:26] <davecheney> cespare: i'd say it's a good idea
[01:26] <davecheney> we dont' have a recommendation
[01:26] <cespare> ok
[01:26] <davecheney> the contents of .juju are very much in flxu
[01:26] <davecheney> we konw that we keep too much state on dick
[01:26] <davecheney> err
[01:26] <davecheney> disk
[01:26] <davecheney> and are trying to fix it
[01:27] <davecheney> but it's not top priority compared to other stuff we want to get done
[01:28] <cespare> davecheney: i see. Are you saying that in an ideal world, your .juju would mostly just have enough info to point at the juju configuration server and everything else would be stored there?
[01:30] <davecheney> cespare: bingo
[01:30] <davecheney> would you like a job ?
[01:30] <cespare> Happy with the one I've got, thanks :)
[01:30] <cespare> Plus I could never use bzr for my dayjob. It wouldn't work out.
[01:31] <davecheney> everyone has their price
[01:31] <cespare> can't argue with that
[01:33] <sarnold> hehe
[01:37] <cespare> Is there something I can read about using juju to manage your own application? I suppose it's basically just going to involve writing a charm for it...but what about redeploying it when the code changes, monitoring, logging, etc?
[01:40] <davecheney> cespare: juju is configuration management
[01:40] <davecheney> it doesn't do monitoring or process management
[01:40] <davecheney> what it does do is define a framework for connecting services together
[01:40] <davecheney> the main driver was virtual environments like ec2
[01:40] <davecheney> when the names of the machines are not known ahead of time
[01:41] <cespare> davecheney: ok.
[01:42] <davecheney> process management is always tricky
[01:42] <davecheney> juju doesn't want to be the process manager
[01:42] <cespare> So how would juju help out if, say, I have an application that needs a database. Can I get it to just provision me some machines, and my deploy tool can ask juju for what the latest set of application servers are?
[01:42] <davecheney> ie, we don't want to, and in reality cannot demand that processes do not daemonise themselves
[01:43] <davecheney> cespare: sort of
[01:43] <davecheney> but not relaly
[01:43] <davecheney> juju lets you define an environemnt, a collection of services
[01:43] <cespare> and then I would want juju to invoke my deploy tool if i add more nodes...:\
[01:43] <davecheney> juju is your deploy tool
[01:43] <davecheney> you describe your environment, ie
[01:43] <davecheney> juju deploy wordpress
[01:43] <davecheney> juju deploy mysql
[01:43] <davecheney> juju add-relation wordpress mysql
[01:43] <davecheney> juju expose wordpress
[01:44] <davecheney> you don't describe machines, hosts, networks, firewall ports, etc
[01:44] <cespare> davecheney: that all makes sense. Does juju not help with my application servers at all?
[01:44] <davecheney> cespare: you'd have to be more specific what kind of help you are looking for ?
[01:44] <davecheney> for monitoring we have the idea of subordinate charms
[01:44] <davecheney> which let you descrive things like zenoss and nagios agents
[01:44] <cespare> well, like in my example. I have an application server that I'm hacking on and want to deploy frequently
[01:45] <cespare> (forget about monitoring and stuff for now)
[01:45] <cespare> it connects to a db that I brought up with juju deploy mysql
[01:45] <freeflying> davecheney, can we deploy ceph onto machine which only have 1 disk, and ceph-osd to machine has 2 disks
[01:45] <davecheney> you, you'd describe the process of deploying your application server as a charm
[01:45] <cespare> now, maybe I need to scale up the app server by adding more nodes, or maybe move the db to a different box...does juju do those things?
[01:45] <davecheney> freeflying: no, ceph rquires two luns
[01:46] <davecheney> you need to use constraints to make sure the unit is provisioned on a machine with that disk setup
[01:46] <davecheney> but, regretably,we haven't implemented those constraints yet
[01:46] <davecheney> cespare: juju does those things
[01:46] <freeflying> davecheney, what about ceph-osd then
[01:46] <davecheney> freeflying: that will work
[01:47] <freeflying> davecheney, one disk for osd will be fine?
[01:47] <davecheney> cespare: juju add-unit $SERVICE
[01:47] <davecheney> freeflying: i guess so, isn't it a dashboard or something
[01:47] <davecheney> cespare: juju has the model of one machine per unit of a sevice
[01:47] <cespare> davecheney: ok, so what does deploying version N+1 look like? You build a new version of the charm and then...
[01:47] <davecheney> cespare: you have two options
[01:48] <davecheney> 1. juju upgrade-charm, and write a hooks/upgrade-charm hook that will git pull your code or something
[01:48] <davecheney> or
[01:48] <davecheney> 2. juju destroy-service && juju deploy $SERVICE
[01:48] <davecheney> or juju deploy $SERVICE $NEW_NAME
[01:48] <davecheney> then destroy the old name
[01:49] <cespare> davecheney: do the subordinate charms break from the one machine per unit of service paradigm?
[01:49] <cespare> i.e. can I run the nagios charm with my app server together?
[01:49] <davecheney> cespare: yes
[01:49] <cespare> s/i.e/e.g
[01:49] <cespare> ok thanks
[01:49] <davecheney> cespare: yes, subordinate charms are deployed 'into' the machine that the thing they are subordinate too
[01:49] <davecheney> nagios isn't a subordinate
[01:50] <davecheney> its the server component
[01:50] <cespare> oh, the agent, whatever
[01:50] <davecheney> nagios-nrpe is the agent
[01:50] <cespare> yeah
[01:50] <davecheney> fair warning
[01:50] <davecheney> we understand that the one machine per service unit is a sucky requirement
[01:50] <davecheney> and makes it hard to have 'small' juju environemnts
[01:50] <davecheney> we'er working on fixing that with lxc containers
[01:50] <cespare> davecheney: yeah, saw that in the docs
[01:51] <davecheney> but there are complex problems, mainly around networking in hostile environemnts like ec2 and private openstack clouds which make the problem much harder
[01:51] <cespare> davecheney: sounds good, but actually for our infrastructure we pretty much have a machine per service
[01:51] <cespare> i mean (many) dedicated machines per service
[01:52] <davecheney> cespare: thta is why i say sevice unit
[01:52] <davecheney> the sevice is the abstract idea
[01:52] <davecheney> the unit is the physical manifestation of one instance of that service
[01:52] <cespare> davecheney: when a charm reacts to the upgrade-charm hook is it supposed to transform itself to the same state as if the upgraded charm were deployed to a fresh machine?
[01:53] <cespare> davecheney: good terminology
[01:53] <davecheney> cespare: as the charm author, we push a lot of that work onto you
[01:53] <davecheney> all we do is call the hook and wave our hands that it is your problem to figure out what that means
[01:53] <cespare> right, I'm asking if that's what I'm supposed to do as a good citizen
[01:53] <cespare> ok
[01:54] <davecheney> cespare: there are many ways of skinning the cat
[01:54] <cespare> davecheney: pretty easy if the application is a single jar/go binary
[01:54] <davecheney> you could also use a config variable to define the revision you want to use
[01:54] <davecheney> then your upgrade could be
[01:54] <davecheney> juju set revision=XXX
[01:54] <davecheney> which would fire the hooks/config-changed hook and you could do a git pull
[01:55] <davecheney> leaving upgrade charm to only change the actual code of the hooks/*
[01:55] <cespare> ah
[01:55] <davecheney> cespare: at it's core, juju is two things
[01:55] <davecheney> 1. a generic interface to varoius vm providers
[01:56] <davecheney> 2. a way of scheduling the remote execution of remote commands
[01:56] <davecheney> any assuptoins above and beyond that have to belong with the charm authors
[01:56] <davecheney> (we do push a lot of responsibility to charm authors)
[02:02] <cespare> I wish juju worked on digital ocean, that'd be cool
[02:03] <davecheney> cespare: we're working on a thing called manual provisoining
[02:03] <davecheney> which lets you supply machines via ssh
[02:03] <cespare> ah ok, still totally scriptable though heh
[02:03] <cespare> that would do the trick
[02:03] <davecheney> it's there in tip if you want to try it
[02:04] <davecheney> but not documented because there are a lot of rough edges
[02:05] <cespare> davecheney: thanks for answering all my questions
[02:06] <davecheney> np
[08:10] <jamespage> marcoceppi, please ping me when you start today re charm-tools update
[08:10] <jamespage> marcoceppi, as its pretty much a complete re-write I need more information before I go speak to the release team
[11:48] <AskUbuntu> Set up nodes for Ubuntu cloud 12.04 | http://askubuntu.com/q/349867
[13:18] <AskUbuntu> Error on juju configuration for maas | http://askubuntu.com/q/349892
[13:34] <marcoceppi> jamespage: ping
[13:34] <jamespage> hey marcoceppi
[13:35] <jamespage> marcoceppi, so a few questions re cloud-tools 1.0.0 if you have time
[13:35] <marcoceppi> jamespage: I've got all the time in the world for this
[13:35] <jamespage> marcoceppi, OK _ so I pulled the packages from the PPA and merged them into the main packaging branch in ubuntu
[13:35] <jamespage> then restored a few files under debian/* that had got dropped
[13:36] <jamespage> 1.0.0 is a complete rewrite in python right?
[13:36] <marcoceppi> jamespage: correct, the code is rewritten, the packagining is re-done, and the structure of the package changed
[13:37] <jamespage> marcoceppi, so the rationale is really about supporability going fowards right?
[13:38] <jamespage> as the current package is a mix of bash/python and not actively developed
[13:38] <marcoceppi> jamespage: the current package, 0.3, is no longer maintained. The re-write was to make charm-tools multi-platform and bring it's quality up
[13:49] <jamespage> marcoceppi, OK
[13:57] <ehw> hey, guys, is there any way to tell juju which lxc bridge name it should be using?  lxc works fine, but juju is failing with the net device not found error
[14:05] <marcoceppi> ehw: not that I know of, let me dig through the environments.yaml options
[14:08] <ehw> marcoceppi: thanks; was looking through the source, but it hasn't got any clearer for me
[14:09] <marcoceppi> ehw: there's two places for config options, one is in the providers code itself, then there's like this global options file that is env.yaml options for all environments
[14:13] <marcoceppi> ehw: it looks like there's an "JUJU_LXC_BRIDGE" environment variable you can set during bootstrap
[14:13] <marcoceppi> let me dig a little more
[14:13] <marcoceppi> ehw: oh, wait, that's for something different
[14:14] <ehw> marcoceppi: yeah, just tried that, didn't seem to get me what I needed
[14:14] <marcoceppi> ehw: line 42 of provider/local/environ.go has it hard-coded `const lxcBridgeName = "lxcbr0"`
[14:15] <marcoceppi> ehw: if you wanted that to be configurable, which isn't out of reason, you'd need to open a bug https://bugs.launchpad.net/juju-core
[14:15] <ehw> marcoceppi: yeah, looks like I'll be doing that
[14:17] <adeuring> marcoceppi: could you please have a look here: https://code.launchpad.net/~adeuring/charm-tools/python-port-check-config/+merge/186080 ?
[14:18] <marcoceppi> adeuring: sure can!
[14:18] <adeuring> thanks!
[14:18] <marcoceppi> adeuring: while you're here
[14:19] <marcoceppi> REQUIRED_OPTION_KEYS = set(('description', )) - description is the only req key? I thought type was as well?
[14:21] <adeuring> marcoceppi: http://bazaar.launchpad.net/~charmers/juju/docs/view/head:/source/service-config.rst says that "str" is the default type. so I assume that is not need to be specified (well, unless you want an int or float)
[14:21] <marcoceppi> adeuring: ah, gotchya, thanks
[14:29] <ehw> marcoceppi: done.   pad.lv/1230306
[16:03] <marcoceppi> Charm call, http://ubuntuonair.com and http://pad.ubuntu.com/7mf2jvKXNa
[16:14] <mattyw> I can't see anything on ubuntuonair?
[16:16] <marcoceppi> mattyw: http://www.youtube.com/watch?v=UPUO62DQiuw&feature=youtu.be
[16:17] <mattyw> marcoceppi, much better tnanks :)
[16:20] <mattyw> jcastro, can I ask some more questions?
[16:20] <mattyw> I know you love it
[16:23] <jcastro> sure!
[16:23] <jcastro> keep on keeping on!
[16:28] <mattyw> These pages: https://jujucharms.com/fullscreen/search/~mattyw/precise/docker-3/?text=docker
[16:28] <mattyw> how do they get generated? I expected them to update if I updated the charm - or after some interval - but they don't
[16:29] <mattyw> my 2nd question is: this is what I'm doing with the config http://bazaar.launchpad.net/~mattyw/charms/precise/docker/trunk/view/head:/hooks/config-changed. but it's not really config. is this how the framwork charms work at the moment?
[16:41] <mattyw> jcastro, I think that's all my questions actually
[16:43] <jcastro> the pages are generated ... nightly I think? rick_h_ do you know the interval?
[16:43] <jcastro> marcoceppi can answer the 2nd one
[16:46] <marcoceppi> mattyw: that hook looks fine. a lot of my charms do things like that in the conduit changed hook
[16:46] <mattyw> marcoceppi, ok cool, glad I get the basic idea
[16:47] <marcoceppi> config*
[16:50] <marcoceppi> jcastro: I think we did the charm call to soon?
[16:53] <jcastro> no it's always been at this time
[16:53] <jcastro> I just moved it to thr wrong spot
[16:56] <jcastro> fixed, thanks
[17:58] <jcastro> http://highscalability.com/blog/2013/9/25/great-open-source-solution-for-boring-ha-and-scalability-pro.html
[17:58] <jcastro> share/tweet/reddit/whatever please!
[19:11] <Cobold> Hi all!
[19:56] <AskUbuntu> Is there a juju PostGIS charm out there? | http://askubuntu.com/q/350035
[20:16] <jcastro> hey popey
[20:20] <jcastro> huh
[20:20] <jcastro> hey guys check this out
[20:20] <jcastro> http://code.scenzgrid.org/index.php/p/jujucharms/
[20:21] <jcastro> http://code.scenzgrid.org/index.php/p/jujucharms/source/tree/f906376d2ecba34e82e15b1e558e1b9e3c4d4ea1/postgis/precise/postgis/README
[21:57] <rick_h_> jcastro: used to be about every 15min


[11:51] <mtaylor> anybody around?
[11:52] <mtaylor> I'm trying to track down figuring out java info for an autoconf script...


[01:43] <thumper> rockstar: still there?
[01:49] <rockstar> thumper, yes.
[01:50] <rockstar> (for various definitions of the word "there")
[01:50] <thumper> did you work out the upgrade branches issue?
[01:52] <rockstar> thumper, no.  I started looking through logs but then got distracted by an actual ec2 email (!)
[01:52] <thumper> ok
[01:52] <rockstar> ...and now I seem to have lost my connection to devpad and cannot reconnect.
[01:52] <rockstar> ssh: Could not resolve hostname chinstrap.canonical.com: Temporary failure in name resolution
[01:53] <rockstar> wtf?
[01:54] <thumper> we need a losa query to work out which upgrade branch is in progress
[01:54] <thumper> because it isn't being logged
[01:59] <thumper> sinzui: I don't suppose you can take a 5 minutes call?
[02:00] <sinzui> thumper, I do
[05:19] <lifeless> moinish
[06:02] <thumper> lifeless: hi
[06:03] <thumper> anyone remember how to get a vocabulary from a name?
[06:09] <StevenK> maxb: They are caused by the same issue.
[06:13]  * thumper is hanging out for the day to end
[06:14] <thumper> almost got this bug fixed
[06:14] <thumper> StevenK: how are you enjoying soyuz?
[06:15] <StevenK> thumper: It's challenging, but I'm enjoying it
[06:18] <stub> thumper: They are named utilities IIRC, so getUtility(IVocabulary, 'foo') (not sure if that is the real interface to use)
[06:18] <thumper> stub: thanks, but I've got it now
[06:18] <thumper> stub: I've avoided the need :)
[06:19] <stub> IVocabularyFactory looks like... anyway.
[06:19] <thumper> stub: I don't suppose there is a way to replace the vocabulary being used in form_fields easily is there?
[06:20]  * thumper fires up pdb again
[06:21] <stub> thumper: I think you create a new interface and override that attribute. Not sure.
[06:21] <thumper> hmm
[06:22] <thumper> I have to do it somewhat dynamically
[06:22] <thumper> it seems I have to do the form_fields.omit, then add the new one
[06:22] <thumper> I was just wondering if there was a short circuit
[06:22] <thumper> although I feel that the underlying fields that are being referenced are exactly that, references
[06:22] <thumper> and changing the vocabulary could be hazardous
[06:50] <jtv> stub: thanks, your help got me a lot further.  Added comments to bug 388997.
[06:50] <mup> Bug #388997: +imports page should handle URL "hacks" more gracefully, instead of OOPS with LookupError <oops> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/388997>
[06:51]  * thumper EODs
[06:52] <jtv> g'night thumper
[06:53] <jtv> danilos: that branch for setting BuildQueue.processor looks good to me... what work does it still need?
[06:53] <danilos> jtv, QA :)
[06:53] <jtv> pah
[06:54] <danilos> jtv, well, I'd like to QA it before I get it landed :)
[06:54] <jtv> sissy
[06:56] <jtv> danilos: two separate issues there afaics...  is the branch good, and does it solve the problem.  As part of the former, I can give you a review now.
[06:56] <danilos> jtv, heh, certainly then :)
[10:16] <wgrant> bigjools: Can I get a full publisher log at some point? The last one was truncated early on.
[10:24] <bigjools> wgrant: ppa or ubuntu?
[10:24] <wgrant> bigjools: The latter.
[10:24] <wgrant> (the former I can't really see, since it is full of private stuff)
[10:24] <wgrant> (and the latter is the one that is really really really slow)
[10:37] <wgrant> bigjools: I know how that build go corrupted yesterday.
[10:37] <wgrant> The one where the build was 'Needs building', but the job was FAILED.
[10:37] <wgrant> There's a bug in the abort handler.
[13:18] <ghostoyo> hi
[13:19] <ghostoyo> i would like have some help about installing launchpad
[13:20] <mars> Hi ghostoyo.  I might be able to help.  What is the problem?
[13:21] <ghostoyo> i have install bzr
[13:21] <ghostoyo> then i launch the script rocketfuel-setup
[13:22] <ghostoyo> i have an error : ERROR: The user root has not registered any SSH keys with Launchpad.
[13:23] <ghostoyo> then i have a question i must to give some keys but i donnu which
[13:23] <mars> ghostoyo, what do you see when you type "bzr whoami"?
[13:23] <ghostoyo> root <root@lxc-vz2>
[13:23] <mars> ghostoyo, and have you set up a launchpad account?
[13:24] <ghostoyo> yes i have a launchpad account
[13:25] <mars> ghostoyo, and "bzr launchpad-login" shows the correct user?
[13:25] <ghostoyo> no it's not the same
[13:25] <mars> well, it should be your launchpad username
[13:26] <mars> one is the account that will be signing the commits
[13:26] <mars> the other is the account that communicates with launchpad
[13:26] <ghostoyo> No Launchpad user ID configured.
[13:27] <ghostoyo> how i can configure a account ?
[13:28] <mars> ghostoyo, if you have a launchpad account set up, just type "bzr launchpad-login whatevermylpaccountnameis"
[13:30] <ghostoyo> it say me that i am not registered
[13:31] <mars> ghostoyo, could you tell me your Launchpad account name, so I can look it up?
[13:31] <ghostoyo> Ghostoyo :)
[13:35] <ghostoyo> did you found me?
[13:35] <mars> ghostoyo, I'm reading the source for rocketfuel-setup, and it says that the error can be ignored.  When you ran it, did the script continue despite the error?
[13:36] <ghostoyo> yes but then i have a ask about som keys
[13:36] <wgrant> You probably shouldn't be running rocketfuel-setup as root.
[13:36] <wgrant> It's not designed for that, and probably hasn't been tested.
[13:36] <ghostoyo> have u succed in install it?
[13:36] <wgrant> Yes, as my own user.
[13:37] <mars> ghostoyo, I just checked on launchpad for "https://edge.launchpad.net/~Ghostoyo", and there is not account there.
[13:37] <ghostoyo> i launch the script and give you exactly the message
[13:37] <wgrant> Does it cause an error?
[13:37] <wgrant> It should work even without keys.
[13:37] <mars> correct
[13:37] <ghostoyo> ok i will try
[13:38] <ghostoyo> https://launchpad.net/~milot-jean
[13:38] <maxb> ghostoyo: Please confirm you're not running any of this as root any more
[13:38] <ghostoyo> yes i'm root
[13:39] <maxb> Well, that is incorrect
[13:40] <ghostoyo> sorry ?
[13:40] <maxb> You should NOT be setting up Launchpad as root
[13:41] <ghostoyo> ok
[13:42] <maxb> Also, when you say you want to "install" launchpad, you do realize that what you are doing is setting up a Launchpad *development* environment, *not* installing Launchpad for production usage?
[13:43] <ghostoyo> yes
[13:45] <mars> ghostoyo, when you run the rocketfuel-setup script (as a user account, your own or a new one like /home/launchpad), the script will ask you for your Launchpad username.  Type 'milot-jean' when it does.
[13:46] <ghostoyo> yes i do
[14:05] <mars> ghostoyo, it should work then.  You can try adding "set -x" to the top of the script, and it will print out each command as it is executed.  You can then tell us the line with errors if it happens again.
[14:15] <mars> gary_poster, should zc.buildout projects still have the "import ez_setup" line at the top of their setup.py file?
[14:16] <mars> gary_poster, I'm noticing that lazr-js uses "import distribute_setup" instead.  That dies horribly when you then try to run "bin/py setup.py"
[14:16] <gary_poster> mars, that and other changes I now regard as mistakes.  I tried to make changes so a non-buildout workflow would still be possible  It made things messier than necessary for little to no benefit.  So IOW, "no" is fine.
[14:16] <mars> good!
[14:17] <mars> that is a nice answer :)
[14:19] <mars> gary_poster, fwiw, I noticed that 1.5.0b1 also fails in isolating lazr-js from the base system when you set install-from-cache with the default setting.
[14:20] <mars> gary_poster, it picks zope.interface 3.5.1 from dist-packages, then dies.  What it /should/ do is look on PyPI for 3.5.3 and download it into the global .buildout/ cache.
[14:22] <mars> gary_poster, I suspect that there is a new "buildout way" for 1.5.0, one that uses nice things like the global cache, and that lazr-js does not follow it.  Pain ensues.
[14:24] <gary_poster> mars, ah, yes!
[14:24] <gary_poster> mars, is there a branch I can see?
[14:24] <gary_poster> the easy answer is this:
[14:24] <mars> gary_poster, lp:lazr-js/1.0
[14:24] <gary_poster> for scripts, instead of using the zc.recipe.egg recipe in buildout.cfg, use z3c.recipe.scripts
[14:24] <gary_poster> that should be it
[14:25] <mars> subtle
[14:25] <gary_poster> Some recipes still need to use the new approach, so they still may be problematic
[14:25] <gary_poster> mars, I guess yes.  I felt it was important to provide full backwards compatibility
[14:25] <mars> I agree
[14:26] <mars> it is subtle because it is not obvious that I need to change the buildout.cfg recipe in order to use the new buildout cache, and to fix the isolation problem.
[14:26] <mars> gary_poster, given that there is a new "buildout way", and upgrade guide or cheatsheet may be in order.
[14:29] <gary_poster> mars, agreed about the lack of obviousness. :-/  in the same vein as the discussion we had aboutan "opinionated" buildout, I thought it might be nice to have a bootstrap (or some other script) that would give you a buildout directory set up the opinionatedly-correct way.  Something much lighter weight than the lazy.yourpackage thing, but a similar way to get started.
[14:29] <gary_poster> s/discussion we had aboutan "opinionated" buildout/discussion we had about an "opinionated" bootstrap/
[14:30] <mars> right
[14:32] <ghostoyo> the message : Fetching revisions:Inserting missing keys:
[14:33] <ghostoyo> what i must to enter ?
[15:31] <cody-somerville> sinzui, https://launchpad.net/live-installer
[15:32] <cody-somerville> sinzui, Why doesn't launchpad suggest the 'live-installer' package under 'Packages in Ubuntu' section?
[15:33] <sinzui> Usually because live-installer is not published in Maverick
[15:33] <sinzui> cody-somerville, it may have matched, but we limit the matches to 8
[15:34] <cody-somerville> It is published.
[15:34] <sinzui> cody-somerville, I think the latter is the case here
[15:34] <cody-somerville> me too
[15:34] <cody-somerville> Should I file a bug?
[15:35] <sinzui> Lp is search DistributionSourcePackageCache. It looks like the method does not give precedence to exact matches
[15:35]  * cody-somerville nods.
[15:36] <cody-somerville> sinzui, Also, can I have maintainership of the live-installer project on launchpad? I maintain the package in Ubuntu and participate upstream as well.
[15:37] <sinzui> cody-somerville, you need to ask Mantas Kriaučiūnas, if he never replied a Launchpad admin can give it you
[15:37]  * sinzui has a plan to let registry administrators do this too
[17:12] <mars> EdwinGrubbs, ping, were we supposed to nuke the apidoc dirctory in r10865 ?
[17:18] <mars> EdwinGrubbs, the $(API_INDEX) target in the Makefile still depends on that directory existing in source control.  If you want, I can make it into a generated target instead of a checked-in one if the deletion was intentional.
[17:28] <EdwinGrubbs> mars, I'm looking at that revision now.
[18:56] <pabelanger> I'm testing out launchpad from ~/launchpad/lp-branches/devel, but can't locate etc/zope.conf to disable Developer mode
[19:24] <maxb> Why would you want to disable developer mode?
[19:31] <pabelanger> to see how much faster it is
[19:52] <mars> flacoste, ping
[20:00] <mars> flacoste, unping
[20:20] <mars> gary_poster, do you know where in the test suite an expensive functional test for test_on_merge.py might go?
[20:21] <gary_poster> mars on call
[20:21] <mars> k
[20:45] <sinzui> gary_poster, ping
[20:46] <gary_poster> sinzui on call
[20:46] <sinzui> notes
[20:46] <sinzui> noted
[21:47] <gary_poster> mars, um....canonical.launchpad.scripts.tests ?
[21:48] <gary_poster> sinzui, pong
[21:49] <mars> gary_poster, I was looking for something under lib/lp/ actually.  I think lib/lp/scripts/tests/ or lib/lp/testing/tests/ may work.
[21:49] <mars> gary_poster, it is slightly complicated by the fact we do not distinguish between unit tests and functional/integration tests, but oh well.
[21:50] <gary_poster> mars, sounds fine.  "expensive" should give the build engineer pause, I would think, but I expect it's a tricky balance?
[21:50] <mars> I prefer not to touch lib/canonical/... for new code.  There are 6? scattered directories under there with some sort of 'test' in the name.
[21:51] <mars> gary_poster, expensive because it involves IPC and a one second timeout.  IPC means it is not a unit test.
[21:51] <gary_poster> mars, ah ok
[22:24] <creatix> http://tinychat.com/pugquit
[22:26] <thumper> creatix: irc spam?  please don't


[11:12] <Dutchman> Hello, does anyone have experiance with Ubuntu server 7.0.4 and an Hyperthreading CPU ? My system only recognize 1 core but HT is enabled ...
[11:18] <Dutchman> Hmm no1 :(
[11:35] <dendrobates> bug 306571
[11:50] <AlexC_> bje: hey there,
[03:27] <Emilinux> nickserv
[04:07] <Emilinux> ns/ register 00ubuntu00<EMAIL_ADDRESS>[04:08] <mralphabet> o0
[04:08] <Kamping_Kaiser> oops
[04:08] <nealmcb> !bug 306571
[04:24] <Emilinux> I want to sent mail from a bash script without installing a mail server like postfix or other mail server. IT's possible?
[04:25] <Emilinux> HI
[04:25] <ivoks> yes
[04:25] <ivoks> with telnet :)
[04:26] <ivoks> you need relay mail server
[04:27] <Emilinux> which one do you suggest?
[04:28] <ivoks> that deppends on your ISP
[04:28] <ivoks> your ISP has mail server which users of that ISP can use
[04:29] <ivoks> for example, for eutelia.it, it's smtp-in.eutelia.it
[04:31] <Emilinux> ok, but I have to use Telnet, right?
[04:32] <ivoks> no, i've never tried doing that in bash
[04:33] <ivoks> you can use mutt, iirc
[04:33] <ivoks> i don't remember if you could script it in bash
[04:35] <ivoks> mutt also depends on /usr/sbin/sendmail :/
[04:36] <Emilinux> I see
[04:36] <ivoks> if you know perl, there is libmail-sendmail-perl
[04:38] <Emilinux> no I don't know per but I will try, I had just consider perl solution
[04:38] <ivoks> you can do it in python too :)
[04:38] <Emilinux> What is most secure, install sendail or Perl compiler?
[04:39] <ivoks> perl isn't a compiler
[04:39] <ivoks> it's parser
[04:39] <Emilinux> perdon parser
[04:39] <ivoks> you just want to send mail from that machine?
[04:40] <Emilinux> yes just send for log
[04:40] <ivoks> if that's true, you don't need MTA (postfix/sendmail/exim); if i were you, i would do it with python
[04:41] <ivoks> there is even example in /usr/share/doc/python-twisted-mail/examples
[04:41] <Emilinux> ok thank you I will try
[04:42] <lcdd> erm. i'd imagine there are about bazillion existing programs that do exactly this
[04:42] <ivoks> like logcheck :)
[04:44] <Emilinux> Let'me see
[04:44] <lcdd> apt-cache finds ssmtp, nullmailer, nbsmtp, esmtp-run ...
[04:45] <ivoks> oh, you meant fake MTAs
[04:46] <lcdd> i think they might suit the situation well
[04:46] <Emilinux> now I have a lot to do thank you


[00:02] <SpamapS> hazmat: quite common
[00:02] <SpamapS> hazmat: it actually will come back.. you have to wait for whatever giant operation (probably an image upload) completes
[00:02]  * SpamapS decides its time to call it a day.
[00:26] <hazmat> bcsaller1, is the lxc-lib branch ready to go back into review?
[00:35] <bcsaller1> hazmat: I think I can mark it again, yeah
[00:37] <_mup_> ensemble/local-ubuntu-provider r331 committed by<EMAIL_ADDRESS>[00:37] <_mup_> classify managed zk, add missing test package module
[01:17] <_mup_> ensemble/local-ubuntu-provider r332 committed by<EMAIL_ADDRESS>[01:17] <_mup_> refactor file storage out of dummy into common for lxc reuse
[01:18] <_mup_> ensemble/local-ubuntu-provider r333 committed by<EMAIL_ADDRESS>[01:18] <_mup_> switch lxc provider over to using providers.common.files
[01:38] <_mup_> ensemble/local-ubuntu-provider r334 committed by<EMAIL_ADDRESS>[01:38] <_mup_> local machine using /proc/uptime for launch time
[13:59] <wrtp> niemeyer: hiya
[13:59] <niemeyer> wrtp: Hey!
[14:43] <fwereade> niemeyer: https://code.launchpad.net/~niemeyer/ensemble/go-final-formula-meta/+merge/73304
[14:44] <fwereade> niemeyer: is the testrepo copied from the python one? and if so, why?
[14:44] <niemeyer> fwereade: It is.. and I don't get the question
[14:45] <fwereade> niemeyer: there seem to be redundant formulas
[14:45] <fwereade> niemeyer: it feels to me as if either the go and the python ones are conceptually different -- in which case we don't need the extra formulas like mysql2
[14:46] <fwereade> niemeyer: ...or fundamentally the same, in which case I feel nervous about the lack of any mechanism to keep them the same
[14:46] <fwereade> niemeyer: does that make more sense?
[14:46] <niemeyer> fwereade: It does, thanks
[14:47] <niemeyer> fwereade: There's so such thing as "Go formula" and "Python formula"
[14:47] <niemeyer> fwereade: There is "Ensemble formula" only
[14:47] <fwereade> niemeyer: indeed
[14:47] <niemeyer> fwereade: The repository there contains example Ensemble formulas for test purposes
[14:47] <Daviey> What would be a good formula to be beta 1 QA Guinea pig?  Ideally expected to work on bare metal.. OpenStack formula is too complicated for the QA team to scratch for this.
[14:48] <niemeyer> fwereade: We have two self-contained repositories.. one with a Python implementation, and one with a Go implementation
[14:48] <fwereade> niemeyer: understood
[14:48] <niemeyer> fwereade: I'm not sure about what's your proposal.. are you suggesting we should merge both repositories in a single one?
[14:49] <niemeyer> Daviey: Hmm
[14:49] <niemeyer> SpamapS: any suggestions?
[14:51] <fwereade> niemeyer: ...maybe -- I'm not really proposing anything so much as talking in the hope that I can feel comfortable with a verdict on the review
[14:51] <m_3> Daviey: anything will do.... mysql and mediawiki have the most history, but hadoop-master/slave are easy to install and more apropos to the openstack demo atm
[14:52] <Daviey> m_3: Hmm.. mysql and mediawiki might be easier for someone that doesn't have prior experience with hadoop?
[14:53] <niemeyer> fwereade: No worries really.. I'm just explaining the problem we have
[14:53] <niemeyer> fwereade: and trying to investigate if you have anything in mind :)
[14:53] <fwereade> niemeyer: I guess I would be happier if we had a common place for common stuff
[14:54] <niemeyer> fwereade: What's the problem you have in mind?
[14:54] <m_3> Daviey: sure... there're more moving parts with the mysql/mediawiki... hadoop has a little more of a mem requirement too
[14:55] <Daviey> m_3: I'll present them as either/or then :)
[14:55] <Daviey> thanks
[14:55] <fwereade> niemeyer: just that someone will, sooner or later, change one but not the other, and I'm not sure what the worst possible consequences could be
[14:55] <niemeyer> Daviey, m_3: Hadoop feels sexy, if nothing else :)
[14:55] <m_3> Daviey: sure... hadoop's easy though... we have several blog posts about using it with ensemble in cloud.ubuntu.com
[14:55] <m_3> certainly has all the buzz
[14:56] <niemeyer> fwereade: That's a critical point we have to watch out for that indeed
[14:56] <niemeyer> s/for that/for/
[14:57] <Daviey> niemeyer / m_3: Heh.. Ok.. Someone might want to have a chat with hggdh about QA effort ongoing. :)
[14:57] <niemeyer> fwereade: The test repository feels pretty minor, though
[14:57] <niemeyer> Daviey: Superb!
[14:57] <niemeyer> fwereade: This is a real issue across the board
[14:57] <niemeyer> fwereade: We are effectively duplicating logic
[14:57] <fwereade> niemeyer: true, but the test repo will be the second thing I approve which could drift out of sync, and I don't want that to become a habit ;)
[14:57] <niemeyer> fwereade: I'm not sure the burden of separating out into different repositories pays off
[14:58] <niemeyer> fwereade: Given that we'll still have the burden either way
[14:58] <niemeyer> fwereade: Care from coders and reviewers is necessary
[14:58] <niemeyer> fwereade: Heh..
[14:58] <niemeyer> fwereade: Every single line in that source code can drift out of sync
[14:59] <niemeyer> fwereade: The real solution for that is to finish the port.
[14:59] <fwereade> niemeyer: heh, yes
[14:59] <niemeyer> fwereade: After thinking some more, I also don't feel good about the suggestion of having a metadata format that is common for both
[15:00] <niemeyer> fwereade: for syncing up the schema
[15:00] <niemeyer> fwereade: Because that's _increasing_ the problem
[15:00] <niemeyer> fwereade: You're basically pushing the problem to a different level
[15:00] <niemeyer> fwereade: We'd have to develop a schema metadata format (a schema schema!)
[15:00] <niemeyer> fwereade: and a parser, etc
[15:00] <niemeyer> fwereade: and _that_ would have to stay in sync
[15:01] <niemeyer> fwereade: Doesn't feel like it'd pay off
[15:01] <fwereade> niemeyer: well, I never proposed that :)
[15:01] <niemeyer> fwereade: I think you did?
[15:01] <fwereade> niemeyer: not exactly
[15:02] <fwereade> niemeyer: well, ok, I did :/ ...but I'm not convinced it actually makes the problem worse
[15:02] <niemeyer> fwereade: "A language-agnostic schema format (where we define any given schema OAOO, and load it in both Go and Python) would solve the second problem."
[15:02] <niemeyer> https://bugs.launchpad.net/ensemble/+bug/833906
[15:02] <_mup_> Bug #833906: go and python schema implementations could drift out of sync <Ensemble:New> < https://launchpad.net/bugs/833906 >
[15:03] <niemeyer> fwereade: That's a schema schema
[15:03] <fwereade> niemeyer: hmm, I wrote it badly: I mentioned that, and went on to describe something similar but less heavyweight
[15:04] <niemeyer> fwereade: The schema is in place.. formula metadata is in review
[15:04] <niemeyer> fwereade: Very small amount of code
[15:04] <fwereade> niemeyer: just a common way of specifying tests -- ie we keep schemas native and readable, but ensure we're running the same tests for each implementation
[15:05] <niemeyer> fwereade: Diving into a significantly more complex implementation in *both* languages to solve a drift-away problem feels like going into the opposite direction
[15:05] <fwereade> niemeyer: I don't believe that what we have is unworkable, otherwise I'd be making a lot more noise about it
[15:06] <fwereade> niemeyer: but I'm fretting that the amount of things we need to remember to keep in sync will grow and grow
[15:06] <niemeyer> fwereade: Again, the way to avoid that is to not have duplication
[15:06] <niemeyer> fwereade: You seem to be worried about the metadata, but that's the simplest case
[15:06] <niemeyer> fwereade: Just cp -a solves it..  the real problem is in logic
[15:07] <niemeyer> fwereade: I'm also concerned for sure, but I'm more concerned about logic and thinking about approaches to solve that
[15:07] <fwereade> niemeyer: I'm worried about the duplication, and the metadata is what set me off :)
[15:08] <niemeyer> fwereade: That's what I just said I think
[15:08] <niemeyer> fwereade: I want help on that.. how can we avoid duplication of _logic_
[15:09] <fwereade> niemeyer: clearly we need a third language, which will generate both go and python for us
[15:09]  * fwereade ducks
[15:09] <niemeyer> LOL
[15:09] <niemeyer> fwereade: The interesting thing is that this is exactly what the bug above is about ;-)
[15:10] <fwereade> niemeyer: kind of, I don't think I've expressed myself very effectively there, I might have another go at it in a little while
[15:10] <fwereade> niemeyer: anyway, thanks for the discussion, my nerves are soothed ;)
[15:11] <niemeyer> fwereade: :-)
[15:11] <niemeyer> fwereade: Mine are not.. I'm still concerned about duplication
[15:12] <niemeyer> fwereade: I just don't see a big deal in test data.. this can easily be copied
[15:12] <fwereade> niemeyer: I'm still worried about that, but I'm reassured that you are too
[15:12] <niemeyer> fwereade: I've been thinking about potential ways to speed up a migration
[15:13] <niemeyer> fwereade: The real solution would really be to finish the port
[15:13] <niemeyer> fwereade: We can have intermediate wins, though
[15:14] <niemeyer> fwereade: and port bits in a way we can kill the other side
[15:14] <niemeyer> fwereade: I have also been thinking about the possibility of _integrating_ both ports (!)
[15:14] <niemeyer> fwereade: There may be a way to do it nicely
[15:15] <niemeyer> fwereade: and I want to talk to you about that at some point.. I know you've made some very interesting work on that area before
[15:15] <fwereade> niemeyer: hmm, that does sound interesting actually
[15:15] <hazmat> gopython ?
[15:15] <niemeyer> hazmat: Yep :)
[15:15] <niemeyer> fwereade, hazmat: http://labix.org/lunatic-python
[15:16] <fwereade> niemeyer: nice :D
[15:16] <niemeyer> I'm still not entirely sure about it, since it might get so involved that simply porting things over could be easier/faster/simpler
[15:17] <niemeyer> But, it's an idea..
[15:18] <fwereade> niemeyer: > =python.eval("lua.eval('python.eval(\"lua.eval(\\'t\\')\")')")
[15:18] <fwereade> niemeyer: you're clearly insane :)
[15:18] <niemeyer> fwereade: Yeah, it's sick, I know :-)
[15:18] <fwereade> niemeyer: (but in a good way ;))
[15:23] <SpamapS> niemeyer: re suggestions for a formula.. I'm particularly fond of /usr/share/principia/tests/mediawiki.sh from principia-tools. :)
[15:23] <niemeyer> SpamapS: Sounds good
[15:25] <SpamapS> for bare metal that might be too many machines tho
[15:28] <SpamapS> Daviey: re QA effort.. I've been writing automted tests for the wordpress/mysql example on EC2 and working on the mediawiki example as well. Maybe hggdb can use my scripts?
[15:28] <SpamapS> hggdh even :-P
[15:29] <Daviey> SpamapS: -> #ubuntu-testing ?
[15:29] <SpamapS> Man.. I gotta /part some channels and close some query windows.. I'm at 106 open.
[15:31] <Daviey> 106.. is that all? :)
[15:33] <_mup_> Bug #837476 was filed: python2.6: /usr/lib/pymodules/python2.6/ensemble/providers/ec2/files.py:8: DeprecationWarning: the sha module is deprecated <Ensemble:New> < https://launchpad.net/bugs/837476 >
[15:52] <_mup_> ensemble/local-ubuntu-provider r335 committed by<EMAIL_ADDRESS>[15:52] <_mup_> pull ability to use release tarballs and src builds of zk from tests/common.py
[15:55] <hazmat> SpamapS, interesting it doesn't do the same under 2.7
[16:02] <SpamapS> hazmat: yep totally weird
[16:02] <SpamapS> hazmat: further, python2.6 can't run the test suite.
[16:03] <SpamapS> http://paste.ubuntu.com/678082/
[16:04] <SpamapS> Tho I'm pretty sure thats my fault ;)
[16:04] <hazmat> SpamapS, easy enough to fix though
[16:04] <SpamapS> agreed
[16:06] <niemeyer> Lunch time..
[16:15] <_mup_> ensemble/local-ubuntu-provider r336 committed by<EMAIL_ADDRESS>[16:15] <_mup_> switch test runner to using lib/zookeeper
[16:16] <SpamapS> FAILED (failures=5, errors=8, successes=1417)
[16:16] <SpamapS> Clearly we haven't been running the test suite against python 2.6
[16:18] <m_3> SpamapS: we mentioned the other day freezing ensemble at something like 305 for oneiric?
[16:19] <m_3> there're changes in 326 that/re critical for config.yaml
[16:19] <SpamapS> 306 is the version in Oneiric
[16:20] <m_3> can we make an exception?
[16:20] <SpamapS> If it fixes a critical bug I can either cherry pick it in or go ahead and do a FFE
[16:20] <m_3> either cherr
[16:20] <m_3> gotcha
[16:20] <m_3> it's pretty important... config.yaml defaults aren't picked up until then
[16:20] <SpamapS> got a bug reference I can mark it as affecting the package (helps build the case for the FFE)
[16:20] <m_3> so every formula that has a config.yaml requires you to pass a --config
[16:20] <SpamapS> not that we have to build a massive case
[16:21] <SpamapS> its universe and unseeded.. so there's really no reason for people to complain
[16:21] <SpamapS> m_3: just give me the bug # :)
[16:21] <m_3> ok, lemme find it... thanks!
[16:21] <SpamapS> m_3: you can mark it as affecting the package too, I think.
[16:24] <m_3> SpamapS: #828152
[16:24] <_mup_> Bug #828152: default formula config values not available to hooks <Ensemble:Fix Released by bcsaller> < https://launchpad.net/bugs/828152 >
[16:26] <SpamapS> m_3: yeah try clicking "Also affects distribution"
[16:26] <m_3> I think I did
[16:26] <m_3> ubuntu ensemble
[16:27] <m_3> should I 'target to a milestone' too?
[16:44] <SpamapS> m_3: cool thanks
[17:07] <jcastro> jamespage: aha! So it wasn't exposing the port? :)
[17:08] <jamespage> well it was broken as well - but should be more stable now upstream have released 1.0
[17:08] <jcastro> ok so should I give it a shot now?
[17:08] <jamespage> sure - it should work
[17:08] <jamespage> just finished my testing
[17:09] <jcastro> cool
[17:09] <jcastro> want me to blog it?
[17:09] <jcastro> I think people would use the heck out of this
[17:35] <SpamapS> jamespage: the jenkins formula?
[17:35] <SpamapS> I added an open-port call last week.
[17:35] <jamespage> nope- the etherpad-lite one
[17:36] <SpamapS> ahh cool. :)
[17:36] <SpamapS> whats the official position on python 2.6 support?
[17:37] <SpamapS> Should I file bugs for all the broken stuff? :-P
[17:48] <niemeyer> SpamapS: https://blueprints.launchpad.net/ensemble/+spec/formula-store
[17:49] <niemeyer> SpamapS, hazmat: Both of you have demonstrated interest in blueprints several times
[17:49] <niemeyer> My feeling is that it'll increase the workflow burden without much benefit
[17:49] <niemeyer> But I'm willing to try it out..
[17:50] <SpamapS> I expect it will add a bit of management burden yes. The idea is to provide visibility from outside your team, so that dependent work can carry on without interruptions on either side.
[17:51] <hazmat> niemeyer, afaics the main benefit is just tracking features instead of implementation, but that's not an obvious one to the person doing the implementation, because they intuitively know it.
[17:51] <niemeyer> SpamapS: The kanban provides a lot of visibility already
[17:51] <niemeyer> SpamapS: and it's not like the major features we're working on change every day
[17:51] <hazmat> niemeyer, not at a feature level
[17:51] <SpamapS> last I looked, there was no kanban for eureka.. but maybe I looked in the wrong place?
[17:51] <niemeyer> SpamapS: The conversation we had at the sprint is still valid
[17:52] <hazmat> SpamapS, link in channel topic
[17:52] <SpamapS> ah
[17:52] <jimbaker> http://people.canonical.com/~niemeyer/eureka.html
[17:52] <SpamapS> Yeah this is good for right now.. it doesn't show anything that is on the "not now but later" list..
[17:53] <SpamapS> and it doesn't speak to dependencies.. I can't see there that LXC work has to finish before multi-unit-per-machine
[17:53] <niemeyer> SpamapS: You can find that here: https://bugs.launchpad.net/ensemble
[17:53] <SpamapS> Let me step back. The reason BP's are good is just to group efforts that don't fit into one implementation piece like a bug.
[17:55] <SpamapS> Its just an idea to help get over-arching change implemented.. not something I think is critical to the visibility of the project as a whole.
[17:55] <SpamapS> The visibility problem that I see isn't real.. I think you're right that the kanban is "whats happening now" and the bugs list is "everything else"
[17:56] <niemeyer> SpamapS: I understand.. we went through that before.  The point I continue to make is that there's a point in the gradient of documentation boilerplate where it's easier to talk to someone on IRC.
[17:58] <hazmat> i've experimented with just using tags as easy way to track larger works.. all the security impl bugs are tagged 'security'
[17:58] <SpamapS> yeah thats probably the lightest weight solution, and could even be visualized very easily
[17:58] <niemeyer> hazmat: It feels a bit off to be using tags to track chunks of work like that
[17:59] <niemeyer> hazmat: Tags should continue to be useful across the lifetime of the project
[17:59] <niemeyer> hazmat: security seems to make sense
[17:59] <niemeyer> hazmat: But e.g. "handle-ec2-firewall" is not a nice tag
[17:59] <hazmat> but perhaps firewall does
[17:59] <niemeyer> hazmat: Sure, but you're addressing a different problem
[17:59] <SpamapS> Right, any defects in the firewall handling would be valid years later.
[18:00] <niemeyer> hazmat: You may have firewall in orchestra and in zookeeper handling of security
[18:00] <niemeyer> hazmat: It's orthogonal to the concept of features
[18:00] <niemeyer> and so is security
[18:00] <SpamapS> Likewise, if it were decided that disconnected operation is important.. one could identify the steps to do that as bugs.. and anything in the future that went against that, can also have said tag.
[18:01] <SpamapS> I agree that its orthogonal to features..
[18:01] <SpamapS> But all the over arching changes that I can think of are actually just wide spread defects .. ;)
[18:01] <niemeyer> SpamapS: This is a good use for blueprints indeed
[18:02] <SpamapS> I think it would be worthwhile to use BP's to group bugs and show the dependencies in long term goals.
[18:03] <SpamapS> but... not worth more than coding.. so.. I thin I'll just stop producing more bytes of text for all of you to consume.. :)
[18:03]  * SpamapS returns to testing like its 1999
[18:04] <niemeyer> SpamapS: I agree, this sounds like a sane approach, as long as we agree on what the blueprints are before starting to dump things on them
[18:04] <niemeyer> SpamapS: It's also different from the idea of blueprints I was against
[18:21] <_mup_> ensemble/lib-lxc-merge r336 committed by<EMAIL_ADDRESS>[18:21] <_mup_> merge lxc-lib
[18:40] <_mup_> ensemble/lib-zookeeper r337 committed by<EMAIL_ADDRESS>[18:40] <_mup_> extract managed zk into separate branch
[18:43] <_mup_> ensemble/lib-zookeeper r338 committed by<EMAIL_ADDRESS>[18:43] <_mup_> rename managed zk module to avoid name conflict
[18:46] <_mup_> Bug #837601 was filed: a zookeeper class for reuse by both local provider and tests <local-dev> <Ensemble:New for hazmat> < https://launchpad.net/bugs/837601 >
[19:16] <_mup_> ensemble/go-formulas r11 committed by<EMAIL_ADDRESS>[19:16] <_mup_> Reorganized files so meta handling has its own file/tests.
[19:52] <hazmat> bcsaller1, got time for a catch-up?
[19:58] <niemeyer> hazmat, bcsaller1: Quick interface review: http://paste.ubuntu.com/678276/
[20:00] <bcsaller1> hazmat: yeah
[20:00] <bcsaller1> niemeyer: still leaving out the regex stuff (validator), is that intended?
[20:01] <niemeyer> bcsaller1: No, I was just going to figure it was missing down the road :)
[20:02] <niemeyer> The title type is wrong as well, but otherwise the interface will look like this
[20:03] <niemeyer> I guess default should be anything rather than string
[20:03] <niemeyer> These issues will be sorted out once I actually implement it, though
[20:04] <hazmat> niemeyer, agreed, else looks fine... is the goal to turn the config into a schema?
[20:04] <hazmat> for validation?
[20:04] <bcsaller1> hazmat: a schema is already used for that
[20:04] <niemeyer> hazmat: It is.. will work the same way as the Python side in that regard
[20:04] <niemeyer> hazmat: Well.. maybe, I guess what you say may be interpreted in a different way
[20:04] <niemeyer> hazmat: We have actual validator functions to validate the input against the config schema
[20:05] <niemeyer> hazmat: Against the config, sorry
[20:05] <niemeyer> hazmat: The config itself has a schema, though
[20:05] <hazmat> right, which this is reading, i was just curious if this was going to use a separate mechanism to validate values then the go schema work already done
[20:05] <niemeyer> hazmat: So there are two levels.. config has a format and a schema to validate it.. the validated config *value* is used to validate the user input using validator functions
[20:06] <niemeyer> hazmat: That's how it works in Python, at least..
[20:06] <niemeyer> hazmat: What you say makes me curious though..
[20:06] <niemeyer> hazmat: Maybe we can use the schema to validate the input too
[20:06] <hazmat> niemeyer, indeed, but config is a schema, used to validate the user input
[20:06] <niemeyer> hazmat: Right
[20:07] <niemeyer> hazmat: It's not how it works today, but I'll see if that may simplify things as I write tests
[20:07] <hazmat> cool
[20:07] <_mup_> ensemble/go-formulas r12 committed by<EMAIL_ADDRESS>[20:07] <_mup_> Got config support skeleton in place, and a failing test.
[20:07] <hazmat> bcsaller1, phone work for you?
[20:07] <bcsaller1> its fine, I'm on skype too
[20:12] <robbiew> bcsaller1: cool if we push our call back to the top of the hour?
[20:29] <bcsaller1> robbiew: was on the phone, anytime is fine
[21:00] <_mup_> ensemble/lib-files r339 committed by<EMAIL_ADDRESS>[21:00] <_mup_> extraact file storange into providers.common for use by local and dummy providers.
[21:06] <_mup_> Bug #837692 was filed: A common provider file storage for local and dummy providers <local-dev> <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/837692 >
[21:10] <_mup_> ensemble/local-machine r340 committed by<EMAIL_ADDRESS>[21:10] <_mup_> extract local machine into separate branch..
[21:17] <niemeyer> >>> sio.truncate()
[21:17] <niemeyer> >>> sio.getvalue()
[21:17] <niemeyer> 'foo'
[21:17] <niemeyer> This is a pretty weird behavior in StringIO
[21:18] <niemeyer> Ah, I misunderstand the interface
[21:18] <niemeyer> truncate(0) is what I'm looking for
[21:25] <_mup_> ensemble/no-regex-option r336 committed by<EMAIL_ADDRESS>[21:25] <_mup_> Some consistency clean up in the config handling:
[21:25] <_mup_> - Removed regex type. It's uneven with the other types (the value of a
[21:25] <_mup_>   regex option is not a regex), and it's binding the generic formula
[21:25] <_mup_>   definition to a specific language.
[21:25] <_mup_> - Renamed 'str' type to 'string'. There's no value in saving the 3 chars
[21:25] <_mup_>   when we have e.g. 'float' already in the same context, and 'string'
[21:25] <_mup_>   is actually readable while 'str' is not.
[21:25] <_mup_> - Introduced backward compatibility handling for 'str' so that it
[21:25] <_mup_>   continues to work, but the user is warned about the fact that it's
[21:25] <_mup_>   obsolete so that we can pester authors to rename it timely before it's
[21:25] <_mup_>   too late and we can't go back. Tested this appropriately.
[21:30] <_mup_> Bug #837708 was filed: 'str' in config.yaml should be renamed to 'string' <Ensemble:New> < https://launchpad.net/bugs/837708 >
[21:33] <_mup_> Bug #837710 was filed: regex type should be dropped <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/837710 >
[21:38] <_mup_> ensemble/no-regex-option r337 committed by<EMAIL_ADDRESS>[21:38] <_mup_> Fixed examples.
[21:39] <ameetp> Does anyone know if this tutorial is still valid?  https://ensemble.ubuntu.com/docs/user-tutorial.html
[21:39] <ameetp> I see the instances in my AWS console, but the relation never occurs.  well at least from what I see (rather don't see) in the debug logs
[21:41] <niemeyer> ameetp: It should be valid, yeah
[21:41] <niemeyer> ameetp: Note that the debug-log has to be started upfront
[21:44] <ameetp> niemeyer, yes, I started the logs in-line with the tutorial.  I don't see any relevant output
[21:44] <niemeyer> ameetp: Cna you please paste it somewhere?
[21:46] <ameetp> niemeyer, https://pastebin.canonical.com/51984/
[21:47] <hazmat> ameetp, you started the debug-log before you launched the machines?
[21:47] <niemeyer> ameetp: That's pretty strange.. it's a completely empty log
[21:47] <hazmat> or before adding the relation?
[21:47] <niemeyer> hazmat: Just asked that
[21:48] <ameetp> niemeyer, I was hoping to at least see 'Machine:1: ensemble.agents.machine DEBUG: Downloading formula' when I ran 'ensemble deploy --repository=examples mysql'
[21:48] <niemeyer> ameetp: Yeah, it's quite weird.. it should definitely be showing that
[21:48] <niemeyer> ameetp: Unless you deploying and then started the command
[21:48] <niemeyer> deployed
[21:49]  * hazmat heads out to dinner, bbiab
[21:49] <ameetp> niemeyer, no.  I started the command after doing 'ensemble bootstrap' in another console
[21:50] <niemeyer> ameetp: Ok.. then you kept the command running, and did something else in a different terminal?
[21:50] <ameetp> niemeyer, correct
[21:51] <niemeyer> ameetp: What happens if you deploy mysql again?
[21:51] <niemeyer> ameetp: Or add the relation?
[21:51] <niemeyer> hazmat: Enjoy
[21:52] <ameetp> niemeyer, https://pastebin.canonical.com/51985/
[21:52] <niemeyer> ameetp: Use a different name..
[21:52] <niemeyer> ensemble deploy --repository=examples mysql mysql2
[21:53] <niemeyer> ameetp: Second name is the service name
[21:53] <niemeyer> ameetp: It defaults to the same name of the formula, if you don't provide it
[21:55] <ameetp> niemeyer, https://pastebin.canonical.com/51986/
[21:55] <ameetp> i see an new instance in AWS console as well.
[21:56] <niemeyer> ameetp: The debug-log seems completely off somehow..
[21:56] <niemeyer> ameetp: Can I access the bootstrap instance to have a look?
[21:57] <ameetp> niemeyer, sure.  I can't give access to the system itself, but I can give you a file if you would like.  Or I can open a bug.  I went down this path because the relation never completes for me
[21:58] <niemeyer> ameetp: What's the status?
[21:59] <niemeyer> ameetp: You can open a bug, but without further information we won't be able to do much
[22:00] <ameetp> niemeyer, state always remains null.  Even after 4 hours
[22:00] <niemeyer> ameetp: :-)
[22:00] <niemeyer> ameetp: It's quite fast when things are working
[22:01] <niemeyer> ameetp: Debug log is the way to check this out, but it feels like things are really hosed there
[22:01] <niemeyer> ameetp: Sorry about that.. can't really do much without further debugging
[22:01] <ameetp> niemeyer, is accessing the system the only way to debug?
[22:02] <niemeyer> ameetp: Telepathy would be the other option, but I'm not very good with that ;-)
[22:02] <ameetp> niemeyer, :)  Okay let me see if I can get someone to recreate this
[22:03] <ameetp> niemeyer, anyway.  Thanks for your assistance!
[22:04] <niemeyer> ameetp: No problem, and sorry for the trouble
[22:04] <_mup_> Bug #837724 was filed: Relation already exists error message is bad <Ensemble:New> < https://launchpad.net/bugs/837724 >
[22:08] <niemeyer> ameetp: Btw, if you manage to run this again and reproduce, please ping me
[22:08] <ameetp> niemeyer, sure
[22:50] <_mup_> ensemble/go-formulas r13 committed by<EMAIL_ADDRESS>[22:50] <_mup_> Config parsing begins.
[22:50] <niemeyer> Alright.. I'm stepping off
[22:50] <niemeyer> May be back later for other activities
[22:50] <niemeyer> Cheers everyone
[23:50]  * niemeyer waves


[00:19]  * rww looks amused
[00:22] <IdleOne> changed my mind
[00:50] <rww> lolz
[12:38] <DJones> I've set a ban forward on am0nrahx|work to ##fix_your_connection because of multiple join/disconnects in #ubuntu, seems to have stopped as soon as I set the forward, but will leave it for a while to see if starts again
[12:42] <AlanBell> that was a rather sweet interaction with ubottu ;)
[15:29] <k1l> !guidelines > anonymous_


[02:03] <blr> wgrant: do you see anything obviously wrong with the validation or call to getByPath on l.829? https://code.launchpad.net/~blr/launchpad/ui-project-setbranch/+merge/259069
[02:04] <blr> wgrant: user 'kit' owns 'gitrepository-100046' yet getUtility(IGitRepositorySet).getByPath(kit, 'gitrepository-100046') is None (have tried with git_identity and other forms as well)
[02:05] <wgrant> blr: getByPath takes a user for privilege checking, and a full repository path.
[02:05] <wgrant> eg. the user should enter ~kit/project
[02:05] <wgrant> Or ~kit/project/+git/some-non-default-repo
[02:07] <blr> wgrant: is the interface comment misleading?
[02:07] <blr> s/comment/docstring/
[02:08] <wgrant> blr: Looks fine to me. It specifies the valid forms.
[02:08] <wgrant> What's confusing about it?
[02:09] <blr> '~kit/product-name-100049/+git/gitrepository-100046' returns a repo, however '~kit/+git/gitrepository-100046' does not
[02:09] <wgrant> blr: The latter is a personal repo; one not related to a project.
[02:09] <blr> aah
[02:09] <blr> of course, sorry.
[02:16] <blr> wgrant: pity zope IField doesn't support arbitrary attributes, or more specifically 'placeholder'
[02:16] <blr> default isn't quite the same
[02:17] <wgrant> blr: Right, that's more of an attribute of the widget, I think.
[02:17] <wgrant> eg. a widget could use the title as a placeholder.
[02:18] <blr> it would be nice to have the expected form for the git repo path as a placeholder, but perhaps I'll just add it the label
[02:18] <blr> I suppose I could set it in the js, but that might be a little odd.
[02:19] <blr> will be less of an issue once we have a search modal for git.
[02:20] <wgrant> Yep, search will make it much better. It's also a relatively uncommon case.
[02:33] <blr> wgrant: from [code]/project configure hosting is still for the series, do we want that to also point to project setbranch? That would leave project/[series] as the only means of configuring a series branch
[02:33] <wgrant> blr: I think that's very reasonable.
[02:34] <blr> yep, possibly even confusing in its current state.
[11:17] <cjwatson> wgrant: Nice, I didn't know about variable_name_prefix in batchnavs.
[11:18] <wgrant> cjwatson: I only knew about it from +members
[11:18] <wgrant> That's quite possibly the only other callsite.
[11:19] <cjwatson> wgrant: There's one other, BugTrackerSet:+index
[11:20] <wgrant> Ah, so there is.
[11:20] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/1455907 suggests that the +members use doesn't work ideally, but that isn't really a batchnav problem as such.
[11:20] <mup> Bug #1455907: Every "Former members" batch page starts with a list of "Active members" <Launchpad itself:New> <https://launchpad.net/bugs/1455907>
[11:20] <wgrant> Yeah
[11:21] <cjwatson> Except in that maybe batchnav Next should do AJAX rather than reloading the whole page
[11:21] <wgrant> It can be fixed by anchors, only showing one half on subsequent batches, or using the AJAX batchnav stuff.
[11:23] <cjwatson> I see the FF for the last is disabled on prod
[11:23] <cjwatson> Indeed, everywhere
[11:24] <wgrant> I think AJAX batchnav is only enabled for +bugs
[11:24] <cjwatson> Branches too
[11:24] <wgrant> I'd forgotten it was even implemented for +branches until I saw the code.
[11:24] <cjwatson> But it's behind a disabled feature flag in both cases
[11:24] <wgrant> No, +bugs has been AJAXed since 2013.
[11:25] <cjwatson> Huh, that's interesting because I see ajax.batch_navigator.enabled mentioned in lib/lp/bugs/templates/bugs-listing-table.pt and that flag is definitely off.
[11:26] <wgrant> Is that the right template?
[11:26] <cjwatson> Perhaps not.
[11:26] <wgrant> Hm, I think it is.
[11:26] <wgrant> But there's a whole lot of custom JS for that page.
[11:40] <danilos> launchpad consistently times out when I attempt to comment on my MP (ajax just mentiones a server problem after ~30s, but if I go to +comment and try to submit, I get http://people.canonical.com/~danilo/tmp/lp-problem.png): any known issues?
[11:41] <danilos> MP in question is https://code.launchpad.net/~danilo/landscape-charm/actions/+merge/260916
[11:42] <wgrant> danilos: Yep, looks like a weird postgres issue, we're investigating.
[11:42] <danilos> wgrant, ok, thanks (I've even tried sending an email, still hasn't shown up)
[11:54] <cjwatson> danilos: The mail processor will be writing to the same table, indeed.
[11:54] <danilos> cjwatson, yeah, I was hoping the problem was somewhere between haproxy and lp appservers :)
[11:54] <cjwatson> No such luck.
[11:54] <danilos> yeah, got it
[11:58] <wgrant> danilos: Should all be OK again now.
[11:59] <danilos> wgrant, repeated comments have gotten through, fwiw (not a big deal, just letting you guys know)
[12:00] <wgrant> cjwatson: Oh, I didn't realise IGitCollection handled PersonProduct etc.
[12:01] <cjwatson> Yup, I overachieved slightly on the adapters since it was easy.
[12:55] <cjwatson> Top tip to self: it's more likely that somebody will review my merge proposals if I actually remember to propose them.
[21:01] <blr> wgrant: cjwatson: any suggestions for a user response for GitTargetError that is likely to make sense to them?
[21:01] <blr> "repo attached to another target" may not be meaningful
[21:21] <blr> hmm, well I'll go with that for now given it isn't the typical case.
[21:24] <cjwatson> blr: I think that your form field should be using a vocabulary that only offers repositories attached to the correct target.
[21:24] <blr> cjwatson: I think we decided to defer the repository search modal
[21:25] <blr> cjwatson: so the case here is just providing the user with a git_repository_location TextLine
[21:26] <blr> I believe the only error paths are repo not found, and target error
[21:28] <blr> cjwatson: just updating the configure code link on [code]/project, but perhaps you could have a look in review if there's a better way.
[21:29] <blr> I'll ping you
[22:20] <wgrant> blr: It could still have a non-searchable vocab.
[23:29] <blr> wgrant: ok, so presumably we want something like ValidTargetDefault?
[23:30] <wgrant> blr: Any Git repository for the target is valid.
[23:30] <wgrant> blr: What does the branch equivalent do? It has pretty much the same rules, but we don't need searching yet.
[23:32] <blr> hmm branch_location doesn't have a vocabulary afaict
[23:34] <wgrant> blr: How's it validated?
[23:34] <wgrant> It's possible that it isn't; there are some cross-project relations that shouldn't exist, but they might be from branches that have been moved later.
[23:36] <blr> wgrant: yep only validated for presence
[23:37] <wgrant> blr: OK, then it might not be worth using a vocab just yet. Manually validate the target and use an error message like "Repository is in a different project." or similar?
[23:37] <blr> okay, that's what I have atm
[23:38] <wgrant> Really weird that the branch case wouldn't use a vocab already!
[23:39] <blr> branch_type does


[19:15] <PaoloRotolo> Hi all!
[19:30] <zleap> hi
[23:05] <zleap> hello
[23:06] <UnderControl> Hiya zleap
[23:06] <zleap> how are you
[23:07] <UnderControl> zleap, I'm going alright, how about you?
[23:07] <zleap> i am good
[23:08] <zleap> brb going to see what gme the football highlights is showing
[23:12] <zleap> ok not on till later
[23:16] <UnderControl> :)
[23:17] <zleap> NFL Play off games
[23:18] <zleap> ohh SF are in the championship game, i wonder if they can go all the way this year


[01:18] <cprofitt> itnet7: or anyone else...
[01:18] <cprofitt> in building a loco-testing team I think I should create an LP team for that... thoughts?
[08:56] <Ed__> hi
[12:51] <osacar2007> hi
[12:51] <osacar2007> how r u ?
[12:52] <osacar2007> hi
[12:52] <osacar2007> how r u ?
[14:44] <Ddorda> ‚Äégood afternoon everybody :)
[14:44] <paultag> heyya Ddorda
[14:44] <Ddorda> ‚Äépaultag: sup my man?
[14:44] <paultag> Ddorda: Nada, buddy. Just at the airport, flying back home
[14:44] <paultag> I really have to go to the bathroom, but my phone's charging
[14:45] <paultag> Sooo that's where I'm at
[14:45] <Ddorda> ‚Äépaultag: well, wait for the plane :P
[14:45] <paultag> :P
[14:48] <Ddorda> ‚Äéis there anyone over here from the Italian LoCo?
[14:49] <paultag> Ddorda: I just sent an email to one of the fur l10n guys
[14:49] <paultag> Ddorda: persia is from IT
[14:49] <paultag> Ddorda: but he's not in here right now, I don't think
[14:49] <Ddorda> ‚ÄéItaly is awesome and i'm sorry i'm part of the Israeli LoCo and not the Italian one :(
[14:50] <paultag> Ddorda: IT is great, but IL is doing great! You've done a fantastic job turning it around, and I'd not trade that for anything :)
[14:51] <paultag> Ddorda: being on a big fancy team is great and all, but nothing beats running your own team. You have your own particular fingerprint on it.
[14:51] <paultag> Ddorda: It may be a smaller team, but by god, it's your team, you know?
[14:51] <Ddorda> ‚Äépaultag: sure, but i miss my country. nothing about Ubuntu :P
[14:51] <paultag> Ddorda: :)
[14:52] <Ddorda> ‚Äépaultag: anyway, what with our Flux users team?
[14:52] <paultag> Ddorda: I love it. Start it up, I'll join
[14:52] <paultag> Ddorda: got to fly, I'll BRB ( pun intended 0
[18:29] <kairo> Hi, i need some help with my Microphone Driver for the Asus eee 1005PX
[18:31] <kairo> Anyone there who can help, i tried this: https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules
[18:31] <kairo> But the Mic still not work
[20:05] <Ddorda> ‚Äépaultag: ping
[22:04] <paultag> Ddorda, pong
[22:38] <Ddorda> ‚Äépaultag: still here?
[22:38] <paultag> Ddorda, yes
[22:39] <Ddorda> ‚Äéyou're more than invited: https://launchpad.net/~fluxbox-users
[22:39] <Ddorda> ‚Äé(which means that i don't ask you, you must register it!)
[22:39] <paultag> Ddorda, already done :)
[22:39] <paultag> Ddorda, I had fluxbox-maintainers join it
[22:40] <Ddorda> ‚Äépaultag: awesome :)
[22:40] <Ddorda> ‚Äéoh, and
[22:41] <Ddorda> ‚Äénow i see your msg in #fluxbox
[22:41] <paultag> Ddorda, :)
[23:04] <cjohnston> mhall119: I replied
[23:54] <Ddorda> ‚Äégn people