[09:01] <brobostigon> morning boys and girls.
[10:30] <zmoylan-pi> morning mammals
[10:33] <brobostigon> morning
[10:33] <zmoylan-pi> tis cold out there...
[10:47] <brobostigon> yep.
[17:23] <daftykins> diddledan: help, my cat's got no head - https://dafty.rocks/nextcloud/index.php/s/LpB8ur6b7PaTsic
[17:24] <penguin42> how does it smell?
[17:24] <diddledan> bleedin terrible
[17:25] <daftykins> like cat food ;D
[17:27] <daftykins> ah, bit more outdoor painting today to keep me as near to finished on the outside as possible
[17:27] <daftykins> getting tough to squeeze it in between bouts of rain
[17:27] <penguin42> yeh you couldn't have painted outdoors up here
[17:28] <daftykins> :D
[17:30] <daftykins> did it ~mid-day then we had rain from 4pm, pretty fast drying that stuff
[17:31] <daftykins> still got 4 windows to do on the outside!
[20:57] <zmoylan-pi> daftykins: aren't the windows on the inside too? :-)
[20:57] <daftykins> zmoylan-pi: yep but i can paint those at my leisure!
[21:04] <zmoylan-pi> sitting in a bean bag chair painting it with paintball gun while sipping chilled cider... too much leisure? :-D


