=== _salem is now known as salem_
=== arrrghhh is now known as arrrghhhAWAY
=== salem_ is now known as _salem
[12:49] <cjwatson> stgraber: Right.  It *looks* like it's auto-imported, but it would be good if you could check it over if you get a moment.
[16:45] <almostevery> hello, is this the ubuntu dev channel?
[16:55] <almostevery> hello, can anyone help please? I have a problem with 14.04. keyring program
[16:56] <kklimonda> almostevery: it's not really the best channel for asking support questions (especially on weekends), it's for discussing development of ubuntu itself.
[16:57] <kklimonda> almostevery: you'll have more luck on #ubuntu probably
[16:58] <almostevery> kklimonda, it is where I'm coming from, as it is beyond a support matter. and my question is precisely about a problem related to design-development of the keyring program on 14.04.
[17:00] <almostevery> I just started using 14.04., and saw that the new design of the keyring program doesn't 'forget' the keyring passwords. that is, across restarts of computer or re-insertions of hardware, it doesn't ask the password again, but instead it suffices to right-click on unlock to access the keyring.
[17:00] <almostevery> that is, it suffices to access desktop to access a keyring, if it is once decrypted via its respective password
[17:01] <almostevery> which wasnt the case in 12.04. I dont know 13.04. or 13.10. as I didnt use them
[17:02] <kklimonda> you may have more luck asking during the working week, right now most people aren't around
[17:02] <almostevery> well, maybe I have. let's see..
[17:02] <mdeslaur> almostevery: the keyring is automatically unlocked with your login password when you log in
[17:02] <mdeslaur> almostevery: that's how it always worked
[17:03] <almostevery> mdeslaur, yes, for the 'login' keyring it is true. but login keyring is not my only keyring, and until now it wasn't the case that all other keyrings were 'kept open' forever in the way I described above. this is the novel problem.
[17:04] <mdeslaur> almostevery: if you don't want it to use your login password to unlock automatically, you can change it in the Passwords and Keys tool by right-clicking the "Login" section and selecting "Change password"
[17:04] <mdeslaur> almostevery: are you using the same password for the other keyrings?
[17:06] <almostevery> mdeslaur, even there, it is not the same thing as before. it never was the case that accessing desktop released access to all keyrings that have been unlocked before.
[17:06] <mdeslaur> almostevery: I'm guessing people thought that was a bug that needed fixing :)
[17:07] <mdeslaur> almostevery: perhaps open a bug with the upstream gnome-keyring project?
[17:07] <almostevery> mdeslaur, yes. this was what I heard in the support channel
[17:08] <almostevery> mdeslaur, I have installed 14.04. only now, and promptly noticed this. hasn't this been reported as a problem until now?
[17:08] <mdeslaur> almostevery: nope
[17:08] <almostevery> since April?
[17:08] <mdeslaur> almostevery: most people are happy that the bug is finally fixed and it automatically unlocks all keyrings I guess
[17:11] <almostevery> mdeslaur, 'bug is finally fixed'? which bug was there?
[17:11] <mdeslaur> almostevery: please file a bug with "ubuntu-bug gnome-keyring", then file an upstream bug here: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring
[17:12] <mdeslaur> almostevery: people used to complain that the other keyrings wouldn't unlock automatically at login
[17:13] <almostevery> mdeslaur, and you call this a 'bug'?
[17:13] <almostevery> it is a feature.
[17:13] <mdeslaur> almostevery: that's why you should file a bug upstream, and explain your point of vue and see if they agree and will change t
[17:14] <mdeslaur> it
[17:14] <mdeslaur> s/vue/view/
[17:15] <mdeslaur> almostevery: oh, are the passwords for your other keyrings actually stored in the login keyring?
[17:16] <almostevery> the bug is what we have now. devices and keyrings auto-decrypting across restarts and reconnects..I should think ubuntu users -and by all means devs- know way better than offering a facebookization of the OS.
[17:17] <almostevery> mdeslaur, in the present 'transparent' state of the keyrings, I fear I cant answer such a question publicly, sorry.
[17:17] <mdeslaur> almostevery: well, if they are, then that's your problem, you didn't uncheck the "automatically unlock this keyring when I log in" option when you unlocked them
[17:17] <mdeslaur> so they got atored
[17:17] <mdeslaur> stored
[17:18] <mdeslaur> almostevery: if you click on the "Login" keyring and you have an entry called "Unlock password for:keyringname" then that's why
[17:19] <mdeslaur> right click on that and delete it
[17:20] <almostevery> mdeslaur, you mean I delete the login keyring?
[17:20] <almostevery> mdeslaur, sorry, I got it
[17:20] <almostevery> yes, I see such entries
[17:21] <mdeslaur> ok, so delete those entries, and then lock and unlock your other keyrings
[17:21] <mdeslaur> when it asks for your password, UNCHECK the box marked "Automatically unlock this keyring whenever I'm logged in"
[17:25] <almostevery> mdeslaur, I deleted them. now I will uncheck the box, and hope the keyrings wont be kept open afterwards. in the login keyring, I see also password used in a client application. if I deleted it, would I have to reenter the password each time I open the client?
[17:29] <mdeslaur> almostevery: depends how the application stores the password. Either it stores it unconditionally, or it has a checkbox that asks you whether or not it should be stored
[17:33] <almostevery> mdeslaur, I will just try it, then. thank you for your help, it seems to have solved the auto-access problem. thanks for the links to bug reporting, too. I would anyway consider contacting them to know more.
[17:36] <almostevery> and to get clear about it
[17:38] <almostevery> mdeslaur, have a good weekend!
[18:33] <hjd> The package haskell-data-lens-template is in the FTBFS list for Utopic (due to unmet dependencies). However, I was able to build it on an up to date utopic system without any problems, atleast on i386. Could someone please trigger a rebuild of this package? :)
[19:30] <rbasak> hjd: apt-get can't install libghc-data-lens-dev for me on utopic-proposed on amd64. Are you sure you have utopic-proposed enabled in your build environment?
[19:44]  * hjd checks
[19:49] <hjd> rbasak: No, I don't have -proposed enabled.
[20:01] <hjd> ...and I get the same unmet dependencies error after enabling -proposed. Nevermind then :)
=== doko_ is now known as doko
[21:35] <cjwatson> rbasak: I recommend leaving it alone.  I'm on top of the Haskell transition, but there are a number of layers.
[21:35] <cjwatson> (hjd has left.)
[21:35] <cjwatson> It's always "fun" when people think they can parachute into the middle of that :-/
[21:35] <cjwatson> Well-meaning, but ...
[21:36]  * xnox irc disconnected again.....
[21:38]  * cjwatson uploads rebuilds of another layer of the above
[22:49] <rbasak> cjwatson: yeah, I assumed it wasn't as simple as that :)
[23:43] <Guest67794> Hello, I need help compiling a non-pae Kernel
[23:44] <Guest67794> I found out what to change in the .config flies, but the rules script keeps overwriting what I put in there
[23:59] <directhex> Guest12249, why do you need a non-pae kernel?