[00:20] <nhaines> pleia2: ping
[00:20] <nhaines> pleia2: Would you prefer I make a natty CD request here or on list?  :)
[00:59] <crashsystems1> Anyone know if one must tag off when leave a vta light rail?
[01:03] <pleia2> nhaines: doesn't need to be on the list, but an email will be best (that way I don't lose track of it, I don't expect the CDs to arrive for at least another week)
[04:12] <DarkwingDuck> Wow...
[04:12] <DarkwingDuck> We finally did it...
[04:12] <akk> yeah, amazing
[04:13] <DarkwingDuck> Did 7 years of deployments looking for this day
[04:17] <nhaines> I only care if I can fly without a minimun wage TSA angent touching my genitals.
[04:19] <akk> Alas it's not common to give us back freedoms after they've taken them away. :(
[04:20] <nhaines> akk: yeah :(
[04:24] <MarkDude> nhaines, +1
[04:24] <akk> Hey MarkDude! I have little gooseberries starting to form.
[04:25] <akk> (on second thought, that sounds like maybe too personal information to share on IRC. :)
[04:25] <MarkDude> lol
[04:25] <MarkDude> I have at least 10 small plants started
[04:26] <akk> I have three pots each with 10+ seedlings (that I guess I should try to thin out somehow).
[04:26] <MarkDude> I plan to have at least a large bowlfull by end of summer
[04:26] <akk> I think I planted too many seeds, being pessimistic about what would sprout.
[04:26] <MarkDude> Me too
[04:26] <MarkDude> The quick ones really grow taller
[04:26] <akk> I get so excited about plants. Silly thing, but ... creating new life!
[04:27] <MarkDude> those that lag dont do much for a while- but seem to take off the next year
[04:27] <MarkDude> Iheartubuntu tomatoes have started
[04:28] <akk> I still haven't planted tomatoes this year. Been so busy with other stuff.
[04:29] <MarkDude> I have an extra plant
[04:29] <MarkDude> As well as spices
[04:30] <akk> I have sage and chard left over from last year. Ate some of the chard last week.
[04:49] <philipballew> i am curious as to how exactly this opp went down. great for american forces
[04:50] <philipballew> DarkwingDuck thanks for helping make this happen!
[04:50] <akk> Hopefully there will be more details over the next few days.
[04:50] <philipballew> i guess the opp went down today
[04:50] <nhaines> philipballew: guess again. He's been dead for a week.
[04:51] <philipballew> hum, obama said something about today in his specech. wonder why so long to get the word out?
[04:52] <nhaines> philipballew: they have to positively ID him and DNA takes two weeks.
[04:52] <philipballew> that makes sense. this will probably cause osama's troups to fight even harder
[04:53] <akk> It really takes that long to do the actual test? It's not just labs not getting around to it?
[04:54] <nhaines> akk: I think electrophoresis only takes a few hours but I'm sure analysis takes some time. I'll bet there was a lot of other things to verify, too.
[04:58] <philipballew> dental records, and such. I wonder how hidden his hideout was
[05:00] <akk> true
[05:00] <nhaines> philipballew: it wasn't. He was killed in a mansion in Abbottabad.
[05:00] <philipballew> the mension was most likely hidden i would assume though.
[05:01] <philipballew> if not he was most likely hiden by other means
[05:01] <nhaines> One doesn't hide mansions.
[05:03] <philipballew> haha. this is true. the town he was hiding in maybe supported him, who knows?
[05:09] <MarkDude> DarkwingDuck, all other stuff aside, Ty for your service. People that are willing to put their ass on the line for others - very cool
[05:19] <philipballew> ^ agreed!
[05:48] <DarkwingDuck> Thanks MarkDude philipballew
[05:50] <philipballew> anytime dude!!!
[05:53] <DarkwingDuck> :D
[17:50] <jdeslip> Just watched the LAS's review of 11.04 - they pretty much destroyed it
[17:50] <jdeslip> These guys have been so positive about every other Ubuntu release up to this one :/
[17:54] <crashsystems> Soon they'll use it without thinking about it, just like buttons on the left.
[19:42] <pleia3> :)
[19:42] <pleia2> http://ubuntu-california.org/chat/ now has the embedded chat
[19:43] <iheartubuntu> NICE
[19:51] <EureCA> wiki: http://wiki.ubuntu.com/CaliforniaTeam/Menu edited | http://wiki.ubuntu.com/CaliforniaTeam/Meetings/11May22 edited | http://wiki.ubuntu.com/CaliforniaTeam/Meetings/11April24 edited
[19:54] <iheartubuntu> Apparently I have someone downright copying my website at http://www.guideubuntu.com/
[19:54] <MarkDude> That is way cool on the web-chat
[19:56] <pleia2> I wouldn't say "downright copying" it looks similar but the content seems original
[19:56]  * pleia2 has seen cases where sites were actually copied into foriegn languages
[19:56] <pleia2> post for post
[19:57] <iheartubuntu> main point is to get ubuntu word out there
[21:10] <iheartubuntu> Ahhhh, Eureka changed her name.


[17:59] <pleia2> new theme is installed with fix for #809754
[18:00] <pleia2> you can test it by logging in and clicking on your name on the top right, and going to "Preferences" and selecting "ubuntuwomen" as preferred theme
[18:24] <akgraner> pleia2,  thanks!
[18:25] <pleia2> also: http://blog.ubuntu-women.org/2011/11/career-days-from-developer-to-ceo-wrap-up/
[18:26] <pleia2> we should start thinking of our next Career Days :) http://wiki.ubuntu-women.org/CareerDays
[18:27] <pleia2> and I don't have an interview for FCM again :\
[18:27] <pleia2> so suggestions for interviewees welcome
[18:28] <akgraner> oh crap - I didn't get you Gema's email did I - grrrrr
[18:28] <akgraner> one second let me do that right now!
[18:28] <pleia2> ok, thanks :)
[18:32] <akgraner> pleia2, sent
[18:35] <pleia2> thanks


[15:00] <schopin> o/
[15:01] <ogayot> o/
[15:01] <ginggs> o/
[15:01] <bdmurray> o/
[15:02] <slyon> o/
[15:03] <adrien> o/
[15:03] <juliank> o7
[15:03] <ogra> ubuntu yoga class ?
[15:04] <adrien> workplace ergonomics course
[15:04] <slyon> #startmeeting Weekly Ubuntu Foundations team
[15:04] <meetingology> Meeting started at 15:04:49 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:04] <ogra> 🙂
[15:04] <juliank>  /o\
[15:04] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:05] <juliank> 🤦
[15:05] <xypron> o/
[15:05] <slyon> #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-13-october-2022/31342
[15:05] <slyon> The weekly status is here:
[15:05] <slyon> Let's all take our usual time to read and ask questions
[15:08] <bdmurray> still reading
[15:08] <slyon> Alright, any questions?
[15:09] <bdmurray> enr0n: how many rts are opened about bad mirrors now?
[15:09] <bdmurray> I don't think the ones from April have been sorted
[15:09] <enr0n> bdmurray: I'm not sure in total. I opened one last week or so that has been resolved.
[15:09] <enr0n> Just opened the uz one today
[15:10] <bdmurray> Ah, maybe we (you?) should have a look before the release
[15:10] <enr0n> I can do that
[15:10] <slyon> #topic Release incoming bugs
[15:10] <slyon> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-kk-incoming-bug-tasks.html#foundations-bugs
[15:11] <slyon> bug #1842439
[15:11] -ubottu:#ubuntu-meeting- Bug 1842439 in apport (Ubuntu Focal) "apport-gtk crashed with SIGSEGV in _gtk_settings_get_screen(settings=0x0) from gtk_css_value_icon_theme_compute() from gtk_css_static_style_compute_value()" [High, Triaged] https://launchpad.net/bugs/1842439
[15:11] <schopin> still in the hands of Desktop afaict
[15:11] <slyon> ok, let's move on
[15:11] <slyon> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[15:11] <slyon> bug #1965094
[15:11] -ubottu:#ubuntu-meeting- Bug 1965094 in ubuntu-drivers-common (Ubuntu) "'Additional Drivers' application crashes on startup" [High, Confirmed] https://launchpad.net/bugs/1965094
[15:12] <slyon> ^ we seem to be waiting on desktop here, too?
[15:12] <slyon> (or kernel team)
[15:13] <slyon> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/foundations-triage-discuss-bug-tasks.html
[15:14] <slyon> bug #https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1992513
[15:14] -ubottu:#ubuntu-meeting- Launchpad bug 1992513 in apt (Ubuntu) "apt will not install nvidia-driver-470-server if nvidia-driver-450-server is installed and out of date" [Medium, Triaged]
[15:14] <juliank> I don't think this needs discussing just more investigating
[15:15] <slyon> so shall we un-tag it? and mabye mark the nvidia-graphics-* bug tasks invalid?
[15:15] <juliank> So subscribe foundations-bugs and untag it
[15:15] <bdmurray> If you think we should work on it then it should be tagged foundations-todo
[15:16] <slyon> bug #1992485
[15:16] -ubottu:#ubuntu-meeting- Bug 1992485 in git (Ubuntu) "git cannot fetch: fatal: fetch-pack: unable to fork off sideband demultiplexer" [Undecided, New] https://launchpad.net/bugs/1992485
[15:18] <bdmurray> let's ping the server team about this
[15:18] <juliank> probably seccomp bs again
[15:20] <slyon> ack.
[15:20] <slyon> bug #1992472
[15:20] -ubottu:#ubuntu-meeting- Bug 1992472 in apt (Ubuntu) "APT hooks do not respect the -q option" [Low, Triaged] https://launchpad.net/bugs/1992472
[15:21] <slyon> bug #1992369
[15:21] -ubottu:#ubuntu-meeting- Bug 1992369 in fonts-dejavu (Ubuntu) "DejaVu Serif Italic capital letters and digits broken" [Undecided, New] https://launchpad.net/bugs/1992369
[15:21] <slyon> we're subscribing ~foundations-bugs to the APT hooks one.
[15:22] <slyon> the next one is about font rendering
[15:23] <schopin> No change to the package besides rebuild between focal and jammy, might be more an issue with whatever renders the font?
[15:23] <slyon> I agree.
[15:24] <bdmurray> Maybe its gnome-font-viewer?
[15:24] <slyon> or fontconfig?
[15:25] <slyon> let's add a gnome-font-viewer task to this bug and have the desktop team have a look at it.
[15:25] <bdmurray> It looks fine to me
[15:26] <schopin> freetype2 could be a culprit, and it's Foundations... :)
[15:26] <adrien> harfbuzz too iirc
[15:26] <schopin> which is desktop. Great.
[15:27] <slyon> bug #1992358
[15:27] -ubottu:#ubuntu-meeting- Bug 1992358 in nfs-utils (Ubuntu) "existing 20.04  nfs-kernel-sever default which did not convert" [Undecided, New] https://launchpad.net/bugs/1992358
[15:29] <schopin> That sounds like a support request?
[15:29] <bdmurray> "your very kind note on upgrading to jammy" ?
[15:29] <schopin> Probably in the release notes.
[15:30] <slyon> let's skip this one, its not really clear why it got tagged.
[15:30] <slyon> bug #1992297
[15:30] -ubottu:#ubuntu-meeting- Bug 1992297 in ubiquity (Ubuntu) "Instalation enters wrong UUID for EFI partition in fstab when installing Ubuntu  with 'ubiquity -b'" [Undecided, New] https://launchpad.net/bugs/1992297
[15:33] <juliank> so this one is just weird I did not fully understand what they tried to say
[15:33] <juliank> but I think it's incomplete
[15:34] <slyon> "if this problem is something that seems to be hardware speciffic or speciffic and very rare to happen then the chance that it happens to many people who don't know what to do is small. however if this problem turns out to be more common or that it could happen also on normal systems with a new install then that could be a problem"
[15:34] <slyon> seems to be an edge case and resolved for the reporter, he's just waiting for others to see the same issue. maybe we should set it as Triaged/Low?
[15:36] <slyon> okay adding some questions => Incomplete
[15:36] <slyon> bug #1992283
[15:36] -ubottu:#ubuntu-meeting- Bug 1992283 in ubiquity (Ubuntu) "/target could not be mounted" [High, Triaged] https://launchpad.net/bugs/1992283
[15:38] <bdmurray> Oct  9 12:00:27 ubuntu kernel: [  441.390511]  nvme0n2: unable to read partition table
[15:38] <bdmurray> Oct  9 12:00:27 ubuntu kernel: [  441.390522] nvme0n2: partition table beyond EOD, truncated
[15:38] <bdmurray> Is that suspicious?
[15:38] <juliank> looks like broken partition table
[15:42] <slyon> Let's set importance to medium, as the new installer should better handle such situations
[15:42] <slyon> bug #1992228
[15:42] -ubottu:#ubuntu-meeting- Bug 1992228 in imagemagick (Ubuntu Kinetic) "Fax/PDF performance regression compared to focal" [High, Triaged] https://launchpad.net/bugs/1992228
[15:44] <slyon> imagemagick is in universe since Focal
[15:45] <slyon> so I'll unsubscribe and removed the tag
[15:45] <dbungert> note that we should also set aside some time to discuss proposed-migration, it has 8 items
[15:45] <slyon> bug #1992179
[15:45] -ubottu:#ubuntu-meeting- Bug 1992179 in shim (Ubuntu) "shim FTBFS in Kinetic" [Medium, Triaged] https://launchpad.net/bugs/1992179
[15:46] <slyon> dbungert: thanks for the heads-up. let's discuss the shim bug ^ and move to proposed-migration net
[15:46] <slyon> next*
[15:48] <slyon> foundations is already subscribed, this should be fixed, let's remove the -discuss tag
[15:48] <slyon> #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:49] <slyon> libevent vs mysql, is that something waveform could have a look at?
[15:49] <waveform> yup
[15:49] <slyon> glibc vs ubuntu-image, schopin?
[15:50] <schopin> Yup, already looking into it :)
[15:50] <slyon> nice!
[15:50] <slyon> liverto, is just waiting for libevent
[15:50] <slyon> so is nfs-utils
[15:50] <slyon> all the rest is pretty much just waiting for tests to run,
[15:51] <slyon> i'll re-trigger those netplan vs glib2.0 tests
[15:52] <slyon> #topic AOB
[15:52] <juliank> ooo tomorrow
[15:52] <juliank> release next week
[15:53] <slyon> final freeze today :)
[15:53] <juliank> so no #ubuntu-meeting meeting next week then
[15:54] <slyon> alright, thanks all!
[15:55] <slyon> #endmeeting
[15:55] <meetingology> Meeting ended at 15:55:33 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-10-13-15.04.moin.txt


