[02:58] <guille> hola
[02:59] <guille> alguien sabe como transferir los archivos de una camara nikon ?
[02:59] <Unit193> !es | guille
[08:32] <Guest96093> hello
[08:33] <Guest96093> I'm newbie about Ubuntu Studio...
[08:34] <Guest96093> need some information about install correct driver about my computer with cdrom
[08:35] <Guest96093> there is someone could help me?
[22:08] <piltb1> hi
[22:17] <SonikkuAmerica> Hello!
[22:17] <SonikkuAmerica> Who even speaks in here these days? Lol :D


[02:47] <Amapele> If I specify a clear text password on a command in a bash script, how can I be sure that it won't be recorded somewhere?  I am under the impression that the ps command can capture such text.
[03:30] <mutes> it can, youre fucked
[04:15] <holstein> mutes: check out the channel guidelines
[04:15] <urlin2u> holstein, happy holidays.:D
[04:15] <holstein> urlin2u: o/ ... same to you and yours!
[04:28] <mutes> i knew the answer and replied as soon as i could
[04:28] <holstein> mutes: sure, and we appreciate it, just remember this is a 'family show'
[04:30] <mutes> psh
[04:30] <mutes> nobody who uses linux isnt sterile
[04:31] <holstein> mutes: its just ubuntu channel guidelines man, its not a big deal... would you like a link?
[04:31] <mutes> im just carrying on a conversation, not making a big deal of it
[04:31] <mutes> man
[04:50] <wildcrazyhorse> My Ubuntu 11.04 Natty is locking up my computer often. The screen freezes but the mouse still moves around. I have to cold reboot the computer and start all over again. What can I do to fix this problem?
[04:53] <mutes> upgrade to oneiric
[04:54] <wildcrazyhorse> do you have a url address of that file oneiric ?
[04:54] <holstein> wildcrazyhorse: you could look and see if you have an older kernel in your grub list, and try booting it
[04:54] <holstein> wildcrazyhorse: oneiric is ubuntu 11.10
[04:55] <wildcrazyhorse> let me go to ubuntu web site and see if I can find that file...  Will I be able to upgrade and not loose any of my apps or data?
[04:56] <holstein> wildcrazyhorse: theres not a file named oneiric... thats the next version of ubuntu after yours... 11.10
[04:57] <holstein> wildcrazyhorse: you can try it live *before* upgrading or installing
[04:57] <holstein> you can also try an older kernel in 11.04
[07:45] <mlinscott> Hiya, quick question. Is it normal to see oneiric branding after upgrading to precise? I ran update-manager -d, upgraded to 12.04 but noticed on the restart that the login screen and like show 11.10. I did check apt/source.list and it shows it pointing to the precise sources. So something that can be ignored right?
[07:45] <bioterror> uname -cd
[07:45] <bioterror> what does it say?
[07:45] <bioterror> sorry
[07:45] <bioterror> lsb_release -cd
[07:46] <bioterror> did I remember right :D
[07:46] <mlinscott> Description:	Ubuntu precise (development branch)
[07:46] <mlinscott> Codename:	precise
[07:46] <bioterror> you're running precise
[07:46] <bioterror> so edit your sources and remove anything that points to oneirc
[07:47] <mlinscott> •bioterror• awesome thanks! Just wanted to make sure I didn't botch an upgrade.
[07:47] <bioterror> it's pretty hard to botch an upgrade ;)
[07:48] <Unit193> It's normal too, nothing really new :P
[08:44] <r4y> I have a neat RCA mp3 played I got from Walmart for 25 dollars that can hold 4 GB, I am wondering if I can make playlists out of songs in folders without having to the Windows software that came with it and without put the same song on it twice so I can save space
[08:47] <r4y> I'd like to delete the software that came with it which I don't want to use. That software wasn't needed for me to have albums of info put onto it. It works great. If I can't make playlists that's fine with me.
[08:48] <r4y> I tried making symbolic links but the device doesn't support it.
[08:50] <r4y> I am checking it to see what the format is.
[08:51] <r4y> Fat 32-bit, W9 Fat32 (0x0b)
[08:53] <r4y> I don't have experience with mp3 players. Do you know perhaps if I can change the format so I can make symbolic links, or maybe I that will not work
[08:53] <r4y> I didn't mean to add that I to that last sentence
[08:54] <geirha> It probably only supports fat32
[08:54] <geirha> What's the format of the playlist files?
[08:54] <r4y> I haven't tried using the software to make playlists yet
[08:55] <r4y> I tried using wine, but I am going to have to use Windows XP to try it out
[08:55] <r4y> "rcaeasyRip_setup.exe"
[08:56] <r4y> Thank you for telling me that this mp3 might only support fat
[08:57] <r4y> Well, I guess I should try it out on Windows XP for fun.
[08:58] <r4y> I am wondering if what I already put on it will be effected. I hope not, because I put some work into what's already on it, but there shouldn't be any problems because I can start over.
[08:59] <r4y> I guess I should back it up
[09:01] <r4y> I am wondering if I could mimic what the software does to make playlists and then make playlists myself instead and get rid of the software, but I will keep a couple backups, one on one hard drive and another hard drive just in case.
[09:01] <r4y> OK, that's all, sorry for posting so much
[20:10] <kristian-aalborg> grr, my internets are falling out
[20:12] <kristian-aalborg> I get the "Flow control is on for TX and on for RX" in dmesg, suggesting hardware problems (?)
[20:20] <visago> hello?
[20:22] <kristian-aalborg> hi visago
[20:22] <visago> hey
[20:25] <visago> how do i make a usb bootable for ubuntu?
[20:26] <nothingspecial> visago: Do you have ubuntu already?
[20:27] <visago> as an iso
[20:29] <nothingspecial> visago: if you have the latest version of Ubuntu, hit the 'windows'/'super' key then type U S B, choose usb-creator-gtk
[20:29] <nothingspecial> if you have windows use unetbootin http://unetbootin.sourceforge.net/
[20:32] <kristian-aalborg> my internet breakage is weird, in that downloads and IRC are not affected, seemingly
[20:36] <visago> thank you trying it now
[22:37] <seidos> so network-manager isn't configuring wireless in 11.10 for some reason
[22:38] <seidos> had to configure it through the terminal
[22:40] <seidos> any ideas on how to fix it?  maybe i should just install 10.04, but i don't want to burn another cd
[22:41] <seidos> that would be such a waste of plastic >_> :D
[22:41] <seidos> der, didn't check the net
[22:48] <seidos> hmmm, looks like there's an update for nm
[23:30] <seidos> well, updates didn't seem to fix it...network-manager says "device not managed" under "wireless networks"
[23:30] <seidos> going to search the net
[23:33] <geirha> If the wireless devices is configured via /etc/network/interface,  network-manager will ignore it.
[23:58] <seidos> thanks geirha, that did it


