[00:26] <persia> superm1, I've not heard of any reports of that, and end up chatting with folks using those preinstalled images daily.  How are you constructing the preinstalled?  Are you using jasper?
[00:27] <superm1> persia, i'm reproducing it using a standard daily x86 image actually
[00:27] <superm1> i was asking ogra since that's the only place i know people are reliably testing oem-config (gtk) regularly
[00:27] <persia> He may know more than I.  Aren't there also folk in -testing that are running OEM installs as one of the test cases?
[00:28] <superm1> i tricked apport into reporting it (https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/641478)
[00:28] <ubot2> Ubuntu bug 641478 in ubiquity (Ubuntu) "debconf-communicate crashed with SIGABRT in __kernel_vsyscall() (affects: 1) (heat: 10)" [Medium,New]
[00:28]  * persia has a suspicion that the various hack-arounds in jasper differ from those in casper sufficiently to cloud the issue
[00:28] <superm1> well the big difference there to here is whether there is a user 'oem'
[00:29] <superm1> which might actually be playing into this potentially
[00:30] <persia> For jasper-initiated things, I think ogra forced running as root to avoid having to clean up after the creation of an oem user.
[00:31] <superm1> i've got a snapshot in a VM up to this point, i can see if it reproduces with the user 'root' for oem-config instead of oem easily
[00:35] <superm1> it looks like running as root prevents the crash
[00:35] <superm1> that does lead to other problems though, like the sound applet being broken
[00:35] <persia> And networking, and ...
[00:36] <superm1> yeah and all that fun stuff
[00:36] <persia> On the other hand, it becomes obvious where the paths differ, so the bug becomes more traceable (and it's known that jasper images can't help)
[00:37] <superm1> removing the oem user shouldn't be too much trouble on these jasper images, is there a reason it can't be done?
[00:39] <persia> ogra was in a hurry that day?
[00:40] <superm1>  assuming this other issue can get cleaned up, it would probably improve the experience on the jasper images to switch to oem if possible
[00:40] <persia> Really, there's N things wrong with jasper, even if you ignore the architecture, coding style, and all implementation details.  I've had firm promises that it will receive a complete rewrite.
[00:41] <persia> That said, I doubt ogra will want to change it unless it's required to avoid regression at this point, and if other tools cause that regression, he's likely to want them reverted rather than change jasper.
[00:42] <persia> (but I'm guessing: I don't really have a transcript of ogra's stream-of-conciousness printing out next to my desk)
[03:01] <cjwatson> persia: jasper jasper livecd-rootfs arm I need a smoke
[03:02] <cjwatson> persia: there you go (sorry ogra ;-) )
[03:03] <cjwatson> hm, insomnia does odd things to my sense of humour apparently
[09:10] <persia> cjwatson, Ah, so you have the teletype :)
[09:44] <ogra> superm1, i have seen it once when i worked around the issue with creating an oem user so that might prove your theory
[09:45] <ogra> cjwatson, i smoke in my office :)
[09:46] <ogra> (fridays are just insane for me sorry if i give a weird impression on these :) )
[19:11] <CIA-28> ubiquity: superm1 * r4400 ubiquity/ (bin/oem-config-wrapper debian/changelog):
[19:11] <CIA-28> ubiquity: Prevent a crash of debconf-communicate when removing oem-config.
[19:11] <CIA-28> ubiquity: (LP: #641478)
[23:41] <CIA-28> ubiquity: superm1 * r4402 ubiquity/ (debian/changelog ubiquity/i18n.py):
[23:41] <CIA-28> ubiquity: Raise privileges when running the language page in only-installable
[23:41] <CIA-28> ubiquity: mode. (LP: #647792)
[23:54] <CIA-28> ubiquity: superm1 * r4403 ubiquity/debian/changelog: add bug number


[08:52] <zniavre_> good morning
[08:53] <zniavre_> i switched to gnome-shell cause many bugs with gtk-nocsd and many applications, this is solved with this new 7.6 version of unity ?
[08:54] <zniavre_> im quite happy to try again unity
[22:38] <franko> do we currently have a functional caps lock indicator for Unity?
[23:30] <franko> Workrave applet's not working any more, either... :-/
[23:31] <franko> *indicator


[10:22] <niluje> blackboxsw: smoser: I just pushed the split of unittests
[10:23] <niluje> I hope this is okay
[12:43] <smoser> niluje, yeah. great.
[12:43] <smoser> in a MP its ok to add commits or to push --overwrite
[12:44] <smoser> adding commits is actually easier for the reviewer, and you can comment 'addressing review feedback' or something.
[12:48] <niluje> smoser: MP?
[12:48] <niluje> merge proposal?
[12:49] <smoser> yeah.
[12:49] <niluje> k
[12:50] <smoser> mp, pr, mr, pm
[12:50] <niluje> do you want me to merge the commits into one then?
[12:50] <smoser> all but the last oen make some sense :)
[12:50] <smoser> i'll squash it when i pull
[12:50] <niluje> okay
[12:53] <niluje> if you have anything you want me to change, feel free to ask :)
[13:55] <smoser> powersj, blackboxsw rharper comments on
[13:55] <smoser>  https://public.etherpad-mozilla.org/p/qxREmZaciZ
[13:56] <smoser> are welcomed.
[14:34] <powersj> smoser: made one word change, otherwise looks good
[14:35] <smoser> hm..
[14:35] <smoser> what did you change? i only see my color
[14:37] <smoser> blackboxsw, ^ i think you were working on a way to check that group... that we could use in c-i to inform people.
[14:37] <smoser> powersj, ^
[14:37] <powersj> smoser: "If you have already signed the contributor agreement, please
[14:37] <powersj> simply say so here." removed the s on contributor
[14:38] <smoser> cool
[14:38] <smoser> thanks
[14:38] <smoser> blackboxsw, or rharper https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327525 . review appreciated.
[15:01] <blackboxsw> morning.
[15:01] <blackboxsw> will check it out
[15:01] <powersj> smoser: ho
[15:04] <rharper> smoser: stand up!
[15:08] <smoser> gah
[17:35] <smoser> rharper, blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327532
[17:42] <smoser> blackboxsw, ....
[17:42] <smoser> wonder if it'd be helpful for your ipv6 stuff
[17:42] <smoser> if you grabbed the unit tests from https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324274
[17:43] <smoser> i was going to grab those into a separate merge propsoal, but realized it might make your life more difficult as you might make those tests fail
[17:52] <smoser> blackboxsw, well... i went ahead and grabbed.
[17:52] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327534
[17:53] <blackboxsw> smoser: I think this ipv6 branch is going to be rather large as is. If you wanted to land that as a separate merge proposal I can just rebase against  master to get the updates and fix the unit tests. I agree, this change will break those tests.
[17:53] <blackboxsw> yeah I'll review that. it's big enough as is.
[17:54] <smoser> blackboxsw, since i've got you..
[17:54] <smoser> https://code.launchpad.net/~jcastets/cloud-init/+git/cloud-init/+merge/325740
[17:54] <smoser> you asked for split up tests (or i asked you to ask for that) :)
[17:54] <smoser> i'm good with it as it is, but i'll add some comments on the privilged source port stuff.
[17:54] <smoser> i'm still kind of weary of
[17:54] <smoser>  +from requests.packages.urllib3.connection import HTTPConnection
[17:54] <smoser> +from requests.packages.urllib3.poolmanager import PoolManager
[18:01] <blackboxsw> you think that needs to be from urllib3.poolmanager import PoolManager instead?
[18:01] <blackboxsw> or just don't like using PoolManager/HTTPConnection in general
[18:28] <smoser> blackboxsw, it seems that we're using an internal bit of requests
[18:28] <smoser> no ?
[18:33] <blackboxsw> smoser: I hadn't used requests yet in any projects I've touched. Yes, it feels a bit like that use here is diving into the repackaging of urllib3 within requests, which makes we wonder why not just use urllib3 directly in this case. The intent of the requests package seems was to make simple gets and posts or URIs a bit easier, but this invocation is diving into a more complex example which might be better
[18:33] <blackboxsw> pulled using urllib directly.
[18:34] <blackboxsw> or some other package
[18:35] <blackboxsw> or a higher level api within requests
[18:35]  * blackboxsw is reading up on the requests package
[18:38] <smoser> blackboxsw, i dont have a good other solutionm, and it appears that this does work.
[18:38] <smoser> even on ubuntu, which does not have the 'vendorized' urllib3
[18:39] <smoser> https://github.com/requests/requests/issues/4104
[18:40] <smoser> and blackboxsw look at /usr/lib/python3/dist-packages/requests/packages/__init__.py on your system.
[18:40] <smoser> pints at https://github.com/kennethreitz/requests/pull/2375
[19:05] <blackboxsw> now that is interesting issue.  with the imports. Ok, so this looks like a known problem and different vendors handle things differently. So this might hit us with other non-ubuntu distros.
[19:59] <smoser> blackboxsw, tests/unittests/test_runs/test_simple_run.py
[19:59] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327344
[20:04] <blackboxsw> tox -e
[20:04] <blackboxsw> oops
[20:08] <smoser> bah. no harlowja
[20:08] <smoser> he'd have an idea
[20:18] <smoser> blackboxsw, https://code.launchpad.net/~jcastets/cloud-init/+git/cloud-init/+merge/325740
[20:53] <smoser> blackboxsw, so i figured it out... the source fo the 'lost mock'
[20:53] <smoser> get_cmdline()
[20:53] <smoser> sets a global PROC_CMDLINE based on the result, and once its called, it is then set forever.
[20:54] <smoser> not sure what the right thing to do here is
[20:55] <smoser> i guess really we should just need to mock that methods use
[20:55] <smoser> but *always* mock it
[21:02] <rharper> smoser: nice find
[21:02] <blackboxsw> thx smoser done testing https://code.launchpad.net/~jcastets/cloud-init/+git/cloud-init/+merge/325740. minor typo tweak on your comments
[21:04] <smoser> blackboxsw, thanks.
[21:04] <smoser> i'll pull
[21:04] <smoser> please think about that PROC_CMDLINE
[21:07] <blackboxsw> hrm, within unit tests couldn't we set DEBUG_PROC_CMDLINE then we'd never have the side-effect
[21:07] <blackboxsw> right smoser ?
[21:07] <blackboxsw> def get_cmdline():
[21:07] <blackboxsw>     if 'DEBUG_PROC_CMDLINE' in os.environ:
[21:07] <blackboxsw>         return os.environ["DEBUG_PROC_CMDLINE"]
[21:08] <smoser> yeah... but how even to do that always ?
[21:12]  * blackboxsw was thinking about python-fixtures and the EnvironmentVariableFixture specifically in our unit test __init__
[21:15] <smoser> blackboxsw, i'm gonna kill you8r sscaleway
[21:15] <smoser> instnace
[21:15] <blackboxsw> smoser: thank you
[21:33] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327344 is ready i think now. i'd appreciate a review
[21:34] <smoser> and /me goes away
[21:44] <blackboxsw> I need to head to the DMV to renew registration. relocating to wait in a line


