[02:04] <klepas> artnay_: ping
[02:04] <klepas> artnay: ping
[10:01] <artnay> hey guys
[10:02] <artnay> have you seen what has happened with wiki?
[10:03] <artnay> https://wiki.ubuntu.com/?action=fullsearch&context=180&value=artwork&titlesearch=Titles
[10:03] <artnay> henrik has been quite busy
[10:08] <artnay> I urge you all to check the new pages
[10:10] <artnay> how come I find it to be much more complicated now... it only focuses on ubuntu and leaves out all other *buntu flavours
[03:42] <klepas> artnay_: ping


 I don't like the wallpaper 😐
 .___.
 🙃
 @tsimonq2, Seems nice!
 I think so :D
 Wallpaper sucks, but... Its easy to fix
 XD
 Just  kidding, i like the default Lubuntu wallpapers
 hehehehehehehehehe :)
 There is a place with al the past  wallpapers?
 @Wolfenprey, @VikingRedwolf would know.
 Aye, tis
 https://lubuntuofficial.deviantart.com/
 (Document) http://vps.tsimonq2.net:9090//file_1411.mp4
 😉
 @tsimonq2, looks clean is that qterminal or lxterminal one?
 @ShiBonCip, QTerminal


[21:46] <airurando> It's far too quiet in here
[21:54] <airurando> looking forward to the 14.04 release all the same......