[03:24] <sladen> 9687
[11:37] <Laney> 6354
[16:00] <pitti> o/
[16:00] <xnox> o/
[16:00] <sil2100> o/
[16:01] <tdaitx> o/
[16:01] <barry> o/
[16:01] <cyphermox> o/
[16:01]  * slangasek waves
[16:01] <chiluk> o/
[16:01] <sil2100> Tsk tsk, slangasek broke the pattern
[16:01] <slangasek> #startmeeting
[16:01] <meetingology> Meeting started Thu Jan 21 16:01:43 2016 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:02] <slangasek> [TOPIC] Lightning round
[16:02] <slangasek> $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx xnox chiluk)
[16:02] <slangasek> barry caribou xnox bdmurray sil2100 pitti infinity chiluk doko cyphermox slangasek robru tdaitx
[16:02] <barry> win!
[16:02] <barry> debuntu: debian bug #806824 (split libpeas for py2/py3 - waiting on debian gnome maintainers to comment); dirtbike (itp: debian bug #811110); pip 7.1.2 (ongoing)
[16:03] <barry> virtual sprint: working on various debci/autopkgtest.u.c tasks (e.g. retry server; LP: #1519894)
[16:03] <barry> other: booked pycon 2016 trip.
[16:03] <barry> --done--
[16:03] <caribou> Bugfix:
[16:03] <caribou> - rsyslog fails to start under upstart : Provided workaround
[16:03] <caribou> - DMB : Voted +4 for Core Dev Rights
[16:03] <caribou> - LP #1532146 - initramfs-tools nvme support
[16:03] <caribou>   apw is preparing upload
[16:03] <caribou> - LP #1528101 - vm.min_free_kbytes crash issues
[16:03] <bdmurray> caribou: congrats!
[16:04] <caribou> - LP #1534106 - rsyslog segfault with juju
[16:04] <caribou> - LP #1535898 - multipath-tools segfault on Precise
[16:04] <caribou>   cyphermox identified potential fix. User is testing
[16:04] <caribou> - Nut merge : Need to revisit changelog once again
[16:04] <sil2100> caribou: congratulations!
[16:04] <caribou> Project:
[16:04] <caribou> - clvm/dlm supportability
[16:04] <caribou>   clvm to be demoted to Universe for 16.04
[16:04] <caribou> bdmurray: sil2100: thanks!
[16:04] <caribou> ☑ Done
[16:04] <tdaitx> caribou, sweet! congrats! =)
[16:04] <xnox> applied branding to zipl-installer, ubuntu-cdimage
[16:04] <xnox> tought cloud-utils about s390x
[16:04] <xnox> fixed a few FTBFS for golang 1.6
[16:04] <xnox> validated that lxd, docker.io
[16:04] <xnox> resolved a few raised question, raised my own questions and got answers for them
[16:04] <xnox> fought with simplestreams, and got them to work somewhat (report to follow)
[16:05] <xnox> discussed image testing with CPC
[16:05] <xnox> discussed image installation with a few people -> i have an action plan
[16:05] <xnox> trying to find a place where to publish things with #is
[16:05] <xnox> libica is waiting in new
[16:05] <xnox> EOF
[16:05] <xnox> * also branding for d-i
[16:05] <bdmurray> tested staging update of daisy code (good)
[16:05] <bdmurray> uploaded xenial fix for app-install-data-partner bug LP: #1531194
[16:05] <xnox> * lxd, docker.io... work correctly
[16:05] <bdmurray> investigation into ubuntu-release-upgrader test failure
[16:05] <bdmurray> investigation into dist-upgrade failure from T to V
[16:05] <slangasek> caribou: indeed, congrats!
[16:05] <bdmurray> virtual sprint regarding proposed migration                                                                                modified debci title pages to more informative to make browser history better
[16:05] <caribou> tdaitx: slangasek: thank you
[16:05] <bdmurray> modified debci not to use the rabbitmq management plugin
[16:05] <bdmurray> modified proposed-migration deployment scripts to not setup management plugin
[16:05] <bdmurray> ✔ done
[16:06] <sil2100> - Landing team work, silo coordination, preparing landing e-mails
[16:06] <sil2100> - RTM Status meetings
[16:06] <sil2100> - system-image code cleanup, more testing
[16:06] <sil2100> - Writing up a few additional utility tools to the landing-team-tools
[16:06] <sil2100> - OTA-9: * Landing coordination, helping in verifying some issues * Snapshot preparation in the stable-snapshot, image copies and tagging * Re-spinning candidate images with missing fixes and language-packs
[16:06] <sil2100> - xenial - vivid-overlay delta: * Documented findings, e-mail sent to team leads * Started poking individual upstreams about shrinking the delta
[16:06] <sil2100> - Poked kernel team about the missing ppp-modules for s390x
[16:06] <sil2100> - Merged isdnutils to further unblock ppp - all migrated
[16:06] <sil2100> - Filling RT for access to macquarie
[16:06] <sil2100> - Plans regarding future touch hardware enablement
[16:06] <sil2100> - Packaging reviews for dual-landing-enablement merges
[16:06] <sil2100> (done)
[16:06] <sil2100> Uh, some newlines got truncated, oh well
[16:06] <pitti> ]autopkgtest:
[16:06] <pitti>  - Fix implementation of rw-build-tree (#1535234)
[16:06] <pitti>  - Get the right source package version with apt pinning for linux
[16:06] <pitti>  - Make deployment work with juju-local, Canonistack and null runner, for easy local testing
[16:06] <pitti>  - Further debug arm64 breakage in scalingstack (#1531768), ongoing
[16:06] <pitti>  - Help didrocks with running ubuntu-make upstream tests on autopkgtest CI
[16:06] <pitti> proposed-migration sprint: since Tuesday, still ongoing until tonight; see http://pad.ubuntu.com/autopkgtest-sprint, will blog about results tomorrow
[16:06] <pitti> distro:
[16:06] <pitti>  - merge debhelper, sort out dbgsym fallout (#1535949)
[16:06] <pitti>  - libvirt: Don't stop guests during upgrade (#1533839)
[16:06] <pitti>  - Debug juju-local failure after reboot, file #1536522
[16:06] <pitti>  - Fix user lxc containers on wily with xenial kernel (#1533833)
[16:06] <pitti>  - postgresql-9.5 transition, finished now (a few unmaintained modules demoted into -proposed)
[16:06] <pitti> END
[16:07] <xnox> infinity is out.
[16:07] <xnox> chiluk,
[16:07] <chiluk> Mostly distracted with non-public issues.
[16:07] <chiluk> LP #1535349 - Have reviewed changes, and working on likely fix.  I expect to find time to do that today.
[16:07] <chiluk> --done--
[16:07] <cyphermox> chiluk: great
[16:08] <chiluk> yeah stuff got busy this week.
[16:08] <doko> - work on two more Linaro GCC regressions, this starts costing time
[16:08] <doko> - work on python3.4 removal
[16:08] <doko> - work on ruby2.1 removal
[16:08] <doko> - pkgbinarymangler fun, introduced by debhelper merge
[16:08] <doko> - ongoing GCC 6 packaging work
[16:08] <doko> - fix some cross toolchain installation errors, recently introduced
[16:08] <doko> - backport a go patch to allow handling of pkg-config directives in gccgo
[16:08] <doko> - work on petsc/slepc/mpich/source-highlight transitions
[16:08] <doko> - merges, sphinx, python-networkx, numpy & co
[16:08] <slangasek> sil2100: ah, glad that ppp migrated (and a kernel with it) :)
[16:08] <doko> - openjdk-9 update, building on all archs
[16:08] <doko> - new swig upstream
[16:08] <doko> (done)
[16:08] <cyphermox>  - partman-efi SRUs for bug LP: #1512589
[16:08] <cyphermox>  - fixed error with leases file from isc-dhcp merge
[16:08] <cyphermox>  - partman-prep SRU for bug LP: #1487365
[16:08] <cyphermox>  - quickly prepared proposed fix for bug LP: #1318875 since I had some background on it
[16:08] <cyphermox>  - investigated some server install preseeding issues for server image QA
[16:08] <cyphermox>  - testing multipath-tools update for async device detection
[16:08] <cyphermox>    - trying to switch multipath-tools to run multipathd in initramfs.
[16:09] <cyphermox>  - debugging multipath-tools crashes on precise/trusty with caribou
[16:09] <cyphermox>  - MIR review: pyotherside
[16:09] <cyphermox> (done)
[16:09] <tdaitx> doko, did you fix the openjdk 9 build or the update already contained the fix?
[16:10] <sil2100> slangasek: yeah ;) Thanks for poking me quickly when it got stuck after the new kernel upload
[16:10] <sil2100> slangasek: isdnutils was on my list of rdeps but I see it now as marked as 'unneeded' and I can't recall why I marked it so
[16:10] <sil2100> Invalidly
[16:11] <slangasek>  * short week, national holiday on Monday
[16:11] <slangasek>  * sorting out coverage while I'm out next month
[16:11] <slangasek>  * looking at a regression in apt auto-removal of kernels, looks like an upstream apt change (LP: #1440608)
[16:11] <slangasek>  * MP reviews for debian-cd for s390x
[16:11] <slangasek>  * merge reviews: nut, golang 1.5
[16:11] <slangasek>  * discussions around tpm2.0 support for 16.04
[16:11] <slangasek>  * working on the P7 machine deprecation
[16:11] <sil2100> slangasek: while we're at it, what about the removal of unneeded devices from our system-image servers?
[16:12] <robru> lp:britney
[16:12] <robru> * disabled Heidi output to save a few hundred MB of disk space
[16:12] <robru> * started working on a web interface for retrying autopkgtests
[16:12] <robru> lp:bileto
[16:12] <robru> * fix a pile of small bugs
[16:12] <robru> * new /v1/comments API for searching comments
[16:12] <robru> (done)
[16:12] <tdaitx> * Backported OpenJDK 8u71 security patches to OpenJDK 7; package build & tested for Xenial on a private PPA; backports for supported distros for the security team prepared and build locally; dropped after IcedTea 2.6.4 release
[16:12] <tdaitx> * Initial work on backporting OpenJDK 8u71 to OpenJDK 6, talking to Andrew to check how I can help with IcedTea 1.13.10
[16:12] <tdaitx> * Updated OpenJDK 7 from 7u91-2.6.3-3 to 7u95-2.6.4
[16:12] <tdaitx>    - Xenial 7u95-2.6.4-0ubuntu1; waiting doko review
[16:12] <tdaitx>    - Wily, Vivid, Trusty, and Precise packages build for the security team
[16:12] <sil2100> slangasek: should I just go on and remove manta for instance (with a proper announcement of course)? Pat is +1 on that
[16:12] <tdaitx>    - available @ https://launchpad.net/~tdaitx/+archive/ubuntu/openjdk/+packages
[16:12] <tdaitx> * Trying to catch up with the autopkgtest sprint
[16:12] <tdaitx> * Often moving to a coffee shop for some free internet leeching while my ISP struggles to provide any service at all
[16:12] <tdaitx> * Preparing to travel to FOSDEM and a short vacation at Stuttgart afterward; planning fun stuff to do (openjdk stuff, drinking belgian&german beer, exit games, snow shoveling, and whatnot)
[16:12] <tdaitx> (done)
[16:12] <slangasek> sil2100: did you have a list of those from the product side that were agreed already that should be removed? I don't remember
[16:13]  * sil2100 likes the new bileto comments API
[16:13] <sil2100> Just need to re-write my scripts to use that
[16:13] <slangasek> robru: a few hundred MB of disk space> is that per silo?  (also, I guess the time saved per run is important)
[16:13] <doko> tdaitx, go ahead
[16:13] <sil2100> slangasek: no official list, we only discussed that on the RTM status meetings and so far agreed on getting rid of manta for now, the rest needs to stay until... well, a certain time
[16:14] <slangasek> sil2100: sure, go ahead with removing manta :)
[16:14] <sil2100> Ok, thanks
[16:15] <slangasek> OK, any questions re: status?
[16:15] <tdaitx> doko, thanks =)
[16:16] <doko> pitti, xnox: will you enable automatic autopkg testing for golang packages? same as for ruby
[16:16] <pitti> I don't plan to write autopkgtests for Go packages
[16:16] <xnox> doko, my plate is a bit full at the moment.
[16:16] <pitti> if someone does, we'll run them of course
[16:16] <xnox> doko, what do you have in mind? dh_auto_test -v ? for them all?
[16:16] <tdaitx> doko, regarding openjdk 9, updating it was enough to fix the build? or did you have to fix it yourself?
[16:17] <xnox> doko, as in, a blanket test (the fancy way to cover a class of tests)
[16:17] <robru> slangasek: no it saves something like 20mb pet silo IIRC
[16:17] <slangasek> robru: ok. any noticeable improvement in britney runtime?
[16:17] <doko> xnox, I haven't looked how ruby is doing it. but now after the sprint there must be a whole lot of experts =)
[16:18] <robru> slangasek: haven't looked that closely yet
[16:18] <xnox> doko, hahahah. note, that i'm not the doctor!
[16:18] <slangasek> ok
[16:19] <slangasek> [TOPIC] AOB
[16:19] <slangasek> anything else today?
[16:21] <robru> slangasek: actually (unscientific) it looks like the per-silo run time of britney is down from 4 minutes to 3 minutes, but it's not clear to me how much of that is attributable to just disabling heidi vs other factors (i highly doubt writing a file takes a full minute)
[16:21] <robru> they were big files though
[16:21] <slangasek> robru: it has to generate the contents of that file, not just write it
[16:21] <slangasek> or did you only eliminate the writing part?
[16:21] <robru> slangasek: nah the contents of the file are still generated and needed, all we disabled was the writing to disk
[16:22] <pitti> we can't eliminiate the internal dicts of sources and binaries, britney needs those
[16:22] <pitti> write_heidi() just dumps those out as text files; not much computation, just lots of data
[16:22] <slangasek> robru, pitti: ahhh ok, I was thinking of update_output instead
[16:22] <slangasek> which is the second processing pass that we should skip
[16:22] <pitti> we already diabled that a while ago
[16:22] <slangasek> ok
[16:22] <slangasek> then nevermind :)
[16:23] <robru> pitti: oh we did?
[16:23] <pitti> robru: yes, you mailed me about it :)
[16:24] <robru> pitti: https://requests.ci-train.ubuntu.com/static/britney/index.txt still shows output.txt. I have no recollection of disabling that.
[16:24] <slangasek> "update_output.txt"
[16:25] <slangasek> ?
[16:25] <pitti> the second-stage installability test
[16:25] <pitti> timestamp: Fri 2015-12-18 16:37:23 +0100
[16:25] <pitti>  Skip second-stage upgrade testing if UPGRADE_OUTPUT option is absent or empty
[16:25] <slangasek> hmm, sure enough the output.txt are the update_output files
[16:25] <slangasek> anyway
[16:25] <slangasek> sounds like something we can diagnose out of the meeting
[16:25] <robru> UPGRADE_OUTPUT    = /tmp/britney_output/%(SERIES)/<EMAIL_ADDRESS>[16:25] <slangasek> and it doesn't sound like there's any other business?
[16:25] <robru> ok
[16:26] <pitti> robru: perhaps you didn't drop UPGRADE_OUTPUT?
[16:26] <pitti> ah
[16:26] <slangasek> xnox: just assigned you a bug about reusing a DASD for install, clearly they should just be using ASDF instead
[16:27] <slangasek> robru: right, so you can omit that because it's not needed/used for bileto and just adds extra processing time
[16:27] <xnox> slangasek, i think ASDF is not this https://youtu.be/WTUnwygoFsU
[16:27] <slangasek> (maybe a little, maybe a lot)
[16:27] <slangasek> xnox: ummm ok
[16:28] <slangasek> #endmeeting
[16:28] <meetingology> Meeting ended Thu Jan 21 16:28:15 2016 UTC.
[16:28] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-01-21-16.01.moin.txt
[16:28] <slangasek> thanks, all!
[16:28] <barry> thanks!
[16:28] <caribou> slangasek: thanks!
[16:28] <doko> thanks, nurse xnox ...
[16:28] <tdaitx> thanks!
[16:29] <pitti> thanks everyone
[16:29] <sil2100> o/
[16:31] <xnox> tah