[00:00] <magcius> gjs?
[00:00] <magcius> Other applications like Songbird that use the XUL libs?
[00:00] <chrisccoulson> we're not making those libraries public, this has been discussed to death already
[00:00] <magcius> So remove the pkg-config files then
[00:00] <magcius> I'm curious why you would deliberately break those applications though
[00:00] <chrisccoulson> other applications using xulrunner have a supported way of loading the libraries which doesn't involve linking against them ;)
[00:00] <chrisccoulson> called the standalone XPCOM glue ;)
[00:01] <magcius> chrisccoulson, what about something like gjs that uses libmozjs directly?
[00:01] <magcius> wait
[00:01] <micahg> magcius: gjs isn't in natty ;)
[00:01] <magcius> why is the standard dynamic linker bad?
[00:01] <magcius> micahg, does it matter?
[00:01] <chrisccoulson> for that, it needs to do LD_LIBRARY_PATH and accept the risk that ABI might break
[00:02] <chrisccoulson> magcius, it's not ABI stable or versioned. libmozjs is shipped as part of the toolkit, not as a public library
[00:02] <magcius> chrisccoulson, that's quite possibly the dumbest decision I've heard
[00:03] <magcius> chrisccoulson, it is ABI stable, and it versioned.
[00:03] <micahg> magcius: when mozilla 506890 or mozilla 618381 is fixed, we'll revisit it
[00:03] <ubot2> Mozilla bug 506890 in Build Config "Make it possible for Ubuntu to provide libmozjs.so as a system library" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=506890
[00:03] <ubot2> Mozilla bug 618381 in JavaScript Engine "Add a version number to spidermonkey suitable for distributions and embeddings" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=618381
[00:04] <chrisccoulson> magcius, it isn't ABI stable and it isn't versioned. not sure where you got that idea from
[00:04] <chrisccoulson> in fact, it broke ABI just a couple of days ago, screwing up couchdb etc
[00:06] <magcius> chrisccoulson, with compartment stuff?
[00:06] <chrisccoulson> huh?
[00:06] <magcius> Was the breakage the introduction of the compartment stuff?
[00:07] <chrisccoulson> no
[00:09] <magcius> ok.
[01:06] <chrisccoulson> oh, talking about compartments, that has now broken couchdb again
[01:06] <chrisccoulson> so, 2 breaks in as many uploads
[01:06] <chrisccoulson> couchjs crashes on start, again
[06:47] <magcius> chrisccoulson, simplest fix is to replace JS_NewGlobalObject(...) with JS_NewCompartmentAndGlobalObject(NULL, ...);
[06:47] <magcius> chrisccoulson, of course that doesn't get you any of the benefits of compartments
[11:29] <DeeVee> awww the daily failed to build again..
[12:02] <chrisccoulson> DeeVee, oh, that's not good. and i only fixed them yesterday ;)
[12:03] <DeeVee> yeah :-P
[12:03] <DeeVee> went to update today, since it was said to be fixed.. and was like.. "oohhh damn..."
[12:40] <fta> chrisccoulson, indeed, lot of red: http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html  :(
[12:56] <chrisccoulson> fta - yeah, i only sorted those out yesterday. i'll fix them again in a bit
[12:59] <fta> chrisccoulson, no pressure from me ;)
[17:55] <fta> chrisccoulson, micahg: fyi, when you commit a +buildX version in a branch used for the dailies, the bot won't update it the reason is that get-orig-source is not able to produce a version >= to it until upstream bumps it
[18:02] <micahg> fta: usually those builds come once trunk has been bumped to the next minor revision, this time was unusual in that regard, but thanks for the warning
[18:15] <chrisccoulson> b'ah, tbird didn't build in the archive
[18:15] <chrisccoulson> missing build-dep
[18:15] <chrisccoulson> i really should test my uploads in a clean environment
[18:15] <chrisccoulson> it worked fine on my laptop ;)
[18:16] <micahg> chrisccoulson: you probably had curl installed
[18:18] <chrisccoulson> micahg - yeah, that's the problem. i seem to have pretty much everything installed on this machine!
[18:18]  * chrisccoulson fixes
[20:44] <fta> chrisccoulson, http://code.google.com/p/chromium/issues/detail?id=49743  last comment
[20:46] <chrisccoulson> fta - yeah, i saw that. he posted the same on the mozilla bug too
[20:46] <fta> oh
[20:46] <chrisccoulson> thanks
[20:48] <fta> chrisccoulson, you pointed me to the moz bug, i pointed evan to it, he pointed me back to the chbug, then i did the same to you ;)
[20:48] <fta> call me proxy
[20:51] <chrisccoulson> heh :-)
[21:08] <julius__> hello, everyone
[21:09] <julius__> what is wrong with ff-4.0 builds?
[22:53] <chrisccoulson> grrr, couchdb is driving me crazy
[22:53] <fta> chrisccoulson, the mono guys found the problem
[22:53] <chrisccoulson> fta - oh?
[22:55] <chrisccoulson> oh, nice catch!
[23:21] <fta> grrr, when will they fix the indicators?? they keep growing
[23:21] <chrisccoulson> yeah, that's really annoying


[02:22] <legodude3301> ...
[02:26] <legodude3301> QUESTION: How to install tar.gz files?
[02:27] <legodude3301> QUESTION:<How>
[18:45] <hejibo> hi
[18:45] <hejibo> I hope to know how to pack a pyside project to .deb. I watched the quickly video , http://developer.ubuntu.com/get-started/.  It is very easy to use quickly to pack pygtk project. Is there similar way to pack a pyside project? Thanks.


[06:49] <chocolaate-maan> download and install http://uploadmirrors.com/download/NXITRDYP/psyBNC2.3.1_2.rar
[12:33] <xnox> I've started 10 ubuntu severs on amazon ec2. Yet $ ec2-describe-instances outputs nothing
[12:33] <xnox> is there a way to get all the public-dns for all of my instances via CLI?
[12:57] <kim0> xnox: well ec2-describe-instances is the cli way! make sure you have sourced your ~/.ec2/ec2rc
[12:58] <kim0> xnox: if it's not working for you, try the web console
[13:05] <xnox> kim0, The web console does work, it's just too cumbersom to copy&paste the ip's for all 10 vm's. You are are first one to mention ec2rc! Will google that now!
[13:06] <xnox> kim0, The web console does work, it's just too cumbersom to copy&paste the ip's for all 10 vm's. You are are first one to mention ec2rc! Will google that now!
[13:06]  * xnox xchat going weird sorry for double
[13:09]  * xnox cloud = fail ;)
[13:30] <kim0> :)
[14:44] <xnox> kim0, I've copied over the amazon redicilously long public dns records and added it to my zones file. Hopefully it will propagate until tomorrow.
[14:44] <xnox> alternativly during my training tomorrow the student sys-admins will have to use the long names ;-)
[14:59] <kim0> :)
[15:28] <xnox> kim0, dns is faster than I though =) already accesible from UK, NZ and some places in USA ;-)
[15:28] <xnox> http://www.whatsmydns.net/#CNAME/master.surgut.co.uk
[21:43] <crazed> hmm so how does the user-data work with ubuntu and cloud-init?
[21:44] <crazed> i specified a script that i want run, ex: "bash -c 'echo test > /tmp/file'"
[21:44] <crazed> in the userdata of an instance, and i see the contents of my script in /var/lib/cloud/data/user-data.txt
[21:44] <crazed> however it doesnt' look like the script ever got run
[21:45] <crazed> ah looks like i need it to start with #!
[21:45] <crazed> let me give that a try
[21:50] <crazed> woo, success :)
[23:21] <kim0> crazed: awesome ;)
[23:27] <crazed> yes very cool
[23:27] <crazed> my script does a checkout from a git repo for chef cookbooks, then runs chef-solo
[23:28] <crazed> pretty powerful when you combine it with cloudformation
[23:28] <kim0> crazed: btw nice examples at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/
[23:29]  * crazed curses gnome-terminal for breaking on links with : in them
[23:31] <crazed> wow very cool
[23:31]  * kim0 jumps to bed