[00:35] <cnd> qt may be easier than I thought to forward port
[00:35] <cnd> I'm still not crazy about the patch, it's rather hairy due to a bunch of #ifdefs
[00:35] <cnd> but there really isn't that much that changed between the two implementations
[00:36] <cnd> and the bits that did change are easy to fix
[00:37]  * cnd is running a test build of qt on behemoth
[00:44] <RAOF> Yay behemoth!
[00:44] <RAOF> At least that quad core monstrosity is good for something :)
[03:49] <cnd> when I upgraded behemoth this morning, it installed a bunch of i386 packages
[03:49] <cnd> I have no idea why
[03:50] <RAOF> Either breakage, or dependencies that dropped out of ia32-libs?
[03:53] <RAOF> apt can now sometimes do that if something's uninstallable on amd64, but a multi-arch: foreign alternative is installable.
[03:58] <cnd> dunno
[03:58] <cnd> I've done a lot to behemoth
[03:58] <cnd> and I may have only ever wiped it once since I've had it
[03:58] <cnd> so there's bound to be a lot of cruft
[03:58] <cnd> on the plus side, I've got qt and multitouch working!
[03:59] <cnd> it was much easier than I thought it would be
[03:59] <RAOF> Sweet!  That was fast.
[03:59] <RAOF> Hows about a synaptics that doesn't reset to (0,0) at infuriatingly frequent, yet seemingly random, intervals? :)
[03:59] <cnd> I'll be pushing it in a few mins
[03:59] <RAOF> Or, even better, do you see that behaviour?
[03:59] <cnd> heh, you'll have to wait a bit on that
[03:59] <cnd> I don't even have a rebuilt synaptics installed yet
[04:00] <cnd> and because I partially upgraded qt on my system to test
[04:00] <RAOF> You haven't upgraded from the staging PPA?
[04:00] <cnd> it would be easier for me to just try it tomorrow
[04:00] <cnd> apt-get is useless if it thinks your packages are in a broken state
[04:00] <cnd> it needs a "I know what I'm doing, just install these other packages please" option
[04:01] <RAOF> Yeah, it's sucky that way.
[04:02] <RAOF> The ppa is, at least, fully installable.
[04:03] <cnd> with the updated qt, unity-2d starts up
[04:03] <cnd> though I'm missing the dock
[04:03] <cnd> any ideas why that would be?
[04:03] <RAOF> No idea - I *thought* that was missing geis, because that's what would happen with the non-multitouch frankenserver.
[04:04] <RAOF> Is unity-2d-launcher spinning at 100% cpu still?
[04:04] <cnd> well, geis still won't work with this multitouch frankenserver
[04:04] <cnd> oh, it is
[04:04] <cnd> compiz does that too
[04:04] <cnd> so unity 3d is useless
[04:04] <cnd> and unity 2d's launcher is useless
[04:05] <cnd> gnome classic with effects is also useless due to the same compiz issue
[04:05] <RAOF> GNOME Do, however, LIVES ON!
[04:05] <cnd> heh
[04:05] <cnd> I'm on vacation now though
[04:05] <cnd> I'll be back on the 3rd
[04:06] <RAOF> Like essentially everyone else :)
[04:06] <cnd> I'm just uploading qt, and I'll send out an email to ubuntu-devel and ubuntu-x about the x-staging ppa
[04:06] <RAOF> Doing anything interesting?
[04:06] <cnd> not much
[04:06] <RAOF> Excellent!
[04:06] <cnd> heh
[04:06] <cnd> playing zelda skyward sword I guess
[04:06] <RAOF> That can be the most fun.
[04:06] <cnd> yeah
[04:06] <cnd> less stress
[04:07] <cnd> urgh, the qt4-x11 tarball is huge
[04:07] <RAOF> It's ~200MB, isn't it?
[04:07] <RAOF> Don't try building it on a tmpfs :)
[04:08] <RAOF> I'll be doing something similar, but with jml's bucks party, and running a one-shot D&D campaign while jml's here thrown into the middle :)
[04:08] <cnd> 215 MB
[04:08] <cnd> I have no clue what any of that is
[04:08] <cnd> I do know what a jml is :)
[04:08] <cnd> but the rest...
[04:09] <RAOF> Buck's party not familiar to you?
[04:10] <RAOF> I mean, it's not like *I* had one, but I thought they were pretty universal across UK/US-derived cultures.
[04:11] <cnd> no, I have no clue what a "Buck's party" is
[04:11] <cnd> oh, bachelor party!
[04:11] <cnd> yeah, I got it
[04:13] <RAOF> Perhaps more commonly known as a "buck's night", to go with the feminine "hen's night". :)
[04:14] <cnd> yeah, those terms didn't make it across the atlantic
[04:14] <cnd> we have bachelor and bachelorette parties
[04:14] <cnd> don't know if I spelled the latter correctly
[04:15] <RAOF> Heh.
[04:26] <cnd> RAOF, I'm getting this error: File qt4-x11_4.7.4.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents.
[04:26] <cnd> when I try to dput to the ppa
[04:26] <cnd> I tried downloading the exact orig tarball from precise
[04:26] <cnd> and then rebuilt the source package
[04:26] <cnd> it didn't even upload an orig.tar.gz, since the archive already has it
[04:26] <cnd> any ideas?
[04:29] <bjsnider> do -S -sd
[04:29] <cnd> bjsnider, what does that do?
[04:30] <bjsnider> it uploads without uploading the tarball
[04:30] <bjsnider> it assumes the tarball is already there
[04:30] <bjsnider> debuild -S -sd
[04:30] <cnd> yeah, the second time it didn't upload the tarball
[04:30] <cnd> the first time it did
[04:30]  * cnd wonders if the tarball is stuck in the ppa
[04:31] <bjsnider> what happened the second time?
[04:31] <cnd> same error came back
[04:31] <bjsnider> impossible
[04:31] <cnd> I have the emails :)
[04:32] <bjsnider> you did an -sd instead of an -sa, and dput the changes file, and got that error?
[04:33] <cnd> yeah
[04:33] <bjsnider> and you need to do the -sd against the tarball it's talking about, in precise, not your own tarball
[04:33] <cnd> correct
[04:33] <cnd> I downloaded the orig tarball from launchpad from the precise package overview page to be sure
[04:33] <bjsnider> that's one i have't seen before
[04:34] <cnd> I've seen weird issues like this before
[04:34] <cnd> I'm guessing it's a bug somewhere in soyuz, and someone may need to manually delete the tarball from the servers
[04:34] <bjsnider> did you ask in #launchpad?
[04:35] <cnd> I am right now :)
[04:35] <bjsnider> you could do a bit of trickery and add +0 to the version number, thus creating a unique tarball
[04:36] <bjsnider> but only if it's being superseded by a newer version soon enough
[04:36] <cnd> yeah, I'm not sure that will happen
[04:36] <cnd> ever in precise
[04:47] <cnd> bjsnider, it was still building against the bad tarball in ../build-area
[04:47] <cnd> I had only replaced the tarball in ../
[04:48] <bjsnider> so it worked?
[04:48] <cnd> still building
[04:50] <cnd> uploading now
[04:52] <cnd> ok, it worked finally
[04:53] <bjsnider> cool
[04:54] <cnd> I don't like how bzr bd copies the orig tarball into the build-area
[04:55] <cnd> I can kinda see why they do it
[04:55] <cnd> but I think it just makes things more confusing when there are issues
[04:55] <cnd> they could just symlink and be done with it
[04:55] <cnd> anyways, I'm done
[04:56] <cnd> I'm off for the holidays, but I'll troll, as always :)
[07:08] <tjaalton> oh new qt didn't fix compiz
[07:09] <tjaalton> let's install gnome-shell then :)
[07:15] <tjaalton> yeah it works
[07:16] <ricotz> cnd, hi
[07:17] <cnd> hi
[07:17] <cnd> tjaalton, new qt isn't finished building yet
[07:17] <cnd> but yeah, compiz seems borked
[07:17] <ricotz> cnd, the inputstack of xserver git master and the 1.11+input2.2 should be "indentical", right?
[07:18] <cnd> that's the theory :)
[07:18] <ricotz> cnd, could look at this https://launchpadlibrarian.net/88180194/buildlog_ubuntu-precise-amd64.xf86-input-wacom_1%3A0.12.0-0ubuntu3_FAILEDTOBUILD.txt.gz
[07:18] <cnd> it depends on whether you count the new InputOption API
[07:18] <cnd> yeah...
[07:18] <tjaalton> ricotz: wacom hasn't been ported
[07:19] <ricotz> cnd, ah ok
[07:19] <cnd> that input option api was not backported from 1.12
[07:19] <ricotz> tjaalton, wacom worked fine with abi 15
[07:19] <cnd> I couldn't be sure that it would not cause ABI/API issues with other drivers
[07:19] <ricotz> cnd, i see
[07:19] <cnd> the whole option parsing API changed, IIRC
[07:19] <cnd> not just for input modules
[07:20] <ricotz> cnd, wouldnt it be better the pull this in too rather than creating a "new" abi which isnt abi 16?
[07:21] <cnd> ricotz, we can't modify any ABI that would affect video drivers
[07:21] <cnd> i.e. the 1.11 nvidia and fglrx drivers must still work
[07:21] <cnd> I'm worried that the new option abi would conflict
[07:21] <ricotz> alright
[07:22] <ricotz> but the reported abi will be 16?
[07:22] <cnd> and, it's a little outside of the scope of what we really need to backport
[07:22] <cnd> yeah
[07:22] <ricotz> ok
[07:22] <cnd> in wacom and one other driver (I think synaptics), we might have to dance around the input abi
[07:22] <ricotz> synaptic works
[07:23] <ricotz> https://launchpad.net/~ricotz/+archive/unstable/+packages
[07:23] <ricotz> i havent rebuild them all yet
[07:23] <cnd> yeah, it might not be forward ported yet
[07:23] <tjaalton> ricotz: wacom d54d936146fa58fb10a1b6839e1413671f96f86e perhaps?
[07:25] <ricotz> tjaalton, could be
[07:25] <ricotz> probably all commits since 0.12 would be needed
[07:33] <tjaalton> oh strong work dude, removed the wrong disk from a live system :P
[07:35] <tjaalton> ah, no i didn't, thought the one would've been wd blue instead of black..