[08:54] <brobostigon> morning boys and girls.
[08:55] <SuperMatt> ahoy
[08:57] <brobostigon> ahoy hoy.
[09:51] <BobMottram[m]> g'day
[10:39] <Gargoyle> What is the correct way to restart gpg-agent? Seems to be spawned from "systemd --user" but I cant seem to identify a service unit name for it (service xyz restart, etc)
[12:09] <penguin42> bytemark really trying to get me to convert to BigV now; they added something to let you carry legacy IPs over
[15:14] <diddledan> AI is taking over - no driver on this bus: https://twitter.com/HackRead/status/899288384270737412
[15:16] <penguin42> haha
[15:17] <zmoylan-pi> stand back, i'm in i.t.!!
[15:18] <diddledan> I know REGEX!
[15:18] <zmoylan-pi> how is reg? :-)
[15:18] <diddledan> bloated
[15:19] <zmoylan-pi> it was always thus
[15:22] <ali1234> if you have a USB LTE adapter, how do you read SMS from it?
[15:23] <diddledan> via AT commands no doubt
[15:23] <zmoylan-pi> quickly? :-P
[15:25] <zmoylan-pi> nokia used to have a desktop app that could connect to your phone to do the deed, perhaps something similar exists for the device?
[15:26] <ali1234> there's a cdc-acm device so that is probably it
[15:27] <ali1234> 9600 baud, responds to AT commands
[15:28] <zmoylan-pi> fingers crossed someone has documented all the at commands...
[18:31] <ali1234> okay i got a sms out of the modem
[18:31] <ali1234> but i had to disable network manager because it takes over the interface normally
[18:32] <ali1234> apparently i need to do this instead: https://mail.gnome.org/archives/networkmanager-list/2012-January/msg00007.html
[19:39] <ali1234> okay so this is all controlled by modemmanager and apparently indicator-messages should support it
[21:44] <frank__> #debianboot
[21:44] <frank__> #debian-boot
[21:45] <frank__> how do I switch channel?
[21:45] <zmoylan-pi>  /join #channel
[21:45] <frank__> thanks
[21:49] <diddledan> zmoylan-pi: you don't need to prefix with space. just double the /: //join
[21:49] <diddledan> /join <-- does that
[21:49] <zmoylan-pi> what can i say, i'm lazy... :-)
[21:50] <diddledan> hitting the same key twice is surely more energy saving than hitting two distinct keys, though, no?
[21:50] <zmoylan-pi> perhaps but my hand was resting on spacebar at the time...
[21:52] <brobostigon> i generally always have some of my left hand fingers around the ctrl/alt/fn/shift buttons, unless when i am typing, in which case my little finger on my left hand hovers over those keys, :)
[22:59] <diddledan> !isitoutyet
[22:59] <diddledan> lies!
[23:28] <zmoylan-pi> it's not a proper release till you get it on a magazine cover :-)