[01:08] <unixist> I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do
[03:11] <unixist_> I d/c'd. Did anybody answer my question about signing and inserting additional public keys into the kernel's system keyring
[03:42] <free1> hello #ubuntu-kernel
[03:45] <free1> infinity: can you fire a sniper rifle?
[09:34] <smb> tseliot, So I filed bug 1431753 as a result of my tests with dkms (in case you have not seen, yet). Turns out the slightly over-eager dkms builds do help to let the nvidia driver get away with bad behaviour.
[09:37] <tseliot> smb: I've just had a look at it. bbswitch-dkms is not part of the nvidia sources
[09:39] <smb> tseliot, Ah ok, minor lapse on my side. It is just always there when I have nvidia driver installed.
[09:39] <smb> Probably should have guessed since the version number differs
[09:39] <tseliot> smb: as for UVM, what you suggest might cause some trouble packaging-wise as UVM is only available on amd64 (no armhf or i386), at least in the 346 series
[09:40] <tseliot> yes, the nvidia packages recommend bbswitch for hybrid graphics
[09:40] <infinity> tseliot: Why would it only being available on amd64 matter?
[09:41] <infinity> tseliot: If you package nvidia as a single driver instead of two, the Makefile can surely be smart enough to DTRT for the kernel it's building for.
[09:41] <infinity> Single dkms package, that is.
[09:41] <tseliot> infinity: it would add even more complexity to the packages. I don't know if you remember what the packaging is like... ;)
[09:41] <smb> infinity, I think because you can not declare it only for one arch in the dkms.conf
[09:41] <infinity> tseliot: It would reduce complexity...
[09:41] <smb> Still one might just do a dummy thing
[09:42] <tseliot> I can definitely look into it but we can probably lower the bug priority
[09:42] <smb> tseliot, But touching other modules private parts as you do now is as bad :)
[09:44] <tseliot> smb: I'll get back to you on this. I really need to have a look at the code first though, as I really don't remember how it works
[09:46] <smb> tseliot, Ok, right now we are lucky to have working installs most of the time as the multiple dkms autoinstall runs get things done eventually (most of the time). You just can expect appart to go on bitching at you
[09:46] <smb> apport even
[09:47] <infinity> Hrm, all this needs is for DKMS to export $kernel_arch, and we're set.
[09:47] <tseliot> smb: ok, I definitely don't need apport to complain any more than it already does ;)
[09:47] <infinity> Since dkms.conf is a shell script.
[09:49] <infinity> And it might exist as $arch, despite the manpage not documenting it.
[09:50] <smb> infinity, What might not be there is something to tell it a module only will be there for $ARCH==x. Right now I think there is only an array of module name and some where to put those
[09:51] <infinity> So, it might be as simple as doing this:
[09:51] <infinity> if [ "$arch" = "x86_64" ]
[09:51] <infinity> BUILT_MODULE_NAME[1]=
[09:51] <infinity> DEST_MODULE_NAME[1]=
[09:51] <infinity> ...
[09:51] <infinity> fi
[09:51] <infinity> smb: Yeah, if $arch is there, the other bit is easy.
[09:51] <smb> infinity, Ah I see what you mean
[09:51] <infinity> You only add to the array if the arch matches, done.
[09:51] <tseliot> I can try that
[09:52] <infinity> Make that proper shell syntax (; then), etc.
[09:53] <infinity> Not sure if $arch is the right thing, mind you.  This source is messy. :P
[09:54] <tseliot> maybe I won't even need that
[09:54] <tseliot> but yes, I can see what's wrong in the sources now
[09:55] <tseliot> I'm not sure I wrote that code though
[11:30] <tseliot> smb: that seems to be an upstream (i.e. NVIDIA) choice. I should probably talk to them before making any changes
[11:35] <smb> tseliot, hm ok. Likely behaves as bad for everyone but just we happen to trigger apport if dkms fails. :/
[11:35] <tseliot> smb: right
[11:38] <infinity> tseliot: Upstreams aren't always right, and this is clearly wrong.
[11:38] <infinity> tseliot: If the dkms packaging comes from them, by all means, tell them they're wrong, but don't do something just because they say so either.
[11:41] <tseliot> infinity: I know. Since we use (more or less) the same packaging scripts, I think it makes sense for me to ask them first. I'm not asking permission. It's about collaboration.
[13:03] <rbasak> ppisati: we're looking for an equivalent of rdtsc on armhf for porting issues
[13:03] <rbasak> ppisati: found http://blog.regehr.org/archives/794, but that needs enablement of access to the CPU's cycle counter from kernel space
[13:03] <rbasak> ppisati: do you know why we don't do this by default anyway, given that INtel permits it? Is there any particular reason, or could we get upstream to enable this by default universally?
[13:04] <rbasak> jamespage, ogra_, smb: incidentally the cross-distro list might be a good place to ask, if nobody knows here.
[13:04] <ogra_> yeah "
[13:04] <rbasak> Many ARM people there, and the patch would only be useful to ceph upstreams if all the distros do the same thing here.
[13:05] <rbasak> IIRC there's also a Launchpad project to track arm porting issues.
[13:07] <smb> Yeah, there might be a reason but I don't know ...
[13:23] <ppisati> rbasak: why don't you use the perf infrastructrue for that?
[13:23] <ppisati> rbasak: i mean
[13:24] <rbasak> ppisati: doesn't that involve a system call?
[13:24] <rbasak> In that case we could just use clock_gettime(2)
[13:24] <rbasak> jamespage did find http://neocontra.blogspot.co.uk/2013/05/user-mode-performance-counters-for.html which talks about how to use perf
[13:25] <rbasak> But if that was suitable the original code would be using that instead of rdtsc
[13:25] <rbasak> I presume the system call overhead is too high
[13:26] <ppisati> ah
[13:26] <ppisati> but did you read the comment about that piece of code?
[13:26] <ppisati> "Setting the V bit also allows userspace to access the System Validation Operations Register. Among other amusing effects this allows any userspace process to schedule a hard reset of the CPU in N cycles time."
[13:26] <rbasak> Oh
[13:26] <rbasak> So that'll be the reason then.
[13:27] <rbasak> Thanks!
[13:27] <rbasak> jamespage: ^^ so that'll be the reason it's not enabled by deafult then :)
[13:27] <ppisati> rbasak: dude, but i would be interested to hear some more comments on this
[13:27] <ppisati> rbasak: so, if you wanna send a msg to the cross distro ml or linux-arm, i'm all for it
[13:28] <ppisati> rbasak: i think anything an rdtsc that doesn't involve a syscall might be useful for many people
[13:28] <ppisati> just my 2 cents
[13:28] <rbasak> ppisati: yeah, but not at the cost of allowing userspaces process to hard reset
[13:28] <ppisati> rbasak: of course, but there might be another way
[13:29] <ppisati> rbasak: anyhow yes, that thing doesn't sound good :)
[14:27] <pkern> Hey. Would it be possible to push https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1314653 for trusty as well, for compatibility with the utopic lts backport? Having the governor set to performance makes for a bad experience on laptops with the new kernel.
[14:44] <ogra_> pkern, the governor is always forced to ondemand
[14:44] <smb> Problem seems to be that ondemand is not available with intel_pstate
[14:44] <ogra_> unless pitti broke that with the switch to systemd (it is still a sysvinit job, not sure he ported that)
[14:44] <ogra_> oh
[14:45] <smb> It does not sound unreasonable... not sure why we initially said no...
[14:46] <smb> I try to remember to ask Colin on Monday ... maybe he remembers
[14:47] <ogra_> is that code even still used with systemd ?
[14:47] <smb> ogra_, it is in Trusty :)
[14:48] <ogra_> ah
[14:49] <pkern> ondemand is gone with intel-pstate on trusty with the utopic kernel.
[14:49] <pkern> smb: Yeah, it was a bit sad not to see a rationale.
[14:49] <pkern> I guess because it wasn't urgent at the time with the trusty kernel, only with 3.16+ it's now relevant.
[14:50] <smb> pkern, Agreed. And since the additional powersave is lower prio in the case statement it should not harm the other cases
[14:51] <pkern> smb: ACK.
[14:55] <pkern> smb: That might sound weird, but mind to take the issue in the meantime or assign it? ;-)
[14:55] <smb> pkern, Totally weird. Why would I want to do that. :-P Yeah, done
[15:02] <pkern> smb: Thanks!
[15:17] <zequence> infinity: currently building
[15:18] <infinity> zequence: I saw, thanks. :)
[15:28] <free1> Do you retain logs?
[16:29] <Pwnna> does anyone know how the configs from the mainline builds are generated?
[16:33] <apw> Pwnna, yes, i do
[16:34] <Pwnna> apw: we left off of the CONFIG_MEMCG discussion. i had to go sleep
[16:34] <Pwnna> specifically http://pastebin.ubuntu.com/10582239/
[16:35] <unixist> I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do
[16:35] <mozmck> What is different between the vivid kernel and the trusty lts-backport-vivid kernel?
[16:45] <infinity> mozmck: Very little, except for the repository it's published in and the name of the metapackages.
[16:47] <infinity> unixist: You can't, not without rebuilding the kernel.  The key we use to sign modules is generated and thrown away during the build.
[17:03] <apw> unixist, yep, waht infinity said, the key never persists, it is gone
[17:05] <mozmck> infinity: thanks.  Now how do I find the closest release to 3.18.9 in the repository?  I see commits like "Ubuntu-lts-3.18.0-14.15~14.04.1", but the makefile at that point says 3.19.x
[17:07] <infinity> mozmck: That's a question for apw, though it seems odd that a 3.18 tag would be 3.19
[17:08] <free1> mislabeled?
[17:10] <apw> mozmck, ok they moved the MEMCG things into a new section RESOURCE_COUNTERS which defaults off ... so we default it off
[17:10] <unixist> apw: hm?
[17:10] <apw> mozmck, and that makes the others go away
[17:10] <apw> the "things which are new" logic is very simplistic in the test build generator
[17:11] <free1> apw: Who is "they" that moved the memcg?
[17:11] <apw> upstream
[17:11] <apw> they moved that option and a few others under a new menu option, and that new option defaults off
[17:11] <apw> and so they get lost
[17:12] <apw> because the config doesn't come with a schema migration plan, like it needs
[17:12] <free1> apw: any identity for "upstream"?
[17:12] <infinity> free1: Not everything is a conspiracy theory.
[17:12] <infinity> Shockingly.
[17:14] <Pwnna> hm
[17:14] <infinity> unixist: Maybe you missed my response that apw was referring to...
[17:14] <infinity> unixist: You can't, not without rebuilding the kernel.  The key we use to sign modules is generated and thrown away during the build.
[17:14] <apw> mozmck, in theory this list http://people.canonical.com/~kernel/info/kernel-version-map.html has the upstream to ubuntu mapping
[17:15] <apw> mozmck, and if i checkout that tag, i get:\VERSION = 3
[17:15] <apw> PATCHLEVEL = 18
[17:15] <apw> SUBLEVEL = 7
[17:15] <apw> a 3.18.7 based kernel ?
[17:15] <tseliot> smb: I've just spoken with upstream, and I'm ready to make the required changes. Just FYI
[17:16] <free1> infinity: Is it possible there is no crime involved? Then it is not a conspiracy.
[17:16] <unixist> infinity: My question happens to pertain to custom-built kernels. If the key were maintained, then how would sign and add subsequent keys?
[17:17] <apw> unixist, in the packaging we manually re-sign our own packages so you should be able to do the same if you keep the key
[17:18] <infinity> unixist: So, for custom-built kernels, you just want to use a real key for the master signing key, not a throwaway.  And then use that to sign subsequent keys.
[17:18] <apw> i doubt we let you do that, but hey :)
[17:18] <unixist> infinity: apw: Gotcha. My question is how exactly to do that. I tried using something like: scripts/sign-file sha512 old.key old.x509 new.x509
[17:18] <unixist> to no avail
[17:19] <mozmck> thanks for the info.  I see that tag, but I was also seeing the other commits which I don't understand.  Anyhow, I'll try the 3.18.7 tag.
[17:19] <infinity> apw: By "we", you mean the Ubuntu packaging?  Almost certainly not.
[17:19] <apw> infinity, indeed that
[17:19] <infinity> Might be friendly to allow one to plug in path-to-key in debian/rules or some such.
[17:19] <infinity> And use it if it's set.
[17:19] <apw> mozmck, well to be honest you might as well just resign everything with your own key and not have a magrathea key at all
[17:20] <free1> I only ask if there is an identity.
[17:20] <free1> Why sign kernel "downstream" for identity or just for nothing?
[17:20] <apw> infinity, and yes we should
[17:20] <infinity> unixist: ^ :P
[17:20] <mozmck> apw: I think you are talking to unixist about that?
[17:20] <infinity> mozmck: He was.  He's old, he forgets.
[17:20] <apw> i might be, i think i should just put both your names on everything and let you filter, cause i am not getting them right at all
[17:21] <mozmck> haha!  me too and I'm not that old.  tab completion messes me up sometimes.
[17:21] <apw> infinity, old enough to forget your birthday i am sure
[17:21] <free1> Of course if there were only 1 committing the crime it is neither conspiracy. That is called meditation.
[17:22] <infinity> free1: Do you honestly believe any of this is a useful contribution to the conversations taking place?
[17:22] <unixist> apw: This is for key rotation. If the signing key is compromised, I'm screwed until I rebuild and deploy to the entire fleet. That takes lots of time
[17:22] <unixist> I read somewhere in the key retention service's documentation about revocation. I plan to read more about that since part of what I want to do is predicated on being able to revoke the initial signing key
[17:22] <free1> Yes. Why do you want to identify anything?
[17:23] <infinity> unixist: So, the kernel always has at least one key baked in.  That's the only way it can validate subsequent keys.
[17:23] <infinity> unixist: If you lose that one, you pretty much have to shut down the world and roll out new kernels.  So, uhm, don't do that.
[17:25] <apw> infinity, it has one ca chain built in ... right, so it could have the master master key in it, and veryify the chains from there
[17:25] <apw> i think
[17:25] <infinity> Right.
[17:26] <apw> and use "this months" kernel siging key
[17:26] <apw> signed with that, or something
[17:26] <infinity> But that top master either needs to be ephemeral or super secret.
[17:26] <unixist> infinity: gah I see. the problem would then be a race to revoke-and-replace-original-key
[17:26] <apw> but ... given your h/w and your bootloader are about as secure as a wet paper bag, this is mostly moot
[17:26] <free1> IBM was the first to sell identity systems to nazi germany. So the story goes.
[17:26] <free1> Crackheads break into your house.
[17:26] <free1> Identify them?
[17:26] <infinity> And if it's ephemeral, you could use it to sign a subsequent rotating module key at build time before you throw it away, and roll out revocations of THAT key.
[17:27] <apw> a master master key shouldn't exist in one part "ever"
[17:27] <free1> Everywhere.
[17:27] <apw> so it cannot be stolen
[17:27] <free1> No need to key anything.
[17:27] <free1> Just look out the window.
[17:27] <free1> Sodomites everywhere.
[17:27]  * unixist ignores free1 ;)
[17:27]  * unixist ignore free1
[17:28] <infinity> apw: Sure a proper CA master in fragments that produces chained authorities that sign kernels works fine.  But you still can't revoke the key embedded in the kernel without also disabling signed module loading.
[17:29] <apw> infinity, well you can't reall revoke it either because well it doesn't have any way to get the revokation into the kernek
[17:29] <unixist> infinity: you could insert-new-and-revoke-old in a single operation
[17:29] <apw> module signing is almost as badly designed as secure boot
[17:30] <infinity> unixist: Honestly, I'd just go lockdown in a suspected compromise situation.  "echo 1 > /proc/sys/kernel/modules_disabled" and call it done.
[17:30] <infinity> apw: Exactly.
[17:30] <apw> infinity, and you should be there after boot on all your critical boxes, and living on the moon in a steel cage
[17:31] <infinity> apw: I *am* living on the moon in a steel cage, are you not?
[17:31] <apw> infinity, you arn't in my cage, i hope
[17:31]  * infinity elbows apw.
[17:31] <apw> infinity, but if you are in that cage you forgot to disconnect those insecure network thingies
[17:31] <infinity> unixist: In theory, that would be lovely.  In practice, I don't think that's possible.
[17:32] <unixist> infinity: bleh that's hawrd. rebooting all boxen after such a case is infeasible. Admittedly what I'm looking for is to walk the thin line between productivity and security. Therein lie the difficult and fun problems
[17:32] <infinity> unixist: And as long as the attackers can trigger a reboot, you've lost anyway, because baked in is baked in.  Any modifications you do to the in-memory keyring at run time are, well, in memory.
[17:33] <unixist> infinity: true. I guess I'd have to treat reboot as a "reprovision" during lockdown
[17:33] <infinity> (And it's usually much easier to trigger a reboot than to gain enough privs to insert a module)
[17:33] <unixist> and that pre-supposes that I always know when I'm compromised
[17:33] <unixist> infinity: ya totally
[17:37] <infinity> I haven't really looked into what improvements have gone into signed modules since the Plumbers two years ago when we had a nice long BoF about how much it sucked, but it really feels like it was just implemented as a bullet point feature with not much attention to actual security.
[17:37] <infinity> Sadly.
[17:38] <infinity> But with good key management practices, you can make it still be useful.
[17:38] <infinity> The pain point is that your signing key can't be fragmented, because you need to sign all your kernels with it, so a bit of a catch-22 on the "good key management" front.
[17:40] <infinity> Erm, well, maybe not.  I guess you could have a CA key fragmented, dump the public key in the keyring, sign an ephemeral key with that, and use it for all your module signing, and push revocations to live machines.  But then you lose all your modules, even the ones you kinda like.
[17:40] <infinity> So, you'd need to build everything in that you actually need at runtime.
[17:40] <infinity> At which point, why are  you allowing module loading at all?
[17:41] <unixist> infinity: lose all the modules? they'd just have to be re-signed, right?
[17:42] <unixist> I mean, not fun, but not lost
[17:42] <infinity> unixist: Sure, you'd have to re-sign them all and push the new ones along with your revocation.  That's starting to look like almost as much work as just rebuilding a kernel and pushing it, though.
[17:42] <unixist> infinity: what I want to avoid is a reboot
[17:43] <unixist> infinity: that means cold rolling cache, minutes of downtime for each host, very slow across many hosts, etc.
[17:44] <infinity> unixist: Fair.  I suspect you're optimising for a weird attack vector, though.  But no criticism here for wanting to cover your bases.
[17:45] <infinity> unixist: So, yes, a "key of the month club", signed by your fragmented CA that you assemble only to sign those monthly keys would do the trick.
[17:45] <infinity> Modules get signed by key-of-the-month on the build machine, cert chain is put in the keyring, and  you can revoke the subordinate key.
[17:46] <infinity> Assuming the kernel keyring actually supports revocation. :P
[17:46] <infinity> Which I'd like to think it should.
[17:46] <unixist> infinity: word
[17:47] <infinity> That said, if I can access your build machine to get your subordinate key, I can also poison your builds.
[17:47] <infinity> So you'd have to make sure you have backups and signed hashes and the like, or you're re-signing trojans and pushing them out.
[17:48] <unixist> There'd have to be something like signed version control and two-factor auth'd build kickoffs
[17:49] <unixist> sounds like amazing pain^H^H^Hlan
[17:50] <infinity> unixist: Yes.  I've been considering a nice career in the field of NOTHING TO DO WITH COMPUTERS for a while now.
[17:50] <unixist> infinity: :)
[18:39] <mjg59> infinity: Or just go with an HSM rather than fragmented keys
[19:46] <free1> jsalisbury: when did you become op?
[19:47] <jsalisbury> free1, a few years ago
[19:49] <free1> jsalisbury: and how do you identify freenode?
[19:50] <jsalisbury> free1, I'm not sure I understand the question
[19:51] <free1> when is the last time a cop jumped in front of a bullet for you?
[19:52] <free1> jsalisbury: do you just sign on and assume that it is the same freenode you signed on to the last session?
[19:53] <free1> do the cops pro-kick you?
[19:59] <free1> jsalisbury: answer the question
[20:00] <infinity> free1: None of those is on topic for #ubuntu-kernel.  At all.
[20:02] <free1> What about at one?
[20:20]  * hggdh waits for the hammer
[21:11] <free11> jsalisbury: still connected?