[03:15] <codygarver> hey guys, I'm getting this error on a few trusty builds. Anyone know what's up? "dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision" https://launchpadlibrarian.net/157057722/buildlog.txt.gz
[03:16] <dobey> codygarver: fix your debian/source/format file, or your version string. you are using an invalid version string in debian/changelog for the native format
[03:19] <codygarver> dobey, are you sure? It used to build and still builds for saucy and precise. Nothing has changed and it was working for Trusty until a few days ago https://code.launchpad.net/~elementary-os/+recipe/granite-daily
[03:21] <codygarver> http://bazaar.launchpad.net/~elementary-os/granite/deb-packaging/view/head:/debian/changelog and the format is not native http://bazaar.launchpad.net/~elementary-os/granite/deb-packaging/view/head:/debian/source/format
[03:21] <StevenK> codygarver: Nothing has changed except trusty itself, it's the new dpkg in trusty.
[03:21] <StevenK> Ah, a recipe. bzr-builder will override the format to 3.0 (native) if you don't have pristine-tar information.
[03:22] <codygarver> StevenK, so the version string is the problem?
[03:24] <StevenK> codygarver: You have a solution, which is to use pristine-tar with your orig tarball which will stop bzr-builder overriding the format to 3.0 (native). A workaround is to drop the - from the version string.
[03:27] <codygarver> StevenK, how can I provie a pristine-tar with a recipe build? It's also happening with this recipe that's changelog doesn't contain a - https://code.launchpad.net/~elementary-os/+recipe/noise-daily
[03:27] <codygarver> provide a pristine-tar*
[03:31] <StevenK> codygarver: A version of 0.2.4 should be 3.0 (native), not 3.0 (quilt)
[03:31] <StevenK> And that is what is the error is trying to point out.
[03:32] <codygarver> ok so that one is not liking that it was expecting patches and didn't find them, got it
[03:32] <StevenK> No, it is purely a comparsion of the version, files and format. 3.0 (quilt) is for non-native packages, ie: 1.0-1; 0.2.4 is a native version
[03:33] <codygarver> StevenK, oh ok, thanks a lot!
[03:33] <codygarver> StevenK, but what about this one https://code.launchpad.net/~elementary-os/+recipe/noise-daily it is not a native version and is quilt with patches?
[03:34] <StevenK> noise-daily is the native version
[03:34] <StevenK> 0.2.4 is a native version
[03:34] <codygarver> StevenK, oh it's complaining about the - in the recipe header?
[03:35] <codygarver> {debversion}+r{revno}-0+pkg{revno:packaging}
[03:35] <StevenK> Oh, yeah, exactly.
[03:35] <dobey> codygarver: you need to change the version in debian/changelog in the packaging branches to be 0.2.4-0elementary1 or something
[03:35] <StevenK> Sorry, I was comparing the version in debian/changelog, which the recipe machinery doesn't use.
[03:35] <codygarver> now it really all makes sense, thanks dobey and StevenK
[03:35] <StevenK> dobey: Still contains a -
[03:35] <StevenK> Try again? :-P
[03:36] <dobey> StevenK: yes, it should be fine as long as debian/changelog has the thing. dpkg is looking at what's already in debian/changelog
[03:36] <StevenK> bzr-builder adds an entry first, no?
[03:36] <StevenK> So fix the recipe text and retry
[03:37] <dobey> hrmm
[03:37] <dobey> StevenK: then it shouldn't matter, since source/format has 3.0 (quilt)
[03:38] <dobey> but having the - in debian/changelog apparently doesn't fix it either
[03:38] <StevenK> dobey: But bzr-builder overrides the format to 3.0 (native) with no pristine-tar information, which I said earlier.
[03:38] <codygarver> I have modified the recipe versioning and requested a build, so we'll see in a few minutes
[03:39] <StevenK> codygarver: If it's not already building, link it to me and I'll make it build.
[03:39] <codygarver> stgraber, I used a recipe that's not in a somewhat-production environment yet https://code.launchpad.net/~codygarver/+recipe/midori-elementary-daily
[03:39] <codygarver> StevenK, ^
[03:39] <dobey> then i guess bzr-builder needs fixing
[03:40] <StevenK> Or use pristine-tar, and it won't override.
[03:40] <StevenK> It wants to make the exact same orig from just bzr history, it needs something more.
[03:45] <dobey> what does it even mean to provide pristine-tar in a source recipe?
[03:46] <StevenK> dobey: pristine-tar takes an orig tarball and the repoistory information and creates a diff and commits it. Then you can always reconstruct the *exact same* orig using only bzr history
[03:49] <StevenK> dobey: 'man pristine-tar' ?
[03:49] <dobey> that doesn't actually tell me anything. nor does it work for sources that have never actually made a tarball release, and seems like it would be unusable for git imports
[03:50] <StevenK> dobey: Sorry for not explaining it well -- the DESCRIPTION in the pristine-tar manual page should help, then.
[03:53] <dobey> doesn't really help either. it tells me it is not a usable solution, though.
[03:55] <wgrant> dobey: Sources that have never made a tarball release have to be native.
[03:55] <wgrant> Because non-native implies release tarball.
[03:55] <dobey> native implies the package information is part of the source tree; it doesn't necessarily imply tarball
[03:56] <StevenK> native also implies a format and version
[03:56] <codygarver> it looks like removing the - from the recipe version resolved the issue https://code.launchpad.net/~codygarver/+recipe/midori-elementary-daily
[03:56] <codygarver> thanks for your help again
[03:57] <wgrant> dobey: Non-native necessarily implies release tarball
[03:57] <wgrant> A package is non-native iff it has at least one orig.tar.*
[04:00] <dobey> does "debuild -S -sa" in the tree of a non-native package without an orig.tar in the parent directory, fail completely, or ask you to continue anyway, with the new dpkg?
[04:01] <StevenK> It will fail completly, I think.
[04:01] <wgrant> dobey: If you've specified '3.0 (quilt)' as the format it will fail
[04:02] <wgrant> I don't know the behaviour of format 1.0 in the new dpkg
[04:02] <dobey> :(
[04:02] <wgrant> But it previously would fall back to native, as there was no way to distinguish.
[04:02] <wgrant> 3.0 (quilt) without an orig.tar.gz has failed since almost day 1
[04:03] <dobey> since day 1?
[04:03] <wgrant> 3.0 (native) with a non-native version has only failed since last week.
[04:03] <wgrant> day 1 of the 3.0 formats.
[04:03] <dobey> no, it doesn't fail. it asks if you want to make the source anyway
[04:04] <wgrant> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../hello_2.8+fake.orig.tar.{bz2,gz,lzma,xz}
[04:04] <wgrant> It asks, but still fails.
[04:07] <dobey> oh, ok
[04:08] <dobey> can't bzr-builder export the tree to the orig.tar.gz if format is 3.0 (quilt)?
[04:08] <dobey> seems like it should do
[04:08] <StevenK> It will do so, given pristine-tar information is in the branch.
[04:10] <dobey> and generate a giant diff for all changes made since that tarball release? that is silly
[04:11] <wgrant> Silly?
[04:11] <wgrant> What else can it do?
[04:12] <dobey> export the current revision of the tree to the orig.tar?
[04:13] <wgrant> That would be the original tarball, though.
[04:13] <wgrant> s/would/wouldn't/
[04:13] <dobey> yes it would be
[04:13] <wgrant> How?
[04:13] <dobey> it would be the original tarball for that revision of the branch.
[04:14] <dobey> and it would avoid many other potential failures as a result of not doing that
[04:14] <wgrant> What potential failures?
[04:14] <dobey> such as binary files in the tree having changed since the last "tarbsll release"
[04:15] <wgrant> There shouldn't be binary files in a source tree in the first place :P
[04:15] <dobey> yeah, well, good luck with that
[04:15] <wgrant> What version would the orig.tar.gz have?
[04:15] <wgrant> How do we ensure that it's bit-identical each time?
[04:15] <dobey> the same version as the recipe
[04:16] <wgrant> 3.0 (quilt) handles changed binaries anyway.
[04:16] <wgrant> If it's the same version as the recipe, what value does it provide over a native non-orig.tar.gz/
[04:16] <wgrant> orig.tar.gzs are useful because they can be shared.
[04:16] <dobey> making versions strings that are correct for things that aren't native sources
[04:17] <dobey> well if you are getting orig.tar.gzs from a PPA to use as "official original tarballs" you've already failed
[04:18] <wgrant> There may be some value in being able to construct a bit-identical tarball from just the upstream branch with a version like 1.0+bzr20131122, but it's not entirely clear how that would work, and it's significantly more complicated.
[04:18] <dobey> for official archive, sure; for PPAs, many of them aren't maintained by debian developers
[04:18] <dobey> "bzr export" isn't complicated
[04:18] <wgrant> Daily builds today should either produce a native package with a native version, or produce a non-native package based on some real release tarball for which the branch has pristine-tar metadata, and include changes since the tarball in the debian.tar.gz.
[04:19] <dobey> recipes can't use real release tarballs
[04:19] <wgrant> dobey: Recipes would need to specify how to construct the upstream tree and then separately how to apply the Debian changes.
[04:19] <wgrant> dobey: Why can't they?
[04:19] <wgrant> Lots of recipes do.
[04:19] <dobey> because people making recipe builds of things don't necessarily have commit priveleges to the things they are packaging to add pristine-tar info to them, even if it made sense to do so
[04:19] <wgrant> They could include the pristine-tar metadata in the packaging branch.
[04:20] <wgrant> Anyway, those are the two ways it works today.
[04:20] <wgrant> If you want to implement the separate upstream branch functionality, by all means.
[04:22] <dobey> and pristine-tar doesn't make sense in the recipes; the thing i am packaging isn't the last released tarball with a signficant number of changes in a giant diff. it's trunk.
[04:22] <dobey> anyway, i am not in .au time zone, so i should go get some sleep :)
[04:22] <wgrant> pristine-tar makes sense in recipes.
[04:22] <wgrant> One could argue it makes less sense in *daily build* recipes.
[04:23] <wgrant> That's up for debate.
[04:23] <dobey> sure, if those recipes are packaging a specific revision of a branch that is exactly the same as the tarball in question :)
[04:23] <wgrant> Or recipes composing upstream releases and a Debian branch.l
[04:23] <wgrant> Not all recipes are of an ever-changing trunk.
[04:24] <dobey> all the ones i care about are :)
[04:24] <wgrant> But they are not all the recipes in the world.
[04:24] <dobey> no, but they are the ones that are broken by these changes
[04:24] <wgrant> Recipes that are daily builds of trunk must today use one of the two solutions I described.
[04:25] <dobey> while the others aren't, and wouldn't be broken by changing bzr-builder to deal with the changes in a better way for these sorts of recipes
[04:25] <wgrant> If someone wants to implement the third, they can.
[04:25] <wgrant> bzr-builder can't simply be magically changed.
[04:25] <wgrant> It would require an extension of the recipe format, for example.
[04:25] <wgrant> If someone wants to do that, that'd be great.
[04:25] <dobey> anyway, sleep for now
[04:26] <dobey> later :)
[04:31] <wgrant> Night
[07:07] <Noskcaj> wgrant, To test if the package builds. If so, it can be synced to ubuntu
[08:47] <czajkowski> aloha
[20:23] <philsf> I need help with a recipe for building packages in LP. When I test locally (bzr dailydeb recipe wd), the source package is built. When I request a build in LP, I get the following error: https://launchpadlibrarian.net/157361878/buildlog.txt.gz
[20:23] <philsf> how come LP is complaining I didn't set my LP-id, if I'm doing it while logged in?
[20:24] <dobey> that has nothing to do with your lp id; you aren't running the recipe, launchpad is, on a build server in a chroot somewhere. it doesn't have your credentials to access or write to things
[20:26] <dobey> what is the url for the recipe?
[20:29] <philsf> https://code.launchpad.net/~philsf/+recipe/philsf-likes-workstation
[20:31] <dobey> so, some stuff in format 0.4 doesn't work on launchpad yet. format 0.3 works fine though. so you need to use something like "{debupstream}+r{revno}" for the version instead of {latest-tag}
[20:32] <philsf> dobey, hmm, but this way I can't use a single recipe to track releases from tags, right? that is, unless I request a build whenever I push the revision of a release, am I correct?
[20:37] <dobey> what do you mean? {latest-tag} also isn't really a good version number. the tag could be "foo" which isn't a number at all. version numbers have to begin with a digit
[20:37] <dobey> philsf: also, the version string in the recipe doesn't control what revision is being checked out in the build
[20:38] <philsf> dobey, I always use tags like "0.1.0", or something like that. I thought it was the simplest way to manage releases in LP
[20:40] <philsf> dobey, yay, it built now. thanks! I think I'll only use {debversion}, since I don't need a daily build
[20:41] <dobey> well, the binary build will fail
[20:46] <philsf> why?
[20:47] <dobey> because your branch doesn't contain anything but the debian/ directory; so nothing to build or install
[20:47] <philsf> I meant {debupstream}, not {debversion}.
[20:48] <philsf> debuild builds the binary package fine. what should I do to create a metapackage that makes LP happy, then?
[20:59] <dobey> you are trying to make a metapackage?
[20:59] <philsf> yup
[20:59] <philsf> btw, is there a way NOT to include ~ubuntu13.10.1 or similar in the uploaded package version?
[21:00] <dobey> it might work as-is. you'll have to wait 5+ hours to see
[21:00] <dobey> no, there isn't
[21:00] <dobey> the ubuntu release version is automatically appended to all recipe builds
[21:01] <dobey> if you are going to build on multiple versions of ubuntu, it is very necessary
[21:03] <philsf> If I want the kind of versioning that is usual in official packages (say, for another project),  would I need to use the likes of dput instead of using a recipe?
[21:04] <dobey> i'm not sure what you're asking exactly
[21:05] <philsf> lol, sorry. say I have a serious project I'm releasing, and want the package version to be 0.1, or 0.1-1, instead of 0.1~ubuntu13.10. How can I accomplish that in LP?
[21:06] <philsf> (for an example, I'm working on launchpad.net/~mmrrsim, but that packaging is not finished yet)
[21:06] <dobey> well, in a PPA you should always append the ~ubuntu13.10.1 for example
[21:06] <dobey> whether it is via dput or a recipe
[21:07] <philsf> for this ~mmrrsim project, I intend to ask debian to include it there, then ask ubuntu to include. but I'm using LP as upstream, for both coding and packaging, bugs, questions, etc.
[21:08] <dobey> if you want 0.1 (because you're a native package), or 0.1-1 (because you're a non-native package with an orig.tar.gz), or 0.1-0ubuntu1 (because you want it in ubuntu) you should do the requisite work to get it included in debian or ubuntu
[21:08] <dobey> PPAs are not the place official debian/ubuntu packages
[21:09] <dobey> recipes are easier because they automatically append the ~ubuntu13.10.1 bit
[21:09] <dobey> so they are great for making use of PPAs easier
[21:09] <philsf> dobey, cool. thanks for clarifying that. I'll do exactly that for my work project. the one I bothered you about is just a little thing to help me keep updated in all my boxes.
[21:10] <dobey> philsf: maybe you should look at using oneconf in software-center, instead of a meta package
[21:10] <dobey> philsf: it's a feature that allows you to install the same packages as you have installed on another computer on your network
[21:11] <philsf> dobey, thanks for the pointer. I was curious about metapackaging, though ;)
[21:12] <philsf> it's also a simple way of sharing my base workstation install with coworkers. the rant about the ~ubuntu13.10 is irrelevant, and as you said, useful
[22:34] <slackner> wgrant: Hiho. You probably remember our questions recently about moving PPAs to a different user/groups, where we didn't find a good solution. Is it probably possible to put just a symlink / redirection at the original location of the PPA, and reuse the same signing key for a new one, without breaking the installation of our current users? Or alternatively that all packages are copied automatically from one location to the other one?
[22:47] <maxb> Automatic copying could be done with a cronjob calling the lp web api
[23:09] <wgrant> slackner: Neither of those are possible within Launchpad, but as maxb suggests you could use an API script and cron to keep two PPAs in sync.
[23:10] <slackner> wgrant: is it technically not possible, or just not implemented?
[23:17] <wgrant> Aliasing PPAs is not supported and difficult to support in the current implementation. We could probably work out a way to transfer a PPA key if you have a good reason to request it.
[23:17] <wgrant> slackner: ^^
[23:18] <slackner> wgrant: well, what we would like to have is one central PPA for all package, unfortunately we started with several ones, and we cannot just change it with >10k users
[23:19] <slackner> wgrant: transfering PPA keys itself would not be sufficient, as users will need some time to figure out that the old PPA is deprecated
[23:20] <slackner> wgrant: does it make sense to fill out feature requests for this (which could be implemented in the next time)? or do we have to use something like the cronjob approach?
[23:21] <slackner> wgrant: not sure how everything works internally, but in principle a http redirect and a new ppa with same key should already do the trick (if i don't miss anything)
[23:22] <wgrant> slackner: We'd transfer the PPA key manually by hacking the database, but it's unlikely that we'd be able implement PPA redirects within say a year. I'd suggest that using an API cronjob would be your best bet for now.
[23:25] <slackner> wgrant: hm, okay.. well, the cronjob method also seems a bit hacky too me, but if there isn't any better solution we'll implement it ^^ thanks!
[23:28] <wgrant> slackner: Yeah, it's not ideal, but it should work fine for now.
[23:45] <maxb> slackner: there's a script you can use already written, look for lp-promote-ppa in lp:hydrazine
[23:46] <slackner> maxb: ah, nice :)