[08:04] <wrtp> fwereade: mornin'
[08:04] <fwereade> wrtp, heyhey
[08:13] <wrtp>   fwereade: my ping last night BTW was to let you know that i'd found an old branch that actually made some of the juju commands work, in case you were about to work on something similar.
[08:14] <wrtp> fwereade: it's funny though, i dusted off the branch, split off a part of it that was logically separate and proposed that, then proposed the original again, and only *then* did i discover i'd proposed it before and even had a LGTM!
[08:15] <fwereade> wrtp, yeah, it was nagging at my mind, I *thought* you'd done something like that :)
[08:16] <wrtp> fwereade: yeah, exactly. i looked at cmd/bootstrap and thought "i thought this was working now", then i found the branch and thought i'd never got around to proposing it.
[08:16] <wrtp> fwereade: there was quite a bit of code that i'd totally forgotten about
[08:17] <fwereade> wrtp, heh, ouch :)
[08:18] <wrtp> fwereade: it's fine. nobody's written anything similar in parallel, and the tests are *almost* passing.
[08:18] <wrtp> fwereade: it's quite nice actually.
[08:20] <fwereade> wrtp, awesome :)
[08:21] <fwereade> wrtp, the Init change will hit one of us soon but it shouldn't be a bother
[08:21] <fwereade> wrtp, oo, cath has made breakfast, bbs :)
[08:21] <wrtp> fwereade: is there another Init change in the offing?
[08:21] <wrtp> fwereade: enjoy!
[08:21] <wrtp> hey Daviey
[08:30] <fwereade> wrtp, oh, yeah, Init went in already; sorry, confused :)
[08:30] <fwereade> wrtp, (mmm, maltese bread :))
[08:31]  * wrtp has no idea what maltese bread might be like, but thinks he should have some breakfast because his mouth is watering.
[08:32] <wrtp> (mmm, Sainsbury's muesli :-))
[08:32] <wrtp> TheMue: hiya
[08:33] <TheMue> wrtp: moin, just came back from workout
[08:34] <TheMue> wrtp: … and a discussion with my daughter that a fresh setup of a computer keeping software and data is more than a five minute job
[08:34]  * TheMue laughs
[08:38] <wrtp> TheMue: what, you mean you can't just do "juju add-unit ms-windows --constraint machine=daughters-computer ? :-)
[08:40] <wrtp> fwereade: what *is* maltese bread like, BTW?
[08:40] <TheMue> wrtp: Hehe, no. And even no "osx" (she's got an Apple). OK, installing the OS is done quickly, but a backup of her data as reinstallation of her software later.
[08:41] <TheMue> Btw, anyone already upgraded to 12.04?
[08:42] <fwereade> wrtp, crusty on the outside, awesomely soft and springy on the inside, nice taste that I don't really have the vocabulary to describe; works really *really* well with tomatoes, capers, maybe basil, little bit of oil
[08:42]  * fwereade is hungry again
[08:42] <wrtp> TheMue: not I
[08:43] <fwereade> TheMue, yeah, haven't got around to it yet
[08:43] <wrtp> fwereade: white or brown?
[08:43] <fwereade> wrtp, white
[08:44] <TheMue> wrtp, fwereade: Will also wait a few days until upgrade.
[08:45] <TheMue> fwereade: Hey, I'm trying to loose some weight. Please don't write about delicous food here. ;)
[08:46]  * fwereade resists the urge
[08:47]  * TheMue once again listens to Porcupine Tree and is happy about such a great music
[09:17] <fwereade> wrtp, btw, you remember we had a discussion about cmd/jujuc/server and tomb the other day
[09:17] <wrtp> fwereade: i do
[09:18] <wrtp> fwereade: i suggested not using tomb in that case if i remember rightly
[09:18] <fwereade> wrtp, I must say I keep wanting to use tomb when I look at it -- for example, as it is I think it will be tricky to implement both Close and Wait nicely
[09:19] <wrtp> fwereade: does it need a Wait?
[09:19] <fwereade> wrtp, perhaps not yet; but without one, error discovery is deferred until you want to close the server anyway
[09:19] <fwereade> wrtp, and that feels like it could be a problem
[09:20] <wrtp> fwereade: i see
[09:20] <wrtp> fwereade: depends whether something might want to wait for an error and start a new server or something
[09:21] <wrtp> fwereade: but to be honest, when are you ever going to get an error here? accept is never going to fail in reality.
[09:22] <fwereade> wrtp, I don't know... but I'm not very comfortable just dropping errors on the floor like that: just because I can't imagine the error doesn't mean it won't happen ;p
[09:23] <wrtp> fwereade: can you paste the code again so i can remember it a bit better?
[09:23] <fwereade> wrtp, http://paste.ubuntu.com/947032/
[09:25] <wrtp> fwereade: are you ever going to implement any other methods on Server? (other than Wait)
[09:25] <wrtp> fwereade: cos i have a suggeston
[09:25] <wrtp> iom
[09:25] <fwereade> wrtp, I don;t think so
[09:25] <wrtp> ion
[09:26] <fwereade> wrtp, go on
[09:26] <wrtp> fwereade: why not remove the server type, and replace with a function: RunServer(...) error
[09:26] <wrtp> ah, no
[09:27] <fwereade> wrtp, I *think* I need both wait and close
[09:27] <wrtp> well, why not
[09:27] <wrtp> fwereade: when are you going to want to shut down the server?
[09:27] <wrtp> fwereade: won't it always run forever?
[09:27] <fwereade> wrtp, as part of an orderly shutdown in preparation for a code upgrade, for example
[09:28] <wrtp> fwereade: if we're doing that, won't we be exiting the whole program anyway?
[09:29] <wrtp> fwereade: alternatively...
[09:31] <wrtp> fwereade: don't start the server on NewServer - just return the server object. then implement Server.Run which blocks when called.
[09:31] <fwereade> wrtp, ah, that sounds like it could work
[09:31] <wrtp> fwereade: similar to rpc.Server.ServeConn
[09:32] <fwereade> wrtp, I'll try that, ty :)
[09:32] <wrtp> fwereade: np
[11:34] <wrtp> fwereade, TheMue: https://codereview.appspot.com/6120052/
[11:34] <TheMue> *click*
[11:34] <wrtp> you have reviewed it before, but it has changed a certain amount
[12:00] <fwereade> wrtp, I can't decide whether I like the bootstrap Init
[12:01] <wrtp> fwereade: you mean that it initialises the Conn rather than just the env name?
[12:01] <fwereade> wrtp, it kinda feels as though an error in juju.NewConn would be better reported to the user with os.Exit(1) rather than (2)
[12:01] <fwereade> wrtp, which is the observable distinction between Init and Run errors
[12:01] <wrtp> fwereade: it means we can uniformly test that all commands open their environment correctly
[12:02] <wrtp> fwereade: although perhaps there's another better way of doing that that i haven't thought of
[12:03] <fwereade> wrtp, I don't see how that follows -- the code is duplicated in the Inits of Bootstrap and Destroy, so where we happen to test it is a matter of choice
[12:04] <fwereade> wrtp, now I think of it, what we did with Log could quite easily work with other chunks of common command functionality
[12:04] <wrtp> fwereade: ah, now yer talkin
[12:05] <fwereade> wrtp, I think it'd work out really quite nicely :)
[12:05] <wrtp> fwereade: consider it done
[12:05] <fwereade> wrtp, cool
[12:05] <fwereade> wrtp, I'll leave a comment for form's sake, I haven't finished looking through it yet
[12:05] <wrtp> fwereade: are the final Log changes submitted yet?
[12:06] <fwereade> wrtp, afraid not, you'll have to look at the CL for the latest
[12:06] <wrtp> fwereade: k
[12:06] <fwereade> wrtp, hoping that this morning's modifications will pass muster :)
[12:24] <wrtp> fwereade: i'm not sure that that approach entirely solves the problem. it looks to me like we'll still need to test the environment behaviour of every command.
[12:24] <wrtp> fwereade: for instance, here's what bootstrap might look like: http://paste.ubuntu.com/947216/
[12:26] <wrtp> fwereade: although, i suppose that if we test at least one working example, we can infer the fact  that the command has the correct c.env.open call, and hence testing the env name after Init is sufficient.
[12:26] <fwereade> wrtp, I think that's a good boundary, yeah
[12:27] <wrtp> fwereade: yeah, i think i'll do that.
[12:29] <fwereade> wrtp, other comments delivered btw
[12:30] <wrtp> fwereade: tyvm
[12:57] <niemeyer> Hello!
[12:59] <wrtp> niemeyer: yo!
[13:05] <TheMue> niemeyer: moin
[13:12] <wrtp> fwereade: PTAL
[13:12] <wrtp> niemeyer: https://codereview.appspot.com/6120052
[13:12] <fwereade> niemeyer, heyhey
[13:14] <niemeyer> fwereade: https://codereview.appspot.com/6115048/ reviewed
[13:14] <fwereade> niemeyer, tyvm
[13:14] <niemeyer> fwereade: My pleasure
[13:15] <fwereade> niemeyer, ah, I think I missed the import of what you said before
[13:15] <niemeyer> wrtp: Ohhh, tasty
[13:15] <niemeyer> fwereade: You mean re. public/private?
[13:15] <fwereade> niemeyer, Help should probably be public if for no other reason than directness of testing
[13:15] <niemeyer> fwereade: Yeah, it looks like a nice piece for the API
[13:16] <fwereade> niemeyer, there's a followup that covers that but it's WIP until the parent pipeline settles down
[13:16] <niemeyer> fwereade: That's ok
[13:16] <wrtp> niemeyer: you reviewed it before some time ago, and i forgot about it, found the old branch, dusted it off, split it, and only when i re-proposed did i find the old thread!
[13:16] <niemeyer> wrtp: Hah :-)
[13:17] <niemeyer> wrtp: Nice to see this going along the cool improvements by fwereade in the last few days
[13:17] <fwereade> niemeyer, I feel that "ERROR:" beats "error:" in practice merely because it's often followed up with "usage:", etc, and it makes it stand out much better
[13:18] <niemeyer> wrtp: Should we do a gigantic s/Environ/Env/ replacement?
[13:18] <wrtp> fwereade: the Init/Run distinction works well. i don't know quite why we didn't go with that originally. maybe because we didn't think of the trick of passing in FlagSet
[13:18] <niemeyer> and s/environs/envs/ etc
[13:18] <wrtp> niemeyer: i like Environ
[13:18] <wrtp> niemeyer: but i'd prefer "environ" as the package name
[13:18] <niemeyer> wrtp: I see we often pick one or the other arbitrarily
[13:18] <fwereade> wrtp, indeed, it would be interesting to go spelunking through its very early history in my copious free time ;)
[13:19] <wrtp> fwereade: yeah, there was a long discussion AFAIR
[13:19] <niemeyer> That's of course not too important, and if there's no agreement let's move on
[13:20] <wrtp> niemeyer: i realised that unnecessary plurals don't help anything. hence my "environs->environ" suggestion.
[13:20] <wrtp> niemeyer: but i'm much less keen on abbreviations than i used to be :-)
[13:21] <niemeyer> wrtp: I'd take "env" as a tradeoff ;-)
[13:22] <wrtp> niemeyer: i'll think about it
[13:23] <niemeyer> wrtp: FWIW, we had "environs" to free the "environ" name for variables, if I'm not mistaken
[13:23] <niemeyer> I may be wrong, though
[13:23] <wrtp> niemeyer: maybe. though we usually use "e" or "env" (a good reason not to rename the package, perhaps)
[13:24] <TheMue> niemeyer: Just for info, https://codereview.appspot.com/6111053/ has the changes after the review in and https://codereview.appspot.com/6118055/ is a new one I would like to see in trunk before moving the watchers.
[13:25] <niemeyer> wrtp: Or a good reason to have it as juju/envs
[13:25] <niemeyer> wrtp: same as strings, bytes, ..
[13:25] <niemeyer> TheMue: Cool, thanks
[13:26] <wrtp> niemeyer: i don't feel like i type it that often, or that it's an eyesore when i do.
[13:26] <niemeyer> wrtp: "that"?
[13:26] <wrtp> niemeyer: although i'm still thinking :-)
[13:26] <wrtp> niemeyer: "environ"
[13:26] <wrtp> niemeyer: "Environ"
[13:26] <niemeyer> wrtp: Ah, .. it's more that we can't agree on the proper way to abbreviate it
[13:27] <niemeyer> wrtp: Not that I dislike it per se
[13:27] <wrtp> niemeyer: true.
[13:27] <niemeyer> wrtp: Your branch has EnvName
[13:27] <wrtp> niemeyer: ah!
[13:27] <wrtp> niemeyer: now i see where you're coming from!
[13:27] <niemeyer> wrtp: It's not the only place.. it just reminded me of the issue
[13:28] <wrtp> niemeyer: hmm, you're right: http://paste.ubuntu.com/947322/
[13:28] <niemeyer> wrtp: I'm pretty sure I had reviewed that branch before, but my comments are not there.. was there a different thread in place already?
[13:28] <wrtp> niemeyer: look at the first message in the thread
[13:28] <wrtp> niemeyer: i had to make a new CL because i changed the dependency
[13:29] <niemeyer> OMG
[13:29] <niemeyer> I can see that :-)
[13:29] <niemeyer> wrtp: I reminded of it because I still feel the same way about the tests
[13:30] <wrtp> niemeyer: all of them? i think there's enough commonality to justify tables, but perhaps only because i anticipate very similar tests for other subcommands.
[13:30] <niemeyer> wrtp: cmd_test.go
[13:31] <wrtp> niemeyer: there are two table-driven tests there.
[13:31] <niemeyer> wrtp: It feels over the top.. I'm tempted to reduce them to straightforward checks to see how it'd look
[13:31] <wrtp> niemeyer: the first one really will be identical for every command that takes a --environment flag
[13:31] <niemeyer> wrtp: Maybe I'm just missing how complex it is, but the amount of exceptions and reflection on these tests makes me feel like it's being unnaturally forced onto a table
[13:32] <wrtp> niemeyer: i don't see any exceptions in the EnvironmentInit tests, or reflection in the Commands tests.
[13:34] <wrtp> niemeyer: your argument is stronger for TestCommands, i think
[13:34] <niemeyer> if t.initErr != "" {; if t.runErr != "" {; com := testInit(c, t.cmd, t.args, t.initErr); etc
[13:34] <wrtp> niemeyer: i could easily factor out the command test thing into a function.
[13:35] <niemeyer> wrtp: This is also extremely simplistic:                 ops: envOps("peckham", dummy.OpBootstrap),
[13:35] <wrtp> niemeyer: say runCommand(c *C, com Command, args ...string) (initErr, runErr error, ops []dummy.Operation)
[13:35] <niemeyer> wrtp: This only works for cases where it's calling a simple method without any expectations about it
[13:36] <niemeyer> wrtp: It's mocking on its best.. tying implementation shape to the tests
[13:36] <wrtp> niemeyer: that's perhaps true
[13:36] <wrtp> niemeyer: i'll try refactoring it. i stick to my guns on TestEnvironmentInit though.
[13:37] <niemeyer> wrtp: This one is not so bad, but I'd change it to have a list of factories rather than a list of commands
[13:37] <niemeyer> wrtp: So that the magic copying can go away
[13:37] <wrtp> niemeyer: ok
[13:41] <niemeyer> wrtp: That's the only comment really.. everything else is great
[13:41] <wrtp> niemeyer: it doesn't get rid of reflection entirely BTW
[13:41] <wrtp> niemeyer: thanks
[13:43] <andrewsmedina> niemeyer, wrtp morning
[13:43] <wrtp> andrewsmedina: hiya
[13:44] <andrewsmedina> wrtp: are you ok?
[13:44] <wrtp> andrewsmedina: fine thanks. and you?
[13:45] <andrewsmedina> wrtp: when you have time, please take a look https://codereview.appspot.com/6099051/
[13:45] <andrewsmedina> wrtp: im ok
[13:45] <wrtp> andrewsmedina: yes i will. thanks for the reminder.
[13:48] <andrewsmedina> wrtp: thanks
[14:05] <wrtp> andrewsmedina: one question: do you need to be root to run those tests?
[14:09] <wrtp> andrewsmedina: also i'm slightly concerned that running the tests might have undesirable side effects (but i'm not familiar with virsh - perhaps there are none)
[14:10] <andrewsmedina> wrtp: not. the user that will run the tests need access to libvirt
[14:10] <wrtp> andrewsmedina: and side effects?
[14:10] <andrewsmedina> wrtp: not
[14:11] <andrewsmedina> wrtp: i created and drestoy a dummy net
[14:12] <wrtp> andrewsmedina: i don't see anywhere in the tests that the net is destroyed
[14:14] <andrewsmedina> wrtp: in the other tests I'm using the default libvirt net
[14:15] <wrtp> andrewsmedina: sorry, i don't know anything about libvirt. what's the default libvirt net?
[14:15] <wrtp> andrewsmedina: is it something the user might be using anyway?
[14:16] <niemeyer> fwereade: https://codereview.appspot.com/6123049/ done
[14:17] <fwereade> niemeyer, tyvm
[14:17] <andrewsmedina> wrtp: I'll be more careful in the tests and create a flag for those who have not installed virsh
[14:18] <andrewsmedina> wrtp: he may be using the network default but I do not modify it in the tests
[14:18] <wrtp> andrewsmedina: isn't starting it a modification?
[14:18] <fwereade> niemeyer, nice suggestion, ty
[14:19] <niemeyer> fwereade: Glad you like it
[14:19] <andrewsmedina> wrtp: the start verify if the net is already started
[14:19] <niemeyer> fwereade: I pondered about the forcing upgrade as well, btw
[14:19] <wrtp> andrewsmedina: what if it's not already started?
[14:20] <niemeyer> fwereade: I didn't bother too much because it's mimicking what's in Py today
[14:20] <fwereade> niemeyer, oh, ok
[14:20] <niemeyer> fwereade: I'm happy to splat the state if we have --force, but I don't think the opposite is sensible
[14:21] <niemeyer> fwereade: IOW, if somebody does "upgrade --force", and then "upgrade", the second shouldn't drop the --force state
[14:21] <fwereade> niemeyer, ah, I thought it... kinda dumb to do so, but not intrinsically *bad*
[14:22] <TheMue> niemeyer, fwereade: I found it in the Py code, that a change isn't allowed.
[14:22] <fwereade> niemeyer, I don't really feel that it should be an error, even so
[14:22] <fwereade> niemeyer, it may silently refuse to downgrade from --force to not
[14:22] <niemeyer> fwereade: I think it's actually bad because doing an upgrade at all is generally forbidden unless the unit is running fine
[14:22] <niemeyer> fwereade: The first succeeds because of the --force, and the second succeeds because of the first
[14:23] <andrewsmedina> wrtp: a network should be active, inactive or does not exists
[14:23] <niemeyer> fwereade: So, in a way, the second would only happen at all because there's a --force in place..
[14:23] <fwereade> niemeyer, hmm, ok
[14:23] <andrewsmedina> wrtp: if it's active, it's started
[14:23] <niemeyer> fwereade: That's why, in that situation, I'd rather see "hey, already doing it, hold on" rather than "sure!"
[14:23] <wrtp> andrewsmedina: by running this test, the current status is changed. i don't think tests should have side-effects.
[14:24] <andrewsmedina> wrtp: in your machine?
[14:24] <wrtp> andrewsmedina: that's right
[14:24] <niemeyer> TheMue: Are you with us
[14:24] <niemeyer> ?
[14:24] <niemeyer> TheMue: The summary is:
[14:24] <wrtp> andrewsmedina: it's ok if it has side-effects that are cleaned up afterwards
[14:24] <niemeyer> TheMue: upgrade + upgrade == fine
[14:24] <niemeyer> TheMue: upgrade + force-upgrade == fine
[14:25] <andrewsmedina> wrtp: yes
[14:25] <niemeyer> TheMue: force-upgrade + force-upgrade == fine
[14:25] <niemeyer> TheMue: force-upgrade + upgrade == NOT fine
[14:25] <andrewsmedina> wrtp: I will use a testdummy net in tests for start method ok?
[14:25] <wrtp> andrewsmedina: but anyone should be able to run go test launchpad.net/juju/go/... and be happy that it won't interfere with anything on their machine
[14:25] <niemeyer> TheMue: Well.. or maybe, fine as well
[14:25] <niemeyer> fwereade: We could actually make it fine, by saying that the --force continues in place in that situation
[14:26] <TheMue> niemeyer: Hmm, sadly don't know enough about the upgrade mechanism in total.
[14:26] <wrtp> andrewsmedina: you should make sure to delete the net afterwards too (perhaps by defining TearDownSuite)
[14:26] <fwereade> niemeyer, yeah, that seemed nicer to me
[14:26] <andrewsmedina> wrtp: you are "+1" for virsh flag or I shoud reuse the lxc flag?
[14:26] <andrewsmedina> wrtp: I'm doing it for other tests
[14:26] <wrtp> andrewsmedina: i don't understand
[14:26] <fwereade> niemeyer, you're not allowed to, er, downgrade your upgrade ;)
[14:26] <niemeyer> TheMue, fwereade: Ok, so what about this.. let's just move on with what's there given that it mimics what exists today.. we can improve it later
[14:26] <niemeyer> fwereade: We can then implement that nicer behavior on a follow up
[14:27] <TheMue> niemeyer: Sounds ok.
[14:27] <fwereade> niemeyer, TheMue: yep, I'm fine with that
[14:27] <niemeyer> TheMue: Cool
[14:28] <wrtp> andrewsmedina: what flag are you referring to?
[14:28]  * TheMue sadly forgot why he added (TODO) to the comment.
[14:28] <TheMue> I'm getting old.
[14:28] <andrewsmedina> wrtp: a "--virsh" flag
[14:28] <andrewsmedina> ops
[14:28] <niemeyer> TheMue: So you just need to observe the last of fwereade's point to see how to get to some agreement
[14:29] <andrewsmedina> wrtp: a "-virsh" flag
[14:29] <wrtp> andrewsmedina: it depends whether you think you can implement the tests without affecting the user's environment
[14:30] <wrtp> andrewsmedina: if you don't, i think it would be a good idea to implement some tests that can be run without running virsh, even if they don't verify all the functionality
[14:30] <andrewsmedina> wrtp: how I mock the virsh commands?
[14:31] <wrtp> andrewsmedina: you could set $PATH
[14:31] <andrewsmedina> wrtp: I dont undertand
[14:31] <wrtp> andrewsmedina: have a look at state/ssh_test.go
[14:31] <wrtp> andrewsmedina: it uses that technique
[14:32] <andrewsmedina> wrtp: brb
[14:32] <wrtp> andrewsmedina: ok
[14:32] <TheMue> fwereade: For the watchers which run concurrently I would like to keep those changes in the background (see the other watchers). Direct write/read tests are already done in state_test.go.
[14:37] <fwereade> TheMue, I don't see how it's a benefit to run the test code concurrently when you don't have to
[14:39] <fwereade> TheMue, the change goes through ZK just the same either way, and if you skip the concurrency you can eliminate both waiting and the (admittedly unlikely) potential event coalescing
[14:40] <TheMue> fwereade: How would you build this as a table driven test?
[14:40] <andrewsmedina> wrtp: im back :D
[14:41] <fwereade> TheMue, I'm not sure it favours a table-driven style so much as it does a plain old procedural style
[14:42] <TheMue> fwereade: niemeyer and wrtp convinced me about the elegant way of doing it table-driven. And I've got to admit, I now like this way. It's clean.
[14:42] <fwereade> TheMue, heh, has it changed already?
[14:43] <fwereade> TheMue, still don't feel it's a good fit tbh, but perhaps it'll grow on me
[14:43] <TheMue> fwereade: What has changed? I had changed other watcher tests to be table-driven today.
[14:44] <TheMue> fwereade: All now work the same way, also the new PortsWatcher test.
[14:45] <fwereade> TheMue, sorry, I'm just unclear on a largely irrelevant point: whether or not the watcher tests were originally more procedural
[14:46] <TheMue> fwereade: I've started them in a more mixed way, asynchronous changes and a procedural testing of the obtained values.
[14:47] <TheMue> fwereade: And here it would habe been more simple to move the changes between the tests.
[14:47] <fwereade> TheMue, it's the asynchronicity that I feel is the problem anyway, not the table-drivenness
[14:48] <fwereade> TheMue, what behaviour does it exercise that a synchronous test wouldn't?
[14:48] <TheMue> fwereade: Yes, that's why I asked you if you've got a good idea on integrate the changes int the table too.
[14:50] <TheMue> fwereade: I've got no problem in convert it to be synchronous (but in a different branch, all watchers, after moving). But I would like to keep it table-driven.
[14:50] <fwereade> TheMue, `func() { unit.OpenPort("tcp", 80)}` ?
[14:50] <andrewsmedina> wrtp: I will create the mock for virsh like your ssh tests, ok?
[14:50] <wrtp> andrewsmedina: you've got a review
[14:51] <TheMue> fwereade: OK, so the table has to be an anonymous struct to contain test func and expected result, but yous, looks ok to me.
[14:52] <fwereade> TheMue, cool
[14:52] <wrtp> andrewsmedina: i think so. perhaps you might talk to niemeyer some time about this too.
[14:52] <andrewsmedina> wrtp: ok
[14:52] <andrewsmedina> wrtp: I will improve the tests and talk with you and niemeyer again
[14:53] <TheMue> niemeyer: How about you? I would do that change after this watcher and the PortsWatcher are in and then the branch with moving all watchers is in too.
[14:59] <niemeyer> TheMue: Which change?
[15:00] <niemeyer> TheMue: The refactoring fwereade suggested?
[15:00] <TheMue> niemeyer: I discussed with fwereade to take the concurrent changes out of the tests later.
[15:00] <TheMue> niemeyer: Yes.
[15:01] <niemeyer> TheMue: Yeah, as long as fwereade is happy, I'm happy
[15:01] <niemeyer> TheMue: and as long as you're happy too, of course
[15:01] <TheMue> niemeyer: Fine, and I will keep it as small branches to make you happy.
[15:01] <niemeyer> TheMue: WOohay small branches!
[15:01] <niemeyer> :)
[15:01] <TheMue> niemeyer, fwereade: Big party!
[15:01] <niemeyer> !
[15:02] <niemeyer>   i i i
[15:02] <niemeyer> ----------
[15:02] <TheMue> *rofl*
[15:02] <fwereade> TheMue, I'm happy :)
[15:02] <niemeyer> |          |
[15:02] <niemeyer> \:-)
[15:02] <TheMue> Oh, we get a cake.
[15:03] <TheMue> Btw, just had some selfmade chocolate chips by my wife with the coffee. Yummy.
[15:09] <fwereade> niemeyer, btw, ERROR/error: thoughts? ERROR stands out much better when the error line is not the only output
[15:13] <TheMue> niemeyer: So, submitted, next stop: PortsWatcher. ;)
[15:14] <niemeyer> TheMue: Was just looking at it, but in a meeting with zaid just now.. will continue after lunch
[15:14] <niemeyer> fwereade: just a sec and will be with you
[15:22] <TheMue> niemeyer: OK, np.
[15:30] <niemeyer> fwereade: I'd prefer "error: unrecognized flag --foo" than "ERROR: unrecognized flag --foo"
[15:31] <niemeyer> fwereade: My feeling about it is that it was just a problem detected.. no one is dying :-)
[15:31] <fwereade> niemeyer, fair enough, I imagine I'll grow used to it :)
[15:31] <niemeyer> fwereade: That said, you have a point..
[15:31] <niemeyer> fwereade: Something we should do is to reorder the error vs. help
[15:31] <niemeyer> fwereade: In that one place we print the error & help, error should come last
[15:31] <niemeyer> fwereade: So it's next to the prompt
[15:32] <fwereade> niemeyer, that's no problem... and it will be much clearer in that case anyway
[15:32] <fwereade> niemeyer, ok, if I rearrange all that and make it lowercase, good to submit?
[15:32] <niemeyer> fwereade: In other cases, I suspect that's already happening
[15:32] <niemeyer> fwereade: I mean, error is already the last thing printed
[15:33] <niemeyer> fwereade: As long as that's true, I don't see a problem with it being lowercased as it'll be very clear
[15:33] <niemeyer> fwereade: Yep, +1
[15:34] <niemeyer> TheMue: Btw, I just detected a silliness I've suggested that isn't necessary
[15:35] <niemeyer> TheMue: You know that change, ok := ... if !ok { s.tomb.Kill(nil); return }, that we're using everywhere?
[15:35] <TheMue> niemeyer: Yes?
[15:35] <niemeyer> TheMue: It's not necessary
[15:36] <niemeyer> TheMue: It's fine to just return in that case
[15:36] <niemeyer> TheMue: The deferred Done() will make it all work fine
[15:36] <TheMue> niemeyer: So check the ok but don't Kill()? OK, I'll change it during refactoring.
[15:37] <TheMue> niemeyer: Is it ok when putting it into the watcher movement change?
[15:37] <TheMue> niemeyer: So that change would only contain this code change and the moving.
[15:39] <niemeyer> TheMue: No, please not in the movement change
[15:39] <niemeyer> TheMue: You can put it in the PortsWatcher, though
[15:39] <niemeyer> TheMue: As it's just a bunch of one-liner removals, that's fine
[15:39] <TheMue> niemeyer: OK, no pro.
[15:40] <niemeyer> TheMue: If you do that now, please fix the comment of the watcher as well.. it's referring to the copy & pasted watcher
[15:40] <niemeyer> TheMue: I'll review it right after lunch and hopefully we can already get it in
[15:40] <TheMue> niemeyer: fwereade already reviewd it.
[15:40] <niemeyer> TheMue: Ah, superb
[15:40] <niemeyer> TheMue: Btw, do you understand why these lines can be removed?
[15:40] <TheMue> niemeyer: OK, will change it now and propose it immediately.
[15:43] <niemeyer> TheMue: Btw, do you understand why these lines can be removed?
[15:44] <wrtp> niemeyer: PTAL  https://codereview.appspot.com/6120052
[15:45] <TheMue> niemeyer: We don't pass an error to outside, but want to close the tomb and the channel. That's done by defers after the return.
[15:46] <niemeyer> TheMue: Right, Done() takes care of "killing" the tomb if it's not yet dead
[15:46] <niemeyer> TheMue: So as long as we're returning from this function, with nil err, just returning is fine
[15:47] <niemeyer> wrtp: Thanks, I'll have  a look right after lunch + TheMue's
[15:47] <TheMue> niemeyer: Fine, code reduction at its best.
[15:47] <niemeyer> TheMue: +1
[16:03]  * niemeyer => lunch
[16:16] <wrtp> isn't it nice to know that gustavo implies lunch? i'll make sure to have him around as often as possible.
[16:20] <TheMue> wrtp: *rofl* took a few moments to get it.
[16:20] <wrtp> :)
[16:28] <wrtp> hmm, i thought i'd sussed this prerequisite stuff. but despite small diffs
[16:28] <wrtp> bzr diff --old lp:~rogpeppe/juju/go-more-commands | wc
[16:28] <wrtp>      68     260    2113
[16:28] <wrtp> i guess this:
[16:28] <wrtp>  https://codereview.appspot.com/6117064
[16:28] <wrtp> s/guess/get
[16:30] <TheMue> wrtp: Strange. It claims different changes as yours. Hmm.
[16:31] <wrtp> TheMue: yeah. somewhere it's diffing against an unmerged branch
[16:31] <wrtp> or something
[16:33] <TheMue> wrtp: I still don't understand the prereq stuff.
[16:33] <wrtp> TheMue: i thought i did!
[16:34] <TheMue> wrtp: As long as the tools are working I'm happy. But in case of a problem I'm lost.
[16:42] <wrtp> TheMue: and this is really weird: http://paste.ubuntu.com/947637/
[16:42] <wrtp> if i revert to a revision, isn't the revision-id going to be that revision?
[16:42]  * wrtp is trying to work out how to diff two revision-ids
[16:43] <fwereade> TheMue, wrtp: is it not that lbox requires that changes on the target that have been merged into the proposed branch have *also* been merged into the prereq, even if the prereq has already been merged?
[16:43] <TheMue> wrtp: Huh
[16:43] <wrtp> fwereade: yes. i did that though, i think
[16:43] <fwereade> wrtp, ah ok -- it just looked a bit like it has for me when I've got that wrong
[16:43] <wrtp> fwereade: me too. that's why "i thought i understood it!"
[16:44] <fwereade> wrtp, haha, sorry :(
[16:45] <wrtp> oh, i have uncommitted changes.
[16:45] <wrtp> and it wants to remove cmd/juju/destroy.go
[16:47] <wrtp> so weird. i could've sworn it passed its test *and* i merged it.
[17:00] <fwereade> gn all, take care
[17:01] <wrtp> fwereade: gn, take care
[17:01] <wrtp> niemeyer, TheMue: https://codereview.appspot.com/6117064
[17:01] <wrtp> all that hassle for about 6 lines of code :-)
[17:01] <wrtp> niemeyer, TheMue: ultra-small branch BTW!
[17:02] <TheMue> wrtp: *lol*
[17:04] <niemeyer> wrtp: LGTM
[17:05] <wrtp> niemeyer: still waiting for prereq BTW, but i'm sure you know that :-) it turns out that it didn't need to be a prereq, but i didn't want to delete the CL.
[17:05] <wrtp> i probably should've
[17:06] <niemeyer> wrtp: Yeah, I'll just review TheMue's first
[17:06] <wrtp> niemeyer: np
[17:10] <wrtp> niemeyer: do you know if http.Client.Do is guaranteed to close req.Body ?
[17:16] <niemeyer> TheMue: Done.. just a couple of trivials
[17:16] <TheMue> niemeyer: Fine, thx.
[17:16] <niemeyer> wrtp: I don't
[17:17] <wrtp> niemeyer: np. just wondering about s3 Put. but i don't think it matters actually.
[17:26] <niemeyer> wrtp: I'd check the implementation
[17:26] <TheMue> niemeyer: Do you wonna see the openPortsNode change? Otherwise I submit it.
[17:26] <niemeyer> TheMue: No, happy to have it submitted, thanks!
[17:26] <wrtp> niemeyer: yeah, i did, but it's not greatly obvious
[17:28] <wrtp> time to go
[17:28] <wrtp> niemeyer, TheMue: g'night. see ya tomorrow.
[17:28] <TheMue> wrtp: Yes, good night, I leave too in a few minutes.
[17:28] <TheMue> wrtp: CU
[17:28] <niemeyer> wrtp: Thanks, and have a good one too
[17:29] <wrtp> niemeyer, TheMue: to both of you too
[17:36] <niemeyer> wrtp: I think the answer is no, there's no guarantee
[17:39] <TheMue> niemeyer: So, I'm off. CU tomorrow.
[17:39] <niemeyer> TheMue: Cheers, have a good evening too
[17:39] <TheMue> niemeyer: You too, bye.
[18:31] <robbiew> niemeyer: we have 1:1 now, mind if we just have it in person next week?
[18:31]  * robbiew is cleaning up Precise blueprints all day today :/
[18:32] <niemeyer> robbiew: np
[18:33] <robbiew> thx...back to the grind