[00:29] <Amoz> cjohnston, have you worked with the django builtin auth stuff?
[01:11] <Ronnie> Amoz: maybe i can help
[01:36] <Amoz> Ronnie, I'm trying to do the usual session stuff, e.g. print "Logged in as $user"
[01:37] <cjohnston> Amoz: look in either website_base.html or base.html
[01:38] <cjohnston> i forget which
[01:40] <Amoz> ubuntu_website?
[01:40] <Amoz> or common?
[01:41] <Amoz> there it was
[01:41] <cjohnston> website_base is ubuntu_website
[01:41] <Amoz> common base.html
[01:41] <Amoz> thanks
[01:41] <cjohnston> base is common
[01:42] <Amoz> user.is_authenticated
[01:42] <Amoz> I love you cjohnston
[01:42] <Amoz> I've been trying to find this for... an hour or something
[01:42] <Amoz> the django docs aren't really explicit with that stuff
[01:42] <cjohnston> :-)
[01:42] <cjohnston> I've had a few beers
[01:43] <cjohnston> I may actually be helpful
[01:44] <Amoz> cjohnston, lol
[01:44] <Amoz> Ballmer peak
[01:45] <Amoz> http://xkcd.com/323/
[01:46] <cjohnston> very nice
[01:47] <Amoz> I'm playing around with django and bootstrap right now
[01:47] <cjohnston> Amoz: I think I got all the CSS done... I couldn't wait any longer..
[01:47] <cjohnston> summit.chrisjohnston.org
[01:48] <cjohnston> I need to get the new create meeting feature pushed for testing
[01:48] <cjohnston> then we can look at the other changes
[01:49] <Amoz> cjohnston, yeah what happened with imbrandon ?
[01:49] <cjohnston> he got busy
[01:50] <Amoz> oh
[01:50] <Amoz> anyway
[01:50] <Amoz> what code is merged there?
[01:50] <Amoz> the footer is weird
[01:51] <Amoz> probably a div missing or something
[01:51] <cjohnston> I agree..
[01:51] <cjohnston> care to look into it?
[01:51] <cjohnston> I'm working on my meeting stuff
[01:51] <Amoz> not now unfortunately
[01:51] <Amoz> it's almost 3AM here
[01:51] <cjohnston> ok
[01:51] <Amoz> I need to sleep ^^
[01:51] <cjohnston> sounds good
[01:52] <Amoz> did you merge my branch?
[01:52] <cjohnston> which branhc
[01:52] <cjohnston> branch
[01:52] <cjohnston> i merged your stuff in a couple times
[01:52] <Amoz> weird
[01:52] <cjohnston> so which commit i guess is the more correct question
[01:52] <Amoz> mine shouldn't have the weird footer afaik
[01:52] <cjohnston> it could be something I changed that reversed it
[01:53] <Amoz> cjohnston, http://amoz.dyndns.org:8080/uds-p/
[01:53] <cjohnston> ya.. i dont know what the difference is
[01:53] <cjohnston> and i need go get this meeting stuff pushed for testing
[01:53] <Amoz> okay
[01:53] <cjohnston> if you figure it out tomorrow, let me know and ill make the change
[01:54] <Amoz> yeah I'll try :)
[01:54] <cjohnston> ty
[01:54] <Amoz> gnite guys :)
[01:54] <cjohnston> g'nite
[15:03] <AlanBell> history |grep runserver
[15:03] <AlanBell> no, not this window :)
[15:11] <AlanBell> so remind me how we start summit these days? ./manage.py runserver ubuntusettings.py or something like that?
[15:13] <cjohnston> python manage.py runserver --settings ubuntu_setting
[15:13] <cjohnston> python manage.py runserver --settings ubuntu_settings
[15:16] <AlanBell> thanks
[15:16] <cjohnston> np
[15:16] <cjohnston> whatcha workin on AlanBell
[15:17] <AlanBell> etherpad lite
[15:17] <cjohnston> cool
[15:17] <AlanBell> bother, I think I broke my summit.db
[15:17] <cjohnston> one sec
[15:17] <cjohnston> http://ubuntuone.com/2xpQW5q06Yp26f47lboHmb
[15:19] <AlanBell> no such table: schedule_summit
[15:19] <cjohnston> migrate
[15:19] <cjohnston> ./manage.py migrate
[15:22] <AlanBell> hmm, list index out of range now, this is back where I was before
[15:23] <cjohnston> AlanBell: http://<IP_ADDRESS>:8000/admin
[15:23] <cjohnston> admin/password iirc
[15:23] <cjohnston> Click on "summit"
[15:23] <cjohnston> click on uds-p
[15:23] <cjohnston> For "sites" select summit.ubuntu.com
[15:24] <cjohnston> save
[15:24] <AlanBell> no such table: django_site
[15:24] <cjohnston> ./manage.py syncdb
[15:24] <cjohnston> ./manage.py migrate
[15:27] <AlanBell> http://alanbell.libertus.co.uk:8000/admin/
[15:31] <cjohnston> ./manage.py shell
[15:31] <cjohnston> from common import menu
[15:31] <AlanBell> ImportError: cannot import name menu
[15:33] <cjohnston> from common import Menu
[15:33] <cjohnston> Menu.objects.create(site_id=1, name='uds', slug='uds')
[15:33] <cjohnston> exit()
[15:34] <AlanBell> that doesn't work either :(
[15:34] <AlanBell> from common import <tab> returns
[15:34] <AlanBell> admin               forms               migrations          templatetags        utils
[15:34] <AlanBell> context_processors  management          models              tests               views
[15:34] <cjohnston> try from common.models import Menu
[15:35] <AlanBell> yup, that works
[15:42] <AlanBell> admin console works now, I think I can get the rest up soon
[15:51] <AlanBell> ok, it is up now, thanks cjohnston
[15:55] <cjohnston> np AlanBell
[15:56] <cjohnston> I clearly need to update my db
[15:56] <AlanBell> yeah, I think the installation instructions need a bit of a tweak, it doesn't mention the ubuntu_settings bit, just make run which doesn't work any more
[15:57] <nigelb> AlanBell: Please submit patch. Instructions are in docs folder.
[15:57] <AlanBell> but I have a container running now, so I am happy
[15:57] <nigelb> and they get rendred to summit.rtfd.org.
[15:58] <AlanBell> ooh, nice
[15:58] <AlanBell> oh, those are right
[15:59] <AlanBell> INSTALL and requirements.txt are wrong
[16:00] <nigelb> then add a note in install to look at summit.rtf.org
[16:00] <nigelb> and fix what needs fixing in requirements.txt
[16:00] <AlanBell> yeah, that sounds reasonable
[16:01] <nigelb> I've been liking readthedocs project for how nicely they render sphinx based documentation.
[16:02] <nigelb> also, readthedocs itself is built on django and is open source.
[16:20] <cjohnston> whats wrong in requirements.txt
[16:20] <cjohnston> INSTALL isnt actually wrong, but Make hasn't been updated to work with the new sites support
[16:32] <AlanBell> there might not be anything wrong in requirements.txt
[16:32] <nigelb> AlanBell: requirements.txt is not for humans.
[16:49] <AlanBell> hmm, wonder what that says about me
[17:14] <Amoz> AlanBell, hmm, you're not human?
[17:14] <AlanBell> *mostly* human
[17:14] <nigelb> he's half chicken :P
[17:14]  * nigelb runs
[17:14] <Amoz> half bell
[17:14] <Amoz> it seems
[17:15] <Amoz> okay, django drives me nuts
[17:15] <Amoz> ViewDoesNotExist at /calendar/
[17:15] <Amoz> Could not import workspaces.views. Error was: cannot import name HTMLCalendar
[17:16] <Amoz> I'm trying to make HTML cal stuff