[05:36] <cpaelzer> good morning
[07:03] <pitti> infinity: right, I remember again -- we made the libpam-systemd a recommends instead of a depends to keep out dbus etc. from being quasi-essential
[07:03] <pitti> infinity: but now that the entire init dropped out of essential, that's actually okay and desirable
[07:04] <pitti> Good morning
[07:04] <infinity> pitti: I made all the changes, FYI.  I'm going to look at fallout for "weird" images (people who don't ship minimal/standard, because reasons) when I wake up and fix any oddities.
[07:09] <pitti> cyphermox: this morning when I tried to boot my laptop, EFI refused to boot because it could not verify the signature; I disabled secureboot for now, but I suppose that Should Not Happen™; how can I debug this?
[07:09] <pitti> cyphermox: (yakkety du jour)
[07:28] <pitti> mdeslaur, jdstrand: IIRC you started working on loading apparmor profiles in systemd directly, like it does with SELinux, to get rid of the apparmor rcS init.d script and the associated race conditions, right?
[07:29] <pitti> mdeslaur, jdstrand: I was curious what the status of that was, as Debian is trying to get rid of rcS init.d scripts (they tend to cause problems)
[07:33] <RAOF> Hm. *Some* update appears to have broken the Mir build. With weird template linker errors!
[07:43] <pitti> urgh, what happened to prodstack swift
[08:02] <Laney> mapreri: was away for a few days; will look soon
[09:04] <six86> Hello. I can't manage to create a bootable stick with my preseeded *.iso file... It works fine in a VM and Also creating a bootable stick from the orginal ubuntu image works fine
[09:37] <pitti> tjaalton: please see my followup/question in bug 1577735
[09:48] <rbasak> pitti: I see systemd 230 is in Yakkety. What are the plans for KillUserProcesses? Does the server team need to consider our view on the screen/tmux use case? That is, will there be a behaviour change in Yakkety?
[09:48] <pitti> rbasak: the change is already reverted in the packaging git, so 230-2 will be back to the 229 behaviour
[09:50] <rbasak> pitti: ah, thanks.
[09:51] <infinity> pitti: Can we get that out sooner rather than later, to avoid the impending whine-fest (and people like me who've been sprinkling config snippets around already...)
[09:52] <pitti> infinity: yeah, can do; it'll be stuck in -proposed for a while though, as autopkgtesting is currently blocked on swift being down
[09:52] <pitti> but people could get it from -proposed then
[09:52] <infinity> pitti: Whee.  But yeah, better than nothing.
[09:53] <infinity> pitti: Is there ongoing upstream discussion about the madness, or are downstreams just expected to fork that bit forever?
[09:53] <pitti> infinity: there are upstream discussions, yes
[09:54] <pitti> e. g. upstream bugs for screen/tmux
[09:54] <pitti> but until that has settled down, we'll just revert to the old behaviour
[09:54] <pitti> infinity: it's just a ./configure option, not that much of a fork
[09:54] <pitti> and given how much opposition it met, I wouldn't be surprised if the default flips back in 231 upstream too
[09:54] <infinity> pitti: So, in the new world order, how does a user intentionally detach a process so it doesn't get whacked?
[09:55] <lifeless> infinity: there's a systemd thing you can call
[09:55] <infinity> Ick.
[09:55] <pitti> infinity: that's still being discussed actually; IMHO it'd be cleanest to start a PAM session, or use systemd-run to start a new scope (like a "mini" session)
[09:55] <rbasak> You have to enable lingering first AIUI? Or is that not necessary?
[09:55] <pitti> but I haven't seen a really satisfying answer to that
[09:55] <pitti> yes, but lingering is global
[09:56] <pitti> if you enable it, all other leftover processes from your session will survive too
[09:56] <rbasak> I see. So one or the other will suffice?
[09:56] <pitti> this is still a problem at the conceptual level, before we even can discuss technical solutions
[09:56] <infinity> pitti: None of that would satisfy the simple use case of "./long-job > log 2>&1 &" oh crap, need to logout "disown && logout".
[09:56] <infinity> pitti: But I guess we'll see where it goes.
[09:57] <infinity> Breaking UNIX, one use-case at a time.
[09:57] <pitti> we either accept tons of leftover processes, or change the ones that are deliberately long running
[09:57] <pitti> infinity: e. g. I wouldn't expect ./long-job & to survive on logout
[09:57] <pitti> that'd go straight against my idea of logging in and out
[09:57] <rbasak> Or we fix the bugs so processes exit when they should?
[09:57] <pitti> screen and tmux I can understand
[09:58] <pitti> but, as said, we first need to define what we actually want before discussing implementation
[09:58] <infinity> pitti: I suppose one could write a souped-up disown that moves the process out of the cgroup instead of just unparenting it?
[09:58] <pitti> and everyone seems to want something different
[09:58] <pitti> infinity: yes, that's more or less what systemd-run or a new PAM session would do
[09:58] <infinity> pitti: Well, but post-run is the key.
[09:59] <infinity> pitti: Having to think of this in advance is a massive behavioural change for old farts. :P
[10:00] <pitti> this is a prime example for https://xkcd.com/1172/
[10:00] <infinity> I disagree entirely.
[10:00] <pitti> I think it's a bug and counter-intuitive that session processes survive logout, you consider it a feature, one of us will always be unhappy :)
[10:00] <rbasak> pitti: do you consider an ssh disconnect a logout?
[10:00] <infinity> rbasak: Yes.
[10:01] <infinity> Anything that will result in killing your shell (or base process) is a logout.
[10:01] <pitti> rbasak: I'd say yes
[10:01] <infinity> disown exists specifically to unparent processes from the controlling shell, so the HUP sent on disconnect isn't propagated.
[10:01] <infinity> It's a feature, not a misfeature.  It's not spacebar heating. :P
[10:02] <pitti> yes, I can close the terminal and the process goes on
[10:02] <infinity> And HUP has a very specific meaning, and has done for decades.  Again, I don't think it's sane to say "actually, that should have been KILL all along".
[10:03] <pitti> anyway, 230-2 building, and I'll upload it to sid then; should get autosynced to y in half a day or so
[10:03] <infinity> As in, some things intentionally deamonize on HUP, so they don't get rudely interrupted by a remote disconnect.
[10:04] <infinity> In fact, even apt does that. :P
[10:04] <infinity> (To avoid half-done dpkg runs)
[10:06] <infinity> pitti: Anyhow.  I agree that making tmux/screen spawn new login sessions would be a workaround for the problem, but I disagree that remapping HUP to KILL for disconnects is in any way POSIX/UNIX friendly. :P
[10:06] <infinity> And, honestly, it'll just lead me to set my shell to /usr/bin/tmux
[10:07] <infinity> Which then gives me the same behaviour I had before, and renders the new world order a no-op.
[10:07] <pitti> infinity: I don't actually expect it to become a new world order anytime soon
[10:08] <pitti> this was an idea, it failed, it gets reverted, maybe the next concept and iteration works better
[10:13] <tjaalton> pitti: adding a handful of missing pci-ids so that compiz works properly shouldn't break anything
[10:14] <pitti> tjaalton: maybe, but it still needs to be confirmed that the package upgrades and runs correctly, and that X still works with the -proposed package
[10:14] <pitti> tjaalton: we've had SRUs of binutils and gcc, for example
[10:14] <tjaalton> pitti: well I copied a comment from the private bug
[10:16] <pitti> tjaalton: that comment makes little sense
[10:16] <tjaalton> huh?
[10:16] <pitti> tjaalton: 2.4.67 *is* the version in t/x-proposed
[10:16] <pitti> if it's only fixed by .68, then that needs to be SRUed as well, that's only in y
[10:16] <tjaalton> well yes the version in the comment is wrong
[10:16] <pitti> and it also doesn't say whether that's t or x
[10:16] <tjaalton> no, it just needs the pci-id's that the rest of the stack already has...
[10:16] <tjaalton> (kernel, mesa)
[10:17] <tjaalton> sigh
[10:17] <tjaalton> if you insist, I'll ask chih to comment himself
[10:18] <pitti> well, I insist on someone testing the actual package from -proposed and confirming the version and that it still works
[10:18] <tjaalton> pitti: and the only diff between t/x is the version number
[10:19] <pitti> tjaalton: doesn't matter -- we are looking for regressions here; confirming that it fixes the bug is nice, but not actually the first priority
[10:19] <pitti> but if the xenial-proposed one misbuilt because of our gcc or binutils SRU, we want to know this
[10:19] <pitti> just trusting "the diff is simple" isn't sufficient, and has led to catastrophes more than once
[10:20] <tjaalton> have you even looked at the diff?
[10:20] <pitti> the diff is *completely* irrelevant
[10:20] <tjaalton> it's completely relevant
[10:20] <tjaalton> this is not gcc
[10:20] <tjaalton> or binutils
[10:20] <pitti> (well, it's not in geneal, but the diff doesn't change the fact that we need to test teh proposed package)
[10:20] <tjaalton> and it was tested, I don't have the hw for that
[10:21] <pitti> testing for regressions on any intel hardware is fine
[10:21] <pitti> it's more important that it doesn't regress on existing systems than that it actually fixes the bug
[10:21] <pitti> we can always do a followup SRU if we missed a PCI ID, but we don't want to leave existing systems with a broken X
[10:22] <pitti> sorry, but just saying "it'll work without testing" for a compiled library is not acceptable
[10:31] <Saviq> xnox, hey, could you help with bug #1585517 please - between vivid and xenial we can no longer cross-build unity8 again - I've tried :any, :native for the two B-Ds, but I suppose that's wrong (and it didn't work anyway...)
[10:50] <mapreri> Laney: ok, don't worry :)  Thanks for prodding the thing!
[10:50]  * mapreri now waits for the mirror to updates
[10:50] <mapreri> -s
[11:03] <mdeslaur> pitti: jdstrand can confirm, but I don't believe we ever started that work, as the init script worked ok and we got busy  doing other stuff
[11:04] <pitti> mdeslaur: thanks, what I thought; the usual fate of makeshift solutions which work well enough :)
[11:04] <pitti> *cough* ddeb-retriever *cough*
[11:04] <mdeslaur> heh, yeah :)
[11:18] <Mirv> I think qtchooser  qt4-x11 qtbase-opensource-src could migrate to release pocket, together, but some hinting would be definitely needed still.
[11:19] <Mirv> there are also "Test in progress" ones that seem to be ghosts - kactivities under qt4-x11, ktnef under qtbase-opensource-src (others are always failed ones)
[11:22] <Mirv> some KDE update remaining autopkgtest breakage is there, but they don't completely go away too soon.
[11:45] <xnox> Saviq, commented.
[11:45] <Saviq> xnox, thanks
[11:45] <xnox> but it's been a while since i did multi-arch fixes
[11:45] <mdeslaur> @pilot in
[11:45] <xnox> so maybe barry and/or slangasek would be best to doublecheck the assertions I stated on bug #1585517
[13:05] <smoser> pitti, "cloud-init hash seed issue" ? you mean bug 1584147 right ?
[13:53] <tyhicks> pitti (FYI mdeslaur & jdstrand): the hard work is done - the parser code that handled policy loads has been moved into libapparmor with a nice simple interface for systemd to use
[13:53] <tyhicks> pitti: what we didn't get to are the systemd changes to use libapparmor
[13:53] <mdeslaur> tyhicks: oh, cool
[13:54] <mdeslaur> that should be reasonable trivial
[13:54] <mdeslaur> reasonably
[13:54] <pitti> smoser: right, that; that causes looong boot times (and adt-run timeouts; I could bump them, but it's still a nuisance)
[13:57] <smoser> pitti, o'
[13:57] <smoser> i'm open to suggestions
[13:58] <pitti> tyhicks: ah, thanks; that sounds a lot better indeed
[13:58]  * pitti still in meeting, sorry for lag
[14:10] <pitti> yay, swift is back, re-enabling the autopkgtest minions
[14:49] <infinity> pitti: Is this a misconfiguration in scalingstack, by not providing virtio_rng to the guests?
[14:50] <pitti> infinity: could very well be, yes; the RNG takes aaages to initialize
[14:50] <infinity> pitti: (Not that I'm agreeing with the new python behaviour, it seems a bit daft, but not starting instances with zero entropy certainly wouldn't hurt)
[14:50] <pitti> *nod*
[14:52] <infinity> pitti: Well, s/a bit daft/completely daft/ really.  Given the irresponsible people tend to fork hundreds of python scripts as if it were as cheap as POSIX shell, sucking your RNG dry when you might not even end up using it seems batty.
[14:53] <pitti> infinity: I also don't quite see why one needs cryptographically secure hash randomization
[14:53] <infinity> s/Given the/Given that/
[14:53] <pitti> in most programming languages hashes have a reproducible order
[14:54] <pitti> I did read the upstream report about the resource exploits with CGI arguments, but this appears to be a bit silly
[14:54] <infinity> pitti: There's certainly that argument too, yes.  Though, I can certainly firmly place myself on both sides of that fence.  But I'd prefer, as a programmer and sysadmin, to make that decision per call, not have it made for me.
[14:54] <pitti> if your CGI program allows me to specify a thousand GET arguments, then making that more efficient rather than just preventing so many args in the first place isn't a good fix
[14:55] <infinity> pitti: I have zero hope of influencing python upstream, however, but nudging IS/LP to see if you can get some virtual rng might at least get you past the hump.
[14:56] <infinity> I do wish we lived in a world where reliable randomness was a thing all computers had in abundance.  Can't quite sort out how we've failed so miserably to do that by now.
[14:57] <mdeslaur> @pilot out
[14:57] <pitti> infinity: at first the upstream bug report sounded like a wontfix, but I think they were pondering adding a NOBLOCK flag to the getrandom call
[14:58] <infinity> pitti: Yeah, I read the whole thread.  Still seems a bit up in the air, and the behaviour still seems incorrect (to me), even with the NOBLOCK, but meh.
[14:58] <infinity> If I want cryptographically awesome randomness, I should ask for it, I think assuming it (and, indeed, draining my RNG to seed it on every python call) is silly.
[14:58] <infinity> But, whatever.  One more reason for me to not be a Python fan.  As if I didn't have enough of those.
[14:59] <pitti> I actually am, all the more reason to fend off insanity :)
[15:00] <infinity> I suppose it could be worse, they could make /usr/bin/python3 dial-up Amazon and order a hardware fuzz dongle, and block until you plug it in.
[15:00] <pitti> "throw a dice 200.000 times and type in the results"
[15:00] <infinity> "No cheating, we've turned on your webcam to make sure."
[15:04] <infinity> Hey neat, I just tore open my stomach.
[15:04] <infinity> For some value of "neat".
[15:04] <infinity> Also, ow.
[15:05] <infinity> (afk)
[15:17] <cjwatson> eek?
[15:25] <mdeslaur> infinity: are you ok?
[15:27] <rbasak> "reliable randomness was a thing all computers had in abundance."
[15:27] <rbasak> That exists. It's called flaky hardware :-P
[21:22] <smoser> anyone else seeing ubuntu connection failures ?
[21:22] <dobey> everyone is yes
[21:22] <smoser> k
[21:22] <smoser> thanks
[21:23]  * smoser out
[22:14] <jbicha> why is https://launchpad.net/debian/+source/vlc missing the stretch branch (2.2.2-6 or the current 2.2.3-2) ?
[22:38] <nacc> jbicha: https://launchpad.net/debian/+source/vlc/+publishinghistory
[22:38] <nacc> jbicha: i'm guessing that pacakge isn't actually using lp for development, so it might be that someone just hasn't made a tracking branch appropriately
[22:38] <nacc> jbicha: i'm not sure how those work in lp.net/debian, maybe ask on #launchpad
[22:41] <jbicha> I believe it has the result that Ubuntu isn't auto-syncing vlc from Debian
[22:43] <cjwatson> nacc: no that's not a "using LP for development" thing
[22:43] <cjwatson> will check after call
[22:44] <nacc> cjwatson: oh ok
[22:44] <cjwatson> but stretch also isn't pertinent to auto-sync
[22:44] <nacc> jbicha: yakkety is synced?
[22:44] <cjwatson> sid is
[22:44] <nacc> well, with a rebuild
[22:44] <nacc> 2.2.2-6 from unstable, it seesm
[22:44] <cjwatson> https://launchpad.net/debian/+source/vlc/+publishinghistory has it as deleted for some reason
[22:45] <nacc> weird, and without an attribution as to who did it?
[22:45] <cjwatson> it's entirely automatic
[22:45] <cjwatson> checking logs
[22:46] <nacc> ok, i thought even then it said by the bot or something
[22:48] <cjwatson> nacc: not for /debian, that's more like reflecting external status than a deletion as such
[22:49] <cjwatson> it could be deleted by ~janitor I guess but it wouldn't add any useful information
[22:49] <cjwatson> jbicha: so in this case the problem is apparently that the dpkg-dev we're using can't unpack sid's vlc
[22:49] <nacc> cjwatson: ok, i must be misremembering
[22:50] <cjwatson> dpkg-source: error: unrecognized file for a v2.0 source package: vlc_2.2.3.orig.tar.xz.asc
[22:50] <cjwatson> damnit
[22:51] <cjwatson> https://lists.debian.org/debian-dpkg/2016/05/msg00041.html and thread
[22:51] <jbicha> I hit that with bzr earlier today, bug 1587659
[22:52] <cjwatson> separate issue
[22:52] <jbicha> right
[22:52] <cjwatson> I'm pretty cross at the excessively rapid introduction of this feature
[22:53] <cjwatson> jbicha: can you file a bug against Launchpad itself about this?  we're clearly forced to do something
[22:53] <jbicha> yes
[22:54] <cjwatson> it'll probably also require some other changes to LP beyond the dpkg backport
[22:54] <cjwatson> SourcePackageFileType for starters
[22:55] <cjwatson> in fact we might need those first, would need to check
[22:57] <cjwatson> ... yup, that sure looks like it'd be an IntegrityError or similar if we try to insert it without knowing its file type
[22:59] <jbicha> filed bug 1587667
[23:01] <cjwatson> thanks.  will try to get to it ASAP


