[00:28] <slangasek> pitti: did you still need an owncloud-client ignore?
[00:38] <slangasek> pitti: seems so - hint added now
[02:24] <lolcat> Has it ever been considered to make aptitude use bitorrent?
[02:31] <tarpman> lolcat: https://wiki.debian.org/DebTorrent
[02:41] <lolcat> cool
[02:44] <lolcat> tarpman: So it isn't feasible?
[02:45] <lolcat> I would love for it to use bittorrent on the local network in addittion to a web seed. SO if bandwidth is thight it gets it from local computers
[03:00] <RAOF> lolcat: In the meantime, running an apt-proxy is pretty simple.
[03:00] <RAOF> lolcat: See squid-deb-proxy-client + squid-deb-proxy/apt-cacher-ng etc.
[03:01] <lolcat> Hard to install on freeBSD
[03:01] <RAOF> Why would you install it on freeBSD?
[03:01] <RAOF> (And I'd be amazed if squid was hard to install on FreeBSD!)
[03:02] <lolcat> Because I have three computers with ubuntu
[03:02] <lolcat> They are not on at the same time always
[03:02] <lolcat> How would I set it up so they know which has the package?
[03:02] <lifeless> lolcat: pkg_add squid; done - no ?
[03:03] <RAOF> There's apt-zeroconf for that, if you don't have a machine that'd be mostly-on.
[03:03] <lifeless> lolcat: squid-deb-proxy uses zeroconf
[03:03] <RAOF> Welcome, squid-highlighting friends!
[03:03] <RAOF> :)
[03:03] <lolcat> ah
[03:04] <lolcat> I guess Ill just upgrade to 100mbps and forget about it
[03:04] <lifeless> *blink*
[03:05] <RAOF> Oh, apt-zeroconf is dead-dead. That's a bit of a shame; the other caching solutions don't quite cover the distributed-cache usecase.
[03:07] <RAOF> lifeless: There's no trivial configuration to turns squid into a distributed cache solution, right? (ie: multiple squid caches on the network, dispatch to appropriate cache if cache has file, otherwise download locally and cache)
[03:10] <RAOF> (I've probably asked that before)
[03:11] <lifeless> RAOF: cache_peer and list all the peers
[03:11] <lifeless> RAOF: IIRC digests (bloom filter API) are on by default, so you'll get that behaviour
[03:11] <lifeless> should be easy enough to wire a config generator into zeroconf and do that
[03:11] <RAOF> Hm, yeah. Interesting.
[03:12] <lifeless> of course, trust is an issue, as you're basically saying 'hey, use me for transit!'
[03:12] <RAOF> Well, there's apt's signing mechanism on top.
[03:12] <lifeless> for the special case of safe-over-http content, sure
[03:13] <RAOF> So you shouldn't be able to silently break stuff.
[03:13] <lifeless> just saying :)
[03:13] <lifeless> you could silently withhold security updates
[03:13] <RAOF> Don't we https:// them yet?
[03:13] <RAOF> No, we don't. Sadface (:
[03:14] <lifeless> and also they don't exist for the open release
[03:14] <RAOF> True.
[03:14] <RAOF> We could always turn off proxying for Packages.gz
[03:17] <RAOF> Actually, I suspect the default config works for that; setting all 0s for refresh_pattern on Packages should do that?
[03:18] <lifeless> no
[03:18] <lifeless> that affects heuristics
[03:18] <lifeless> explicit timing data from servers takes precedence
[03:18] <lifeless> unless you actually explicitly override which IIRC requires a compile time option to enable RFC violations
[03:19] <lifeless> I'm not really worried about someone withholding updates
[03:19] <RAOF> There's presumably a squid key to disable caching and always got to the server?
[03:19] <lifeless> it was just an observation
[03:19] <lifeless> yes
[03:21] <RAOF> Well, if I were to, say, update the default squid-deb-proxy configuration to handle this I'd want to make sure it's approximately as secure :)
[03:21] <lifeless> its not secure now
[03:21] <lifeless> in this sense
[03:21] <lifeless> because I can plug an unprivileged machine in and advertise
[03:21] <lifeless> so - no new hole
[03:22] <lifeless> the difference is that you want to share the cache
[05:55] <pitti> Good morning
[05:55] <pitti> slangasek: yes, doko_ asked for it; thanks
[05:57] <Noskcaj> pitti, The g-s-t merge should be ready for you to look at
[05:58] <Noskcaj> (finally)
[05:58] <pitti> Noskcaj: yes, thanks muchly! I have it in a tab to review this morning
[05:58] <Noskcaj> :) Then i can nag you about the other 50 packages i have that need sponsoring
[06:00] <darkxst> hey pitti
[06:06] <pitti> hey darkxst, how are you?
[06:07] <darkxst> yeh good, finally it has cooled down here!
[06:08] <Unit193> mvo: Howdy.  Did you happen to see my comment before you left last night?
[06:08] <darkxst> pitti, would you be able to add an endorsment to my PPU/MOTU application? (Planning on attending the next meeting 27th)
[06:09] <pitti> darkxst: sure, will do
[06:09] <darkxst> thanks
[06:14] <pitti> Noskcaj: hm, did you update debian/control manually? curious how the "XSBC-Original-Maintainer: Maintainer:  [...]" oddity came in here (will fix that during merge)
[06:15] <Noskcaj> Probably. I think bzr had a conflict there that i must have done wrong. oops
[06:15] <pitti> Noskcaj: FYI, debclean will update debian/control from control.in
[06:15] <Noskcaj> This is why i hate packaging one thing over many days
[06:16] <Noskcaj> ok
[06:16] <pitti> (no worries)
[06:20] <mvo> Unit193: i didn't, sorry - could you please paste it to me again?
[06:21] <Unit193> I ended up commenting before you responded.  I saw several marked as dupes of that bug so just figured there was proper, then noticed I couldn't re-open.  Is there a chance you can do that?
[06:33] <mvo> Unit193: I think I can, could you please give me the bugnumber again?
[06:34] <Unit193> mvo: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060543
[06:41] <Noskcaj> Could someone help me with refreshing a patch to argyll?
[06:41] <Noskcaj> ty for the syncs pitti
[06:41] <pitti> Noskcaj: yw
[06:43] <Noskcaj> I need help re-adding a patch to https://code.launchpad.net/~noskcaj/ubuntu/trusty/argyll/merge
[06:43] <Noskcaj> xnox, I think you made the  original
[06:44] <Noskcaj> drop-usb-db.patch
[06:53] <Unit193> mvo: Danke!
[06:54] <mvo> Unit193: your welcome .)
[06:54] <mvo> Unit193: I will try to look at your diff today, if nothing has happend by lunchtime please gently nudge me again (have to do some other stuff first)
[06:55] <Unit193> mvo: Heh, it's 01:55, I'm watching Castle then going to bed. :P  But sure, next time.
[06:56] <mvo> Unit193: wehh, these timezones .) yeah, lets talk tomorrow, have a good night
[07:01] <Unit193> Indeed.
[07:30] <dholbach> good morning
[09:21] <xnox> Noskcaj: be careful, in debian I think they dropped the db usage completely, which I don't think is correct.
[09:22] <Noskcaj> xnox, ok. Is there any chance you could try and finish the merge, since it's beyond my understanding
[09:23] <xnox> yeah, i will.
[09:23] <Noskcaj> thanks
[09:51] <apw> pitti, autopkgtests ... the one we did for linux ... this is a compile test basically which is great when gcc changes, but makes no sense to fire when the package in question is linux itself as we just did that.  is this something we can codify in the test?
[09:52] <pitti> apw: not really in linux itself, as that autopkgtest has no idea when/why it gets called
[09:52] <apw> pitti, so i don't get offered the name of the trigger'er or anything
[09:52] <pitti> apw: we could perhaps change eglibc's autopkgtest to try and build linux, not itself
[09:53] <pitti> apw: no, britney/jenkins are way higher up in the stack than autopkgtest, I'm afraid
[09:53] <apw> pitti, i thought that way lay madness or something, as every package had to list all possible packages
[09:53] <pitti> apw: i. e. instead of trying to build itself, packages could try and build the others in the "toolchain" set except themselves
[09:53] <pitti> right
[09:53] <pitti> and it doesn't parallelize that way
[09:53] <pitti> which is why we did it this way around and live with the overhead
[09:53] <brendand> ponder - launchpadlib in python3
[09:54] <apw> so it sounds like something fundamental to the /control level to say "but not for me"
[09:54] <brendand> rebuilt on requests
[09:54] <pitti> apw: we have enough build slaves, after all; the unnerving thing are the failures
[09:54]  * apw has yet to see a kernel make it through testing i think
[09:54] <pitti> apw: we recently found a too small copy timeout for linux (on one node, copying the sources takes more than 5 mins, yay slow disks); so it ought to get better now
[09:54] <pitti> and fail less often
[09:54] <pitti> apw: how do you mean?
[09:55] <pitti> apw: they succeed often, but also used to timeout often
[09:55] <pitti> https://jenkins.qa.ubuntu.com/job/trusty-adt-linux/?
[09:55] <apw> pitti, all the ones i have followed through have failed on one arch out of the two i think
[09:55] <apw> but that would be only on upload, not ones triggered say but eglibc or whatever
[09:56] <pitti> ah, tar freaking out again with "File removed before we read it
[09:56] <apw> pitti, so you pointed me at a jenkins page which is like shoving hot needles in my brain, but making the foolish assumption that red == bad and green == good down the left there, my head says <half worked
[09:56] <pitti> apw: exactly
[09:57] <apw> ok so by my cound 60% are failing
[09:57] <jibel> apw, timeout increased to 2000s. It may still fail depending on IO contention on the servers.
[09:57] <pitti> apw: ah, that's still the timeout apparently
[09:57] <pitti> from copyupdown
[09:57] <pitti> jibel: thanks
[09:58] <pitti> jibel, apw: retried
[09:58] <jibel> pitti, yes, now set to 2000s we could as well drop it completely
[09:59] <apw> pitti, what is this copy, is it someting i need and can i ask for it not to be so copied in my test stanza
[10:00] <pitti> apw: no, unfortuantely not
[10:00] <pitti> apw: that's autopkgtest copying the source package/source tree into its temp dir in the runner
[10:00] <pitti> apw: and aldebaran's disk is just awfully slow
[10:01] <pitti> apw: most tests are run on tmpfs (this machine has 64 GB RAM or so), but it's not enough to build linux; so linux and libreoffice run on a disk overlay instead of RAM
[10:02] <directhex> pitti, exclusively on disk? or ram overflowing to disk?
[10:03] <jibel> pitti, this machine is quite good but if at the same time it runs smoke tests they eat all resources available
[10:03] <pitti> ah
[10:03] <pitti> directhex: exclusively on disk; can qemu-img do this kind of hybrid mode?
[10:05] <directhex> pitti, i think we hammered it into working for a project at work. trying to remember the details. it involved using nbd to create a ram block device (not using tmpfs) but i don't remember which service was used to overflow to an LV
[10:05] <directhex> maybe bcache
[10:11] <pitti> apw: hey, perhaps you have an idea about that: since recently (few days, could be with the new -4 kernel), preparing our autopkgtest VMs fail due to ENOSPC
[10:11] <pitti> apw: the issue is that df says that /dev/vda1 (which is root) is 100% full, it's 5.9 GB
[10:11] <directhex> am asking the engineer who did it if he documented it anywhere
[10:11] <pitti> apw: but du -hcx / only reports some 800 MB being used
[10:12] <pitti> apw: I already checked /proc/*/fd/ and lsof for deleted files, there are none at all; and tune2fs says the journal is only 32 MB
[10:12] <pitti> apw: do you happen to know anything else which could eat up disk space which doesn't appear in df or in deleted files?
[10:13] <lifeless> pitti: out of inodes?
[10:13] <pitti> lifeless: nope, checked that already
[10:13] <pitti> Block count:              1572608
[10:13] <pitti> Free blocks:              1340686
[10:13] <pitti> Free inodes:              332101
[10:13] <Laney> jodh: just got the reboot again
[10:14] <pitti> # du -hsx /
[10:14] <lifeless> pitti: so clearly has free blocks
[10:14] <pitti> 832M/
[10:14] <lifeless> pitti: what about quotas?
[10:14] <pitti> /dev/vda1       5.9G  5.9G     0 100% /
[10:14] <pitti> lifeless: they aren't set up
[10:14] <lifeless> oh, I see, df thinks its full
[10:14] <pitti> but even if they were, they shouldn't affect root and df?
[10:14] <lifeless> the free blocks is what 80%
[10:14] <pitti> lifeless: yes, and everything else fails on ENOSPC too
[10:14] <pitti> lifeless: right
[10:15] <pitti> I'm running out of ideas what could be wrong
[10:15] <lifeless> I smell a bug :)
[10:15] <pitti> neither cloud-init nor cloud-utils changed recently, nor the ext tools
[10:15] <pitti> I suspected hidden or deleted files, but I don't find any
[10:15] <lifeless> pitti: they would use up free blocks
[10:16] <lifeless> pitti: so it can't be that
[10:16] <pitti> true that
[10:16] <TJ-> pitti: sparse allocation maybe?
[10:16] <Laney> jodh: what logs do you want?
[10:16] <Laney> I was doing an apt update in the host and inside an lxc container simultaneously
[10:16] <jibel> pitti, lifeless and after a reboot used space on /dev/vda1 is 15%
[10:16] <pitti> TJ-: perhaps; I'm not entirely sure how the cloud images' root fs are put together
[10:17] <pitti> qemu-img resize $DISKPATH +${DISKSIZE}
[10:17] <pitti> jibel: ^ is that it?
[10:17] <jibel> pitti, yes
[10:18] <pitti> last qemu update was on Jan 3, the next upload is still stuck in -proposed, so not that either
[10:18] <jibel> then cloud-init resizes it to the maximum size available
[10:18] <jibel> it = rootfs
[10:20] <Laney> jodh: the last thing in my apt log is Setting up libselinux1:amd64 (2.2.2-1) ...
[10:20] <Laney> libselinux1's postinst does telinit u
[10:22] <jodh> Laney: I think you'll find that you have an invalid conf file that is triggering the crash. alsa-utils is the most recent package that had invalid jobs, but that has now been fixed.
[10:22] <Laney> would it be logged?
[10:23] <Laney> anyway, that should certainly not cause the machine to reboot
[10:24] <jodh> Laney: yes, if you're running in debug mode (--debug).
[10:24] <jodh> Laney: of course :) I've now fixed the bug but am awaiting an upstart developer to review the fix: lp:~jamesodhunt/upstart/bug-1269731. Maybe xnox or cjwatson could take a look?
[10:25] <TJ-> pitti: doesn't make sense though; df uses the block allocation maps, so if it reports 100% the host is using sparse allocation and has run out of space
[10:27] <cjwatson> jodh: looking shortly
[10:27] <jodh> cjwatson: thanks!
[10:27] <lifeless> pitti: jibel: is it possible that online resize is being used, and is broken ?
[10:27] <jibel> pitti, I reprovisioned a VM with a disk size of 12G and df is still reporting it is full on first boot. /dev/vda1        12G   12G     0 100% /
[10:27] <lifeless> anything in dmsg
[10:27] <pitti> TJ-: I just wanted to check this, and I made an interesting observation
[10:28] <pitti> $ sudo du -hsxc /tmp
[10:28] <pitti> 4,0K/tmp
[10:28] <pitti> tmpfs                  7,8G    5,7G  2,1G   74% /tmp
[10:28] <pitti> that's on my workstation (not in qemu)
[10:28] <pitti> $ sudo du -hsxc /run
[10:28] <pitti> 1,3M/run
[10:29] <pitti> tmpfs                  1,6G    1,2M  1,6G    1% /run
[10:29] <pitti> err, no, run-adt-test is using /run/shm, right?
[10:29] <pitti> anyway, I have 4K files in /tmp/, but df says 5.7 GB are used in /tmp
[10:29] <cjwatson> jodh: r=me, sorry for the delay
[10:29] <pitti> so it might very well be that qemu has no space because on my host /dev/shm/ is full
[10:30] <pitti> although it isn't, /run/shm/ has 7.3 GB free
[10:30] <pitti> just /tmp/ is really wrong
[10:30] <Laney> jodh: oh cool, thanks
[10:30] <pitti> jibel: ^ does prepare-testbed use /tmp? that might explain why it's full during prepare-testbed, but works after a reboot when it uses /run/shm
[10:31] <Laney> grr
[10:31] <pitti> jibel: well, I'll try booting with 3.13.0-3 and compare
[10:31] <Laney> stgraber: got any ideas how we can make the ssh-agent script less racy?
[10:32] <jodh> cjwatson: thanks!
[10:32] <jibel> pitti, it uses what you set as BASEDIR in ~/.adtrc and defaults to /tmp
[10:32] <pitti> BASEDIR=/home/martin-scratch/adt
[10:33] <TJ-> pitti: Isn't it pressure on RAM? tmpfs is backed by swap space
[10:34] <pitti> TJ-: well, I still don't know why it would run out of RAM; but the lost 5.7 GB in my /tmp/ are certainly curious
[10:34] <pitti> (/tmp is on tmpfs)
[10:35] <smb> pitti, jibel Note that the 3.13.0-3 kernel very likely has an accounting bug for tmpfs
[10:35] <pitti> smb: I didn't have the cloud-init problem on -3; it just started maybe two days ago
[10:35] <smb> 3.13.0-4 (currently in proposed is believed to fix this)
[10:36] <pitti> could coincide with -4
[10:36] <pitti> smb: you mean -3 → -4 and -4 → -5 ?
[10:36] <pitti> smb: I'm currently downloading -5 from -proposed and will test that
[10:36] <smb> pitti, Err yeah I probably do
[10:37] <smb> pitti, Versions changing so quickly, sorry.
[10:37] <cjwatson> what's up with the linux autopkgtest?
[10:37] <pitti> that at least would also explain why we don't get that problem in the DC where we have precise or saucy as a host OS
[10:38] <pitti> cjwatson: it keeps timing out on copying the sources into its tmp dir; jibel just bumped the timeout again
[10:38] <cjwatson> ah, /me reads scrollback.  so is somebody retrying the test?
[10:39] <cjwatson> we need to get this in for the alpha
[10:39] <pitti> cjwatson: already did
[10:39] <cjwatson> ok, good
[10:39] <cjwatson> sorting d-i now
[10:41] <pitti> jibel: ok, so with -5 on the host I still get the bug in the VM; we might need to get -5 into the cloud image
[10:41] <pitti> at least df now looks sensible in my hosts' /tmp/
[10:41] <pitti> smb: ^
[10:42] <darkxst> cjohnston, hey, I am applying for upload rights on ubuntu GNOME packageset but there isnt one!
[10:42] <cjwatson> pitti: good, hopefully it'll fix d-i too
[10:42] <darkxst> cjwatson, ^^
[10:42] <cjwatson> darkxst: I'm no longer on the TB so I don't operate packagesets any more
[10:42] <cjwatson> darkxst: though you probably actually want to ask the DMB
[10:43] <darkxst> cjwatson, Laney told me to ask you
[10:43] <cjwatson> darkxst: Laney is wrong :)
[10:43] <Laney> haha
[10:43] <Laney> Can we drive those scripts?
[10:43] <smb> pitti, Probably needs to move to updates. But then I should read more scrollback on what exactly your tmpfs problem is after changing the latest kernel
[10:43] <cjwatson> I *think* it needs the TB, but you can try
[10:43] <cjwatson> lp:~cjwatson/+junk/packageset - there's a component you need to run on lillypilly
[10:44] <pitti> smb: right, let's wait until this is in trusty and we have a cloud-image with -5
[10:44] <Laney> == All uploaders for package set 'ubuntugnome' in 'trusty' (owned by 'Ubuntu Technical Board') ==
[10:44] <cjwatson> (or I suppose just anywhere with a full mirror)
[10:44] <Laney> DMB cannot manage that
[10:44] <pitti> smb: it's all very confusing ATM, and tests on various host and guest configurations give contradicting results
[10:45] <smb> pitti, With the tmpfs bug, anything that actually makes use of it has a chance to fail. So it could be something ending up in tmpfs on the host but also and probably more often when using anything inside the guest
[10:45] <darkxst> Laney, cjwatson, so I am applying for a non-existent packageset ? atlest MOTU will be useful ;)
[10:45] <Laney> stgraber is in the intersection
[10:46] <apw> if it is the percpu fix we are talking about you would need that everywhere, as /dev is one
[10:46] <Laney> he might be interested in learning how to run this process
[10:46] <cjwatson> Laney: I was planning to hand it over at the core sprint next week
[10:47] <pitti> apw: originally it was the "/dev/vda1 is 100% full although it isn't" issue in qemu, then I noticed the "df gives bogus tmpfs usage" on my host; they might or might not be releated
[10:47] <pitti> apw: so I guess we'll let -5 propoagate and get a cloud image with it, then I'll try again; let's hope it's all good then
[10:47] <Laney> cjwatson: nod
[10:47] <cjwatson> Laney: when people can throw tomatoes at me for it in person
[10:47] <cjwatson> (it's really dreadful code)
[10:47] <apw> pitti, indeed, but i would test with everything updated rather than hurt your mind with the infinite possibilities
[10:48] <pitti> apw: right; apparently -5 on the host and -4 in the qemu guest doesn't fix it yet
[10:48] <smb> pitti, Quite expectedly
[10:48] <pitti> apw: conversely, with a raring kernel on the host and -4 as a qemu guest it seems to work
[10:48] <pitti> apw: but curiously this is on a qemu-img backed on ext4, not tmpfs
[10:49] <pitti> oh well *shrug* kernel mystics .. /me goes and investigates the equally mysterious bug 1220681
[10:49] <apw> the issue is in per cpu counters, its not tmpfs related just that is very sensitive to it
[10:50] <apw> given the bug, i am amazed the kernel boots with it at all under any circumstances
[10:50] <pitti> apw: ah, so it could break just about anything
[10:50] <cjwatson> apw: I guess it effectively means it never clears any references to anything
[10:50] <cjwatson> probably uses a shitload of memory
[10:50] <apw> and pretty much everything, i had all sorts of random things going on on -4, -5 seems better to me
[10:50] <pitti> that now also explains why my apt-get was so glacially slow yesterday
[10:50] <apw> leaking like hell at least i recon
[11:14] <pitti> apw: hm, something isn't quite  right -- why does the autopkgtest build it *twice*?
[11:17] <pitti> apw: nevermind, I mislooked; all good (i386 succeeded)
[11:31] <pitti> stgraber: is it possible to set a different default container dir (than /var/lib/lxc) in /etc/lxc/default.conf or ~/.lxc<something>? man lxc.conf doesn't mention it, nor does it mention what the actual config files are
[11:32] <pitti> stgraber: so that I don't need to use -P all the time
[11:41] <pitti> apw, cjwatson: linux autopkgtest succeeded now, BTW
[11:42] <pitti> "Not touching package due to block request by freeze "
[11:42] <pitti> but excuses still says "autopkgtest for linux 3.13.0-5.20: FAIL"; I hope it's just out of date
[11:45] <apw> pitti, i don't think it ever notices when you rerun a test does it ?
[11:45] <pitti> apw: actually I think jibel fixed that a while ago
[11:45] <apw> it just need ignoring the test i think there
[11:46] <pitti> apw: if it didn't update after the next run, I'll fix the history file
[11:46] <pitti> apw: ah, it just did
[11:46] <pitti> apw: all good now, it's just the release team blocker that holds it back now
[11:46] <pitti> (a2 freeze)
[11:47] <apw> and possibly d-i
[11:47] <apw> oh no that is there too ... ok
[11:47] <cjwatson> I uploaded d-i
[11:47] <pitti> not blocked by itself, it' sjust waiting on linux
[11:47] <apw> thanks
[12:24] <xnox> jibel: (i think we discussed this ~1.5 weeks ago) have you tried running tests under utah with this change applied to the base image: sudo sh -c "echo exec su - -c adbd > $OUT/mnt/etc/init/android-tools-adbd.override"
[12:24] <xnox> ?
[12:25] <xnox> sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
[12:25] <xnox> that actually?
[12:32] <jibel> xnox, it was not with me, sorry.
[12:36] <xnox> ok. i'll search my logs then...
[13:13] <shadeslayer> is there a reason why I would not have com.upstart.Ubuntu?
[13:14] <shadeslayer> over dbus that is
[13:15] <Laney> shadeslayer: firstly it's com.ubuntu.Upstart
[13:16] <Laney> assuming you just typoed, then I don't know :-)
[13:16] <shadeslayer> qdbus com.ubuntu.Upstart gives me Service 'com.ubuntu.Upstart' does not exist.
[13:18] <shadeslayer> Laney: I don't suppose there's a way to actually start that interface by hand?
[13:19] <shadeslayer> Laney: also, i'm on Kubuntu if that makes a difference
[13:21] <Laney> shadeslayer: sorry, I don't know - I was under the impression that it should always be there
[13:21] <Laney> maybe #upstart can help you
[13:21] <shadeslayer> aha, I'll ask
[13:52] <smoser> cjwatson,  i'm thinking about  memtest86+ as part of ubuntu standard.  how would you recommend re-ordering things so that I can get that out of cloud images?
[13:58] <cjwatson> smoser: will follow up to the dormant mail thread, this IRC channel is too narrow
[13:58] <smoser> ok thank you.
[14:00] <pitti> cjwatson: FYI, ubiquity autopkgtest failed on i386 FTBFS of webkit-gtk (causing uninstallability)
[14:06] <doko> pitti: I usually use severity serious for broken autopkg tests by design. it's nice if people add them, but things like this should never happen in the first place
[14:06] <doko> pitti, please overwrite this test. blocks a package removal
[14:07] <doko> pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty
[14:07] <pitti> doko: err, yes, I know -- that looks like a replay?
[14:07] <pitti> doko: slangasek added the override, it's in trusty
[14:07] <doko> pitti, oh, is it overwritten?
[14:08] <xnox> doko: any ~ubuntu-release can commit adt overrides in britney hints.
[14:08] <pitti>  libocsync-plugin-owncloud | 0.90.4-1        | trusty/universe | amd64, arm64, armhf, i386, powerpc, ppc64el
[14:08] <doko> still see
[14:08] <doko> libocsync-plugin-owncloud
[14:08] <doko>    	python-owncloud	universe	amd64 i386 arm64 armhf powerpc ppc64el
[14:08] <pitti> doko: ^ is that the version you are looking for? (nothign in -proposed)
[14:09] <cjwatson> pitti: is that something we (ubiquity developers) need to do anything about?  I'd expect it to be retried once webkitgtk is fixed
[14:09] <pitti> I don't see any "croc" in component-mismatches, NBS, or britney
[14:09] <pitti> cjwatson: no, it was just a FYI (as you probably got the mail)
[14:10] <pitti> ah no, xnox got it
[14:10] <cjwatson> that explains my confusion :)
[14:10] <pitti> cjwatson: sorry, in my mind "ubiquity" is still "Colin"
[14:11] <pitti> so for once an autopkgtest failure today was not due to the test machinery *sigh*
[14:11] <xnox> pitti: i'm not on top of my post-vacation unread mail threads yet, especially those from robots =)
[14:11] <pitti> xnox: no worries, and welcome back :)
[14:19] <xnox> pitti: re:autopilot. last time i was talking with thomi & barry, we were thinking to add a "python2" flag to all existing clicks (cause their tests run from $PWD), and for deb tests simply try module import with python3 to see if it should be run with python3.
[14:20] <xnox> pitti: once all tests are converted to python3. A python2 flag can be dropped from clicks (one by one) and for deb tests try python3 import will no longer be needed.
[14:20] <pitti> xnox: right; I just don't quite like the metapackage pulling in both the py2 and py3 stacks, as that's quite some overhead for the phone
[14:20] <xnox> pitti: thus we should arrive at not having any "X-Run-Me-Python3" in the long term, once all is converted. Without an explicit flag day.
[14:20] <pitti> so we need to do that transition for trusty now
[14:21] <xnox> pitti: which should be all done and dusted next week, at the core sprint when barry will be there + the rest of CI etc peoples =)
[14:21] <xnox> pitti: barry did submit a few merge proposals, but not all of them are merged yet.
[14:22] <pitti> xnox: right, I added it to the agenda of our QA sprint as well (mid-Feb)
[14:23] <pitti> xnox: I have patches for dialer-app and messaging-app here, but when I did them they were blocked on splitting out emulators for python3 for some packages
[14:23] <pitti> which in turn was blocked by some discussion how to package/name them
[14:23] <xnox> pitti: i think the next piece that is missing, is for phablet-test-run / utah-runners to do the "try python3" tests. And there is a rejected merge proposal that I saw in my emails.
[14:24] <pitti> doko: in our precise → trusty upgrade tests, several packages failed due to a missing python:any; what particularly provides that :any magic, new dpkg?
[14:24] <xnox> pitti: once we have ability to run tests under python3 in jenkins it should be all easy and quick to transition things one by one.
[14:24] <doko> pitti, yes
[14:24] <pitti> doko: or new python metapackages? it seems python:any deps now get autogenerated, but there is no Pre-Depends: or somethign like that on dpkg/python-defaults/etc.
[14:24] <doko> it's dpkg
[14:25] <pitti> xnox: still needs things like bug 1253627 fixed first
[14:25] <pitti> doko: ah, so perhaps dh_python[23] need to generate pre-depends for that?
[14:26] <pitti> doko: well, this is rather complex, I'll create a bug report and a small reproducer first
[14:26] <doko> pitti, won't help, I don't that any python-* module has misc:pre-depends
[14:26] <pitti> yeah, we'd need to either add them, or don't use misc:pre-depends
[14:27] <pitti> bbiab, will investigate this in detail later
[14:27] <pitti> doko: thanks, will try with old and new dpkg then
[14:41] <stgraber> pitti: lxc.lxcpath = in /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf
[14:42] <stgraber> pitti: those are currently undocumented because lxc.conf refers to the container's configuration, not the system config... I have a todo item for this week to create lxc.system.conf and lxc.container.conf manpages and have the lxc.conf one just explain what the two files are for and what their respective manpage is
[14:51] <mdeslaur> chiluk: unfortunately, I once again superseded your mysql packages in -proposed. Sorry.
[15:02] <pitti> stgraber: works perfectly, merci !
[15:03] <mdeslaur> barry: quick question: would this be the right way to run 'python setup.py configure' in a rules file? http://paste.ubuntu.com/6792046/
[15:04] <mdeslaur> or is there something better?
[15:04] <mdeslaur> (with dh_python2)
[15:04] <xnox> mdeslaur: there is "pybuild" which will run stock: configure, build, test, install for all python2 / 3 versions et.al.
[15:04] <barry> mdeslaur: interesting.  configure isn't a standard command, so i'm guessing the setup.py has added this.  in that case, dh_python2 probably won't help
[15:05] <xnox> mdeslaur: dh_python2, is a pure packaging helper that does correct extension renaming at the end.
[15:05] <xnox> mdeslaur: and you are playing with highly non-standard libvirt build machinery, so i'm not sure there is anything better for you than what you wrote.
[15:05] <xnox> (dh_python2 doesn't build/configure/install anything)
[15:06] <xnox>  * mostly true.
[15:06] <mdeslaur> xnox, barry: ok, thanks, so I'll stick with what I used
[15:07] <mdeslaur> thanks!
[15:07] <barry> sure!
[16:45] <ara> hello!
[16:46] <ara> any member of the sru team could have a look to these two verified bugs, please?
[16:46] <ara> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/404658
[16:46] <ara> https://bugs.launchpad.net/oem-priority/+bug/1253591
[16:46] <ara> thanks!
[16:50] <caribou> infinity: did you notice the email I sent a while ago about the merging of makedumpfile ,
[16:50] <caribou> ?
[16:51] <caribou> infinity: if it's ok with you, I'll merge it & do my best to get the debian side I package in sync
[16:58] <pitti> jibel: FYI, I filed bug 1271237 to track investigations
[17:00] <cjwatson> pitti: followed up with what might be a useful link
[17:00] <pitti> cjwatson: right, it very much sounds like that
[17:01] <pitti> python:any isn't satisfied yet, but apt doesn't upgrade python to satisfy it
[17:01] <pitti> cjwatson: many thanks for the link
[17:01] <cjwatson> np
[17:02] <cjwatson> seb128: could you check that the newer grub in trusty-proposed fixes your timeout problem?
[17:02] <pitti> cjwatson: I'll backport that and test an upgrade with that; the next question is of course whether apt gets upgraded before that
[17:02] <cjwatson> pitti: similarly, could you check that grub in trusty-proposed still works with SB for you?  another commenter spotted a bug that would affect from-scratch installs on SB
[17:02] <cjwatson> pitti: right, but that's more tractable, u-m could force that
[17:02] <cjwatson> (if it doesn't already)
[17:02] <pitti> *nod*
[17:02] <cjwatson> I guess I mean u-r-u
[17:03] <pitti> cjwatson: yes, I'm happy to update grub again, but it'd be an upgrade, not from scratch
[17:03] <cjwatson> right, just want to check that I didn't break anything else in the process
[17:03] <pitti> cjwatson: unless I can emulate a new installation by purging and reinstalling grub? (I can do that)
[17:03] <seb128> cjwatson, sure
[17:03] <cjwatson> no, you'd have to do manual stuff to your EFI System Partition - an upgrade is fine for this purpose
[17:04] <cjwatson> you could maybe run "sudo grub-install -v" after the upgrade to check that it copies shim to the right place
[17:04] <pitti> cjwatson: ah, that's -4 now -- that should also get rid of the menu again, right?
[17:04] <cjwatson> i.e. /boot/efi/EFI/ubuntu/shimx64.efi not /boot/efi/EFI/ubuntu/grubx64.efi
[17:04] <cjwatson> pitti: yep
[17:11] <pitti> argh, laggy german mirror
[17:11] <pitti>  *** 2.02~beta2-2 0
[17:11] <pitti>         500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
[17:11] <pitti> WTH
[17:15] <pitti> cjwatson: downloaded debs from LP, installed; no failure; with -v: http://paste.ubuntu.com/6792642/
[17:15] <pitti> grub-install: Info: copying `/usr/lib/shim/shim.efi.signed' -> `/boot/efi/EFI/ubuntu/shimx64.efi'.
[17:15] <pitti> grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
[17:16] <alkisg> Hi, I'm seeing 100% usage of overlayfs (squashfs nbd + tmpfs) file systems, while it should be 0%, it happened in some of the latest trusty kernels, and I'm guessing it should also affect the live CDs (other than LTSP), is it a known issue or should I try to pinpoint it more precisely?
[17:19] <cjwatson> pitti: great, thanks
[17:19] <cjwatson> alkisg: 3.13.0-5 will fix it
[17:19] <pitti> cjwatson: I'll reboot once my container upgrades are done
[17:19] <alkisg> Thank you cjwatson
[17:22] <pitti> cjwatson: booted fine, menu gone \o/
[17:22] <cjwatson> great
[17:23] <cjwatson> it's not totally without reported glitches but I think it's close enough that I'm inclined to push it to trusty after alpha-2
[17:23] <cjwatson> so far
[17:24] <jibel> pitti, postgresql upgrade fails from P>T, I'll file a bug. http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-tasks-amd64/5/
[17:24] <pitti> jibel: thanks
[17:25] <Laney> are those tests on public jenkins?
[17:26] <pitti> there certainly ought to be; it's a bit hard to link to logs ATM
[17:26] <jibel> Laney, they should be, I'll check the configuration.
[17:27] <pitti> update-alternatives: error: alternative pg_basebackup.1.gz can't be slave of psql.1.gz: it is a slave of postmaster.1.gz
[17:27] <Laney> I usually try s/<private host>/jenkins.qa.u.c/ but it failed in this case
[17:27] <Laney> thanks jibel
[17:27] <pitti> jibel: ^ ah, that, rings a bell
[17:27] <jibel> pitti, and a false positive http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-lts-saucy-amd64/6
[17:27] <pitti> jibel: I thought that was fixed already, but apparently it needs some further nudging
[17:27] <jibel> ^ fails during the removal phase
[17:27] <pitti> jibel: I don't see a psql bug there?
[17:28] <pitti> jibel: oh nice, that's precise with an LTS enablement stack; I guess these fall over pretty hard still
[17:28] <jibel> pitti, last bug is not postgresql, it is in xserver-common-lts-saucy and u-r-u
[17:29] <pitti> jibel: right, I discussed that with mlankhorst the other day; we need these -lts-* metapackags as transitionals in trusty, which move back to the standard stack
[17:29] <jibel> because upgrade aborted but the release-upgrader terminates without error
[17:30] <mlankhorst> pitti: oh right I need to create some
[17:30] <pitti> good night everyone!
[17:31] <cff> I'm trying to dual boot CM Android 4.2.2 on a Galaxy Nexus with Ubuntu but after I downloaded the Ubuntu image with the Android app and click reboot to Ubuntu I'm rebooted to recovery mode. What can I do to see what's wrong?
[17:31] <cff> (is this the right channel to ask this question?)
[17:32] <cff> ah, didn't realize there is an #ubuntu-touch channel
[17:53] <chiluk> mdeslaur
[17:54] <chiluk> mdeslaur can you have a look at 1121874
[17:54] <chiluk> mdeslaur it looks like your recent security update for mysql-5.5 updated the package
[17:54] <chiluk> mdeslaur, and maintained the fix for 1121874, but removed it's changelog entry..
[17:55] <chiluk> mdeslaur... I really think you should add the changelog entry back *(not sure if that's really doable.)
[17:55] <chiluk> I'm verifying s, and t right now.
[17:55] <mdeslaur> chiluk: what release are you talking about?
[17:55] <chiluk> p,q,s,t
[17:56] <mdeslaur> trusty has the fix, and includes the changelog
[17:57] <chiluk> I just looked at p and q... and they have the fix... but not the changelog entry.
[17:57] <mdeslaur> chiluk: not sure what you're looking at, but my packages definitely don't contain the fix
[17:58] <chiluk> the fix is in debian/mysql*.init
[17:59] <chiluk> mdeslaur also why did you just blindly remove the fix like that
[17:59] <mdeslaur> chiluk: huh? https://launchpadlibrarian.net/159968670/lp1121874.saucy.debdiff
[17:59] <mdeslaur> chiluk: no fix in .init there
[17:59] <chiluk> mdeslaur.. one sec... I think I missed the series arg to pull-lp-sourcfe
[17:59] <mdeslaur> chiluk: your package was in -proposed, I can't include a fix that hasen't been qa verified
[18:00] <chiluk> mdeslaur, I guess I'm just pissed because this is the third time that I'm having to rebase debdiffs because of security team.
[18:01] <chiluk> and the sru team taking too long to upload/sru approve this fix.
[18:01] <chiluk> this is insane.
[18:01] <mdeslaur> chiluk: yeah, the -proposed process sucks
[18:01] <infinity> (The SRU team doesn't do uploads)
[18:01] <mdeslaur> chiluk: I'll rebase and upload them today
[18:01] <mdeslaur> chiluk: and I'll get someone from SRU team to push them to -proposed right away
[18:01] <chiluk> thanks.
[18:02] <chiluk> i was going to verify them today.
[18:02] <chiluk> so I guess I'll get that done as soon as this gets figured out..
[18:02] <mdeslaur> chiluk: again, sorry about that...bad timing
[18:03] <chiluk> mdeslaur, it's always bad timing... this bug has been fixed since October, and it's wasted too much of a lot of peoples time.
[18:03] <mdeslaur> I definitely agree
[18:06] <mdeslaur> chiluk: mind if I keep your name in the changelog, and just change the version and date?
[18:06] <chiluk> that's fine.
[18:06] <chiluk> mdeslaur.. I just checked precise.. and the fix is definitely in the precise version just not in the changelog
[18:07] <infinity> caribou: I don't see much point in merging makedumpfile in Ubuntu at all.  Looking at the changes, those are all things you should want in Debian, so I'd merge in the other direction, if I were you, and then just sync-with-force back to Ubuntu.
[18:07] <mdeslaur> chiluk: I don't see it
[18:08] <rbasak> chiluk: if it's any consolation, I have also found it hard to get any SRUs into mysql in the past. I think I went round three times once.
[18:08] <chiluk> mdeslaur the fix is mostly thesse lines   # check for diskspace shortage
[18:08] <chiluk>   datadir=`mysqld_get_param datadir`
[18:08] <chiluk>   if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
[18:08] <chiluk>     log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
[18:08] <chiluk>     echo                "ERROR: The partition with $datadir is too full!" | $ERR_LOGGER
[18:08] <chiluk>     exit 1
[18:08] <chiluk>   fi
[18:09] <mdeslaur> chiluk: yeah, I don't see that in the precise package
[18:09] <chiluk> one of us is doing something wrong *(probably me)
[18:13] <chiluk> mdeslaur .. I run pull-lp-source mysql-5.5 precise, and look at debian/mysql-server-5.5.mysql.init
[18:13] <chiluk> and the fix is definitely sitting there.
[18:14] <chiluk> mdeslaur is there a chance the fix got pushed back into debian, as is now coming full circle?
[18:16] <mdeslaur> chiluk: you're looking at the .init file, you need to look at the .upstart file
[18:16] <mdeslaur> chiluk: that's where the bug is
[18:16] <chiluk> crap...
[18:16] <chiluk> see it's been so long ..
[18:16] <mdeslaur> hehe :)
[18:17] <chiluk> mdeslaur..see I knew i was doing something wrong..
[18:18] <chiluk> mdeslaur... the debdiffs should still mostly just apply ... aside from the changelog entries.. do you need anything from me to get that uploaded?  or are you just going to take care of it.
[18:20] <mdeslaur> chiluk: I'm almost done uploading, and then I'll ping someone from SRU to get it pushed to -proposed right away
[18:20] <chiluk> cool thanks.
[18:20] <mdeslaur> chiluk: np
[18:20] <chiluk> well at least it looks like the debian people have been paying attention and pulled my fix into the init script.
[18:21] <chiluk> and I use the term "fix" loosely ... I just want to see this thing gone.
[18:30] <mdeslaur> bdmurray: I just uploaded updated mysql packages to -proposed for bug 1121874, do you think you could push them today, please?
[18:31] <bdmurray> mdeslaur: sure
[18:32] <mdeslaur> bdmurray: thanks!
[18:36] <xnox> tkamppeter: recently I was able to use llvmpipe / gallium 3d on an openstack instance. But with current trusty I can't.
[18:36] <xnox> I get:
[18:36] <xnox> $ LIBGL_DEBUG=verbose xvfb-run glxinfo
[18:36] <xnox> name of display: :99
[18:36] <xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/swrast_dri.so
[18:36] <xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/swrast_dri.so
[18:36] <xnox> libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
[18:36] <xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
[18:36] <xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
[18:36] <xnox> libGL error: failed to load driver: swrast
[18:36] <xnox> Error: couldn't find RGB GLX visual or fbconfig
[18:36] <xnox> Error: couldn't find RGB GLX visual or fbconfig
[18:37] <xnox> tkamppeter: is that known?
[18:38] <seb128> xnox, hum, why do you ping our printer maintainer about graphic stack issues? are you sure you don't want mlankhorst or tjaalton?
[18:38] <xnox> seb128: good catch!
[18:38] <xnox> tkamppeter: sorry about that.
[18:39] <xnox> mlankhorst: tjaalton: any idea about above ^^^
[18:40] <seb128> xnox, btw I get the same output on my desktop (but followed by the glxinfo one)
[18:40] <xnox> and there haven't been any changes to mesa recently...
[18:41] <xnox> seb128: does it tell you "Vendor" ?
[18:41] <seb128> xnox, no
[18:41] <xnox> seb128: in my case, i don't GPU acceleration, so the swrast better load....
[18:42] <seb128> xnox, that undef symbol looks wrong in any case
[18:42] <xnox> seb128: well on my desktop i get:
[18:42] <xnox> OpenGL vendor string: Intel Open Source Technology Center
[18:42] <xnox> OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop x86/MMX/SSE2
[18:42] <xnox> (among the rest of the stuff glxinfo prints)
[18:42] <seb128> $ ldd -r /usr/lib/i386-linux-gnu/dri/swrast_dri.so
[18:42] <seb128> ..
[18:42] <xnox> seb128: and on headless systems I used to get "Gallium 3D vendor" now I get nothing.
[18:42] <seb128> undefined symbol: _glapi_tls_Dispatch	(/usr/lib/i386-linux-gnu/dri/swrast_dri.so)
[18:42] <seb128> etc
[18:43] <seb128> xnox, seems like the software rendering backend is having issues
[18:44] <xnox> seb128: here is full, working pastebin from my computer http://paste.ubuntu.com/6793108/
[18:44] <seb128> xnox, right, that has hardware support
[18:46] <seb128> though "LIBGL_ALWAYS_SOFTWARE=1 glxinfo" works on my desktop
[18:48] <xnox> seb128: mlankhorst: tjaalton: actually nevermind me it does work after all.
[18:49] <kees> doko: why was debian bug 27363 re-opened? I added --with autoreconf and a dep on dh-autoreconf. what is missing?
[18:50] <kees> sorry, debian bug 727363
[18:52] <cjwatson> that looks like a mistake - it builds just fine on ppc64el
[18:53] <kees> okay, cool
[18:53] <cjwatson> I think doko was mass-operating on all those bugs and hadn't noticed that that one had already been fixed in the more comprehensive way
[18:54] <kees> yeah, that's what I suspected, but I wanted to double-check. thanks!
[20:00] <Noskcaj> Could someone help me fix an FTBFS in xchat-gnome? just get https://code.launchpad.net/~noskcaj/ubuntu/trusty/xchat-gnome/merge and build it
[20:01] <Noskcaj> doko, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727373 can be closed, ppc64el builds fine
[20:01] <Noskcaj> and i'm doing the merge now
[20:06] <Ampelbein> Noskcaj: What failure do you get?
[20:06] <Ampelbein> (with xchat-gnome)
[20:07] <Noskcaj> Ampelbein, just let me re-branch it. It's been a few days since i worked on it
[20:12] <hallyn> infinity: mdeslaur is asking about qemu in trusty's ftbfs on powerpc.  have you had any luck there?  or should we just dump the aarch64 patchset?
[20:14] <infinity> hallyn: I was sick all weekend and yesterday, haven't had a chance to look at all.
[20:15] <hallyn> infinity: ok;  i'm out today;  maybe i can use a qemu-ppc to try the build tomorrow :)
[20:16] <hallyn> mdeslaur: so if you need the debdiff reverted to have it build please do so;  i'll then push when we figure out what went wrong
[20:16] <infinity> hallyn: I shouldn't think you'd need a PPC machine to build on.  I imagine if you build that ppc64-softmmu target on *any* arch, it will fail the same.
[20:17] <infinity> THough maybe not.  Hrm.
[20:18] <infinity> No, okay, that gets built on x86 and works.  That makes this so much more confusing.
[20:19] <hallyn> infinity: all right well maybe it'll be obvious to me once i take a closer look tomorrow.  thanks, get better!  /me out
[20:22] <Noskcaj> Ampelbein, http://paste.ubuntu.com/6793607/
[20:27] <Ampelbein> Noskcaj: gnome-doc-utils.make is missing, are you running autogen.sh ? That should call gnome-doc-prepare and create it.
[20:29] <Ampelbein> Noskcaj: Just checked out the branch (unrelated: What switch can I use to tell bzr that I only want to checkout the files at current state, not the entire history?).
[20:30] <Ampelbein> Noskcaj: I'd do it like in debian, with DEB_CONFIGURE_SCRIPT := ./autogen.sh
[20:31] <Noskcaj> I'll test that now
[20:32] <tarpman> Ampelbein: are you looking for 'bzr checkout --lightweight'?
[20:35] <Noskcaj> Ampelbein, The error still appears
[20:35] <Ampelbein> tarpman: Well, basically the equivalent of git clone --depth=!
[20:35] <Ampelbein> *depth=1
[20:38] <Ampelbein> Noskcaj: mc
[20:38] <Ampelbein> ups
[20:39] <Noskcaj> ?
[20:39] <Ampelbein> clumsy fingers.
[20:45] <Ampelbein> Noskcaj: http://paste.debian.net/77688/ makes it build.
[20:45] <Ampelbein> You probably still had autoreconf.mk in your rules file.
[20:45] <Noskcaj> yeah
[20:47] <Noskcaj> Can i drop the autoreconf build dep then?
[20:47] <Ampelbein> No, it still gets run.
[20:48] <Noskcaj> ok. thanks. I'll just test build it myself then propose the merge
[21:38] <Logan_> how can I add extra usertags with submittodebian? (cc doko)
[21:47] <doko> Logan_, I didn't check, sorry. never used that
[21:47] <Logan_> hmm, alright
[21:47] <Logan_> I might have to tag retroactively for every bug :/
[22:05] <doko> Logan_, see my email, you can do this with a single email to<EMAIL_ADDRESS>[22:05] <Logan_> okay, I'll do that
[22:24] <Noskcaj> Can someone please sync xfce4-weather-plugin from debian stable to precise? it would fix bug 1244629
[22:24] <Noskcaj> which is making it unusable
[22:24] <Logan_> Un momento.
[22:24] <Logan_> Oh, precise?
[22:25] <Noskcaj> yeah
[22:25] <Logan_> You didn't subscribe ~ubuntu-sru.
[22:25] <Logan_> Er. Hold up. There was already an SRU upload?
[22:26] <Noskcaj> no, and no
[22:26] <Logan_> http://launchpadlibrarian.net/162524610/xfce4-weather-plugin_0.7.4-3ubuntu1_source.changes
[22:26] <Noskcaj> i've just subscribed SRU
[22:26] <Logan_> It hasn't been approved yet.
[22:26] <Noskcaj> and it shouldn't be approved. It's broken
[22:26] <Logan_> Oh.
[22:27] <infinity> Broken how?
[22:27] <Noskcaj> which is why i was waiting for -5 to ask
[22:27] <Noskcaj> https://bugs.launchpad.net/ubuntu/precise/+source/xfce4-weather-plugin/+bug/1244629/comments/23
[22:28] <infinity> Noskcaj: We're not going to sync a new upstream from Debian to precise.
[22:28] <Noskcaj> Not a new upstream. two new debian stable uploads
[22:28] <Noskcaj> although i can change that to one ubuntu upload if you'd prefer
[22:29] <infinity> Erm.  0.7.4-3 in precise, versus.  Oh, I see, you mean from wheezy.
[22:30] <infinity> I misread.
[22:30] <Noskcaj> :)
[22:31] <infinity> We, we *could* sync that, though it wouldn't have the LP bug reference in it, which makes it a bit harder to track.
[22:31] <infinity> If someone's willing to verify the SRU as soon as it's built, I wouldn't be against just syncing it.  I just wouldn't want it to get lost/forgotten in proposed forever.
[22:31] <infinity> Noskcaj: Would you be okay with doing a verification pretty much immediately?
[22:32] <Noskcaj> we've got a fair few affected users. We'll find people
[22:32] <Logan_> shouldn't we get rid of the current one in the queue first?
[22:32] <Noskcaj> I think some of the other xubuntu devs have a precise machine
[22:32] <Noskcaj> Logan_, yes
[22:32] <infinity> Logan_: This would supersede that, so meh.
[22:32] <infinity> But I can reject it right now.
[22:32] <Logan_> sweet
[22:35] <infinity> LP hasn't picked up the new wheezy upload yet, so couldn't sync it even if I wanted to.
[22:36] <Noskcaj> ok, let me know when it does and i'll find some people to test


[08:07] <CIA-37> ubiquity: evand * r4795 pygi/ubiquity/frontend/gtk_ui.py: Fix recursively quitting the main loop.
[08:20] <CIA-37> ubiquity: evand * r4796 pygi/ (158 files in 12 dirs): Merge with trunk.
[08:26] <CIA-37> ubiquity: evand * r4797 pygi/ (d-i/update-control debian/control): Tidy up build-deps.
[08:29] <CIA-37> ubiquity: evand * r4798 pygi/ (17 files in 9 dirs): Merge with webcam branch.
[08:33] <CIA-37> ubiquity: evand * r4790 trunk/ (66 files in 18 dirs): Merge PyGI branch. Ubiquity now uses PyGI and GTK+3.
[08:35] <CIA-37> ubiquity: evand * r4791 trunk/ (d-i/update-control debian/control): Fix gtk-dev typo.
[08:44] <CIA-37> ubiquity: evand * r4792 trunk/tests/test_gtkwidgets.py: Use PyGI TimezoneMap in tests.
[08:54] <CIA-37> ubiquity: evand * r4793 trunk/ (6 files in 4 dirs): Fixes from pyflakes.
[08:58] <CIA-37> ubiquity: evand * r4794 trunk/ubiquity/plugins/ubi-timezone.py: One more from pyflakes.
[10:05] <CIA-37> ubiquity: evand * r4795 trunk/ubiquity/im_switch.py: Move im_switch to PyGI.
[10:11] <CIA-37> ubiquity: evand * r4796 trunk/bin/ubiquity-dm: Port ubiquity-dm to PyGI.
[10:18] <CIA-37> ubiquity: evand * r4797 trunk/ubiquity/frontend/gtk_ui.py: Don't use the pygtk glib module.
[13:52] <CIA-37> netcfg: cjwatson * r1260 ubuntu/debian/ (71 files in 2 dirs): merge from Debian 1.68
[15:02] <ev> cjwatson: regarding the work item to filter out passwords in debconf, does this mean you're happy for us to carry the delta in debian bug 357118?
[15:02] <ubot2> Debian bug 357118 in debconf "debconf: exposes passwords in debug messages" [Normal,Open] http://bugs.debian.org/357118
[15:02] <ev> I can't recall the exact conversation at UDS, but I seem to recall the suggestion being to do this in ubiquity itself, which strikes me as far more error-prone
[15:02] <cjwatson> "happy" is too strong
[15:02] <ev> :)
[15:02] <cjwatson> "reluctantly conceding"
[15:02] <ev> lol
[15:02] <ev> okay
[15:03] <cjwatson> I'm actually in complete agreement with joeyh
[15:03] <ev> I don't agree with his solution. Our users and strace users are not in the same pool.
[15:04] <cjwatson> he's the debconf maintainer, not the ubiquity maintainer
[15:04] <ev> absolutely
[15:04] <cjwatson> if ubiquity were using strace in debug mode, I would expect the strace maintainer to say the same thing
[15:05] <ev> fair enough
[15:05] <cjwatson> there is a slight difference I suppose, because debconf has information about the data type
[15:06] <cjwatson> anyway, I don't really want to repeat the argument :-)  if you feel it's necessary, go ahead and upload it
[15:06] <cjwatson> you get to field complaints from joeyh about us carrying a patch that he's explicitly nacked, though
[15:07] <cjwatson> disagreement ought to be expressed by actual conversation on the Debian bug rather than just by uploading the patch, IMO
[15:07] <cjwatson> maybe a conversation will reveal some middle ground?
[15:08] <cjwatson> (so actually, I think it would be better for you to follow up to the Debian bug first, and see what comes of that)
[15:11] <ev> okay
[15:11] <ev> wi
[15:11] <ev> will do
[15:44] <bdmurray> ev: https://code.launchpad.net/~brian-murray/ubiquity/bug-reporting-method/+merge/70793
[15:46] <ev> bdmurray: I agree with Mario's comment.  Could you add a "do it for me" button?
[15:46] <ev> bdmurray: we should chat with mpt to discuss the right UI for this
[15:47] <bdmurray> ev: I agree with his comment too but I've no idea how to do it and would rather we take this incremental step now.
[15:47] <ev> fair enough
[15:47] <ev> merging
[15:48] <CIA-37> ubiquity: evand * r4798 trunk/d-i/update-control: Add dependency for building the keyboard names.
[15:49] <CIA-37> ubiquity: evand * r4799 trunk/ (4 files in 3 dirs): Instead of sending people to +filebug recommend using apport
[15:49] <ev> ugh, I am having no luck at all with a i386 pbuilder
[15:49] <cjwatson> is anyone here in a position to test d-i WPA support?
[15:49] <cjwatson> (not quite yet but soon)
[15:50] <ev> cjwatson: I've got a netbook to hand
[15:50] <ev> I'll be heading home around 6pm though, to avoid confrontation with thuglets.
[15:52] <cjwatson> oh, yeah, absolutely keep safe at the moment :-/
[15:52] <cjwatson> won't be ready by 6pm anyway
[15:52] <cjwatson> working through the tree of blockers
[15:53] <ev> sure - let me know if you haven't found anyone by tomorrow morning and I'll give it a go
[15:53] <cjwatson> I hate landing 6000-line (temporarily) Ubuntu-specific patches :-/
[15:53] <ev> eep
[15:55] <ev> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634107
[15:55] <ubot2> Debian bug 634107 in mount "umount: tries to umount /proc when umounting "proc" without the /etc/mtab entry" [Serious,Open]
[15:59] <cjwatson> oh, there was a patch in the sponsorship queue for that
[15:59] <cjwatson> https://code.launchpad.net/~pr0gg3d/ubuntu/oneiric/util-linux/bug-805886/+merge/70680
[16:00] <cjwatson> I think that's the same?
[16:00] <ev> it is - looks okay, mind if I send that to the archive?
[16:01] <cjwatson> sure
[16:01] <cjwatson> um, sure, I don't mind :-)
[16:01] <cjwatson> English, it sucks
[16:01] <ev> :)
[16:02] <CIA-37> netcfg: cjwatson * r1261 ubuntu/ (41 files in 6 dirs):
[16:02] <CIA-37> netcfg: Merge upstream IPv6 branch (not yet mergeable in Debian since it's
[16:02] <CIA-37> netcfg: waiting for ifupdown 0.7). Thanks to Matt Palmer for the bulk of this
[16:02] <CIA-37> netcfg: work.
[16:08] <CIA-37> netcfg: cjwatson * r1262 ubuntu/ (debian/changelog dhcp.c netcfg-common.c):
[16:08] <CIA-37> netcfg: * Backport from trunk:
[16:08] <CIA-37> netcfg:  - Explicitly ignore some errors to placate -Wunused-result.
[16:10] <CIA-37> netcfg: cjwatson * r1263 ubuntu/ (debian/changelog dhcp.c): Adjust start_dhcp_client to placate -Wformat-security.
[16:12] <CIA-37> netcfg: cjwatson * r1264 ubuntu/ (debian/changelog wpa.c): Handle failure to read a pid from the wpasupplicant pid file.
[16:12] <CIA-37> netcfg: cjwatson * r1265 ubuntu/Makefile: revert temporary -Wno-error=* changes
[19:59] <lool> is it a bug if debootstrap + apt-get install linux-image + grub-pc gives graphics corruption on boot (unusable console), or is it expected that either the installer or the sysadmin sets up the video mode with the output of vbeinfo?
[20:49] <CIA-37> ubiquity: evand * r4800 ubiquity/d-i/update-control: Add timezonemap gir to build deps.
[21:31] <CIA-37> ubiquity: evand * r4801 ubiquity/src/webcam/webcam.c: Actually use a webcam. Move the test image stuff into an exported function.
[22:25] <CIA-37> ubiquity: evand * r4802 ubiquity/ (configure.ac d-i/update-control src/webcam/webcam.c): Add a method to test if a webcam is available using udev.
[23:27] <cjwatson> lool: you should not have to set up the video mode by hand, no
[23:28] <cjwatson> and the installer doesn't do it; GRUB is supposed to select a sensible mode at run-time
[23:28] <cjwatson> lool: oneiric or older?
[23:29] <cjwatson> lool: if pre-oneiric, I'll place a bet that you have a Thinkpad, and either look impressively telepathic or utterly wrong


[00:40] <ahoneybun> any meeting today?
[01:00] <itnet7> Hey there!
[01:02] <chloric> Good evening guys
[01:03] <itnet7> Hey there chloric ! Just got off the phone with govatent
[01:03] <Max-Tither> Good Evening
[01:03] <itnet7> How's it going Max-Tither ?
[01:03] <chloric> Yeah, same here, HE said he can't make it but asked for me to represent Miami
[01:03] <Max-Tither> I am very well. And yourself?
[01:03] <mhall119> hi guys
[01:03] <itnet7> not bad, Thanks!
[01:03] <mhall119> #startmeeting
[01:03] <meetingology> Meeting started Tue Dec  3 01:04:09 2013 UTC.  The chair is mhall119. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[01:03] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[01:03] <itnet7> Hey there mhall119
[01:03] <Max-Tither> :)
[01:03] <mhall119> yay, we have a meeting bot still
[01:03] <chloric> and it's govatent!
[01:04] <itnet7> ;-)
[01:04] <chloric> hey mhall
[01:04] <mhall119> let me pull up the agenda
[01:04] <govatent> Hey guys!
[01:04] <govatent> I'm joining from my mobile on a bad Internet connection. I really did not want to miss the meeting
[01:04] <mhall119> http://loco.ubuntu.com/meetings/ubuntu-us-florida/700/detail/ for those who don't have it
[01:05] <mhall119> govatent: no worries, we'll just assume you say "yes" to everything :)
[01:05] <mhall119> #topic Admin restaffing
[01:05] <mhall119> no?  I thought that worked
[01:06] <mhall119> maybe it just doesn't say anything
[01:06] <itnet7> I can't remember
[01:06] <Michelle_> hey y'all
[01:06] <itnet7> Hey there Michelle_ !!
[01:06] <mhall119> anyway, we currently have myself, itnet7 and dan trevino as Launchpad team admins
[01:07] <mhall119> this is mainly a janitorial position, it gives you the abilityt to update info on Launchpad and loco.ubuntu.com, but it's god to have active folks doing it
[01:07] <mhall119> give the amount of stuff govatent has been doing, I wanted to recommend making him an admin
[01:07] <itnet7> +1
[01:07] <ahoneybun> hey peopl
[01:07] <itnet7> Hey there ahoneybun
[01:08] <mhall119> does anybody have anything they want to talk about on that before I open the vote?
[01:08] <ahoneybun> hey itnet7 mhall119
[01:08] <mhall119> hey ahoneybun, welcome to the team
[01:08] <ahoneybun> mhall119: thanks did not know I was a team now lol
[01:08] <mhall119> govatent: are you happy and willing to be a team admin?
[01:09] <govatent> Cookies. Just for old time sakes
[01:09] <chloric> I can help govatent anyway he needs
 Yes mhall119, I would love to
[01:09] <mhall119> :)
[01:09] <Michelle_> LOL
[01:09] <govatent> Yes.
[01:09] <mhall119> alrighty
[01:09] <mhall119> #vote make govatent a launchpad team admin
[01:09] <meetingology> Please vote on: make govatent a launchpad team admin
[01:09] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[01:09] <Michelle_> +1
[01:09] <meetingology> +1 received from Michelle_
[01:09] <itnet7> +1
[01:09] <meetingology> +1 received from itnet7
[01:09] <chloric> +1
[01:09] <meetingology> +1 received from chloric
[01:09] <mhall119> +1
[01:09] <meetingology> +1 received from mhall119
[01:09] <Michelle_> if my vote counts for anything these days
[01:09] <govatent> There is a huge delay on my end FYI cause my service.
[01:09] <Max-Tither> +1
[01:09] <meetingology> +1 received from Max-Tither
[01:09] <chloric> Aye AYe
[01:09] <itnet7> Michelle_: it always does
[01:10] <mhall119> #endvote
[01:10] <meetingology> Voting ended on: make govatent a launchpad team admin
[01:10] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[01:10] <meetingology> Motion carried
[01:10] <ahoneybun> mhall119: I guess about hangouts?
[01:10] <mhall119> well that was pretty unanimous
[01:10] <mhall119> ahoneybun: that'll be coming up in a later topic
[01:10] <ahoneybun> mhall119: ok
[01:11] <mhall119> #action mhall119 to add govatent as team admin in Launchpad
[01:11] <meetingology> ACTION: mhall119 to add govatent as team admin in Launchpad
[01:11] <mhall119> yay, more work items :)
[01:11] <chloric> perfect
[01:11] <itnet7> lol
[01:11] <mhall119> alright, the next topic is from itnet7
[01:11] <mhall119> #topic New team lead/contact elections
[01:11] <chloric> govagova, just keep me posted on those cookies.
[01:11] <mhall119> itnet7: did you want to introduce this topic?
[01:12] <itnet7> Sure
[01:13] <itnet7> Basically, I have kind of been out of the loop lately with my job and other things that have been going on. I don't really want to stand in the way of any progress. So I thought I would propose the idea if we should elect a replacement that could help set the direction for the team
[01:13] <mhall119> itnet7: can you give folks an idea of what a lead needs to do?
[01:15] <itnet7> The team lead will act as a laison (sp?) between the team and the councils and canonical. They would be subscribed to the Loco-contacts list and would share information that is important to share with the team
[01:16] <govatent> My time is a bit tough with work, but I'd like to nominate myself to help or try it.
[01:16] <mhall119> so the councils, like the community council (which I'm now on) and the loco teams council (which itnet7 is/was on) like to have a point of contact within loco teams in case they need to get information about the team, or push some info out to them
[01:16] <chloric> can it be more than one person?
[01:16] <itnet7> I was thinking that it might be good to potentially form a council
[01:16] <mhall119> it can be whatever we want, really, but having one or a small number is better
[01:16] <chloric> that works
[01:16] <govatent> I like a small number.
[01:17] <mhall119> I'm happy with a council, how about 3 people?
[01:17] <chloric> a small council might be a great idea
[01:17]  * ahoneybun would like to try/help
[01:17] <Michelle_> a triumverite would be probably best in terms of a small number
[01:17] <govatent> I feel given our team members time, a Council would be better.
[01:17] <itnet7> I think it makes the most sense
[01:18] <mhall119> ok, so should we set a timeframe for nominations, and then put those up for a vote?
[01:18] <chloric> vote to have a 3 member council?
[01:18] <mhall119> chloric: we probably should, yeah
[01:18] <govatent> I like that idea
[01:18] <munz> crap sorry im late :)
[01:18] <itnet7> No problem munz
[01:18] <mhall119> #vote should we nominate and vote on a 3-member team council?
[01:18] <meetingology> Please vote on: should we nominate and vote on a 3-member team council?
[01:18] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[01:18] <Michelle_> hey munz
[01:18] <munz> hi :)
[01:18] <mhall119> munz: no worries
[01:18] <chloric> +1
[01:18] <meetingology> +1 received from chloric
[01:18] <mhall119> +1
[01:18] <itnet7> +1
[01:18] <meetingology> +1 received from mhall119
[01:18] <meetingology> +1 received from itnet7
[01:18] <Michelle_> +1
[01:18] <Max-Tither> +1
[01:18] <meetingology> +1 received from Michelle_
[01:18] <meetingology> +1 received from Max-Tither
[01:19] <govatent> +1
[01:19] <meetingology> +1 received from govatent
[01:19] <ahoneybun> +1 ?
[01:19] <meetingology> +1 ? received from ahoneybun
[01:19] <ahoneybun> not sure if I can vote
[01:19] <mhall119> #endvote
[01:19] <meetingology> Voting ended on: should we nominate and vote on a 3-member team council?
[01:19] <meetingology> Votes for:7 Votes against:0 Abstentions:0
[01:19] <meetingology> Motion carried
[01:20] <mhall119> alright, so how do we want to collect nominations? mailing list?
[01:20] <chloric> perfect, vote to fill govatent into all council positions?
[01:20] <mhall119> he might win all 3 seats
[01:20] <itnet7> :-)
[01:20] <chloric> sweet
[01:20] <govatent> Some kind of cloud document to store votes?
[01:20] <govatent> Nominations
[01:21] <mhall119> we can do etherpad or google doc
[01:21] <ahoneybun> govatent: google docs?
[01:21] <ahoneybun> yea
[01:21] <mhall119> ok, I'll set it up and email the team
[01:21] <itnet7> Thanks mhall119
[01:21] <mhall119> #action setup a google doc for collecting team council nominations
[01:21] <meetingology> ACTION: setup a google doc for collecting team council nominations
[01:21] <govatent> I've never used ether pad but I've heard of it and would like to use it
[01:21] <mhall119> #action setup google form to collect voting on nominees
[01:21] <meetingology> ACTION: setup google form to collect voting on nominees
[01:22] <Michelle_> it's kinda cool, govatent
[01:22] <mhall119> alright, itnet7 was there anything else on this topic you wanted to bring up?
[01:22] <mhall119> govatent: you haven't participated in a UDS yet?
[01:22] <govatent> I've done both uds online and in person
[01:23] <mhall119> then you've seen etherpad
[01:23] <itnet7> Not really mhall119 thanks!
[01:23] <mhall119> it's what we use for note taking during UDS sessions
[01:23] <mhall119> alright, next topic
[01:23] <mhall119> #topic Online presence focus
[01:23] <govatent> Ah OK
[01:24] <mhall119> so we have a *lot* of ubuntu-florida stuff all over the internet
[01:24] <mhall119> more than we can keep up to date and active
[01:24] <mhall119> http://loco.ubuntu.com/meetings/ubuntu-us-florida/700/detail/ has a list of just what I could find with some quick googling
[01:24] <govatent> I'd be willing a few days a week help post and update our stuff
[01:24] <chloric> yeah, the Linux Cafe has tons of photos
[01:25] <mhall119> so I wanted to recommend we pick 2 or 3 to focus on
[01:25] <Michelle_> I'll break out the editing fingers, if it'd be helpful.
[01:25] <mhall119> IRC should definitely remain one of our main ways of staying in touch
[01:25] <mhall119> we also have Facebook, Google+, discourse.ubuntu.com, ubuntu forums, etc
[01:26] <mhall119> discourse is new, but very slick, it's like a better version of forums
[01:26] <mhall119> how many of us are on facebook and/or google+?  I'm on both pretty frequently
[01:26] <itnet7> Me too
[01:26] <ahoneybun> same
[01:27] <Max-Tither> I personally like Google+
[01:27] <ahoneybun> same
[01:27] <Michelle_> I facebook like a madwoman
[01:27] <chloric> G+ is my preference, but I also want to start getting on the IRC channel more often
[01:27] <Michelle_> I'm happy to mind the Ubuntu Fl Facebook page, if we have one.
[01:28] <mhall119> ok, so Google+ seems popular, right now we only have a page, but we could change to using a G+ community if we wanted
[01:28] <itnet7> We do michelle I can add you as an admin to the facebook page
[01:28] <mhall119> I'll have to see who's admin on the Facebook page, it's not me, maybe itnet7 or dan?
[01:28] <Michelle_> That'll work, itnet7
[01:28] <mhall119> thanks itnet7
[01:28] <mhall119> #action itnet7 to add Michelle_ as admin of the team Facebook page
[01:28] <meetingology> ACTION: itnet7 to add Michelle_ as admin of the team Facebook page
[01:29] <mhall119> https://plus.google.com/u/0/105170995860560250368/posts is our Google+ page
[01:29] <mhall119> itnet7: are you an admin there too?
[01:29] <itnet7> mhall119: I'll check
[01:30] <itnet7> I just added Michelle
[01:30] <itnet7> to facebook
[01:30] <ahoneybun> I would like to help if I can
[01:30] <chloric> any way we can get a custom URL?
[01:30] <mhall119> ahoneybun: content will always be needed
[01:30] <ahoneybun> yea
[01:31] <Michelle_> got it, itnet7
[01:31] <mhall119> ok, so IRC, Facebook, Google+, is everybody happy with focusing on those 3?
[01:31] <mhall119> we can use discourse too, and see if we like it
[01:31] <itnet7> It seems I am listed as the owner of the google+ team page
[01:32] <mhall119> itnet7: can you add me as an admin there?
[01:32] <itnet7> but I have to figure out how to create roles or give rights to others
[01:32] <mhall119> since I'm on G+ a lot
[01:32] <itnet7> yeah
[01:32] <mhall119> thanks
[01:32] <itnet7> I will as soon as I see how ;-)
[01:32] <govatent> I love to follow and find Linux news
[01:32] <mhall119> whomever is elected to the council we should add as admins too
[01:32] <Michelle_> mhall119 and I can cross-post as necessary, too... since we share a living room.
[01:32] <mhall119> :)
[01:33] <govatent> I've found that reddit/Ubuntu and /Linux have good stuff in community news
[01:33] <mhall119> yeah, anything you find that the team might be interested in we should post on those outlets
[01:34] <Michelle_> govatent: if you'll email/IRC/whatever me links, I'll be sure they get FB crossposted, too.
[01:34] <itnet7> mhall119: I just invited you to the team page, I think once you join I can make you a moderator
[01:34] <govatent> Can we create a location so team members can submit content for posting?
[01:34] <Michelle_> oh, that would be a good idea.
[01:34] <munz> nice^
[01:34] <govatent> With approval
[01:34] <mhall119> oh, a community now \o/
[01:34] <munz> :)
[01:34] <mhall119> https://plus.google.com/u/0/communities/116790741559809422077 anybody can join that now and post to it
[01:35] <mhall119> govatent: we have the mailing list, and anybody can post to the G+ community or on the Facebook page
[01:35] <mhall119> then one of us can share it *as* the page to spread it wider
[01:35] <govatent> Alright
[01:35] <munz> nice mhall119
[01:36] <govatent> Btw, my phone is going to die soon
[01:36] <mhall119> first thing I'll post is the log of this meeting :)
[01:36] <mhall119> govatent: you know what I'll recommend
[01:36] <mhall119> ok, last topic!
[01:36] <mhall119> #topic Recurring meetings
[01:37] <mhall119> this has been great, I'm really excited to have something going on across the whole team again
[01:37] <mhall119> thanks everybody who came tonight
[01:37] <govatent> If I disconnect it's cause my phone died.
[01:37] <mhall119> to keep things rolling, we should setup regular meetings again
[01:37] <Michelle_> Be sure to give it a proper funeral, govatent
[01:37] <munz> lol
[01:38] <mhall119> revive it, zombie phone!
[01:38] <Max-Tither> haha
[01:38] <munz> hehe
[01:38] <govatent> If I may before we talk about reoccurring meetings, can we also mention the Linux cafe.
[01:38] <govatent> Wanna say it now before I die
[01:38] <mhall119> govatent: sure, but only because you're phone is dying
[01:38] <itnet7> ;-)
[01:38] <mhall119> death-bed promotions
[01:38] <Michelle_> govatent's last stand!
[01:39] <mhall119> govatent: ?
[01:39] <mhall119> still with us?
[01:39] <govatent> We can do it after. Chloric can tell you guys about it.
[01:39] <mhall119> ah, ok
[01:39] <mhall119> so, recurring meetings, monthly?  bi-weekly? weekly?
[01:39] <govatent> It's to much to type on my phone.
[01:40] <govatent> Bi weekly is my vote
[01:40] <mhall119> govatent: I'll make an open topic after this one
[01:40] <ahoneybun> weekly or bi
[01:40] <chloric> what's up?
[01:40] <itnet7> govatent: is the indiegogo campaign still going on for PLC?
[01:40] <mhall119> weekly might be too much, we've managed to have one all year in 2013
[01:40] <munz> monthly or bi
[01:41] <munz> monthly
[01:41] <Michelle_> I suggest monthly, until we get our tushes in gear and have need for more frequently.
[01:41] <munz> yes
[01:41] <mhall119> how about the first-monday of the month?  that would put the next one Jan 5th
[01:41] <mhall119> same time and place
[01:41] <munz> yes
[01:41] <Michelle_> works
[01:41] <mhall119> monday's seemed to work best when I polled people on the mailinglist
[01:41] <ahoneybun> yea I think
[01:42] <govatent> Alright
[01:42] <chloric> that works
[01:42] <mhall119> alright, I'll get it on loco.ubuntu.com
[01:42] <mhall119> anybody can add agenda items to it between now and then, you just need to log in using Ubuntu SSO
[01:43] <chloric> wait
[01:43] <chloric> Jan 5th is a sunday
[01:43] <chloric> you mean the 6th?
[01:43] <mhall119> yeah, I can't read calendars evidently
[01:43] <mhall119> http://loco.ubuntu.com/meetings/ubuntu-us-florida/706/detail/
[01:43] <Michelle_> Well.
[01:43] <chloric> oh ok
[01:43] <chloric> perfect
[01:44] <mhall119> also, we have Google Hangouts available now, which would let us use audio/video conferencing instead of IRC
[01:44] <mhall119> is there any interest in using that for team meetings instead of IRC?
[01:45] <govatent> Alright guys. I need to hop off.
[01:45] <mhall119> IRC has the benefit of being logged, we get this lovely meetingology bot, and we don't need to wear pants
[01:45] <itnet7> I actually like using g+ alot for meetings
[01:45] <govatent> Don't forget about me! Chloric or itnet7 please tell the group about the stuff we've done in Milan
[01:45] <Michelle_> I vote no pants.
[01:45] <itnet7> ROFL
[01:46] <govatent> And I do like both ideas
[01:46] <munz> :)
[01:46] <mhall119> govatent: someone will
[01:46] <chloric> General meetings could be done of hangouts, but shouldn't board meetings on IRC?
[01:46] <mhall119> there isn't much difference for us right now
[01:46] <chloric> oh ok
[01:46] <chloric> then nvm
[01:46] <govatent> Except the pants
[01:46] <Max-Tither> We could use both for those who can not get on hangouts.
[01:47] <mhall119> ok, I'll make a note to start a hangout next time and we'll give it a test-run
[01:47] <Max-Tither> But IRC does have the benefit of it being logged
[01:47] <munz> and no pants
[01:47] <mhall119> alright, that's it for the official agenda
[01:47] <itnet7> We can record the hangouts right?
[01:48] <mhall119> #topic open mic
[01:48] <mhall119> itnet7: yes, but they're public on YouTube forever and ever after
[01:48] <itnet7> OH
[01:48] <itnet7> nvm
[01:48] <itnet7> ;-)
[01:49] <mhall119> yeah
[01:49] <mhall119> chloric: ok, now's your time to tell us all about PLC
[01:49] <chloric> Oh ok
[01:49] <chloric> sure
[01:50] <chloric> I find it to be a gathering place to share ideas and actually share technologies. They have nearly monthly capture the flag competitions and a wide variety of meetings too
[01:51] <chloric> the owners and most of the patrons are very very approachable and eager to teach and spread linux as a platform
[01:52] <mhall119> for those that don't know: http://planetlinuxcaffe.com/
[01:52] <mhall119> it's a cool little place in Miami that's linux-themed everything
[01:53] <mhall119> they've hosted a number of in-person meetups that chloric and govatent organized
[01:53] <chloric> There are plenty of individual interests at the cafe and competing opinions, but everyone is open to Linux in many ways. sure we argue over best DE or distro or whatnot, but everyone is using linux to some extent regardless of distro
[01:53] <munz> i looked at the website it looks cool
[01:53] <chloric> yeah, we've had a lot of events there
[01:53] <mhall119> chloric: do you register those events on loco.ubuntu.com?
[01:53] <chloric> it's awesome. they have plenty of gadgets to play with and 5 computers to tinker with
[01:53] <chloric> a few server racks too
[01:54] <ahoneybun> I for sure want to go there sometime
[01:54] <itnet7> The owners have really supported the Florida Team, they have promoted release parties, and made custom cakes for everyone to help celebrate the release parties that have been held there!
[01:54] <Michelle_> mhall119: roadtrip!
[01:54] <chloric> Yeah, itnet has come to a few as well
[01:55] <chloric> it's always awesome seeing ya itnet
[01:55] <itnet7> thanks chloric
[01:55] <munz> nice, can you just come in any time during biz hours? and they have coffee and such?
[01:55] <itnet7> munz: yeah
[01:55] <chloric> they have coffee, cakes, snacks, drinks and sandwiches
[01:56] <munz> nice, soy milk?
[01:56] <mhall119> itnet7: chloric: btw, if you guys want to get money for food or drinks at these events, we have some community budget from Canonical you can request
[01:56] <itnet7> They even allow you to bring in Pizza from Dominos
[01:56] <mhall119> http://community.ubuntu.com/help-information/funding/
[01:56] <chloric> it's easy to spend between 5 and 10 bucks
[01:56] <itnet7> Awesome mhall119 !
[01:56] <ahoneybun> I don't see any meetings this month for Ubuntu
[01:56] <chloric> mhall119: really?
[01:56] <mhall119> chloric: yup
[01:56] <chloric> mhall119: that's good to know. we'll have to keep that in mind for 14.04
[01:57] <itnet7> ahoneybun: we were having monthly meetings, but I think things have been really busy lately for the organizers
[01:57] <mhall119> alright, well we've used up the full hour, is there anything else you guys want to talk about?
[01:58] <itnet7> No, Thanks mhall119 so much for getting the ball rolling again!!
[01:58] <Michelle_> mhall119: do you want to make an announcement about our tentative Qimo plans?
[01:58] <mhall119> itnet7: happy to do it, want to get the Florida team rocking again
[01:58] <mhall119> sure
[01:58] <itnet7> Heck yeah!
[01:58] <chloric> this'll be awesome too
[01:58] <itnet7> Oh, QIMO PLANS woohoo!!
[01:58] <mhall119> so for those that don't know, Michelle_ and I made an ubuntu-based distro for kids a few years ago called Qimo
[01:58] <Michelle_> yes, sir, itnet7
[01:59] <mhall119> and we want to reboot that too, and plan to put together a new release to coincide with 14.04
[01:59] <itnet7> Excellent mhall119 !
[01:59] <mhall119> it'll still be Ubuntu-based, but we're going to switch it to Unity instead of Xfce, because it's close to what Qimo's old UI was, and will make it much easier to maintain
[01:59] <itnet7> and Michelle_ of course ;-)
[01:59] <mhall119> if anybody is interested in helping, email me<EMAIL_ADDRESS>[01:59] <chloric> mhall119: you should come down and do a QIMO event alonside an Ubuntu gig
[01:59] <Michelle_> mhall119's doing the hard work.  I'm just gonna do the promotion!
[02:00] <mhall119> chloric: maybe some time, it's a pretty long drive and we're not all as crazy as govatent :)
[02:00] <mhall119> but we can maybe make a weekend of it
[02:00] <chloric> true lol
[02:00] <Michelle_> yes, we can.
[02:00] <Michelle_> ::determined face::
[02:00] <chloric> awesome!
[02:00] <itnet7> That would be awesome
[02:01] <mhall119> alright, I'm going to wrap this up and post the logs
[02:01] <mhall119> #endmeeting
[02:01] <meetingology> Meeting ended Tue Dec  3 02:01:40 2013 UTC.
[02:01] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-us-fl/2013/ubuntu-us-fl.2013-12-03-01.04.moin.txt
[02:01] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-us-fl/2013/ubuntu-us-fl.2013-12-03-01.04.html
[02:01] <itnet7> If you were to go down there, you would definitely gain some new supporters
[02:01] <chloric> agreed.
[02:01] <mhall119> thanks again to everybody who came, and let's not let this channel get so quiet again :)
[02:02] <Michelle_> chloric: I'll be in touch, maybe we can organize something end-of-Feb-ish.
[02:02] <mhall119> I'm connected 24/7, so if anybody ever wanted to get in touch with me you can ping me here (or use the email above)
[02:02] <chloric> itnet7: any more events going on in Melbourne in the next few months?
[02:03] <itnet7> chloric: I am planning on trying to get some things cooking again
[02:03] <mhall119> anybody on the team can add events to our calendar on http://loco.ubuntu.com/teams/ubuntu-us-florida/ too, that helps let people see what's going on locally
[02:03] <itnet7> chloric: You guys are always welcome to visit regardless ;-)
[02:03] <Michelle_> itnet7, I'm happy to help organize, too.
[02:03] <itnet7> mhall119: absolutely
[02:04] <itnet7> Michelle_: Sweet \o/
[02:04] <chloric> govatent and I will have to make a trip of it
[02:04] <Michelle_> I'll bring cookies.
[02:04] <itnet7> Nom
[02:04] <chloric> govatent has cookies on lockdown
[02:05] <itnet7> chloric: is that indiegogo thing still going on for Planet Linux Caffe?
[02:05] <itnet7> I guess not
[02:05] <itnet7> I just went to the link
[02:06] <chloric> Oh, I haven't kept up with that
[02:06] <chloric> sorry
[02:07] <itnet7> I was hoping they would have been able to raise more ;-(
[02:07] <Michelle_> Well, maybe we can help with that over the next year.
[02:08] <Max-Tither> Good Night everyone. Great meeting.
[02:08] <itnet7> gnight Max-Tither
[02:08] <chloric> PLC's hackerspace is competing with two other hackerspaces in Miami
[02:09] <Michelle_> We've got a hackerspace in Tampa, too, mhall119 , we should touch base with.
[02:10] <mhall119> didn't know that
[02:10] <Michelle_> They're the one that built the TARDIS at mosi
[02:11] <munz> Michelle_: i did not know that
[02:11] <chloric> oh, that sounds awesome. hackerspaces are creeping up in cities all over the world
[02:11] <Michelle_> that's me.  Don't mind.
[02:16] <chloric> alrighty
[02:17] <itnet7> I didn't realize danmery was here
[02:17] <chloric> take care guys, switching distros
[02:17] <itnet7> see you later chloric !
[02:17] <itnet7> gnight all!
[02:17] <mhall119> chloric: good luck :)
[02:17] <chloric> itnet7: you should check out Manjaro if you have the chance
[02:18] <itnet7> chloric: it looks very clean
[02:18] <chloric> mhall119: just restarting into ubuntu from manjaro
[02:18] <itnet7> I finally have an internet connection at my house that is over 2 Mbps
[02:19] <itnet7> crappy bhouse router
[02:19] <itnet7> they switched it today!
[02:19] <mhall119> chloric: ah, thought you were installing something new
[02:19] <MichelleQ> woo, not sucky internet, itnet7
[02:20] <itnet7> It just stinks paying for a "Turbo" connection and not even able to watch a low resolution 60 second video without it buffering like 100 times
[02:21] <itnet7> :-P
[02:23] <MichelleQ> ack, no
[02:23] <MichelleQ> we switched to Fios a while back - decently satisfactory.
[02:54] <itnet7> bbl
[17:27] <mhall119> govatent: you've been added as an admin to the Launchpad team
[17:27] <govatent> mhall119, alrighty
[17:33] <mhall119> govatent: would you be willing to be on the team council too?
[17:36] <govatent> I would
[17:38] <mhall119> thanks