[10:15] <lcpfnvcy> how
[10:16] <lcpfnvcy> *hi
[10:16] <lcpfnvcy> need some help
[10:16] <lcpfnvcy> I have a cloud-init config file used to create a vm
[10:16] <lcpfnvcy> I'm trying to write a file into a /home/user directory
[10:16] <lcpfnvcy> but as the owner: user
[10:16] <lcpfnvcy> but it keeps being owned by root
[10:16] <lcpfnvcy> any ideas why ?
[10:16] <lcpfnvcy> this is with the write_file module
[10:17] <lcpfnvcy> write_files:
[10:17] <lcpfnvcy>   - path: /home/user/storage.cfg
[10:17] <lcpfnvcy>     permissions: '0755'
[10:17] <lcpfnvcy>     owner: "user:user"
[10:17] <lcpfnvcy>
[10:17] <lcpfnvcy> it's a simple text file
[10:18] <tribaal> lcpfnvcy: I suspect you're hitting https://bugs.launchpad.net/cloud-init/+bug/1486113
[10:18] <lcpfnvcy> ok
[10:19] <lcpfnvcy> looks like that is it
[10:19] <lcpfnvcy> I can change the ownership via runcmd then ?
[10:19] <tribaal> I suspect you could yes - but I'm not sure when runcmd runs relative to the other modules
[10:20] <tribaal> maybe somebody else can chime in later (a lot of people on this channel are on American timezones)
[10:21] <lcpfnvcy> ah ok
[10:22] <lcpfnvcy> runcmd also gives weird user issues
[10:22] <lcpfnvcy> but ok I'll wait
[10:34] <lcpfnvcy> https://stackoverflow.com/questions/34095839/cloud-init-what-is-the-execution-order-of-cloud-config-directives
[10:34] <lcpfnvcy> if this is correct, then the execution order doesn't make sense to me
[10:34] <lcpfnvcy> why with runcmd, I still cannot 'chown user directory'
[13:26] <Odd_Bloke> lcpfnvcy: I believe runcmd should work; what issues are you seeing using it?
[13:52] <lcpfnvcy> Odd_Bloke: I've tried runcmd, with a simple 'chown user directory' but the directy remains root
[13:52] <lcpfnvcy> unless my runcmd is wrong
[13:52] <lcpfnvcy> but I dont see errors in the log
[13:53] <lcpfnvcy> [ chown, lcp, /mnt/blobfusetmp]
[13:53] <lcpfnvcy> something like that
[13:55] <Odd_Bloke> Does that do what you expect if you run it by hand after boot?
[15:08] <lcpfnvcy> Odd_Bloke: yes
[15:08] <lcpfnvcy> I can chown the directory login into vm
[15:10] <Odd_Bloke> lcpfnvcy: In that case, please file a bug and attach the output of `cloud-init collect-logs` to it. :)
[15:12] <lcpfnvcy> ok
[15:12] <lcpfnvcy> I'm trying to do this with an azure vm
[15:37] <blackboxsw> Odd_Bloke: forgot to ask about cloud-init SRU, did we get all the verification logs we needed
[15:37] <blackboxsw> ?
[15:37] <Odd_Bloke> blackboxsw: I'm not sure, TBH, I've been focused on other stuff.
[15:38] <blackboxsw> np I'll kick it. I think we are all green all the way
[15:39] <blackboxsw> yep powersj marked it verfication done yesterday
[15:39] <blackboxsw> just needed a bump in#ubuntu-release
[15:39] <Odd_Bloke> OK, nice.
[18:31] <AnhVoMSFT> blackboxsw rharper has the cloud-init 19.3 SRU been cut yet?
[18:39] <chillysurfer> now that AnhVoMSFT mentions it, what determines when we increment the minor or the build component for versioning in cloud-init?
[18:40] <blackboxsw> AnhVoMSFT chillysurfer: I checked in on this internally ~3 hours ago. it was approved but hadn't yet been published. The SRU team did get that upload finalized today, so tonight it should be put into new cloud images
[18:40] <blackboxsw> chillysurfer: minor is changed with each new upstream cut of cloud-init
[18:40] <blackboxsw> we number our versions <year>.<upstream_release_count_for_this_year>
[18:41] <blackboxsw> the subrevision number is generated based on the number of commits that landed since the upstream release cut and we only generate that when we release into an ubuntu series as part of an SRU or package upload into the latest development ubuntu release (Eoan).
[18:42] <blackboxsw> so 19.2.36 happens to be 36 commits past the 19.2 upstream cut as published into  Xenial, Bionic, Disco and Eoan
[18:43]  * blackboxsw needs to double check on the subrevision numbering. But, the major and minor is 19 (year), 2 (second upstream release within 2019 [4 per year])
[18:43] <Odd_Bloke> AnhVoMSFT: We haven't released 19.3 yet; did you mean the 19.2 SRU that Chad is talking about, or something else?
[18:44] <blackboxsw> chillysurfer: we are *late* on an upstream release of 19.3, but it is just a line in the sand based on trying to get 4 upstream upstream releases per year, it is not specifically gated on a feature set.
[18:44] <Odd_Bloke> We only have major/minor versions upstream, which follow the pattern Chad mentioned.
[18:45] <Odd_Bloke> The -36 is Ubuntu-specific.
[18:45] <blackboxsw> for context 19.2.36 is the version of cloud-init that we are SRUing (publishing stable release update) into Xenial, Bionic and Disco
[18:46] <Odd_Bloke> It's -36, _not_ .36.
[18:46] <blackboxsw> :) thx
[18:46] <Odd_Bloke> We don't follow semver, so we need to be careful about that.
[18:46] <Odd_Bloke> Because 19.2-37 could have one enormous change compared to 19.2-36, for example.
[18:47] <blackboxsw> good pt.
[18:49] <chillysurfer> but the "37" in this case will be pushed to the ppas right?
[18:49] <chillysurfer> or if not, what determines when a version/update is pushed?
[18:50] <Odd_Bloke> The daily PPAs get the latest every day.
[18:50] <Odd_Bloke> (But note that PPAs are Ubuntu-specific, so that doesn't invalidate my point above. :)
[18:50] <chillysurfer> so SRU != upstream release cut?
[18:50] <Odd_Bloke> Correct.
[18:51] <Odd_Bloke> Well, we will SRU new upstream releases, in general.
[18:51] <Odd_Bloke> But we also SRU snapshots of upstream in Ubuntu.
[18:51] <chillysurfer> so what is the determining factor to make, for instance, 19.2-37 instead of 19.3-0?
[18:51] <Odd_Bloke> There isn't a clear rule about it.
[18:52] <chillysurfer> ah ok
[18:53] <Odd_Bloke> Because of the nature of cloud-init (which is that it's generally only consumed when integrated into an image by a distributor), having semantic version numbers isn't all that valuable.
[19:01] <chillysurfer> last question (hopefully :)), is every SRU pushed to the archives for ubuntu? for instance, 19.2-0 all the way to current is pushed? or are some skipped? e.g. 19.2-15 wasn't pushed to archives?
[20:09] <blackboxsw> chillysurfer: sorry I missed that. for Ubuntu, we actually take tip of tree of master and bring that into each SRU. so all commits make it into the SRU. We also have an obligation to existing ubuntu Xenial, Bionic and Disco users to retain original behavior. For example.  if a new feature that landed in tip changes a default behavior on Xenial, we end up surfacing a configuration option to retain the original
[20:09] <blackboxsw> defaults in Xenial, but allow cloud-init users to make use of that feature by enabling a configuration option to get the 'new' behavior seen on tip.
[20:11] <blackboxsw> if we know ahead of time we are changing default cloud-init behavior, we generally surface that #cloud-config configuration  option in tip and just alter the config defaults to turn that new feature 'off' on stable Ubuntu releases
[20:26] <Odd_Bloke> chillysurfer: I think you're confusing some terminology here.  SRU stands for Stable Release Update, and is the process we follow to get newer versions of cloud-init back into already-released versions of Ubuntu.
[20:26] <Odd_Bloke> (In general, the software in the Ubuntu Archive does not change after release, to provide stability for its users.)
[20:29] <Odd_Bloke> chillysurfer: We only create new packages every so often, generally when there's a specific feature or bug fix that would be valuable to older releases.
[20:29] <Odd_Bloke> The latest such packages were based on the 36th commit since the 19.2 tag, so their versions all have the prefix "19.2-36".
[20:30] <Odd_Bloke> But you shouldn't expect to see every commit turned into a package in the Ubuntu archive.
[20:31] <Odd_Bloke> For example, the version prefixes before 19.2-36 were (working from latest to oldest) 19.2-24, 19.2-21, 19.2-13, 19.2-9, 19.2-5, and 19.2.
[20:32] <Odd_Bloke> chillysurfer: Does that make some sense?
[20:56] <blackboxsw> thx Odd_Bloke
[23:22] <chillysurfer> Odd_Bloke blackboxsw that makes total sense! thank you!


[03:16] <c2tarun> yofel: on packaging page, you wrote PPA/BZR in third column, why BZR?
[03:17] <yofel> a) you're lucky catching me at 4am, b) we commit all our packaging to bzr branches too
[03:17] <yofel> you should too, since you don't have commit rights that would be merge requests in your case
[03:18] <c2tarun> ok :)
[03:19] <yofel> the branches are: lp:~kubuntu-packagers/<project>/ubuntu
[04:26] <rbelem> hi ScottK
[04:26] <rbelem> ScottK, i will do the spec tomorrow
[04:27] <rbelem> :-)
[04:32] <c2tarun> anyone here ever used google SDK for desktop gadgets?
[05:15] <ScottK> rbelem: Great.
[06:59] <jussi> So... theres going to be a little jussi fork running around :D :D :D
[06:59]  * jussi can hardly sit still.
[07:00] <DarkwingDuck> Congrats!
[07:01] <jussi> :D
[07:02] <c2tarun> I which channel should I ask plamoid related questions?
[07:02] <c2tarun> In which channel should I ask plamoid related questions?
[07:05] <jussi> c2tarun: user or developer q's?
[07:05] <c2tarun> jussi: developers
[07:05] <jussi> c2tarun: here or #kde-devel ?
[07:06] <c2tarun> jussi: ohh.. sorry I just asked it on #plasma :( wait let me repaste the question here
[07:06] <c2tarun> I am reading a plasmoid tutorial and found the use of this signal http://paste.kde.org/44467/ Can anyone please tell me how this signal is behaving.
[07:07] <jussi> #plasma is probably a good place also.
[07:07] <c2tarun> now I have to wait for someone to reply :)
[07:08] <jussi> c2tarun: keep it mind its early on a sunday in europe, and late saturday in america, you might be waiting a bit...
[07:08] <c2tarun> jussi: ohh... its sunday today :( ok, I'll wait
[07:09] <tsimpson> c2tarun: what's confusing you?
[07:09] <tsimpson> and congrats jussi :D
[07:09] <tsimpson> and to the Mrs too
[07:09] <jussi> tsimpson: :D
[07:10] <c2tarun> tsimpson: the parameter that is passed in connect.
[07:10] <c2tarun> tsimpson: I read somewhere in this tutorial that connect can be used to connect signals with slots.
[07:10] <tsimpson> c2tarun: it's a function definition, an inline, unnamed/anonymous function
[07:11] <tsimpson> rather than passing the name of a function, you define the function there and then
[07:11] <tsimpson> it's a common thing in JavaScript
[07:11] <tsimpson> as in JavaScript, functions are objects, and you can pass them around just as any other value
[07:12] <c2tarun> tsimpson: one more help please, can you please tell how the control flows in a javascript code?
[07:13] <tsimpson> the same as in C/C++
[07:13] <tsimpson> there are top-level (or global) declarations, and scopes inside braces {}
[07:14] <tsimpson> there are also if's and for's etc
[07:14] <c2tarun> tsimpson: ok, :) thanks
[08:36] <bambee> morning
[12:41] <shadeslayer> hey :)
[12:42] <shadeslayer> jussi: Congrats!!! :D
[12:42] <shadeslayer> jussi: remind me to get you a smaller kurta next UDS :P
[12:48] <apachelogger> shadeslayer: what did he win?
 So... theres going to be a little jussi fork running around :D :D :D