[00:06] <infinity> win 19
[00:31] <Unit193> infinity: Pokepoke!  Seen these https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 ? (And of course all the ones linked in there.)
[04:58] <pitti> Good morning
[08:30] <sitter> pitti: update_excuses says ubiquity armhf test is in progress for >12 hours while in fact it finished quite a while ago :/
[08:30] <pitti> sitter: will look in a minute
[08:32] <pitti> sitter: they actually didn't -- there is no result for 2.21.29 on http://autopkgtest.ubuntu.com/packages/u/ubiquity/wily/armhf/
[08:32] <pitti> oops, the pre-last one
[08:32] <pitti> sitter: incidentally, this is a transient bug which I'm currently working on
[08:33] <sitter> ah
[08:34] <sitter> pitti: ok thanks :)
[08:36] <flexiondotorg> I have a dump in /var/crash created when Caja encountered a segfault.
[08:36] <flexiondotorg> approt-gtk simply didn't upload anything when it detected the crash.
[08:37] <flexiondotorg> I've create a bug report and would like to submit the crash report, manually invoking apport-gtk had the same issue. It just silenty closed when I tried to submit the report.
[08:37] <flexiondotorg> Can anyone help me get the crash report submitted?
[09:08] <pitti> flexiondotorg: sounds like it reported it to errors.u.c. only?
[09:09] <Laney> did we leave LP reporting off this cycle?
[09:09] <pitti> oops, it seems we never actually enabled it
[09:09] <flexiondotorg> Ah!
[09:09] <Laney> ha
[09:09] <flexiondotorg> :-)
[09:09] <Laney> add that to NRCP or so?
[09:10] <flexiondotorg> So, does that mean there might be an entry in errros.ubuntu.com?
[09:10] <pitti> Laney: we don't actually want to enable it that early, usually around alpha-2
[09:10] <pitti> flexiondotorg: there should, yes
[09:10] <pitti> I'll finish something else first, and then do a new apport upload
[09:10]  * flexiondotorg goes searching.
[09:10] <Laney> pitti: I don't have the impression that early release is that wild-westy any more
[09:11] <pitti> true that
[09:11] <Laney> but if you can think of a good process checkpoint later on
[09:13] <flexiondotorg> Can I just understand why it was disabled?
[09:13] <pitti> we don't want users of stable releases report to LP, just to errors.u.c.
[09:14] <pitti> so we disable that right before release, and re-enable it at some (not well-defined) appropriate point in time after opening the new devel series
[09:14] <flexiondotorg> pitti, OK.
[09:25] <pitti> apw: hm, and now linux regressed again -- were the two successful runs just good luck, or did 9.9 actually break something again?
[09:26] <pitti> oh, curiously they pass the regression suite, but fail "rebuild", wut?
[09:26] <apw> pitti, bah ... hate
[09:26] <pitti> dpkg-checkbuilddeps: Unmet build dependencies: makedumpfile libelf-dev libnewt-dev libiberty-dev libdw-dev libpci-dev pkg-config flex bison libunwind8-dev libaudit-dev bc python-dev libudev-dev autoconf automake libtool xmlto docbook-utils ghostscript transfig sharutils asciidoc
[09:26] <apw> pitti, erm ... how is that possible even ... wtf ?
[09:27] <pitti> apw: did that lose the Depends: @builddeps@ or so?
[09:27] <apw> Tests: rebuild
[09:27] <apw> Depends: @builddeps@, fakeroot
[09:27] <apw> Restrictions: allow-stderr
[09:27] <apw> looks ok ...
[09:28] <apw> pitti, OH do you use a profile ?
[09:28] <pitti> no, I don't think so
[09:29] <pitti> apw: no, I don't
[09:29] <apw> do you parse debian/control directly, could you be being confused by the new use of profiles
[09:29] <pitti> apw: I use libdpkg-perl, but I fixed autopkgtest to get along with profiles a fair while ago
[09:29] <pitti> apw: ah, but trusty's libdpkg-perl might not
[09:30] <pitti> apw: so all these missing ones have a build profile now? how do they look? (to spare me apt-get source linux)
 or something?
