[07:56] <Noskcaj> could someone confirm bug 1094997
[19:27] <Noskcaj> could someone confirm bug 1094997
[19:59] <Noskcaj> can someone confirn bug 1087848 and bug 1087409


[02:23] <sujx> anyone has been used debootstrap? when i Use debootstrap to build the ubuntu core system, the system is not stable and often crash
[03:24] <aeoril> darkxst /etc/init.d/gdm seems to have some additional bugs in vivid (not trusty) than just the syntax error.  Found this trying to test on vivid:  http://paste.ubuntu.com/10496518/
[03:24] <darkxst> aeoril, that is expected
[03:25] <darkxst> use restart (or stop gdm first)
[03:25] <aeoril> darkxst really?  just because the path used is different to the script?  That seems kind of odd ...
[03:26] <darkxst> aeoril, what are you talking about paths for?
[03:26] <darkxst> you ran gdm start, and it said gdm already running
[03:27] <aeoril> darkxst look at the paste - when I was testing, I tried to test using "./gdm" because I was in the /etc/init.d directory - it did not fail becasue of the syntax error.  But typing "../init.d/gdm" from the same directory hit the syntax error - then, from the same directory, "/etc/init.d/gdm" gave the proper error message, but never hit the syntax error
[03:27] <darkxst> aeoril, just fix the syntax error
[03:28] <aeoril> darkxst that is fine, but shouldn't we be concerned about the odd behavior?
[03:28] <aeoril> darkxst it doesn't act like that in trusty
[03:28] <darkxst> aeoril, I don't recommend you step into that world
[03:28] <aeoril> darkxst ok, I'll "keep it simple" then ... - just had anomalies during test, so figured I'd mention it to you ...
[03:28] <darkxst> there a ton of wrappers that hook all the various init systems command together
[03:29] <aeoril> darkxst yes, I went through some of them, loops, etc.
[03:29] <aeoril> pretty complex
[03:30] <aeoril> darkxst so don't even file a bug report?
[03:30] <darkxst> aeoril, you could file a bug
[03:30] <aeoril> darkxst I was definitely not thinking of fixing it myself ...
[03:31] <darkxst> aeoril, no one cares about sysv (in Linux anyway) anymore
[03:32] <darkxst> aeoril, I've been giving you trivial bugs so you can just concentrate on the packaging side
[03:32] <aeoril> darkxst ok, just trying to be helpful
[03:33] <darkxst> if you want a fun bug, thats more than just that, then bug 1385572
[03:33] <aeoril> darkxst ok, I'll take a look at it, but I will finish this bug to learn the packaging side of things better
[03:35] <darkxst> aeoril, btw invoke-rc.d is usually used for sysv scripts I think
[03:35] <darkxst> and that should have a wrapper that would re-direct to upstart or systemd init (or whatever you boot with)
[03:36] <aeoril> darkxst I will just do the syntax error fix then look at the next bug.  I really appreciate all the help
[03:37] <aeoril> darkxst I need to learn how to get a vivid fix back into 14.10 and 14.04 anyway
[03:41] <darkxst> aeoril, https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=https%3A%2F%2Fwiki.ubuntu.com%2FStableReleaseUpdates&ei=xtvzVKjEE8LbmAXZ2oHQDw&usg=AFQjCNFl9CrvGudijLLJ0UQ8dxx7Lj3WRQ&sig2=ht7tqyA-Zn9MmwlOf-demw&bvm=bv.87269000,d.dGY
[03:41] <darkxst> silly google links: https://wiki.ubuntu.com/StableReleaseUpdates
[03:42] <aeoril> darkxst good gosh!  But it worked!  Thanks ... :)
[03:42] <darkxst> aeoril, I can upload gdm, so all you need worry
[03:42] <darkxst> about is a  debdiff and the SRU paperwork
[03:42] <aeoril> ok - thanks
[03:43] <aeoril> darkxst getting tired, work further tomorrow - that glitch took all my time hunting down the odd behavior
[03:44] <aeoril> (it was not immediately apparent what was going on, so I was doing all kinds of crazy stuff devling into the scripts)
[03:44] <darkxst> aeoril, those things come with experience
[03:45] <darkxst> and wasting an enitre night chasing down a phantom bug, would be considered experience
[03:46] <darkxst> I've certainly done that before
[03:50] <darkxst> aeoril, our first realease was 12.10 and I spent the entire cycle fixing about 10 hard bugs
[03:55] <aeoril> darkxst 12.10 was the first release of Ubuntu GNOME?
[03:59] <aeoril> darkxst does Fedora still use GNOME as its default GUI?
[04:22] <darkxst> aeoril, yes and yes
[04:23] <aeoril> darkxst yes, I looked both answers up - the first release on releases.ubuntu.com is 13.04, though - I wasn't sure what you meant by "our first" - now I understand that what you meant a while back when you said "you should work on gnome" - you meant "Ubuntu GNOME" I guess
[04:25] <aeoril> darkxst why not?    I think it will be exciting to fix things in the desktop I have on my own pc.  I could never get that with Windows or Mac
[04:26] <aeoril> darkxst the whole FOSS thing is just amazing.  When I was starting out way back, that kind of thing did not happen as much - some, but not a lot
[04:28] <darkxst> aeoril, 12.10 was the first release
[04:28] <darkxst> 13.04 was the first as an official flavour
[04:29] <aeoril> darkxst yes, I figured it was something like that
[04:29] <aeoril> darkxst thanks for the clarification, though
[04:29] <aeoril> darkxst it is nice that it became an official flavour
[04:29] <darkxst> aeoril, we founded ubuntu GNOME to get contributors working upstream
[04:30] <darkxst> so work on GNOME fixing ubuntu bugs upstream kinda thing
[04:30] <aeoril> darkxst I am sorry, I do not sure what you mean - do you mean fixing upstream GNOME bugs that cause problems specifically with Ubuntu?
[04:31] <darkxst> aeoril, yes
[04:31] <aeoril> darkxst yes, that makes sense.  I really like the GNOME website - very professional.  Seems like a well run project
[04:32] <aeoril> darkxst well, I guess a whole "web" of interrelated projects really - it is very important to Linux, I think
[04:32] <darkxst> aeoril, although it wasnt really that specific it was more just have people contributing upstream from GNOME on ubuntu
[04:34] <darkxst> only problem is it has affected my time to work on upstream bugs
[04:34] <aeoril> darkxst oh, I see - where do you work?
[04:34] <aeoril> do you actually work for GNOME?
[04:35] <aeoril> (for pay?)
[04:35] <darkxst> aeoril, no, everyone on the ubuntu GNOME team is volunteers
[04:35] <aeoril> oh, sorry - I thought you said "at work" not "to work" - my mistake
[04:35] <aeoril> darkxst ^
[04:36] <aeoril> darkxst I thought "at work on upstream bugs" implied you actually worked for pay on the GNOME project or something
[04:36] <aeoril> (but you said "to" not "at")
[04:37] <darkxst> aeoril, no, distro patching every little annoyance is rubbish
[04:37] <aeoril> darkxst lol ok, so pay to work means crappy work?  You can't pick and choose?
[04:37] <darkxst> some packages have close to 100 patches
[04:37] <aeoril> wow
[04:38] <aeoril> darkxst oh, I see what you mean - "distro patching" meaning fixing all the nit-noid things that need to be done for each distro
[04:38] <darkxst> aeoril, nautilus has 20odd ubuntu patches which will be broken in 3.16
[04:39] <darkxst> aeoril, yes, mainly ubuntu though, they are the only distro visionary enough to produce their own product
[04:40] <aeoril> darkxst what do you mean by "produce their own product?"  Don't most distros have unique stuff in them?
[04:40] <aeoril> (I just don't know)
[04:40] <darkxst> aeoril, Unity?
[04:41] <aeoril> darkxst yes, I thought you meant that ...
[04:41] <darkxst> I don't know any other distro that ships their own DE
[04:41] <aeoril> What does DE stand for?  I cannot figure it out
[04:42] <aeoril> Distro Environment?
[04:42] <darkxst> aeoril, desktop-environment
[04:42] <aeoril> darkxst oh, ok - duh!
[04:42] <darkxst> gnome, kde, unity, etc
[04:42] <aeoril> yes, I understand
[04:42] <aeoril> I remember when Unity came out - it was GNOME or KDE before that ...
[04:43] <darkxst> aeoril, it was GNOME2
[04:43] <darkxst> up until about 11.10 (at a wild guess)
[04:43] <aeoril> right, the default was Gnome, IIRC - I did not like Unity when if first came out
[04:44] <aeoril> darkxst yes, that rings a bell
[04:44] <darkxst> Kubuntu, would have been around back then anyway (for kde)
[04:44] <aeoril> darkxst I think you may have nailed it - 11.04 -> Gnome2, 11.10 -> Unity, IIRC
[04:45] <aeoril> Back around 2011 I think
[04:48] <darkxst> aeoril, yes gnome-shell has really evolved since those early GNOME3 days
[04:48] <aeoril> darkxst yah, 2011 - I think it was when I was doing this (https://answers.launchpad.net/launchpad/+question/172028) - I think that was on "natty"
[04:48] <aeoril> darkxst or maybe "precise"
[04:49] <aeoril> darkxst yes, I was surprised at how much it had changed - I like the improvements
[04:49] <darkxst> aeoril, what do recipes have to do with anything?
[04:50] <darkxst> always seemed like a broken way to try things to me
[04:50] <aeoril> darkxst lol - just what I was into ... learning all about packaging and recipes and stuff - I don't remember why I was all into recipes
[04:50] <aeoril> darkxst I may have been directed that way, or I may have thought it was some kind of "correct" way of doing things or something
[04:51] <darkxst> look at how broken UDD branches are and then they automatically building random git branches
[04:51] <aeoril> UDD?
[04:51] <darkxst> lp:ubuntu/<package> branches
[04:52] <darkxst> aeoril, you already found that out right?
[04:52] <aeoril> darkxst that project was a "learning" project to figure out packaging
[04:52] <aeoril> darkxst yes, quite ... :P
[04:52] <darkxst> recipes don't help with packaging
[04:53] <aeoril> darkxst well, I was making a "super clean" package, and somehow making it work on the recipe led to some insights - I really don't remember all about what I was doing
[04:53] <darkxst> in fact they only even make sense on stable (bug fix only) branches
[04:54] <aeoril> darkxst unfortunately, I nuked that PPA (randconverse) - it was actually pretty funny - you had a "conversation" with the computer, and it said abusive, funny things to you randomly based on your inputs
[04:55] <aeoril> darkxst it was in C++
[04:58] <aeoril> darkxst I got all into the debian policy guides, extensively into building a package from scratch using only autotools, manually configuring all the .am files myself, learning all about the debian directory and everything - I was really trying to learn packaging from the "ground up".  However, I pretty much forgot all of it
[04:59] <aeoril> darkxst well, building a "build" from scratch using autotools would be more correct, then adding in the packaging stuff for debian/Ubuntu myself
[04:59] <aeoril> (its kind of coming back to me a little)
[05:01] <darkxst> ok, but I don't see the connection between autotools and recipes!
[05:02] <aeoril> darkxst I just don't remember ... maybe they were just separate things I thought I should learn about?
[05:03] <darkxst> aeoril, ok keep learning and then maybe you can make the distinction!
[05:04] <aeoril> darkxst Maybe I thought the "best" build environment was on launchpad using a recipe?
[05:04] <darkxst> aeoril, and now you know that is sbuild ;)
[05:04] <aeoril> darkxst that is what everyone says now!
[05:05] <darkxst> was probably pbuilder back then though
[05:05] <aeoril> darkxst yes, I was holding off using pbuilder until I learned the underlying stuff that pbuilder "hides" and makes easier ... trying to learn what was below pbuilder
[05:06] <darkxst> pbuilder doesnt hide anything
[05:06] <aeoril> darkxst well, I guess I just don't know what I thought I was doing then :(
[05:07] <darkxst> yes you said that already ;)
[05:07] <aeoril> darkxst maybe pbuilder automated things that I was trying to learn how to do automatically?
[05:07] <aeoril> s/automatically/manually/
[05:07] <darkxst> aeoril, nope
[05:08] <darkxst> pbuilder is very much like sbuild
[05:08] <darkxst> i.e take a clean chroot, install builddeps, build packes
[05:08] <darkxst> packages
[05:08] <aeoril> hmmmm ... then I just probably didn't even know back then what the heck I was doing, I guess
[05:09] <aeoril> darkxst yes, that makes sense
[05:10] <aeoril> darkxst I seem to remember feeling I was making great progress, though, and "experts" were helping me a lot
[05:12] <darkxst> aeoril, so make this your goal, find and a fix a bug that the "experts" can't fix ;)
[05:14] <aeoril> darkxst I just want to learn, have fun and contribute to something worthwhile.  And keep my skills up.
[05:15] <aeoril> darkxst It would certainly be wonderful to become an "expert" though - really know this stuff well
[05:16] <aeoril> darkxst with your help, I feel I have already come a long way, even just using Linux and understanding how it is put together
[05:16] <aeoril> sarnold and others have helped me too
[05:16] <darkxst> aeoril, but an expert in packaging or an expert in coding?
[05:16] <darkxst> the first is largely generic and there are a bu
[05:17] <darkxst> bunch of very expert packagers around this part that don't know any coding
[05:17] <aeoril> darkxst I am much more interested at becoming an expert at coding Linux
[05:18] <darkxst> aeoril, in which case you need to pick a project
[05:18] <aeoril> darkxst but, I have to be a competent and preferably accomplished packager, I would think, to work with the community best?
[05:18] <aeoril> darkxst I was thinking kernel/driver
[05:19] <darkxst> aeoril, maybe not
[05:19] <aeoril> darkxst but, you are the person who is helping me the most, so maybe I should go with GNOME because I need the help ...
[05:19] <aeoril> darkxst why not?
[05:20] <darkxst> aeoril, kernel code would be pretty scary for someone with no evidence of proper coding experience
[05:20] <aeoril> darkxst I have no evidence of proper coding experience?
[05:22] <darkxst> aeoril, I gues that is a little irrelevant, but open a random driver in the kernel and see if you can understand?
[05:23] <aeoril> darkxst well, I am just wondering - in working with me, have you gotten the impression I have no coding experience?
[05:24] <darkxst> aeoril, nope, because you haven't asked a single question about code I guess
[05:25] <darkxst> aeoril, and really I won't judge that until I see a patch ;)
[05:26] <aeoril> darkxst I have not been having a hard time following code, just using the tools (like git/bzr) and packaging.  Of course, the code changes have been trivial so far
[05:27] <aeoril> darkxst I made that one stupid mistake following the wrong code in the super-easy fix I am doing now, but oh well - it happens
[05:27] <aeoril> (not seeing the syntax error in the vivid /etc/init.d/gdm script)
[05:27] <aeoril> I was embarrassed about that one
[05:28] <darkxst> aeoril, vala?
[05:28] <aeoril> darkxst what about vala?
[05:28] <darkxst> have you used it?
[05:29] <darkxst> programmed even
[05:29] <aeoril> darkxst no, never - there was vala in my first bug I tried to fix though, so I saw some of it
[05:29] <aeoril> (the vim/gnome-terminal racey thing)
[05:29] <aeoril> vte3
[05:29] <darkxst> gnome-contacts need a titlebar fix
[05:30] <darkxst> probably similar to https://bugzilla.gnome.org/show_bug.cgi?id=745346
[05:30] <aeoril> I could try - bug?
[05:32] <aeoril> darkxst my background is embedded and real time design, mostly, C, C++, FORTRAN, assembler, Ada, JOVIAL, etc.  I think I was a reasonably competent programmer for all those years
[05:32] <darkxst> bug 1339355
[05:33] <aeoril> Most recently, since 2011, I took a hiatus from learning about Linux development to learn about JavaScript/HTML5/CSS3 - that was fun, but I think I like this better
[05:33] <darkxst> aeoril, you reliase gnome-shell/gtk is a funny combination of javascript and css?
[05:34] <aeoril> darkxst nope
[05:35] <darkxst> aeoril, there you go, gnome-shell UI is nearly entirely JS, and most all GTK theming is CSS (although generated from SASS now)
[05:35] <aeoril> darkxst I really learned an incredible amount in a short time doing JavaScript/HTML/CSS - it opened up whole new ways of thinking for me.  A wonderful experience
[05:36] <aeoril> darkxst I did some GTK/GDK coding on my last job, maybe 10 years ago?
[05:37] <aeoril> but just a littl
[05:37] <aeoril> e
[05:38] <aeoril> darkxst I have learned over time I am not a "great" coder, but I am good enough to make a solid effort and tend to be thorough and careful
[05:40] <aeoril> darkxst I will never be a "star" but I believe I bring value and can contribute well
[06:06] <aeoril> darkxst I was thinking about kernel/driver development because I have the most experience in C and have done quite a bit with low-level stuff interacting with hardware and firmware, or even writing firmware.  Since that is where most of my experience lies, I thought that was the best choice for me
[06:08] <aeoril> darkxst also, there seem to be some very good avenues to learn that stuff (kernelnewbies, osdev) so it might not be too bad
[06:47] <pitti> aeoril: yes, after checking out trunk you need to select a packaging backend; you can just ./setup.py build, that'll install the dpkg one
[06:47] <pitti> aeoril: I usually run PYTHONPATH=. gtk/apport-gtk [args]
[06:49] <pitti> aeoril: thanks for your MP! will look at it today, looks fine at first glance
[08:07] <dholbach> good morning
[08:11] <seb128> hey dholbach
[08:12] <dholbach> hey hey seb128
[08:12] <seb128> :-)
[08:25] <Mirv> is there an automated way to change Maintainer: to XSBC-Original-Maintainer: and add Maintainer: Ubuntu Developers<EMAIL_ADDRESS>[08:26] <Mirv> it'd be easy to automate of course, but I wonder if it's something that's already in some tool
[08:26] <pitti> Mirv: it's called "update-maintainer" :)
[08:26] <Mirv> ooh! :)
[08:26] <pitti> Mirv: in ubuntu-dev-tools
[08:26] <pitti> Mirv: it also DTRT for debian/control.in
[08:27] <Mirv> thanks a lot!
[08:49] <mitya57> Mirv: qtscript -2 from Debian will ftbfs on ppc64el, I have just uploaded a potential fix for that
[08:50] <mitya57> (and also uploaded an untested fix for qtwebkit)
[08:55] <doko> pitti: are you looking at the autopkg test failures triggered python3-defaults?
[08:55] <pitti> doko: yes, some 10 mins ago
[08:55] <doko> cool, thanks
[08:56] <pitti> infinity: speaking of which, it's not clear to me whether the upstart regression is induced by the new glibc, or if something else broke it
[08:56] <pitti> so I don't override that one for now
[08:57] <pitti> (although it probably isn't related to the new glibc)
[08:57] <Mirv> mitya57: thanks, I noticed you were working on those right at the moment.
[08:57] <infinity> pitti: Given nothing changed in that libc (other than the compiler/binutils used to build it), the odds of a regression are pretty low.
[08:57] <infinity> pitti: But not nil.
[08:59] <pitti> not ok 54 - with single line command writing lots of data fast and exiting
[08:59] <pitti> wrong value for bytes, expected 3145728 got 3018031
[08:59] <pitti> at tests/test_job_process.c:3886 (test_start).
[08:59] <pitti> jodh: ^ does that tell you anything?
[09:00] <pitti> that happened 4 times during the last 6 runs
[09:00] <infinity> pitti: But not 6 times?
[09:00] <pitti> infinity: right
[09:00] <pitti> but the history on http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-upstart/ looks like that's something recent
[09:00] <infinity> pitti: Smells like an intentionally racy test meant to test accidentally racy code. :P
[09:01] <infinity> Even the name of the test sounds racy.
[09:01] <pitti> so, http://launchpadlibrarian.net/198971296/glibc_2.19-15ubuntu1_2.19-15ubuntu2.diff.gz indeed looks unrelated
[09:02]  * pitti waves through
[09:02] <infinity> pitti: Right, the diff is *obviously* unrelated, but that doesn't rule out the toolchain having produced a broken libc.  Seems pretty unlikely that it would have produced whatever breakage we're seeing here, though.
[09:04]  * pitti leans on the retry button
[09:14] <infinity> pitti: Another example of why a static foo triggers bar mapping would be nice: linux uploads should trigger ubuntu-drivers-common tests.
[09:15] <pitti> infinity: yeah, I'm well aware of why this would be useful; new linux broke nvidia-304
[09:15] <infinity> pitti: I wonder if a new header in debian/tests would be a good place to document such magic.
[09:16] <pitti> infinity: no, it's not; if we had an index of all debian/tests/control, we would do reverse test dependency checking
[09:16] <pitti> and as we don't, adding new fields there doesn't help either
[09:16] <infinity> pitti: So, that specific case is meant to be covered by some automated testing we're going to be doing to make dkms in general block the kernel.  But still, it would have been awesome if u-d-c could have blocked it, which we could get with that sort of mapping.
[09:16] <pitti> we either need an additional external mapping in britney, or a Tests.gz index
[09:17] <infinity> pitti: Well, sure, a Tests.gz makes sense.  But we still need a header to define "should be triggered by: foo" when it's not actually a direct dep of the test or package.
[09:18] <pitti> how is that not a Depends: ?
[09:18] <infinity> pitti: Well, I assume autopkgtest follows the same "don't need to depend on Essential", for instance.
[09:19] <infinity> s/, for/rule, for/
[09:19] <pitti> right, you don't have to, but there's nothing stopping you from doing that once it becomes useful
[09:19] <infinity> But I guess you could just add explicit deps if you want the trigger, sure.
[09:19] <pitti> also, for this particular example, linux-headers isn't essential
[09:19] <infinity> No, true.  linux-headers isn't.
[09:20] <infinity> So, fair enough.
[09:20] <infinity> Are you looking to have a Tests.gz produced by apt-ftparchive and published in the archive next to Packages.gz, or externally produced?
[09:21] <pitti> the former would be nice, but I'm not going to do that myself; I could envision a cronjob on people and put it into http://people.canonical.com/~ubuntu-archive/ somewhere?
[09:21] <infinity> And does debian/tests/control end up in control.tar.gz or data.tar.gz?  Cause if it's the latter, that will be expensive.
[09:21] <pitti> no, debian/tests/control is per-source, it doesn't make sense in binary packages anyway
[09:21] <infinity> I'm guessing it's the latter, cause I doubt autopkgtest has ended up specced/supported in dpkg in any way yet.
[09:21] <infinity> Err, oh.  Right.  Derp.
[09:21] <infinity> Sorry, not away.
[09:22] <infinity> Nor awake.
[09:22] <pitti> so at most it could live next to Sources.gz
[09:22] <infinity> Check.  That would be VERY expensive to generate, then. :/
[09:22] <infinity> Since Sources.gz never unpacks source, it's just a concatenation of .dsc files, essentially.
[09:22] <pitti> but I think we should prototype it first on people.u.c., see what we need and how far we get with it, and then perhaps send lots of beer and flowers to cjwatson to put it into LP :)
[09:23] <infinity> It's not about beer and flowers, it's that there's no way I'd let the publisher be slowed down that much.
[09:23] <pitti> infinity: well, it's grepping Sources.gz for "Testsuite: autopkgtest", and unpacking a 1000 debian.tar.gz tarballs for debian/tests/control
[09:23] <infinity> Unpacking source is slow.  Very slow.
[09:23] <pitti> right, you definitively don't want to do that 3 times an hour
[09:23] <pitti> maybe once a week or so
[09:23] <pitti> it's more like Contents.gz than Sources.gz
[09:23] <infinity> pitti: Not a guarantee that it's debian.tar.gz, not the whole world is v3(quilt).
[09:24] <pitti> infinity: yeah, for those cases you need to dpkg-source -x the whole thing
[09:24] <pitti> buit we can optimize for v3-quilt
[09:24] <xnox> pitti: infinity: that one tries to catch a race. I ponder if it should declare "skip" when it didn't manage to race.
[09:24] <infinity> pitti: Doesn't it become a bit useless if it's doesn't match the archive, since we care about testing the ever-changing -proposed pocket?
[09:24] <pitti> we could even optimize for a debian.diff.gz, but that'd be a bit hackish
[09:25] <infinity> xnox: Well, I assume it *did* race, and hence failed.
[09:25] <infinity> xnox: If it's testing (and finding) a bug in the code could we, I dunno, fix the bug?
[09:25] <pitti> infinity: obviously, the more current the better; that was just an initial idea for a prototype
[09:25] <pitti> a more "rolling" db would obviously be better
[09:25] <infinity> pitti: apt-ftparchive doesn't pull dirty tricks like that, generally, it's more about trusting dpkg to know how to deal with its own formats.  This is usually saner.
[09:25] <pitti> whenever a source is uploaded, its debian/tests/control goes into that db
[09:26] <pitti> infinity: yeah, but really expensive
[09:26] <infinity> Quite.
[09:27] <infinity> pitti: But, since non-a-f archive probably need to know how to do this too, I guess we could attack it from a different angle and store tests/control on upload.  We already waste a ton of cycles there unpacking and validating.
[09:27] <pitti> that sounds ideal indeed, as we wouldn't have to download and unpack anything in additon
[09:28] <infinity> pitti: Not sure how I'd spec that in a DAK world, though.  And I do prefer universal solutions.
[09:29] <infinity> pitti: But in Soyuz, it would just become another source artefact, like .changes
[09:31] <infinity> pitti: And, derp.  There's perhaps the real solution.
[09:31] <infinity> pitti: Add a dh helper to take all deps from debian/tests/control and concat them to XS-AutoPkgTest-Depends, so they end up in .dsc
[09:32] <infinity> pitti: And then if and when this gets specced in dpkg, dpkg-source can do it on its own without said helper.
[09:32] <infinity> pitti: Done, clean, and it lands in Sources.gz
[09:32] <flexiondotorg> Morning. I need some help please.
[09:32] <flexiondotorg> There are some critical glib 2.43.x compatibility issues in MATE.
[09:33] <flexiondotorg> The MATE Debian maintainers (of which I am a memeber) requested an unblock in Debian to provide the patches we've prepared.
[09:33] <pitti> infinity: dpkg-source already adds the Testsuite: header, so it could just as well add the new one
[09:33] <flexiondotorg> That request was denied.
[09:33] <pitti> infinity: I thought about that, it'd just inflate Sources.gz even more
[09:33] <flexiondotorg> So I need to add the required patches directly to Ubuntu.
[09:33] <flexiondotorg> I have the patches, have built and tested in a PPA.
[09:34] <flexiondotorg> How do I proceed?
[09:34] <infinity> pitti: Oh, does it?  Wasn't sure if that was specced in dpkg or not.  Sweet.  That will make it much easier to get guillem to accept a patch for the Testsuite-Deps too.
[09:34] <infinity> pitti: A tiny inflation in Sources.gz is MUCH better than parsing source packages to generate yet another file.
[09:34] <pitti> infinity: https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=3e6253 and https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=db3c4ab FYI
[09:34] <infinity> pitti: Even if every source in the archive had a test-deps line, it wouldn't be that much more data.  About the same as adding a new hash.
[09:36] <pitti> let's say 5000 packages, 100 bytes dep line == 500 kB uncompressed, perhaps 100 kB compresssed
[09:36] <pitti> not that bad indeed, but measurable
[09:36] <infinity> pitti: Yeah, not really a big deal, the archive grows faster than that for other reasons.
[09:36] <infinity> pitti: And "Sources.gz is getting large because everyone keeps adding testsuites to their packages" is a problem I kinda would like to have.
[09:37] <infinity> pitti: Normal users (despite RMS arguing viciously to the contrary) shouldn't have deb-src lines enabled anyway, IMO.
[09:37] <pitti> +1 on that
[09:37] <infinity> pitti: And certainly not users who care about how long updates take; they turn it off.
[09:37] <pitti> it's a pretty big waste of download bandwidth
[09:37] <wgrant> 100 bytes?
[09:37] <flexiondotorg> dholbach, Have you the time to help point me in the right direction regarding glib2.43 patches?
[09:38] <wgrant> Would most packages really have that many?
[09:38] <dholbach> flexiondotorg, I would suggest asking in #ubuntu-desktop
[09:38] <pitti> wgrant: a wild guesstimated pessimistic average between a lot of packages just doing "Depends: @" and some needing a lot
[09:38] <dholbach> flexiondotorg, I'm in the middle of 3 things right now
[09:38] <infinity> wgrant: Header plus lots of deps, might average out to more like 50 or 75, but whatever.
[09:38] <dholbach> plus, the guys in #u-desktop are far more knowledgeable when it comes to glib than I am
[09:38] <pitti> wgrant: we also only have ~ 1300 tests, but the number has doubled every release for 4 releases neow
[09:38] <pitti> now
[09:38] <infinity> Either way, I don't think it's a big deal.
[09:39] <pitti> yeah, agreed
[09:39] <infinity> Sources.gz/.dsc feels like the right place for it.
[09:39] <wgrant> It does.
[09:39] <infinity> And the code to do that is simple and clear.
[09:39] <flexiondotorg> dholbach, Thanks.
[09:40] <infinity> It does mean we don't get the benefit until those old source packages are rebuilt with a new dpkg-source, but I suspect 95% of tests are in the 5% of packages that are uploaded quite frequently.
[09:41] <pitti> right; and in particular, we could upload ubuntu-drivers-common and glibc (i. e. the use cases which were particular important)
[09:44] <infinity> pitti: Right, I'm crazy tired, but can you file a bug on dpkg on assign it to me (or to yourself, if you're comfy with the perl in dpkg-source), and we'll discuss it with guillem too?
[09:44] <pitti> infinity: sure
[09:44] <infinity> pitti: Just copy-pasta some of the IRC log. :P
[09:45] <pitti> infinity: I'll file it to Debian BTS and CC: you?
[09:45] <infinity> pitti: Or that, I figured an LP bug to start with and we can work on the implementation in Ubuntu while talking guillem into taking it.
[09:46] <infinity> pitti: But we could just work directly in Debian, up to you.
[09:47] <infinity> pitti: I think there'd be value in us doing it ahead of Debian anyway, but obviously the biggest benifit is if it happens in Debian too, so we get the header in syncs.
[09:47] <pitti> infinity: right, so I thought we discuss it in a Debian bug, then implement it in Ubuntu, and send the patch
[09:47] <infinity> pitti: WFM.
[09:47] <pitti> but let's rather get agreement (or some input) from Debian first?
[09:48]  * infinity nods.
[10:00] <xnox> slangasek: thanks a lot for this post https://lists.debian.org/debian-devel/2007/02/msg00398.html
[10:24] <pitti> infinity: debian bug 779559, I CC:ed you
[10:24] <infinity> pitti: Ta.
[10:24] <pitti> bah, forgot wishlist, /me "bts"es
[10:25] <infinity> pitti: That should be Testsuite-Depends, I think, to match the existing Testuite: header.  But I imagine guillem will make the same argument.
[10:29] <pitti> infinity: yeah, I don't care that much about the precise name
[12:25] <aeoril> pitti ok, cool - I tried 'setup.py', and figured there was some command line argument to pass into it i was missing, but did not know what - I guess I should have looked at it better.  That was a challenging one to test for me, since I did not know the way to do it directly with the source code I downloaded, but I made due ...
[12:26] <aeoril> pitti you can see how I tested it in the MP comments
[12:38] <seb128> mvo, hey, is there any known issue with click/schroot/ecryptfs user directories?
[12:42] <seb128> "E: 10mount: umount: /var/lib/schroot/mount/click-ubuntu-sdk-14.10-armhf-ec6aaf62-31e0-47e9-b2f8-73f0b038fb4d/home/ubuntu: target is busy E: 10mount: (In some cases useful info about processes that E: 10mount: use the device is found by lsof(8) or fuser(1).) "
[12:42] <seb128> it's consistent here, it tries to unmount my real userdir for some reason, which of course doesn't work since I'm logged in with that user
[12:52] <flexiondotorg> Trevinho, Can you take a peek at this little merge proposal please? https://code.launchpad.net/~ubuntu-mate-dev/compiz/improved-compiz-mate-profile/+merge/251438
[12:52]  * Trevinho on it
[12:53] <ginggs> hi, anyone from ubuntu-archive around?  I need someone to remove pycuda i386 binaries (LP: #1426722) please, they are blocking nvidia-cuda-toolkit.
[12:56] <cjwatson> ginggs: done
[12:57] <ginggs> cjwatson: thanks!
[13:04] <mvo> seb128: not know to me at least, no.
[13:05] <seb128> mvo, hey :-)
[13:05] <seb128> mvo, wie gehts?
[13:05] <mvo> seb128: good, thanks! and you?
[13:05] <seb128> mvo, I'm good, thanks :-)
[13:05] <mvo> seb128: if you could file a bug I will have a look
[13:06] <seb128> mvo, I can try to debug as well, http://people.canonical.com/~seb128/clickfail.log is my qtcreator framework adding log
[13:07] <seb128> mvo, but I also have an issue that the click schroot can't be unmounted, which leads to spam, since it restores previous sessions on reboot and adds a new one
[13:08] <mvo> seb128: oh, so this might be releated I wonder - i wonder if that also happens in a fresh install / clena chroot
[13:09] <seb128> mvo, clean chroot? I don't have any of those, I had purged schroot because of those issues and cleaned the dirs, just tried again, it fails to create any because it tries to unmount the real homedir for some reason
[13:09] <mvo> seb128: ok
[13:10] <seb128> mvo, tried to create one from another user on the same machine, which isn't using ecryptfs
[13:10] <mvo> seb128: and same result with that?
[13:11] <seb128> mvo, sorry, "trying", it's running
[13:11] <mvo> aha, ok
[13:11] <seb128> I can let you know in a bit :-)
[13:11] <mvo> ta
[13:11] <seb128> yw!
[13:11] <mvo> yeah, I'm debugging some different problem right now, but I'm >< close :)
[13:11] <mvo> (hopefully)
[13:13] <seb128> mvo, k, I'm going to try to debug the click issue myself, but help might be welcome if you are available for that later on
[13:15] <mvo> seb128: please tell me once you finished the test with the other user :)
[13:19] <flexiondotorg> Trevinho, Thanks.
[13:33] <flexiondotorg> cjwatson, Can you take a quick peek at this please? https://bugs.launchpad.net/ubuntu-mate/+bug/1426436
[13:33] <flexiondotorg> cjwatson, I can't reproduce this. Does this look familiar to you?
[13:34] <flexiondotorg> cjwatson, Am I missing something in my seeds? Could it be EFI related? I have no EFI hardware.
[13:40] <cjwatson> flexiondotorg: After lunch.
[13:40] <flexiondotorg> cjwatson, Thanks.
[13:41] <ochosi> hmm, someone contacted me as xubuntu project lead and asked whether there is an easy way to download/get the full source of xubuntu14.10 (in order to run the code through fossology for license checking). frankly i have no clue, any of you got a pointer here?
[13:47] <pitti> didrocks: FYI, I updated bug 1312976 with some noninteractive commands how to set up a VM for nfs server+client
[13:47] <pitti> didrocks: after that works, we can test server and client separately, but that should be good enough for initial testing
[13:50] <didrocks> pitti: oh nice! I want to finish fsck+systemd autopkgtests first (the turnaround to get more complex issues dealt with the testbed installing lightdm is really slow), but then (I guess tomorrow), will jump on that!
[14:02] <cjwatson> flexiondotorg: It's broken because you turned off Recommends, and it works in Ubuntu because ubiquity Recommends: grub-pc.
[14:02] <cjwatson> (This is arguably a bit fragile ...)
[14:03] <cjwatson> flexiondotorg: I'd suggest http://paste.ubuntu.com/10501858/
[14:13] <doko> Mirv, Qt & GCC 5 ping
[14:13] <flexiondotorg> cjwatson, Thanks.
[14:14] <Mirv> doko: the destructor related symbol changes coming via Debian for the 5.4.1 in landing in ~two weeks
[14:15] <cjwatson> flexiondotorg: I think you should put this on your list of reasons to get back to being able to enable Recommends
[14:15] <flexiondotorg> cjwatson, I am contributing patches to indicator-* to add MATE support so I can eventually disable the no-install-recommends feature.
[14:16] <flexiondotorg> cjwatson, Thanks for looking.
[14:16] <doko> Mirv, cool, that's what I wanted to know
[14:17] <cjwatson> flexiondotorg: Cool.
[15:10] <slangasek> xnox: heh, that was a while ago
[15:12] <xnox> slangasek: but i did answer "wtf nis is loaded" and the other statement about BenC is still true I guess =)
[15:12] <slangasek> heh
[15:12] <BenC> ??
[15:26] <Laney> @pilot in
[15:30] <cjwatson> BenC: The context was https://lists.debian.org/debian-devel/2007/02/msg00398.html
[15:31] <BenC> Hehe
[15:31] <BenC> Yes, NIS and DFS had a hold on me at the time. Blame NASA
[15:32] <BenC> cjwatson, slangasek: Are you both still Debian developers?
[15:32] <cjwatson> Yep
[15:33] <BenC> cjwatson: I have an new GPG key I need signed so I can get my debian account reactivated (my account wasn’t closed in a nice way, so I have to basically re-do NM process).
[15:34] <BenC> Is there a protocol for verifying me via launchpad, but old GPG key, a picture of my photo ID signed by my old key, and getting my new key signed?
[15:34] <cjwatson> BenC: If I've signed your old key, and it wasn't revoked, I'm generally happy (if slow ...) to sign the new key given a signed statement of transition
[15:34] <cjwatson> BenC: Mail me
[15:47] <slangasek> BenC: my personal policy is similar, I wouldn't use launchpad as a proxy for id but I would sign a new key for someone I'd previously signed given a transition statement; but AFAICS I didn't sign your previous key so this doesn't help you :/
[15:48] <BenC> No, you didn’t.
[15:49] <BenC> I’m having difficulty locating Debian folks to get my signatures, so I’m reaching out to people who may be willing to secure by alternative means.
[15:50] <BenC> Although, I am going to Boston next week, so I might be able to rally some folks around there.
[16:28] <Snow-Man> BenC: Where-abouts are you..?
[16:35] <Snow-Man> BenC: If it's still "somewhere, VA", then we might be able to work something out..
[16:53] <BenC> Snow-Man: Hampton Roads area
[16:59] <Snow-Man> BenC: ok.  I'm in the NoVa area (right near dulles airport)
[17:00] <Snow-Man> BenC: Maybe we could meet in Richmond for lunch or something?
[17:00] <BenC> Snow-Man: That’s a good hike. Let me see what I can do in Boston, but I’ll let you know if I still need a sig after that.
[17:00] <BenC> Thanks
[17:00] <Snow-Man> k.
[17:00] <Snow-Man> I don't mind trying to work something out half-way
[17:01] <Snow-Man> BenC: and, of course, if you're flying through dulles or national and have a long enough layover, that'd probably work too.
[17:36] <alexbligh1> What's the canonical way to determine whether some is in trusty-proposed for an SRU? http://people.canonical.com/~ubuntu-archive/pending-sru.html is not showing the package concerned.
[17:37] <cjwatson> rmadison will tell you what suites a package is in
[17:38] <alexbligh1> cjwatson, I mean I have a bug which says it's been uploaded to trusty-proposed, but I can't see it in the Packages file or http://people.canonical.com/~ubuntu-archive/pending-sru.html , so I'm presuming rmadison wouldn't see it either.
[17:40] <alexbligh1> cjwatson, (and to be clear, rmadison does not show it)
[17:45] <Laney> @pilot out
[17:45] <Laney> will do a bit more tomorrow probably
[17:50] <cjwatson> alexbligh1: No, if rmadison doesn't show it then it isn't there.
[17:50] <cjwatson> alexbligh1: But what exactly does the bug say?
[17:51] <cjwatson> alexbligh1: "uploaded" could well simply mean "developer has uploaded it, but it's in the queue waiting for approval", in which case you'll find it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 (linked from near the bottom of pending-sru)
[17:52] <cjwatson> alexbligh1: apache2 is there and mentions your name, so that's probably it.
[17:52] <cjwatson> alexbligh1: And indeed I see that bug explicitly says "I have uploaded this to trusty-proposed and this now awaits review from the SRU team."
[17:53] <cjwatson> alexbligh1: That is, it needs review before it enters trusty-proposed.
[18:15] <infinity> BenC: I'd do a video call reading of fingerprints with you, if you're going to go to the effort to fake a call to the point where I believe it's you, you deserve the sig anyway.
[18:15] <BenC> infinity: I can do that. Which service, and when’s a good time?
[18:17] <infinity> BenC: hangouts, skype, whatever.  And sometime soonish?
[18:18] <BenC> Hangouts I can do.
[18:20] <BenC> infinity: Connected…just start it up
[18:22] <alexbligh1> cjwatson, https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1366174 says "I have uploaded this to trusty-proposed and this now awaits review from the SRU team. As Chris Arges looked at this previously, I'll ask him if he can look at this again now."
[18:23] <alexbligh1> cjwatson, I'd presumed (wrongly) that you could see what was in the SRU queue at http://people.canonical.com/~ubuntu-archive/pending-sru.html
[18:23] <alexbligh1> cjwatson, and yes I'm still going on about the same bug :-)
[18:28] <cjwatson> alexbligh1: Right, so as I said above.  Robie meant that it was waiting for review before being accepted into trusty-proposed.
[18:31] <alexbligh1> cjwatson, thanks
[19:41] <Noskcaj> ScottK, What should i be doing to get a +1 from you for MOTU next time i try?
[19:42] <Noskcaj> And is there any chance of me just getting the xubuntu packageset?
[19:46] <slangasek> hallyn_: bug #1358835.. did bugproxy get itself in a busy loop?
[19:48] <hallyn_> seems like
[19:48]  * hallyn_ out for lunch ,biab
[20:00] <bdmurray> pitti: there is still one outstanding apport merge-proposal from me
[20:37] <smoser> barry, sorry to bother you... what am i doing wrong:
[20:37] <smoser> http://paste.ubuntu.com/10506162/
[20:37] <barry> smoser: in a meeting.  will look when i'm done
[20:37] <smoser> thats lifed from https://oauthlib.readthedocs.org/en/latest/oauth1/client.html
[20:37] <smoser> k
[21:02] <Noskcaj> jpds, Are you planning to package the current release of efitools (1.5.2)? There's a fair few issues it fixes. If you do, can you drop the arches that won't build from d/control.
[21:24] <flexiondotorg> cyphermox, Are you about?
[21:30] <cyphermox> yes
[21:32] <infinity> Noskcaj: No need to drop arches.
[21:33] <infinity> Noskcaj: Having it dep-wait where gnu-efi and sbsigntool don't exist is fine, it this offending you somehow? :P
[21:33] <infinity> jpds: ^
[21:35] <infinity> Noskcaj: As a general rule, please don't recommend people drop arches unless the package is VERY arch-specific.  Nothing about EFI is meant to be arch-specific, and more arches should have those things working in time.
[21:36] <infinity> Noskcaj: It hurts no one to have packages dep-wait or ftbfs, and it's a handy pointer to porters as to what work could be done.
[21:39] <cyphermox> flexiondotorg: what's up?
[21:39] <flexiondotorg> cyphermox, Hey 😃
[21:39] <flexiondotorg> Are you super busy?
[21:41] <cyphermox> flexiondotorg: I can help
[21:42] <flexiondotorg> I raised a few package update bugs earlier. Some got actioned a couple more need updates.
[21:42] <flexiondotorg> Could you take a peek?
[21:42] <cyphermox> flexiondotorg: could you get me a list?
[21:43] <flexiondotorg> cyphermox, This one is kind of important. https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1427195
[21:43] <flexiondotorg> Get you on a list?
[21:43] <cyphermox> no on.
[21:43] <cyphermox> :)
[21:44] <flexiondotorg> cyphermox, Lost in translation :) What do you want me to do?
[21:44] <cyphermox> is this the only bug or are there more?
[21:45] <cyphermox> I think Laney may have meant to do this one
[21:45] <flexiondotorg> cyphermox, Well Laney was Patch Pilot today so looked at them all.
[21:45] <flexiondotorg> There are 2 over.
[21:45] <flexiondotorg> The meta package.
[21:45] <cyphermox> ok
[21:46] <flexiondotorg> And the settings - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1427182
[21:56] <barry> smoser: you need to "import oauthlib.oauth1" if you want to access a class from that submodule.  nothing special going on here, just standard python semantics (discounting os.path, which *is* a special snowflake)
[21:57] <smoser> barry, yeah. i got it.
[22:10] <doko> Mirv, is there an easy way to turn off PCH in the qt builds?
[22:14] <doko> Mirv, in qttools-opensource-src
[22:42] <Unit193> Hello.  While there is a new bugfix version, and it'd likely just be a better idea to just go to that, would someone mind taking a look at https://bugs.launchpad.net/ubuntu/+source/exo/+bug/1425972 ?  it fixes a problem with exo and the new firefox version that landed, in trusty, utopic, and vivid.


 Hi,has anyone been sucessful in connecting mobile broadband on Kubuntu? tried multiple times with different settings (it used to work on my old laptop with the same version of Kubuntu,just don't remember how got it set up) sam mobile,just probably something wrong,maybe i need to install something? Thanks!
[06:27] <Imaginatrix> Anyone have issues with sound streams not closing? Like if I play a youtube video, sometimes it will get stuck and still play after the app is closed.
[09:09] <lordievader> Good morning
[12:20] <BluesKaj> howdy all
 Hey blueakaj
 Opentoons seems cool
[22:56] <keithzg> @Swift110: Never heard of that before, but it does indeed seem cool (always nice to see FOSS applications for creating multimedia)
 Anybody know how to recover previous versions of Libre Office?  File>versions shows nothing! accidentally pasted over a whole load of work that I need so 90% of my document is missing now :(
[23:43] <swift110-phone__> Hey all


[13:38] <Brainstorm> Updates for Bangladesh: +214 cases (now 1.6 million), +2 deaths (now 27870), +19734 tests (now 10.4 million) since a day ago


[16:17] <Muscovy> Morning all.
[16:52] <Muscovy> I think we now have IRC logs.
[18:04] <Muscovy> http://irclogs.ubuntu.com/2010/08/30/%23ubuntu-tour.txt
[18:04] <Muscovy> Yep, we have IRC logs.


[07:25] <h0mer> hey can anyone help with me trying to SSH into a glance server (deployed using Cannonical openstack/juju)?  I dont know what key or username to use
[11:12] <hazmat> h0mer: juju ssh glance/0  .. user is typically 'ubuntu' on the cloud images used by juju.
[11:55] <h0mer> yep got it, but I had to ssh into the landscape server first (I'm using the cannonical openstack distro), which is what puzzled me
[11:55] <h0mer> thanks
[13:04] <h0mer> anyone know how I can restart the keystone component from juju?
[13:13] <coreycb> h0mer, I'm not sure there's a direct way to just restart services, but you could toggle a config option on and then off to restart them.  gnuoy, do you know a better way?
[13:15] <coreycb> h0mer, assuming verbose is already set to false.  juju set keystone verbose="true"; juju set keystone verbose="false".
[13:18] <coreycb> h0mer, you could also juju ssh in to the units and manually restart services.  that should be fine.
[14:30] <stub> Can I get a fresh run of http://reports.vapour.ws/all-bundle-and-charm-results/lp%3A%7Estub%252Fcharms%252Ftrusty%252Fpostgresql%252Frewrite ? I think the remaining rough edges are gone from the integration tests.
[14:38] <jose> stub: sure, I'll kick the tests in a bit
[14:38] <stub> jose: ta. whenever convenient - I won't be looking at any results tonight.
[14:39] <jose> stub: they should start running soon. just clicked the butto
[14:39] <jose> niedbalski: ping
[15:21] <niedbalski> jose, hey :)
[15:21] <jose> niedbalski: have a min for a quick PM?
[15:21] <niedbalski> jose, sure.
[16:08] <pmatulis> when destroying a juju environment, what is the point of the '-e <environment>' if you can specify the environment like this: juju destroy-environment <environment-name> ?
[16:29] <ddellav> pmatulis, i'm not sure what the actual reason is but If i had to guess It's either 1 of 2 things. Either the -e or inline option are deprecated to maintain functionality with old scripts, OR the -e option allows you to specify multiple environments where the inline option does not.
[16:29] <ddellav> again, just a guess.
[16:31] <lazyPower> pmatulis: its a positional arg now, but hositorically it was not
[16:31] <lazyPower> i beleive that is an artifact
[16:33] <ddellav> right, deprecated option from early dev.
[16:33] <ddellav> makes sense
[16:34] <lazyPower> ddellav: watching this plumgrid deploy on bare metal is kinda mesmerizing... lots of services lots of scrolling text
[16:35] <ddellav> you should deploy openstack sometime ;)
[16:35] <lazyPower> ddellav: plumgrid contains openstack <3
[16:35] <lazyPower> they are a bolt on SDN for carrier grade virtual network functions (NFV in teleco terms), you'll be seeing more of this after i finish my review(s) today
[16:36] <ddellav> do I have a video review to look forward to?
[16:36] <lazyPower> Possibly, but not in the immediate future. I'm routing through some internal cloudy type stuff that I Would have to capitalize on, and i'm pretty sure beisner has only let me the resources for the time being
[16:36] <lazyPower> but with some coordination, sure
[16:36] <lazyPower> https://insights.ubuntu.com/2015/04/15/plumgrid-joins-canonical-ubuntu-openstack-interoperability-lab/
[16:37] <lazyPower> here's the press release when they signed up for CPP and their overview
[16:37] <ddellav> nice
[16:43] <pmatulis> ddellav, lazyPower: muchos
[16:48] <lazyPower> denada
[17:16] <pmatulis> lazyPower: is it 'destroy-service' or 'remove-service'? another deprecation?
[17:19] <lazyPower> juju destroy-service is the perferred nomenclature i would think
[17:50] <marcoceppi> pmatulis: neither are being deprecated?
[18:32] <pmatulis> marcoceppi: why are there 2?
[18:32] <marcoceppi> pmatulis: same reason there's juju init and juju generate-config
[18:32] <marcoceppi> or juju terminate-machine and juju destroy-machine
[18:32] <pmatulis> marcoceppi: which is?
[18:32] <marcoceppi> aliases help improve discoverability and people probably couldn't decide on the best verbiage
[18:34] <pmatulis> marcoceppi: from a user's point of view, and from the Doc team's POV, it's bad to have duplication of commands. i suggest standardizing
[18:35] <marcoceppi> pmatulis: well that's not going to happen at all until juju 2.0 because we don't break backwards compatibility
[18:35] <marcoceppi> pmatulis: I haven't heard any users complain
[18:39] <pmatulis> marcoceppi: i'll follow up somehow. thanks for the info
[18:39] <marcoceppi> pmatulis: What problem are you trying to solve?
[18:43] <pmatulis> marcoceppi: globally, making juju easier to use. specifically, getting the documentation in shape. i don't want to have to write 'use this command or that command, they're the same' all over the place
[18:44] <marcoceppi> pmatulis: then just pick one, that's what Nick's done in the past.
[18:45] <marcoceppi> they're aliases, not slightly different invocations
[18:57] <pmatulis> this is beyond my mandate on the official docs but i would *like to* avoid users following some online doc that uses one and then having them encountering another one, possibly the official ones, that use another. it's just confusing and, to me, leaves a bad taste in the mouth b/c i'm not sure whether they are equivalent or whether one is a different invocation. the commands.md file also uses 'destroy-service' and then ...
[18:57] <pmatulis> ... underneath it uses 'remove-service'
[18:58] <lazyPower> pmatulis: i'm +1 for having consistent verbiage used throughout our docs and help commands
[18:58] <lazyPower> pmatulis: but i also think to marcoceppi's point, since we're maintaining backwords compat in the 1.x series the path forward today is to file bugs where appropriate to make it consistent, update the docs to use that same bit, and turn a blind eye to the aliases. We can address those as people ask
[18:59] <pmatulis> lazyPower: i'm fine with waiting until 2.x but we should just decide at that time and then go forward
[19:35] <ted> I heard a rumor on the street that Juju does some type of YAML validation.
[19:35] <ted> Does it? How does it do that?
[19:35]  * ted may have just ended up in the wrong part of town
[19:45] <wolsen> skylerberg, ping
[19:46] <lazyPower> ted: hey there o/
[19:46]  * ted waves
[19:46] <lazyPower> ted: when you say juju does yaml validation, can you expand on what you're expecting with that statement? as it seems pretty broad
[19:47] <ted> lazyPower, Like has a schema and checks to see if the YAML conforms to that schema.
[19:47] <lazyPower> ted: well it does some ridumentary things like check for sub keys of units, and it has a standardizd format for bundles
[19:47] <lazyPower> but aside from that, the yaml validation is largely on trial/error with deployer and quickstart depending on your flavor of the moment
[19:48] <ted> Okay, but there's no definition format that you're using.
[19:48] <lazyPower> https://jujucharms.com/docs/stable/charms-bundles
[19:48] <lazyPower> this is the overview of that format, and if i dig hard enough I may be able to surface an old bundles format doc
[19:49] <lazyPower> we're currently changing that spec and work is underway (and may have been completed) to finalize teh bundle v4 spec. Whats on thta page is the bundle v3 spec
[19:49] <lazyPower> but if you're looking for a pure schema document, I don't beleive one exists today
[19:49] <lazyPower> but i could be wrong
[19:49] <lazyPower> rick_h_: do you have anything to add here? we're talking bundles and specs ^
[19:50] <ted> Ah, okay. I won't be able to steal anything then :-)
[19:50] <lazyPower> ted: the other side of this is metadata/config in charms, and we do have schema validation on those baked into juju
[19:50] <ted> That file is getting complex, you guys are gonna need XML soon.
[19:50] <lazyPower> Ayyyyy
[19:50]  * JoshStrobl throws up at XML
[19:50] <lazyPower> ted: i doubt we'll convert to XML :)
[19:50] <JoshStrobl> Oh wait...did I do that out loud?
[19:50] <lazyPower> JoshStrobl: i would expect no less ;) o/ how are ya
[19:51] <JoshStrobl> lazyPower, doing well, how are you?
[19:51] <lazyPower> JoshStrobl: trying to complete my todo list so i can get into the audio lab
[19:51] <lazyPower> so good :) but busy
[19:51] <JoshStrobl> lazyPower, yea I caught the latest vibes you put up, loved it :)
[19:51] <lazyPower> THe raw studio sessions?
[19:51] <lazyPower> man those were terribad
[19:51] <JoshStrobl> lazyPower, any pointers to where I can catch up on Juju stuff? Like actual Youtube content to grind through.
[19:52] <lazyPower> new deck, new software, new everything... and hooooo i twas rough.
[19:52] <JoshStrobl> lazyPower, nah it wasn't bad man
[19:52] <lazyPower> JoshStrobl: yeah, the juju office hours for the last 3 months are a brilliant place to catch up
[19:52] <JoshStrobl> lazyPower, figured as much :D
[19:53]  * JoshStrobl has been out of the Juju loop for way too long and trying to catch up on the mailing list archive (still subscribed to juju mailing list) is like a needle in a haystack :D
[19:55] <lazyPower> yes, yes it is
[19:55] <lazyPower> we got chatty while you were away
[19:56] <lazyPower> we're publishing the current state of the union more often, including review-q highlights et-al
[19:56] <wolsen> skylerberg, I added a comment to your mp, ping me if you have questions on it/want to chat about it a bit
[19:58] <JoshStrobl> lazyPower, yea I noticed as much (about the chattiness, changed to daily digests due to the activity - which is awesome because it is lively)
[19:59] <lazyPower> :) that makes me happy
[19:59] <lazyPower> if we're getting so chatty you went to digest vs the 12 emails a month it used to be
[19:59] <JoshStrobl> It is also nice because I always know it is 1500, my phone chimes with the Juju daily digest :DD
[20:00] <lazyPower> its the little things ;)
[20:05]  * JoshStrobl begins watching playlist of Juju office hours to get up-to-speed
[20:20] <JoshStrobl> That moment when you see Jorge pound the up key and enter...then 5 minutes later finally opting to use "watch" :DD
[20:21] <JoshStrobl> Or was it Marco...
[20:21] <JoshStrobl> Oh...it was Marco. Thanks non-intuitive Hangouts UX
[20:22] <jcastro> JoshStrobl: plenty of time for the juju charm summit
[20:22] <jcastro> see the list
[20:22] <jcastro> lmk if you want to apply for sponsorship
[20:22] <skylerberg> wolsen: I read your review. I think your approach makes sense, the only reservation I have is that it is more complex than my current approach.
[20:23] <JoshStrobl> jcastro, no thanks :) doing this for my sanity mainly :D
[20:23] <jcastro> ack
[20:24] <wolsen> skylerberg, there's no doubt that it is slightly more complex and it results in having to make changes to more charms, but I do think its the right approach and provides the best overall user experience
[20:26] <skylerberg> wolsen: Yeah, I agree. I will change the code and update the merge request.
[20:26] <wolsen> skylerberg, if there's anything I can do to help, let me know
[20:27] <skylerberg> wolsen: Will do. Thanks.
[20:27] <wolsen> skylerberg, and sorry I wasn't on the same page with you before :(
[20:29] <skylerberg> wolsen: No worries, man.
[20:46] <rick_h_> lazyPower: sorry, sprinting and just now trying to catchbacklog
[20:47] <rick_h_> lazyPower: ted the juju actions work uses a spec called "json schema" and that's used for a pure schema validation and it's on the todo to add that to the GUI, update juju config schema to use it down the road, etc. http://json-schema.org/ and https://github.com/juju/gojsonschema
[20:49] <ted> rick_h_, Cool, thanks!
[21:07] <lazyPower> thanks rick_h_ :) i knew you'd have the magic answer
[21:07] <rick_h_> lazyPower: :)
[21:08] <rick_h_> lazyPower: fyi, email reply inbound to the big thread I'd love to get your feedback on
[21:13] <skylerberg> When a new relation is created does it trigger a relation-changed event after triggering relation-joined?
[21:16] <JoshStrobl> skylerberg, I do believe it is ran after -joined.
[21:16] <JoshStrobl> https://jujucharms.com/docs/stable/authors-charm-hooks#[name]-relation-changed
[21:16] <lazyPower> skylerberg: it does
[21:16] <lazyPower> skylerberg: the sequence is -joined, -changed (optionally run more than once depending on relation-set commands)
[21:17] <skylerberg> JoshStrobl, lazyPower: Thanks
[21:17] <lazyPower> inversely, -broken (runs when you remove relation, they still have communication established between the two), and -departed (no connectivity between the units. ship has sailed, adios)
[21:23] <cholcombe> ok question time
[21:24] <cholcombe> with relation_get am i supposed to return if i don't get the info i need in the hopes that the charm gets called again with more info?
[21:28] <marcoceppi> cholcombe: yes
[21:29] <cholcombe> marcoceppi, ok.  how do i know the difference in code between i didn't get a value and i'm never getting that value and i should fail?
[22:07] <marcoceppi> cholcombe: you don't, that's why we have extended status
[22:07] <marcoceppi> cholcombe: ie status-set waiting "waiting for x, y, z value to continue"
[22:07] <marcoceppi> cholcombe: and as long as the other charm implements the relation protocol properly (and isn't in an error state) all should be swell
[22:10] <JoshStrobl> oh lol. So catching up on Juju Office Hours. In the 30th July episode, when Jorge said "dog might wander in and out and talk about dev ops", literally lol'd. And suddenly makes me want to have some sort of Juju dog sweater...and I don't even have a dog.
[22:11] <marcoceppi> JoshStrobl: if jcastro has anything to say about it, he will tell you to get a beagle
[22:11] <JoshStrobl> :D
[22:15] <cholcombe> marcoceppi, ok cool i'll set the status so that people know what's going on
[22:15] <marcoceppi> cholcombe: +1 always use status all the time and everywhere
[22:15] <cholcombe> :)
[22:15] <marcoceppi> it's basically my drop in replacement for juju-log and it's amazing
[22:15] <cholcombe> interesting
[22:16] <cholcombe> that sounds like quite a good idea to me
[22:16] <cholcombe> you can see at a glance with status what is goign on
[22:16] <marcoceppi> cholcombe: yeah, and with juju-run you can have processes out of band of hooks set status :D
[22:16]  * marcoceppi picks up all the lightbulbs falling off cholcombe's head
[22:16] <cholcombe> marcoceppi, fancy :)
[22:16] <cholcombe> haha
[22:17] <cholcombe> marcoceppi, yeah this is giving me a lot of ideas of code i need to chance
[22:17] <cholcombe> change*
[22:20] <marcoceppi> cholcombe: as a protip, you can query the current status with status-get from the hook, as to prevent friendly "non-blocked" status from updating a blocked, waiting, or maintenance state `juju help-tool status-get`
[22:20] <cholcombe> marcoceppi, nice tip!
[22:21] <cholcombe> marcoceppi, i feel as though you just leveled me up haha
[22:21] <marcoceppi> yeah, extended status is like the best kept secret in charming
[22:21] <marcoceppi> I want to dedicate an entire summit session to "secrests in juju that shouldn't be secrets"
[22:22] <cholcombe> yeah i like that idea
[22:23] <marcoceppi> jcastro: ^