[12:49] <shadeslayer> apachelogger: ^^
[12:49] <apachelogger> zomg
[12:50] <apachelogger> jussi: congrats \o/
[12:50] <yofel> congratulations jussi :D
[12:50] <apachelogger> forks are awesome :D
[12:51] <Blizzz> congrats jussi!
[14:03] <yofel> hm... this week is ubuntu open week
[14:04] <c2tarun> good evening :)
[16:34] <c2tarun> I wrote this simple plasmoid http://paste.ubuntu.com/601765/ to get the pointer location from mouse data engine, but instead of position I am getting output QVariant(QPoint), what does it mean?
[16:39] <shadeslayer> c2tarun: #plasma for plasma questions
[16:39] <c2tarun> shadeslayer: ok
[19:18] <shadeslayer> apachelogger: tonight i blog!!!!
[19:33] <sheytan> apachelogger ping pong need ya  :D
[20:19] <sheytan> apachelogger you really want to ping me back now, trust me :D
[20:43] <sheytan> apachelogger http://img34.imageshack.us/img34/181/phononc.png
[21:00] <shadeslayer> !find glew.h
[21:38]  * arpan is away: Gone away for now
[21:59] <DarkwingDuck> Wow, I hate the firefox update
[22:03] <DarkwingDuck> I'm running out of a good browser to use.
[22:05] <yofel> what update?
[22:09] <DarkwingDuck> I have not used Firefox in close to 4 months
[22:09] <DarkwingDuck> I can't save open tabs anymore
[22:11] <yofel> hm, never really tried that built-in session restore, I've used the session manager addon since long before they added theirs. Works fine even today
[22:24]  * DarkwingDuck shrugs
[22:24] <DarkwingDuck> It was just acting funky for me... Maybe I'll keep using it because everything else is so far behind it.
[22:37]  * ScottK gave up on Firefox awhile ago.
[22:38] <ScottK> DarkwingDuck: Did you try chromium?
[22:39] <shadeslayer> apachelogger: around?
[22:40] <micahg> DarkwingDuck: firefox should save open tabs by default now, there's a config setting to ask like in 3.6 if you like
[22:47] <DarkwingDuck> micahg: I found it
[22:48] <DarkwingDuck> ScottK: I've been using it for the past few months... it's alright