[08:48] <cjwatson> evand: looking at https://beta.launchpad.net/ubuntu/+source/ubiquity/+bug/93197 - shouldn't 'set_os_type $line' be 'set_os_type "$line"'? $line might well contain spaces and needs to be quoted
[08:49] <cjwatson> evand: also seems like it wouldn't hurt to have set_os_type return 1 if it's an unknown OS type and then do 'set_os_type "$line" || continue' or similar in calling code
[10:45] <CIA-15> oem-config: cjwatson * r275 oem-config/ (d-i/manifest debian/changelog): * Automatic update of included source packages: console-setup 1.13ubuntu9.
[10:52] <CIA-15> oem-config: cjwatson * r276 oem-config/debian/changelog: releasing version 1.12
[11:47] <CIA-15> ubiquity: cjwatson * r1967 ubiquity/ (configure configure.ac): bump to 1.4.3
[11:59] <saispo> hi
[12:00] <saispo> cjwatson: does ubuntu installer support pgp key with passphrase ?
[12:02] <cjwatson> should be irrelevant, the installer isn't signing anything, only verifying
[12:03] <cjwatson> verification doesn't need passphrase input, unless you're doing something truly weird
[12:03] <saispo> oki, thanks
[12:59] <evand> cjwatson: hrmm, I'll take a look at it after classes.  Thanks!
[01:51] <cr3> after installing in OEM mode, would there be a way to preseed questions asked to the enduser?
[01:51] <cr3> for example, if an OEM is selling machines in a country which only has one language, there would be little reason to prompt the user for language
[01:58] <cjwatson> cr3: not at present. Haven't we had this conversation before?
[02:00] <cjwatson> yes, we have, last Tuesday
[02:00] <cr3> cjwatson: wow, I need to keep better logs of my conversations
[02:02] <cr3> cjwatson: aha! I remember that the outcome of the conversation was that the OEM team should formalize their request to make it happen. I'll write them an email right away
[02:02] <cjwatson> right
[02:47] <CIA-15> ubiquity: cjwatson * r1968 ubiquity/ (debian/changelog scripts/install.py):
[02:47] <CIA-15> ubiquity: * Install dummy policy-rc.d and start-stop-daemon while doing anything
[02:47] <CIA-15> ubiquity:  that might install or remove packages in the target system, so that we
[02:47] <CIA-15> ubiquity:  don't try to run init scripts (LP: #89463).
[02:54] <CIA-15> ubiquity: cjwatson * r1965 feisty-beta/ (configure configure.ac debian/changelog scripts/install.py): merge r1967 and r1968 from mainline
[04:15] <thom> cjwatson: hey, is there any way to perform an action after the reboot into the new install?
[04:17] <cjwatson> write out an init script
[04:20] <thom> hrm. i only want to do this once; but yeah, that works
[04:36] <CIA-15> ubiquity: cjwatson * r1969 ubiquity/ (d-i/manifest debian/changelog): merge from feisty-beta branch
[04:51] <CIA-15> ubiquity: cjwatson * r1970 ubiquity/ (configure configure.ac): bump to 1.4.4
[04:51] <CIA-15> ubiquity: cjwatson * r1967 feisty-beta/debian/changelog: releasing version 1.4.3
[05:31] <evand> cjwatson: whoops, noted your comments on 94336 for future reference.
[05:32] <cjwatson> np
[08:13] <cr3> how can I debug the desktop installation? I'm attempting to install from nfs and the nfs mounted squashfs seems to start failing at "Starting GNOME Display Manager...", so I'd like to get some more details.
[08:16] <cjwatson> that's not the installer at that point so best not asked here
[08:16] <cjwatson> if squashfs is dying you would probably be best asking the kernel team for help
[08:16] <cjwatson> seeing as we employ the squashfs author and all that
[08:18] <cr3> cjwatson: the problem is most likely that the gnome display manager is affecting the network which where the squashfs is being nfsmounted. so, I made sure /etc/network/interfaces only contained lo information but that didn't seem to help.
[08:18] <cr3> I'll see if I can enable xtrace in the gnome display manager init script
[08:19] <cjwatson> that seems an odd inference and would surprise me if true
[08:19] <cjwatson> but at any rate, please not here
[08:26] <cr3> something installer related then :) I managed to get the nfs part of the installer working with a couple minor patches wihch I submitted to the right people, thought you might like to know :)
[08:27] <cjwatson> could you point me to those patches?
[08:27] <cjwatson> I would have expected it to need new components
[08:28] <cr3> cjwatson: they were sent directly to lifeless and tfheen, upon lifeless' request. I'll forward the message to you if you like
[08:28] <cjwatson> er - that's not the installer
[08:29] <cjwatson> casper is not the installer, it's the live CD bootstrap process
[08:29] <cjwatson> not bothered about it, I thought you meant d-i :)
[08:29] <cr3> ah, my mistake, thanks for pointing that out: booting != installer :)
[08:30] <cjwatson> the installer begins when you (a) boot d-i or (b) select the "Install" icon on the desktop. :)
[08:35] <CIA-15> ubiquity: cjwatson * r1971 ubiquity/ (debian/changelog ubiquity/frontend/kde-ui.py):
[08:35] <CIA-15> ubiquity: * KDE frontend: Disable subsidiary autopartitioning options according to
[08:35] <CIA-15> ubiquity:  the primary selection (thanks to Thorbjrn Tux for prompting me with
[08:35] <CIA-15> ubiquity:  suggestions; LP: #85980).
[11:07] <stephanecharette> Is this where I would ask about some installation problems?
[11:22] <cjwatson> ... yes


[08:55] <alkisg> @#$%^&*(  adobe flash player crashes palemoon in my desktop pc 22.04, but it works fine in my almost identical 22.04 VM ... /me is afraid that he'll lose his whole morning troubleshooting that one... :D
[08:56] <alkisg> > ###!!! [Parent][MessageChannel::Call] Error: Channel error: cannot send/recv
[10:02] <lotuspsychje> !info flashplugin-installer
[10:04] <alkisg> Yeah neither flash nor palemoon, yet I suspect the problem lies in the graphics driver updates (intel)...
[10:08] <lotuspsychje> could be alkisg got some graphics issues on intel/wayland also
[10:09]  * alkisg created an image of his desktop installation, and will boot it from a VM now...
[10:10] <alkisg> Yup, it works fine there
[10:23] <alkisg> Meh, it fails on another PC with a newer intel as well. I'll search for something non-intel tomorrow, thank you lotuspsychje :)
[12:57] <xu-irc82w> hello, how do u save xfce panel setup file, eveytime when i click save, it got stacked in there, i cant save or cancel
[12:58] <xu-irc82w> and i cant mount my phone now also, its mounted automatically before


[00:44] <axw> thumper: hey, FYI I'm online today - taking tomorrow off instead
[01:02] <babbageclunk> axw: standup then? ;)
[01:10] <axw> babbageclunk: oh sorry! I didn't know you were on today
[01:11] <axw> babbageclunk: I'm here if you really do want to standup, but for me it's just: working on upgrades
[01:13] <babbageclunk> axw: :) externalreality and I had a brief chat, but no need - I'm chasing a bug with my sub-sub relation thing and he's working on getting details of run actions earlier to determine whether to take the machine lock.
[01:13] <axw> babbageclunk: okey dokey, thanks
[01:31] <thumper> menn0: is there a way to force a mongo election between peers?
[01:32] <menn0> thumper: you can be fiddling with the member priorities
[01:32] <thumper>  https://bugs.launchpad.net/juju/+bug/1701275
[01:32] <mup> Bug #1701275: [2.2.1] juju-agent loses connection to controller and doesn't retry to connect <cpe> <cpe-sa> <juju:Triaged> <https://launchpad.net/bugs/1701275>
[01:32] <thumper> looks like the agents disconnect during an election
[01:32] <thumper> and don't reconnect
[01:33] <menn0> thumper: we've seen that occasionally. it seems like a dep engine bug to me.
[01:33] <thumper> yeah...
[01:33] <thumper> we saw that on the customer site too
[01:33] <menn0> thumper: the dep engine stops trying after a while
[01:33] <thumper> where agents had disconnected
[01:33] <thumper> and didn't reconnect
[01:33] <menn0> thumper: perhaps due to manifold returning the wrong thing
[01:33] <thumper> not sure...
[01:33] <thumper> I may read through the dep engine code and see if anything leaps out
[01:34] <menn0> thumper: I have some old logs from jam for a system he had where it happened
[01:34] <menn0> on his machine
[01:34] <thumper> hmm...
[01:39] <menn0> thumper: do you have the tail end of the logs for an agent that got "stuck"
[01:39] <menn0> ?
[01:40] <thumper> not off hand
[01:40] <thumper> they are all in warning+ mode
[02:01] <axw> thumper: 1:1?
[03:47] <menn0> babbageclunk: I'm seeing failures in TestSplitLogsCollection. Looks like the bit that looks for the "ns not found" error isn't working on my machine for some reason
[03:47] <menn0> babbageclunk: is this a known thing?
[03:57] <babbageclunk> menn0: not by me!
[03:58] <menn0> babbageclunk: the QueryError Code is coming back as 0 despite the message being the expected "ns found found"
[03:59] <babbageclunk> menn0: maybe a mongo version difference?
[03:59] <menn0> babbageclunk: must be, although I can see that the tests are using our officially packaged mongodb 3.2 package
[04:00] <menn0> babbageclunk: should we be worried that this is in a released version?
[04:00] <menn0> (I don't know if it is)
[04:01] <babbageclunk> It definitely is - it was done for 2.2.0, I think.
[04:02] <babbageclunk> menn0: is it failing consistently for you?
[04:02] <menn0> babbageclunk: yes
[04:02] <menn0> babbageclunk: I have a fix which uses the error code /or/ the message
[04:03] <menn0> babbageclunk: looks like this is in 2.2
[04:05] <babbageclunk> menn0: So is my machine using the wrong mongo version for tests?
[04:06] <menn0> babbageclunk: possibly. there's a number of fallbacks
[04:06] <menn0> babbageclunk: run the state tests and do: ps ax | grep mongo
[04:08] <babbageclunk> It's using the juju-mongo32 mongod - that reports that it's 3.2.12
[04:09] <menn0> babbageclunk: hmmm same for me
[04:09] <menn0> how strange
[04:09] <babbageclunk> menn0: hmm
[04:10] <babbageclunk> git version ef3e1bc78e997f0d9f22f45aeb1d8e3b6ac14a14 (just in case)
[04:11] <babbageclunk> menn0: so, that's weird. Different versions of mgo?
[04:11] <menn0> babbageclunk: i'm at f2b6f6c
[04:11] <babbageclunk> menn0: I'm working on a branch off 2.2 at the moment
[04:12] <babbageclunk> menn0: same git hash for mgo
[04:12] <babbageclunk> curiouser and curiouser
[04:13] <menn0> babbageclunk: hang on... I may have been running the tests remotely on a different machine
[04:13]  * menn0 checks
[04:14] <menn0> babbageclunk: i've got it
[04:14] <menn0> babbageclunk: it's my "workhorse" machine
[04:15] <babbageclunk> menn0: And what's that running?
[04:16] <menn0> babbageclunk: the official mongo 3.2 it would appear :/
[04:16] <menn0> babbageclunk: but that's where it's failing
[04:16] <menn0> i'll dig some more
[04:16] <babbageclunk> ok
[04:19] <menn0> babbageclunk: this machine has mongodb 3.2, 2.6 and 2.4 installed
[04:20] <babbageclunk> menn0: Which one's the test picking?
[04:20] <menn0> babbageclunk: still trying to figure that out
[04:21] <menn0> babbageclunk: it's 2.6.10
[04:22] <menn0> babbageclunk: which is odd given the test code is supposed to prefer the 3.2 installation
[04:26] <menn0> babbageclunk: the problem with this upgrade step will be that it could fail on trusty controllers
[04:26] <menn0> which still use 2.4 IIRC
[04:27] <babbageclunk> menn0: But that's only a problem if we were upgrading controllers to 2 from 1.25 in-place, isn't it?
[04:27] <menn0> babbageclunk: no
[04:27] <menn0> babbageclunk: if you bootstrap a 2.x controller on trusty I believe it still uses mongo 2.4
[04:28] <babbageclunk> menn0: Ah, right
[04:29] <babbageclunk> menn0: Wouldn't that be a pretty odd thing to do?
[04:29] <babbageclunk> menn0: I guess we support it though.
[04:29] <menn0> babbageclunk: yes, unless you wanted to run some trusty only charms on the controller
[04:30] <thumper> menn0: so ideas on forcing a leader election in mongo without restarting juju?
[04:30] <babbageclunk> menn0: It sounds like your fix will correct it anyway.
[04:30] <menn0> babbageclunk: yes it will but it's already in 2.2.1
[04:31] <menn0> babbageclunk: I guess it only fails the second time the upgrade step is attempted. is that right?
[04:32] <babbageclunk> menn0: oh, right - because the first time the logs collection is there?
[04:32] <thumper> axw: did you say that the metrics gathering now all uses the state pool?
[04:32] <thumper> axw: in 2.2?
[04:32] <axw> thumper: on the 2.2 branch, yes. the second fix I was talking about landed last week
[04:32] <thumper> axw: cool. I'll see if that fixes my issue here
[04:32] <menn0> thumper: connect using the mongo shell and give the current leader a priority of 0
[04:33] <menn0> thumper: rs.conf() show the current configuration
[04:34] <thumper> I'm thinking of writing a 'juju-fetch' plugin that just does 'git fetch'
[04:34] <menn0> thumper: this is helpful: https://docs.mongodb.com/manual/tutorial/force-member-to-be-primary/
[04:34] <thumper> menn0: thanks
[04:36] <menn0> babbageclunk: so the chances of hitting the problem are fairly slim but not 0. a re-run of the upgrade step could happen when any upgrade step fails and the upgrade is retried.
[04:37] <menn0> babbageclunk: i'll file a bug and get the fix in
[04:37] <menn0> babbageclunk: i've confirmed it works for 2.4
[04:38] <menn0> babbageclunk: I didn't even know you had done this work to split out log collections :)
[04:39] <babbageclunk> menn0: You mean if another upgrade step fails after this one succeeds, right? I did the state work, thumper did the upgrade step.
[04:41] <menn0> babbageclunk: I should have known :)
[04:45] <menn0> babbageclunk: just to be sure, I just confirmed that we still use 2.4 on trusty
[04:47] <babbageclunk> menn0: nice one.
[04:59] <menn0> babbageclunk or thumper: https://github.com/juju/juju/pull/7588
[04:59] <babbageclunk> menn0: looking
[05:00] <thumper> menn0: so... I got that logs deserialization error
[05:00] <thumper> went and looked in the DB
[05:00] <thumper> there is no entry with a missing TAG
[05:00] <thumper> so...
[05:01] <thumper> it looks like the oplog tailer is returning an empty value sometimes
[05:01] <thumper> when it shouldn't
[05:01] <menn0> thumper: were you looking for docs with an empty tag, or a missing tag?
[05:01] <thumper> ah... empty
[05:01] <thumper> how do I say missing?
[05:02] <thumper> nm
[05:02] <menn0> thumper: https://stackoverflow.com/questions/8567469/mongodb-find-a-document-by-non-existence-of-a-field
[05:03] <thumper> db.logs["ac97e810-63f3-49b1-89dd-ea7f32e6e5d4"].find({n:{$exists:false}}).count()
[05:03] <thumper> 0
[05:03] <thumper> neither empty nor missing
[05:06] <thumper> menn0: the error is being emitted every five minutes
[05:06] <thumper> seems very exact
[05:06] <menn0> thumper: it could also be that the field is the wrong type, so that it gets deserialised to "" because the db type doesn't match the struct type
[05:07] <menn0> thumper: where is the error being emitted?
[05:07] <menn0> thumper: when deal with broken txn metadata i've seen fields with nil values that are confusingly deserialised
[05:11] <thumper> menn0: db.logs["ac97e810-63f3-49b1-89dd-ea7f32e6e5d4"].find({n:{$not: {$type: "string"}}}).count()
[05:11] <thumper> 0
[05:11] <thumper> not not a string either
[05:12] <thumper> menn0: the error is emitted in the controller model, which happens to be the one I'm tailing
[05:12] <menn0> thumper: nice query
[05:12] <thumper> I recall the oplog query code has a reconnect on timeout
[05:13] <thumper> I'm wondering if that is emitting something bad by mistake
[05:13] <thumper> it goes back to look for values of the current time slice
[05:13] <thumper> but what if the logs are quiet
[05:13] <thumper> and there isn't one?
[05:13] <thumper> perhaps that's the use case
[05:13] <menn0> thumper: that seems likely
[05:13]  * menn0 looks at the code
[05:14]  * thumper goes back to finding his other bug
[05:14] <menn0> thumper: seems the default cursor timeout is 10mins
[05:15] <thumper> this is happening every 5 minutes on the nose
[05:16] <menn0> thumper: i'm seeing other sources which say 5 mins
[05:16] <menn0> digging
[05:18]  * thumper is getting a bunch of unit agents connected before he forces a mongo election
[05:31] <menn0> thumper: so it turns out the oplog tailer uses a timeout of 1s so that it can be interrupted
[05:32] <menn0> thumper: but there's also the concept of cursor invalidation and we might be running into that
[05:32] <thumper> hmm..
[05:32] <menn0> thumper: i've added logging and have left debug-log running
[05:32] <thumper> I'm curious to see if you see the same error message every 5m
[05:32] <menn0> what does the message look like?
[05:34] <menn0> thumper: ^^
[05:49] <thumper> machine-1: 17:29:11 WARNING juju.state deserialization failed (possible DB corruption), while parsing entity tag: "" is not a valid tag
[05:51] <thumper> I'm trying option two
[05:52] <thumper> stopping all api server agents
[05:52] <thumper> while leaving all unit agents running
[05:52] <thumper> will go away for a few hours
[05:52] <thumper> and bring them up again
[05:52] <thumper> that seems to mirror some of the failure cases
[05:52] <thumper> back later folks
[22:32] <babbageclunk> thumper: 1:1? (Sorry, was slow to see the reminder)
[22:33] <thumper> coming