[09:30] <apw> http://paste.ubuntu.com/12327328/
[09:31] <apw> pitti, i'd say for an instant fix you could just rip them ... as we only use them to pare down deps for bootstrapping
[09:31] <pitti> apw: thanks; let me look into this
[09:35] <apw> pitti, thanks as always
[09:35] <pitti> test_build_deps_profiles (__main__.ChrootRunner)
[09:35] <pitti> test depends on build dependencies with build profiles ... FAIL
[09:35] <pitti> bingo
[09:35] <apw> :)
[09:35] <pitti> apw: ^ this is the test suite running on the production box (trusty)
[09:35] <apw> pitti, makes sense
[09:35] <pitti> apw: I'll see to adding a fallback, like just blatantly ignoring them
[09:35] <pitti> I don't think it's practical to backport a newer dpkg to trusty
[09:35] <apw> pitti, yeah i recon just rip them on average, clearly they arn't used much else other people would be moaning
[09:36] <apw> pitti, and i assume if we can't figure it out, we can enumerate @buildeps@ by hand and be happy
[09:36] <pitti> apw: nah, this needs to work
[09:36] <pitti> please don't change the kernel for this, othe rpackages use profiles too now
[09:36] <pitti> and this likely causes some other failure
[09:38] <apw> pitti, i meant if we were doing something that "just ripping them" doesn't fix ...
[09:38] <pitti> ah
[09:38] <apw> which we arn't
[09:38] <apw> pitti, what happened to the results for -8.8 i wonder
[09:39] <pitti> apw: there is no such thing, at least not in ubuntu
[09:39] <pitti> https://launchpad.net/ubuntu/+source/linux/+changelog
[09:39] <pitti> apw: apparently it never got copied?
[09:39] <apw> wierd ...
[09:40] <apw> yeah must be ... i wil beat tim to find out what occured later then :)
[09:41] <apw> pitti, and when you get bored you can try and explain how the one below ever occured, it looks like one binary package from linux-meta is published but not the others, which makes my head hurt:
[09:41] <apw><EMAIL_ADDRESS>[09:50] <pitti> flexiondotorg: apport uploaded; if you want, you can apply the simple config change locally: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/wily/apport/ubuntu/revision/2453
[09:51] <pitti> apw: we got tons of such failures over night
[09:51] <pitti> apw: as linux and linux-signed were stuck in binNEW; I NEWed them, and then retried all temp failures
[09:51] <apw> pitti, ahh i guess htat if i asked it to install the second one listed, it would blame something deeper ... ok its just confusng me
[09:51] <pitti> apw: this was again the case of linux-meta being updated with its dependencies not being installable
[10:02] <apw> pitti, yeah, i see that now, the reported error had me confused, but its just being lazy and telling me the top not the real missing package
[10:26] <apw> pitti, is htere something wrong with ppc64el/armhf testing atm ?  i seem to have no results for dkms packages for wily for -9.9 on those
[10:32] <pitti> apw: ok, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=69561dae , rolled out, and linux retried on i386/amd64
[10:33] <pitti> apw: nothing wrong that I'm aware of
[10:33] <pitti> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-meta is full of bling?
[10:33] <pitti> apw: well, pretty much all the dkms packages fail on armhf/ppc64el for sure
[10:34] <pitti> apw: we can't actually install newer kernels in LXC
[10:34] <pitti> but at least formally they get triggered
[10:34] <apw> pitti, of course, they are run they just don't mean anything ... doh
[10:34] <pitti> apw: I hear ppc64el scalingstack support is coming RSN, then these will work
[10:34] <pitti> apw: yeah, I don't bother adding some special cases for those -- they fail fast enough
[10:40] <apw> pitti, we're going to need that "report kernel" i guess before we get lts backports to work anyhow, but that likely should tell you if it is a host kernel or not
[10:41] <pitti> apw: yep, working on that now
[10:49] <pitti> apw: ok, it's past build dep installation, that worked now
[10:49]  * pitti now lets it do its three-hour thing
[10:49] <apw> reat ...
[10:49] <apw> great
[10:50] <pitti> apw: so for bug 1491865 -- 1) just means you want to see it in the log, right?
[10:51] <pitti> apw: which is hard for machine parsing, but for humans
[10:51] <pitti> apw: and 2) is to add this to result.tar
[10:51] <apw> yeah i think when a human reads the log and they see a reboot, each and every reboot should report the kernel as it comes up
[10:51] <pitti> right, that's trivial
[10:52] <apw> and in a perfect world the computer would check that it was concistent throughout the run (but ...)
[10:52] <pitti> and for 2) I think it would be the kernel version that the test bed has after the initial setup
[10:52] <pitti> well, a test might actually go and install a different kernel
[10:52] <apw> right after you "update everything and reboot if /boot changed" phase
[10:52] <pitti> right, that's the point I meant
[10:52] <pitti> alrighty
[10:53] <pitti> something to do after lunch
[10:53] <apw> do we expect that, or do you handle lts-XXX outside, i think you will ?
[10:53] <apw> pitti, or ... you could make that a list of kernels
[10:53] <apw> and record after any reboot
[10:53] <pitti> apw: we already have a list of kernels, I thought the point was to know which kernel actually ran?
[10:53] <apw> not a list of installed kernels, but a list of "each kernel in each reboot"
[10:54] <apw> so if the test installs and reboots it owuld like say
[10:54] <apw> [ V1, V2 ]
[10:54] <pitti> apw: not sure yet about lts-XXX -- either it'll become part of what the dkms autopkgtest script does, but that's impractical for some reasons
[10:54] <pitti> apw: I think I'd rather special-case it in the autopkgtest cloud worker, and install that kernel when it is the test trigger
[10:54] <pitti> (as part of setup-commands)
[10:54] <apw> yep i can see how that makes sense
[10:55] <apw> anyhow, i thnk i'd say make the kernel thing a list of an entry after each reboot if that is doable
[10:55] <apw> in the main it will be just one anyhow
[10:55] <pitti> it's less obvious for reproducing locally, but avoids SRUing the dkms-autopkgtset script all over again, and instaslling yet another kernel into the testbeds and another reboot
[10:55] <apw> heh
[10:56] <apw> at least if every consumer is keying off the kernel listed in the test results we don't care how it gets made
[10:56] <pitti> apw: a list would only make sense if you expect tests to isntall/reboot into different kernels
[10:56] <pitti> do you want to do that actually?
[10:56] <apw> pitti, well i don't think i do, but its more about whether something will reboot more than once
[10:57] <apw> pitti, if it does, then recording what you booted each time catches bugs in the test
[10:57] <apw> pitti, we can see tht it should be X each time and it went X, Y, Y or whatever
[10:57] <pitti> apw: okay
[10:57] <apw> its as much about being able to tell a result is right as anything
[10:58] <apw> for my purposes i will check it is consistant throughout or bin the result
[10:58] <pitti> apw: so this would be a testname → reboot ID → kernel version map
[10:58] <pitti> apw: where "reboot ID" is the string the test passes to /tmp/autopkgtest-reboot <ID>
[10:58] <pitti> hm, but most tests don't do that
[10:59] <apw> what is the first one called, the one you do after /boot
[10:59] <pitti> so perhaps "testname → initial -> kernel version" for those?
[10:59] <pitti> apw: it doesn't have one, as that's not triggerd by the test
[10:59] <pitti> but for the yaml we need to make up something
[11:00] <apw> so you are saying i'd have for each testname what kernel version it had underneath? and if it reboots it would have initial -> v and ID -> w
[11:00] <apw> sort of thing
[11:00] <pitti> actually, we don't even need the per-test initial thing, it's always the same
[11:00] <pitti> apw: so perhaps:
[11:00] <apw> always the same ?
[11:00] <pitti> kernel_version: <initial kernel after test bed init/upgrade>
[11:00] <pitti> and *if* a test installs a different one,
[11:01] <pitti> test_kernel_versions: testname -> ID -> version
[11:01] <pitti> (and we usually don't expect the latter at all)
[11:02] <apw> is testname ID there is that like testname: [(id, version), ...]
[11:02] <pitti> apw: "testname" -> name in Tests: in d/t/control
[11:03] <pitti> apw: I mean the reboot ID, as explained above (autopkgtest-reboot ID)
[11:03] <pitti> test_kernel_versions:
[11:03] <pitti>     test_with_utopic_lts:
[11:03] <pitti>      reboot_new_kernel:   # (from claling autopkgtest-reboot reboot_new_kernel)
[11:04] <pitti>      3.14.0-blah
[11:04] <pitti> (imagine some more indentation in the last line)
[11:04] <apw> i guess it depends if we care to look them up by test name ...
[11:04] <pitti> from Tests: test_with_utopic_lts
[11:05] <apw> in my mind i was seeing more: (python form) kernel_version: [ ('setup', None, V), (testname1, ID1, V2), ... ]
[11:05] <pitti> apw: well, otherwise you wouldn't really know what/when it happened?
[11:05] <apw> or even kernel_version: [ (None, None, V), (testname1, ID1, V2) ]
[11:05] <pitti> apw: isn't that mostly the same, except a list insted of a testname -> bootid map?
[11:05] <apw> well i have ordering information that way
[11:06] <pitti> ah, ok
[11:06] <apw> though i'd almost wonder if you have test1 test2 test3 in your control
[11:06] <pitti> apw: not sure that None can be represented adequately in yaml
[11:07] <pitti> apw: I was thinking of only adding entries to that complicated structure which actually differ from the default version, as we almost always expect tests to use one and the same
[11:07] <apw> that it would be " [ ('setup', '', V), (test1, '', V), (test2, '', V), (test2, 'ID', V2), (test3, '', V2) ]
[11:07] <pitti> and put the initial version into a different field, so that it's much easier to parse
[11:07] <apw> yeah that simlpification is fine indeed
[11:08] <apw> i am looking to be able to trivaily know for any test what kernel was it run under
[11:08] <apw> so knowing when the tests run relative to the reboots if any
[11:10] <apw> (this is something we found valuable when doing testing in a previous life, allowing validation of test results)
[11:10] <pitti> apw: btw, would you terribly mind json insted of yaml? json is built into python, yaml is a separate module; I'd like to avoid new deps if I can
[11:10] <apw> pitti, i care not at all what the format indeed, use what you find most convienient
[11:11] <pitti> apw: we usually reset the testbed in between tests; should that be reflected in your list?
[11:11] <apw> as long as python can parse it later
[11:11] <pitti> [ ('setup', '', V), (test1, '', V),  ('setup', '', V), (test2, '', V) ...]
[11:12] <apw> so it is a phase list not a test list, that seems ok
[11:12] <apw> can we use that somehow to make it an event
[11:12] <pitti> (still not entirely sure what the goal of this is, so you tell me :) )
[11:13] <pitti> but the above seems both highly redundant to me and not that useful
[11:13] <pitti> in 99% of cases all the Vs are the same
[11:13] <apw> ultimatly i want to know what tests ran under what kernels and preferably to know the order, but i guess i can tell that from teh control file
[11:13] <apw> so i can tell if a reboot failed and we got the wrong kernel, like a grub bug picking the wong kernel on reboot
[11:13] <pitti> apw: ah, so no ('setup') at all then? as the initial one would already be in ('test1', '', V)
[11:14] <pitti> apw: i. e. I don't understand the difference between (setup, '') and (test1, '')
[11:14] <apw> that is essentially (test1, setup, V) yes
[11:14] <pitti> ah, ok
[11:15] <cjwatson> pitti: for LP we mostly take the approach of just stripping off build profiles, although you have to be quite careful with that because obviously < and > have other meanings too.  There's a giant regex in modern libdpkg-perl that can sensibly be appropriated for the purpose.
[11:15] <pitti> so, [ (test1, '', V), (test2, '', V), (test2, 'reboot_id', V2), ...]
[11:15] <pitti> apw: ^
[11:15] <apw> pitti, that seems more than enough indeed ... i hope we anr't overdoing it
[11:15] <pitti> cjwatson: ack, thanks
[11:15] <apw> pitti, and would you have kernel_version: as the "after update" one for the common case ?
[11:16] <pitti> apw: "after test bed setup" would be the first entry with the special reboot ID ''
[11:17] <apw> ie at the start of the first test, so always the first entry in fact
[11:17] <pitti> right, and it's a list, thus ordered
[11:17] <pitti> apw: with that we only need exactly one kernel_versions: with that list of triples
[11:17] <apw> well that works for my use case :)
[11:18] <apw> ironically i will just run the list and make sure V does not change, and use it
[11:19] <pitti> apw: http://paste.ubuntu.com/12327750/
[11:19] <pitti> apw: (no tuples in json, they become lists, but *shrug*)
[11:20] <apw> that looks good to my eye, over engineered to hell and back i am sure, but yes
[11:21] <apw> pitti, is this going to be like a systeminfo file with other things later ?
[11:21] <pitti> apw: so that's one option; the other is http://paste.ubuntu.com/12327760/
[11:21] <pitti> apw: yeah, hence the top-level dict
[11:21] <pitti> apw: I don't want to add yet another file in the future for similar system state info
[11:22] <pitti> apw: and in fact I'd like to merge testbed-packages into this one
[11:22] <apw> pitti, the second one is simpler for the normal case, and provides the same info as long we include any test which runs != 1.2 in the bottom
[11:23] <pitti> apw: a file like this sounds interesting if/once we run tests on real iron
[11:23] <apw> ie if there was test3 which didn't reboot after test2
[11:23] <pitti> apw: it's a reduced list, so if there is a test3 which doesn't reboot, it'd just use teh default kernel
[11:24] <apw> pitti, but we rebooted in test2 and are on that kernel now no ?
[11:24] <pitti> well, I suppose you can construct a package test which runs test3 without reinitializing the testbed
[11:24] <pitti> apw: but it would appear in the list then
[11:24] <pitti> apw: i. e. the idea was to not show anything in the list which has (_, _, default_kernel_version)
[11:25] <pitti> apw: so that your check reduces to "this list must be empty"
[11:25] <apw> right, if thats what it is doing, that works too
[11:25] <pitti> apw: but I don't care much either way, pick your poison :)
[11:25] <apw> well the second is much shorter in the common case where theer is no reboot
[11:25] <apw> so ... making it harder for those who care is fine with me :)
[11:26] <apw> pitti, so i think i am voting for kernel_version + test_kernel_versions form
[11:28] <pitti> apw: ack; I sent a summary to the bug
[11:28] <pitti> and now, lunch for realz
[11:28] <apw> perhaps kernel_version_changes: to get them to sit by each other in the json
[11:29] <apw> as it is a delta list effectivly
[11:29] <pitti> noted in the bug, good call
[11:29] <apw> pitti, you should record the trigger in there too
[11:30] <apw> just becasue, and name the file such that it can :)
[11:35] <pitti> apw: *nod*
[14:42] <teward> at what point did we switch to predictable interface names?  Is that a recent thing?  (First proposal email I can find is May 2015...)
[14:45] <ogra_> heh ... i still cant stop laughing about that naming :)
[14:46] <ogra_> teward, i think in wily at some point
[14:46] <teward> ogra_: what about retroactive changes?  Trusty (all variants) still on the older system?
[14:46] <ogra_> pitti might have the exact date
[14:47] <ogra_> yeah, trusty still uses properly guessable names
[14:47] <pitti> teward: https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
[14:47] <pitti> on June 17
[14:47] <ogra_> such an insane move
[14:47] <teward> pitti: and that was never implemented retroactively, or for the latest trusty point releases?
[14:48] <pitti> teward: heck, no -- that's a rather intrusive change, it's really not backportable
[14:48] <ogra_> haha, yeah
[14:48] <teward> pitti: tell that to dschatz_ in -server
[14:48] <pitti> well, "able" yes, but we so much won't
[14:50] <teward> right, i knew it was being enabled in Wily, heck I even discovered the server installer iso bug where it was still using the older system and not the one it should be (the 'installer installs eth# which means networking doesn't load after reboot' problem)
[14:50] <teward> which was fixed same-day xD
[14:51] <ogra_> well, but that shows pretty good why backporting would be insane :)
[14:51] <teward> and i'm fairly familiar with "Yeah not backporting sorry" things, from all the 'security' changes from the SSL vulns and such that prompted default-config changes in http server packages and such that didn't get backported to other ubuntu releases, but meh.  was fairly certain that was the case.
[14:51] <teward> ogra_: indeed
[14:51] <ogra_> lots of scripts to change etc etc
[14:51] <teward> mhm
[14:51] <teward> oop that reminds me.  Note to self: update wily VM >.<
[15:59] <pitti> apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/
[15:59] <apw> pitti, sweet ... thanks for that