[19:30] <Eickmeyer[m]> teward: Got any experience with Docker or know someone who does who can evaluate a log for me?
[19:31] <teward> I know a bit about docker, why?
[19:31] <teward> What’s broken and who needs to be yelled at for it :P
[19:32] <Eickmeyer[m]> teward: It's an unrelated project. I'll DM you.
[19:32] <teward> Ok
[23:35] <temporary_visito> Morning, sirs.
[23:35] <temporary_visito> Anybody alive here to discuss RME Hammerfall card issues here?
[23:36] <temporary_visito> Well, considering the geostationary delay ;)
[23:37] <temporary_visito> The issue: cannot make this card working under Ubuntu Studio: 03:01.0 Multimedia audio controller [0401]: Xilinx Corporation RME Digi9652 (Hammerfall) [10ee:3fc4] (rev 03)
[23:37] <temporary_visito> while this card is working: 09:04.0 Multimedia audio controller [0401]: Xilinx Corporation RME Hammerfall DSP [10ee:3fc5] (rev 6b)
[23:38] <temporary_visito> the issue: neither hdspconf nor rmedigicontrol appplies to the particular card ([10ee:3fc4]).
[23:39] <temporary_visito> And indeed, rmedigicontrol.c does not even consider this card within the statement
[23:39] <temporary_visito> if(strcmp(snd_ctl_card_info_get_driver(hw_info),"Digi96")==0)		{*BLAAH* }