[14:05] <psivaa> cjwatson: infinity: i reported bug #1212239 for print server installation failures with today's saucy images, tkamppeter says it's an image building issue and not one with the cups-filters
[14:05] <ubot2`> Launchpad bug 1212239 in cups-filters (Ubuntu) "cups-filters is reported to have unmet dependencies with the latest saucy server installations" [Undecided,New] https://launchpad.net/bugs/1212239
[14:05] <psivaa> shall i reassign the bug to d-i?
[14:08] <seb128> psivaa, not sure if it's a *bug/issue* with d-i, but we need help from somebody who understand how the image building is working to debug it
[14:09] <seb128> we fixed the rdepends to depends on "cups-filters (>= ...) | oldname" and things install/upgrade fine
[14:09] <seb128> not sure how to debug those sort of issues :/
[14:09] <seb128> psivaa, cjwatson is at debconf though, not sure how often he looks at IRC
[14:13] <psivaa> seb128: ahh ok, thanks. dint realise that it's so complex :). could wait.
[14:13] <seb128> psivaa, it's probably not "so complex" but most of us are not really familiar with the image build details
[14:14] <psivaa> seb128: ack
[14:40] <rtg> infinity, bah! please reject fglrx-installer so that I can re-upload it with the proper version diff


 I know cause brobostigon keeps saying morning :-D
[15:46] <Nafallo> it's a keep-alive thing :-)
[15:47] <brobostigon> :)
[16:51] <zmoylan-pi> i'll get the word out on aol im.... :-)
[16:53] <daftykins> hi all \o
[16:53] <zmoylan-pi> o/
[16:55] <daftykins> i've been up the scaffold, balancing on a milk crate to paint the last of the new windows :O
[16:55] <daftykins> first dry day in ages
[16:55] <zmoylan-pi> ^ most likely to be included on a medical insurance form later...
[17:05] <diddledan> it it weren't for brobostigon pinging us regularly with "morning boys and girls." then this channel would have timed-out
[17:05] <brobostigon> lol, yep.
[17:05]  * diddledan sets up a punger
[17:06] <diddledan> now I wonder what's wrong with my https service - it's not
[17:06] <diddledan> i.e. not servicing
[17:07] <diddledan> I'm teaching myself k8s
[17:07] <diddledan> trying to get my head around traefik
[17:07]  * diddledan wonders if anyone knows either of those two terms or I'll have to explain
[17:07] <daftykins> >:D
[17:08] <daftykins> nope neither
[17:08] <daftykins> k9s are much more commonplace ;)
[17:08] <diddledan> k8s is a docker "orchestration" service - stands for "kubernetes". traefik is a proxy thingamajig for routing requests to the right docker containers
[17:09] <daftykins> mmm i've heard kubernetes is the flavour of the week for all container fiends that maintain distance from harbours/ports
[17:09] <diddledan> totally random question, but at this time of year wtf wears short shorts?!
[17:09] <daftykins> kinda sick of hearing about them in the news really XD
[17:10] <daftykins> fashion victims?
[17:10] <diddledan> who wears short shorts?
[17:10] <daftykins> pass
[17:10] <diddledan> bah
[17:10] <diddledan> y'all suck
[17:11] <daftykins> even i've hung up my shorts for the winter season
[17:11] <diddledan> I might put my thick jumpie on in a bit for a snugglesession
[17:12] <diddledan> if you don't got noone to cuddle, wear a thick jumper!
[17:13] <diddledan> interesting one from VLC in the terminal: main decoder error: buffer deadlock prevented
[17:13] <diddledan> if it was prevented then surely that's a good thing, not an error?!
[17:13] <daftykins> ;)
[17:14] <daftykins> glad to read that MPC-HC won't die after all, that's my player of choice when at the PC
[17:14] <daftykins> https://dafty.rocks/nextcloud/index.php/s/7fBRPdMvPmWwDp9
[17:14] <daftykins> here are some cat snaps and the aforementioned milk crate of doom
[18:36] <m0nkey_> Wooh! One of my PPI claims came through :)
[21:20] <daftykins> o0
[21:23] <Maefs> hi
[21:23] <daftykins> hello
[21:24] <Maefs> how are you?
[21:25] <daftykins> not bad thanks, just relaxing here after some house painting - how's about yourself? what brings you here?
[21:25] <Maefs> i am very well
[21:27] <Maefs> i am looking to talk to someone about computing
[21:27] <Maefs> and you?
[21:27] <daftykins> anything specific?
[21:28] <Maefs> i can talk about everything... maybe computer security
[21:28] <Maefs> i need to improve my english
[21:29] <daftykins> ah, there might be more people active in #ubuntu-offtopic , there's also #ubuntu-discuss
[21:30] <Maefs> thank you
[21:30] <Maefs> why are you here?
[21:31] <daftykins> well i'm kind of in the UK - and i use Ubuntu servers
[21:33] <daftykins> private messages are usually best done after asking if it's ok
[21:35] <Maefs> ok
[21:35] <Maefs> sorry
[21:35] <daftykins> i've gotta go shower now :) cya later
[21:35] <Maefs> i will wait
[21:36] <daftykins> might make more sense for you to try joining the other channels if you want to find people to talk to
[21:37] <diddledan> so. been banging my head repeatedly all day trying to figure out what's going wrong with my kubernetes inbound traffic. turns out I had accidentally deployed a duplicate inbound rule which conflicted and was helpfully in a different section of config than I was looking
[21:37] <diddledan> yey for UI actually highlighting it when I got the dashboard up finally


[05:55] <hikiko> hello :)
[05:55] <hikiko> snow!
[06:56] <pitti> Good morning
[07:13] <hikiko> hi pitti
[07:13] <pitti> hey hikiko, how are you?
[07:14] <pitti> hikiko: seriously, snow in Greece?
[07:14] <hikiko> yeah :) in my city
[07:14] <hikiko> well, we have a lot of snow in greece (so many mountains) in the cities that are next to the sea it's rare :)
[07:15] <hikiko> winter :D :D :D
[07:32] <seb128> good morning desktopers
[07:32] <seb128> hey hikiko pitti
[07:33] <hikiko> hey seb128
[07:34] <seb128> it's freezing in Greece now?!
[07:34] <seb128> we are done with the warming, getting colder!
[07:34] <seb128> :p
[07:42] <hikiko> lol it's not freezing :) it's normal winter!
[07:43] <hikiko> finally :)
[07:44] <hikiko> it was very weird to have 15 and 17 degrees in november :p but anyway I have to stop the weather forecast :D
[07:49] <pitti> bonjour seb128 !
[08:00] <seb128> pitti, how are you?
[08:01] <pitti> seb128: f-f-f-f-reezing! :-)
[08:01] <pitti> seb128: nah, je vais bien, merci !
[08:01] <seb128> lol
[08:01] <seb128> it's still cold here as well but should get a bit warmer later on
[08:01] <pitti> seb128: j'ai eu du pizza et de la bière avec mon voisin hier soir, et on a vu "Star Wars V"
[08:01] <pitti> un soir d'hommes
[08:01] <seb128> like going from 0° to 7°C
[08:01] <seb128> haha
[08:02] <didrocks> some people prepare themselves for Star Wars 3.5 soon :)
[08:02] <didrocks> hey pitti, hikiko, re seb128
[08:02] <pitti> seb128: Annett was away on a christmas party with their colleagues
[08:02] <seb128> didrocks, when does it go out?
[08:02] <seb128> pitti, it's not even december yet!
[08:03] <pitti> didrocks: oui, mon voisin n'a vu jamais Star Wars -- donc nous faisons ça maintenant
[08:03] <didrocks> seb128: mid-december I think? I don't even really know :)
[08:03] <didrocks> ah, an illiterate, like I am! :)
[08:03] <didrocks> (catching up is still planned though)
[08:03] <seb128> whhhaaattttt
[08:03] <pitti> watching the old movies is a bit boring indeed, but you gotta start there of course
[08:04]  * seb128 needs to fix didrocks' culture next time we are romming
[08:04] <seb128> rooming
[08:04] <pitti> says the guy who never watched Star Trek!
[08:04] <didrocks> :)
[08:05] <seb128> one day
[08:05] <seb128> maybe
[08:05] <pitti> which clearly is the better of the two!
[08:05]  * pitti ducks and evades the gauntlet
[08:05] <seb128> I tried but speaking of nothing happening...
[08:05] <seb128> it's even more borring than the old starwars
[08:05]  * seb128 stops there before he crosses a line :p
[08:05] <pitti> yeah, we got spoiled by the modern movies with fast cuts
[08:06] <hikiko> hi didrocks
[08:06] <pitti> seb128: well, I can understand it -- the TNG stories were great, but I do appreciate that the narrative style is a bit slow for modern taste
[08:07] <seb128> right
[08:07] <seb128> damn modern world!
[08:54] <willcooke> morning all
[08:54] <willcooke> c..c..c..cold
[08:55] <chrisccoulson> hi willcooke :)
[08:55] <willcooke> how's it going chrisccoulson?
[08:55] <willcooke> I was going to ask you about you know what today, do you think it'll be done by EOY?
[08:56] <chrisccoulson> willcooke, yeah
[08:57] <willcooke> cool, thanks chrisccoulson
[09:02] <flexiondotorg> Good morning seb128 didrocks pitti willcooke chrisccoulson hikiko
[09:03] <willcooke> hey flexiondotorg
[09:03] <seb128> hey willcooke chrisccoulson flexiondotorg
[09:03] <chrisccoulson> nobody's using firefox, right? http://arstechnica.com/security/2016/11/firefox-0day-used-against-tor-users-almost-identical-to-one-fbi-used-in-2013/
[09:03] <chrisccoulson> hi everyone :)
[09:03] <seb128> how are you?
[09:03] <seb128> chrisccoulson, says the firefox maintainer? :p
[09:03] <Laney> brRRRRrrRRRrrrRRRr
[09:03] <hikiko> good morning flexiondotorg chrisccoulson willcooke Laney
[09:03] <chrisccoulson> seb128, I'm not the firefox maintainer :P
[09:03] <seb128> who is?
[09:03] <davmor2> Morning all
[09:03] <chrisccoulson> lol
[09:03] <seb128> hey Laney
[09:03] <hikiko> and davmor2 :p
[09:03] <chrisccoulson> seb128, it's you
[09:04] <flexiondotorg> Good morning Laney, davmor2
[09:04] <flexiondotorg> chrisccoulson, Have you spoken to anyone at Mozilla about snapping Firefox?
[09:04] <chrisccoulson> flexiondotorg, they're doing it
[09:04] <davmor2> morning hikiko flexiondotorg
[09:05] <flexiondotorg> chrisccoulson, Oooh. Excellent.
[09:05] <seb128> chrisccoulson, :-(
[09:07] <seb128> chrisccoulson, so we get to pick between an outdated chromium or a non-maintainer-buggy-but-uptodate firefox?
[09:07] <seb128> bah
[09:07] <seb128> way to escape the question!
[09:07] <seb128> oh, he's back
[09:07] <seb128> chrisccoulson, so we get to pick between an outdated chromium or a non-maintainer-buggy-but-uptodate firefox?
[09:09] <chrisccoulson> seb128, is firefox that bad?
[09:09] <chrisccoulson> I probably should use it again really
[09:10] <seb128> chrisccoulson, no, I'm enjoying it still, you are the one pointing the security issues and trying to escape maintainship :p
[09:11]  * pitti gives firefox a ♥ -- works fine and it's our default browser after all
[09:12] <pitti> I have occasional trouble with hangouts, but then who doesn't (most certainly it doesn't work perfectly in chromium either)
[09:13] <seb128> no it doesn't
[09:15] <chrisccoulson> seb128, oh, judgint the state of firefox from the current 0-day is probably a bit unfair - that's quite unusual, and there's a fix already ;)
[09:16] <seb128> :-)
[09:16] <ricotz> chrisccoulson, yeah fun :-)
[09:16]  * ricotz likes firefox too, of course
[09:17] <chrisccoulson> I did stay up until 3am this morning waiting for them to start builds but then got bored and went to sleep, so we'll probably end up being a few hours late with the fix
[09:17] <chrisccoulson> hi ricotz :)
[09:17] <chrisccoulson> hi pitti :)
[09:17] <pitti> hey chrisccoulson!
[09:18] <chrisccoulson> pitti, gutted to hear that you're leaving us :(
[09:18] <chrisccoulson> although, it does sound like you'll be having a lot of fun :)
[09:20] <chrisccoulson> seb128, anyway, we always have webbrowser-app if firefox and chromium suck ;)
[09:20] <pitti> heh, I hope :) I'll just try it and see if it suits me, but for sure I'm looking forward to being able to concentrate on two or three projects for a change and lose all these little maintenance tasks
[09:20] <chrisccoulson> yeah, I can imagine :)
[09:21] <seb128> be careful to not be too nice and end up in the same situation where everybody needs you!
[09:22] <pitti> yeah, I must learn how to say "no" :)
[09:25] <Laney> "<manager> man, this new hire 'pitti' refused all my tasks"
[09:25] <Laney> "* pitti drinks cocktails on the beach"
[09:25] <chrisccoulson> heh
[09:25] <pitti> ^ right, so my work day wouldn't change at all, just who pays for the cocktails!
[09:30] <willcooke> Did someone say cocktails?  I mean, it's a bit early, but ok.
[09:32] <pitti> willcooke: you didn't fully appreciate the concept of a world-wide distributed company yet!
[09:32] <seb128> willcooke, I though you said you would be at the office tomorrow, not today? :p
[09:32] <willcooke> haha!
[09:32] <chrisccoulson> I'm expecting a delivery of beer this morning. I think it's going to be a challenge to make it last the whole day
[09:34] <willcooke> chrisccoulson, do you use a subscription service?
[09:35] <chrisccoulson> willcooke, I don't, although I have been thinking about doing the beerhawk subscription
[09:37] <willcooke> chrisccoulson, I'll give you a Flavourly referal code.    Well worth it IMO
[09:47] <chrisccoulson> oh fun, I've ran out of disk space
[09:49] <willcooke> :/
[09:50] <chrisccoulson> lol, I have a single source tree that takes up nearly 200GB
[10:02] <hikiko> 200
[10:02] <hikiko> 200GB?
[10:03] <hikiko> wow.
[10:04] <chrisccoulson> hikiko, it contains a few build directories at nearly 50GB each. I should probably think about deleting some
[10:06] <hikiko> yeah but even 50GB is quite big :)
[10:06] <chrisccoulson> hikiko, don't ever get dragged in to browser stuff :)
[10:07] <hikiko> heh
[10:07] <hikiko> too late
[10:08] <hikiko> I am currently building gcc in 3 machines to have the same version same prefix and I am going to try distcc+ninja btw... I'll tell you my experience tomorrow (I am optimistic) ;p
[10:08] <hikiko> :s/prefix/suffix
[10:08] <chrisccoulson> sounds fun :)
[10:09] <chrisccoulson> I might be interested in that work ;)
[10:09] <chrisccoulson> (although, I can already build chromium fairly quickly)
[10:09] <hikiko> chrisccoulson, how?
[10:09] <hikiko> tell me the trick
[10:10] <chrisccoulson> hikiko, 64GB of RAM and one of these - http://www.samsung.com/uk/consumer/memory-storage/ssd/950-pro/MZ-V5P512BW
[10:11] <chrisccoulson> and I have a quad core xeon CPU in my laptop too
[10:15] <hikiko> lol
[10:15] <hikiko> ok
[10:16] <hikiko> I don't have such hardware:)
[10:16] <chrisccoulson> it still takes a while for a full build though. But not 9 hours :)
[10:16] <hikiko> but if I combine the RAM+cores of our 3 computers here it will be fast I hope
[10:16] <hikiko> yeah
[10:17] <hikiko> the 1st time was 9hrs
[10:17] <hikiko> and I didn't use all the cores
[10:17] <hikiko> I just followed the instructions in the manual ninja -C
[10:17] <hikiko> now I am using -j4
[10:17] <hikiko> and soon -j 16
[10:18] <hikiko> (with distcc)
[10:57] <marga> desrt, I'm having a super weird issue dconf related: after years of our /etc/dconf/db/site.d/foo settings working properly, they are suddenly not applying.  If I look in dconf-editor, it shows that the default is the wrong value (i.e. false when it should be true). I expect it's something that we changed last week or so, but I can't figure out what could cause this, any idea?
[11:01] <andyrock> morning
[11:04] <willcooke> hey andyrock
[11:05] <Trevinho> Laney: once andyrock ACKed the libappindicator change ;-), can you please check this https://bileto.ubuntu.com/#/ticket/2208 ?
[11:07] <desrt> marga: huh.  nothing should have changed with this.  what does the commandline tool say?
[11:09] <marga> which tool?  If I do dconf read or dconf dump, it shows the wrong value. But I have no way of knowing where the value is coming from.
[11:10] <marga> desrt, as I said, I'm pretty sure it's our fault, I'm just at a loss as to how to debug where the problem is
[11:10] <desrt> what release are we talking about here?  an LTS?
[11:10] <desrt> or did you do a dist-upgrade?
[11:10] <marga> Trusty
[11:10] <desrt> ya.... really really no changes there :p
[11:11] <marga> Freshly installed and updated to the latest security updates.  But I'm also seeing it on a different machine running a different release. So, pretty sure it's a config change on our side. :-/
[11:11] <desrt> try: touch /etc/dconf/db/*.d; dconf update ?
[11:12] <marga> desrt, I sort of tried that (editing one of the files there), but I'll try again.
[11:12] <desrt> some text editors do unsafe file access (and as a side-effect, the timestamp on the directory doesn't get updated properly)
[11:12] <desrt> a shockingly large number do this, in fact
[11:13] <marga> I edited with vim
[11:13] <marga> I'd hope it does this right :)
[11:13] <desrt> vim does it properly, i think
[11:13] <desrt> (and even if it doesn't, the .swp files in the directory would have modified the timestamp)
[11:14] <marga> Alright, tried this, no change.
[11:14] <marga> Is there any way I could figure out where the "bad" setting is coming from?
[11:16] <desrt> do you have locks?
[11:16] <marga> I tried reading the setting as root and it was also wrong. Also tried removing the .conf/dconf/user file.
[11:17] <desrt> weird.......
[11:17] <marga> desrt, yeah, the locks actually work correctly (i.e. I can't edit the setting manually). But I've tried removing them and the default is still wrong.
[11:17] <desrt> what is the profile?
[11:17] <marga> Ah! I forgot about that part.  Let me check, maybe we screwed that
[11:18] <desrt> there were some changes in the last year or so to how profile got picked, but i don't think you'd be seeing those in trusty
[11:18]  * desrt double-checks
[11:19] <marga> So, the profile _should_ be the one called "user", that contains "user-db:user system-db:local system-db:site"
[11:19] <desrt> ya... the profile selection stuff came much later than the version in trusty
[11:20] <marga> But it might be that we managed to screw that, maybe. How do I check which profile I'm actually using?
[11:20] <desrt> strace? :)
[11:20] <desrt> is DCONF_PROFILE set to anything?
[11:20] <marga> Nope
[11:21] <desrt> so then the tool should try to open /etc/dconf/profile/user, indeed
[11:21] <marga> Ok, I'll strace
[11:21] <desrt> strace dconf read /whatever
[11:21] <desrt> just to see what gets opened
[11:21] <marga> Yes, open("/etc/dconf/profile/user", O_RDONLY) = 3
[11:22] <desrt> (like, literally "/whatever" is a good choice, since there is no value here, it will result in less strace output)
[11:22] <marga> open("/etc/dconf/db/site", O_RDONLY) = 4
[11:22] <desrt> looks good...
[11:22] <marga> Yeah...
[11:22] <desrt> and the timestamp on 'site' is reasonable?
[11:23] <desrt> it's a bit of a shame that you are working with trusty... the tool grew some features lately that would be useful here
[11:23] <marga> Nov 30 12:12 /etc/dconf/db/site (11 minutes ago)
[11:23] <marga> desrt, I have a more modern system as well.  Both are experiencing the same, that's why I blame our configs.
[11:26] <marga> So, what are those fancy new features? :)
[11:28] <desrt> sorry.
[11:28] <desrt> so the main one is that you can list locks
[11:29] <desrt> dconf list-locks / will tell you if dconf thinks that you have any paths locked
[11:29] <desrt> (ie: this could be why user values are allowed to appear over system values that you think should be locked)
[11:30] <desrt> (no output = no locks)
[11:30] <marga> Ok, I had moved one file away (the one that locked the value that I'm using to track the problem).  I see the other locks with that. I'll put my lock file back in place
[11:31] <marga> Yep, the locks work fine.  It's the values that are broken
[11:31] <marga> From what I'm seeing, it might be that only booleans are broken.
[11:32] <desrt> this is very odd.
[11:32] <marga> Indeed.
[11:32] <desrt> everything is x86 here, ya?
[11:32] <marga> amd64
[11:32] <desrt> right
[11:33] <desrt> okay, so my advice: focus on a single key that is showing the problem
[11:33] <desrt> make those separate file-db profile files, one per each layer (site, local, user)
[11:33] <desrt> and query what dconf thinks each database says, and also if it sees a lock there or not
[11:33] <marga> How can I query each db?
[11:34] <desrt> write into a file called "myprofile" one line: "file-db:/etc/dconf/db/site" (or whatever single file you want)
[11:34] <desrt> then do DCONF_PROFILE=/path/to/myprofile dconf dump /
[11:34] <marga> BTW, I can confirm that only boolean values are affected.
[11:34] <marga> ok, will do
[11:34] <desrt> this is _really_ weird
[11:34] <desrt> did you try ints?
[11:34] <marga> yeah, I changed an int value and then queried it and it showed the new value.
[11:37] <desrt> other option: email me a .tar.gz of your /etc/dconf (complete with both .d directories and the compiled db files, and the profiles)
[11:38] <marga> I found the issue.  Someone created a second file that overwrote the values with wrong values.
[11:38] <desrt> party :)
[11:38] <marga> I was checking the file that I had created, and it had the right values...
[11:38] <marga> Sigh
[11:38] <marga> Thanks for your time :)
[11:39] <desrt> just glad i don't have a bug to fix :p
[12:46] <xnox> marga, you must love dconf a lot =)
[12:46] <marga> xnox, I actually find the site.d thing pretty neat
[12:46]  * xnox learned a lot about dconf from above
[12:47] <xnox> mostly that i really don't want to touch it
[12:47] <marga> :)
[12:47] <xnox> marga, when i want to change the defaults, i upload the package into Ubuntu and dist-upgrade =)
[12:47] <marga> Ah, but then you can't lock the settings away from the hands of misguided users :)
[12:48] <marga> (we are not mean, we only lock some specific settings, like the screensaver lock)
[12:48] <xnox> =)
[13:06] <Trevinho> Laney: this is all yours now https://bileto.ubuntu.com/#/ticket/2208 ;-)
[13:48] <Laney> THE BITS ARE FLOWING
[13:48] <Laney> Trevinho: ok
[14:13] <Laney> git bisect run you absolute beauty
[14:15] <pitti> Laney: well, it's more like a meticulous craftsman with a big hammer than a fairy, but de gustibus non disputandum est :)
[14:17] <Laney> de mortuis nihil nisi bonum
[14:18] <Laney> pitti: fair comment
[14:18] <Laney> my scripts are usually "git clean -fdx; make; make check"
[14:18] <Laney> hardly delicate
[14:18] <pitti> Laney: confused -- what is dead in that context?
[14:19] <pitti> Laney: heh, my usual one is a bit more elaborate: http://people.canonical.com/~pitti/scripts/systemd-bisect-run.sh.simple
[14:20] <pitti> here's to packages which can be sensibly tested with "make check" :)
[14:21] <Laney> pitti: there's a play (forgot the name) where those two phrases are confused
[14:21] <pitti> Laney: hm, curious; aside from being completely ignorant of Latin basics, it's hard to imagine how to confuse them
[14:21] <Laney> a misquoting IIRC
[14:22] <pitti> #ubuntu-desktop topics → is it Friday yet?
[14:23] <Laney> http://www.cynic.net/~cjs/degustibus.html
[14:23] <seb128> back to learn something fridays rather than troll fridays?
[14:24] <pitti> Laney: ah, thanks!
[14:24] <seb128> not enough larsu around nowadays :-/
[14:24] <Laney> pitti has rectified that one too
[14:24]  * Laney sobs
[14:25] <Laney> seb128: (fosdem)
[14:25] <seb128> right!
[14:26] <Laney> nothing like a cold and grey weekend in bruxelelelelels to regenerate yourself
[14:26] <seb128> :-)
[14:29]  * larsu waves to seb128!
[14:29] <seb128> hey larsu! wie gehts? ;-)
[14:30] <pitti> it's a larsu!
[14:30] <larsu> seb128: too dark!
[14:30] <larsu> otherwise great :) How are you?
[14:30] <pitti> "pink killer"??
[14:31] <larsu> pitti: hi! What's going on?
[14:31] <seb128> I'm good thanks, sunny here today and not night yet
[14:31] <pitti> larsu: eh? bright blue sky and sun here
[14:31] <larsu> pitti: rain and dark here :(
[14:32] <davmor2> Laney: man what did Pink do to you to deserve killing
[14:32] <davmor2> Laney: She sings okay songs if you don't like them just listen to something else ;)
[14:33] <Laney> davmor2: what happens at fosdem stays at fosdem
[16:35] <p_d> hy, After installing/downloading virtualbox completely..it gives me an error - http://imgur.com/a/MbMsf ..how to resolve it "Running VMs found"?
[18:01]  * flexiondotorg calls it a day
[18:01] <flexiondotorg> Night desktopers
[18:01] <willcooke> see ya flexiondotorg
[18:02] <seb128> night flexiondotorg
[18:03] <seb128> going to do the same here
[18:03] <seb128> have a nice evening desktopers and see you tomorrow
[18:03] <willcooke> night seb128
[18:03]  * willcooke follows
[18:03] <willcooke> London tomorrow
[18:03] <willcooke> ta ta
[18:30] <Laney> night too
[20:53] <ximion> Laney: are you *sure* that you uploaded the appstream patch? Because it is nowehere to be seen in Launchpad