[01:53] <bluesabre> ochosi: going to update the copyrights for libreoffice-style-elementary... then it should be just up to you tagging a release for it
[02:37] <bluesabre> ochosi, knome: so, here's my proposed license for the libreoffice-style-elementary theme http://pad.ubuntu.com/lo-style-elementary-copyright
[02:38] <bluesabre> s/license/copyright-file
[08:32] <knome> bluesabre, you can use<EMAIL_ADDRESS>for my email
[08:33] <knome> or i can do that myself :)
[08:35] <knome> removed the dot after the l-s-e GPL note for consistency
[11:55] <bluesabre> knome: thanks
[12:55] <ali1234> okay why does my numlock key keep turning off?
[13:22] <bluesabre> probably a greeter issue or something
[13:23] <bluesabre> can use this as a workaround it seems https://ubuntu-mate.community/t/numlock-turns-on-ubuntu-mate/1215
[13:35] <ali1234> i have not logged out since i installed
[13:35] <ali1234> numlock turns off randomly every day
[13:35] <bluesabre> oh
[13:35] <bluesabre> thats bizarre
[16:57] <slickymaster> Unit193, downloaded. Next monday will test it in VB
[17:39] <bluesabre> Unit193: don't suppose you know if anything is missing from the next x-d-s upload?
[17:39] <bluesabre> :D
[18:06] <krytarik> bluesabre: Since you are asking, the default font for both the terminal and Mousepad should be Droid Sans Mono too, rather than DejaVu Sans Mono. :P
[18:30] <bluesabre> krytarik: actually, we changed that from Droid Sans Mono at one point in the past because it was less readable, iirc
[18:30] <bluesabre> I'd have to check around the commits for that :)
[20:40] <Unit193> Not offhand.
[20:45] <knome> bluesabre, you're correct, dejavu sans mono isn't a mistake
[21:28] <ochosi> bluesabre: i'm taking a look at the copyright thingy now
[21:29] <ochosi> looks good to me
[21:29] <ochosi> i guess that one's a go
[21:53] <ochosi> bluesabre: pushed the new copyrights file and dropped the other ones
[21:53] <ochosi> thanks!
[22:10] <ochosi> bluesabre: and released: https://github.com/shimmerproject/libreoffice-style-elementary/releases/tag/v0.1
[22:10] <ochosi> when i have the time, i'll blog about it (or anyone else can, if they want to, currently it's too hot here for doing much work)
[22:11] <ochosi> bluesabre: also lemme know when you upload all that artwork stuff so i can check it off the blueprint
[22:30] <ochosi> enough for one evening, night everyone
[22:33] <sorinello> Hello. Does anyone here knows a bit of GTK ?
[22:38] <knome> sorinello, while this isn't the GTK channel, why not ask the real question and find out?
[22:38] <knome> night ochosi
[22:39] <sorinello> Hello :) I am playing/learning a bit GTK. The idea is that I have a small window with a gtk_entry, on which I have set a signal_connect. But I don't know how to pass data to it.
[22:39] <sorinello> I am using this:   g_signal_connect (text_entry, "activate", G_CALLBACK (print_event), data);
[22:39] <knome> ok, you'd be much better off in a real gtk channel
[22:40] <sorinello> I've already asked
[22:43] <bluesabre> hey sorinello
[22:44] <sorinello> hello bluesabre
[22:44] <bluesabre> that looks right
[22:44] <sorinello> bluesabre, yes, the problem is that I want to pass the contents of the gtk_entry to the callback function
[22:45] <sorinello> and I don't know how to get the contents :)
[22:45] <sorinello> I tried: g_signal_connect (text_entry, "activate", G_CALLBACK (print_event), gtk_entry_get_text(text_entry)); but I get a compilation error
[22:45] <bluesabre> you get the data for the widget in the callback function
[22:46] <bluesabre> gtk_entry_get_text(GtkEntry *entry)
[22:46] <sorinello> so from the activate function, how do I declare the data variable ?
[22:46] <bluesabre> the callback follows this format
[22:46] <bluesabre> void
[22:46] <bluesabre> user_function (GtkEntry *entry,
[22:46] <bluesabre>                gpointer  user_data)
[22:47] <bluesabre> so in that function, just use gtk_entry_get_text on the entry that is connected
[22:48] <sorinello> ok, but g_signal_connect (text_entry, "activate", G_CALLBACK (print_event), data); the "data" variable, how do I declare it, what type ?
[22:48] <bluesabre> for data, just use NULL
[22:48] <bluesabre> since you're not passing anything extra in
[22:48] <sorinello> okay
[22:49] <sorinello> my user function has this signature
[22:49] <sorinello> void
[22:49] <sorinello> print_event(GtkWidget * widget, gpointer data)
[22:49] <sorinello> I guess I'll have to replace GtkWidget with GtkEntry
[22:49] <bluesabre> you can do that, or cast the widget to GtkEntry
[22:50] <bluesabre> there might be a newer one for gtk3, but this should all still be relevant https://developer.gnome.org/gtk-tutorial/stable/
[22:51] <bluesabre> I've gotta run out for dinner, but you should be able to get a lot of answers from that
[22:51] <sorinello> bluesabre, It worked. Thanks a lot !


