[08:34] <Kamion> it's entirely possible and reasonable for a package to want a non-default gcc
[08:35] <Kamion> are you sure you don't mean gcc-3.4-base, though?
[08:35] <mdz> it would be rather odd for it to depend on gcc at all
[08:35] <Kamion> indeed
[08:35] <Kamion> in any case, libgtkmm-2.4-dev is in universe ...
[08:36] <mxpxpod> when I do apt-get install libgtkmm-2.4-dev, it installs cpp-3.4, g++-3.4, and gcc-3.4
[08:37] <Kamion> it's likely to be easier to find out what depends on it using a package management frontend a little more sophisticated than apt-get
[08:37] <mdz> seems to be specific to powerpc
[08:37] <Kamion> dselect would tell you; I assume aptitude will too
[08:38] <mdz> it's due to libstdc++6-dev Depends: g++-3.4
[08:38] <mxpxpod> oh, nice
[08:38] <mdz> and something in that chain depends on libstdc++-dev, which is provided by libstdc++6-dev
[08:38] <Kamion> still, universe :)
[08:38] <mdz> yep
[08:38] <Kamion> I'm guessing 3.4 will become the default by hoary, if not that then by grumpy
[08:38] <mxpxpod> c++ stuff is universe?
[08:39] <Kamion> no, but libgtkmm-2.4-dev is
[08:39] <Kamion> there's libstdc++5-dev
[08:39] <__daniel> unfortunately libxml++-2.*-dev isnt :-(
[08:41] <mxpxpod> Kamion: so, is it a problem with libgtkmm-2.4-dev depending on libstdc++6-dev?
[08:41] <mdz> no, it doesn't
[08:41] <mdz> something else does
[08:41] <mdz> it looks like a problem of some package depending on a pure virtual package with no concrete alternative
[08:41] <mxpxpod> hmm
[08:41] <doogie> I've sent 800MB thru bt
[08:41] <mdz> apt happens to choose libstdc++6-dev rather than 5-dev
[08:42] <mdz> which is perfectly legitimate
[08:42] <mdz> doogie: 4.4GB here
[08:42] <doogie> seeding now, of course
[08:44] <mxpxpod> mdz: ok, I installed libstdc++5-dev and removed all the 3.4 stuff and libstdc++6, and libgtkmm-2.4-dev works fine
[08:45] <sabdfl> guys i think i screwed up the /. submission by selecting Linux as the section
[08:45] <sabdfl> i've emailed timothy (who accepted the story) and asked him to consider it for the main page
[08:45] <mdz> ah
[08:45] <mdz> sabdfl: add this to the release checklist? :-)
[08:46] <sabdfl> mdz: yup :-)
[08:46] <sabdfl> thought i was being helpful by Alex tells me he did the same thing for Plone 2.0 and it also went into a section
[08:47] <silbs> Release checklist: 1. No naked people. 2. Slashdot main page or nothing at all.
[08:49] <mdz> Kamion: enjoy
[08:49] <carlos> X-)
[08:58] <mdz> "I had never tried Debian before because the packages were too slow"?
[09:15] <vorlon> mdz: gentoo user? :)
[09:19] <mxpxpod> I've asked this before, but why does ubuntu use pbbuttonsd instead of pmud?
[09:34] <lucas_> sbody familiar with X and mouse problems ? I have a regression regarding my touchpad, which worked out of the box with debian unstable and doesn't work (I can't use it to "click", I have to use the buttons) with ubuntu
[09:39] <doogie> 1.6g
[09:40] <vorlon> lucas_: installed the synaptic driver?  I think I noticed that this wasn't installed for me by default by Ubuntu.
[09:40] <__daniel> mxpxpod, i didnt even hear of both before
[09:41] <lucas_> vorlon: I didn't need it
[09:41] <lucas_> actually, I just tested with an old knoppix, and it still doesn't work. Maybe my touchpad is broken ...
[09:44] <mxpxpod> __daniel: the problem I have is that I let gnome do volume up/down, mute, and brightness up/down, but when pbbuttonsd does them, it messes with gnome
[09:44] <chrisa> mxpxpod: Probably because pbbuttonsd works a hell of a lot better
[09:44] <mxpxpod> __daniel: and I don't know of a way to tell pbbuttonsd to leave those things alone
[09:44] <chrisa> Especially with things like gtkbbuttonsd
[09:44] <__daniel> mxpxpod, oh :-(
[09:47] <mxpxpod> chrisa: bah, gtkpbbuttons's themes suck
[09:47] <sabdfl> response from /. is that they can't sanely switch a story from the linux to main sections, but i'm sure there will be more coverage in due course! they said they've been accused of bias towards us already because of all the coverage :-)
[09:47] <chrisa> mxpxpod: Then don't use it. Either way, I have the same laptop as you and everything works flawlessly with pbbuttonsd
[09:47] <mako> fair enough i suppose
[09:48] <mako> i'm sure /. is accused of a lot of things :)
[09:49] <__daniel> bye... see you later
[09:50] <mxpxpod> chrisa: is there a way to get pbbuttonsd to step the volume up more than one on a volume up/down keypress?
[09:56] <lamont_r> moo
[09:57] <doogie> /. always was insane
[09:57] <lucas_> does ubuntu do sthing out of ordinary with the mouse ? for example, use something like gpm ? my touchpad doesn't work with ubuntu, while it worked with debian. I'd like to try something before reinstalling debian just to check if my touchpad is actually broken ...
[09:59] <amu> wb lamont
[09:59] <lamont_r> hi amu
[09:59] <mdz> lucas_: -> #ubuntu
[10:00] <mdz> vorlon: the synaptics driver has been installed by default in ubuntu for some time
[10:00] <lamont_r> damn college kids taking all the bandwidth... :-)
[10:01] <vorlon> mdz: ok, I suppose the fact that I installed the preview has something to do with it. :)
[10:01] <azeem> congrats, dudes
[10:03] <mdz> vorlon: I think that even predates preview
[10:04] <mdz> yep
[10:04] <mdz> vorlon: http://wiki.ubuntu.com/WartyWarthog_2fDesktopSeed?action=recall&date=1092046589
[10:05] <amu> lamont_r: tested it on a ibm r40, Dell Optiplex GX270, Noname maschine with nvi, noname with ati and a virtual pc ...
[10:06] <lamont_r> -17?
[10:06] <lamont_r> er, 16?
[10:06] <vorlon> mdz: ok, we'll chalk it up to delirium then.
[10:06] <amu> 7
[10:06] <lamont_r> ok
[10:10] <amu> a common problem was, the Xfree detection, Dell with nv it works, Dell with intel 82865 only 640*480, Dell with nv OK, IBM R40 with Radeon M7 7500 ( vesa ) noname with X800 pro ( vesa )  virtual pc S3 ( vesa ), sound works, all have problems with my usb stick, device is detected but not mounted, bootsplash still need a please hold the line and press ESC for detailed bootmessages
[10:12] <amu> desktop itself need some icons like Mail,Browser and a link to the FAQ .... homedir needs some dirs like Documents/Picture/Music ....
[10:13] <lamont_r> amu: I think the desktop and homedir are consistant with what's on the installed system, hence won't change
[10:13] <lamont_r> seb128: jdub: or am I smoking crack?
[10:13] <mdz> amu: the focus right now is on stability and functionality
[10:13] <mdz> amu: we are not adding any new features to the live CD for Warty
[10:14] <lamont_r> and it's not RC, like mdz said.
[10:14] <doogie> 2g
[10:14] <lamont_r> mdz: would better X detection be considered enhancement or RC, I wonder?
[10:14] <lamont_r> since it's throwaway work for hoary, I expect
[10:14] <mdz> lamont_r: bug, but not RC
[10:15] <lamont_r> ok.
[10:15] <mdz> the live CD seems to fall back to vesa pretty reliably
[10:15] <amu> mdz: x autodetection is a small problem, vesa works, not good as it should
[10:15] <mdz> I don't particularly care if it's accelerated or not
[10:15] <lamont_r> amu: could you file a bug (sev=normal) wrt autodetection?
[10:15] <amu> ^k
[10:15] <mdz> please don't
[10:15] <mdz> this will all be obsoleted when we unify the hardware detection
[10:15] <lamont_r> ok
[10:16] <amu> k
[10:16] <lamont_r> mdz: was thinking of steming the flow of user bug reports by having one there already.
[10:16] <lamont_r> but then, users don't read.
[10:17] <amu> test with many hardware today, the cd itself is functional, should i dl the latest for a final test ?
[10:17] <lamont_r> still need to generate one more with WinFOSS 0.4
[10:17] <lamont_r> which is downloading now to my laptop, while I kill time at the coffee shop downloading the release i386 iso
[10:18] <lamont_r> jdub prolly not awake yet, eh?
[10:19] <amu> lamont_r: got too much problems building on amd64 in the chroot, i'm moving now to i386 pure, which is also faster ;)
[10:19] <lamont_r> amu: no surprise there
[10:20] <amu> exefile on the computer, that look strange ;)
[10:20] <lamont_r> yeah
[10:28] <lucas_> arg my touchpad is not broken. This is good news for me and bad news for the ubuntu devel who will help me debug this ;-)
[10:30] <amu> touchpad on the ibm R40 is also not working *ducks*
[10:30] <lucas_> amu: can you define not working ?
[10:30] <lucas_> not working at all ?
[10:30] <lucas_> or you just can't click ?
[10:30] <amu> my does not move
[10:30] <amu> my=mouse
[10:30] <lamont_r> mdz: I don't think there's really anything else to put in it...
[10:30] <lucas_> ok
[10:31] <amu> lucas_: .... -7 live-CD
[10:33] <amu> 33 matches for winfoss :)
[10:35] <lamont_r> amu: www.theopencd.net
[10:40] <amu> got it, nice idea
[10:49] <amu> dammed, gpg should be global accepted ;)
[11:00] <lamont_r> wow - someone quit hogging bandwidth. :-)
[11:03] <amu> lamont_r: wondershaper is your best friend
[11:04] <lamont_r> amu: sharing coffee shop's bandwidth with the rest of the patrons... No control over shaping
[11:05] <lamont_r> interesting that either I'm on the tail end of the torrent, or something... 76Kdown, 10Kup
[11:05] <TMIegel> hi
[11:05] <TMIegel> i can't boot the LiveCD with my USB-CDRom
[11:06] <TMIegel> have tried all the boot-options in the menu, but it can't find the morphix-filesystem afterwards
[11:12] <amu> TMIegel: boot in general works ? which point system stops booting ?
[11:12] <nictuku> Hi! How can I tell if it's ok for you guys if I register a ubuntu.* domain for a community.
[11:15] <Ng> is it at all possible to get a newer gksudo into Ubuntu?
[11:15] <Ng> unless I'm being dumb the currently included version can't pass arguments to the command it executes
[11:15] <Ng> but the newer versions in debian do seem to offer that
[11:16] <TMIegel> amu: booting works, i get to the menu, then then it loads some scsi-modules but then it can'T access the cdrom
[11:16] <lamont_r> Ng: debian versions should sync into hoary when it opens
[11:16] <lamont_r> But warty is, well, like, _done_.
[11:16] <amu> TMIegel: did you tried with bootparameter noscsi ?
[11:16] <TMIegel> it tries /dev/hd?[1-9] [0-9]
[11:16] <gma> I work for a company that is keen to convert quite a few of our standard PC users from win2k to Linux. we were just about to deploy UserLinux, but after two days with a Ubuntu box our IT people were sold on it. we'll be deploying the first boxes shortly, and are very impressed by what you've put together. so thanks very much.
[11:17] <Ng> lamont_r: ok. what's the policy for updates to released versions? security only?
[11:17] <TMIegel> no, i will
[11:17] <lamont_r> Ng: that's on the wiki, but basically security or critical data corruption type issues
[11:17] <amu> TMIegel: ok
[11:17] <lamont_r> we get paid to do them for main/restricted, universe is merely subject to those policies for community uploads.
[11:18] <lamont_r> or something like that
[11:18] <Ng> lamont_r: great, thanks :)
[11:18] <TMIegel> amu: no, doesn't work either. i have also tried usbboot=on
[11:19] <nictuku> I dont mean to bother, but has my question about domain registration got in? this epic client is strange. hehe
[11:19] <amu> TMIegel: what happen, if you boot with noscsi ?
[11:20] <TMIegel> amu: then it doesn't load the scsi modules, but same problem. it only detects the harddisk, but not the usb-cdrom
[11:20] <lamont_r> nictuku: second
[11:22] <amu> TMIegel: you usb-cdrom use the default usb-modules ? usb-uhci and usb-starage ?
[11:22] <TMIegel> amu: after enabling dma for hda it gives: "Warning: unable to find base module!"
[11:22] <lamont_r> nictuku: biggest issue is that the folks who would know the answer to that question are predominantly in .uk, where it's 2220 on a release night...
[11:22] <nictuku> hehe.
[11:23] <amu> TMIegel: ah, try "nodma"
[11:23] <TMIegel> amu: i think so. the gentoo-minimal-install-cd 2004.2 works finde
[11:23] <amu> TMIegel: probably a bug .....
[11:24] <amu> TMIegel: together noscsi nodma
[11:26] <TMIegel> amu: no, no go. same warning (and it doesn't detect hda then...)
[11:27] <amu> lamont_r: pls note, bug: booting with usb-cdrom
[11:28] <amu> lamont_r: probably same with firewire
[11:28] <lamont_r> probably
[11:28] <nictuku> do you personally believe it's ok to register that, lamont?
[11:29] <amu> I've a idea how to fix it, but how i can test ... missing hardware
[11:29] <nictuku> thanks :)
[11:29] <lamont_r> amu: same issue here
[11:29] <amu> TMIegel: you're fine for a personal betatest ?
[11:29] <lamont_r> nictuku: I really dunno what the opinion would/should be, hence I'll limit myself to pointing in the direction of a definitive answer.
[11:30] <TMIegel> amu: sure
[11:32] <nictuku> That is very fine lamont, I thank you for that. Sorry if I sounded unpolite.
[11:33] <TMIegel> ok, knoppix (latest) works fine: after enabling dma for hda it states "Accessing KNOPPIX CDROM at /dev/scd0 ..."
[11:34] <amu> TMIegel: I guess the order ( loading the usb modules ) is important/wrong on the liveCD
[11:35] <TMIegel> i have startet dl'ing the install cd and give that a try...
[11:35] <lamont_r> nictuku: not at all.  I just _need_ to not be giving anything like a definitive answer, or even opinion on that topic.
[11:36] <nictuku> I understand. I shall wait! =]
[11:37] <amu> TMIegel: ^k, letme know if it works there
[11:37] <lamont_r> amu: I have a USB cdrom, but I don't think the laptopwill boot from USB...
[11:37] <amu> lamont_r: and your desktop ?
[11:39] <lamont_r> almost certain it has the same issue.
[11:39] <lamont_r> OTOH, there might be another machine that would...
[11:39] <amu> lamont_r: newer bioses, detect the usb-device only if it's plugged in. After you plugged in intu a slot, you see the option on your bios. Without a connected device no option
[11:39] <lamont_r> right
[11:40] <nictuku> where can I find ubuntu's logo usage policy? couldn't find in the wiki.
[11:42] <nictuku> hhmm /legal
[11:42] <amu> http://www.pro-linux.de/news/2004/7409.html
[11:43] <mdz> nictuku: I believe jdub was writing it up
[11:44] <Ng> is it bad form (or even possible) to mark bugs as duplicates in bugzilla? should I leave a comment saying it's a duplicate? email the assignee? :)
[11:44] <Ng> I suppose that question really is "does anyone mind if I triage some bugs?" :)
[11:49] <TMIegel> amu: i'll go to bed know, i will try the install cd tomorrow, will you be here then?
[11:53] <TMIegel> i will see, god night everyone...
[11:54] <__daniel> bye TMIegel
[11:54] <__daniel> TMIegel, schlaf gut :-)
[11:54] <amu> TMIegel: yap