[15:59] <ogra> fnop
[15:59] <NCommander> #startmeeting
[15:59] <MootBot> Meeting started at 09:59. The chair is NCommander.
[15:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:00] <ogra> do we have persia ?
[16:00] <janimo> hello
[16:00] <ogra> hmm, doesnt seem like
[16:00] <NCommander> [topic] Specs
[16:00] <ogra> did anyone get a linklist with blueprint links ?
[16:00] <MootBot> New Topic:  Specs
[16:00]  * davidm says hello, 11.04 is out
[16:00] <NCommander> yay 11.04
[16:00] <ogra> davidm, oh, thats good news *g*
[16:01] <davidm> Indeed, too bad I was sleeping when it happened
[16:01]  * ogra doesnt have any idea what blueprints persia set up
[16:01] <ogra> which makes it a bit hard to discuss specs :)
[16:02] <davidm> there are a lot of blueprints and many may have to be renamed, currently there is no ARM track!!
[16:02] <ogra> and we wont get one ?
[16:02] <davidm> I'm asking for one, otherwise everything arm will shift to "other"
[16:03]  * ogra makes a note to tickle jcastro until he cries once a day at UDS if we dont get one
[16:03] <davidm> goto: https://blueprints.edge.launchpad.net/~davidm
[16:03] <davidm> all the current specs are at the bottom labeled  -o- something
[16:03] <jcastro> davidm: I've been in calls all morning, jono recommends putting them in existing tracks
[16:03] <jcastro> so like, foundations, etc.
[16:03] <janimo> I checked the list of BP yesterday, none of arm only linaro specs
[16:03] <ogra> fun
[16:04] <jcastro> (sorry to barge in, we can sort it post meeting if you'd like)
[16:04] <ogra> i didnt get email notification for any of the ones i'm assigned to
[16:04] <davidm> I did  not get any email either, I think it's borked
[16:04] <ogra> jcastro, thats sad
[16:04] <davidm> jcastro, yes lets sort it post meeting, 5thanks
[16:05] <ogra> well, that was our meeting ... we wanted to discuss specs, if we need to rename them its possibly best to discuss it now
[16:05] <davidm> Also we need to review any open natty spec's and either close them or move them forward
[16:05] <NCommander> so maybe we should go around one by one and discuss the specs we have or?
[16:06] <ogra> NCommander, well, we did that already in the call, i think the renaming would be important now
[16:06] <ogra> we know who does what (well, persia knows since he assembled a list)
[16:06] <davidm> ogra, the name is not important really it's either arm or other that is it
[16:07] <ogra> davidm, well ... i guess we have to live with that
[16:07] <davidm> if other it will be hard for folks to find but that is the only real impact
[16:07] <davidm> ogra, yea, I'm less then happy but I don't make the rules
[16:08]  * ogra would love to rant now about being ignored as arm dev by other devs all the time and now not even having our own track ... but i'm used to be treated as second class citizen nowadays
[16:08] <ogra> but i wont do that rant now :P
[16:08] <davidm> if we have to rename my plan is 	arm-o-boot-speed -> 	other-o-arm-boot-speed
[16:08] <ogra> that sounds good
[16:08] <ogra> so people can at least match arm
[16:08] <NCommander> guess that works
[16:09] <davidm> Yep it's the only way that folks that care about arm will find them if we don't have a track
[16:09] <NCommander> Lack of ARM track though is extremely annoying
[16:09] <ogra> NCommander, ++
[16:09] <davidm> OK moving on
[16:09] <GrueMaster> Sorry I'm late.  https://wiki.ubuntu.com/OmapNetbook is up.  Please check it for correctness, it was mostly a cut/paste from Maverick.
[16:09] <ogra> nothing to move to :)
[16:09] <ogra> specs was our topic today
[16:09] <davidm> well lest talk about specs that we have
[16:10] <ogra> GrueMaster, download link is wrong
[16:10] <davidm> first is arm-o-preinstall-pool ogra that is yours
[16:10] <GrueMaster> ogra: That's where I found the images.
[16:11] <ogra> yeah, its about putting the contents of the ship seed and langpacks into /var/cache/apt/archives om the images
[16:11] <ogra> GrueMaster, http://cdimage.ubuntu.com/releases/11.04/
[16:11] <ogra> davidm, i think that one is pretty straightforward
[16:12] <ogra> GrueMaster, dont say natty there
[16:12] <davidm> likely, do you have any guestimate on how much time it will take
[16:12] <ogra> a few days including testing
[16:12] <ogra> not more than one to techincally implement it
[16:13] <ogra> testing the langpacks actually get installed etc will be time consuming here
[16:13] <davidm> OK what I'd like is if all specs have a guestimate of time in them, could be wrong but it would be very helpful to know some rough idea
[16:13] <ogra> changing livecd-rootfs to fill the pool should be quick and easy
[16:14] <ogra> davidm, i know though (since we discussed it before) that NCommander had concerns doing it that way
[16:14] <ogra> so we should definitely discuss other ways to implement it at UDS
[16:15] <ogra> which might take more time
[16:15] <ogra> putting a time guestimate up for the specs before we discussed the final implementation feels a bit premature
[16:15] <davidm> that is OK lets try to get some very rough guestimates this week and next and the refine at UDS
[16:16] <ogra> hmm, k
[16:16] <ogra> oops
[16:19] <ogra> well, lets get this meeting moving then
[16:19] <ogra> NCommander, 	arm-o-seed-spices is yours
[16:19] <davidm> yep thanks
[16:19] <ogra> any time guesstimate ?
[16:19] <NCommander> Would estimate about a month if we stil want to implement it
[16:19] <NCommander> Needs some minor tweaks to LP and cdimage
[16:20] <ogra> that is: generic rootfs and overlay for /lib/modules and boot stuff, right ?
[16:20] <davidm> NCommander, if we still?
[16:20] <davidm> what are your thoughts?
[16:21] <ogra> davidcalle, it was discussed for natty already but never implemented
[16:22] <NCommander> ogra: It was more finer grain control for seeding things onto a per image basis
[16:22] <ogra> err, sorry DavidLevin
[16:22] <ogra> GAH !!!!
[16:23] <ogra> NCommander, well, i think the initial idea GrueMaster had was what he called hwpacks (not to mix up with linaro hwpacks though) to have overlays for images on the download server
[16:23] <ogra> which wuld put all hw specific bits in as an overlay over a generic rootfs
[16:23] <ogra> i think thats different from seeds
[16:23] <GrueMaster> Yes, the idea was to have some kind of compressed file with modified MLO & u-boot + any other bits specific to a platform.
[16:24] <ogra> anyway, 1 month is your ETA for it ?
[16:24] <GrueMaster> And a tool that would extract and update an image with these bits.
[16:24] <GrueMaster> Yes, sounds good.
[16:24] <ogra> k, lets move on
[16:24] <ogra> arm-o-faster-preinstall-filesystem
[16:24] <ogra> janimo, !
[16:25] <ogra> you will speed up our lives
[16:25] <ogra> how long will that take you ?
[16:25] <janimo> the SD alighn should be a week with testing
[16:25] <ogra> yeah, agreed, but thats not all of it, is it ?
[16:25] <janimo> the generic boot speed improvements depending on what the scope is
[16:26] <janimo> I did not research ionto the jasper part of the spec
[16:26] <ogra> oh, right, the arm-o-faster-preinstall-filesystem one was GrueMaster
[16:26] <ogra> i didnt match the line
[16:27] <GrueMaster> I plan on taking a natty image and converting the rootfs to various different filesystems to run benchmarks.
[16:27] <ogra> janimo, i think we can leave out jasper here ... and focus on bootspeed of the installed system
[16:27] <ogra> GrueMaster, just take into account resizeability
[16:27] <ogra> with your selection of filesystems
[16:27] <ogra> GrueMaster, any rough ETA ?
[16:28] <GrueMaster> Of course.  My idea is to continue to use the existing format and have jasper convert after resize.
[16:28] <janimo> so there is one spec for SD speed and the generic iterative boot improvements (which are general ubunut-foundation work)
[16:28] <GrueMaster> 1 month?
[16:28] <ogra> GrueMaster, k
[16:29] <ogra> GrueMaster, dont forget that convertion has its own danger ... it would be intresting to have user interaction though if you add a conversion anyway, so he can select what to conver to ;)
[16:29] <ogra> janimo, yeah, any time estimate for them ?
[16:29] <GrueMaster> My thought was to convert to an optimal fs.
[16:30] <GrueMaster> If you want user interaction, that is a whole nother ball game.
[16:30] <ogra> GrueMaster, and why not use that optimal one from the beginning ?
[16:30] <janimo> so SD align 1 week, ongoing boot speed at most a month - depending on how much we want to squeeze
[16:30] <GrueMaster> Because resize tools may not exist.
[16:30] <ogra> user interaction is trivial now that we have plymouth support in jasper
[16:30] <janimo> do a general bootchart/perf evaluation and pick low hanging fruits if there are
[16:30] <GrueMaster> For example, btrfs doesn't support resize, but there is a conversion tool.
[16:30] <rsalveti> we can even squeeze the boot time from u-boot if needed
[16:30] <ogra> can we all simply add the time estimates to the whiteboards for now ?
[16:31] <ogra> rsalveti, we should definitely cut down the autoboot timeout :)
[16:31] <rsalveti> yeah, 10 sec for omap 3
[16:31] <janimo> I'd think we should wait with all timing optimizations after the SD changes land, so we make sure we don't optimize something that won't be there with a better layout
[16:31] <janimo> this includes boot speed and firrefox startup speed
[16:32] <ogra> so add the right dependencies to your specs then
[16:32] <ogra> you can make one spec depend on another
[16:32] <janimo> right
[16:32] <davidm> ogra, good point
[16:33] <ogra> hmpf, i got 	arm-o-firefox-startup ?
[16:33]  * ogra cries
[16:33] <janimo> ogra, I am happy to take that
[16:33] <janimo> I did not know it exists
[16:33]  * NCommander raises hands
[16:33] <NCommander> I'M FREE, FREE FROM EVIL!
[16:33] <ogra> well my ETA would have been 6 years and counting for that one :)
[16:33] <janimo> heh
[16:33] <NCommander> janimo: I warn, the FF codebase will twist and distort your mind
[16:34] <janimo> I know upstream ff does a lot of work on startupperformance
[16:34] <ogra> anyone who would like it, i'm happy to give it away
[16:34] <janimo> but it is still slow (2-3 seconds on beefey desktop computers)
[16:34] <janimo> much of it due to sick extensions
[16:34] <janimo> NCommander, I am pretty sure when I get to the bottom of the uglies C++ file in FF I'll see a "NCommander wuz here" comment
[16:34] <ogra> on my ac100 its currently at 30sec or so
[16:35] <ogra> vs 10 in maverick
[16:35] <ogra> it got a lot worse in natty for me
[16:35] <ogra> so who takes it? janimo or NCommander
[16:35]  * NCommander still thinks we should ship Chromium but YMMV
[16:35] <janimo> me
[16:35]  * NCommander runs away
[16:35] <ogra> k
[16:36]  * ogra moves it over
[16:36] <janimo> I also think we should ship chromium FWIW
[16:36] <ogra> not sure about the security team implications here :)
[16:36] <ogra> we had that discussion at several UDSes already
[16:36] <jdstrand> whoa!
[16:37] <jdstrand> no way, not without a lot of discussion
[16:37] <jdstrand> upstream introduces regressions and then doesn't fix them for weeks
[16:37] <jdstrand> plus there is no advance warning on security issues, even though we have tried
[16:37] <ogra> heh
[16:37] <jdstrand> we are completely at the mercy of upstream
[16:37] <ogra> everyone is lurking today :)
[16:38]  * NCommander wonders if jdstrand has 'security' has a highlight
[16:38] <jdstrand> I think there may be a bp on it. micahg is the one to talk to if interested
[16:38]  * jdstrand will never tell
[16:38] <jdstrand> :)
[16:38] <ogra> TBH on natty chromium on the ac100 isnt much faster than FF
[16:38] <ogra> they are both slow like wet sponges
[16:39] <GrueMaster> ogra: We really can't use an unsupported system as a benchmark.
[16:39] <ogra> i didnt test on panda but wouldnt expect much difference
[16:39] <ogra> GrueMaster, come on
[16:39] <NCommander> We should ship lynx
[16:39] <jdstrand> +1
[16:39] <ogra> we used to ship w3m
[16:39] <NCommander> -1
[16:39] <ogra> why would lynx be better ? :P
[16:39] <NCommander> Its not emacs
[16:39]  * janimo writes up Add GLES2 backend to Lynx BP and assigns to NCommander
[16:40] <ogra> ++
[16:40] <ogra> i also want GLES animations in u-boot !
[16:40]  * jdstrand hands w3m-el to NCommander
[16:40] <ogra> add that to him too ... he said he has no evil yet :)
[16:40] <NCommander> how the heck are you supposed to accelerate a CLI application?!
[16:40] <jdstrand> plus, w3m-img is funky
[16:40]  * jdstrand stops being distracting now
[16:41] <GrueMaster> On my panda, ff comes up in 15 seconds first time, 5 seconds second time.
[16:41] <GrueMaster> Base image.
[16:41] <ogra> k, my MMC in the ac100 is probably a tad slower
[16:41] <janimo> GrueMaster,the logical solution is to skip the first start everytime
[16:41] <ogra> haha
[16:41] <ogra> well, lets move on ... there are more specs
[16:41] <ogra> arm-o-netinstall
[16:42] <ogra> thats mine
[16:42] <ogra> a week or less
[16:42] <ogra> arm-o-partman-chs ... NCommander
[16:42] <ogra> (that should really not have partman in the name)
[16:42] <NCommander> Need to research what it will take to get partman to write a partition table OMAP will like
[16:42] <NCommander> er, parted
[16:42] <ogra> well, the question is, do we want to use it at all
[16:42] <NCommander> (parted appartantly grew CHS paritioning when no one was looking, but damned if I can find documentation)
[16:43] <NCommander> ogra: to be discussed?
[16:43] <ogra> you could add such stuff to the new flash-kernel-installer architecture as a hook
[16:43] <ogra> or some such
[16:43] <ogra> yeah, that will need a lot of discussion
[16:43] <NCommander> ogra: uh, that won't work.
[16:43] <ogra> and wont be easy to implement
[16:43] <NCommander> Lets discuss at UDS
[16:44] <ogra> a typical NCommander spec then ;)
[16:44]  * NCommander shouts family-unfriendly words
[16:44] <ogra> mind wrapping and hard to do ... :)
[16:44] <ogra> NCommander, make sure to invite cjwatson or ev to the session
[16:45] <NCommander> ogra: is TI going to be at UDS?
[16:45] <ogra> NCommander, any eta ? 4 months ?
[16:45] <ogra> not clear yet
[16:45] <ogra> probably not
[16:45] <NCommander> I'd like to know specifically what there bootrom needs
[16:45] <NCommander> ugh
[16:45] <ogra> the TI guys from the linaro landing team will  probably be around though
[16:45] <ogra> they should be able to help
[16:45] <cjwatson> NCommander: partman/alignment=cylinder, probably
[16:46] <ogra> and i thinnk rsalveti knows some internals about the rom code too
[16:46] <cjwatson> (and if you aren't using partman, why not ...)
[16:46] <NCommander> cjwatson: you've been implementing useful features again :-P
[16:46] <ogra> cjwatson, rom code fo omap expects a certain CHS setup
[16:46] <rsalveti> yup, and the trm can help here, usually they put the restrictions there
[16:47] <ogra> right, but lets discuss that at UDS :)
[16:47] <rsalveti> sure :-)
[16:47] <ogra> 	arm-o-port-lightspark
[16:47] <ogra> janimo, !!!
[16:47] <ogra> flash for everyone !!
[16:48]  * NCommander suspects ligthspark has some sorta JIT in it
[16:48] <janimo> well, would be nice to have a foss flahs p[layer on arm
[16:48] <micahg> does gnash not work on arm?
[16:48] <janimo> lightspark is promising if still not too mature(ponly suport youtube)
[16:48]  * micahg knows it FTBFS last time around
[16:48] <ogra> micahg, works fine ... exactly one time for me
[16:48] <janimo> micah yes it fdoes
[16:48] <ogra> and then never again until next boot
[16:48] <janimo> but most flash content is moving AIUI towards actionscript3 /Adobe Virtual MAchine 2 which gnash does not implement
[16:49] <ogra> we could indeed just add an auto-reboot to its code ;)
[16:49] <ogra> and just release note it *g*
[16:49] <NCommander> ogra: so we'd turn it into Microsoft WIndows?
[16:49] <janimo> lightspark needs some more testing and optimizations for arm
[16:49] <janimo> maybe 3 weeks
[16:49] <ogra> NCommander, win has such a cool feature ?
[16:50]  * NCommander thinks emulating Microsoft's design decisions w.r.t. to error handling (auto-rebooting) is a bad idea
[16:50]  * ogra was surely not serious :)
[16:50] <ogra> anyway, moving
[16:50] <janimo> crash-only software is not that bad if it boots up fast enough :)
[16:50] <ogra> which gets us to the next spec :)
[16:50] <ogra> arm-o-preinstall-sd-optimisation
[16:50] <ogra> i think we covered that above
[16:51] <ogra> 	arm-o-uboot-tftp
[16:51] <ogra> another famous janimo spec
[16:51] <janimo> NCommander, the JIT is LLVM based (and quite experimental) so should not be an issue, as that is the point of using LLVM
[16:51] <janimo> only the SD one, uboot is not my cup of coffee :)
[16:51] <janimo> that's rsalveti right?
[16:51] <ogra> well, its assigned to you atm
[16:51] <janimo> hmm, weird
[16:51] <ogra> tsk
[16:51] <ogra> no, you are right
[16:52] <ogra> i cant read today or the CSS on LP tricks me
[16:52] <ogra> i always catch the wrong line
[16:52] <GrueMaster> Maybe your laptop.
[16:52] <ogra> rsalveti, so tftp in uboot :)
[16:52] <janimo> uboot == testing booting == testing hw == cables all over the desk == chaos
[16:52] <ogra> GrueMaster, i'm working on a 24" screen atm
[16:52] <rsalveti> lol
[16:53] <rsalveti> should be easy to work with, if the patches are really in a good shape and working :-)
[16:53] <ogra> and if not ?
[16:53] <ogra> take the worst case for the time estimate
[16:54] <rsalveti> then we clearly need some work, probably around 1 month
[16:54] <ogra> k, put that in the whiteboard
[16:54] <ogra> NCommander, !
[16:54] <rsalveti> sure
[16:54] <ogra> 	foundations-o-image-build-docume...
[16:54] <ogra> long title :)
[16:54] <ogra> LP chopped it
[16:54] <ogra> NCommander, i think thats just "take notes while helping ScottK to implement mx5 images"
[16:55] <ogra> so we have a wikipage for later community images
[16:55] <ScottK> I thought it was me watching.
[16:55] <NCommander> I was actually looking at documenting the stack
[16:55] <ogra> ScottK, well, you being the customer, we help and document :)
[16:55] <NCommander> A large problem of ANYONE trying to do anything with our infrastructure is there is a big "?" when you go look for documentation
[16:56] <ogra> NCommander, seems a bit over the top, but your spec, as you like :)
[16:56] <ogra> NCommander, ETA ?
[16:56] <NCommander> Two weeks, plus however long it takes my test vict^W^W ScottK to run through it
[16:56] <ogra> hehe
[16:57] <ogra> make it 4 weeks then, to be on the safe side
[16:57] <NCommander> k
[16:57] <ogra> we will have finalized times after UDS anyway
[16:57] <ogra> i doubt they will stick
[16:57] <ogra> kernel-o-flash-kernel-postinst ... thats me
[16:58] <ogra> and largely implementing the postinst logic of grub into our kernel images for flash-kernel ... i will pester cjwatson and apw for that at UDS
[16:58] <ogra> two weeks i'd say
[16:58] <ogra> i think thats all specs ...
[16:58] <ogra> NCommander, take over the meeting again (and sorry for hoggin it )
[16:59] <ogra> (you have 1min for AOB and closing ;) )
[16:59] <NCommander> [topic] AOB
[16:59] <MootBot> New Topic:  AOB
[17:00] <ogra> nothing here
[17:00] <janimo> are these all the specs?
[17:00] <NCommander> janimo: feel free to donate more
[17:00] <ogra> janimo, yeah
[17:00] <janimo> do we get more (possibly from others?)
[17:00] <ogra> we will
[17:00] <NCommander> ANyway
[17:00] <janimo> ok
[17:00] <NCommander> if nothing else
[17:00] <NCommander> closing in 3
[17:00] <janimo> 2
[17:00] <NCommander> 2
[17:00] <ogra> 1
[17:00] <NCommander> \1.5
[17:00] <janimo> 2
[17:00] <NCommander> 3
[17:00] <ogra> 0.5
[17:00] <NCommander> #endmeeting
[17:00] <MootBot> Meeting finished at 11:00.
[17:00] <ogra> 1.725
[17:01] <ogra> bah
[17:01] <janimo> cheers
[17:01] <ogra> thanks all ... enjoy the post release relaxation !
[17:03]  * ScottK wonders what that is (just did two toolchain uploads ...)
[18:48] <gaara> i cant blv i waited soo long for 11.04 and finally ended up with having a ridiculous unsolved backlight issue! cant see anything in it! safer being with 10.10
[20:47] <Ahmuck> sorry, wrong channel