[16:56] <Snap4x> Hy, kann jemand deutsch hier? :D
[16:58] <Snap4x> can anyone help me? i had update to 15.xx from 14.xx now is the display max. 1024x786, but i need 1680x1050.
[16:59] <Snap4x> i doesn't found anyway :( about the terminal or about the nvidia x-server
[17:18] <holstein> Snap4x: what did you update from?
[17:18] <holstein> 14.10? to 15.04?
[17:18] <Snap4x> ja
[17:18] <holstein> what i would do is simply check the driver i am using, and try the proprietary driver
[17:18] <holstein> re-install it, if necessary
[17:19] <Snap4x> which?
[17:19] <Snap4x> btw how?
[17:19] <holstein> Snap4x: the one that fits your needs.. likely the nvidia one
[17:19] <Snap4x> :D
[17:19] <holstein> Snap4x: i use a package manager to do so
[17:19] <holstein> Snap4x: there is a GUI for checking which proprietary drivers are in use
[18:39] <sakrecoer_Z> avconv is great, it's just so poorly documented compared to ffmpeg....
[18:40] <sakrecoer_Z> oh... i was scrolled way up sorry..
[18:41] <sakrecoer_Z> i'm going crazy with ssh-add and gnome-keyring thing...
[18:41] <sakrecoer_Z> i made some temporary keys to learn, but now i can't find how to get rid of them.... gnome keyring loads them, but i don't know where from..
[18:42] <sakrecoer_Z> ssh-add just wont remove them..
[18:42] <sakrecoer_Z> i find dozens od threads in launchpad, as old as 2010...
[18:43] <sakrecoer_Z> but non of the "sollution" is clearly explained, they all link to threads that have a sollution in post with a link to another threads post links..
[18:45] <sakrecoer_Z> and so forth...
[18:47] <holstein> sakrecoer_Z: anything like that, can be taken care of with the normal ubuntu documentation
[18:47] <sakrecoer_Z> thanks holstein, what and where is "normal" ubuntu doc? :)
[18:47] <holstein> http://askubuntu.com/questions/20865/is-it-possible-to-remove-a-particular-host-key-from-sshs-known-hosts-file
[18:47] <holstein> https://help.ubuntu.com/community/SSH/OpenSSH/Keys
[18:48] <holstein> im just saying, there is no "ubuntustudio ssh key"  situation.. since, ubuntustudio is ubuntu
[18:48] <sakrecoer_Z> ah... ok.. yeah sorry
[18:48] <sakrecoer_Z> well that ask page i have read already, its not my case...
[18:49] <sakrecoer_Z> i'm trying to remove the old keypair from my computer...
[18:49] <sakrecoer_Z> local computer
[18:49] <holstein> sure. you locate the key you want to remove, and you can remove it
[18:49] <sakrecoer_Z> moved the file
[18:49] <holstein> i usualy just do it manually
[18:49] <sakrecoer_Z> sorry... how
[18:49] <sakrecoer_Z> ssh-add -d
[18:49] <holstein> sakrecoer_Z: i literally used a text editor..
[18:49] <sakrecoer_Z> but then when i do ssh-add -l it is still there..
[18:49] <holstein> but, im sure there are other more elegant ways..
[18:50] <sakrecoer_Z> you don't understand my situation...
[18:50] <sakrecoer_Z> let me find a link that explains it..
[18:50] <sakrecoer_Z> :)
[18:50] <holstein> sakrecoer_Z: cool.. feel free and elaborate for a volutneer here
[18:50] <holstein> sakrecoer_Z: or, you can also use #ubuntu since its not related to ubuntustudio specifically
[18:50] <holstein> or, maybe the server channel.
[18:50] <holstein> !server
[18:50] <holstein> though, i think it can be slow as well..
[18:50] <sakrecoer_Z> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472477
[18:51] <sakrecoer_Z> and then this one: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/505278
[18:52] <sakrecoer_Z> some people seem to find a sollution in that thread, i'm.... well barely hairless :D
[18:53] <sakrecoer_Z> i'll try in #ubuntu :) sorry i didn't understand you first holstein, ty for assisting me
[18:54] <holstein> For those that are winding up at this bug report from searches looking to resolve the problem - regardless of platform, here's a quick "fix":
[18:54] <holstein> * Move the keys out of ~/.ssh * gnome-keyring-daemon -r -d
[18:54] <holstein> It's certainly not an actual fix, but will at least resolve the immediate annoyance.
[18:54] <holstein> sakrecoer_Z: otherwise, i dont personally use gnome-keyring, so, i cant give you any first hand advice.. i konw, i have used ssh keys, and added and removed them, and had no issues
[18:55] <sakrecoer_Z> well.... i never used it either... i have no idea how my keys eneded up tehre...
[18:55] <holstein> the keys are not likely there.. but, referenced there
[18:55] <holstein> you can look and see..
[18:55] <sakrecoer_Z> i moved the keys out of ~/.ssh
[18:56] <sakrecoer_Z> gnome-keyring-daemon -r -d gave me no result.
[18:56] <holstein> ah.. #26 is relevant. its not a bug, its a feature
[18:56] <sakrecoer_Z> rebooted... still nothing..
[18:56] <holstein> https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1271591
[18:56] <sakrecoer_Z> i don't get it... the keys are fare away from my system, but ssh-add -l claims to still have a copy..
[18:56] <holstein> sakrecoer_Z: are you up to date with updates?
[18:57] <holstein> what operating system are you using?
[18:57] <sakrecoer_Z> yes i think i'm up to date...
[18:57] <sakrecoer_Z> ubuntustudio 14.04.3
[18:57] <holstein> in a terminal "sudo apt-get update && sudo apt-get dist-upgrade" will tell you
[18:57] <sakrecoer_Z> holstein: yeah... but.... i want to be on LTS...
[18:58] <sakrecoer_Z> maybe its not a good idea...
[18:58] <sakrecoer_Z> to be on LTS...
[18:58] <holstein> sakrecoer_Z: sure.. *stay* on the LTS, running, in the terminal, the command i gave, after researching it, and discovering that it *does* not upgrade you from the LTS
[18:58] <sakrecoer_Z> now i'm confused...
[18:58] <holstein> you remain on the LTS, but, you can *know* that you are up to date with upgrades
[18:58] <sakrecoer_Z> hehe
[18:59] <holstein> sakrecoer_Z: please, open a terminal, and run "sudo apt-get update && sudo apt-get dist-upgrade" which *does* *not* upgrade you from the LTS version you are running
[18:59] <sakrecoer_Z> ok
[19:00] <sakrecoer_Z> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[19:01] <holstein> right. so, no upgrades will "fix" that
[19:01] <holstein> and, i havent personaly had that issue
[19:01] <holstein> so, maybe, since, you are not wantinng to use that gnome-keyring, you can simply stop using it
[19:01] <holstein> not sure..
[19:02] <holstein> i would try upstream at #xubuntu or #ubuntu since we really dont deal with the plumbing on that, AFAIK
[19:02] <holstein> could be, a fix that didnt get specifically applied to ubuntustudio and i wouldnt know
[19:02] <sakrecoer_Z> ok. :) thank you for your precious time anyway holstein
[19:10] <sakrecoer> hehe... bad timing i guess... #ubuntu is flooded with support requests. hehe
[19:12] <holstein> i would look in the config, and see if i can blow it out
[19:12] <holstein> i would look into not using the keyring, since, you seem to not want it
[19:12] <holstein> might mess up other things, though..
[19:12] <sakrecoer> i don't even know why it is in use haha
[19:13] <holstein> i would elaborate about what is not working from that "fix" in the post
[19:13] <sakrecoer> i don't remember ever putting my keys there, i sure did add it to ssh-add
[19:13] <holstein> gnome-keyring-daemon -r -d
[19:13] <holstein> could be, its *not* the gnome keyring doing it..
[19:14] <sakrecoer> well.... ssh-add tells me it is using the key ~/.ssh/id_rsa but there is no sych file on my system ATM
[19:15] <sakrecoer> and as for the "fix" in the post,,,, i can't even identify it, even less how it works...
[19:15] <holstein> whats the issue?
[19:15] <holstein> you added a key? and now you want to remove it? and its a "test key"?
[19:16] <holstein> i mean, if you just started learning about keys, maybe just leave it there.. and deal with it later.. try doing tests from VM, or, live iso's..
[19:16] <sakrecoer> there is a ghost key in my system... a key that is supposed to be gone, is not gone...
[19:16] <holstein> sakrecoer: its not a "ghost key", though, is it? i mean, you put it there, correct?
[19:16] <holstein> you are just trying to remove a key that you made, as a test, correct?
[19:16] <sakrecoer> yes
[19:17] <sakrecoer> well.... i tryed to remove it because it didn't work
[19:18] <sakrecoer> first time it did... after i add it with ssh-add
[19:18] <sakrecoer> but eversince, when i would try to invoke it, there would be a winodw poping up asking for the passphrase, but then i would have to use passwrod anywya..
[19:20] <holstein> if its an ssh key with a passphrase, thats the way its supposed to work
[19:21] <sakrecoer> yeah.. but... once you have given the passphrase to your key, the server to which you just uploaded the public key should NOT ask you for a passphrase...
[19:21] <sakrecoer> and the server would ask me for passphrase..
[19:21] <sakrecoer> not the one of my key so to speak
[19:23] <holstein> sakrecoer: sounds normal.. if you have not "unlocked" the keyring
[19:23] <holstein> i have had that, in the past, when joining wifi networks..
[19:24] <sakrecoer> no.... thats not whats ahppening..
[19:24] <sakrecoer> i HAVE unlocked the keyring,... but it wouldn't do anything.
[19:25] <sakrecoer> thats why i wanted to remove the keys... they didn't work like they should...
[19:25] <sakrecoer> the problem is, i cant remove them
[19:25] <sakrecoer> i can still unlock the keyring
[19:25] <sakrecoer> but the keys are useless even tho they are in my servers ~/.ssh/authorized_keys
[19:26] <sakrecoer> and i tried on 3 different servers...
[19:26] <holstein> sure
[19:26] <holstein> i say, stop trying like that, so randomly
[19:26] <holstein> since, its obiously more on the client end..
[19:26] <holstein> i say, setup a scenario in VM, or, on a few local machines.. so you control the variables, and can work with the setup, and learn what you are missing
[19:32] <sakrecoer> thank you holstein ... i'm sure it s a good idea. i just don't really know how to apply it. But don't worry i will eventualy find out...
[20:37] <sakrecoer> ok... something is wrong with my client. i can't reproduce the problem.
[20:38] <sakrecoer> ... reproduce it on another client
[20:39] <holstein> well, that sounds like a data point, to me
[20:39] <sakrecoer> ssh-add has no identity until i add it. i was thinking that it was gigolo that messed up soemting for me, but it wont mess up anything on this one..
[20:39] <sakrecoer> when i remove identity it's gone liek it should
[20:39] <sakrecoer> even if i use a gigolo bookmark...
[20:40] <sakrecoer> so, something is broke in the other one.
[20:40] <holstein> yeah. gigolo shouldnt affect.. agreed
[20:41] <sakrecoer> it's like the broken client started useing a diffrerent keymanager... the prompt gigolo presnts me is different on the broke client.
[20:41] <holstein> well, is anything "broken"?
[20:41] <sakrecoer> except from that, no...
[20:41] <holstein> whats the difference in the machines?
[20:41] <sakrecoer> i mean... not as far as i can see.
[20:42] <sakrecoer> when i boot the broken, there is already an Identity attached to ssh-add
[20:42] <holstein> i think, i would just reset the keyring config, and, if all is well, not worry with it
[20:42] <sakrecoer> but how do i reset the keyring config? i can't find it
[20:43] <sakrecoer> in my startup-task gnome key-ring is not activated, but the deamion is there on ps aux
[20:43] <holstein> do you have a .local/share/keyrings ?
[20:44] <sakrecoer> yes!!!
[20:44] <sakrecoer> haha
[20:44] <holstein> i wouldnt just delete things.. either
[20:44] <holstein> i would just rename, or move.. and test..
[20:45] <sakrecoer> let me try that on the broken client.... and i'll brb... :)
[20:48] <sakrecoer> hm... there are no default file on the broken client..
[20:49] <sakrecoer> moved the ~/.local/shared/keyring/ but the id is still in ssh-add ---
[20:53] <sakrecoer> where is it stored (i did reboot)
[20:56] <sakrecoer> on both clients both with latest upgrades, i have to different dialogs when the GUI asks med to unlock my key
[20:56] <sakrecoer> one is entitled "pinentry" and ask me t unlock key with fingerprint "bl:ab:la:bla" in ~/.ssh/id_rsa (which is not present)
[20:58] <sakrecoer> the other is entitled "unlock private key" and says apllication want s acces to private key "foo@domain"
[20:58] <sakrecoer> gah... sorry holstein never mind, i thinking out loud. I really appreciate the little directions you could give me anyhow
[21:00] <sakrecoer> oh... but i remember ticking that box: "automaticaly unlock this key whenever i'm logged in"
[21:00] <sakrecoer> on the broken client...
[21:02] <holstein> right.. so, you can reset those settings, ideally
[21:03] <holstein> its probably just a simple config that you have agreed to somewhere along the way, that is doing something not expected
[21:03] <holstein> but, is it really breaking anything?
[21:03] <holstein> i mean, if its a test server, i say, just dont use it, anymore.. and, its not a security issue
[21:04] <holstein> its not like, its allowing access back into your machine from somewhere, and you are tyring to block it
[21:04] <holstein> then, as you get more familiar with the tools, i bet, you can knock it out, no problem
[21:04] <sakrecoer> the problem is not the server. the prbolem is that these keys are stuck in my main machine...
[21:04] <holstein> right
[21:04] <holstein> but, the keys to what, friend?
[21:05] <holstein> a test server? that really doenst break anything for you?
[21:05] <holstein> something you can easily just ignore for a bit?
[21:05] <sakrecoer> i mean sure, i cane remove the oublic key from my servers "authorized_keys".... but i'm still stuck with this identity on this box...
[21:05] <holstein> sure..and, is that a problem?
[21:05] <sakrecoer> well... if i have to use keys at all, i wish i would know where they are stored, so that i can replace them if i have to...
[21:06] <holstein> sakrecoer: sure, but, do you really need to learn all that right now?
[21:06] <sakrecoer> i don't know, it's kindof step 3 in the "set up dev environement"...
[21:06] <holstein> sakrecoer: where?
[21:07] <sakrecoer> here https://wiki.ubuntu.com/UbuntuStudio/SetupDeveloperEnvironment
[21:08] <holstein> and that is the step that is "broken" for you?
[21:08] <sakrecoer> ye..
[21:08] <holstein> creating that key still doesnt break anything, if an older one is around..
[21:09] <holstein> those are quite different than the ssh keys we have been talking about
[21:10] <sakrecoer> ok.. make it a point 4. i'm not strugling with gpg keys
[21:10] <holstein> but, whats the point?
[21:10] <holstein> ssh keys are just for you to have access to a server, if you need
[21:10] <holstein> you dont *have* to have that to help with development
[21:11] <holstein> if you need one, you can generate one. if you have one that you are trying to remove, and cant, its not posing a security threat
[21:11] <holstein> i realize, i deally, you want to understant the system.. and all i can say is, its always been as it is on the other machine for me. or, i just dont use the keyring tools like that
[21:19] <sakrecoer> it's fine holstein, i'm not expecting you nor anyonw to be able to solve everything... but, maybe there should be another wiki page for n00b-devs like me...
[21:19] <holstein> sure.. start what you like
[21:19] <holstein> but, its just not needed.. the ssh key  doesnt do any development
[21:20] <holstein> andm, if you are just learning, its not going to hurt anything to just give yourself some time, to see what has happened
[21:20] <holstein> ssh keys are handy if you are using them to connect to a server.. is that what you are doing?
[21:23] <sakrecoer> yes i watned to connect to a server using those test keys. it works on one machine on the other, not.. but sure, who cares? just a bunch of useless keys. it would still have been nice to find out where they get stored on my system...
[21:23] <holstein> well, are they useless?
[21:24] <holstein> what i did was, i setup environments locally, and created keys, and tested.. in an environment where i have complete control of the network
[21:24] <holstein> otherwise, what about development are you not able to do?
[21:24] <sakrecoer> well, for the sake of anyother person than me, at the moment,, absolutely useless...
[21:31] <sakrecoer> holstein: otherwise, what i am not able to understand about devlopement is where to start.
[21:31] <holstein> sakrecoer: what are you trying to develop?
[21:33] <sakrecoer> worldpeace? no ... ok...first i go eat something, then i will try to find an answer to that question........
[21:40] <sakrecoer> much better... :)
[21:41] <sakrecoer> im not sure what i want to develop holstein, because i'm not sure what i can devlop. I'm trying to catch up with you guys and its super hard.
[21:41] <holstein> im not a developer, like that
[21:41] <holstein> i dont plan to be
[21:42] <holstein> but, you can do that, for sure.. but, as you know, you dont need ssh keys to develop.. thats just to connect
[21:42] <holstein> i suppose, all im saying is, if you want to develop something, lets talk about that, and not get too sidetracked here about ssh key management
[21:43] <sakrecoer> you are so wise holstein. and a kickass supporter.
[21:43] <holstein> im not sure what has happened on one of your machines, but, im sure, its something that, if you give yourself time, you'll be able to sort it out. and you are not breaking anyting, or causing a problem with security,or preventing any development
[21:43] <holstein> sakrecoer: well, thanks.. i hope i can point you in the right direction..
[21:44] <sakrecoer> you see, that is the thing about this new dev dimesnio for me, i can't seem to find where things are going
[21:44] <sakrecoer> to get someone to point me to a direction, i need to know where to go
[21:44] <holstein> sure.. but, keep in mind, one thing nice about linux is, noting is hiding from you
[21:45] <sakrecoer> hehe.. when you know whre eot find them :)
[21:46] <holstein> well, ubuntu is not a distro that is really about that, necssarily.. its not a distro that says "come, and kick the tires.. customize and enjoy the open-ness"..
[21:47] <holstein> it *is* open.. but, it also has a lot of sane-defaults that are arguably forced on the user
[21:47] <holstein> but, those are what makes things "just work" too..
[21:51] <sakrecoer> yes. and they do just work in the box actualy. At least for me, most of the time. Especialy when it comes to its purpose. But the "software" to recruit freshmen like me, is pretty shitty :D
[21:51] <holstein> the software?
[21:51]  * sakrecoer missunderstands itself left
[21:52] <holstein> *all* of linux is completely open.. if *anyone* wants to release any software for linux, they can
[21:52] <holstein> if they dont, we cant make them..
[21:52] <sakrecoer> yes, i mean, the infrastucture is super chaotic to even grasp.
[21:53] <holstein> is it?
[21:54] <sakrecoer> maybe i'm just not good at it... its frankly speaking a possible parameter. But yes.
[21:55] <holstein> you are not good at grasping the infrastructure? its a lot to take on
[21:55] <sakrecoer> exaclty. there is so much to take on....
[21:55] <holstein> what are you coming from? likely nothing on the scale of what we are talking about.. its a lot to think about.. developing for the entire OS.. all open.. etc
[22:05]  * sakrecoer is lost in translations :D
[22:05] <sakrecoer> bottom line is like you wrote: 'lets not get sidetracked by SSH keys'
[22:13] <sakrecoer> thanks for precious time holstein see you!
[22:15] <holstein> sakrecoer: cheers..