[07:26] <dholbach> good morning
[08:47] <nigelb> dholbach, hey.  got some time?
[08:47] <dholbach> nigelb: a bit, yes
[08:47] <nigelb> can you do a review of the current https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved
[08:48] <nigelb> the problem is we haven't run into all the use cases yet, so I'm still actively reviewing to come into all the use cases so I add them as examples
[08:48] <dholbach> sure
[08:48] <dholbach> who should I mail with my feedback?
[08:48] <nigelb> just ping me :)
[08:48] <dholbach> persia, bryce, bdmurray, james_w, you? somebody else?
[08:48] <nigelb> or mail me
[08:48] <dholbach> I just thought it'd be good to keep the discussion in the team going :)
[08:49] <dholbach> but I can mail just you too
[08:49] <nigelb> dholbach, if you want to start a new thread with the entire discussion, I think thats fine too :)
[08:49] <dholbach> I'll do it a bit later today, I first need to get some other stuff done
[08:49] <dholbach> but I'll definitely do it today
[08:49] <dholbach> thanks for your work on this!
[08:49] <nigelb> lot more to go :)
[08:49] <dholbach> :-)
[08:50] <nigelb> oh and just to keep the motivation going
[08:50] <nigelb> we have only 135 bugs in the "to be reviewed queue"
[08:53] <Ciemon> nigelb: are those pre-freeze reviews?
[08:54] <nigelb> Ciemon, well, we'll try to get as many before freeze as possible
[08:54] <nigelb> but I dont think much will happen
[08:54] <Ciemon> ok
[08:54] <nigelb> like, I'm working on 6 bugs now.  I'll probably try and get all of them it :)
[08:54] <Ciemon> I have some time, but my new patching knowledge often needs guidance
[08:55] <Ciemon> ask Daviey :)
[08:55] <nigelb> Ciemon, what part are you having trouble with
[08:56] <Ciemon> oh, not trouble.. just lack of knowledge.
[08:56] <Ciemon> :)
[08:57] <nigelb> you can always ask in #ubuntu-motu, the responses are fairly fast
[08:57] <Ciemon> yep, thanks
[09:04] <Daviey> Ciemon wants to close 4 bugs with his branch
[09:04] <Daviey> so that'll help the stats ! :)
[09:05] <nigelb> you can do that :)
[09:05] <nigelb> (actually encouraged, so that you dont clutter the rev numbers)
[09:06] <Daviey> nigelb: yeah, he did have it as two items.. but the first one hadn't been sponsored yet, so he cleaned it down to 1
[09:06] <nigelb> Daviey, nice :)
[16:26] <nigelb> persia, any thoughts regarding what I PM'd you a few days back?
[16:30] <persia> So, the last couple times you asked me, I replied in /query, and it seems not to have stuck.
[16:30] <persia> Anyway, geser summed up my opinion fairly well in -motu when you asked there.
[16:30] <nigelb> it was an unsure move anyway
[16:31] <nigelb> so, any intersted devs can straight away join is better?
[16:31] <persia> No.
[16:31] <persia> But I suspect that any developer that comes by here and reads our procedures ought get in speedy-like.
[16:32] <nigelb> the trouble I'm facing is recruiting review leads
[16:32] <persia> Yeah, I'm expecting most of them to end up being me.
[16:32] <persia> Although I hope you'll fill in any times you can.
[16:32] <nigelb> I will
[16:33] <nigelb> btw, cypher_mox has agreed to help too :)
[16:33] <nigelb> and james__w and maco_ will depending on schedule then
[16:33] <persia> Be aware that some folks have nifty highlighting that _ doesn't skip.
[16:33] <nigelb> persia, I tried :D
[16:34] <nigelb> crimsun if his schedule permits though his suspects he might be busy that week
[16:34] <persia> I suspect many folks will be busy dealing with the sync flush + UDS preparation
[16:34] <nigelb> if their script catches their name, not my fault :D
[16:35] <nigelb> yup, thats what I'm afraid of
[16:39] <nigelb> persia, if its any consolation, only 132 bugs in review queue
[16:39] <nigelb> It can be reduced to 117 since a few of them are kernel or packages we need to ignore
[16:42] <persia> Cool.  I've a couple things on my plate now, but will take a swipe through sometime tonight: maybe we can get down to < 100 :)
[16:42] <nigelb> thats what I'm hoping for
[16:43] <nigelb> what happens if we get it down to 0? party? :D
[16:47] <persia> If you like, but there's still all the old patches to tackle.
[16:48] <persia> If we get *that* down to 0, someone needs to start a new patch creation initiative.
[16:48] <nigelb> yeah, its down to 1797
[16:48] <nigelb> lol, so we'll have patch creation team :D
[16:49] <persia> So, I'm expecting that in maverick+1 or maverick+2 we'll be able to have classes "How to fix bugs" for bugsquad again, and get more people contributing fixes.
[16:49] <persia> Right.
[16:49] <persia> And we'll encourage the patch creation team to follow-up with upstream, etc.
[16:49] <persia> But that's the future: let's concentrate on the bugs we have now :)
[16:49] <nigelb> we'd then we a *really really good* distro
[16:49] <nigelb> s/we/be
[16:50] <persia> I guess.  My thought is more that we ought leverage our strong point (lots of users) as much as possible to help everyone.
[16:51] <nigelb> I was thinking we move the starting date up for the script once we get to less than 20
[16:51] <persia> Sounds reasonable.
[16:51] <nigelb> Let me get to work on a few patches, some of them can still be removed from review queue
[16:52] <nigelb> ah, dan has given me more work on the wiki
[16:52] <nigelb> are you up-to-date on mails?
[16:53] <nigelb> dholbach, the patch-rejected-tag is to be used when upstream doesn't want to incorporate it in, when they want changes to it, it becomes patch-needswork.  See bug 33288
[16:54] <ubot3> Malone bug 33288 in poppler "Evince doesn't handle columns properly" [Unknown,Confirmed] https://launchpad.net/bugs/33288
[16:54] <dholbach> nigelb: right, I'm asking "when is patch-*-rejected tag going to be != patch-needswork"
[16:54] <nigelb> dholbach, I'll hunt down a use case from gnome upstream
[16:55] <dholbach> it would mean "ok we forwarded it upstream, they don't want it, but we'll use it anyway", right?
[16:55] <nigelb> its like work that ayatana does
[16:55] <nigelb> some stuff is ubuntu specific that upstream doesnt want in their code base
[16:56] <nigelb> so they reject the patch, but if its something we'd like it, we'll know it was forwarded and they didn't want it in
[16:57] <nigelb> persia, got anything to add to ^
[16:58] <dholbach> I think it'd be better if we made the decision process so that we don't need those tags :-)
[16:58] <dholbach> but it's basically just a foot note
[16:58] <dholbach> nothing too important
[16:58] <dholbach> I'd just prefer if we had less tags ;-)
[16:58] <persia> I've had patched rejected as not-needswork.
[16:59] <persia> For example, a patch to implement some feature that upstream said didn't belong in the software at all.
[16:59] <dholbach> right
[16:59] <persia> (I know: let's make dpkg a mailreader!)
[16:59] <dholbach> in that case it'd still be a patch-needswork for us
[16:59] <nigelb> hehe.  we could just change it to patch-rejected and add comments as to which upstream (debian vs all the way upstream)
[16:59] <dholbach> we have an open bug that we want to resolve somehow
[16:59] <persia> dholbach: Why?  How is adding mail reader support to dpkg "needs-work"?
[16:59] <dholbach> if upstream says "please do it differently" that's the decision we want to hear
[16:59] <persia> There's no sensible work that can improve that?
[17:00] <dholbach> ok, then we won't fix the bug too
[17:00] <nigelb> then we'd like to see why as soon as we open the bug
[17:01] <persia> But patch-rejected-upstream != patch-rejected
[17:02] <dholbach> all I'm saying is: if I have difficulties getting the sense of these tags, there will probably be a bunch of others who have more problems
[17:02] <dholbach> :)
[17:02] <persia> Quite possibly.
[17:02] <dholbach> the decision tree is not quite clear and "patch-rejected-upstream" is in no way a "final stage of the bug or patch"
[17:02] <persia> I suspect we need a significant body of data to actually interpret the tags properly.
[17:02] <dholbach> I personally would have preferred tags that indicate what needs to be done with the bug / patch
[17:02] <dholbach> so we could use them as working lists
[17:02] <persia> No, patch-rejected-upstream only says that upstream didn't want it: we might want to carry it, or we might want to rework it.
[17:03] <dholbach> but anyway
[17:03] <persia> dholbach: Do you have an alternate strategy/workflow for all the tags?  If you've a better one, I'm sure the rest of us would be willing to adjust.
[17:04] <dholbach> I proposed something in a mail I sent to the first discussions of the team
[17:04] <dholbach> but I have a call coming up now
[17:06] <persia> I see that, but I can't imagine how we can know what has been sent upstream, or what upstream responses we have with that.
[17:06] <persia> Anyway, tell me after your call if you like :)
[17:07] <nigelb> i'll try incorporate what you've suggested and yes, we're open to suggestions :)
[17:31] <nigelb> So, when to forward to debian?  When issues are in something inside /debian and when upstream is dead and we still sync from debian?
[17:50] <nigelb> persia, can reply ^ when you get time
[17:53] <persia> I think we should forward to Debian whenever the issue expresses itself in Debian
[17:53] <persia> That means testing in Debian, of course.
[17:54] <persia> If we *also* forward upstream, it's trivial to tell the Debian BTS that it's been forwarded upsteam, and the Debian maintainer can make a determination as to how to proceed.
[18:05] <nigelb> persia, lost power for 10 mins just after I asked you.  but got the answers :)
[18:12] <nigelb> ok, so replied to dholbach's mail  :)
[18:27] <nigelb> persia, we need to come up with something for bugs like bug 511502
[18:27] <ubot3> Malone bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,Fix released] https://launchpad.net/bugs/511502
[18:28] <nigelb> there are patches, but all sponsored, but there are open tasks, so end up in review queue
[18:28] <persia> I think the real solution is to convince people not to file those bugs, and complain when they do.
[18:28] <nigelb> huh?
[18:28] <persia> It's duplicate information (see the NBS page), and mostly useless.
[18:28] <persia> Plus it annoys all sorts of folk who are subscribed to the packages.
[18:29] <nigelb> yeah
[18:29] <nigelb> There are a couple more of those bugs.  I'm waiting for update to the script to deal with these for now
[18:29] <persia> Making them go away takes time and education.
[18:30] <nigelb> isn't it easier to open multiple bugs?
[18:30] <persia> No.  It's trivial to open a bug with lots of tasks.
[18:30] <persia> It just happens to be completely useless for that class of issue.
[18:30] <nigelb> Its mostly our developers themselves who do it :(
[18:31] <persia> I know.
[18:31] <persia> For now, I suggest the reviewers team completely ignore them.
[18:31] <persia> If I can make them go away, I will, but I'm unsure I can do that easily.
[18:31] <nigelb> or create lots of noise that people stop fililng it :D
[18:35] <nigelbabu> persia, *sigh* oh well, your point just got re-emphasized
[18:36] <nigelbabu> can PM me what you said after "nigelb> or create lots of noise that people stop fililng it :D" ?
[18:37] <persia> No, because you're not here :)  But I didn't say anything, so perhaps I can, as the receipt of nothing would comply with the request to send nothing :)
[18:38] <nigelbabu> persia, sometimes I wish you spoke English.
[18:38]  * nigelbabu smirks
[18:41] <nigelbabu> persia, so is there a way to show only 1 instace of those type of bugs?
[18:43] <persia> Search only for a given source package :)
[18:44] <nigelbabu> persia, :P  I meant in the review queue
[18:45] <persia> I don't think so: we've had that issue in the sponsoring queue before.  Since the only sensible justification for those massive bugs is to help sponsor other people's NBS work, this makes it useless even for it's intended purpose.
[18:46] <nigelbabu> sigh :x