[03:44] <ejat> morning
[03:44] <ejat> lama nye rase x masuk irc nie
[11:34]  * wariola is away: I'm busy
[15:26] <maiz> helloo


[07:49] <lordievader> Good morning
[15:37] <jak2000> hi all
[15:39] <quantic> sup
[15:39] <jak2000> i have a clean installation of ubuntu server 14.04, how to do, create 1 user:JAK and do FULL root Privileges? (visudo and copy root ? 2) how to add user and add privileges but, i want, this user cant see the JAK home directory and root directory?
[15:40] <quantic> jak2000: that's something easily found via google.
[15:40] <jak2000> i try
[15:40] <quantic> Try harder.
[15:41] <jak2000> and found: type visudo then look the line: root    ALL=(ALL:ALL) ALL  and copy and modify...
[15:41] <jak2000> but i think i gave all privileges ot user?
[15:41] <quantic> jak2000: don't just copy things without understanding what they do.
[15:42] <quantic> jak2000: do a little more research, you'll thank yourself in the long run
[15:42] <jak2000> quentic, ok, google: "ubuntu adduser with limitations" ?
[15:43] <quantic> jak2000: what, exactly, do you want to do? in clear terms, please.
[15:44] <jak2000> i want add an admin user, but with not ALL root privileges, can update, can create directories, change permissions only the home directory of the user, change permisions to /var/www directory and ONLY
[15:45] <quantic> jak2000: try reading the "sudoers" man page.
[15:46] <jak2000> ok, thanks
[21:57] <Kalimero> my server still fails to restart by cronjob. can someone tell me where in the logs i have to look and maybe help me to fix it?
[21:58] <ikonia> you should see cron logs in the syslog, or you should write error trapping in to the script
[22:06] <Kalimero> i looked in it. thats the last thing before i hard restart it.Sep 13 06:03:24 mom kernel: init: tty4 main process (980) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: tty5 main process (983) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: tty2 main process (990) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: tty3 main process (991) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: tty6 main process (994) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: cron main process (1076) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: irqbalance main process (1095) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:24 mom kernel: init: tty1 main process (1936) killed by TERM signal
[22:06] <Kalimero> Sep 13 06:03:29 mom kernel: device p1p1 left promiscuous mode
[22:06] <Kalimero> Sep 13 06:02:12 mom logger: cluster stop
[22:09] <Kalimero> sry for the flooding
[22:16] <Kalimero> it seems the server is unable to shut it down completely but i dont know how to solve this problem
[22:18] <sarnold> Kalimero: does shutdown -r  work alright?
[22:20] <Kalimero> sarnold: shutdown -r works fine like it should
[22:21] <sarnold> Kalimero: crazy. I wonder hyw it fails in your cron :(
[22:25] <Kalimero> the first thing was the playmouth-shutdown which failed to stop correctly so i added a sleep 2 after its exec command. that solved the problem for a while but now its back
[22:27] <sarnold> I don't think plymouth is there foranything important; you might try removing it entirely.
[22:32] <Kalimero> sarnold: its removed hope it solves the problem and hopefully didnt screwed a needed function ^^
[22:33] <sarnold> :)
[22:33] <Kalimero> sarnold:  if not i am here tomorrow and ask you again ;)
[22:35] <sarnold> hehe :D
[23:33] <Tangurin> Hi! I can't upload files via PHP. The upload folder have 777 rights, and it works on my localhost + it worked before?
[23:35] <sarnold> Tangurin: do you have any errors in your logs?
[23:36] <Tangurin> sarnold: no there was no error
[23:37] <Tangurin> I am 99% sure this is no code error. Should I check what permission the file has which is executing the upload?
[23:37] <sarnold> is it being executed from apache or nginx or php-fpm or something similar?
[23:37] <sarnold> or are you running it as a stand-alone executable?
[23:39] <Tangurin> I am using Laravel (PHP framework), so it is Apache PHP via the web browser
[23:39] <Tangurin> sarnold: the controller file has this permission: -rwxrwxr-x
[23:40] <sarnold> Tangurin: does it perhaps give you better error messages if you run the browser onthe same computer as the web server?
[23:40] <sarnold> or perhaps you can run it in a development mode or something similar
[23:41] <Tangurin> sarnold: The application is running in dev mode, and I just tried on the localhost without any problem which declares that the code works, right?
[23:42] <sarnold> "worked once" isn't what I'd call "known to work", eheh
[23:44] <sarnold> you'll have to put in some time to change variables until you find out what fixes it -- try it from mutliple hosts, try uploading multiple types or sizes of files, collect the error messages from browsers and servers and the application, figure out what works and what doesn't, and try to determine the variable upon which the whole thing pivots
[23:44] <Tangurin> sarnold: Now I see that the image is uploaded but it is when the PHP is trying to create a thumbnail of the image
[23:44] <Tangurin> sarnold: Okey,but now I got: WriteBlob Failed
[23:46] <Tangurin> sarnold: Thank you for trying to help me, I appreciate your time! I found out that the upload worked but it was when PHP tried to create a thumbnail to another folder which did not have www-data as owner
[23:47] <sarnold> Tangurin: aha! :)
[23:48] <Tangurin> sarnold: Do you know how I can force the files to be www-data even if I upload via SFTP? Because when I use SFTP all my files gets wrong owner and all gets... broken haha
[23:50] <sarnold> Tangurin: nothing easy; unix provides for ways to ensure e.g. a specific group is set on files created in a directory, but nothing for user.
[23:51] <Tangurin> sarnold: Aha I understand. But how do I solve the problem with the files getting wrong permissions. Like this which happened now, the folder had wrong owner that's why I couldn't "upload" the file
[23:53] <sarnold> Tangurin: mostly you just have to know which user ids are used by which programs, know which directories they need to use to do their job, and set the ownerships appropriately when you install and configure them.
[23:54] <Tangurin> But if I am logged in via SFTP and create a folder, then I create a new "object" which has no configuration
[23:54] <sarnold> allowing uploads via a web server is unfortunate, I really like to configure web servers so they only have write access to e.g. their logs and a database socket, if they need to use a database to get their work done. but that's not always possible.
[23:54] <sarnold> it does have configuration, it is created with whatever owner and group you used to log in as ..
[23:55] <sarnold> if it needs to be owned by someone else, you can ssh in and use chown to change the owner as approrpriate..
[23:57] <Tangurin> sarnold: I understand why it is like this and that is a problem yes. But how do webhosting companies solve it? When user logs in and upload files, it still works.
[23:59] <sarnold> Tangurin: there's a lot of range in webhosting companies... some more or less create entire new virtual machines for each user, and those users are given root to those machines, and are expected to manage it all themselves


