[00:00] <RAOF> Wasn't there some flash-not-working-right with the new eglibc?
[00:02] <slangasek> yes, but that shouldn't hang the browser
[00:02] <slangasek> but the flash issue is one of the two fixed in -0ubuntu2
[00:03] <hrw> RAOF: ok, disabled all plugins
[00:05] <hrw> ok, not hangs now so far. just waiting for packets which got stuck in queue to this 33600 modem which whole conference is using
[00:06] <hrw> thanks
[00:08] <hrw> ok, was too optimisti ;( but ignore me - I lack mood to debug it - its too late in day
[00:09] <slangasek> hrw: just in case, please try upgrading libc6 when you have a chance (just published)
[00:10] <hrw> slangasek: I will
[00:12] <hrw> once will get there with elinks ;D
[00:13] <slangasek> heh
[00:26] <hrw> ok, ubuntu2 installed, reboot to get them reloaded
[00:30] <hrw> yay! much better
[03:33] <nigelb> I didn't expect a bourbon ping in this channel :)
[03:33] <nigelb> Problems of having that as a safe word ^-^
[05:56]  * pitti retries the webkit build which causes so much uninstallability; the i386 build hit -ENOMEM
[06:01]  * micahg hopes a rebuild helps
[06:16] <pitti> it's on a different buildd now
[06:16] <pitti> can only cross fingers
[06:16] <pitti> we really need a real staging area, such as -proposed
[06:17] <RAOF> I thought precise-proposed was already open, for exactly that reason?
[06:17] <pitti> yes, we just didn't start using it yet
[06:17] <pitti> everyone uses PPAs
[06:17] <RAOF> Yeah, I'm not entirely sure why :)
[06:18] <pitti> but we can't do binary copies from them
[06:18] <pitti> would be better to use precise-proposed, for new X.org, eglibc, gtk, glib etc. versions
[06:18] <pitti> I guess we just need to start trying
[06:18] <pitti> it's some extra overhead as they need to be hand-approved, but archive admins wouldn't actually need to read debdiffs
[06:23] <RAOF> We can do binary copies from (specially calibrated) PPAs, but you're right; they're not available to all.
[06:24] <RAOF> Is it trivial to auto-approve everything in precise-proposed until release?
[06:26] <broder> i wonder if my pre-release backports patch already covers this...
[06:26] <broder> let me look
[06:27] <broder> although i suspect you want s/release/archive freeze/ or something
[06:27] <ajmitch> broder: the one for opening up backports next week or so? :)
[06:27] <broder> yup!
[06:28] <ajmitch> what are the restrictions going to be on uploading new packages there?
[06:30] <broder> uh, i believe the plan approved by the TB was that all uploads would land in UNAPPROVED
[06:30] <broder> like they do now
[06:31] <broder> so that might not help RAOF's problem
[06:31] <broder> though i will note that currently it is not possible to upload to a non-RELEASE pocket if a release is not either frozen or stable
[06:31] <ajmitch> are pre-release uploads to backports likely to be copied to the main archive for q when it opens?
[06:31] <RAOF> Not really RAOF's problem; I'm a canonical employee, so can request a super-PPA that *can* be binary-copied from.
[06:32] <broder> heh, fine
[06:32] <broder> ajmitch: they *will* be copied to q. that's part of the rules
[06:32] <RAOF> But a problem in general, yes :)
[06:32] <ajmitch> broder: ah, excellent :)
[06:32] <broder> though "copy" may actually be "script bumping the version number and re-uploading"
[06:32] <ajmitch> either way, it's useful
[06:33] <broder> the approved plan also auto-files bugs against backports if a change to the release pocket should "supersede" a change in backports
[06:33] <broder> to tell us that we need to do a merge
[06:33] <ajmitch> it means less bugging the release team for FFEs for new packages
[06:33] <broder> right. in general, the intent is to remove some of the pressure for FFEs all aroudn
[06:33] <broder> or at least part of the intent
[06:34] <broder> https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html is my post with the updated proposal based on TB feedback
[06:34] <broder> the stuff at the end of the e-mail is more interesting/relevant than the quote
[06:34] <ajmitch> thanks
[06:36] <broder> pitti: ^ fyi, when i was looking into the pre-release backports stuff, i discovered that you can only upload to a non-RELEASE pocket if the series status is FROZEN, CURRENT, or SUPPORTED, so we can't actually use -proposed right now
[06:36] <pitti> broder: oh, so that was it
[06:36] <pitti> because we did use devel-proposed in the last days of a release heavily, but at that time it was FROZEN
[06:37] <broder> yeah, i'm surprised we didn't notice it, though, since we've been using 0-day srus fairly heavily lately
[08:08] <dholbach> good morning
[08:25] <dholbach> It's Sponsorship Friday! :)
[08:25] <dholbach> @pilot in
[08:26] <seb128> @pilot in
[08:26]  * dholbach hugs seb128
[08:26] <dholbach> let's see how many pilots we can fit into the topic ;-)
[08:26] <seb128> dholbach, let's drive carefully, it's snowing out there ;-)
[08:27] <dholbach> haha
[09:08] <tjaalton> same here, haven't tried figuring out why
[09:10] <apw> presumably its s/w center that won't install, so it gets removed and to remove it we lose ubuntu-desktop
[09:10]  * apw will try and reinstall it shortly
[09:10]  * diwic runs upgrade instead of dist-upgrade today.
[09:11] <seb128_> could somebody reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040
[09:13] <apw>  libwebkitgtk-1.0-0 : Depends: libwebkitgtk-1.0-common (>= 1.7.5) but 1.7.4-0ubuntu1 is to be installed
[09:13] <seb128> apw, wait on the i386 build to success so the arch:all binaries are available, amd64 built first
[09:14] <apw> this new interdep between arches is just causing chaos
[09:14] <seb128> apw, it's not new?
[09:14] <seb128> it's there since ubuntu is there
[09:14] <seb128> but yeah, it's annoying
[09:17] <seb128> dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
[09:17] <seb128> dholbach, the fix got uploaded in a sru but I can't edit the merge request
[09:17] <dholbach> seb128, no, but I think pitti can
[09:18] <dholbach> and now fixing a bug from 2007-10-11, thanks Pojar George :)
[09:19] <seb128> dholbach, I hate how we can't edit those buggy merge requests ourself :-( do you know if anybody in launchpad is working on solving that issue?
[09:20] <dholbach> I think somebody is, but I forgot the bug number and stuff
[09:21] <seb128> dholbach, ok, don't bother
[09:21] <apw> seb128, the new multiarch dep between i386 and amd64 is new
[09:21] <apw> the randomly wanting to deinstall things is not new indeed, but we are triggering it in a whole lot of new ways now
[09:21] <seb128> apw, well in this case it's not multiarch, it's good all arch:all built on i386 and binaries depending on common = binary:Version
[09:22] <apw> ahh i see, my error
[09:22] <seb128> we should teach people to just use upgrade :p
[09:22] <apw> yeah except that doesn't work either
[09:22] <apw> in fact there is nothing safe one can do, pretty much ever
[09:22] <seb128> apw, well it will list those webkit binaries as on hold until they are built on i386
[09:22] <apw> and stupidly the most dangerous information is always off the top of ones screen
[09:23] <seb128> doing upgrade is a safe bet
[09:23] <seb128> then try dist-upgrade and see the few potential issues
[09:23] <seb128> upgrade at least helps to clear the one screen set of upgrade issues
[09:23] <apw> though you'll just end up with a hybrid pig over time
[09:23] <seb128> and let you with a small comprehensive set
[09:23] <apw> perhaps we should reorder the list, so removes are last
[09:23] <apw> then i might notice them :)
[09:23] <seb128> yeah
[09:24] <apw> or perhaps we could mark ubuntu-desktop in some way as 'ask them to type the alphabet backwards before allowing me to be deinstalled'
[09:24] <seb128> or we should make dist-upgrade do an upgrade first and show you the remaining part for confirmation then
[09:24] <apw> yeah, perhaps i'll alias it to that and see how that plays out
[09:25] <apw> how much less often i host my machine
[09:25] <apw> seb128, i thought the issue with using upgrade && dist-upgrade was that recommends arn't done for upgrades
[09:26] <apw> so you end up having to do like upgrade && dist-upgrade && install ubuntu-desktop^ to get a full install
[09:26] <seb128> oh, maybe
[09:26] <seb128> so screwed either way? ;-)
[09:26] <apw> that was kinda my point.  you do one and everyone tells you the other is the only safe one ... but clearly thats NP complete
[09:27] <dholbach> looking at mame now
[09:27]  * dholbach hugs jamespage
[09:28] <dholbach> jamespage, seb128: I wonder if we're going to set the record of most concurrent patch pilots today :)
[09:28] <seb128> ;-)
[09:28] <jamespage> **\o/**
[09:29] <seb128> cjwatson, on https://bugs.launchpad.net/ubuntu/+source/vim/+bug/856779 you wrote that you were going to sponsor to oneiric-proposed, it seems that didn't happen ... did you change your mind (i.e found a bug with the update) or was there an issue with the upload (i.e you forgot or it got rejected or something)
[09:31] <seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
[09:32] <seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
[09:37] <seb128> looking to https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/911342
[09:37] <dholbach> looking at unity-mail
[09:46] <jamespage> looking at bacula lzo support
[09:47] <dholbach> can somebody please mark https://code.launchpad.net/~geoubuntu/ubuntu/precise/tvtime/tvtime-1.0.2-fix_fulscreen_crash/+merge/92027 as 'rejected'? pitti or cjwatson maybe? (explanation in last comment)
[09:47] <dholbach> ciao fabbione - auguri! :)
[09:49] <fabbione> dholbach: thanks dude :)
[09:49] <dholbach> taking a look at gedit-developer-plugins
[10:06] <jamespage> looking at nova
[10:07] <dholbach> WAH Launchpad DB offline
[10:09] <Daviey> jamespage: nova?
[10:09] <jamespage> Daviey: looked at - zul has it in hand!
[10:09] <jamespage> unsub'ed sponsors
[10:11] <Daviey> cool
[10:15] <jamespage> looking at dahdi-linux
[10:29] <jamespage> looking at celt upgrade - no action required from sponsors so unsubscribing.
[10:31] <cjwatson> apw: your query didn't get through, so I'm not sure what you were talking about :)
[10:32] <cjwatson> seb128: upgrade isn't intrinsically safe, BTW, because it means your system will forget about new Recommends that were introduced by the packages it did manage to upgrade
[10:33] <apw> cjwatson, does a subsequent apt-get install ubuntu-desktop^ fix the missing recommends ?
[10:33] <seb128> cjwatson, yeah, apw pointed that as well, I didn't notice that until today, thanks ;-)
[10:33] <cjwatson> dholbach: tvtime> done
[10:34] <seb128> cjwatson, can you do those as well?
[10:34] <seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
[10:34] <seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
 dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
[10:34] <seb128>
[10:35] <cjwatson> seb128: gdb, bamf> done
[10:35] <seb128> cjwatson, thanks ;-) oh and did my question gvim went through? I timeouted at some point
[10:35] <cjwatson> apw: provided that the only Recommends in question are within the ubuntu-desktop task, which is likely to cover some but not all
[10:36] <cjwatson> seb128: yeah, I was just paging through the easy stuff in scrollback before looking at the stuff I'd have to think about ...
[10:36] <seb128> cjwatson, ok, thanks ;-)
[10:36] <cjwatson> seb128: my mailbox says the vim upload was rejected without explanation
[10:36] <cjwatson> perhaps a mistake by somebody?  it should still be resurrectable from the REJECTED queue if somebody wants to ...
[10:36] <seb128> cjwatson, can you reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 as well? thanks
[10:37] <cjwatson> a few ntfs-config uploads were rejected without explanation around the same time
[10:37] <apw> cjwatson, i had an overlapping apt-get update or similar break an inprogress dist-upgrade; this stopped the dist-upgrade dead in its tracks with a lock failure, but also left the system with 'E: Internal Error, No file name for libpam0g', install -f didn't fix it, i had to hand dpkg -i the file in /var/cache/apt/archive to recover
[10:37] <seb128> cjwatson, hum, did you get an accept,waiting in the queue and then rejected later? i.e it got rejected by somebody?
[10:37] <cjwatson> seb128: gnome-shell> done, though maybe you could leave a more detailed explanation in that case
[10:38] <seb128> cjwatson, doing so
[10:38] <cjwatson> apw: wacky, that should just have been impossible
[10:38] <cjwatson> seb128: accept/reject> no
[10:38] <cjwatson> just waited in the queue for a while and was then rejected
[10:38] <cjwatson> in retrospect I suspect that somebody fumble-fingered the web interface and didn't notice
[10:38] <cjwatson> it can be all too easy
[10:39] <seb128> right
[10:39] <apw> cjwatson, tjat was my feeling :/  still in case you see it agian, dpkg -i is your friend
[10:39] <seb128> do you still have the source? will you reupload?
[10:39] <cjwatson> seb128: LP still has it - it's in the rejected queue
[10:40] <cjwatson> pitti or RAOF could resurrect it from there
[10:40] <seb128> cjwatson, ok, thanks
[10:40] <seb128> I will check with them
[10:40] <cjwatson> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=4&queue_text=
[10:47] <cjwatson> tjaalton: it is annoyingly slow; in that ~12h there's the delay of Debian publishing the package (unavoidable, IIRC up to 6 hours or so) and then a possible delay of up to 7 hours before LP notices.  https://bugs.launchpad.net/launchpad/+bug/812597
[10:48] <om26er> dholbach, Hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/nux/sru-888039
[10:51] <tjaalton> cjwatson: yeah I was able to sync them maybe an hour ago
[10:51] <tjaalton> thanks for the bug, subscribed
[10:53] <seb128> dholbach, om26er: I can look at the nux sru
[10:54] <om26er> seb128, great, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/sru-764330/+merge/92296 as well
[10:54] <om26er> both should improve the overall performance of oneiric
[10:54] <seb128> om26er, I'm less sure about this one
[10:54] <seb128> dvv had https://code.launchpad.net/~vanvugt/ubuntu/oneiric/compiz/fix-763005-oneiric/+merge/90254 in the queue before you
[10:55] <om26er> seb128, dvv handed me the patch since the initial patch created a regression
[10:55] <seb128> om26er, can you merge both, test if the update work and resubmit yours?
[10:55] <seb128> om26er, should we drop the one I just pointed then?
[10:56] <om26er> seb128, this branch seems to fix another bug,
[10:56] <om26er> seb128, should i merge his fix in as well?
[10:57] <seb128> om26er, I'm confused by you saying that his fix is buggy
[10:57] <seb128> is it buggy or not?
[10:57] <om26er> seb128, its not buggy, its fine
[10:58] <seb128> om26er, ok, can you include this one as well in your update? no need to do 2 different srus and wait  week between those
[10:58] <om26er> seb128, yes doing that now, thanks
[10:58] <seb128> om26er, thank you
[11:11] <Sweetshark> requesting jonos rockstar skills urgently for https://plus.google.com/u/0/115750270177636397262/posts/9fNFpwRW3XK
[11:29] <dholbach> jamespage, seb128: I'll take a break from Sponsorship Friday and leave a few items for others now :)
[11:30] <jamespage> dholbach, ack
[11:30] <dholbach> I'd still love to see the topic overflow :-P
[11:30] <seb128> dholbach, same here, lunch time
[11:30] <seb128> dholbach, what was the count when we started? we are to 48
[11:31] <dholbach> seb128, yesterday when I sent the reminder mail it was 66
[11:31] <seb128> dholbach, ok, progress, still some way to do but for a morning it's not bad ;-)
[11:31] <dholbach> in my notes I have 9
[11:31] <om26er> seb128, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/perf-sru/+merge/92444 :)
[11:31] <seb128> dholbach, enjoy your lunch!
[11:31] <dholbach> you too :)
[11:32] <seb128> om26er, thanks, did you test run it? maybe put it in a ppa for the w.e, I doubt any sru member will approve it before monday anway
[11:32] <seb128> om26er, I will upload it to the queue today but still would be good maybe to get a bit of extra testing meanwhile
[11:32] <om26er> seb128, I have tested the patches from his ppa, I am going to put it into my ppa and test these two patches
[11:33] <Laney> can someone make https://code.launchpad.net/~l3on/ubuntu/oneiric/pdf-presenter-console/sru-922752/+merge/90606 go away from the queue? dholbach nacked it
[11:34] <om26er> Wellark, Hi
[11:34] <seb128> cjwatson, ^
[11:34] <cjwatson> Laney: done
[11:35] <Laney> ty
[11:35] <om26er> Wellark, can you please look into bug 930088 and tell what info would be needed.
[11:37] <Laney> cleaned two items without doing any work ;-)
[12:27] <jml> how does one tell if a particular package is on the CD?
[12:30] <glenn> When a patch is supplied to debian upstream, what exactly are the steps to get it into the ubuntu package?
[12:34] <glenn> there is a bug on launchpad, and a patch in the debian branch of the package
[12:34] <cjwatson> jml: grep the .manifest and/or .list files alongside the CD images
[12:35] <jml> cjwatson: thanks.
[12:36] <cjwatson> glenn: has it actually been uploaded to Debian?
[12:37] <glenn> cjwatson: good question :)
[12:37] <cjwatson> or committed to a branch maintained by the Debian maintainer?
[12:38] <glenn> cjwatson: yeah the patch was supplied on github, and the maintainer put it in
[12:38] <cjwatson> maybe URLs would help :-)
[12:38] <glenn> its in the bug report :)
[12:38] <glenn> https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/920995
[12:39] <cjwatson> so not yet uploaded to Debian
[12:39] <glenn> can i see that in the debian packages list?
[12:39] <cjwatson> http://packages.qa.debian.org/fail2ban
[12:40] <cjwatson> given that we aren't carrying any Ubuntu patches to fail2ban, I think the simplest answer is to wait for it to be uploaded to Debian, and then sync it
[12:40] <cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
[12:40] <glenn> cjwatson: is the fail2ban package on ubuntu a complete debian copy ?
[12:40] <cjwatson> yes
[12:41] <cjwatson> this advice only applies to precise; if it needs to be fixed in stable releases too, then https://wiki.ubuntu.com/StableReleaseUpdates
[12:42] <glenn> cjwatson: well, the exit status wasnt complient to lsb init
[12:42] <cjwatson> I understand that it is a bug
[12:42] <glenn> cjwatson: yeah it is
[12:42] <glenn> cjwatson: my first fixed bug though :)
[12:43] <cjwatson> there are however many bugs that we cheerfully don't fix in stable releases; there is a higher threshold for making any change there
[12:43] <glenn> yeah im reading the link
[12:43] <cjwatson> in any case, I carefully didn't express any opinion about whether this one should be fixed in stable releases or not, because I haven't thought about it enough
[12:43] <cjwatson> but the links above should help
[12:44] <glenn> cjwatson: so you actually saw the bugs i created
[12:44] <cjwatson> well, only when you linked to it
[12:44] <glenn> ah ok
[12:44] <glenn> this is new to me so im trying to find out the workflow
[12:44] <cjwatson> I don't have any involvement with fail2ban
[12:44] <cjwatson> just offering general advice
[12:46] <glenn> cjwatson: the sablereleaseupdates dont mention anything about lsb compliance
[12:46] <glenn> +t
[12:47] <cjwatson> nor should they
[12:47] <cjwatson> the SRU guidance offers general advice on the kinds of things that are suitable for stable updates; its purpose isn't to enumerate all the things that might be considered severe enough
[12:47] <cjwatson> you're meant to apply judgement :-)
[12:48] <glenn> cjwatson: severe severe... i wouldnt call it severe.. was just bad init script coding :)
[12:48] <glenn> its a bug though
[12:48] <cjwatson> sure; most bugs I fix, I only fix in the development release
[12:49] <glenn> so precise?
[12:49] <glenn> or onerice
[12:49] <cjwatson> precise
[12:49] <glenn> k k
[12:49] <glenn> so you fixed the kernel bug to?
[12:49] <glenn> with 3.2.0-14
[12:49] <cjwatson> huh?
[12:49]  * cjwatson <- not a kernel hacker
[12:49] <glenn> im using preseed, and it didnt work for 5 days
[12:49] <glenn> after alpha2
[12:49] <glenn> nm then :)
[12:49] <cjwatson> the installer was broken for a few hours due to kernel ABI desync; not five days, I don't know what that's about
[12:50] <cjwatson> probably nothing to do with me :)
[12:50] <glenn> cjwatson: i had to wait the whole weekend before preseed could install linux-virtual
[12:50] <glenn> and some more days
[12:50] <glenn> it was failing on the wget with a weird error while it was on the repo's
[12:52] <glenn> but thanks for your answers regarding the package
[12:52] <glenn> :)
[12:58] <glenn> cjwatson: is it correct that if the package was uploaded to debian and the debianimport for precise wasnt frozen yet, it wouldt have been auto-synced? and becuase of that i would now have to make a sync request?
[13:02] <cjwatson> glenn: correct
[13:03] <glenn> cjwatson: thats pretty cool :)
[13:04] <jibel> sbeattie, could you look at bug 930115 . regression in lucid
[14:00] <seb128> grrrrrr
[14:00] <seb128> sorry guys
[14:00] <seb128> https://launchpadlibrarian.net/92511991/buildlog_ubuntu-precise-i386.webkit_1.7.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:01] <seb128> "/usr/bin/ld: failed to set dynamic section sizes: Memory exhausted"
[14:01] <seb128> lamont, is there any way to get webkit i386 sent to build on a beefy builder?
[14:01] <seb128> we are going to have that amd64 installability issue for at least another 8 hours
[14:01] <seb128> since that build failed again
[14:02] <cjwatson> Does a sufficiently beefy builder exist?
[14:02] <lamont> what is the failure mode
[14:02] <lamont> doh
[14:02] <seb128> cjwatson, I don't know, what can we do if not? :-(
[14:02] <seb128> cjwatson, it built on amd64
[14:02] <cjwatson> Good question
[14:02] <cjwatson> We could perhaps assign an amd64 builder to i386 temporarily
[14:03] <cjwatson> Although I'd be surprised if there weren't already i386 builders in the same class
[14:03] <lamont> seb128: I'd like to see someone analyze it, but roseapple and allspice are both G6's with what should be plenty of RAM
[14:03] <glenn> cjwatson: the fail2ban package was just uploading to debian-unstable. could you show me an example requestsync commandliner for me on how to request a sync for it?
[14:03] <lamont> and swap
[14:03] <seb128> lamont, well my local built leaded to a ld using a bit over 3gb of ram
[14:03] <cjwatson> glenn: 'requestsync fail2ban precise'
[14:03] <lamont> penguins, antartic bases, elements, fruits, starnames.  later is better
[14:04] <lamont> seb128: file an RT about it mentioning RAM needs, and the builder that failed it?
[14:04] <seb128> lamont, if that helps...
[14:04] <cjwatson> so it requires PAE on i386, basically?
[14:05] <lamont> then get some buildd admin (webops?) to stuff the bunch on manual, score you through the roof, and automaticize allspice, and then the rest once it gets your package
[14:05] <seb128> I could also retry the build and see if I get lucky, but each retry takes some 8 hours and we have amd64 in uninstallable stable due to arch all,any mismatches
[14:05] <lamont> nice
[14:05] <seb128> lamont, so rt is the way to go?
[14:05] <seb128> sending one...
[14:05] <cjwatson> lamont: allspice is amd64 right now
[14:06] <lamont> roseapple
[14:06] <cjwatson> I can try it on roseapple now if there's a credible hope that it should succeed there
[14:06] <cjwatson> which builders has it failed on so far?
[14:06] <cjwatson> grr, just loading that build log has rendered firefox entirely unresponsive
[14:06] <lamont> cjwatson: roseapple or allspice should build it just fine, I expect
[14:07] <seb128> cjwatson, that built was vernadsky
[14:07] <seb128> let me see the previous one
[14:07] <lamont> I suspect that the "not-roseapple" i386 builders all have about 512MB of swap, and 2-4GB of RAM
[14:09] <lamont> seb128: and the ticket will be a dup of another one that says "review the RAM/SWAP on the builders and make it sane"
[14:09] <lamont> hints as to what amount of VM is "sane" are very much helpful in that process
[14:09] <seb128> cjwatson, I didn't keep the email from the previous build
[14:10] <cjwatson> ok
[14:10] <seb128> cjwatson, lamont: do we need a r-t or not?
[14:10] <cjwatson> just waiting for https://launchpad.net/ubuntu/+archive/test-rebuild-20120201/+build/3169749 to finish on roseapple
[14:10] <cjwatson> we should have an RT so that we don't have to fight with selecting the right builder in future
[14:10] <seb128> ok
[14:10] <lamont> seb128: not particularly for your rebuild, but yes, please file one about the memory footprint of webkit
[14:11] <lamont> mixed in with all that is the presumption that you've already asked yourself "is it sane that ld needs 3GB to link this beast?"
[14:11] <glenn> cjwatson: its telling me the versions are the same, but it was accepted in debian unstable with a newer version..
[14:11] <glenn> glenn: should i wait a bit?
[14:12] <cjwatson> seb128: try ld --no-keep-memory
[14:12] <lamont> -d unstable
[14:12] <glenn> mm
[14:12] <cjwatson> glenn: yes, you'll need to wait for a while
[14:12] <cjwatson> simplest to just make a note to try it tomorrow
[14:12] <glenn> lamont: tried that already, didnt help
[14:12] <glenn> cjwatson: thanks again
[14:12] <cjwatson> and yes, you will need -d unstable
[14:12] <cjwatson> but LP needs to have imported the package first
[14:13] <glenn> k k
[14:13] <lamont> ah.  that makes it make sense.  thanks cjwatson
[14:13] <glenn> how much hardware does a amd64 builder have?
[14:13] <lamont> about 2U
[14:13] <lamont> :)
[14:13] <cjwatson> seb128: possibly --reduce-memory-overheads too
[14:13] <lamont> glenn: they vary
[14:13]  * lamont -> town
[14:13] <glenn> who pays for it? :)
[14:13] <glenn> ubuntu?
[14:14] <cjwatson> Canonical
[14:14] <cjwatson> seb128: webkit building on roseapple now, build farm back on autuo
[14:14] <cjwatson> *auto
[14:15] <glenn> cjwatson: are you at the ubuntu office? or where is ur working spot
[14:15] <cjwatson> glenn: most Ubuntu developers work from home
[14:15] <cjwatson> including me
[14:15] <glenn> cjwatson: but your doing it for free right
[14:15] <cjwatson> No, I'm employed by Canonical
[14:15] <seb128> cjwatson, ok, thanks, I will have a look to --no-keep-memory and --reduce-memory-overheads
[14:16] <seb128> cjwatson, lamont: rt #50818
[14:17] <didrocks> hey, for speeding up the call for testing on compiz, is it possible to get a higher build score on those two builds: https://launchpad.net/~didrocks/+archive/ppa/+build/3201504 and https://launchpad.net/~didrocks/+archive/ppa/+build/3201498 ?
[14:20] <cjwatson> didrocks: done
[14:20] <didrocks> cjwatson: thanks :)
[14:26] <glenn> who would someone want to use a builder from canonical, and not your own pc?
[14:27] <cjwatson> Your own PC can't easily build packages for multiple architectures and publish them on ppa.launchpad.net for people to use conveniently
[14:30] <smoser> I wonder if someone here could give some quick advice.
[14:30] <smoser> bug 321091
[14:31] <smoser> if the user does not have mysql installed (apparently also true with postgresql) and types 'apt-get install bacula-director-mysql', then they'll also get mysql.
[14:31] <smoser> mysql will not be running at the time when bacula's db-config tries to populate mysql.
[14:32] <smoser> it would seem that "Pre-Depends" would satisfy this, but "You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list"
[14:39] <smoser> cjwatson, i'm sure you can provide the right answer, so at your convienence, i'd appreciate it.
[14:59]  * ppisati -> reboot
[15:09] <slangasek> smoser: which maintainer script is db-config being called from?  if it's from the .config script, a pre-depends doesn't help at all
[15:11] <smoser>   dbc_go bacula-director-mysql $@
[15:11] <smoser> is in postinst
[15:11] <slangasek> smoser: *never* use pre-depends for something needed in the postinst - simple depends is always sufficient :)
[15:11] <smoser> wait. but also in .config
[15:12] <slangasek> right, so neither depends or pre-depends helps
[15:13] <smoser> slangasek, given the warning in the debian manual, i wasn't going to just shove it in there without testing..
[15:13] <smoser> so you have an idea on what would be correct there?
[15:13] <smoser> i'm mainly just curios. its been around for quite a while.
[15:13] <cjwatson> config *must* only use Essential packages and debconf
[15:15] <cjwatson> the config script seems to only use db-config if it's available, which is in principle ok
[15:16] <cjwatson> unless it also needs mysql to be available at *that* point; the bug report isn't terribly clear to me
[15:21] <slangasek> cjwatson: db-config-foo could be available at .config time without the database backend itself being available
[15:21] <cjwatson> right, I thought of that part-way through
[15:23] <cjwatson> the only suggestion I have is to check for db presence as well at config time, and make sure the config db_inputs are repeated in the postinst so that if they can't be preconfigured due to lack of database at preconfiguration time then the questions are at least asked when the postinst is run
[15:23] <cjwatson> there is no way to fix this using dependency relationships
[15:29] <smoser> cjwatson, slangasek gracias.
[15:40] <roadmr> kelemengabor: are you here?
[15:40] <kelemengabor> roadmr: yes
[15:40] <kelemengabor> feel free to ask :)
[15:41] <roadmr> kelemengabor: thanks! our package (checkbox) imported a bunch of .po files but they contain some commented, duplicate definitions at the end of the files
[15:41] <roadmr> kelemengabor: these are keeping it from building properly :( a quick fix is to delete all those entries (always at the end of the file)
[15:42] <roadmr> kelemengabor: I wanted to ask if that's OK, or if there's a better way to handle this
[15:42] <roadmr> kelemengabor: it looks like our PO files are wrong as described in LP bug 333281, but that is Fix Released so I'm not sure why we're getting those bad POs
[15:43] <kelemengabor> looking...
[15:43] <roadmr> thanks!
[15:43] <kelemengabor> which branch has this files?
[15:44] <roadmr> kelemengabor: https://code.launchpad.net/~roadmr/ubuntu/precise/checkbox/0.13.1-retry
[15:47] <dholbach> seb128, jamespage: still just the three of us? :)
[15:47] <kelemengabor> in general, the presence of such commented old strings should mean no problem, and LP keeps such in case they are reused sometime in the future. duplicates should not really happen, so this may be a toolchain bug
[15:48] <seb128> @pilot out
[15:48] <seb128> dholbach, no, just the 2 of you :p
[15:48] <roadmr> kelemengabor: so in principle it would be OK to remove them?
[15:48] <seb128> sorry I need to get some desktop stuff done ;-)
[15:48] <dholbach> bah
[15:48] <kelemengabor> roadmr: yes
[15:48] <roadmr> kelemengabor: I notice this doesn't happen with the checkbox trunk, so I'll look at the differences between the branches more closely, but if all else fails I'll delete them with confidence
[15:49] <roadmr> kelemengabor: thanks for your help!
[15:49] <jamespage> dholbach, hrm - yes - I have been a little sidetracked this afternoon as well
[15:49] <jamespage> managed to work through ~8 items this morning tho
[15:49] <dholbach> nice :)
[15:51] <slangasek> cjwatson: jhunt and I have a pty question for you :)
[15:52]  * cjwatson holds up a copy of Stevens as a makeshift shield
[15:53] <jhunt> cjwatson: looking at bug 922754, the question is whether we can
[15:53] <jhunt> rework the while loop in log_read_watch().
[15:54] <jhunt> If we only call this once a process has exited, even though the fd
[15:54] <jhunt> is non-blocking, EAGAIN/EWOULDBLOCK shouldn't occur right?
[15:55] <slangasek> cjwatson: my contention is that, if the process we care about has existed, and you receive EAGAIN on the pty, that's definitive that the fd was leaked and we should ignore it
[15:55] <slangasek> because if there's anything in the kernel buffer, the kernel would return it immediately instead of returning EAGAIN
[15:55] <cjwatson> hm, you may be right
[15:56] <jhunt> and if so, we could use this to display a warning if debug is
[15:56] <jhunt> enabled to state the app is not well-behaved or something.
[15:56] <cjwatson> it's possible that I was simply knee-jerking on read in a while loop -> check for EAGAIN
[15:56] <cjwatson> I think Steve's contention is correct
[15:57] <slangasek> also, s/existed/exited/
[15:58] <jhunt> thanks.
[15:58] <jhunt>
[15:59]  * jhunt goes to watch the unit test firework display...
[16:12] <hallyn> hi all - bug 930181 appears to be another libc fallout (this time due to its headers)?
[16:28] <jhunt> slangasek, cjwatson: looks good so far - and yes, we can produce a
[16:28] <jhunt> warning if a service such as openssh leaks an fd when the associated job
[16:28] <jhunt> is stopped.
[16:36] <slangasek> jhunt: yay :)
[16:44] <didrocks> cjwatson: may I annoy you again for a priority bump on https://launchpad.net/~didrocks/+archive/ppa/+build/3202028 please?
[16:46] <slangasek> hallyn: probably linked to the eglibc update, but header changes like that are rarely accidental or erroneous; are you sure this isn't either a regression in linux-libc-dev (i.e., the kernel side), or simply a bug in qemu-kvm's include usage?
[16:49] <diwic> seb128, ping
[16:50] <seb128> diwic, pong
[16:50] <diwic> diwic, can you clarify that the decision to remove the login sound applied to the session-login sound (long jungle like sound) and not the system-ready sound (drums)?
[16:50] <diwic> seb128 even
[16:51] <seb128> diwic, I confirm that
[16:51] <seb128> diwic, I think the system ready sound was just never implemented in lightdm by lack of time,other priorities
[16:52] <diwic> seb128, thanks. So it seems like most people think we should have a system-ready sound but not a session-login sound
[16:52] <seb128> I would tend to agree with that
[16:52] <seb128> login sound is the annoying one
[16:52] <diwic> seb128, that just leaves the live-CD without sound
[16:52] <cjwatson> didrocks: sure, done
[16:52] <didrocks> cjwatson: thanks again :)
[16:52] <seb128> diwic, which is great ;-)
[16:52] <diwic> seb128, ...unless you're blind
[16:53] <seb128> diwic, well, we could turn on login sound on the liveCD easily
[16:53] <seb128> and for a11y installs
[16:53] <diwic> seb128, that could be something to consider at least
[16:53] <ev> jdstrand: still reading through it, but thank you massively for such a comprehensive review of whoopsie.
[16:54] <jdstrand> ev: you're welcome. I wanted to spend a good chunk of time on it which was hard to come by. sorry for the delay
[16:54] <ev> no worries at all
[16:57] <dholbach> @pilot out
[17:03] <hrw> side effect of updating eglibc - irssi session stopped resolving IPs. restart of irssi solved problem
[17:30] <slangasek> hrw: new upstream versions of eglibc frequently cause nss ABI changes, yes; there's no good way to force a restart of arbitrary user processes that might be affected, but the "you must reboot to finish the upgrade" flag should have been set
[17:32] <doko> slangasek, how is this set?
[17:34] <slangasek> doko: /usr/share/update-notifier/notify-reboot-required - which I see that libc6 doesn't touch, after all
[17:35] <slangasek> doko: so this would be a good thing to add, IMHO
[17:36] <doko> ok, I'll add this for upgrades to 2.15
[17:36]  * micahg also got warned about gdm on upgrade for glibc
[17:36] <micahg> ah, I see why, I have it installed, but it wasn't running
[17:49] <jamespage> @pilot out
[17:56] <slangasek> micahg: warned> blah, yes, that needs improving then
[17:57] <micahg> slangasek: want a bug?
[17:57] <slangasek> micahg: yeah
[17:59] <micahg> slangasek: bug 930304
[18:00] <quadrispro> micahg, here I am, still here
[18:01] <quadrispro> micahg, whay were you saying about old glew transitions?
[18:01] <quadrispro> s/whay/what/
[18:02] <micahg> quadrispro: we never finished the glew 1.6 transition and as such currently have glew1.5 and glew (1.6) in precise
[18:02] <quadrispro> yes, I understand
[18:03] <quadrispro> micahg, so you mean it had better to defer this to precise+1?
[18:07] <quadrispro> micahg, did you read my message?
[18:08] <micahg> quadrispro: well, not necessarily, but I'd just suggest taking whichever one is more stable, also as seb128 mentioned unity is prone to issues with glew migrations
[18:09] <micahg> and just keep in mind, there's more than just the glew rdepends
[18:11] <quadrispro> ok, let's wait for feedback/suggestions from ubuntu-release
[18:18] <seb128> cjwatson, still around?
[18:20] <micahg> seb128: as I mentioned in -desktop, webkit is still broke on i386 (failed due to symbols changing) which means dist-upgrades on amd64 are broke still
[18:20] <seb128> micahg, right, I'm doing another update and that's why I just pinged cjwatson
[18:20] <seb128> I will need the i386 build to go to the right builder
[18:20] <micahg> ah, ok, cool, thanks
[18:20] <seb128> since some builders run out of ram calling ld
[18:21] <seb128> he did it for me earlier but the build failed on a stupid .symbols cpp difference between archs
[18:21] <seb128> - _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERmS6_@Base 1.7.4
[18:21] <seb128> + _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERjS6_@Base 1.7.5-0ubuntu1
[18:21] <seb128> stupid cpp mangling :-(
[18:21] <micahg> ah, that's a per arch difference that existed already?
[18:22] <seb128> well I reverted a (regex) use by error but there is a new symbol added which had the same issue
[18:22] <seb128> I'm pondering just using -c1 instead of -c4 to be safe there, I don't want to fail another build
[18:22] <seb128> will do that
[18:23] <micahg> just don't forget to revert it for the next upstream release
[18:23] <cjwatson> seb128: have you uploaded it yet?
[18:23] <cjwatson> (dinnertime here, be quick :-) )
[18:23] <seb128> cjwatson, no, I wanted to talk to you
[18:24] <seb128> I've it ready, but I guess if I upload it will be too late to do your magic
[18:24] <cjwatson> I can switch to manual first
[18:24] <cjwatson> did you try the ld options I suggested?
[18:24] <seb128> cjwatson, not yet, webkit builds take over 6 hours on my box
[18:24] <cjwatson> ok
[18:25] <cjwatson> seb128: upload away and tell me when you've done so
[18:25] <seb128> but the build on the buildd would have worked
[18:25] <seb128> ok, on my way
[18:27] <seb128> cjwatson, uploaded
[18:31] <cjwatson> seb128: ok, it should build when the current build on roseapple completes
[18:31] <cjwatson> I have to go for dinner now, might be half an hour or so until I have time to re-auto the other buildds
[18:32] <glenn> enjoy ur dinner :)
[18:32] <glenn> im off too weekend
[18:32] <glenn> ciao
[18:33] <seb128> cjwatson, thanks a lot
[18:34] <seb128> micahg, <micahg> just don't forget to revert it for the next upstream release
[18:34] <hallyn> interesting - if i switch desktops at just the right time while 'debuild -S' is going, and gpg-agent is running, the pop-up asking my pwd apparently dies (without my seeing it) and debuild stops with bad passphrase
[18:35] <seb128> micahg, I did revert and update the .symbols in the vcs, I just don't want to risk getting it wrong again today
[18:35] <seb128> micahg, or we will keep the issue over the w.e
[18:35] <micahg> seb128: sounds good, thanks :)
[18:35] <seb128> yw
[18:37] <bdmurray> Where / how do I submit a change to lptools?
[18:37] <seb128> bdmurray, google says https://launchpad.net/lptools
[18:37] <seb128> bdmurray, ?
[18:38] <seb128> bdmurray, https://code.launchpad.net/~lptools/lptools/trunk
[18:38] <seb128> bdmurray, same way that for any other launchpad vcs I guess?
[18:38] <bdmurray> hmm debcheckout used something different
[18:41] <bkerensa> slangasek: Do you know much about what was causing the "Waiting 60 more seconds for network configuration" bug?
[18:41] <bdmurray> bkerensa: its a one time thing on first boot and is being looked at
[18:42] <slangasek> that one should already be fixed in the dailies
[18:42] <bkerensa> bdmurray: Hmm ok well it is hitting me everytime I boot in so not one time for me
[18:42] <bkerensa> :D
[18:42]  * slangasek sighs at bug #508083 having been marked "triaged", yet left assigned to the wrong package
[18:54] <bdmurray> slangasek: which term log did you look at?
[18:55] <slangasek> bdmurray: the one from jibel's autoupgrade test
[18:56] <slangasek> bdmurray: can you think of a good way to suppress reports of that particular crash if it happens in the middle of a release upgrade?  Or should we just make sure cron is stopped before unpacking libc6?
[18:56] <bdmurray> I'd think apport would report this as an apport-crash bug about cron so term.log wouldn't be available
[18:57]  * slangasek nods
[18:58] <slangasek> cjwatson: upgrade issue with libnih1 and libc6... libnih1 doesn't pre-depend on libc6, so the new libnih1 can be unpacked before the libc6 providing the symbols it requires... which will handily render init broken.  Should libnih1 pre-depend?
[19:04] <bdmurray> slangasek: looking at the crash file there might be some information that gives it away as happening during an upgrade.  DistroRelease is 12.04 but the kernel is 3.0.0
[19:24]  * lamont wonders what is STOMPING on resolv.conf with <IP_ADDRESS> for the nameserver
[19:25] <micahg> resolvconf?
[19:26] <lamont> possibly
[19:26] <lamont> bind9's RESOLVCONF=no
[19:28] <jdstrand> lamont: that would presumably be network manager's personal dnsmasq: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
[19:31] <cjwatson> slangasek: I think so, this is basically a case of (transitively-)Essential packages needing to promote Depends to Pre-Depends
[19:31] <cjwatson> which is something I've agreed with Santiago in the past as being necessary
[19:32] <slangasek> bdmurray: I don't think I'd like us to have to use kernel version and release version as a proxy for this, because that means we'd have to maintain that list in release-1 versions of apport
[19:32] <slangasek> cjwatson: ok - think I should go ahead with that change then?
[19:33] <lamont> jdstrand: bind9 has port 53 on the box.  it also doesn't want to be the resolver
[19:33] <bdmurray> slangasek: oh I'd thought of using a bug pattern but yes it'd need to be updated per release
[19:33] <cjwatson> slangasek: yeah
[19:34] <slangasek> bdmurray: bug pattern only blocks once they try to submit, yes?  Since this is "not actually a bug", I'd rather that users never got prompted
[19:35] <cjwatson> stopping cron during release upgrades sounds sensible ...
[19:35] <bdmurray> slangasek: that is correct
[19:35] <slangasek> bdmurray, cjwatson: right, I think stopping cron before unpack is probably the better way to go
[19:35] <cjwatson> (during the whole thing?  cron jobs might well be using arbitrary stuff that will be unconfigured for sizeable amounts of the duration)
[19:35] <jdstrand> lamont: aiui if you still have this in /etc/NetworkManager/NetworkManager.conf 'dns=dnsmasq', then resolvconf is in effect for dnsmasq via nm. you might want to comment out that option if you still have it
[19:36] <jdstrand> not sure if you need to restart nm, presumably so
[19:36] <lamont> jdstrand: ah ha!
[19:36] <lamont> so what do I want to set it to?
[19:37] <lamont> just comment, got it
[19:37] <slangasek> cjwatson: oh, technically, we've managed to make it so that runlevel is not part of transitive essential on Ubuntu, so hmm
[19:37] <jdstrand> lamont: comment it out: #dns=dnsmasq
[19:37] <lamont> and # for comments.  that answers the other
[19:37] <slangasek> can still do the pre-depends, but
[19:37] <slangasek> I think apt would be happier if something essential pre-depended on upstart
[19:37] <slangasek> (such as in the current debian-devel discussion)
[19:38] <slangasek> might need to have the pre-depends on a transitional basis for upgrades regardless
[19:38] <lamont> jdstrand: lrwxrwxrwx 1 root root 9 Feb 10 12:38 /usr/sbin/dnsmasq -> /bin/true
[19:38] <jdstrand> lamont: if not rebooting you might need to kill off the dnsmasq and maybe other stuff
[19:38] <lamont> nah, I fixed dnsmasq a while ago
[19:38] <jdstrand> heheh
[19:39] <cjwatson> slangasek: it's true that upstart isn't Essential, but I think that's kind of artificial
[19:40] <slangasek> lamont: so there's a bug in that NM, if it fails to launch dnsmasq on port 53 for whatever reason, should not then call resolvcon
[19:40] <slangasek> f
[19:40] <cjwatson> it caused too many problems when we tried; but the point of using Pre-Depends is to enable the "works even when unconfigured" property of Essential packages, and I think that upstart should behave as if it were Essential
[19:40] <lamont> slangasek: that saves me filing it
[19:40] <slangasek> lamont: I didn't say there was a bug report, I don't know if there is ;)
[19:41] <lamont> bah
[19:41] <lamont> I shall check
[19:41] <slangasek> lamont: I'm simply declaring that this is a bug, a conclusion that you seem to have already reached :-)
[19:41] <slangasek> cjwatson: well, I believe that if something Essential had a pre-depends on upstart, apt's rules about immediate configuration would have made libnih1's dependency a non-issue
[19:41] <slangasek> AIUI
[19:41] <lamont> I also need to reboot for the lastest stuff, and see if unity 3d is still unusable for me
[19:41] <cjwatson> I think it may only propagate that down one level
[19:42] <cjwatson> and it doesn't seem like something we should rely on for individual package correctness anyway
[19:44] <cjwatson> Incidentally, does unpacking the new libc break the old libnih?
[19:44] <slangasek> cjwatson: but, er, consider that libc6's preinst is trying to invoke the runlevel command
[19:44] <slangasek> which is not essential
[19:44] <slangasek> and not in a pre-dep of libc6
[19:44] <cjwatson> oh argh, I see
[19:44] <slangasek> so "correct"ness may vary
[19:45] <cjwatson> well, that means that runlevel must act as if it is essential, regardless of anything else
[19:45] <cjwatson> so any libraries it depends on have to use Pre-Depends, strictly
[19:45] <zanfur> sorry to intrude, just asking for directions -- where do I go for guidance in ubuntu packaging?
[19:46] <slangasek> heh, yes, unpacking the new libc does break libnih as well
[19:46] <slangasek> stupid GLIBC_PRIVATE
[19:46] <slangasek> but probably breaks it less than the converse
[19:48] <doko> hmm, I checked that the type of the used private symbol didn't change
[19:55] <slangasek> doko: probably not between oneiric and precise... what about from lucid to precise?
[19:56] <slangasek> well, it probably doesn't matter
[19:56] <slangasek> the symbol is only used when libnih aborts ;)
[19:56] <slangasek> so yes, unpacking libc6 first should be safe
[19:56] <lamont> I suppose I'll see if I can get dnsmasq and bind9 to coexist nicely on my machine
[19:57] <slangasek> lamont: does it matter? :)
[19:58] <slangasek> lamont: you have bind9 on <IP_ADDRESS>, and you don't want it to be used as your resolver.  To actually care about dnsmasq being used makes you a corner case on a 6-dimensional hypercube
[20:15] <keyzs> unity is crap
[20:16] <keyzs> all lefty
[20:16] <keyzs> and for tv
[20:16] <keyzs> now i dont love ubuntu
[20:17] <keyzs> focus on user
[20:17] <keyzs> not on code gurus
[21:49] <tomreyn> hi, i'm looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule and am trying to understand when the freeze is for debian imported packages to go into the "precise" stable release. since this table lists various sates for various freezes for various releases i'm having a hard time coming up with a definitive answer.
[21:49] <tomreyn> can one of you help me out?
[21:50] <broder> tomreyn: there are a couple stages of how we handle imports. we've already stopped automatically importing packages from debian testing (that's DebianImportFreeze), so any subsequent imports have to be manually requested - but still can be
[21:51] <broder> next week we hit FeatureFreeze, at which point imports either have to only fix bugs (not introduce features) or be approved by the release team
[21:52] <tomreyn> broder: i see "LTS DebianimportFreeze", is precise an LTS?
[21:52] <broder> yes
[21:52] <tomreyn> okay i wasn't aware
[21:53] <broder> we do LTS releases every 2 years in the spring (6.06, 8.04, 10.04, and now 12.04)
[21:54] <tomreyn> oh right
[21:54] <tomreyn> i remember there was some discussion that some release should have been LTS but wasn't in the end, but i forgot the details
[21:56] <tomreyn> broder: so when's the point where even requests for bugfix only updates (debian imports) will be denied?
[21:57] <tomreyn> is this UnseededUniverseFinalFreeze?
[21:57] <broder> depends on the package. for packages included on any of our CDs, we stop taking any updates at FinalFreeze except for critical bugs
[21:57] <broder> for packages in universe that aren't on CDs, yeah, UnseededUniverseFinalFreeze
[22:03] <tomreyn> thanks for your help
[22:07] <tomreyn> broder: actually i have another question related to this: so we released megaglest <IP_ADDRESS> (a bugfix) a few days ago, it's not in debian testing yet (but in sid, and should migrate to testing in 4 days). how do we request for it to be pulled into ubuntu for 12.04?
[22:07] <broder> tomreyn: use the requestsync script in ubuntu-dev-tools (available in both debian and ubuntu)
[22:08] <tomreyn> okay, are there limitations as to who can use it?
[22:08] <tomreyn> well i'll rtfm
[22:08] <broder> you just need a launchpad account
[22:08] <tomreyn> cool
[22:29] <bkerensa> slangasek: Do you know what "Source branch format does not support stacking, using format:
[22:29] <bkerensa>   Branch format 7
[22:29] <bkerensa> " means?
[22:32] <broder> can i get an ~ubuntu-branches member to change the status of https://code.launchpad.net/~jtaylor/ubuntu/oneiric/subversion/sasl-crash-881862/+merge/85228 to merged?
[22:37] <slangasek> bkerensa: the branch your branch is based from needs to have 'bzr upgrade' run
[22:38] <bkerensa> slangasek: I'm assuming whomever maintains that package would be the one to do that?
[22:39] <slangasek> bkerensa: what branch are you getting that error on?
[22:39] <bkerensa> slangasek: ubuntu-wallpapers
[22:39] <slangasek> bkerensa: what *branch*, not what package :)
[22:40] <slangasek> http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu ?
[22:40] <bkerensa> slangasek: https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-wallpapers/precise
[22:40] <slangasek> ok, let's have a look-see
[22:41] <bkerensa> I was proposing a merge to fix a bug
[22:41] <bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+register-merge
[22:41] <slangasek> hmm
[22:41] <slangasek> Standalone tree (format: 2a)
[22:42] <slangasek> the target branch seems to have the right format
[22:42] <bkerensa> yeah it was saying something about that when I merged
[22:42] <slangasek> but maybe that's not the default stacking branch listed for the package
[22:43] <bkerensa> hmm
[22:45] <slangasek> yes, the associated upstream branch (lp:ubuntu-wallpapers) is an old format
[22:45] <bkerensa> ahh
[22:47] <slangasek> and I'm pretty sure that's a dead branch / team; I'll see about getting someone to upgrade the branch
[22:48] <bkerensa> ok
[22:55] <slangasek> bkerensa: were you able to successfully register the merge request, or did this issue block you?
[22:56] <bkerensa> slangasek: My merge request is registered
[22:57] <slangasek> ok
[22:57] <bkerensa> I will big dholbach to review it tonight
[22:57] <bkerensa> :D
[22:57] <slangasek> then you can safely ignore the message ;)
[22:57] <bkerensa> bug*
[23:04] <bdmurray> slangasek: do you have an opinion about blocking package install failures from persistent live media?
[23:23] <slangasek> bdmurray: I don't think so - how about if I adopt your opinion, whatever it is? :)
[23:35] <bryceh> bdmurray, sounds like a good idea to me
[23:36] <bdmurray> bryceh: right you worked on some weird issues in previous releases right?
[23:36] <bdmurray> I just can't decide if we are just hiding other issues though
[23:39] <bryceh> bdmurray, yeah related to nvidia driver installation failures
[23:41] <bryceh> that class of issue tended to hit things that required updating the boot loader when installing them
[23:41] <bryceh> I've not seen any similar issues lately the past two releases, so would guess the root problem got solved, but I don't actually know.
[23:42] <bdmurray> I believe that was fixed in casper
[23:42] <bryceh> bdmurray, do you see a lot of reports about persistent live media package install failures?
[23:43] <bdmurray> bryceh: that would be a good thing to know but its hard to find out
[23:45] <bdmurray> bryceh: you might need to check the dmesg attachment, I'm not certain the description has enough information


[21:38] <damjan> !ping damjan
[21:48] <damjan> !ping damjan
[21:48] <erlbot--> damjan is lagging 2 bannanas


[09:47] <redguy> so for posterity - in Debian jessie (systemd 215) when you restart journald as a part of cloud init it makes the cloud-init (and possibly other systemd units) fail when they want to write something into stdout/stderr. Debian stretch (systemd 232) is not affected.
[16:01] <ajorg> meeting today?
[16:03] <blackboxsw> ajorg: morning. just in time
[16:03] <blackboxsw> was just determining who would kick it off
[16:03] <blackboxsw> <--- winner
[16:03] <ajorg> morning
[16:03] <blackboxsw> #startmeeting Cloud-inin bi-weekly status meeting
[16:03] <meetingology> Meeting started Mon Jan  8 16:03:53 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:03] <meetingology> Available commands: action commands idea info link nick
[16:04] <blackboxsw> Happy  2018 cloud-initers!   Thanks ajorg for helping kick us off.
[16:04] <blackboxsw> Welcome back from break hope the holidays were good for folks.
[16:04] <blackboxsw> It
[16:05] <blackboxsw> It's been a while since we've held the meeting due to holidays and vacation time. So, not a ton of content to report for the last bit. Digging up those details now
[16:06] <blackboxsw> Testing of 17.2 on EC2, Azure, and GCE and release to Ubuntu Bionic
[16:06] <blackboxsw> Complete 17.1.46 SRU to Ubuntu Xenial, Zesty, and Artful
[16:06] <blackboxsw> Fix documentation around 'init' mode for modules subcommand (LP: #1736600)
[16:06] <blackboxsw> Tooling to merge community authored branches into master
[16:07] <blackboxsw> So the canonical side of the team worked a bit on getting the latest SRU updates 17.1.46 into Xenial, Zesty and artful. The testing and verification of that release took a bit of time, but we are getting better(faster)
[16:07] <blackboxsw> I think this last SRU only took us 2 weeks instead of 4 weeks. so that frees up more time on upstream reviews and increasing cloud-init's velocity
[16:07] <ajorg> great
[16:08] <blackboxsw> we also added team tools for streamlining community authored branches. so that we stop slowing folks down :/
[16:08] <blackboxsw> then the only problem is the reviewer :)
[16:09] <blackboxsw> #topic Recent changes
[16:09] <blackboxsw> ^ should have been that topic.
[16:10] <blackboxsw> Also 17.2 release was 'cut' prior to Christmas break, this opened master up for more changes to land. so we've pulled in good  fixes for VMWare NoCloud and SLES
[16:11] <blackboxsw> digging up the changests now.
[16:11] <blackboxsw> Also, keep in touch with our active development and the "done" lane on trello. It's out bookkeeper for anything we are working and Done represents anything landed
[16:11] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[16:13] <blackboxsw> so high-level content that landed between 17.1.46 and 17.2:
[16:14] <blackboxsw> * CLI added the clean and status subcommands
[16:14] <blackboxsw> * Support for identifying OVF datasource provided by VMware
[16:14] <blackboxsw> * NoCloudKVM tests now run in continuous integration
[16:14] <blackboxsw> * Formalize DataSource get_data and related properties
[16:14] <blackboxsw> * Remove prettytable dependency and introduce simpletable
[16:14] <blackboxsw> * VMWare pre and post-customization script support
[16:15] <blackboxsw> Thanks ajorg I think you were the author of note on simpletable stuff, it's nice to drop dependencies where we can to increase speed of cloud-init
[16:15] <ajorg> it was done selfishly
[16:15] <ajorg> we dislike taking on new dependencies :-)
[16:17] <blackboxsw> and thanks to robjo(suse)  maitree(vmware) too and dojordan and Ryan McCabe(redhat) for recent branches too
[16:17] <blackboxsw> :)
[16:18] <blackboxsw> Post our 17.2 release we've started work on improved integration..... I think we just got powersj's ec2 integration tests landed right johs?
[16:18] <blackboxsw> josh even
[16:18] <powersj> \o/ yep!
[16:18] <ajorg> nice
[16:19] <blackboxsw> sweet, so an extra security blanked for us when we have significant changesets landed in master to ensure ec2 is happy.
[16:19] <blackboxsw> powersj: what are out plans for continuous integration frequency
[16:19] <blackboxsw> with ec2 specifically
[16:19] <ajorg> Can those integration tests be run by others with EC2 accounts?
[16:19] <blackboxsw> ajorg: yes they can
[16:19] <powersj> I am working on the jenkins jobs this week and hope to have a weekly run as well as a manual run for backport testing
[16:19] <blackboxsw> I'll get the cmdline
[16:19] <ajorg> thanks!
[16:20] <blackboxsw>  tox -e citests -m tests.cloud_tests run --os-name=artful --platform=ec2 --preserve-data --data-dir=../results --verbose
[16:20] <blackboxsw> or something like that
[16:20] <ajorg> got it
[16:20] <ajorg> thanks!
[16:20] <blackboxsw> powersj: documented it too I think
[16:20] <blackboxsw> getting link
[16:20] <powersj> https://cloudinit.readthedocs.io/en/latest/topics/tests.html#ec2
[16:20] <blackboxsw> #link https://cloudinit.readthedocs.io/en/latest/topics/tests.html#ec2
[16:20] <blackboxsw> :)
[16:21] <blackboxsw> excellent work  Josh
[16:21] <powersj> thanks for all the reviews :)
[16:21] <blackboxsw> anything else I'm missing about landed work?    rharper powersj smoser1 ?
[16:22] <blackboxsw> otherwise next topic
[16:22] <rharper> blackboxsw: nothing from me
[16:22] <blackboxsw> #topic In-progress Development
[16:23] <blackboxsw> So we've got a fairly healthy review queue that we need to get through as we get the year started....
[16:24] <blackboxsw> we also have a few things we are in flight currently:
[16:24] <blackboxsw> - continuous integration improvements per powersj
[16:24] <blackboxsw> - dropping dependence on ifup ifdown utils where possible as that's not supported (or installed in some cases) in systemd world
[16:24] <smoser1> blackboxsw: wow. sorry, missing.
[16:25] <blackboxsw> who is that smoser1 guy anyway
[16:25] <smoser1> yeah, i didnt see anything missing sorry.
[16:25] <smoser> wonder how that happened.
[16:25] <blackboxsw> welcome ;)
[16:25] <blackboxsw> - netplan improvements per rharper and jinja template support for all cloud-config modules
[16:26] <blackboxsw> - and softlayer support per smoser
[16:27] <blackboxsw>  know the Azure guys are also posting a couple branches on getting a pre-provisioning setup going for thier datasource which looks pretty exciting
[16:27] <blackboxsw> I can't think of anything else off the top of my head.
[16:28] <robjo> chrony support
[16:28] <ajorg> we're only talking feature work in this topic?
[16:29] <blackboxsw> any in progress development to highlight is fair game. bug work. refactoring, feature etc
[16:29] <blackboxsw> +10 robjo and again thanks for working with us getting all those branches up and (hopefully soon) landed
[16:29] <ajorg> what does "jinja template support for all cloud-config modules" mean?
[16:31] <ajorg> I'd guess most modules don't need templating?
[16:31] <blackboxsw> ajorg: two things. 1. since we have now landed /run/cloud-instance/instance-data.json    to store metadata/userdata it'd be that #cloud-config can  new be specified with ## template:jinja header and could leverage anything jinjia has to offer plus sourcing any of the instance-data.json metadata fields
[16:33] <ajorg> Ah, right. Is that not being done above the module level?
[16:33] <blackboxsw> so if people have repetitive or template-driven content in the runcmd   or write_files portion or their #cloud-config  they'd be able to leverage jinja templates etc
[16:33] <smoser> ajorg: yes, above the module level.
[16:33] <blackboxsw> ajorg: not anywhere in cloud-config currently
[16:33] <blackboxsw> one sec I misunderstood the question
[16:33] <blackboxsw> smoser: can you clarify what you mean?
[16:33] <ajorg> I mean, shouldn't #cloud-config template expansion happen before the module sees the config?
[16:34] <smoser> blackboxsw: we could/should also allow other part types to be rendered
[16:34] <smoser> ttps://trello.com/c/xyqxyOxg
[16:35] <smoser> er... bad url. in 2 ways
[16:35] <ajorg> The the part handler would be the one to do that expansion.
[16:35] <smoser> https://trello.com/c/AYaCdQyT
[16:35] <blackboxsw> ahh ok, right that makes sense. I think the cut I made was limited in focus to cloud-config modules and custom scripts supporting the ## template:jinja header.. but nothing would preclude handling other parts
[16:36] <blackboxsw> so the link to my WIP branch was
[16:36] <blackboxsw> #link https://trello.com/c/xyqxyOxg
[16:36] <blackboxsw> and the general feature per smoser
[16:36] <blackboxsw> #link https://trello.com/c/AYaCdQyT/21-cloud-init-query-standardized-json-information
[16:36] <ajorg> Is there a design doc of some kind of this?
[16:37] <blackboxsw> not yet.. but we probably should have a spec as it'd be a good template for the docs we'll need to write
[16:38] <blackboxsw> scott captured most of the use cases we'd be going for in that last trello link above
[16:38] <ajorg> Small example of where some clarity is needed: if Jinja is interpreting {foo} in a user-script, what will it do when it sees a shell variable ${foo}
[16:38] <ajorg> ?
[16:39] <smoser> you declare that the content is a jinja template
[16:39] <smoser> if you provide it something that is not renderable as a jinja template
[16:39] <smoser> then it will fail
[16:39] <smoser> it requires input to explicitly say "this is jinja". it does not just attempt to render anything.
[16:39] <smoser> (unless explicitly told to)
[16:39] <blackboxsw> some brief working examples are in the description of the branch @ https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/334030
[16:40] <ajorg> Sure. But as a content author, I need to know if Jinja is going to try to render ${foo} or not.
[16:40] <smoser> then as a content author you can read jinja docs :)
[16:40] <blackboxsw> jinja would try to render {{ foo }}
[16:40] <ajorg> :-
[16:41] <smoser> ajorg: we'll document a simple case, and we can even document "for shell, you'll have to be aware that ...."
[16:41] <smoser> but we're not going to document all of jinja
[16:41] <ajorg> I see.
[16:42] <ajorg> My understanding was that Jinja was highly customizable in what it interpreted and how, so that it's important to document how you've configured it to work.
[16:42] <blackboxsw> and since to burden is on the #cloud-config or script writer to provide the header        ## template: jinja\n#cloud-config\n         they *should* understand what they are doing
[16:42] <blackboxsw> we won't implicitly run the #cloud-config through jinja
[16:43] <ajorg> I get that, no problem, what I'm saying is that Jinja is an engine that you configure to do something, not a markup that always does the same thing for everyone.
[16:43] <ajorg> Am I making any sense?
[16:44] <blackboxsw> understood (though I thought it was fairly constrained it it's application and functionality). We'll make sure that the mechanism by which jinja operates is well documented and confined as best we can... for our own sanity we don't want that template engine to be too flexible... too many tough support use cases
[16:45] <blackboxsw> ok anything else for "In progress development"  otherwise we can move to Office hours for 30 mins
[16:46] <blackboxsw> #topic Office Hours (next 30 minutes)
[16:47] <blackboxsw> robjo: you've got quite a few branches of goodness up for us to review. Any prioritization on those branches or just take them as we can?
[16:47] <rharper> I don't think  there are issues w.r.t jinja and shell; they use different variable escape methods, jinja uses {{ variable/expression }}; and it doesn't consume $  AFAIK, ajorg do you know differently ?
[16:48] <blackboxsw> #link https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/334992
[16:48] <blackboxsw> I'm guessing is top of the list
[16:48] <ajorg> I saw {instance_id} at https://trello.com/c/AYaCdQyT/21-cloud-init-query-standardized-json-information so I assumed it was being customized to look for { instead of {{
[16:48] <robjo> blackboxsw: The chrony support should probably be the last as it will take longer over all and more back and forth
[16:48] <ajorg> (for one thing)
[16:49] <ajorg> rharper: also, there's the whole question of the "extends" feature
[16:50] <ajorg> We integrated Jinja into an internal tool a few years back and we spent a very long time making sure the loaders did the right thing.
[16:50] <blackboxsw> ajorg: I thought I read somewhere that you couldn't exend jinja for custom functions. maybe I was mistaken
[16:50] <robjo> I am also not certain that the "re-write everything" on the first go around for chrony is really what we want to do initially
[16:50] <ajorg> blackboxsw: I don't think I'm referring to custom functions
[16:51] <robjo> That's probably where we ant to end up, but I am not certain that a "step function" approach is in order
[16:51] <rharper> ajorg: hrm, I've always seen {{ variable }} or {% expression %};  so maybe blackboxsw can just update the templates;
[16:51] <rharper> the examples in the cards
[16:52] <ajorg> rharper: sure, that would have helped in this case.
[16:52] <robjo> If we do go down the route of the step function I'll need more gudance then in rharper's comments
[16:52] <ajorg> blackboxsw: I was referring to the ability of one template to extend another.
[16:53] <ajorg> blackboxsw: and the question of where does the engine look when it's asked to extend another template. It can be tricky.
[16:54] <blackboxsw> yeah I honestly hadn't gotten past step one of handling the template markup within an existing single template. so this may need a bit of thought/work
[16:55] <ajorg> Personally, I'd be a lot happier with limiting things to Python format() templates, even though it means you can't have loops, but I won't get in the way as long as we're cognizant of the problems we can run into by accepting the full power of an advanced engine like Jinja.
[16:56] <smoser> i'm not opposed to allowing ## template: python-format
[16:56] <ajorg> heh
[16:56] <smoser> honestly.
[16:56] <smoser> you can pick  a differnt name if you dont like that one.
[16:57] <smoser> but we already use jinja, so it makes sense to support jinja
[16:57]  * smoser has to run. sorry.
[16:57] <rharper> I do feel that supplying the template means the user is opting in;  and specifically if we've got a good way to provide dry-run based on a instance.json and a script; that certainly can help folks work out the kinks in the template of their choosing
[16:57] <ajorg> I'm really not opposed so much as wary of the extensive power of the thing
[16:58] <rharper> ajorg: that's a fair warning; given you've experience here; help drawing the line is most welcome
[16:58] <ajorg> I'm trying to think of a way to read in /etc/shadow using Jinja, you know?
[16:58] <rharper> well, cloud-init is root anyhow; so, what's the deal with that ?
[16:59] <blackboxsw> ajorg: heh, right though you can read that with your runcmd section in #cloud-config :)
[16:59] <ajorg> If I can come up with a way to do it that doesn't make it look obvious that I'm doing it, and then post that as something others can copy, or use with #include <url> then I win.
[16:59] <rharper> I don't think jinja makes that any more troublesome
[17:00] <rharper> folks already wget | bash with shell they don't understand either
[17:00] <ajorg> I suspect Jijna makes it more opaque.
[17:01] <ajorg> The answer to "what file does Jinja read when I use {% extends foo %}" is a very lengthy "it depends"
[17:02] <ajorg> anyway, I've said my piece
[17:03]  * ajorg is a bit of a template naysayer.
[17:05] <blackboxsw> +1, there's one in every group. We'll try to keep that in mind as this feature evolves
[17:05] <blackboxsw> :)
[17:06] <ajorg> nice
[17:06] <ajorg> :-)
[17:06] <blackboxsw> any pet bugs, new features or burning reviews that need mention?
[17:07] <blackboxsw> ajorg: we could do something simple like disable the extends option via policies
[17:07] <blackboxsw> it looks like
[17:08] <blackboxsw> #link http://jinja.pocoo.org/docs/2.10/api/#policies
[17:08] <blackboxsw> or maybe I'm misunderstanding the issue   I'll read up more on it
[17:08] <ajorg> thanks
[17:09] <ajorg> It looked like https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/334074 was blocking https://code.launchpad.net/~yeazelm/cloud-init/+git/cloud-init/+merge/331897 but shouldn't be anymore.
[17:09] <ajorg> I'll remind Matt to try it again now.
[17:13] <blackboxsw> thanks good dela
[17:13] <blackboxsw> dela
[17:13] <blackboxsw> deal
[17:13] <blackboxsw> geez
[17:14] <blackboxsw> on that note. I think it's time for coffee
[17:14] <blackboxsw> and time to end the meeting
[17:14] <blackboxsw> Happy New Year again folks. Good to be back in the office.
[17:15] <blackboxsw> thanks again for the chat, until next time..
[17:15] <blackboxsw> #endmeeting
[17:15] <meetingology> Meeting ended Mon Jan  8 17:15:30 2018 UTC.
[17:15] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-01-08-16.03.moin.txt
[17:15] <ajorg> bye now
[17:15] <blackboxsw> see you ajorg and robjo  have a good one
[17:16] <ajorg> oh, actually before I leave, but not necessarily before you leave, what conferences are folks attending this year?
[17:16] <blackboxsw> powersj: mind promoting me to opp again?
[17:16] <blackboxsw> or rharper
[17:16] <blackboxsw> thx rharper
[17:16] <rharper> np
[17:17] <blackboxsw> I hadn't chosen yet.  I was think about LISA or debconf.
[17:18] <blackboxsw> cloud foundry looks interesting too.
[17:22] <blackboxsw> actually, no it doesn't, to me.
[18:00] <ajorg> I went to LISA when it was in Seattle. I'd probably go again if it was in Seattle again.
[18:15] <powersj> blackboxsw: debconf is in taiwan this year
[18:16] <dpb1> chad and I went in San Diego, it was a good conference, IMO
[18:16] <powersj> blackboxsw: smoser: some fun for you https://paste.ubuntu.com/26348213/
[18:16] <blackboxsw> powersj: guess that narrows down that choice
[18:19] <blackboxsw> anyone heard much about http://devopssummit.sys-con.com/general/papers2018east.htm ?
[18:19] <blackboxsw> cloud/devops expo
[18:19] <blackboxsw> ?
[18:19] <blackboxsw> I think marco ceppi went
[18:20] <blackboxsw> not sure if it's the 'right' venue
[18:34] <smoser> powersj: i really should upload simplestreams to pypi
[18:34] <smoser> and do a release of that.
[18:34] <powersj> smoser: yes you should
[18:55] <smoser> powersj: responded to all of them.
[18:56] <powersj> smoser: thanks!
[18:56] <powersj> after lunch I'll go through 'em
[19:01] <smoser> rharper: or blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/335108 review woudl be appreciated
[19:11] <blackboxsw> will do. just posted archive of meeting notes https://cloud-init.github.io/status-2018-01-08.html#status-2018-01-08
[20:55] <dojordan> @blackboxsw @smoser can you guys take a look at the new changes I made? https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341
[21:04] <blackboxsw> smoser: quick discussion point on your maas oauth branch
[21:04] <blackboxsw> looking dojordan
[21:38] <smoser> blackboxsw: k
[21:48] <smoser> blackboxsw: ?
[21:48] <blackboxsw> sorry, I missed something?
[21:48] <blackboxsw> was working on review comments ATM
[21:48] <smoser> "smoser: quick discussion point on your maas oauth branch"
[21:49] <smoser> i expected follow up on that
[21:49] <blackboxsw> ohh posted on your branch mso
[21:49] <blackboxsw> smoser:
[21:49] <blackboxsw> just wondered about pulling the required oauth token logic down into OauthUrlHelper
[21:49] <blackboxsw> so that other callers (as they grow) could benefit from same behavior... warning and proceed w/out oauth
[22:11] <smoser> blackboxsw: yeah, i kind of saw that duplicated also... i think that sounds reeasonable.


[15:38] <dsmythies> There is supposed to be a doc team meeting over in #ubuntu-meeting-2 in 20 minutes. However the room is double booked, so we will have the meeting here instead.
[16:00] <dsmythies>   #startmeeting Ubuntu Docs
[16:01] <dsmythies>   #chair dsmythies GunnarHj
[16:01] <GunnarHj> Hi there!
[16:01] <dsmythies> Hi Gunnar, the meeting stuff doesn't seem to be working, but I see the bots.
[16:02] <dsmythies> we never updated the agenda.
[16:03] <GunnarHj> Ok. ( Personally I'm not too sad about the missing bot stuff. ;) )
[16:03] <dsmythies> Does anybody have anything they want to bring up for this doc team meeting.
[16:04] <pmatulis> we should probably clear out old items from the agenda
[16:04] <GunnarHj> Maybe we should as who are here for the meeting?
[16:04] <GunnarHj> as -> ask
[16:05] <dsmythies> I wanted to bring up the recurring "Continued maintenance of the UbuntuHashes wiki page" item.
[16:05] <dsmythies> Who is here for the meeting? Doug, Gunnar, Peter. Who else?
[16:07] <dsmythies> Also, we have a conflict with #ubuntu-meeting-2. There is anothe meeting there on an every two weeks timeline, which sometimes conflicts with our 1st Tuesday of the month timeline.
[16:08] <pmatulis> i am much more free than i was in the past
[16:08] <pmatulis> i would be good with any time other than wed 9-11 EST
[16:09] <GunnarHj> I'm flexible too wrt the meeting time.
[16:09] <dsmythies> Peter: Would moving the meeting back to 17:00 UTC work for you? (Still Tuesday).
[16:10] <GunnarHj> dsmythies: Will the conflicting meeting end within an hour?
[16:10] <dsmythies> I think it has been, the last two times. I'll watch today.
[16:11] <GunnarHj> Seems to be the tech board.
[16:11] <GunnarHj> Back to 17 UTC is fine for me.
[16:11] <pmatulis> ok
[16:14] <dsmythies> Gunnar, Peter, seems nobody else is here for doc team meeting, so lets just terminate. Us 3 talk via e-mail and / or IRC anyhow.
[16:14] <pmatulis> why not talk now? since we're here
[16:16] <GunnarHj> I agree with pmatulis. Let's take this opportunity to talk about the current stuff.
[16:16] <pmatulis> re hashes wiki, i'm not sure how we can do anything about it one way or another. can't anyone edit it? if it's locked down, i've been clear on the m/l. my vote is to get rid of it
[16:17] <dsmythies> pmatulis: My vote is to replace it with the page we were working on. There is the person that has volenteered to maintain it, but he always has to be reminded.
[16:18] <dsmythies> No, edit access is restricted.
[16:18] <dsmythies> ... as it should be.
[16:18] <GunnarHj> Yeah, we should go back to the plan we had before he volunteered.
[16:19] <pmatulis> it would be great to get the number of hits on that page. i can ask the admin people. if it's a popular page then it makes sense to keep it, in some form anyway
[16:19] <GunnarHj> the release team won't be interested enough to get involved, since several of them think the page is redundant.
[16:20] <dsmythies> The issue always becomes HTTPs verses HTTP, however that is not our issue, and the people whose issue it is have already said they will not do it (an HTTPS page).
[16:21] <GunnarHj> No, pmatulis, the problem is more complex. The page's popularity isn't a good base for decision.
[16:21] <pmatulis> GunnarHj: how so? briefly :)
[16:22] <GunnarHj> Maintaining it would be a natural task for the release team. They are not interested, since the information is available elsewhere.
[16:23] <dsmythies> hits are available. seems to average about 500 hits per day.
[16:23] <GunnarHj> So let's just replace it with a page which points to the information.
[16:23] <dsmythies> I agree, repleace it with that page we were working on.
[16:24] <dsmythies> Note: Hits can be misleading due to bots.
[16:25] <dsmythies> This page: https://help.ubuntu.com/community/UbuntuHashesProposed
[16:25] <pmatulis> dsmythies: where to see hits?
[16:25] <dsmythies> https://help.ubuntu.com/community/UbuntuHashes?action=info&hitcounts=1
[16:25] <pmatulis> dsmythies: yes, perfect, i agree with the proposed page
[16:26] <GunnarHj> Then let's make a final decision. :)
[16:27] <pmatulis> dsmythies: ok nice
[16:27]  * pmatulis votes +1 for proposed page
[16:27] <dsmythies> I move that we ask someone with access rights to replace the hashes page with the proposed one.
[16:28] <GunnarHj> +1
[16:28]  * pmatulis seconds dsmythies proposal
[16:28] <dsmythies> And vote for the proposal (I don't know how to do it the way Peter did.)
[16:28] <pmatulis> dsmythies: start a sentence with /me
[16:29] <dsmythies> O.K. Motion carried. I'll do the follow up.
[16:30] <GunnarHj> Can we talk abot dholbach's list message after the CC meeting with the docs team?
[16:30] <dsmythies> Peter: I was proposing that if people are interested in a spring at the open help thing, they could try to do as many serverguide bug reports as possible, before we have to split it into 14.04 and trunk.
[16:30] <dsmythies> Gunnar: go first.
[16:31] <dsmythies> spring => sprint
[16:31] <dsmythies> Gunnar: Give me a sec to re-read it.
[16:32] <GunnarHj> Ok. I think the discussion about the lack of manpower and dholback's initiative deserve to be followed up somehow.
[16:32] <pmatulis> yeah, can we get a link to that post?
[16:32] <GunnarHj> https://lists.ubuntu.com/archives/ubuntu-doc/2015-August/019503.html
[16:32] <pmatulis> thank you GunnarHj
[16:34] <dsmythies> Gunnar: I agree. A good example, was for a cycle where we did have good contribution. We were very active on IRC and e-mail and even had a status task list speadsheet on google. It worked very well.
[16:34] <dsmythies> ...In the end though, there were still only a few deeply involved.
[16:35] <GunnarHj> dsmythies: I think that was the case right before I got involved. Then the activity dropped. :(
[16:35] <dsmythies> Yes, and it was Kevin Goodby doing a ton of work on the desktop guide that cycle
[16:36] <GunnarHj> Right. (And before him jbicha)
[16:37] <GunnarHj> Possibly the situation is better wrt the serve guide. As regards the desktop guide I smell a crisis, especially when Unity 8 get started.
[16:37] <pmatulis> what does daniel mean by 'Ubuntu Community Q&A'?
[16:37] <dsmythies> yes, but jeremy, and somewhat Matt, tended to work in isolation. For example, I had not idea that the serverguide was being changed to a new theme. It just happened, and then we suffered side effects for years afterwards.
[16:38] <GunnarHj> dsmythies: That's not the right way, of course...
[16:39] <GunnarHj> pmatulis: Possibly the teams working with quality and bugs.
[16:39] <dsmythies> GunnarHj: I think, but am not sure, that isolation occured due to overload. I think they just charged ahead and did stuff.
[16:40] <GunnarHj> dsmythies: Agreed.
[16:40] <dsmythies> I think there is a Q & A session every week or two or something. I'll try to find it.
[16:42] <dsmythies> I think he was referring to: https://daniel.holba.ch/blog/2015/08/ubuntu-community-qa/
[16:43] <GunnarHj> Latest log: http://irclogs.ubuntu.com/2015/09/01/%23ubuntu-on-air.html
[16:45] <pmatulis> a quick scan shows no doc person was there
[16:46] <GunnarHj> True. I wasn't even aware of its existence...
[16:46] <pmatulis> me neither
[16:46] <dsmythies> I wasn't aware either.
[16:48] <GunnarHj> Anyway, I don't think we will be able to solve the problem in this discussion. My intention of bringing it up was just to emphasize that we should respond properly somehow. I for one need some more time to think it over.
[16:49] <dsmythies> I have been thinking also.
[16:49] <GunnarHj> dsmythies: And? ;)
[16:51] <dsmythies> Well, and as the past example shows, when we have some sort of critical mass and desire to get something done, it just works, without any specific times. In that past example, the string freeze deadline created the sense of urgency.
[16:52] <dsmythies> also...
[16:52] <dsmythies> at the time, Liz was somewhat active in a leadership role, which helped a lot (my opinion).
[16:54] <GunnarHj> So in a sense you say that I'm worrying unnecessarily. Maybe you have a point...
[16:56] <dsmythies> The valid worry is the continuing lack of contributors. Isn't it?
[16:57] <GunnarHj> Probably. I think the situation would improve greatly if we could recruit someone who stepped up and assumed the desktop driver role.
[16:57] <dsmythies> by the way, the meeting in meeting-2 ended at 17 after.
[16:58] <dsmythies> GunnarHj: Yes, a desktop leader driver is needed. I wonder when Kevin is coming back?
[16:58] <pmatulis> maybe we're being too nice
[16:59] <dsmythies> peter: Go on.
[16:59] <GunnarHj> pmatulis: How?
[16:59] <pmatulis> i find there is a disproportionate number of critics compared to the number of people who actually work on the docs. i see this a lot on the m/l. everyone has an opinion and things go nowhere but we continue to strive for a high degree of democracy
[17:00] <pmatulis> we're such a small group. maybe we *should* do what doug said mat and jeremy did
[17:01] <GunnarHj> You mean just do things rather than talking about it? I agree completely. (Tend to do so already personally.)
[17:01] <pmatulis> and perhaps we need more of a guerilla marketing approach to get people onboard. like sticking our necks out and offering to do impromptu hands-on tutorials on how to contribute or establishing a lightweight mentor program
[17:02] <pmatulis> currently we depend on updating our wiki doc page hoping people will just appear
[17:03] <GunnarHj> I like the mentor program idea.
[17:03] <pmatulis> it's good to have that page updated but we shouldn't hope for much
[17:04] <GunnarHj> Explicitly offering mentorship to people who want to get on board might be a very good thing.
[17:04] <pmatulis> sending out general emails doesn't work well either. one guerilla approach might be to "nab" someone who has filed a bug or a newcomer who has done a little more
[17:05] <dsmythies> Ted is a good example. We stepped in and helped when he got stuck woth his first serverguide merge proposals.
[17:06] <GunnarHj> Hannie is another example (has been involved in the manual previously)
[17:07] <dsmythies> I am not sure how to conclude this dicussion, but I have to move on to some other things now.
[17:08] <GunnarHj> I don't think we need to conclude it. Some good thoughts were mentioned. Thanks! Let's keep thinking about it.
[17:08] <dsmythies> I will keep thinking about it.
[17:08] <GunnarHj> A brief report about the desktop guide - there are two things in my mind:
[17:09] <GunnarHj> * Ask bregma about reviving the "What's new" page
[17:09] <GunnarHj> * Add something about fcitx to the keyboard-layouts page
[17:09] <GunnarHj> I have no other items for the meeting.
[17:10] <dsmythies> Oh yes, string freeze is soon.
[17:10] <GunnarHj> yep
[17:10]  * dsmythies - afk for about 20 minutes
[17:11] <GunnarHj> Ok. I'll keep connected to this room.
[17:11] <pmatulis> btw, i'm not sure if i mentioned this to the team but i've recently moved out of the canonical support team to the canonical docs team :)
[17:11] <pmatulis> in the last few months i've been steadily closing juju doc bugs. since juju docs are linked from help.u.c you can say i've contributing quite a lot to server docs ;)
[17:12] <GunnarHj> pmatulis: That was news to me. Thanks.
[17:14] <pmatulis> GunnarHj: juju docs uses github and not launchpad so i am now fairly acquainted with github web site and git CLI
[17:15] <pmatulis> strangely, juju itself uses launchpad
[17:17] <GunnarHj> Ok. I have never taken the time to learn git. Sometimes when dealing with upstream patches it would have been useful to master.
[17:30] <dsmythies> pmatulis: News to me also. Thanks for the update.
[17:31] <dsmythies> git: yes I use git almost every day now, as I pretty much only use the kernel.org kernel,, but with the Ubuntu kernel config file.
[17:32] <pmatulis> dsmythies: why do you do that?
[17:35] <dsmythies> pmatulis: I tend to work upstream for kernel stuff and therefore prefer to work on a compatible kernel. I have been working for a longtime now on the intel_pstate driver.
[17:36] <pmatulis> dsmythies: you are doing code work for that driver you mean?
[17:39] <dsmythies> pamtulis: I have been working on a patch set, yes. However, I don't know if it will ever be included. I first submitted it on 2105.04.11. In my opinion, there are issue with the driver in its current form.
[17:39] <pmatulis> dsmythies: i had no idea. impressive!
[17:40] <GunnarHj> I knew about it. Agree with pmatulis on impressive. :)
[17:40] <GunnarHj> I'd need to do some off keyboard stuff. Can we consider the meeting be ended?
[17:41] <dsmythies> Yes. Ended.
[17:41] <GunnarHj> Ok. See you guys!
[17:41] <pmatulis> bye GunnarHj, dsmythies