[04:29]  * jose jose
[06:49] <dholbach> good morning
[17:01] <Vince-0> 2600hz goes MVNO! http://blog.2600hz.com/post/61407562417/2600hz-mobile
[17:02] <Vince-0> lol wrong chan


[01:48] <wcchandler> has oneiric alpha 1 hit testdrive yet?
[03:38] <skaet> wcchandler,  http://iso.qa.ubuntu.com/qatracker/
[03:39] <skaet> has the images being tested.
[03:57] <charlie-tca> Xubuntu tests are completed except wubi, which I can not do (no windows)
[03:57] <charlie-tca> Kubuntu alternate tests are done except OEM, which fails for the same bug as the live install
[03:57] <charlie-tca> Kubuntu optional tests are not done for alternate images
[04:39] <GridCube> ⚝
[04:39] <GridCube> :D
[10:28] <jibel> brendand, ping
[10:29] <brendand> jibel - hey
[14:18] <jibel> hggdh, ping
[14:20] <charlie-tca> jibel: how we looking today? Do we need more tests done?
[14:21] <jibel> charlie-tca, Hey charlie-tca , looks good, but we never have enough tests done :-)
[14:21] <jibel> charlie-tca, is there a bug report about the broken screen reader install ?
[14:23] <charlie-tca> no, there is a blueprint that accessibility will not be ready for alpha1
[14:23] <charlie-tca> We can't make it work until unity makes 2d work
[14:24] <charlie-tca> The importance of accessibility is always secondary to making the rest work first
[14:44] <hggdh> jibel, pong
[14:55] <jibel> hggdh, Good morning Sir!
[14:56] <jibel> hggdh, I fail to understand the result matrix for ec2, what's the status of alpha1 testing ?
[15:17] <hggdh> jibel, looking
[15:18] <hggdh> jibel, ugh! A lot of tests failed
[15:19] <hggdh> jibel, we now have to transpose the results, I will start on it
[15:19] <hggdh> jibel, but, to answer your question (what is the status of alpha1 testing for ec2): done, barfing right and left
[15:21] <hggdh> jibel, James already entered the data
[15:22] <hggdh> er, _is_ entering
[15:22] <jibel> hggdh, oh nice, we need more James :-)
[15:23] <jibel> jenkins runs the tests, james enters the results, that's perfect.
[15:30] <hggdh> heh
[15:30] <hggdh> we are looking at an automation thingie for Oneiric, also
[15:34] <jibel> hggdh, if you can export the results from jenkins in a sane format, we can update the tracker automatically quite easily
[15:35] <jibel> hggdh, hm, I'm testing lightdm and I guess it killed my netbook :(
[15:42] <hggdh> jibel, oh, thank you -- I am *not* going to test lightDM
[15:42] <hggdh> jibel, yes, I think exporting the results would not be complex
[15:48] <charlie-tca> aw, lightDM is fun to test :-)
[15:49] <charlie-tca> hggdh: I can't seem to crash dasher in natty today
[15:51] <hggdh> charlie-tca, good! (I think)
[15:52] <charlie-tca> This is dasher testing day, too
[16:55] <jibel> patrickmw, do you have the privileges to change the topic of the channel ?
[16:57] <patrickmw> jibel, I do on certain channels, but I don't recall which ones.  I can try changing this channel... send me what you'd like it to be
[16:57] <jibel> patrickmw, "Currently testing Oneiric Alpha 1 candidates | http://qa.ubuntu.com/testing/iso-testing/ | http://iso.qa.ubuntu.com"
[16:58] <patrickmw> jibel, boo,  I can't change this channel.  I always bug ara :)
[16:58] <patrickmw> ara ^^^ :)
[16:59] <patrickmw> ara_ ^
[17:00] <ara> pedro_, how did I do to make myself op? :D
[17:00] <ara> (same questions over and over again)
[17:00] <pedro_> ara, IIRC  /msg chanserv op #ubuntu-testing
[17:01] <ara> pedro_, cool, that worked
[17:01] <pedro_> nice :-)
[19:54] <brendand> hi jibel
[19:54] <brendand> jibel - would extra mago tests be seen as a valuable contribution?
[20:52] <skaet> Just wanted to say thank you to everyone here who's helped test Alpha 1.   Very much appreciate your efforts, and wanted to let you know its been released.  :)
[20:54] <charlie-tca> Thank you, skaet . We are gaining knowlege every time.
[20:55] <skaet> Thanks charlie-tca,  indeed we are.  :)
[21:24] <chadadavis>  Sorry for the lack of macbook tests. I had allocated time on Tue, but the images weren't ready yet. Have the mac tests been dropped?
[21:25] <chadadavis> skaet, ^
[21:25] <charlie-tca> They were for alpha1, yes
[21:26] <chadadavis> charlie-tca, I see. But they'll be back for alpha2? Was there a particular problem there?
[21:26] <charlie-tca> The idea was to have the tests that were done on the tracker for the release
[21:26] <charlie-tca> They should be back for alpha2
[21:26] <chadadavis> Makes sense. THanks.
[21:26] <charlie-tca> Thank you for dropping by
[21:27] <chadadavis> I had to catch a plane on Wed and couldn't wait for the ISOs. I'll test them next week. And I'll be around for alpha2, and beyond.
[21:27] <charlie-tca> it happens
[22:19] <cr3> cyphermox: echo $(cd "$directory" 2>/dev/null && pwd || echo "$directory")/$filename
[22:19] <cyphermox> thanks
[22:19] <cr3> cyphermox: where directory is $(dirname $path) and filename is $(basename $path)
[22:19] <cyphermox> yeah. I was thinking of using dirname to work through what I need
[22:19] <cr3> cyphermox: that should translate pretty well to C
[22:19] <cyphermox> yup
[22:20] <cr3> cyphermox: shell actually works well for inspiration in this particular case because string processing is just as crap as in C :)
[22:20] <cyphermox> I was really hoping to avoid changing directories though :/