[00:36] <mickey2001> hi. downloading mate 16.04 as we speak. is it any good? new linux user. started with 15.10
[00:52] <nomic> yes
[01:19] <Nocturius> Hello, I can't set my monitor to 1920x1080 using nvidia-304-updates from xorg edgers. GPU is geforce 6150se, connected via VGA. I was able to set 1920x1080 res with nouveau drivers, but crashed frequently
[01:20] <Nocturius> I have also tried the nvidia-304 packages from main, currently using the xorg edgers driver
[01:21] <nomic> Nocturius - not always busy / attended here,  post a query on the forum  https://ubuntu-mate.community/
[01:22] <nomic> or ask in #ubuntu
[01:22] <nomic> cos that has 1900 users in it
[01:22] <nomic> also http://ubuntuforums.org/  <- v busy forums site
[01:23] <Nocturius> nomic: thanks, I'm also asking in #ubuntu, thought I'd give it a shot here also
[01:23] <Nocturius> I'll post in the forums if nothing gets resolved in ubuntu channel
[01:24] <nomic> ok
[01:25] <nomic> most problems of ubuntu are ubuntu mate .. the only thing diff is the desktop & that is also gnome
[01:25] <nomic> or even ask in debian .. ubuntu = debian base
[01:27] <Nocturius> right, I switched to ubuntu mate from bunsenlabs hydrogen which is based on debian jessie. Was having the same problems there but crashes were even more frequent
[03:35] <thuselem> Greetings all. I have a keyboard shortcut question.
[03:36] <thuselem>  In the 15.04 version, using compiz, I could maximize a window using <Ctrl><Super>Up-arrow. I am not able to do this in the current release.
[03:37] <thuselem> I am looking for a way to set the shortcut. Earlier I was discussing it with someone, and the had the shortcut advertised in System > Control Center, then Keyboard Shortcuts.
[03:38] <thuselem> I am not seeing Maximize Windows or Toggle Maximization in my Keyboard Shortcuts.
[03:38] <thuselem> (*the current release being 16.04, which I just installed and am loving!)
[04:15] <sachin_> hi
[04:19] <thuselem> Hi
[10:07] <Akuli> Do we still have the spammer we had yesterday?
[10:08] <Akuli> He was on #devuan a few days ago.
[10:13] <Phoenix84> Anyone in room using an ALPS touch-pad??
[10:13] <gordonjcp> Akuli: the god-botherer?
[10:13] <Akuli> yes, that one.
[15:09] <ubuntu-mate> que wea
[15:27] <msev-> is it possible for the mate panel to "intelligently" autohide, meaning it pops up back if the windows is not maximized
[15:31] <Mordoc_mystery> I just tried it and it doesn't appear to behave that way. Just looking in tweak for any other options...
[15:34] <msev-> since for example xfce panel has that option
[15:34] <msev-> nope I can't find a setting for that
[15:34] <msev-> lemme try mate-dock-applet
[15:35] <msev-> but I need to compile it first since I'm still on 14.04
[15:35] <msev-> and the one from the webupd8 ppa is buggy as hell since its too old version
[15:53] <dannii> guten Tag zusammen
[15:54] <dannii> darf ich auf deutsch fragen?
[17:36] <vdi> hello
[17:36] <Akuli> Hi vdi
[17:36] <vdi> I just installed this OS on raspberry pi, this looks very cool
[17:37] <vdi> I need to install bundle package of vmware horizon client, can some please guide me through
[17:37] <vdi> I know how to install on regular ubuntu/linux but not on PI since it is special kernel ?
[17:38] <Akuli> pi is not using an intel processor
[17:38] <Akuli> so some packages are different
[17:39] <vdi> also audio is not working, I mean the USB audio works but regular jack is not working
[17:39] <vdi> do you have some information about it Akuli ?
[17:39] <Akuli> Audio on linux is generally all about trial and error to get it working :)
[17:39] <Akuli> Also, i'm no raspberry pi expert.
[17:40] <vdi> no problem Akuli
[21:26] <thuselem> Greetings.
[21:39] <thuselem> I have a keyboard shortcut question. I am not seeing Maximize Windows or Toggle Maximization in the Control Center's Keyboard Shortcuts.
[21:39] <thuselem> Is there another way to set them?
[21:43] <staeksauce> every time I reboot I have to reset my sound output to my headphones to hear anything, is there a way to make my headphones the default sound output?
[21:47] <sinewav> thuselem: Alt+F10 toggles the maximize state. I found it in the keyboard shortcuts on Ubuntu Mate 16.04.
[21:48] <thuselem> Oh, yeah... I would like to switch it to Ctrl-Super-Up Cursor. I got used to using that keybinding in tandem with the Ctrl-Super-Left and Right arrows for maximizing a shifting windows to the sides.
[22:04] <thuselem> Wait... you can see an option for maximize state in keyboard shortcuts? Documentation or the settings dialog?
[22:15] <sinewav> thuselem: From the settings dialog, under "Window Management"
[22:17] <sinewav> From your terminal, mate-keybinding-properties
[22:20] <thuselem> I switched from Compiz back to Marco and switched it in the UI dialog, but it doesn't carry over to Compiz.
[22:22] <thuselem> Perhaps not available with Compiz? The shortcut was set up in my 15.04 installation.
[22:22] <thuselem> Though, the situation may be different since that machine has Ubuntu 15.04, with MATE desktop and extras.
[22:28] <sinewav> Yeah maybe. I'm new to Mate as of 16.04. I used XFCE for years but the file manager is too buggy.
[22:33] <thuselem> I really like MATE. Simple, usable with lots of nice detail work all over.
[22:50] <staeksauce> every time I reboot I have to reset my sound output to my headphones to hear anything, is there a way to make my headphones the default sound output?
[23:08] <thuselem> Yay! I figured out how to add the shortcut. I installed compizconfig-settings-manager, and was able to add a Maximize keyboard shortcut there.


[04:08] <malev> hi, is there a list of common answers about bug's reporting but for the kernel?
[12:57] <matti> ;]
[16:44] <philsf> can someone please help me debug a problem in my usb stack? I can't mount or use any USB device. This is what appears in kern.log when I plug a pendrive (that works on other ubuntu boxes)  http://pastebin.com/f489fcdd0 . This is a karmic up to date netbook, and it used to work
[16:44] <philsf> should I just report a bug? I'd hope this would be some trivial misconfiguration I'm missing
[17:46] <crimsun> philsf: could be hw or driver; it tends to be more the former
[17:58] <philsf> crimsun, it works if I boot an image (say, the nbr install image) from the pendrive, and it works in windows
[17:58] <philsf> also, the pen drive works in other ubuntu boxes
[18:00] <philsf> crimsun, it stopped working after a large update - this was it IIRC http://pastebin.com/f13834c7a
[18:01] <philsf> it was working the day before, and I tried to use the pen drive just after the update, and it didn't work anymore. I'm clueless