[08:05] <LocutusOfBorg> doko, firefox?
[08:05] <LocutusOfBorg> let me see, I'm not aware!
[08:07] <LocutusOfBorg> if you mean "firefox" ppa, it is building boinc-daily https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox
[08:07] <LocutusOfBorg> it takes some minutes, it is an automatic nightly build, not something I trigger
[08:10] <LocutusOfBorg> please point me to a build, and I'll stop it in the automatic ppa builds
[08:10] <joelkraehemann> nacc: yes, there are 3 patches total
[08:33] <LocutusOfBorg> oh, I read it only now, yes it was boinc, but it takes not that much, and only when new code is pushed upstream (and the project is not so highly developed right now...)
[08:34] <LocutusOfBorg> damn, I now read "bionic" each time somebody writes "boinc"
[08:34] <LocutusOfBorg> stop calling releases with similar names of packages under my ddpo! :p
[09:51] <seb128> doko, some of the ftbfses in the rebuild are "dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC ", do you know if something was pulling in dh-python before and stopped doing so?
[12:09] <fbo> Hi everyone
[12:09] <fbo> I'm trying to install Bionic via netinst/preseed/... and it fails (I've got more details here). Is it already supposed to be working or should I wait until the official release?
[12:09] <doko> seb128: yes, please point me to those. I'll fix them
[12:46] <rbasak> LocutusOfBorg: please could you take a look at bug 1762915?
[12:46] <rbasak> Sounds like the Breaks/Replaces is wrong.
[13:16] <rbasak> cpaelzer: may I have some help with bileto please? I've never used it before, and it isn't obvious to me how to supply an upload to it.
[13:22] <cpaelzer> rbasak: sure, HO so I can show you tihngs?
[13:22] <cpaelzer> standup HO link?
[13:22] <rbasak> ack, omw thanks
[13:23] <cpaelzer> just clsoing a few things ...
[13:50] <LocutusOfBorg> sure rbalint
[13:50] <LocutusOfBorg> s/ rbalint / rbasak
[14:53] <rbasak> LocutusOfBorg: do you have an ETA for that please? I need to rebase my nearly-ready 3.6 branch on it.
[14:55] <nacc> joelkraehemann: ok, i'll review them today
[14:56] <LocutusOfBorg> doko, I see your test rebuilds results... can you please look at keyutils? it seems terribly java rework related
[14:56] <LocutusOfBorg> yes rbasak sorry was afk
[14:57] <LocutusOfBorg> doing it now
[14:58] <nacc> doko: along the same vein, i'm told that since 17.10, possibly, netbeans hasn't worked?
[14:58] <nacc> doko: we might need the newere netbeans (8.2) to be java9 comaptibile
[14:59] <LocutusOfBorg> uploading in some seconds
[15:00] <LocutusOfBorg> sorry rbasak this seems a stupid mistake, just change ubuntu2 to ubuntu4 should fix it
[15:00] <LocutusOfBorg> in case, let me know if somebody complains :)
[15:00]  * LocutusOfBorg is not aware of an easy way to check once stuff has migrated
[15:01] <LocutusOfBorg> uploaded rbasak
[15:01] <rbasak> LocutusOfBorg: a breaks/replaces problem usually leads to a bug report like in this case. Thank you for fixing promptly :)
[15:05] <tseliot> Wimpress: hi, I think I need your help debugging LP: #1756226
[15:06] <Wimpress> tseliot: Sure, in a meeting now. But let me know what you need and I'll help in a bit.
[15:08] <tseliot> Wimpress: thanks. Please have a look at my comment in the bug report
[15:11] <doko> nacc: feel free to update netbeans
[15:11] <nacc> doko: :)
[15:11] <nacc> doko: i'll take a look if i can
[15:11] <doko> or use 8 explicitly
[15:11] <nacc> doko: yeah, that might be the simplest choice, i'll check it out
[15:20] <seb128> doko, https://launchpadlibrarian.net/363906839/buildlog_ubuntu-bionic-i386.libunity_7.1.4+18.04.20180209.1-0ubuntu1_BUILDING.txt.gz , update-notifier was one but that got fixed it seems, adding the build-depends on dh-python is easy but it doesn't tell us what changed in a incompatible way that force us to fix other packages now and that late in the cycle
[15:23] <LocutusOfBorg> rbasak, can you please grab it from there? http://launchpadlibrarian.net/364563021/mongodb_1%3A3.4.14-3ubuntu1_1%3A3.4.14-3ubuntu2.diff.gz
[15:25] <rbasak> LocutusOfBorg: yeah I'll grab from unapproved to unblock me for now, thanks
[15:25] <LocutusOfBorg> oh, I got the problem
[15:25] <LocutusOfBorg> it was not a wrong  version
[15:25] <LocutusOfBorg> it was that debian moved also manpages
[15:25] <LocutusOfBorg> so I had to bump it
[15:25] <rbasak> Oh.
[15:26] <rbasak> Yeah, I should have probably moved the manpages.
[15:26] <LocutusOfBorg> maybe this 1:3.4.14-3ubuntu1 would have been more correct?
[15:26] <LocutusOfBorg> let me reupload
[15:32] <LocutusOfBorg> http://launchpadlibrarian.net/364567650/mongodb_1%3A3.4.14-3ubuntu1_1%3A3.4.14-3ubuntu2.diff.gz
[15:33] <LocutusOfBorg> this one looks better to me
[15:33] <LocutusOfBorg> rbasak, ^^
[16:27] <Wimpress> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1756226/comments/27
[16:30] <rbasak> LocutusOfBorg: you forgot to run update-maintainer. Please leave it as-is though to save me rebasing again.
[16:36] <LocutusOfBorg> thanks sure
[16:36] <LocutusOfBorg> I don't like to run update-maintainer TBH, it makes merges difficult with the usual std-version bumps
[16:37] <rbasak> AIUI, it's basically a policy requirement to run it for us.
[16:37] <rbasak> (since that's what Debian concluded they wanted)
[16:38] <LocutusOfBorg> but what is the effect of this?
[16:38] <LocutusOfBorg> it is really annoying :/
[16:38] <nacc> we really don't want bug reports going to debian for ubuntu delta
[16:38] <nacc> (imo)
[16:39] <LocutusOfBorg> how can ubuntu-bug report to BTS?
[16:39] <LocutusOfBorg> I admit I don't report a bug since a lot of times
[16:39] <rbasak> Some users email the listed maintainer.
[16:39] <Wimpress> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1756226/comments/28
[16:39] <nacc> LocutusOfBorg: people (regularly) use the listed maintainer
[16:39] <LocutusOfBorg> seriously? :( this is ankward
[16:40] <rbasak> LocutusOfBorg: this discussion happened (and was resolved) years ago: https://wiki.ubuntu.com/DebianMaintainerField
[16:40] <nacc> LocutusOfBorg: we get emails to ubuntu-devel-discuss periodically, for sure
[16:41] <nacc> (which is what update-maintainer inserts)
[16:57] <TJ-> there's a script for that!!? I always change it manually :)
[16:57] <nacc> TJ-: yes :)
[16:59] <TJ-> ahh, not so relevant to my own private builds though.
[17:02] <tseliot> Wimpress: ok, so, you seem to have a different problem, which the option certainly doesn't help: (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
[17:03] <Wimpress> tseliot: Ah, OK.
[17:04] <tseliot> Wimpress: so, the nvidia driver is not really working, maybe because your kernel module failed to build (?), and telling X to use nvidia as the main GPU is not going to help
[17:04] <tseliot> Wimpress: "dkms status" should tell
[17:27] <Wimpress> tseliot: nvidia, 390.48, 4.15.0-13-generic, x86_64: installed
[17:27] <Wimpress> virtualbox, 5.2.8, 4.15.0-13-generic, x86_64: installed
[18:11] <nacc> doko: sigh, ftbfs :/
[18:32] <tumbleweed> win 32
[18:32] <tumbleweed> grr
[20:49] <jbicha> I get emails from people that see my email in the debian/changelog…
[20:57] <slangasek> jbicha: I get emails from people who see my launchpad ID attached to package removals that I've mirrored from Debian... so... ;)
[21:00] <jbicha> "thank you" emails I'm sure :)
[21:01] <tjaalton> ahasenack: hi, is bind9 9.11.3 planned for bionic? I'm seeing a crash on startup when configured for freeipa
[21:01] <tjaalton> was wondering if it might help
[21:01] <ahasenack> no, wasn't planning on that
[21:01] <ahasenack> what kind of crash?
[21:01] <tjaalton> ../../../lib/dns-pkcs11/view.c:960: REQUIRE(view->zonetable != ((void *)0)) failed
[21:02] <jbicha> I should start signing my changelogs as "Debian's Automated Developer" https://launchpad.net/ubuntu/+source/libnfs/2.0.0-1~exp1
[21:02] <tjaalton> I'll check if it's just misconfiguration
[21:02] <ahasenack> tjaalton: are you in a chroot?
[21:02] <tjaalton> no, vm
[21:03] <ahasenack> I mean, is named configured to run in a chroot?
[21:04] <tjaalton> ah
[21:05] <tjaalton> don't think so
[21:05] <ahasenack> check /etc/default/bind9 for the "-t" parameter iirc
[21:05] <ahasenack> it's not a default
[21:05] <tjaalton> nope
[21:20] <teward> bdmurray: i've got a user who wants to test an upgrade from 16.04 to 18.04, and is trying to use `do-release-upgrade -d` to do that, but gets the error "Upgrades to the development release are only available from the latest supported release."  I'm assuming that this is by-design and that a 16.04 -> 18.04 upgrade path won't exist until release?
[21:20] <teward> nacc suggested I prod you with the question
[21:20] <bdmurray> teward: it works for me. whats in /etc/update-manager/release-upgrades?
[21:21]  * nacc considers that a successful referral
[21:21] <teward> bdmurray: good question, I'll have to get the information.  https://askubuntu.com/questions/1024147/cant-do-release-upgrade-d-from-16-04-to-18-04 is where I'm asking, since it's on my radar as well
[21:22]  * teward isn't testing the upgrade path yet, himself.
[21:22] <bdmurray> teward: what I'd say is the answer there
[21:23] <teward> OP must have a broken system or a broken do-release-upgrade because they said they did that already in response to the answer.
[21:23] <teward> but i'll keep an eye on it, if there's nothing more they should be doing beyond that answer
[21:23] <teward> god-forbid something in 16.04 exploded horribly and prohibits the upgrade path
[21:23] <teward> (does do-release-upgrade work on server as well?  If so I can test a direct upgrade with a 16.04 VM... wouldn't dare do that in a container but... :P)
[21:23] <bdmurray> then they should maybe remove the cache met-release file
[21:24] <bdmurray> then they should maybe remove the cached meta-release file
[21:25] <nacc> teward: yeah it does
[21:27] <tsimonq2> I did try this myself in a Lubuntu VM the other day; a fresh Lubuntu 16.04 install, fully updated, throws that exact message at me.
[21:28] <teward> bdmurray: given tsimonq2's statement, maybe this is a larger bug?
[21:28] <teward> tsimonq2: unless you don't have the latest release upgrader software?
[21:28] <tsimonq2> teward: Possibly. I'll give it another try.
[21:29] <teward> because it *looks* like this works, at least in a container.  Will test a dedicated VM later, once I'm at home/
[21:29] <bdmurray> tsimonq2: clear out your cache in ~/.cache/update-manager-core/ if you get an error
[21:29] <tsimonq2> bdmurray: ack
[23:26] <tsimonq2> bdmurray, teward: Ah, it's working now.
[23:26] <tsimonq2> Specifically, `sudo do-release-upgrade -d` from LXTerminal on a fresh Lubuntu 16.04 install, fully updated.