[14:48] <Danny> hi
[14:48] <Danny> Hi I would just like to know if the latest Ubuntu linux distribution will work on my TOSHIBA laptop......
[14:49] <persia> And sticking about is more likely to get an answer.


[01:09] <blahdeblah> Can anyone recommend an analytics program for postfix mail logs?  I want something where i can drill down to an individual user level and find out volumes per day, most common senders/recipients, average size, and stuff like that.
[10:54] <ikt>  blahdeblah did you find one?
[10:54] <ikt> i'd also like something similar
[10:54] <ikt> used to have one on zimbra
[10:54] <ikt> daily email with all the stats
[10:54] <ikt> most emails sent, blocked, spam blocked, reasons why etc
[12:35] <Lindon-Wynter> It's just like a chocolate milkshake, only crunchy.
[12:58] <blahdeblah> ikt: Not really - pflogsumm is close


[03:46] <philsf> hi, after upgrading to maverick beta, firefox crashes upon startup if moonlight plugin is installed. removing the addon solves crashing. Is this a known issue?
[03:47] <micahg> philsf: yes, been an issue since lucid on occasion
[03:48] <philsf> micahg, ok. just thought it might be worth noting in the release notes if it wasn't just my system
[07:36] <micahg> chrisccoulson: back so early?
[07:37] <micahg> chrisccoulson: good morning I mean :)
[07:37] <chrisccoulson> micahg - i got up with my daughter this morning
[07:37] <chrisccoulson> so, early start ;)
[07:37] <micahg> chrisccoulson: update on 3.6.10, they'll probably spin in the next day or 2
[07:38]  * micahg is about to go to sleep
[07:39] <chrisccoulson> heh, good timing for final freeze :)
[07:39] <micahg> yeah
[07:40] <chrisccoulson> i'll speak to kate later and let her know that we might upload just after freeze starts
[07:40] <chrisccoulson> not sure what her IRC nick is though
[07:41] <micahg> chrisccoulson: skaet
[07:41] <chrisccoulson> ah, thanks
[07:41] <micahg> chrisccoulson: I'm planning a desktop translation upload thursday around UTC 0400
[07:41] <micahg> for firefox that is
[07:43] <micahg> if the build is ready, I can push then, I also have a xulrunner fix that I might push before if a build isn't ready
[07:43] <chrisccoulson> cool
[07:44] <chrisccoulson> ah, yeah, i've just seen my bug mail
[07:46] <micahg> and I'll have to push 4.0 beta 6 tomorrow night or wed night most likely to the PPA since they have some regressions in there as well
[07:47] <fta2> jdstrand, mdeslaur, kees: fyi, there will be another security update of chromium later this week: 6.0.472.59. i will use that one to ship either the fix (if kees finds one) or workaround for the arm ftbfs with pie.
[07:49] <fta2> jdstrand, mdeslaur: i see at least 6 sec fixes in that one, affecting other products too
[07:49] <fta2> well, at least 3 out of 6
[10:41] <chrisccoulson> hmmm, none of the buttons in my tab bar work in the current FF dailies :/
[15:26] <chrisccoulson> hi fta2 - would you mind respinning the firefox-4.0 dailies if you get a few minutes?
[15:26] <chrisccoulson> the current builds are pretty broken, and the bad commit has been backed out upstream now
[16:24] <fta> chrisccoulson, done
[16:29] <chrisccoulson> fta - thanks
[16:46] <fta> kees, upstream asked me to report the pie ftbfs: http://code.google.com/p/chromium/issues/detail?id=55439
[16:47] <kees> fta: excellent, thanks
[16:47] <kees> i haven't had a chance to check on my arm build yet.
[16:51] <fta> kees, feel free to clarify if needed
[17:17] <kees> fta: neat, looks like they're all over it. :)
[17:18] <kees> fta: based on http://sourceware.org/bugzilla/show_bug.cgi?id=10434 it seems like we should just leave hardy/jaunty disabled
[17:18] <ubot2> sourceware.org bug 10434 in ld "-fpie + -pie does not appear to work with __thread variables" [Normal,Resolved: fixed]
[17:27] <fta> hm, webm broken in chromium trunk... or is it youtube?
[17:45] <fta> ok, known issue
[18:22] <Green00000> i have a problem with updating firefox (installed+portable) ..... installed V3.6.3 ....... portable V3.6.8 ........ i start "searching for updates", but the result is just that all updates are allready installed.
[19:26] <jdstrand> fta2: fyi: 6.0.472.55~r58392-0ubuntu<IP_ADDRESS>  built fine with PIE on armel: https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+build/1958434
[19:26] <jdstrand> kees: ^
[19:27] <fta> jdstrand, hmm, so lucid is fine but maverick is not?
[19:27] <kees> yay
[19:28] <jdstrand> I didn't try maverick-- just lucid
[19:28] <kees> maverick fails for me
[19:28] <kees> /usr/bin/ld.bfd.real: out/Release/obj.target/skia/libskia.a(SkBlurDrawLooper.o)(.text._ZN16SkBlurDrawLooper10CreateProcER23SkFlattenableReadBuffer[SkBlurDrawLooper::CreateProc(SkFlattenableReadBuffer&)]+0x6): unresolvable R_ARM_THM_CALL relocation against symbol `operator new(unsigned int)@@GLIBCXX_3.4'
[19:28] <kees> /usr/bin/ld.bfd.real: final link failed: Nonrepresentable section on output
[19:28] <fta> jdstrand, i push to maverick myself
[19:28] <jdstrand> fta: you cool with me pocket copying that to lucid-proposed, or should we wait for the 6 security fixes you mentioned ealier?
[19:29] <fta> jdstrand, no need to wait, please copy
[19:29] <fta> jdstrand, btw, do you copy or rebuild?
[19:32] <jdstrand> fta: pocket copy. we are building in the ubuntu-security-proposed ppa so we don't pull in -updates. rebuilding would defeat that
[19:42] <fta> http://3.bp.blogspot.com/_JSR8IC77Ub4/TGwf42W-6sI/AAAAAAAAA9o/9Tzb6i52UA0/s1600/d9m38bd_277d2tnf3d9_b.png
[19:42] <fta> makes me want to cry
[19:45] <Dimmuxx> hehe flash
[20:03] <fta> jcastro, you said something about build resources yesterday, what was that?
[20:04] <fta> jcastro, atm, i've been waiting for some builds to start for ~3d, and they are still deep in the q: http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[20:05] <fta> jcastro, and when that happens, because of some lp api bugs, it's difficult to track the status of other builds
[21:11] <jcastro> ok
[21:41] <fta> i'm thinking about dropping support for jaunty and hardy in the dailies sooner than their EOL
[21:41] <fta> we don't have enough resources anyway
[21:41] <fta> and the user base is low
[21:42] <fta> less than 8% each, meaning a microscopic fraction running dailies
[21:42] <fta> thoughts?
[22:54] <fta> no cares? so i have my answer, gone they are
[22:55] <micahg> fta: sorry, I was offline, can I help?
[22:57] <fta> my last 5 lines, if you have logs
[22:59] <micahg> no, I was offline, will check irclogs in 5 minutes
[23:00] <fta> hm, http://libjpeg-turbo.virtualgl.org/   interesting
[23:01] <micahg> yeah, I saw a bug on that
[23:02] <micahg> fta: it should just be lpia that's not buillding
[23:02] <fta> i know
[23:02] <fta> but when it's not that, it's something else
[23:03] <fta> qa, test builds, whatever
[23:03] <fta> i will try one last time to extract ppa stats from lp, if i can't, out


[09:44] <Danatela> hi guys!
[09:45] <Danatela> If I have dependency problem with a specific PPA, should I contact this PPA owner or someone else?
[09:48] <Noskcaj> Danatela, PPA owner
[09:49] <Danatela> thanks!
[20:56] <Unit193> Logan_: MIA team was just contacting Jochen Friedrich, maintainer of Darkice.


[05:01] <Takyoji> Finally spring break for me
[23:24]  * Obsidian1723 If anyone wants/needs some free online storage space, Dropbox normally gives 2GB free, but if you use this link, you'll get an additional 250MB free when you sign up for a free account. https://www.dropbox.com/referrals/NTkxNDE5MTk
[23:36]  * Obsidian1723 sorry all, wasn not mean to go across all channels like that.


[06:50] <davecheney> fwereade: aloha!
[06:50] <fwereade> davecheney, heyhey
[06:50] <fwereade> davecheney, how's it going?
[06:50] <davecheney> good
[06:51] <davecheney> spent the weekend looking at ARM assembly
[06:51] <davecheney> so a change is as good as a holiday
[06:54] <fwereade> davecheney, excellent :)
[07:33] <TheMue> Morning.
[07:33] <fwereade> heya TheMue
[08:05] <fwereade> TheMue, ping
[08:05] <TheMue> fwereade: pong
[08:05] <fwereade> TheMue, figuring out what I should work on; wondering how the relation stuff is going
[08:06] <TheMue> fwereade: One moment please, have to change rooms.
[08:06] <fwereade> TheMue, np
[08:10] <TheMue> fwereade: So, back again. My wife has been in the home office before. ;)
[08:11] <TheMue> fwereade: Currently the State.AddRelation() and State.RemoveRelation() are in review and short before LGTM.
[08:12] <TheMue> fwereade: But Roger and Gustavo discussed and want to keep open, that a service might have relations of the same role mltiple times in future.
[08:12] <TheMue> fwereade: So I'll now change the topology for it and afterwards the AddRelation() and RemoveRelation() to use this new model.
[08:14] <fwereade> TheMue, ok, cool, so not *imminent* -- cheers :)
[08:14] <TheMue> fwereade: Next step will then be to enhance AddRelation() by a better verification of the endpoints. Today it has the same checks as the Py code, but it's not enough.
[08:16] <TheMue> fwereade: What is not so imminent?
[08:32] <fwereade> TheMue, sorry, got diverted; I mean that a usable state.Relation type is still some way off
[08:33] <TheMue> fwereade: There's enough to do, yes.
[08:33] <fwereade> TheMue, cool; I should probably do something that doesn't depend on it then :)
[08:33] <TheMue> fwereade: Or participate. ;)
[08:34] <fwereade> TheMue, if you think the work can be usefully divided that would be cool -- what's the plan?
[08:35] <TheMue> fwereade: That's the problem, there is no real plan. I'm just doing the functionality top-down. I've started with the relation manager, those methods move into our new State.
[08:35] <TheMue> fwereade: Next step would be relation type by type.
[08:36] <TheMue> fwereade: I've seen that the service relation has a lot of functionality.
[08:36] <fwereade> TheMue, I could happily try to do some rudimentary types
[08:36] <fwereade> TheMue, see how far I can take them
[08:37] <fwereade> TheMue, what's the latest stable-ish unmerged relations branch? if you think some will go in soon, it seems sensible to branch from there
[08:38] <TheMue> fwereade: The latest is go-state-remove-relation. But it has a line of prerequisites.
[08:39] <fwereade> TheMue, and is that likely to be merged by the time I have a new type to propose on top of it? and not to change too much between now and then?
[08:39] <TheMue> fwereade: So maybe you should wait until the all are in the trunk.
[08:40] <TheMue> fwereade: I hope to keep the API stable, as well as the types so far.
[08:40] <TheMue> fwereade: Right now only the topology below is changed.
[08:40] <fwereade> TheMue, ok; in that case I can probably just go from trunk, right?
[08:41] <TheMue> fwereade: In trunk there's the current topology, but not yet the relation types as well as Add and Remove.
[08:42] <fwereade> TheMue, I'm just re-checking your current proposals to get myself more up to speed
[08:43] <TheMue> fwereade: Yes, take a look. I think both will go in today or tomorrow.
[08:43] <TheMue> fwereade: Just wait for the LGTM. The Add… had a pre-LGTM by Gustavo.
[08:43] <fwereade> TheMue, hmm, so I should maybe branch from add-relation and add functionality to ServiceRelation?
[08:44] <TheMue> fwereade: Sounds like a plan. ;) In Remove… it only has one method more to return the according Relation.
[08:45] <fwereade> TheMue, cool, I'll ping you if I have any trouble
[08:46] <TheMue> fwereade: Cheers.
[08:46] <TheMue> fwereade: You'll see that those zkXyz are now topoXyz, as we talked about in Oakland.
[08:46] <fwereade> TheMue, sweet
[10:34] <fwereade> TheMue, just mailed juju-dev; would apreciate your thoughts
[10:35] <TheMue> fwereade: Will take a look.
[10:38] <TheMue> fwereade: To summarize: Interface changes (with checks) are ok, but no subordinate changes. Am I right?
[10:38] <fwereade> TheMue, that's what I *think* we should do
[10:39] <fwereade> TheMue, you tell me whether that's right :)
[10:40] <TheMue> fwereade: Hehe, then you have to help me with subordinates before. Where do we find it in our model?
[10:40] <fwereade> TheMue, we don't really yet
[10:41] <fwereade> TheMue, I think that I need to incorporate them before we can move much further ahead on the relations
[10:41] <TheMue> fwereade: Could you please tell me more about subordinates?
[10:41] <fwereade> TheMue, I'm just changing Service.AddUnit to take (container *Unit) and seeing where I go from there
[10:41] <fwereade> TheMue, ok, I'll try
[10:42] <fwereade> TheMue, charms can be subordinate
[10:42] <fwereade> TheMue, if they are, their characteristics change
[10:42] <fwereade> TheMue, when deployed, no units are created
[10:42] <TheMue> fwereade: Do you have an example?
[10:43] <fwereade> TheMue, when added to a relation, units of the subordinate are deployed inside the containers of every unit of the principal service
[10:43] <fwereade> TheMue, rsyslog would make a good subordinate charm
[10:44] <fwereade> TheMue, there are a number of other consequences which I only really discovered today
[10:44] <fwereade> TheMue, and am not quite sure I have a handle on
[10:44] <fwereade> TheMue, so stop me if anything sounds like crack
[10:45] <fwereade> TheMue, one of the issues is that the "connections" are different to in a normal relation
[10:45] <fwereade> TheMue, in a normal relation between P and Q, every unit of P can see every unit of Q, and react to settings changes; and vice-versa
[10:45] <TheMue> fwereade: It's ok so far. I only try to understand it right. Typically I've used to work a lot with my colleagues around a whiteboard. I need to visualize it.
[10:46] <fwereade> TheMue, in a subordinate relation, each unit of P sees only the unit of Q that it shares a container with
[10:46] <fwereade> TheMue, and settings changes are processed entirely within, and do not leak beyond, that container
[10:47] <fwereade> TheMue, (everything is still mediated by ZK, obviously; but a settings change for one unit of P will not e noted by a unit of Q outside its container
[10:48] <fwereade> TheMue, so... when storing unit relations, we have different ZK paths to the settings etc
[10:48] <TheMue> fwereade: IC
[10:49] <fwereade> TheMue, we currently handle the /relations/rel-id case, which is what we want globally; but we also need /relations/rel-id/unit-id (I think)
[10:49]  * fwereade goes to check
[10:51] <fwereade> TheMue, yeah; and the unit-id I referred to above is specifically the unit id of the principal (ie the one that "owns" the container
[10:51] <fwereade> )
[10:51] <TheMue> fwereade: In Py there's code handling /relations/rid/cid/role
[10:51] <TheMue> fwereade: Where cid is the container id
[10:51] <fwereade> TheMue, and also /relations/rid/role, right?
[10:52] <TheMue> fwereade: For global relations, yes.
[10:52] <fwereade> TheMue, AIUI the structure of the nodes underneath that should be similar
[10:52] <fwereade> TheMue, does that seem right to you?
[10:53] <fwereade> TheMue, look for _get_scope_path and how it's used
[10:54] <TheMue> fwereade: Thought it is, but not yet covered the container scoped relations.
[10:55] <fwereade> TheMue, I'll proceed as though it is; can't be sure of every use of it yet but we'll see how it goes
[10:56] <fwereade> TheMue, the topology also changes to accommodate knowledge of what container a given unit is actually deployed
[10:56] <fwereade> TheMue, in
[10:56] <fwereade> TheMue, anyway, I'm just making those changes to begin with
[10:58] <TheMue> fwereade: So this is also a topology change to the current Py version?
[10:58] <fwereade> TheMue, no, it's part of the topology already in py
[10:58] <TheMue> fwereade: OK, then I got you wrong, sorry.
[11:04] <TheMue> Lunchtime
[11:54] <Aram> heyhey.
[12:11] <TheMue> Aram: Hiya.
[12:16] <hazmat> g'morning
[12:25] <fwereade> Aram, hazmat: heyhey
[12:39] <fwereade> heya niemeyer
[12:39] <niemeyer> Yo
[12:39] <niemeyer> !
[12:51] <fwereade> niemeyer, TheMue, Aram: conundrum follows
[12:52] <fwereade> in the topology, in python, we store Machine and Container for each unit
[12:52] <fwereade> only one of those can ever be valid
[12:53] <fwereade> I just got an urge to store Location, which is just a unit key or a machine key (and we can tell which is which, right?)
[12:53] <fwereade> this feels kinda evil, but so does allowing the content to be insane by having both or neither set
[12:53] <fwereade> niemeyer, TheMue, Aram: opinions? ^^
[12:54] <fwereade> niemeyer, TheMue, Aram: I'm leaning towards storing them under separate keys and just being careful about what we write, but...
[12:55] <niemeyer> fwereade: Having a single key feels bad indeed
[12:55] <fwereade> niemeyer, TheMue, Aram: hmm, *at the moment* only one can ever be correct
[12:55] <fwereade> niemeyer, TheMue, Aram: forget I said anything :)
[12:55] <niemeyer> fwereade: They're different fields meaning different things.. having to guess what the field means based on the value isn't great
[12:55] <fwereade> niemeyer, indeed
[12:55] <fwereade> niemeyer, we could still have garbage set in that one field anyway
[12:55] <TheMue> fwereade: Forgotten. ;)
[12:56] <niemeyer> fwereade: can you please expand? Maybe I misunderstand
[12:57] <fwereade> niemeyer, I'm agreeing -- the extra guard against insanity of the icky magic field doesn't eliminate the possibility of insanity anyway, so so even that is not an argument for the icky magic field over two separate fields
[12:57]  * fwereade should go and borrow a cuddly toy from laura to ask these questions to before polluting irc :)
[12:58] <niemeyer> fwereade: Hehe. Jamu used to call that "talking to the bear" :-)
[12:58] <fwereade> niemeyer, yeah, it's a noble technique, we had a cat called mutex at resolver who sometimes served that purpose
[12:59] <TheMue> fwereade: Hehe, or take your pet to talk to (if you got one). Cats are good listeners.
[12:59] <fwereade> TheMue, just a cuddly cat actually
[12:59] <fwereade> TheMue, I'm not sure a real cat would have the patience anyway ;)
[12:59] <TheMue> fwereade: I'm sure -- it doesn't. *lol*
[13:03] <niemeyer> fwereade: That's a great name for a cat :)
[13:04] <fwereade> niemeyer, isn't it :)
[13:33] <TheMue> niemeyer: One question about the topo service inversion. Shall I open the combination of roles even if e not yet use them or shall I keep the current validation for provider/requirer or peer?
[13:33] <niemeyer> TheMue: The validation is fine
[13:33] <niemeyer> TheMue: I mean, it will have to be adapted, of course
[13:33] <niemeyer> TheMue: Given the map change
[13:34] <TheMue> niemeyer: Sure, but I'll keep it and later we can extend it. OK.
[13:34] <niemeyer> TheMue: But we don't have to pretend it's general right now.. we just don't want to shoot ourselves in the foot
[13:34] <TheMue> niemeyer: Could hurt, indeed. ;)
[14:04] <TheMue> niemeyer: So, change is done. Influence on State.AddRelation() is small, only three lines.
[14:21] <fwereade> niemeyer, TheMue: https://codereview.appspot.com/6268050 has subordinate units
[14:23] <niemeyer> fwereade: Woohay
[14:23] <niemeyer> TheMue: Woohay too :)
[14:23] <TheMue> :D
[14:23] <fwereade> niemeyer, er, there'll be a small diff upcoming, missed a signature change in the rest of the project
[14:23] <fwereade> niemeyer, should be a trivial additional file changed
[14:24] <fwereade> niemeyer, ie shouldn't block sane reviewing if you're of a mind :)
[14:25] <niemeyer> fwereade: Not yet.. still trying to catch up on post-sprint stuff
[14:25] <niemeyer> fwereade: But I'll get there
[14:25] <fwereade> niemeyer, no worries :)
[14:27] <fwereade> niemeyer, btw, tyvm for reviewing what you did during the sprint, hope it didn't take too much time away
[14:28] <niemeyer> fwereade: No problem. It didn't take much time away because I've used the evenings for the largest chunks
[14:28] <fwereade> niemeyer, jolly good, thanks :)
[14:30] <fwereade> niemeyer, TheMue, Aram: oh, blast: I've put myself in a situation in which I need two prereqs for the next branch
[14:30] <fwereade> niemeyer, TheMue, Aram: did we ever come up with a nice way of dealing with this?
[14:30] <niemeyer> fwereade: Is any of them small enough that I can review quickly?
[14:31] <niemeyer> fwereade: There's no way to handle that automatically with current infra
[14:31] <niemeyer> fwereade: Launchpad doesn't support it
[14:31] <fwereade> niemeyer, one of them is TheMue's add-relation branch
[14:31] <niemeyer> fwereade: Hmm
[14:31] <fwereade> niemeyer, which IIRC has an LGTM from you already actually
[14:31] <niemeyer> fwereade: I thought that was in already
[14:31] <TheMue> fwereade: There's only a final lgtm missing.
[14:31] <niemeyer> Link?
[14:32] <TheMue> niemeyer: I only proposed it for the final one after the last open points.
[14:32] <TheMue> niemeyer: https://codereview.appspot.com/6223055/
[14:33] <TheMue> niemeyer, fwereade: I'm ready for submitting it.
[14:34] <fwereade> TheMue, if it has an LGTM you should be good to go unless you disagreed with any of the points in the LGTM
[14:34] <fwereade> TheMue, I have been known to be too hesitant on this front :)
[14:35]  * TheMue likes clean LGTMs. ;)
[14:35]  * fwereade lives in hope of them, and is most joyful when they come to pass
[14:35] <niemeyer> TheMue: LGTM
[14:35] <TheMue> niemeyer: Ah, thx, here it comes.
[14:36] <fwereade> niemeyer, thanks, sorry context switch :(
[14:36] <niemeyer> fwereade point applies in this case, FWIW.. your branch reflected the agreement of the last review
[14:36] <niemeyer> fwereade: No problem, happy to prevent blockage
[15:01] <TheMue> niemeyer: Updated the latest propose (topology). Now the new trunk containing State.AddRelation() is merged, the changes adopted and all lamps are green.
[15:02] <niemeyer> TheMue: Beautiful, thank you
[15:02] <niemeyer> !
[15:02] <TheMue> niemeyer: np :D
[20:31] <niemeyer> mramm: ping
[21:45] <mramm> pong
[21:46] <mramm> neimeyer: pong
[22:00] <niemeyer> mramm: Heya
[22:01] <niemeyer> mramm: Are you subscribed to juju-dev?
[22:02] <niemeyer> davecheney: ping
[22:18] <davecheney> niemeyer: ack
[22:18] <davecheney> hang on
[22:18] <davecheney> let me change terminals
[22:18] <davecheney> x has shat itself
[22:21] <davecheney> niemeyer: back
[22:21] <niemeyer> davecheney: Heya
[22:21] <niemeyer> davecheney: Morning
[22:21] <davecheney> yes! finally it wasn't raining, so it was my first chance to go for a ride before work for weeks!
[22:21] <davecheney> niemeyer: how was your trip ?
[22:21] <niemeyer> davecheney: Oh, congrats! :)
[22:22] <niemeyer> davecheney: It was great indeed.. very happy that I managed to meet Aram and rogpeppe in addition to the unrelated sprint
[22:22] <davecheney> niemeyer: didn't you meet roger at UDS ?
[22:22] <davecheney> :P
[22:23] <davecheney> btw, is Aram the Aram taht wrote doozer ?
[22:23] <niemeyer> davecheney: Yeah, but it was great even then.. we managed to cover some interesting ground there
[22:23] <niemeyer> davecheney: He's the Aram that patched doozer for persistence, yeah
[22:23] <niemeyer> ;)
[22:23] <davecheney> niemeyer: i had a great day with rog when we went to the computer history museum
[22:23] <niemeyer> davecheney: By the way, I've pushed a gozk branch that does the semantic change I mentioned
[22:23] <davecheney> 5 hours on SF public transport left ample time for getting to know each other
[22:24] <davecheney> niemeyer: sweet, i'll go get -u now
[22:24] <niemeyer> davecheney: I didn't submit yet, but if you LGTM it I'll push it on
[22:24] <davecheney> niemeyer: does the notification go to gophers ?
[22:24] <davecheney> i haven't seen an email
[22:24] <niemeyer> davecheney: I'd hope so
[22:24] <davecheney> i guess not
[22:25] <davecheney> let me double check
[22:25] <davecheney> https://codereview.appspot.com/6292044
[22:25] <davecheney> but no email, i just foudn that from your reply to my handover note
[22:28] <niemeyer> Hmm
[22:28] <niemeyer> Weird
[22:28] <davecheney> am i a member of golang-gophers? or just the juju project ?
[22:40] <niemeyer> davecheney: I'm somewhat concerned with the lack of tests in the provisioner brancher.. there are tons of edge cases there that are being carefully considered but untested
[22:41] <niemeyer> davecheney: I'm sure you've tested by hand or at least put good thought on these edge cases
[22:42] <davecheney> niemeyer: yes, i wonder how I can decompose the functions to test them
[22:42] <niemeyer> davecheney: Have you used TDD before?
[22:42] <davecheney> nope
[22:43] <niemeyer> davecheney: Ok.. there are a couple of good books that might be useful.. I like the one from Kent Beck, but just last week I've received good feedback on Growing Object-Oriented Software, Guided by Tests by Steve Freeman
[22:43] <niemeyer> davecheney: I suspect Kent Beck might be more to-the-point in terms of TDD specifically, though
[22:44] <niemeyer> davecheney: Regarding decomposing the functions, that may not be necessary
[22:44] <niemeyer> davecheney: I'm more concerned about testing the real edge cases than the *implementation*
[22:45] <niemeyer> davecheney: A simple example: if a misconfigured environment somehow arrives, the new configuration is ignored, but a follow up configuration actually takes place
[22:46] <niemeyer> davecheney: We can integrate this branch before that, though.. I'm happy to have those increments nicely done on top of that, given that what we have in place was well debated over already
[22:46] <davecheney> niemeyer: cool
[22:46] <niemeyer> davecheney: Right now I'm just doing some minor commenting on trivial stuff like log messages and whatnot
[22:47] <davecheney> niemeyer: ... wondering how to observe a misconfigured environment being rejected
[22:47] <niemeyer> davecheney: What we care about is not that it is rejected, but that the provisioner itself stays up
[22:48] <niemeyer> davecheney: and that a follow up correct configuration is loaded
[22:48] <davecheney> niemeyer: gotcha
[22:48] <davecheney> understood
[22:49] <davecheney> making a list now
[22:49] <davecheney> * provisioning does not occur with broken env
[22:49] <davecheney> * provisioning does occur when env is valid, then broken
[22:49] <davecheney> * provisioning does occur when env is valid, then broken, then valid
[22:50] <davecheney> niemeyer: are you comfortable with me integrating those into the woodenman branch ?
[22:50] <niemeyer> davecheney: woodenman? Do we already have another branch up? Sorry, I'm still catching up
[22:51] <davecheney> yeah, strawman is the basic provisioning agent that just obseverves environment changes
[22:51] <davecheney> woodenman is the follow on that actually pokes the Environ when it needs to add machines, etc
[22:52] <niemeyer> davecheney: I'd prefer to fix these outstanding issues before we increase the functionality
[22:52] <niemeyer> davecheney: We have quite a few pending things there
[22:52] <davecheney> sure
[22:52] <niemeyer> davecheney: Tests, state issues within the loop (maybe?), state reconnection
[22:52] <davecheney> ok
[22:53] <niemeyer> davecheney: If we add more logic, we'll be increasing the debt
[22:53] <niemeyer> davecheney: It's not clear to me we need IsValid anymore, btw, assuming the gozk branch
[22:53] <niemeyer> davecheney: We'll have to think about it..
[22:53] <niemeyer> davecheney: Well.. and maybe a test
[22:54] <davecheney> niemeyer: no, as long as the watchers close, then I can return to the Run function, tear everything down, and start again
[22:56] <davecheney> niemeyer: re: gozk, I guess that looks good
[22:57] <davecheney> i don't think i can comment authoratively
[23:02] <niemeyer> davecheney: Actually, we may still need a note from the state
[23:02] <davecheney> niemeyer: that is what I thought of from IsValid()
[23:02] <niemeyer> davecheney: Yeah, may be good to be explicit
[23:03] <davecheney> so the innerLoop becomes for state.IsValid() { .... }
[23:03] <niemeyer> davecheney: Yeah, or IsConnected
[23:04] <davecheney> niemeyer: yup, i'm not fussed about the name
[23:04] <niemeyer> davecheney: I know, just brainstorming as we go
[23:04] <davecheney> I had the idea that that would return false after some event that caused the state to be 'broken'
[23:05] <niemeyer> davecheney: We can watch the session channel for that
[23:05] <niemeyer> davecheney: Should be an easy walk
[23:05] <niemeyer> davecheney: Anything returning event.Ok() != true can set the flag to red
[23:08] <niemeyer> davecheney: Actually, now that I think of it.. I don't think the complexity of machinesChanges and environChanges makes sense anymore, with those decisions
[23:09] <niemeyer> davecheney: Just imagine in which circumstances these channels will break
[23:09] <davecheney> niemeyer: you mean making them recreate themselves
[23:09] <niemeyer> davecheney: Oh, duh.. please ignore me
[23:09] <niemeyer> davecheney: No, wait.. I'm confused
[23:10] <niemeyer> davecheney: These channels are internally reestablished..
[23:10] <niemeyer> davecheney: Yeah, the initial idea seems to proceed
[23:10] <niemeyer> davecheney: We only need to recreate on !ok, right?
[23:13] <davecheney> niemeyer: they are only recreated if, a, they were nil to begin with (just started up) or b, their Stop() method was called, in response to them being closed
[23:14] <niemeyer> davecheney: Yeah, in that second scenario, it doesn't really make sense to bring them back
[23:14] <niemeyer> davecheney: If they're dead, the state itself must be dead too
[23:14] <davecheney> niemeyer: with your change, that is now true
[23:15] <niemeyer> davecheney: That said, it's a trivial simplification we can do in a second moment.. not hurting reliability, so let's move on
[23:15] <davecheney> they anre't recreated util you go through the loop again, so if the loop has a condition that is false if the state is closed
[23:15] <davecheney> they wont' be recreated
[23:15] <niemeyer> davecheney: It was always true..
[23:16] <niemeyer> davecheney: We've changed !ok to happen more frequently, but it was always the case that with !ok the state is dead
[23:16] <davecheney> niemeyer: absolutely, just those channels never closed
[23:16] <niemeyer> davecheney: Exactly, and stop is only called when they closed
[23:16] <davecheney> so, we can use !ok as a proxy for state is closed
[23:16] <davecheney> ok, that makes things simpler
[23:17] <niemeyer> davecheney: Yeah, I think so too
[23:17] <davecheney> if a watcher closes, it's underlying state is closed, so collapse back to the top, cleaning up as we go, then start again
[23:17] <niemeyer> davecheney: Right
[23:17] <niemeyer> davecheney: I think we pretty much never have to retry in place
[23:17] <niemeyer> davecheney: These scenarios are edge cases anyway, and we need to handle harsher scenarios too
[23:18] <niemeyer> davecheney: So we can safely handle hiccups in conservative ways
[23:18] <davecheney> niemeyer: i also wanted to ask you about retring
[23:18] <davecheney> retrying
[23:18] <niemeyer> davecheney: and proceed as if they were major breakups
[23:18] <davecheney> roger suggested there was some retry logic in the ec2 code, but unless he's talking about goamz, I couldn't find it
[23:18] <niemeyer> davecheney: Hopefully we'll also be better off when the major break does happen
[23:19] <niemeyer> davecheney: No, there is indeed, inside environs/ec2
[23:19] <davecheney> grep -i -r retry didn't help me, i'll try again
[23:19] <niemeyer> davecheney: grep for shortAttempt
[23:19] <davecheney> ok
[23:19] <niemeyer> davecheney: Should give you the seed
[23:19] <davecheney> i want to reuse that for the loop at the top of the PA, so we dont' jump straight back in
[23:20] <niemeyer> davecheney: Nice; feel free to refactor it off
[23:20] <davecheney> niemeyer: ok
[23:22] <davecheney> niemeyer: https://launchpad.net/~gophers << i'm still pending approval
[23:22] <davecheney> :(
[23:22] <niemeyer> davecheney: Hah, sorry
[23:22] <niemeyer> davecheney: That explains it
[23:22]  * davecheney feels slighted
[23:22] <niemeyer> davecheney: Ok, review delivered
[23:23] <davecheney> thank you very much
[23:23] <davecheney> who is going to look at IsConnected ?
[23:23] <niemeyer> davecheney: I think the branch can go in with those changes, but I'm fine as well if you decide to refactor it further with some of these ideas we just discussed
[23:24] <davecheney> niemeyer: I would liek to land it today, if there are no objections, then follow up with the other things we have discussed
[23:24] <niemeyer> davecheney: Feel free to do it if you feel like it, or we can ask TheMue to have a look at it
[23:24] <davecheney> niemeyer: re IsConneced, i'll take a look today and hand over to TheMue at 4pm if I get stuck
[23:25] <niemeyer> davecheney: Okay, so let's move ahead.. fixing the comments/messages/etc, so we can get it in with a state we're both happy with
[23:25] <davecheney> ok
[23:25] <niemeyer> davecheney: Okay.. the idea is really simple: we have a loop with event, ok <- session in open.go already.. we just have to add a check to see if event.Ok() for each event received, and set a protected variable in case it's false
[23:26] <niemeyer> davecheney: You can find some Stop/Start tests within zk_test.go that may be useful
[23:26] <niemeyer> davecheney: Look for Reconnect in the test name
[23:27] <niemeyer> / .. but we take all session events that occur before a session is established
[23:27] <niemeyer> as errors.
[23:27] <davecheney> niemeyer: in state/open.go ?
[23:27] <niemeyer> davecheney: Hmm
[23:28] <niemeyer> davecheney: The comment seems clear.. all session event on non-session watches are fatal
[23:28] <davecheney> i guess i don't understand what a zk session is
[23:29] <niemeyer> davecheney: THere are two kinds of watches: a requested watch (e.g. GetW), and the session watch that is obtained via Dial
[23:29] <niemeyer> davecheney: Both of these receive events
[23:29] <davecheney> so a session watch observes everything, a getw is scoped to a path ?
[23:29] <niemeyer> davecheney: The session watch receive *only* connectivity state changes
[23:30] <davecheney> ahh, of course, events about this session, this connection
[23:30] <niemeyer> davecheney: The session watch receives both these and the actual requested watch
[23:30] <niemeyer> davecheney: Yeah.. I call them session events because they actually have a code of EVENT_SESSION
[23:31] <niemeyer> davecheney: It is confusing indeed, sorry
[23:31] <niemeyer> davecheney: Is there a way I can improve that comment in a more understandable way?
[23:32] <davecheney> niemeyer: no, it makes sense now.
[23:33] <davecheney> so if you're a watcher, and you receive an EVENT_SESSION, it's a signal that you should close
[23:33] <davecheney> your comment is correct
[23:36] <davecheney> afk 15 mins
[23:38] <niemeyer> davecheney:
[23:38] <niemeyer>                 // All session events on non-session watches will be delivered
[23:38] <niemeyer>                 // and cause the watch to be closed early. We purposefully do
[23:38] <niemeyer>                 // that to enforce a simpler model that takes hiccups as
[23:38] <niemeyer>                 // important events that cause code to reestablish the state
[23:38] <niemeyer>                 // from a pristine and well known good start.
[23:38] <niemeyer>                 if event.State == STATE_CONNECTED {
[23:38] <niemeyer>                         // That means the watch was established while we were still
[23:38] <niemeyer>                         // connecting to zk, but we're somewhat strict about only
[23:38] <niemeyer>                         // dealing with watches when in a well known good state.
[23:38] <niemeyer>                         event.State = STATE_CONNECTING
[23:39] <niemeyer>                 }
[23:39] <niemeyer> davecheney: Hope that's more understandable
[23:45] <davecheney> +1e9
[23:45] <davecheney> niemeyer: my only change would be
[23:46] <davecheney>  // important events which cause code to reestablish the state