[01:42] -queuebot:#ubuntu-release- New binary: oops [amd64] (disco-proposed/universe) [0.0.14-0ubuntu1] (no packageset)
[06:18] <cpaelzer> Laney: do you think the following might be related to the new autopkgtest?
[06:18] <cpaelzer> test on vagrant-libvirt (trigger libvirt upload in cosmic-proposed)
[06:18] <cpaelzer> new bad results, all skipped but evaluated as "fail"
[06:18] <cpaelzer><EMAIL_ADDRESS>[06:18] <cpaelzer><EMAIL_ADDRESS>[06:19] <cpaelzer> an example of an old good result looks exactly the same to me
[06:19] <cpaelzer><EMAIL_ADDRESS>[07:30] <ginggs> does anyone know what happened to python-pyftpdlib's autopkgtest results?
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [amd64] (disco-proposed) [3.1.11+ds-1]
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [armhf] (disco-proposed) [3.1.11+ds-1]
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [ppc64el] (disco-proposed) [3.1.11+ds-1]
[08:00] -queuebot:#ubuntu-release- New: accepted oops [amd64] (disco-proposed) [0.0.14-0ubuntu1]
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [arm64] (disco-proposed) [3.1.11+ds-1]
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [s390x] (disco-proposed) [3.1.11+ds-1]
[08:00] -queuebot:#ubuntu-release- New: accepted deepin-music [i386] (disco-proposed) [3.1.11+ds-1]
[08:28] <doko> LocutusOfBorg: you synced vtk7, now having unresolved dependencies on armhf and arm64
[08:38] <doko> Logan: second gudhi  ping. you dropped necessary Ubuntu changes
[09:34] <Laney> cpaelzer: we need to handle exit 8 as passed I think
[09:57] <cpaelzer> Laney: is that a new rc for this kind of skip now?
[09:57] <Laney> yes
[09:57] <Laney> 'all skipped'
[09:57] <Laney> in Debian they call it a 'neutral' result
[09:59] <Laney> I copied that a bit here: http://autopkgtest.ubuntu.com/packages/vagrant-libvirt/cosmic/armhf
[09:59] <Laney> but britney should now see it as a pass
[10:01] <cpaelzer> so that made even my old results "neutral" as I see
[10:01] <cpaelzer> no need to rerun them
[10:01] <cpaelzer> great
[10:01] <cpaelzer> I'll wait for the next update to excuses (on cosmic actually) and let you know if it is no more red there
[10:18] <tkamppeter> Hi, cups-filters and poppler are stuck in disco-proposed for no obvious reason, they are both "Valid Candidate", what is happening here?
[10:18] <Laney> a transition, see update_output.txt
[10:19] <tkamppeter> Where do I find update_output.txt?
[10:20] <Laney> replace update_excuses.html with update_output.txt :-)
[10:20] <seb128> speaking of which, does anyone understand from update_output.txt what's the status
[10:20] <seb128> that's a long list, another transition got in between the poppler one clearing off?
[10:21] <Laney> hunspell did
[10:21] <Laney> dunno what the rest of this stuff is
[10:21] <Laney> looking forward to Till helping :>
[10:21] <seb128> :)
[10:23] <LocutusOfBorg> doko, I know, I'm already looking at it
[10:23] <LocutusOfBorg> hello, please update ubuntu-release hint: force-badtest ocfs2-tools/1.8.5-6ubuntu1/s390x and add force-badtest ocfs2-tools/1.8.5-7/s390x
[10:23] <LocutusOfBorg> also, please update force-badtest symfony/3.4.19+dfsg-1ubuntu1 to force-badtest symfony/3.4.20+dfsg-1ubuntu1 thanks
[10:23] <tkamppeter> What does this cryptic stuff in update_output.txt all mean?
[10:23] <LocutusOfBorg> thanks
[10:23] <Laney> tkamppeter: you n ever helped with a transition before?
[10:23] <Laney> LocutusOfBorg: send a merge proposal please
[10:23] <Laney> tkamppeter: https://wiki.ubuntu.com/ProposedMigration/ might help you
[10:23] <tkamppeter> no, I never ran into such a situation?
[10:25] <Laney> k, well first step is to get perl to go to become a valid candidate
[10:25] <Laney> s/go to//
[10:30] <tkamppeter> I have read the doc now and so it seems that poppler and cups-filters a skipped as they cause problems on s390x.
[10:45] <Laney> darkxst: you fixing radare2? your libzip transition
[11:12] <LocutusOfBorg> Laney, https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/360662
[11:12] <LocutusOfBorg> thanks!
[11:13] <LocutusOfBorg> question about mariadb<EMAIL_ADDRESS>[11:13] <LocutusOfBorg> the testsuite is now mostly good, except for ppc64el where this test fails
[11:13] <LocutusOfBorg> they insert into a table this value: 0.6158
[11:13] <LocutusOfBorg> and this check fails:  where key1 <= 0.6158 and key2 >= 1.3762;
[11:14] <LocutusOfBorg> because the stored value is:
[11:14] <LocutusOfBorg> -0.6158000230789185
[11:14] <LocutusOfBorg> +0.6157999634742737
[11:14] <LocutusOfBorg> any clue? should I just don't care?
[11:14] <LocutusOfBorg> I'm asking here because we have glibc folks :)
[11:14] <Laney> suggest #ubuntu-devel
[11:36] <jbicha> could an AA remove radare2 3.1.2+dfsg-1 from disco-proposed and restore 3.0.1+dfsg-1build1 since the new version doesn't build on some arches?
[11:41] <LocutusOfBorg> jbicha, I don't think so
[11:41] <LocutusOfBorg> https://github.com/radare/radare2/commit/5549ad61608b90c65cdb6f5144ce137ce43da5e4
[11:41] <LocutusOfBorg> seems Laney did some good work there :D
[11:41] <jbicha> ok
[11:42] <apw> Laney, ^ can we assume you are on the case ?
[11:42] <apw> (rather than doing any kind of removal dance)
[11:42] <Laney> I've fixed it
[11:43] <LocutusOfBorg> <3
[11:43] <Laney> It was easier than requesting the removal once you actually looked at the problem
[11:50] <LocutusOfBorg> Laney, do you have a picture of what is missing for the big migration?
[11:50] <LocutusOfBorg> vtk is getting green in some hours
[11:51] <LocutusOfBorg> mia might need a tweak again...
[11:51] <ypwong> is there daily images for 18.04.2?
[11:51] <ypwong> need to test this on machines with new nvidia cards
[11:52] <Laney> ypwong: usual place http://cdimage.ubuntu.com/bionic/daily-live/
[11:54] <Laney> LocutusOfBorg: let's see again when vtk is good
[11:55] <ypwong> Laney, the page says <IP_ADDRESS> [sic]
[11:55] <Laney> it's dailies of what's in bionic atm
[11:56] <ypwong> and the manifest says it's using 4.15 linux-image
[11:57] <ypwong> when will daily images with 4.18 start to be built?
[11:57] <jbicha> LocutusOfBorg: update_output.txt suggests we may only need radare2 and vtk7 to finish the transition
[12:04] <LocutusOfBorg> jbicha, Laney I agree, I see only vtk* stuff entangled, but more eyes, better :D
[12:04] <LocutusOfBorg> at the end poppler got entangled anyway
[12:07] <LocutusOfBorg> just FYI, I plan to do haskell once this one migrates
[12:07] <LocutusOfBorg> and also hdf5
[12:07] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/hdf5/1.10.4+repack-1
[12:07] <LocutusOfBorg> *please do not retry it yet*
[12:10] <jbicha> yeah, I intentionally cancelled hdf5 at the beginning in hopes it would make our transition easier
[13:45] -queuebot:#ubuntu-release- New sync: ratchet-rfc6455 (disco-proposed/primary) [0.2.4-2]
[13:46] <LocutusOfBorg> this was lost ^^
[13:46] <LocutusOfBorg> useful to make some php migration
[13:47] <coreycb> RAOF: hello, if you have a moment for an SRU review today I'd like to get nova landed from the bionic unapproved queue.
[14:15] <LocutusOfBorg> vtk is finishing, publisher + britney...
[14:15]  * LocutusOfBorg modulo testsuites
[14:17] <oSoMoN> dear SRU team, could you please consider accepting libreoffice{,-l10n} 1:6.1.3-0ubuntu<IP_ADDRESS> in cosmic-proposed? thanks!
[14:22] <seb128> bdmurray, ^
[14:24] -queuebot:#ubuntu-release- New: rejected ratchet-rfc6455 [sync] (disco-proposed) [0.2.4-2]
[14:27] <LocutusOfBorg> wtf^^^
[14:36] <Laney> someone please clean up nbs in proposed for radare2?
[14:40] <apw> Laney, looking
[14:41] <Laney> thx
[14:41] <apw> Laney, gone
[14:42] <Laney> 🤸
[14:42] <Laney> thanks!
[14:42] <LocutusOfBorg> oh, I was going to ask the same!
[14:42] <LocutusOfBorg> :'(
[14:46] <apw> ?
[14:48] <LocutusOfBorg> to nbs cleanup :)
[14:53] <apw> LocutusOfBorg, and the sad face ?
[14:53] <LocutusOfBorg> because somebody beat me to it :p
[14:53] <LocutusOfBorg> I wish I knew how to do that unicode stuff you all use :p
[14:54] <LocutusOfBorg> ☺
[14:54] <Laney> gnome-characters shell search provider
[14:54] <LocutusOfBorg> ohhhhhhhh
[14:54] <LocutusOfBorg> 💋
[14:54]  * LocutusOfBorg stops
[14:55] <apw> Laney, oh was there one of those on the the line before the thanks! ?  empty here
[14:55] <LocutusOfBorg> yes apw it was somebody doing a wheel or similar
[14:56] <Laney> tsk tsk apw
[14:56] <LocutusOfBorg> apw, would you agree to use your super AA power to remove all the unicode stuff from Ubuntu? thanks!
[14:56] <apw> i see most of your fun ones, i wonder why that one isn't there
[14:57] <LocutusOfBorg> by coming back to ascii, we would fix a lot of stuff
[14:58]  * LocutusOfBorg wonders why he did install gnome-characters
[15:01] <jbicha> LocutusOfBorg: make sure you have the apt version of gnome-characters since I believe the snap version doesn't support that feature yet
[15:01] <LocutusOfBorg> it works
[15:02] <jbicha> Characters works, but not the GNOME Shell search provider for it
[15:03] <Laney> k, far enough off topic now I think
[15:20] <LocutusOfBorg> we are waiting for the big migration, off topic is a must :D
[15:22] <cpaelzer> Laney: the armhf Skip on vagrant-libvirt is stll treded as Regression on https://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html
[15:22] <cpaelzer> it is neutral on http://autopkgtest.ubuntu.com/packages/v/vagrant-libvirt/cosmic/armhf thou
[15:22] <cpaelzer> can we do something to make it pick up the new result=
[15:22] <cpaelzer> or is netural sill a regression for that level of the tooling?
[15:22] <cpaelzer> +t
[15:23] <Laney> retry it, I guess britney has cached the failure
[15:24] <cpaelzer> ok, retry scheduled
[15:24] <Laney> sorry about that, shouldn't happen any more
[15:24] <cpaelzer> all fine, as long as we can sort it out that is ok
[15:25] <cpaelzer> you could not add a line if package=systemd|linux set flaky attribute no matter what?
[15:26]  * LocutusOfBorg tries to sync again ratchet-rfc6455
[15:28] <Laney> heh
[15:28] <Laney> I'd rather be more strict on those packages than less... given what they are ...
[15:30] -queuebot:#ubuntu-release- New source: ratchet-rfc6455 (disco-proposed/primary) [0.2.4-2build1]
[15:42] -queuebot:#ubuntu-release- Unapproved: alsa-lib (cosmic-proposed/main) [1.1.6-1ubuntu1 => 1.1.6-1ubuntu1.1] (core)
[15:47] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-141.167~14.04.1] (kernel)
[16:08] -queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (cosmic-proposed/main) [3.30.1-1ubuntu1 => 3.30.2-0ubuntu1] (ubuntu-desktop)
[16:13] <LocutusOfBorg> Laney, question:
[16:13] <LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/v/vtk7/disco/armhf
[16:13] <LocutusOfBorg> doesn't show a run against 7.1.1+dfsg1-11ubuntu1
[16:14] <LocutusOfBorg> but updates_excuses reports it as green
[16:14] <Laney> wait
[16:14] <Laney> they both independently fetch their results, no synchronisation
[16:15] <LocutusOfBorg> mmm ok, strange that britney picked up them in advance then...
[16:15] <LocutusOfBorg> I remember you doing changes to make the autopkgtest result page "instantly updated" (for some values of instantly(
[16:19] <bdmurray> cyphermox: What's up with this autopkgtest failure for ubuntu-image w/ the grub2 in -proposed for Xenial?
[16:21] <Laney> it's not strange at all, that's a consequence of what I said
[16:21] <LocutusOfBorg> got it
[16:22]  * LocutusOfBorg hopes in the next run
[16:22] <LocutusOfBorg> the notest page is already good
[16:22] <LocutusOfBorg> please somebody unblacklist ghc, but allow manual syncs
[16:22] <LocutusOfBorg> not automatic please, so I can sync in order
[16:23] <jbicha> LocutusOfBorg: there is a cheat you can use to skip the blacklist…
[16:25] <cjwatson> Right, and that is the only way to achieve wheat you're asking for
[16:25] <cjwatson> *what
[16:27] <cjwatson> You can hack the client-side check out of a local copy of syncpackage, or use copy-package from lp:ubuntu-archive-tools
[16:27] <LocutusOfBorg> mmm last time I just used "syncpackage"
[16:27] <LocutusOfBorg> meh I might be wrong, thanks
[16:27] <LocutusOfBorg> I'll look once the stuff migrates
[16:27] <cjwatson> The only way we can "unblacklist ghc, but allow manual syncs" without also allowing automatic syncs would be to turn off autosyncs entirely
[16:28] <cjwatson> Perhaps last time you did it when autosyncs were disabled for some other reason
[16:28] <cjwatson> Easy enough to "cp /usr/bin/syncpackage ." and hack out the check though :)
[16:28] <LocutusOfBorg> oh yes, it was at the begin of the cycle, yes!
[16:28] <jbicha> I think there was also a much shorter haskell-related blacklist last time
[16:28] <LocutusOfBorg> sure, I'm already hacking the changes :D thanks
[16:28] <cyphermox> bdmurray: network error unrelated to grub.
[16:29] <jbicha> and wildcards are funny in that file, the wildcards prevent auto-syncing but not manually syncing
[16:29] <cjwatson> They do?  That's a syncpackage bug then
[16:29] <cjwatson> Possibly we never got round to updating syncpackage to handle the wildcard syntax
[16:30] <bdmurray> cyphermox: Can you add a comment in the SRU bug, after that I'll release it.
[16:31] <cyphermox> bdmurray: done
[16:37] <LocutusOfBorg> its in!
[16:41] <cjwatson> https://code.launchpad.net/~cjwatson/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/360689 fixes this syncpackage behaviour, if anyone would like to review it
[16:45] <LocutusOfBorg> ghc started
[16:46]  * LocutusOfBorg does check it
[16:48] <jamespage> bdmurray, vorlon: can I get your view on https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1805355
[16:48] <LocutusOfBorg> cjwatson, good, I commented on the bug!
[16:48] <jamespage> I'd like to get cosmic and the UCA for OpenStack Rocky back in sync; ceph 13.2.1 slipped out of cosmic due to MIR lag
[16:50] <cjwatson> LocutusOfBorg: thanks
[16:55] <bdmurray> jamespage: I didn't feel great about reviewing it b/c of the size / length of the diff.
[17:01] <jamespage> bdmurray: yes it will be huge as its a stable release major version bump; my supporting fact is that we have tested extensively with the proposed version during cosmic development, and its what's in the Rocky UCA for Bionic.
[17:02] <jamespage> the diff between what we tested on cosmic and the version in the queue is a fix to my 32-bit support patch for the radosgw component which is covered under bug 1805145
[17:04] <jamespage> bdmurray: reviewing the full diff is probably not practical for this one
[17:07] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.3-0ubuntu<IP_ADDRESS>]
[17:09] -queuebot:#ubuntu-release- New binary: hdf5 [s390x] (disco-proposed/universe) [1.10.4+repack-1] (kubuntu)
[17:10] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (cosmic-proposed) [1:6.1.3-0ubuntu<IP_ADDRESS>]
[17:12] -queuebot:#ubuntu-release- New binary: hdf5 [ppc64el] (disco-proposed/universe) [1.10.4+repack-1] (kubuntu)
[17:20] -queuebot:#ubuntu-release- New binary: zimlib [ppc64el] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: zimlib [amd64] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: zimlib [i386] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:21] <bdmurray> jamespage: okay, I'll look at it now
[17:21] <jamespage> bdmurray: thanks
[17:33] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (cosmic-proposed) [13.2.1+dfsg1-0ubuntu<IP_ADDRESS>]
[17:36] -queuebot:#ubuntu-release- New binary: hdf5 [amd64] (disco-proposed/universe) [1.10.4+repack-1] (kubuntu)
[17:36] -queuebot:#ubuntu-release- New binary: zimlib [s390x] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: zimlib [arm64] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:41] -queuebot:#ubuntu-release- New binary: zimlib [armhf] (disco-proposed/universe) [4.0.4-4] (no packageset)
[17:43] -queuebot:#ubuntu-release- New: accepted ratchet-rfc6455 [source] (disco-proposed) [0.2.4-2build1]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [arm64] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [i386] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [s390x] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [amd64] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [ppc64el] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted zimlib [armhf] (disco-proposed) [4.0.4-4]
[17:43] -queuebot:#ubuntu-release- New: accepted hdf5 [amd64] (disco-proposed) [1.10.4+repack-1]
[17:43] -queuebot:#ubuntu-release- New: accepted hdf5 [s390x] (disco-proposed) [1.10.4+repack-1]
[17:43] -queuebot:#ubuntu-release- New: accepted hdf5 [ppc64el] (disco-proposed) [1.10.4+repack-1]
[17:45] -queuebot:#ubuntu-release- New binary: ratchet-rfc6455 [amd64] (disco-proposed/none) [0.2.4-2build1] (no packageset)
[18:03] -queuebot:#ubuntu-release- Unapproved: accepted rdma-core [source] (cosmic-proposed) [19.0-1ubuntu0.1]
[18:14] -queuebot:#ubuntu-release- Unapproved: rejected cups [source] (cosmic-proposed) [2.2.8-5ubuntu2]
[18:22] -queuebot:#ubuntu-release- Unapproved: accepted e2fsprogs [source] (cosmic-proposed) [1.44.4-2ubuntu0.1]
[18:28] -queuebot:#ubuntu-release- Unapproved: accepted libtorrent-rasterbar [source] (cosmic-proposed) [1.1.9-1ubuntu0.1]
[18:31] -queuebot:#ubuntu-release- Unapproved: accepted gnome-tweaks [source] (cosmic-proposed) [3.30.2-0ubuntu1]
[18:38] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (cosmic-proposed) [2.0.874-5ubuntu9.2]
[18:41] -queuebot:#ubuntu-release- Unapproved: e2fsprogs (bionic-proposed/main) [1.44.1-1 => 1.44.1-1ubuntu1] (core)
[18:44] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (cosmic-proposed) [1.12.4-1ubuntu1.2]
[18:47] <vorlon> bdmurray: ^^ sorry, I uploaded e2fsprogs for bionic only after you accepted the one for cosmic
[18:57] <bdmurray> vorlon: alright, I should be able to remember what its about
[18:57] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.5]
[19:00] -queuebot:#ubuntu-release- Unapproved: accepted e2fsprogs [source] (bionic-proposed) [1.44.1-1ubuntu1]
[19:01] -queuebot:#ubuntu-release- Unapproved: rejected cups [source] (bionic-proposed) [2.2.7-1ubuntu2.2]
[19:08] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (bionic-proposed) [3.0.3-0ubuntu1~18.04.1]
[19:21] <coreycb> bdmurray: hello, when you have a moment would you be able to review nova from the bionic unapproved queue?
[19:41] -queuebot:#ubuntu-release- New: accepted xorg-server-hwe-18.04 [source] (bionic-proposed) [2:1.20.1-3ubuntu2.1~18.04.1]
[19:48] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [s390x] (bionic-proposed/none) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[19:49] -queuebot:#ubuntu-release- New source: xf86-input-wacom-hwe-18.04 (bionic-proposed/primary) [1:0.36.1-0ubuntu1~18.04.1]
[19:49] -queuebot:#ubuntu-release- New source: xserver-xorg-input-evdev-hwe-18.04 (bionic-proposed/primary) [1:2.10.6-1~18.04.1]
[19:50] -queuebot:#ubuntu-release- New source: xserver-xorg-input-joystick-hwe-18.04 (bionic-proposed/primary) [1:1.6.3-1build1~18.04.1]
[19:50] -queuebot:#ubuntu-release- New source: xserver-xorg-input-libinput-hwe-18.04 (bionic-proposed/primary) [0.28.1-1~18.04.1]
[19:50] -queuebot:#ubuntu-release- New source: xserver-xorg-input-synaptics-hwe-18.04 (bionic-proposed/primary) [1.9.1-1ubuntu1~18.04.1]
[19:50] -queuebot:#ubuntu-release- New source: xserver-xorg-video-amdgpu-hwe-18.04 (bionic-proposed/primary) [18.1.0-1~18.04.1]
[19:51] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [ppc64el] (bionic-proposed/main) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[19:51] -queuebot:#ubuntu-release- New source: xserver-xorg-video-ati-hwe-18.04 (bionic-proposed/primary) [1:18.1.0-1~18.04.1]
[19:51] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [i386] (bionic-proposed/main) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[19:51] -queuebot:#ubuntu-release- New source: xserver-xorg-video-nouveau-hwe-18.04 (bionic-proposed/primary) [1:1.0.15-3~18.04.1]
[19:51] -queuebot:#ubuntu-release- New source: xserver-xorg-video-fbdev-hwe-18.04 (bionic-proposed/primary) [1:0.5.0-1ubuntu1~18.04.1]
[19:52] -queuebot:#ubuntu-release- New source: xserver-xorg-video-qxl-hwe-18.04 (bionic-proposed/primary) [0.1.5-2build2~18.04.1]
[19:52] -queuebot:#ubuntu-release- New source: xserver-xorg-video-vmware-hwe-18.04 (bionic-proposed/primary) [1:13.3.0-2build1~18.04.1]
[19:52] -queuebot:#ubuntu-release- New source: xserver-xorg-video-vesa-hwe-18.04 (bionic-proposed/primary) [1:2.4.0-1~18.04.1]
[19:53] <bdmurray> coreycb: there are 2 uploads, I assume you want the newer one?
[19:53] -queuebot:#ubuntu-release- New source: xorg-hwe-18.04 (bionic-proposed/primary) [1:7.7+19ubuntu8~18.04.1]
[19:53] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [amd64] (bionic-proposed/main) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[19:53] <coreycb> bdmurray: yes sir
[19:54] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (bionic-proposed) [2:17.0.7-0ubuntu1]
[19:58] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [arm64] (bionic-proposed/main) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[19:59] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.7-0ubuntu1]
[20:01] -queuebot:#ubuntu-release- New binary: xorg-server-hwe-18.04 [armhf] (bionic-proposed/main) [2:1.20.1-3ubuntu2.1~18.04.1] (no packageset)
[20:01] -queuebot:#ubuntu-release- Unapproved: accepted pytango [source] (xenial-proposed) [8.1.8-1ubuntu0.1]
[20:03] -queuebot:#ubuntu-release- Unapproved: rejected cups [source] (xenial-proposed) [2.1.3-4ubuntu0.6]
[20:06] <coreycb> bdmurray: thanks as always
[20:11] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.7]
[20:12] <cpaelzer> Laney: the re-test did unblock the "neutral" test from Britneys POV as well
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted mountall [source] (trusty-proposed) [2.53ubuntu1]
[20:13] <cpaelzer> bdmurray: hi, I saw you accepting libvirt on 1787405
[20:13] <cpaelzer> bdmurray:  I wonder what we should do about qemu and the systemd tests
[20:13] <cpaelzer> the test breakage is in no way related to the uploads
[20:14] <cpaelzer> I had suggested solutions in bug 1806347 - but there was no response at all on my MPs to add overrides so I removed them, nor were there a response on the bug itself
[20:14] <cpaelzer> I'm not sure what to do to unblock this SRU - I can easily re-open the britney MPs if you'd be willing to review and accept them
[20:15] <cpaelzer> The branches still existhttps://code.launchpad.net/~paelzer/britney/hints-ubuntu-cosmic-sru-systemd https://code.launchpad.net/~paelzer/britney/hints-ubuntu-bionic-sru-systemd
[20:18] <bdmurray> cpaelzer: I think the hints changes make sense although the comment seems like wishful thinking
[20:18] <cpaelzer> since I'm actually off - I added new MPs back to bug 1806347 in case you agree to mask them for now
[20:18] <cpaelzer> bdmurray: hope dies last
[20:18] <cpaelzer> I'd also leave the bug open for xnox to consider masking just the few subtests that are flaky
[20:19] <cpaelzer> as that would make the dep8 tests overall more meaningful
[20:19] <cpaelzer> currently nobody gives a penny about them as the assumption always is "ah flaky again"
[20:19] <cpaelzer> just the rate of success recently is so bad ...
[20:20] <cpaelzer> actually let me check if the version of systemd is still correct
[20:20] <cpaelzer> as IIRC xnox did backport some of the fixes we did in Disco
[20:20] <cpaelzer> yeah there are newer version now, let me bump my MPs versions
[20:22] <cpaelzer> B-proposed has 237-3ubuntu10.10 and my bionic MP has old&new
[20:23] <cpaelzer> C-propsoed has the newer 239-7ubuntu10.5 which didn't exist when I created the overrides - let me check the results of this ...
[20:24] <cpaelzer> those seem only too bad on x86 and I need the new version
[20:26] <cpaelzer> ok the Bionic MP is still good and I updated the Cosmic MP now
[20:27] <cpaelzer> bdmurray: consider merging those for the current versions of systemd
[20:27] <cpaelzer> I could then retry Cosmic-nonx86 with triggers on the newer version which should hopefully work more often than not
[20:28] -queuebot:#ubuntu-release- Unapproved: ca-certificates (trusty-proposed/main) [20170717~14.04.1 => 20170717~14.04.2] (core)
[20:28] -queuebot:#ubuntu-release- Unapproved: ca-certificates (xenial-proposed/main) [20170717~16.04.1 => 20170717~16.04.2] (core)
[20:42] -queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.26 => 20101020ubuntu451.27] (core)
[20:43] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.2 => 1.33.1~16.04.3] (core)
[20:51] -queuebot:#ubuntu-release- Unapproved: debian-installer (trusty-proposed/main) [20101020ubuntu318.44 => 20101020ubuntu318.45] (core)
[20:54] <ddstreet> bdmurray btw the trusty/xenial uploads for ca-certificates and debian-installer are linked, ca-certificates needs to go into the archive and build first before debian-installer builds
[22:55] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.33.1~16.04.3]
[22:58] <vorlon> Laney: thanks for 0ff44d90e7b9b3f44e80cc0b41af548a37242dfd , retrying http://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/disco/armhf
[22:58] <vorlon> (and some others)
[23:38] <doko> LocutusOfBorg: why are you starting a haskell transition with the current state of the archive?
[23:40] <doko> vorlon, Laney, infinity, whoever from the release team: what's your plan to get the pending transitions done?
[23:41] <vorlon> doko: I don't know what transitions are pending, and it's not the responsibility of the release team to finish them?
[23:43] <doko> I disagree. Maybe not the responsibility of finishing them, but the responsibility of not adding new stuff. I can't be the only one to ask for stop of autosyncs
[23:43] <vorlon> exactly zero people have asked me to stop autosyncs
[23:43] <doko> so who watches and who cares if things are still managable?
[23:45] <vorlon> can we not talk in generalities? what transitions are you concerned about here?
[23:46] <doko> poppler and now ghc
[23:47] <vorlon> it looks to me like poppler has finished
[23:48] <doko> ohh, I didn't notice
[23:48] <vorlon> ghc: universe-only language which is not entangled with other software stacks and which I do not speak
[23:49] <doko> anyway, now ghc and it looks like a no-go for php and mysql
[23:49] <vorlon> no-go?
[23:49] <doko> but poppler finished is good news
[23:50] <doko> wait until ghc is finished
[23:52] <vorlon> ok