[04:30] <unimaginative> Has anyone had any luck playing a VC-1 stream? I get audio, but a black screen for video (mabye missing video codec?)
[14:02] <Essobi> Morning.


[20:27] <ibeardslee> morning
[20:36] <snail> morning all
[21:11] <ajmitch> morning
[21:48] <ojwb> morning
[22:01] <ojwb> actually managed to coax the natty upgrade into downloading everything off-peak this time
[22:02] <ajmitch> so everything's upgraded now, or just downloaded?
[22:18] <Atamira> mornin
[22:27] <ojwb> it's currently installing stuff
[22:27] <ojwb> or was when I last checked
[22:27] <ojwb> it's not a totally smooth experience the network drops during an install
[22:27] <ojwb> it just bails out
[22:27] <ojwb> and when you restart it seems to insist on refetching the upgrade tool
[22:27]  * ojwb was going to see if there was a bug for that...
[22:28] <ojwb> it could at least do a conditional fetch
[22:28] <ojwb> or just fetch the signature and see if that's changed
[22:28] <ojwb> it does at least reuse the packages it has already downloaded
[22:31] <ibeardslee> yeah that is a plus
[22:31] <ojwb> or I would do if launchpad actually worked
[23:54] <ojwb> hmm, well natty seems to no longer know what resolutions the display can do
[23:55] <ojwb> i think it returns invalid EDID, but maverick coped