[00:20] <thumper> machine-0: 2014-04-11 00:19:50 INFO juju.worker.instanceupdater updater.go:264 machine "0" has new addresses: [public:localhost local-cloud:<IP_ADDRESS>]
[00:20] <thumper> localhost is public?
[00:21] <thumper> also...
[00:21] <thumper> $ juju destroy-environment local -y
[00:21] <thumper> ERROR readdirent: no such file or directory
[00:21] <thumper> where did that start coming from?
[00:27] <davecheney> thumper: that is um, wrong
[00:27] <davecheney> how does that even happy
[00:27] <davecheney> happen
[00:27] <davecheney> NewAddress requires you to give an address scope
[00:28] <thumper> davecheney: axw landed something in the last day that changed it
[00:28] <davecheney> thumper: i've been tinking that Address.Scope should be private
[00:28] <davecheney> then we can force every creation to go through a helper function
[00:31] <thumper> davecheney: chat with axw when he starts as he has done a lot of this
[00:31] <thumper> any one want to review the debug-log client hookup? https://codereview.appspot.com/85570044
[00:33] <wallyworld__> cmars: you got your lgtm, sorry about delay. i've been head down landing some critical 1.18 fixes
[00:33] <cmars> np, thanks wallyworld__
[00:34] <wallyworld__> thumper: suppose so
[00:40] <stokachu> if you remove juju-local juju-mongodb juju-core via apt-get with no bootstraped environment, the mongod process is still around
[00:40] <stokachu> is that intentional?
[00:41] <stokachu> this is 1.18 on trusty
[00:46] <thumper> stokachu: depends, do you have mongodb-server package?
[00:46] <stokachu> thumper: just juju-mongodb
[00:47] <stokachu> and its pointing to /usr/lib/juju/bin/mongod
[00:47] <thumper> probably unintentional
[00:48] <stokachu> ok ill probably file a bug because if you dont kill that process subsequent bootstraps will fail
[00:57] <thumper> wallyworld__: I talked with rog last night about the error
[00:58] <wallyworld__> ok
[00:58] <thumper> wallyworld__: he suggested that I change the connection error to a more generic NotSupported error
[00:58] <wallyworld__> agree that's better
[00:58]  * wallyworld__ doesn't like inconsistency
[00:58]  * thumper nods
[00:58] <thumper> I have found another problem though
[00:59] <thumper> but it is existing and elsewhere
[00:59] <thumper> I'll land this then fix the bug
[00:59] <wallyworld__> s/CodeIsNotImplemented/IsNotSupported :-)
[01:00] <thumper> well...
[01:00] <thumper> not implemented has a different meaning to not supported
[01:00] <thumper> not implemented implies that one day you might
[01:00] <thumper> but yes, agree in general
[01:00] <wallyworld__> sure, but we are using this as a mechanism to delete running against older api servers
[01:01] <wallyworld__> detect
[01:01] <wallyworld__> and failing back to 1dot16foo()
[01:02] <wallyworld__> sinzui: you'll see the email, but i got into 1.18 both john's fixes, for scp and downgrades. hopefully that will allow CI to work again
[01:07] <thumper> wallyworld__: do you want me to just use not implemented?
[01:07] <thumper> I'd be ok with that
[01:08] <wallyworld__> thumper: nah, let's go with the new error and promise hand on heart to port to using it everywhere appropriate :-)
[01:08] <thumper> fft
[01:08] <wallyworld__> the 1dot16 fallbacks will be disappearing anyway
[01:08] <thumper> like that'll happen
[01:08] <thumper> yeah, I also renamed it fallback from 1.16 to 1.18
[01:13] <sinzui> wallyworld__, I am hopeful that 	lp:juju-core/1.18 r2267 will pass. The azure-deploy test is very ill. I think we need to review both the test and azure cloud itself
[01:14] <wallyworld__> ok, we can ask axw for input there perhaps
[01:14] <axw> ?
[01:14] <axw> azure is bad on 1.18?
[01:14] <wallyworld__> axw: sinzui says there are issues with the azure CI test not working
[01:15] <wallyworld__> i haven't looked yet, but perhaps we need to review what's being tested and how
[01:15] <wallyworld__> to see where the issue is
[01:15] <axw> is there a bug I can look at?
[01:15] <axw> or build failure
[01:15] <axw> CI build
[01:16] <wallyworld__> http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/azure-deploy/
[01:16] <axw> ta
[01:16] <sinzui> wallyworld__, I revert the changes that were made to help it pass
[01:16] <wallyworld__> thanks for looking, i'm flat out right now landing stuff
[01:17] <wallyworld__> sinzui: you mean the changes with regard to downgrades and scp changes?
[01:17] <sinzui> wallyworld__, axw. We increased the timeouts and tried to change the tools-metadata-url from stable to testing to help tests pass. The effoerts didn't help
[01:17] <wallyworld__> i saw the metadata url bug
[01:17] <axw> sinzui: what's going on? it's just hanging there?
[01:17] <sinzui> wallyworld__, the downgrades restoration fixes 1.18.
[01:17] <wallyworld__> \o/
[01:18] <wallyworld__> sinzui: i'm porting to trunk now, conflict to solve but should be landed soon
[01:18] <sinzui> In trunk no env will upgrade withing 30 minutes
[01:18] <axw> I see the last one failed in scp, but the current one is just stuck on bootstrap?
[01:18] <sinzui> The scp is secondary, though it also acts as a computability test
[01:20] <axw> 2014-04-11 01:20:06 ERROR juju.cmd supercommand.go:300 charm not found in "/var/lib/jenkins/repository": local:precise/dummy-source
[01:20] <axw> wat
[01:21] <sinzui> axw we tried replacing mysql and wordpress charms with charms the let us test just juju
[01:22] <sinzui> axw, we started on it earlier this week, then rushed it into use when we hoped to remove the many had starts that both of those charms have
[01:22] <sinzui> the next run will use mysql and wordpress
[01:23] <sinzui> In theory charm-testing is responsible for making sure that mysql and wordpress are sane.
[01:24] <axw> ok
[01:36] <axw> sinzui: which location do the azure tests run in?
[01:37] <sinzui> US West...the only location that has ever worked
[01:37] <axw> heh ok
[01:41] <davecheney> sinzui: thumper http://paste.ubuntu.com/7233131/
[01:41] <davecheney> gettng closer
[01:41] <davecheney> the ones maked failed > 600s
[01:41] <davecheney> are actually timeouts
[01:42] <davecheney> if the builder was faster (building gccgo at the same time)
[01:42] <davecheney> they may have passed
[01:42] <sinzui> well done
[01:42] <davecheney> SHIT
[01:42] <davecheney> is jesse around
[01:43] <davecheney> provider/common is still complaining about missing keys
[01:47] <axw> sinzui: I'm not convinced azure is entirely healthy, I'm getting errors I haven't seen before from the API
[01:47] <axw> e.g. the storage API refusing connections
[01:48] <axw> there's scheduled maintenance tomorrow on West US, I wonder if they started early on the "safe" parts
[01:49] <axw> though now I've said that, azure-deploy just passed
[01:49] <sinzui> axw, I see a lot of errors. The CI often reties. Azure is actually very healthy today. I only failed 4 out of 24 hours
[01:50] <axw> ok
[01:50] <axw> heh :)
[01:50] <sinzui> Blessed: lp:juju-core/1.18 r2267
[01:51] <axw> I have to backport another fix, but that's good to know
[02:00] <axw> wallyworld__: I'm about to backport the network addresses change - you're not already doing that, right?
[02:01] <wallyworld__> axw: no, i've been dealing with the other critical issues stopping CI from working
[02:01] <wallyworld__> just porting to trunk now from 1.18
[02:01] <axw> nps, thanks
[02:01] <axw> ah ok
[02:02] <wallyworld__> sinzui: does that mean you worked around the scp issues fixed by r2268?
[02:03] <sinzui> wallyworld__, we didn't succeed. It was a lower priority than getting a pass
[02:03] <wallyworld__> i'm not 100% sure, but maybe r2268 allows the original scripts to work?
[02:03] <sinzui> wallyworld__, the scp issue only comes into play when the test fail
[02:04] <wallyworld__> ah ok
[02:04] <wallyworld__> anyways, it's merged into 1.18 and heading to trunk so if the tests fail again.... :-)
[02:04] <sinzui> wallyworld__, http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/canonistack-deploy-devel/ didn't capture logs from the last tests
[02:05] <wallyworld__> yeah, that's r2267
[02:05] <wallyworld__> r2268 should hopefully cspture the logs
[02:06] <sinzui> CI's normal and fallback credentials are broken in canonistack. we cannot test it until the swift authentication issue is fixed. So every canonistack test will fail
[02:06] <wallyworld__> :-(
[02:49] <thumper> anyone? https://codereview.appspot.com/85570045/
[02:52] <sinzui> Blessed: lp:juju-core/1.18 r2270
[02:53] <waigani> thumper: I put some garbage into jujud/agent.go then ran cmd/juju/bootstrap_test.go TestTest: passes locally, fails on vm
[02:53] <thumper> \o/
[02:53] <thumper> wallyworld__: don't worry about the juju command there...
[02:53] <thumper> waigani: sorry that was for you
[02:53] <thumper> waigani: but check the others
[02:54] <thumper> waigani: although I do challenge that
[02:54] <thumper> waigani: if you delete ~/go/bin/jujud and rerun the test
[02:54] <thumper> waigani: what happens?
[02:55] <waigani> thumper: passes
[02:55] <thumper> waigani: what is the error on the vm?
[02:55] <waigani> https://bugs.launchpad.net/juju-core/+bug/1304767
[02:55] <_mup_> Bug #1304767: test failure in cmd/juju <ppc64el> <juju-core:In Progress by waigani> <https://launchpad.net/bugs/1304767>
[02:55] <waigani> thumper: I'll paste full error, hang on
[02:56] <thumper> waigani: also, run a make check to run all the tests
[02:56] <waigani> thumper: http://pastebin.ubuntu.com/7233312/
[02:56] <thumper> with a broken jujud you'll get a lot of failures
[02:56] <thumper> that I don't think should happen
[02:57] <thumper> heh
[02:57] <thumper> ok, to test locally
[02:57] <thumper> we should do something like this...
[02:57] <waigani> is it something to to with there not being a candidate match for 14.04:ppc ?
[02:57] <thumper> PatchValue(&version.Current.Series, "magic")
[02:58] <thumper> make the series be something it can never be anywhere
[02:58] <thumper> and you'll hit the same problem locally
[02:58] <thumper> (I think)(
[02:58] <waigani> thumper: still passes
[02:59] <thumper> hmm...
[02:59] <thumper> it is something like that...
[02:59] <thumper> patch it before the start of setup
[02:59] <waigani> ah okay
[02:59] <thumper> the conn suite will bootstrap in setup
[03:00] <waigani> thumper: still passes
[03:01] <thumper> it is something like that....
[03:01] <thumper> play a bit and break it
[03:01] <waigani> thumper: I'll keep debugging on the vm - slowly but surely
[03:02] <waigani> thumper: okay, I'm good at breaking things :)
[03:02] <waigani> I have to run and get my girl now
[03:03] <waigani> I've cornered the bug, with a bit more testing I should get it tonight.
[03:08] <thumper> waigani: found it
[03:08] <thumper> we patch version.Current, but don't patch arch.HostArch
[03:12] <sinzui> wallyworld__, https://bugs.launchpad.net/juju-core/+bug/1302205 bothers me. It is critical, but is not targeted to the current milestone. I can see you working on it. I want to move it to 1.19.0 to reflect how it is being treated
[03:12] <_mup_> Bug #1302205: manual provisioned systems stuck in pending on arm64 <add-machine> <hs-arm64> <manual-provider> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1302205>
[03:12] <thumper> sinzui: what is the plan fo releasing 1.19?
[03:13] <wallyworld__> sinzui: sure
[03:14] <sinzui> thumper, if 1.19.0 gets a passing rev today/tomorrow I might release it. lp:juju-core r2587  was the last time 1.19.0 passed.
[03:15] <sinzui> 1.18.1 has two passes today, so I think it is more likely to be released
[03:16]  * thumper nods
[03:28] <cmars> sinzui, i've marked 1303880 and 1295140 as fix-committed. fixes for these have landed in trunk & 1.18
[03:28] <sinzui> thank you cmars
[03:46] <axw> wallyworld__: backport for addresses fix, can you please review? https://codereview.appspot.com/86720043/
[03:46] <wallyworld__> sure
[03:51] <wallyworld__> axw: done, looks like a nice change
[03:52] <axw> wallyworld__: cheers
[04:02] <wallyworld__> davecheney: is this one you've seen before? http://pastebin.ubuntu.com/7233429/
[04:03] <wallyworld__> dannf: you still online?
[04:06] <sinzui> thumper: Maybe you can point a developer to work on bug 1306212. CI will fail trunk because of it
[04:06] <_mup_> Bug #1306212: juju bootstrap fails with local provider <bootstrap> <ci> <local-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1306212>
[04:11] <wallyworld__> sinzui: make him fix it himself :-P
[04:12] <wallyworld__> except, it may be HA related
[04:12] <sinzui> wallyworld__, I don't make fixes after midnight. I do dangerous things when I am tired
[04:12] <wallyworld__> sinzui: no, not you, thumper :-)
[04:12] <wallyworld__> i didn't mean you to fix it
[04:12] <wallyworld__> you need to go to bed!
[04:13] <sinzui> I am very skeptical that any of the trunk upgrades will pass. They are all paused and approaching the 30 minutes timeout
[04:13] <wallyworld__> :-(
[04:13] <wallyworld__> deployments look ok
[04:14] <wallyworld__> at least 1.18 works so that can be released soon
[04:16] <sinzui> I already downloaded the 1.18.1 tarball and win installer. I could release that tomorrow
[04:17] <wallyworld__> sinzui: fix for bug 1303735 landing now though
[04:17] <_mup_> Bug #1303735: public-address change to internal bridge post juju-upgrade <openstack-provider> <juju-core:Fix Committed by axwalk> <juju-core 1.18:In Progress by axwalk> <https://launchpad.net/bugs/1303735>
[04:17] <sinzui> \o/
[04:17] <wallyworld__> we should not release without that one
[04:18] <wallyworld__> the only other one is backup failure
[04:18] <wallyworld__> meh for 18.1 i reckon
[04:26] <sinzui> wallyworld__, There is not much point fixing that backup bug because the restore bug is targeted for 1.19.0.
[04:26] <wallyworld__> that's what i reckon also
[04:26] <wallyworld__> hence, "meh" :-)
[04:27] <wallyworld__> so we can retarget and release as soon as the final fix lands
[04:27] <wallyworld__> sinzui: fuck off to bed, it's way too late for you to be online
[04:27] <wallyworld__> :-)
[04:28] <sinzui> I have more email explain what blocks 1.19.0 and then I will sleep
[04:44] <davecheney> wallyworld__: yes
[04:44] <davecheney> it turns out that there is a bug in gccgo
[04:44] <davecheney> things are only given small stacks
[04:44] <davecheney> and when they run off the end, they crash
[04:45] <wallyworld__> boom
[04:45] <davecheney> dunno why some ppc machines are ok
[04:45] <davecheney> i'm building a test gccgo now
[04:45] <wallyworld__> ok
[04:45] <davecheney> mwhudson: ping
[04:45] <wallyworld__> davecheney: btw, arm64 works now \o/
[04:46] <davecheney> wallyworld__: working on a compiler fix
[04:46] <davecheney> wallyworld__: it's actually a build option
[04:47] <wallyworld__> the issue i has was bug 1274558, transparent huge pages, there is a wor arpund
[04:47] <davecheney> eek
[04:47] <davecheney> autoconf is incorrectly turning on the -fsplit-stack option for gccgo
[04:47] <wallyworld__> the issue caused go executables to hang etc etc
[04:47] <davecheney> which is really only an intel thing
[04:50] <davecheney> wallyworld__: can you grab the last dozen lines of dmesg
[04:50] <davecheney> on that system
[04:50] <wallyworld__> ok
[05:46] <wallyworld__> davecheney: this is not a juju bug is it https://bugs.launchpad.net/juju-core/+bug/1300256
[05:46] <_mup_> Bug #1300256: juju status results in unexpected fault address on arm64 using/ local provider <arm64> <hs-arm64> <local-provider> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1300256>
[07:22] <dimitern> morning all
[07:23] <dimitern> fwereade, I hope you're feeling better today :), just as a reminder - my two VLAN CLs https://codereview.appspot.com/86010044/ and https://codereview.appspot.com/86600043/ when you can have a look
[07:24]  * dimitern is away for 1h
[08:07] <rogpeppe> mornin' all
[08:37] <waigani> davecheney: turned out to be a one liner: https://codereview.appspot.com/86760043/
[08:37] <waigani> morning rogpeppe
[08:38] <rogpeppe> waigani: hiya
[08:38] <waigani> Exciting Friday night here, coding in the kitchen
[08:47] <axw> do we have a way to version API methods yet?
[08:55] <rogpeppe> axw: renaming them is the only way currently
[08:55] <rogpeppe> axw: or going the backwards-compatible route
[08:55] <axw> rogpeppe: ok, thanks
[08:56] <rogpeppe> axw: there are a couple of directions i'd like to go with it, but it's a sensitive issue
[08:57] <rogpeppe> ha, i wondered what i'd done to break the cmd/jujud tests, but this happens in trunk (many times): [LOG] 36.85478 ERROR juju worker: exited "rsyslog": failed to write rsyslog certificates: cannot create temp file: open /var/log/juju/rsyslog-cert.pem824698669: no such file or directory
[08:57] <rogpeppe> this is not great
[09:02] <axw> rogpeppe: did you get a chance to look at the EnsureAvailability CL?
[09:02] <rogpeppe> axw: i'm about half way through the review
[09:02] <axw> ok
[09:02] <rogpeppe> axw: sorry, will get back to it!
[09:03] <axw> rogpeppe: nps
[09:04] <rogpeppe> axw: there was one thing i was having difficulty working out
[09:04] <rogpeppe> axw: i couldn't quite see whether it always preserves the invariant that the number of wants-vote machines is always odd
[09:05] <axw> it should always be the parameter, and that is checked at the top
[09:06] <axw> if one is taken out of VotingMachineIds, another will replace it
[09:07] <axw> rogpeppe: I must admit it was a little mindbendy to me, so don't take my word for it ;)
[09:20] <mwhudson> davecheney: pong
[09:24] <davecheney> waigani: nice fix
[09:24] <davecheney> yeah, that was what I suspected
[09:24] <davecheney> we weren't specifying, so it fell through to 'this machine'
[09:24] <davecheney> which didn't match the fixtures
[09:25] <davecheney> waigani: interesting line wrapping, are you using a c64 ?
[09:26] <waigani> davecheney: line wrapping? in the description you mean?
[09:26] <rogpeppe> axw: i'm wondering if we should be doing all the stateserverinfo ids manipulation inside a single Update op
[09:26] <davecheney> waigani: y
[09:27] <axw> rogpeppe: what's the benefit?
[09:27] <rogpeppe> axw: it means that other code can't see them in an intermediate state
[09:27] <waigani> davecheney: lol - well I may be formatting out of nostalgia ;)
[09:28] <axw> rogpeppe: all the ops are run in a single transaction though?
[09:28] <waigani> davecheney: how are we looking now on ppc?
[09:28] <rogpeppe> axw: read operations don't respect transactions
[09:28] <davecheney> waigani: no complain', just sayin'
[09:28] <davecheney> waigani: will know in < 300 seconds
[09:28] <axw> rogpeppe: ah, I see
[09:28] <davecheney> waigani: provider/common was whinging about mising ssh keys
[09:28] <waigani> oh really?
[09:29] <waigani> I can look into that if you like?
[09:29] <davecheney> waigani: i'll know in a few mins
[09:29] <rogpeppe> axw: the other thing i'm trying to persuade myself of is whether the $size asserts in maintainStateServersOps are still sufficient
[09:29] <davecheney> hold tight
[09:30] <axw> rogpeppe: I was thinking they should be changed to exact match - is there a use case for two concurrent callers?
[09:31] <axw> I figure someone might want to have a cron job calling this
[09:31] <rogpeppe> axw: well, we try to make everything work ok with concurrent callers
[09:31] <rogpeppe> axw: i'm not sure that an exact match is possible to do though
[09:31] <rogpeppe> axw: it might need to be a txn_revno assertion
[09:31] <waigani> davecheney: I looked into 1262967. I suspect it is a similar problem. So far though, none of the tests are failing for me.
[09:32] <davecheney> waigani: bootstrap_test.go:69: c.Assert(err, gc.IsNil)
[09:32] <davecheney> ... value *errors.errorString = &errors.errorString{s:"no public ssh keys found"} ("no public ssh keys found")
[09:32] <axw> rogpeppe: sure, I just meant whether we try to allow concurrent modifications or lock each other out entirely
[09:32] <rogpeppe> axw: ah yes
[09:33] <rogpeppe> axw: if we've got two concurrent callers both calling ensure-availability with different numbers, that's likely to be problematic anyway
[09:34] <rogpeppe> axw: but if the server count hasn't changed, i think it should be fine to just let a concurrent call assume that the first one has worked, and return with success
[09:34] <rogpeppe> axw: s/server count/voting server count/
[09:35] <axw> rogpeppe: as we do now?
[09:35] <axw> len(VotingMachineIds) == numStateServers?
[09:36] <rogpeppe> axw: well, that was ok before, but isn't now, because we want to juggle available servers
[09:36] <waigani> davecheney: I can't reproduce that?
[09:36] <waigani> provider/common$ go test on ppc 31 tests pass?
[09:36] <davecheney> waigani: rm -rf ~/.ssh :)
[09:36] <waigani> ugh god facepalm
[09:37] <axw> rogpeppe: it should still work - it checks if there are any machines being taken out of the voting set
[09:37] <davecheney> waigani: it should be the same as your provider manual fix, right
[09:37] <waigani> davecheney: is there a bug for that one?
[09:37] <davecheney> the underlying cause is the same
[09:37] <axw> rogpeppe: info is updated by updateAvailableStateServersOps if that's not clear
[09:37] <waigani> davecheney: yep, looks very similar
[09:37] <davecheney> waigani: the bug was for both I think
[09:37] <axw> so VotingMachineIds out may be smaller than going in
[09:38] <waigani> ooh right, okay I can fix and link it to the same bug?
[09:38] <davecheney> yup
[09:38] <waigani> sweet, will do
[09:38] <rogpeppe> axw: currently, we just return nil if the number of voting machines hasn't changed. i'm not sure we can still do that.
[09:38] <davecheney> mwhudson: i've found hte cause of the juju crashes on ppc
[09:38] <davecheney> in the gccgo deb
[09:38] <davecheney> actually, i'll step back
[09:38] <mwhudson> davecheney: oh?
[09:39] <davecheney> mwhudson: basically, libgo tests to see if the compiler supposed -fsplit-stack
[09:39] <davecheney> which ppc says it does
[09:39] <davecheney> but it lies
[09:39] <mwhudson> ah
[09:39] <davecheney> i think the same is for arm
[09:39] <davecheney> arm64
[09:40] <davecheney> i mean, you need gold to support it
[09:40] <davecheney> and gold isn't even installed on ppc
[09:40] <axw> rogpeppe: sorry, I don't understand why. if we remove a voting machine ID, then len(VotingMachineIds) < numStateServers. If we bring an available server back in, that count doesn't change, but we add a txn.Op to make the change in mongo
[09:40] <mwhudson> davecheney: i'
[09:41] <mwhudson> davecheney: i'm pretty sure i checked that the configure script does not think arm64 supports split stacks
[09:41] <davecheney> ok, that might be a different error
[09:41] <davecheney> but it looks like ppc is saying it does
[09:42] <davecheney> and so libgo configures itself accordingly
[09:42] <davecheney> and so each goroutine has a small stack and runs of the end easily
[09:44] <davecheney> checking whether -fsplit-stack is supported... no
[09:44] <davecheney> hmm, that is odd
[09:44] <rogpeppe> axw: i'm just saying that i don't think we can just do nothing at all if len(VotingMachineIds) == numStateServers
[09:44] <rogpeppe> axw: (which is the current behaviour)
[09:45] <axw> rogpeppe: ah, we should perform an assertion you mean?
[09:46] <rogpeppe> axw: we'll still need to potentially decommission unavailable machines and add new ones if so
[09:48] <axw> rogpeppe: yes, that's being done in my CL. possibly not very obviously
[09:48] <rogpeppe> axw: yup
[09:48] <axw> or maybe I just don't understand
[09:48] <rogpeppe> axw: perhaps when you said "as we do now" you meant "as we do in my branch" ?
[09:50] <axw> rogpeppe: "if the server count hasn't changed, i think it should be fine to just let a concurrent call assume that the first one has worked, and return with success"  -- do we not do that on trunk? maybe you meant server count hasn't changed in mongo, and availability hasn't changed
[09:51] <axw> anyway. I think we're roughly on the same page
[09:51] <rogpeppe> axw: yeah
[09:51] <natefinch> morning all
[09:51] <rogpeppe> natefinch: hiysa
[09:52] <rogpeppe> axw: i suppose the question now in my mind is: is it possible for EnsureAvailability to do any actions without changing the server id counts?
[09:53] <rogpeppe> axw: hmm, i think it might be possible
[09:53] <axw> morning natefinch
[09:54] <rogpeppe> axw: so perhaps the best thing is to assert on txn_revno and assume that txn.ErrAborted means all's well
[09:54] <axw> rogpeppe: yes, it will change the counts definitely. the check there at the moment says that the counts didn't change externally
[09:54] <axw> rogpeppe: SGTM
[09:55] <davecheney> waigani: are you going to apply https://codereview.appspot.com/85710043/ to provider/common ?
[09:56] <rogpeppe> axw: what if we've got the following scenario (x means unavailable): machineids: 1 2 3x 4; votingids: 1 2x 4; then we'll end up with something like: machineids: 1 2 4 5; voting ids: 1 4 5
[09:56] <rogpeppe> axw: i think
[09:56] <waigani> davecheney: what would be best? I can update that branch or create a new one?
[09:56] <rogpeppe> axw: where the voting counts haven't changed, but the contents have
[09:56] <davecheney> waigani: you need to createa  new branch
[09:56] <rogpeppe> axw: (and 5 is a newly commissioned machine)
[09:56] <davecheney> this is the gift that lbox brings us
[09:57] <waigani> davecheney: ah hehe okay
[09:57] <waigani> nice timing, as I was just starting on the old branch
[09:57] <waigani> you must have sensed it (or you've hacked into my computer)
[09:58] <axw> rogpeppe: each of the promote/demote ops assert that they weren't changed too
[09:58] <axw> rogpeppe: so if something else modified the the contents concurrently, we'd still see assert on wantvote/hasvote fields
[09:59] <rogpeppe> axw: ah, good point
[10:09] <rogpeppe> axw: reviewed
[10:09] <axw> rogpeppe: thanks
[10:10] <axw> rogpeppe: ahhhh, now I see what you mean about voting count not changing
[10:10] <axw> on ErrTxnAborted
[10:10] <axw> ErrAborted rather
[10:13] <rogpeppe> axw: cool
[10:13] <waigani> davecheney: lboxing...
[10:16] <davecheney> kk
[10:17] <waigani> davecheney: https://codereview.appspot.com/86800043
[10:17] <davecheney> waigani: reviewing
[10:17] <axw> night all
[10:17] <davecheney> it would be nice to get this on in this evening
[10:17] <waigani> davecheney: cool, I'll hang around until it lands
[10:20] <davecheney> waigani: nah
[10:20] <davecheney> i can land it myself
[10:20] <davecheney> i have timezones on my side
[10:20] <davecheney> it looks like there might be another bug in cmd/juju
[10:20] <davecheney> tests
[10:20] <davecheney> simple ordering one
[10:21] <waigani> davecheney: I'm hitting this on the vm: fatal error: bad spsize in __go_go
[10:21] <davecheney> eek
[10:22] <waigani> yeah, I don't seem to be able to run my tests
[10:28] <davecheney> waigani: $ go test ./provider/common/
[10:28] <davecheney> ok      launchpad.net/juju-core/provider/common 24.926s
[10:28] <davecheney> LGTM
[10:28] <davecheney> ship it
[10:28] <waigani> davecheney: sweet
[10:34] <waigani> davecheney: cmd/juju$ go test
[10:34] <waigani> OK: 226 passed, 2 skipped
[10:34] <waigani> PASS
[10:39] <davecheney> waigani: nice one
[10:39] <davecheney> give yourself the evening off
[10:43] <waigani> davecheney: thanks. If you see any bugs you want me to look at, send me an email for Monday.
[10:43] <waigani> davecheney: I'll be keen to see how close we are to getting juju working on ppc :)
[10:44] <davecheney> waigani: i think we're down to 3
[10:44] <davecheney> cmd/juju
[10:44] <davecheney> which looks easy
[10:45] <davecheney> cmd/jujud which looks like a timeout
[10:45] <davecheney> the joyent provider which is a timeout
[10:45] <davecheney> and worker tests
[10:45] <davecheney> which are a bug in the compiler i'm working on
[10:47] <mgz> rogpeppe, dimitern: standup!
[10:48] <davecheney> waigani: http://paste.ubuntu.com/7233131/
[10:48] <davecheney> from a few hors ago
[10:48] <davecheney> be suspcious of any tests thta take 600 seconds
[10:48] <davecheney> the watchdog kills it
[10:57] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1306536
[10:57] <_mup_> Bug #1306536: replicaset: mongodb crashes during test <juju-core:Triaged> <https://launchpad.net/bugs/1306536>
[10:57] <davecheney> this is a real thing
[10:57] <davecheney> if mongo shits itself during our CI
[10:57] <davecheney> which it does, continually
[10:57] <davecheney> what is it going to do in the field ?
[11:02] <rogpeppe> natefinch: shall we hang out elsewhere?
[11:02] <natefinch> rogpeppe: sure
[11:03] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/canonical.com/juju-HA?authuser=1
[11:04] <natefinch> davecheney: we'll look into it. I've seen it occasionally.  not sure what causes it yet
[11:05] <davecheney> natefinch: what version is the bot running
[11:05] <davecheney> is it still running out old crack versoin of mongo we made 2 years ago ?
[11:07] <rogpeppe> natefinch: bzr+ssh://bazaar.launchpad.net/~rogpeppe/juju-core/natefinch-041-moremongo/
[11:07] <natefinch> davecheney: I don't think so, but I'm not sure
[11:08] <davecheney> $ ~/bin/juju destroy-environment -y local
[11:08] <davecheney> ERROR failed verification of local provider prerequisites:
[11:08] <davecheney> juju-local must be installed to enable the local provider:
[11:08] <davecheney> umm ....
[11:08] <davecheney> so, i can't develop juju unless I have a conflicting juju binary installed ?
[11:10] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1306544
[11:10] <_mup_> Bug #1306544: developing juju requires juju-local  to be installed <juju-core:Triaged> <https://launchpad.net/bugs/1306544>
[11:11] <natefinch> interesting way to put it, we just need youy to have  juju-mongodb
[11:11] <davecheney> this is kind of a problem
[11:11] <natefinch> it's been a huge problem for new developers.... but you're right, we should have a separate package to just deploy the db
[11:11] <davecheney> you have to be super careful `juju` is the juju you mean
[11:12] <natefinch> yeah, I think rog hit that
[11:12] <natefinch> interesting... actually:
[11:12] <natefinch> $ which juju
[11:12] <natefinch> /usr/bin/juju
[11:12] <davecheney> sad trombone
[12:43] <rogpeppe> does anyone know anything about statecmd.MachineConfig ?
[12:44] <rogpeppe> from the description, it looks like it just returns information, but AFAICS, it's actually responsible for setting up the initial password info on a machine too
[12:46] <rogpeppe> and it seems kinda weird that it's living inside statecmd too
[12:47] <rogpeppe> ah, i see, it's a 1.16 legacy
[12:51] <mgz> evilnickveitch: do you want me to resubmit doc changes against github in order to get them landed?
[12:55] <evilnickveitch> mgz, no, it's fine. I did a PR for the GH repo. Nobody has looked at it, so I will just merge it anyhow
[12:56] <mgz> evilnickveitch: I can probably stamp it...
[12:56] <mgz> evilnickveitch: too late, thanks!
[12:57] <evilnickveitch> :)
[13:00] <wallyworld__> fwereade: hiya, saw your comment on instance type constraints. i haven't done any work on it for a few days except for merging trunk and resolving conflicts as i've been doing the arm stuff and other work for 1.18.1 etc. i guess i should mark it back as wip. i'll be able to get more done next week
[13:31] <natefinch> rogpeppe: back'
[13:34] <fwereade> wallyworld__, no worries, I knew we'd talked about some of the stuff I mentioned, just wanted to make sure it was recrded
[13:34] <wallyworld__> sure, ok
[13:35] <fwereade> rogpeppe, IIRC it's primarily for the manual provider (and particularly for hazmat's convenience)
[13:36] <rogpeppe> fwereade: i'm just pondering the best place to add mongo password setup for new state servers
[13:36] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/canonical.com/juju-HA?authuser=1
[13:37] <fwereade> rogpeppe, preferably purely inside existing state servers, surely?
[13:38] <rogpeppe> fwereade: sure
[13:38] <rogpeppe> fwereade: i think it's best done along with the other password in the API call ProvisioningScript
[13:39] <rogpeppe> fwereade: (FWIW, that's another bad name - it doesn't sound like it actually sets up the machine too)
[13:39] <fwereade> rogpeppe, fair enough, so long as we don't put it in cloudinit
[13:39] <rogpeppe> fwereade: definitely not - it couldn't go in cloudinit anyway
[13:40] <rogpeppe> fwereade: BTW NewAPIAuthenticator seems to be fundamentally misguided - it only gets the state and API addresses once
[13:40] <fwereade> rogpeppe, yeah, I know, it sucks
[13:40] <rogpeppe> fwereade: i'm not sure whether to change it to fetch the addresses each time, or to add a watcher to the provisioner
[13:41] <fwereade> rogpeppe, midpoint: get the addresses once per batch of machines
[13:41] <rogpeppe> fwereade: i suppose AuthenticationProvider could do the watch too
[13:41] <fwereade> rogpeppe, the intent was always to do it per-batch but I forget why it didn't happen
[13:42] <fwereade> rogpeppe, I suspect there was some ugly interaction with container provisioners
[13:48] <rogpeppe> fwereade: ah, i see. we should get the address in provisionerTask.startMachines
[13:49] <perrito666> how cool would be to have a special var that when something other than nil is assigned to it would automatically produce panic or return err (error handling induced day dreaming)
[13:49] <rogpeppe> fwereade: it's pretty awkward to refactor the code so it uses bulk API calls, BTW
[13:50] <rogpeppe> fwereade: although it's definitely a place that it's worth it
[13:51] <rogpeppe> fwereade: although actually just running all the startMachine calls concurrently would be a big win (and quite likely faster than using sequential bulk calls)
[13:51] <natefinch> perrito666: magic is pretty much anathema in Go. I prefer to have the code do exactly what it says it does, and no more.  Magic is how you get bugs.
[13:51] <perrito666> natefinch: amen
[13:56] <perrito666> natefinch: I guess I was more in search of syntactic sugar than magic
[14:00] <natefinch> perrito666: also not something Go generally does :)   you can do this, though:
[14:00] <natefinch> if err := foo(); err != nil {
[14:00] <natefinch>     return err
[14:00] <natefinch> }
[14:02] <fwereade> rogpeppe, we do also want environ.StartInstances to mitigate rate limiting
[14:02] <rogpeppe> fwereade: yes.
[14:02] <perrito666> natefinch: yep, that is where I go whenever I can, although that is closer to syntactic saccharine than sugar
[14:02] <fwereade> rogpeppe, and I'm well aware of just how much hassle that will be, but we can only put it off so long ;)
[14:02] <rogpeppe> fwereade: although i'm yet sure if rate limiting should really be done in the Environ itself
[14:03] <rogpeppe> s/yet/not yet/
[14:03] <fwereade> perrito666, also it keeps the scope of err nice and tight, which is often a benefit of itself
[14:03] <fwereade> rogpeppe, I'm reasonably sure it should be, myself
[14:03] <rogpeppe> fwereade: the problem is that not everything that makes provider calls necessarily shares the same Environ
[14:03] <fwereade> rogpeppe, which is not to say that we shouldn't also have some stuff around instancepoller too
[14:04] <fwereade> rogpeppe, most of them should, though
[14:04] <fwereade> rogpeppe, and it's probably not that hard to arrange
[14:04] <rogpeppe> fwereade: doesn't every worker create its own Environ?
[14:04] <rogpeppe> fwereade: but, yeah, it's probably not too hard to pass an environ in to those workers that need one
[14:04] <mattyw> fwereade, when you have a moment...
[14:05] <rogpeppe> fwereade: except that it can change
[14:05] <fwereade> rogpeppe, yeah, but it doesn't have to -- pass one in, have another worker responsible for updating it
[14:05] <fwereade> mattyw, heyhey
[14:05] <natefinch> anyone understand this log about wordpress not installing?   failed to fstat previous diversions file: No such file or directory    whole log: http://paste.ubuntu.com/7235032/
[14:05] <sinzui> Hi jamespage : I have an idea to address a bug 1304493 that I think was caused by republication of juju tools.
[14:05] <_mup_> Bug #1304493: Juju tools 1.18.0 streams.canonical.com checksum mismatch <ci> <landscape> <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1304493>
[14:05] <jamespage> sinzui, I think so yes
[14:05] <jamespage> sinzui, that feels bad to me
[14:06] <dimitern> rogpeppe, fwereade, updated https://codereview.appspot.com/86010044/
[14:06] <dimitern> rogpeppe, fwereade, (networks stuff)
[14:11] <sinzui> jamespage, I am not convinced it is the right solution since I do not know why streams.canonical.com got a different file size for the amd64 precise tools. I think the only package it could find is the one from the juju stable ppa
[14:12] <jamespage> sinzui, one from the PPA, then one from the distro when I uploaded it I suspect
[14:12] <sinzui> jamespage, you made one for precise?
[14:12] <jamespage> sinzui, no
[14:12] <sinzui> I thought you were just making trusty
[14:12] <jamespage> oh - that really is odd then
[14:13] <jamespage> sinzui, I am
[14:13] <jamespage> sinzui, I don't understand then
[14:13] <jamespage> we need utlemming I think
[14:13] <sinzui> I will keep investigating
[14:13] <sinzui> thank you jamespage
[14:17] <rogpeppe> fwereade: can i run something by you?
[14:17] <fwereade> rogpeppe, sure
[14:18] <rogpeppe> fwereade: i *think* we can remove StateInfo from environs.MachineConfig and cloudinit.MachineConfig
[14:18] <fwereade> rogpeppe, w00t!
[14:18] <fwereade> rogpeppe, I've been wanting to do that for months :)
[14:19] <rogpeppe> fwereade: basically, any agent that needs to connect to State can dial localhost
[14:22] <rogpeppe> fwereade: that will need to change in the future if we want to have more API servers than mongo instances
[14:23] <rogpeppe> fwereade: but even then, i don't think it needs to be in MachineConfig
[14:24] <fwereade> rogpeppe, +100
[14:24] <fwereade> rogpeppe, anything starting up at bootstrap time can use localhost, and anything starting up late can just grab the info over the api, anyway
[14:25] <rogpeppe> fwereade: yup
[14:25] <fwereade> rogpeppe, excellent
[14:46] <sinzui> jamespage, I now think bug 1304493 is caused by different versions of gzip. I don't think this issue is about alternate packages.
[14:46] <_mup_> Bug #1304493: Juju tools 1.18.0 streams.canonical.com checksum mismatch <ci> <landscape> <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1304493>
[14:47] <jamespage> sinzui, ah - yes - deterministic zip creation
[14:50] <natefinch> marcoceppi, hazmat: either of you recognize this error from installing a charm?  failed to fstat previous diversions file: No such file or directory   full log: http://paste.ubuntu.com/7235032/
[14:50] <rogpeppe> fwereade: i think we'll remove state addresses from agent config too
[14:50] <natefinch> seems to only happen when deploying locally
[14:50] <fwereade> rogpeppe, sgtm I think
[14:51] <rogpeppe> fwereade: and i'm also changing the agent config to store hostports to avoid the current impedance mismatch.
[14:51] <rogpeppe> fwereade: then it's [][]instance.HostPort throughout
[14:52] <fwereade> rogpeppe, cool
[15:02] <marcoceppi> natefinch: that's an interesting error, I've not come across it before. What's the charm?
[15:05] <natefinch> marcoceppi: that's wordpress
[15:05] <natefinch> marcoceppi: different error for mysql, start fails
[15:06] <natefinch> marcoceppi: mysql gets this: http://paste.ubuntu.com/7235297/
[15:44] <jamespage> sinzui, are we likely to see a 1.18.1 release today?  as it will be critical bug fixes I can push that pre-release
[15:44] <jamespage> and we're still in universe so meh
[15:45] <sinzui> jamespage, the gzip bug is blocking, but I hope to be able to start the release in 2 hours
[16:11] <alexisb> natefinch, fwereade ping
[16:13] <natefinch> alexisb: howdy
[16:15] <alexisb> hi natefinch happy friday
[16:15] <alexisb> can I lean on you to take a look at the 4 new critical bugs for 1.19.0 and see if you can easily assign them to someone across the juju team?
[16:16] <alexisb> looks like most are regressions
[16:16] <natefinch> alexisb: I can look, for sure. What's the timeline on getting them fixed?  There's not a lot of working hours left for most juju devs
[16:17] <alexisb> as soon as we can, but in regular working hours
[16:17] <natefinch> alexisb: ok
[16:17] <alexisb> we just need to try and unblock sinzui from releasing
[16:18] <alexisb> sinzui, are there any bugs in 1.18 that need our assistance for the release jamespage needs?
[16:18] <alexisb> and natefinch thank you!
[16:18] <natefinch> alexisb: welcome
[16:18] <alexisb> sinzui, our == juju-core
[16:25] <rogpeppe> is hook output still labelled with HOOK in the logs?
[16:32] <sinzui> alexisb, I am working on the one bug that blocks the release of 1.18.1.
[16:32] <sinzui> alexisb, I am going to defer the backup bug because fixing it doesn't allow you to restore. The restore bug is targeted to 1.19.0
[16:33] <alexisb> sinzui, ack
[16:38] <natefinch> sinzui, marcoceppi, alexisb:  Btw, looks like wordpress and mysql both fail to deploy on trunk, at least using the local provider on trusty.  Getting some errors related to apparmor when installing wordpress and when starting mysql.
[16:38] <alexisb> natefinch, that would make sense given on of the critical bugs deals with failing to bootstrap a local provider
[16:40] <natefinch> alexisb: I can bootstrap ok, it's deploying that I have a problem with
[16:41] <alexisb> ah ok, shows my ignorance :)
[16:42] <fwereade> alexisb, heyhey, I'll take a look as well
[16:42] <alexisb> fwereade, thanks
[16:45] <natefinch> fwereade: check out my response to this bug at the bottom and let me know if you disagree: https://bugs.launchpad.net/juju-core/+bug/1208430
[16:45] <_mup_> Bug #1208430: mongodb runs as root user <mongodb> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1208430>
[16:46] <fwereade> natefinch, concur
[16:46] <fwereade> natefinch, db access gives you the keys to the kingdom regardless
[16:46] <fwereade> natefinch, have we closed the mongod ports externally yet?
[16:46] <fwereade> natefinch, I'm guessing not, but I think we can now; right?
[16:47] <fwereade> natefinch, at least on providers where we can do firewalls
[16:48] <fwereade> natefinch, in fact it should be a matter of just not explicitly opening it any more
[16:48] <natefinch> fwereade: roger says he thinks we keep them open still... but I think we can close them (and definitely should close them)
[16:48] <fwereade> natefinch, close 'em :)
[16:49] <fwereade> natefinch, ideally we'd close them even to traffic from other machines in the environment, but that's not practical yet
[16:49] <natefinch> fwereade: yep
[16:49] <sinzui> natefinch, then this is the real bug 1305280
[16:49] <_mup_> Bug #1305280: juju command get_cgroup fails when creating new machines, local provider arm32  <armhf> <local-provider> <lxc> <packaging> <juju-core:Triaged> <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1305280>
[16:49] <sinzui> natefinch, The bug is in ubuntu, but I kept it open on juju-core to make it easy for me to track
[16:50] <natefinch> sinzui: ahh, ok, thanks
[16:50] <fwereade> natefinch, looking at those criticals I am suspicious that the other 3 are ha-/replicaset-related
[16:51] <natefinch> sinzui: the armhf in the title seems misleading, since I'm definitely not running arm here
[16:52] <sinzui> natefinch, yep. I thought it was limited ubuntu ports/packaging issue
[16:52] <natefinch> fwereade: yeah
[16:54] <natefinch> fwereade:  this one seems like it just requires an update to the backup script to find the juju-db binaries: https://bugs.launchpad.net/juju-core/+bug/1305780
[16:54] <_mup_> Bug #1305780: juju-backup command fails against trusty bootstrap node <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1305780>
[16:54] <natefinch> oh, i guess that one is 1.81.1
[16:54] <natefinch> er 1.18.1
[16:55] <natefinch> fwereade: certainly the other ones are HA related
[16:55] <sinzui> natefinch, I am going to move that bug to 1.19.0
[16:56] <sinzui> natefinch, if we fix the backup bug, the user still hits the two restore bugs in 1.19.0
[16:56]  * sinzui moves the bug to be with its friends
[16:56] <natefinch> the more the merrier
[16:57] <sinzui> natefinch, So I see one bug in progress for 1.18.1, It's my job to solve the gzip compression problem between different machines.
[16:58] <sinzui> Juju-Core can focus on getting trunk releasable for Monday/tuesday
[17:15] <fwereade> natefinch, yeah, I think they're not on the $PATH
[17:15] <fwereade> natefinch, sorry, evening is happening around me a bit ;)
[17:15] <natefinch> fwereade: seems like an easy fix at least
[17:15] <fwereade> natefinch, yeah
[17:15] <fwereade> btw, https://codereview.appspot.com/86910043 is up for review at long long last
[17:17] <cjohnston> natefinch or fwereade any chance either of you could help debug an issue where trusty cant deploy precise instances using lxc?
[17:18] <fwereade> cjohnston, IIRC thumper has started work on that -- is this new?
[17:18] <sinzui> cjohnston, did you set default-series in your config...and is your the failure with some charms bug 1305280
[17:18] <_mup_> Bug #1305280: juju command get_cgroup fails when creating new machines, local provider arm32  <armhf> <local-provider> <lxc> <packaging> <juju-core:Triaged> <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1305280>
[17:19] <cjohnston> https://bugs.launchpad.net/juju-core/+bug/1306537 is the bug filed for it, yes default_series is set
[17:19] <_mup_> Bug #1306537: LXC provider fails to provision precise instances from a trusty host <juju-core:Invalid> <https://launchpad.net/bugs/1306537>
[17:20] <cjohnston> I don't see (error: error executing "lxc-start": command get_cgroup failed in juju status, the instances just sit at pending for hours
[17:20] <cjohnston> however deploying cs:trusty/ubuntu works
[17:26] <sinzui> cjohnston, This issue may be fixed in trunk. The opposite scenario was recently fixed: bug 1302820
[17:26] <_mup_> Bug #1302820: juju deploy --to lxc:0 cs:trusty/ubuntu creates precise container <landscape> <juju-core:Fix Committed by thumper> <https://launchpad.net/bugs/1302820>
[17:27] <sinzui> cjohnston, 1.19.0 will be released next week, a day after trunk stabilises.
[17:34] <rogpeppe>  i'm sure i used to be able to move my mouse when my machine was heavily loaded
[17:35] <natefinch> rogpeppe: I've noticed that recently, too
[17:36] <rogpeppe> and this IRC client has an amazing failure mode when i've been typing into it when the machine's heavily loaded
[17:36] <natefinch> (recently = last few months at least)
[17:36] <rogpeppe> every few keys typed, it ignores what i've typed and types something from the past insteads
[17:37] <rogpeppe> so just then, if i typed "ddddddddd", i'd get "d abled abled"
[17:38] <rogpeppe> hmm, we've taken away support for 1.19 to work against 1.16 clients, right?
[17:38] <natefinch> time to get a new irc client
[17:42] <sinzui> rogpeppe, There is a commit in trunk that says that
[17:42] <sinzui> and I removed the ability to package 1.16. its dead to me
[17:42] <rogpeppe> sinzui: so we don't care about upgrading from 1.16 then?
[17:42] <rogpeppe> sinzui: which upgrade transition has been failing on trunk?
[17:43] <sinzui> rogpeppe, we test stable to stable. 1.16 goes to 1.18. 1.18 can go to 1.19 or 1.20
[17:43] <rogpeppe> sinzui: ok, cool
[17:43]  * sinzui notes that juju docs should make that very clear
[18:22] <rogpeppe> natefinch, dimitern, anyone else that's around: large but largely trivial: https://codereview.appspot.com/87010044
[18:41] <natefinch> review for whoever: https://codereview.appspot.com/86920043/
[18:44] <natefinch> rogpeppe: this is the machine 0 log for upgrading 1.18 to trunk
[18:44] <natefinch> http://pastebin.ubuntu.com/7236187/
[19:00] <natefinch> rogpeppe<EMAIL_ADDRESS>[20:40] <perrito666> how deep is a copy of an object in go?
[20:42] <perrito666> for instance I copy a document that has fields such as []string slices and arrays inside
[20:42] <perrito666> do all those get properly copied?
[20:42] <natefinch> perrito666: it's hard to answer that without being flippant.  The obvious answer is, it copies everything.  But that would be confusing
[20:43] <natefinch> perrito666: slices, channels, and maps are all implemented as pointers, so the pointers get copied but not what they point to
[20:43] <natefinch> interfaces, too
[20:43] <natefinch> arrays are actually consecutive memory like you'd expect, and when you copy them, you copy the whole dang thing
[20:44] <natefinch> but slices are just pointers to parts of arrays, so when you copy them, you're only copying the pointer
[20:44] <perrito666> natefinch: as I thought, if I want to "clone" and object, I need to create a sort of deepcopy
[20:45] <natefinch> perrito666: depends on the value, but yes, some values take some extra work
[20:46] <natefinch> perrito666: maps and slices are really the only thing you need to worry about (there's no real way to deep-copy an interface, and it doesn't really make sense to copy a channel)
[20:47] <natefinch> perrito666: I guess a good question would be - why do you need to clone something?
[20:49] <perrito666> natefinch: thank you, btw, how many hours a day do you work, you are here when I arrive and when I leave?
[20:51] <perrito666> natefinch: refactoring a big piece of code of assignToMachine
[20:51] <natefinch> perrito666: haha... not that much, really.  I have a lot of interruptions during the day due to having two small children.  I start work around 5:30 or 6am and end at 5pm, but there's usually a few hours of non-work in there.
[20:56] <natefinch> ok, EOD for me
[20:56] <perrito666> natefinch: have a nice weekend
[20:56] <natefinch> perrito666: you too