=== Ursinha-afk is now known as Ursinha
[00:17] <xnox> mterry: device password to e.g. change sim card on an android phone != pattern to unlock the home screen. Ditto PIN, PUK numbers, and google account password.
[00:18] <sarnold> PUK?
[00:18] <xnox> and i do understand why mpt would hate multiple passwords, but we also do not expect users to use sudo.
[00:19] <xnox> sarnold: PUK unlocks PIN if it's locked out after 3 unsuccesful tries.
[00:19] <sarnold> xnox: ah :) thanks
[00:19] <xnox> sarnold: typically PUK is 10-12 characters.
[00:19] <xnox> sarnold: and one typically needs PIN2 to change PIN1, and PUK2 to change PUK1. Not sure how PIN2 can be changed, or PUK2.
[00:20] <sarnold> *snort*
[00:20] <xnox> sarnold: most current operators though disable PIN1 and/or set it to 0000.
[00:21] <mterry> sarnold, well if mdeslaur and you have opinions on whether the lock screen can/should be distinct from the sudo password, let me know
[00:22] <xnox> mterry: well, it is separate on our current desktops. One can auto-login, but that doesn't e.g. unlock keyring, nor requires one to type your password. I think that's what slangasek means here.
[00:23] <mterry> xnox, right but the next time you lock your screen, you do have to enter your password
[00:23] <xnox> mterry: it's only one password, it is sufficient to unlock lock screen, but it's not required to unlock the screen.
[00:23] <mterry> xnox, Desktop allows a one-time boot unlock without a password.  We could certainly do that on phone, but not useful
[00:24] <xnox> mterry: depending on how lock screen is setup. I have udev rules to token unlock my lock-screen without a password.
[00:24] <xnox> (though less common)
[00:24] <mterry> xnox, that's neat  :)
[00:25] <xnox> mterry: only on my desktop at home though =) not on my laptop.
[00:25] <mterry> xnox, we can do all sorts of things.  I've just been told by security that the unlock password should go through PAM.  And I've been told by design that we should only have one password
[00:25] <mterry> I'm happy to change either one
[00:26] <xnox> mterry: taking those two constraints, we can devise pam rules for lock screen to have a toggle wether pam should be letting one through based on physical access to screen alone, or password prompt as well.
[00:27] <mterry> xnox, well I meant that design wanted swipe-to-unlock == no password
[00:27] <xnox> mterry: all of it should go to pam - such that pam decides if "swipe from mir" is enough to unlock or not, for a given account.
[00:29] <xnox> mterry: design wanted swipe-to-unlock == "users sees it's homescreen / last app" =)))) i'm sure they don't care whether behind the scenes greeter send swipe/login attempt to pam and pam based on local presense authenticated user transparentely without requiring to type in password.
[00:29] <mterry> xnox, mpt said "the ability to use sudo is nowhere near
[00:29] <mterry> justification for asking every swipe-to-unlock user to choose a password that most of them will never use."
[00:30] <xnox> cause i should be able to ssh in, change to require password, and then swipe to unlock returns does login attempt and pam denies that, quering password, and lock screen on swipe presents me with a password prompt.
[00:30] <xnox> if password is empty, let through.
[00:31] <xnox> pam is a series of commands: so we will just need to configure it right -> if no password, let through.
[00:31] <xnox> if password, and local user/display access, let through.
[00:31] <xnox> otherwise password authentication is required/mandatory.
[00:32] <xnox> but it will allow people to e.g. configure NFC yubikey tokens to do e.g. 2fa screen unlock if they so require. password + nfc tap on the back.
[00:32] <xnox> or just one or the other...
[00:32] <xnox> similar how on iphone one can do touchid or password. Or on android face-unlock or password.
[00:33] <xnox> greeter shouldn't care less, just do authentication atempt to pam, and handle queries & errors from pam if there are any. And off-load security to sarnold & mdslaur =)
[00:33] <mterry> xnox, sure.  I'd have to look into how to branch on local swipe
[00:33] <sarnold> hehe I just hope we ccan have some nice GUIs in front it, I don't like doing /etc/pam.d/ by hand, surely most of our users won't like it either :)
[00:33] <mterry> xnox, using PAM is certainly the current plan
[00:34] <xnox> sarnold: have you not seen systemd-logindpam yet?
[00:34] <sarnold> xnox: I can't tell if that's a joke or not at this point..
[00:34] <xnox> sarnold: and the nice kdbus APIs with QML UI in ubuntu-system-settings for it?
[00:34] <xnox> sarnold: it's 1:34AM here ;-)
[00:34] <xnox> good night all! =)
[00:34] <sarnold> xnox: good night :)
[00:35] <mterry> xnox, u-s-s has UI for PAM?
[00:35] <mterry> I've seen the UI, but not the underpinnings that talk to PAM
[00:35] <mterry> xnox, goodnight
[00:35] <sarnold> mterry: I think he's getting giddy :)
[00:52] <mterry> sarnold, another thing -- I assume if we're using PAM for the phone passwords, we want to disable the 'obscure' option to pam_unix, in order to disable the password-strength checks it employs?  PIN and I imagine most user's passphrases would probably not pass muster
[01:12] <sarnold> mterry: hah, yes, that's probably true
=== _salem is now known as salem_
[01:25] <mdeslaur> slangasek, xnox, mterry, sarnold: if there are requirements to have more than one user password, such as a PIN to unlock the current session, but a password to login to decrypt the home directory, etc, we should have a meeting and talk about it
[01:25] <mdeslaur> I'm not sure what the exact requirements are
[01:26] <mdeslaur> but having different passwords depending on the service appears quite odd to me
[01:27] <sarnold> I can definitely see a short pin for unlocking the interface but a good password for e.g. ssh or sudo or ecryptfs..
[01:27] <mdeslaur> sarnold: so you boot, get a screen that asks for your password...at that screen, you enter your long password, but then if you press power and power back on, you need to enter a pin?
[01:28] <mdeslaur> how is that not completely incomprehensible to users?
[01:28] <sarnold> mdeslaur: heh I do that with my laptop now -- two passwords, one for each hard drive, then a login password that also unlocks the session
[01:29] <mdeslaur> sarnold: I don't think you're our target market :)
[01:29] <sarnold> mdeslaur: I can see your point but I also see slangasek's point that it'd be nice to only allow sudo after seomthing better than just a four or six digit pin..
[01:29] <sarnold> mdeslaur: that's what worries me :) lol
[01:29] <sarnold> mdeslaur: but that's the best part about PAM, us oddballs can configure what we want.
[01:29] <mdeslaur> sarnold: so you're ok with having 100% of your personal data be available with a 4 digit pin, but then have sudo, which gains an attacker NOTHING else require a stronger password?
[01:31] <sarnold> mdeslaur: yes; the sudo access would let someone e.g. capture keystrokes used for unlocking passwords in a password storage app or the password for my bank. they'd be hard pressed to pull that stunt with just a login pin.
[01:31] <mdeslaur> sarnold: nonsense, they can do that just fine with your user account access
[01:31] <mdeslaur> it's all running under your user session
[01:31] <slangasek> mdeslaur: right, my point is that anyone who wants to use sudo on the device is not a target "market" at all, so we shouldn't constrain the design of our root access interface by what works in the market :)
[01:32] <slangasek> I wouldn't expect a PIN-based unlock screen to use the user password at all
[01:32] <slangasek> i.e., that's an alternate authentication mechanism, not a password
[01:32] <mdeslaur> slangasek: so in your use case of power users, can't they figure out by themselves how to do 'sudo passwd" like they currently do on the desktop?
[01:33] <slangasek> mdeslaur: how are they supposed to do that?  Are you suggesting that 'sudo' should work passwordless by default?
[01:33] <mdeslaur> no, sudo only works once you've set a PIN or a password
[01:33] <mdeslaur> for your lock screen
[01:33] <slangasek> ok
[01:34] <slangasek> and if I type 'sudo passwd' and change the password, what happens?
[01:34] <slangasek> I change root's password?
[01:34] <slangasek> but sudo access is still available with just a weak PIN?
[01:34] <mdeslaur> same as on desktop, you've now set a password for the root account, at which point you can remove your sudo access
[01:35] <sarnold> heh, and watch juju blow up in a million little pieces..
[01:35] <mdeslaur> slangasek: so...if the PIN is only for the lock screen, what is used to unlock the keyring password?
[01:36] <mdeslaur> what about ecryptfs?
[01:37] <mdeslaur> yes, a 4 character PIN is crummy...but the whole point is that if the screen is locked, you can't use sudo in the first place
[01:37] <slangasek> mdeslaur: ah; I didn't follow that to its logical progression, I didn't understand that "sudo passwd" was followed by "and remove yourself from sudoers" since I never do that :-)
[01:37] <mdeslaur> well, I don't either, but then again I don't want to use two different passwords :)
[01:37] <slangasek> I don't either
[01:37] <slangasek> I want to use a password vs. a PIN ;)
[01:37] <mdeslaur> so PIN is just for the lock screen?
[01:38] <slangasek> PIN is for phoney things
[01:38] <slangasek> sudo is not a phoney thing :)
[01:38] <mdeslaur> you always use the strong password at first boot, and then only PIN for the second time your phone locks?
[01:39] <mdeslaur> or do you _only_ want the user to set a strong password for sudo, but all the rest uses the PIN?
[01:39] <slangasek> you ask good questions
[01:39] <mdeslaur> like, I can use pkexec with only the PIN, but sudo requires a strong password
[01:40] <slangasek> what I do know is that as a power user I would be very surprised to find that setting a PIN on my phone means that this PIN can be used to grant *additional* (i.e., root) access
[01:40] <slangasek> vs. having the phone unlocked
[01:41] <mdeslaur> hrm, perhaps...but the PIN grants access to 100% of your personal data
[01:41] <sarnold> but 0% of the user data of the other users on the system..
[01:41] <mdeslaur> even if we disabled sudo by default, or set a new password for it...there's pkexec, and a whole bunch of other ways with policykit to gain root access
[01:42] <sarnold> well. okay, more than 0%, but still..
[01:42] <mdeslaur> sarnold: not if you're not an administrative user
[01:43] <mdeslaur> I do see the point, but short of asking the users for two passwords, I'm not sure how to solve this
[01:44] <slangasek> mdeslaur: is there any reason to enable sudo use without asking the user for the second password? possibly in a more obscure part of the UI?
[01:44] <mdeslaur> we can easily disable sudo, but all the policykit stuff still either requires a strong password, or will default to the 4 digit PIN
[01:45] <mdeslaur> if we really want to do this, we need to remove the user from the admin group by default
[01:46] <slangasek> hmm
[01:46] <slangasek> not sure of the knock-on effects there
[01:46] <slangasek> anyway
[01:46] <mdeslaur> well, there's possibly quite a bit
[01:46] <slangasek> sorry for upsetting the cart :)
[01:46] <slangasek> but now I'm going to run off to dinner
[01:47] <mdeslaur> that's fine, we can talk about this again tomorrow
[01:47] <mdeslaur> others are apparently upset that users can access application data too
[01:47] <mdeslaur> which is part of the same problem
=== gusnan_ is now known as gusnan
=== salem_ is now known as _salem
[04:39] <robert_ancell> I'm trying to do a SRU for accountsservice in trusty and I'm getting: "Rejected:
[04:39] <robert_ancell> Unable to find accountsservice_0.6.35.orig.tar.gz in upload or distribution.
[04:39] <robert_ancell> Files specified in DSC are broken or missing, skipping package unpack verification"
[04:40] <robert_ancell> that should be in trusty right? The current trusty version 0.6.35-0ubuntu7
[04:40] <robert_ancell> I'm very hesitant to upload the .orig again if LP is confused...
[04:41] <tarpman> robert_ancell: looks like a .orig.tar.xz was uploaded originally
[04:41] <tarpman> https://launchpad.net/ubuntu/trusty/+source/accountsservice/0.6.35-0ubuntu7
[04:41] <robert_ancell> yeah, that's what I though
[04:41] <robert_ancell> t
[05:52] <pitti> good morning
[05:52] <pitti> meh, freenode is broken through my proxy, lost over-night scrollback
[07:21] <dholbach> good morning
[07:53] <sil2100> pitti: hello!
[07:54] <pitti> hey sil2100, how are you?
[07:54] <sil2100> pitti: fine, thank you - how about you?
[07:54] <pitti> sil2100: quite fine, thanks! having fun with click tests
[07:54] <sil2100> :)
[07:55] <bzoltan> ping pitti
[07:55] <sil2100> pitti: I wanted to poke you for some advice, as one of our upstreams seems to have problems with autopkgtests failing, where the tests seem to be fine when ran locally on the device
[07:55] <sil2100> pitti: bzoltan exactly ^
[07:55] <sil2100> ;)
[07:56] <sil2100> pitti: a new release of the UITK seems to have caused ubuntu-system-settings-online-accounts to fail, but bzoltan has problems reproducing it - so maybe there are some specifics to how autopkgtests are being ran?
[07:57] <pitti> sil2100: ah, that race again; I already retried it like 5 times, doesn't seem to be so easy to evade now :/
[07:57] <sil2100> pitti: is that some known race condition..?
[07:57] <pitti> sil2100: it's running exactly like in http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test (except for trusty -> utopic, of course)
[07:57] <bzoltan> pitti: have you rebooted the test device before running that test?
[07:58] <pitti> bzoltan: no, the dist-upgrade didn't seem to affect anything boot relevant, so it didn't reboot after dist-upgrade
[07:59] <pitti> bzoltan: did you run with -proposed enabled? there are a bunch of new packages in -proposed which may have broken it?
[07:59] <bzoltan> pitti:  I run the tests after a clean proposed image flash
[08:00] <pitti> bzoltan: oh, this is not a test on the phone, but an autopkgtest of the debian package in QEMU
[08:00] <pitti> timings there are slightly differetn
[08:00] <pitti> it doesn't find header = self.window.select_single('Header', visible=True)
[08:01] <bzoltan> pitti: and I run it on the device with phablet-test-run online_accounts_ui
[08:01] <pitti> is that at a point where the header is guaranteed to exist? it may need a wait_select_single()?
[08:01] <bzoltan> pitti: Maybe, I am not familiar with all the AP tests of each app.
[08:02] <bzoltan> pitti:  but in a different environment a race condition can mess up things for sure
[08:03]  * pitti runs it locally
[08:06] <pitti> passed here, but again my machine is pretty fast; yay timing issues
[08:08] <pitti> bzoltan: ah, haha!
[08:08] <pitti>     def test_title(self):
[08:08] <pitti>         # On the phone, this fails because of https://bugs.launchpad.net/bugs/1252294
[08:08] <pitti>         if model() != 'Desktop':
[08:08] <ubottu> Ubuntu bug 1252294 in unity-mir "Application window appears in the background" [High,Confirmed]
[08:08] <pitti>             return
[08:08] <pitti> bzoltan: but with QEMU this would actually be "Desktop"
[08:09] <bzoltan> pitti:  ARGHHHH :D :D
[08:09] <sil2100> Oh ;)
[08:09] <pitti> so that means that after self.window.visible is true, the Header isn't immediately visible
[08:09]  * sil2100 knew that pitti would identify the problem
[08:09] <pitti> but that != "Desktop" might just hide the race condition when running on the phone
[08:10] <pitti> there's a bunch of those in those tsets, including in setUp()
[08:11] <pitti> bzoltan: btw, it's better to @unittest.skipUnless() those instead of returning, to make it more obvious in logs
[08:11] <pitti> (or skipIf())
[08:12] <pitti> so in summary, ISTM that wait_select_single() is correct there, to avoid the assumption that opening the app makes the header bar appear instantaneously
[08:12] <xnox> pitti: so last night steve and I chatted about startpar & inits. It seems we can be merging new sysvinit/startpar as you wanted, but steve still wants to review that merge (i didn't find it on the spot, but i thought you may have had it prepared somewhere). Reasons to fix startpar for real, are regressed bootspeed under upstart at the moment due to each no-op init.d script that we introduce.
[08:13] <pitti> xnox: ah, thanks; I still have my old merge, but after all the changes since then it basically needs re-doing
[08:13] <pitti> (but should also be simpler)
[08:32] <bzoltan> pitti: sorry I lost my net
[08:36] <pitti> bzoltan: recent backscroll: http://paste.ubuntu.com/7764422/
[08:38] <bzoltan> pitti: thanks ... so what should I do now?
[08:39] <pitti> bzoltan: as I said, I think the right solution is to use wait_select_single(); I have no idea about whether the tests should be re-enabled on the phone
[08:56] <bzoltan> pitti: So it seems that there is an MR https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437 to address this problem. Is there a way to unblock the UITK landing?
[08:56] <pitti> bzoltan: yes, the release team can ignore particular failures
[08:57] <pitti> (#ubuntu-release)
[09:02] <bzoltan> pitti: thanks, I just did.
=== vrruiz_ is now known as rvr
[10:57] <cjwatson> pitti: I tried to run http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test on utopic to test stuff for bzoltan, and got http://paste.ubuntu.com/7764968/ while installing build-deps (and a bunch of follow-up failures); am I doing something wrong or is that an autopkgtest bug?
[10:58] <pitti> cjwatson: uh, that was fixed many weeks ago -- this might be trusty's autopkgtest?
[10:58] <pitti> cjwatson: it was a missing LSB header in the VM setup script for autopkgtest, yes; this only appeared when moving to insserv
[11:01] <cjwatson> My host is trusty
[11:01] <cjwatson> Don't see why the guest should be though ...
[11:02] <cjwatson> It thinks it's utopic for everything else
[11:02] <pitti> cjwatson: so you need at least the current version of http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=tools/adt-buildvm-ubuntu-cloud;hb=HEAD
[11:02] <pitti> cjwatson: if you want to build utopic guest VMs
[11:03] <cjwatson> pitti: Ah.  Is there something I can do to my current VM to fix it, so I don't have to download all this again?
[11:04] <pitti> cjwatson: yes, you can boot it in kvm (kvm -m 2000 -drive file=adt-utopic.img,if=virtio)
[11:04] <pitti> cjwatson: then add the LSB header like in above script
[11:04] <pitti> phone, brb
[11:05] <cjwatson> OK, brilliant, thanks
[11:06] <pitti> cjwatson: http://paste.ubuntu.com/7765010/
=== doko__ is now known as doko
[11:14] <cjwatson> pitti: yep, got it, thanks
[11:52] <mvo_> stgraber, pitti: is lxc in utopic ready for systemd? I get errors from lxc-start that lxcbr0 is not ready, which indicate that lxc-net is not running (and indeed I just see a upstart.conf file in the package no sysvinit or systemd afaict) - known issue?
[11:53] <mvo_> pitti: aha, I see bug #1312532
[11:53] <ubottu> bug 1312532 in lxc (Ubuntu) "[systemd] Factorize lxcbr0 setup and use it for all init systems" [Low,Confirmed] https://launchpad.net/bugs/1312532
[12:05] <xnox> mvo_: the terms are upstart job, init script, and systemd unit =))))))) ( i cringe over upstart.conf, cause in fact upstart does inotify watch for /etc/upstart.conf which must be empty or non-existant =)))) )
[12:06] <mvo_> xnox: *cough* sorry, I will remember that
[12:07] <xnox> mvo_: meh, pointless details =) don't worry about it.
[12:07] <mvo_> xnox: and I know that in theory, in practice I was too annoyed to pay attention ;)
[12:07] <xnox> mvo_: yeap. We don't have systemd support for lxc, cloud-init and openstack at the moment.
[12:07] <xnox> ( or well, last time I have checked)
[12:08] <mvo_> xnox: ok, not a big deal, it looks like its pretty simple for lxc to add though, is someone on it already or should I give it a shoot?
[12:08] <xnox> mvo_: unless stgraber has, i don't think anyone looked into it. Debian has some integration, but it's different from ours.
[12:09] <pitti> mvo_: right
[12:09] <pitti> mvo_: I also ran into something else, hang on
[12:09] <xnox> mvo_: and no idea if we can do unpriviledged lxc under systemd, the way we can under upstart.
[12:09] <mvo_> pitti: the apparmor issue?
[12:09] <pitti> mvo_: bug 1325468
[12:09] <ubottu> bug 1325468 in lxc (Ubuntu) "[systemd] container startup fails with AppArmor" [High,Triaged] https://launchpad.net/bugs/1325468
[12:09] <pitti> mvo_: there's a proposed fix in there
[12:10] <mvo_> nice, I haven't seen that
=== _salem is now known as salem_
=== greyback is now known as greyback|away
[13:21] <stgraber> mvo_: lxc itself works fine with systemd but the systemd unit doesn't do the same thing that our upstart job does
[13:21] <stgraber> mvo_: which means, no network configuration
[13:21] <pitti> or rather, it doesn't have systemd units at all :)
[13:22] <stgraber> mvo_: all the init scripts (sysvinit, upstart, systemd) are upstream and I think it'd make a lot of sense to have all of them do the same thing. It's something I'm aware of but hasn't been a priority so far.
[13:22] <stgraber> pitti: oh, right, that's because we haven't turned on the systemd unit for Ubuntu in the upstream branch (configure.ac has a mapping of what needs to be built for what distro)
[13:23] <stgraber> pitti: though there's not much point turning that on until we get the same experience with sysvinit, upstart and systemd, so might as well do both at once
[13:23] <pitti> and I suppose that one bit in the  apparmor policy needs to be fixed
[13:23] <pitti> stgraber: well, we don't care much about sysvinit, but the Debian packages certainly do
[13:24] <pitti> although they are completely different (and honestly, quite a mess)
[13:24] <stgraber> pitti: right, I'm talking as LXC usptream here. I'm tired of Debian users never managing to get the network right, so I'd much rather we split all those setup bits into a separate tool and have all the various init scripts call that for a nice consistent behaviour.
[13:25] <pitti> stgraber: exactly, that's pretty much what I proposed in that bug, I just call "~/lxc-net start" whenever I need it :)
[13:25] <stgraber> pitti: what's the apparmor issue again? (sorry, not good at remembering bug reports :))
[13:25] <pitti> stgraber: bug 1325468
[13:25] <ubottu> bug 1325468 in lxc (Ubuntu) "[systemd] container startup fails with AppArmor" [High,Triaged] https://launchpad.net/bugs/1325468
[13:26] <pitti> it needs an additional "mount options in (rw, slave) -> /,"
[13:27] <stgraber> pitti: hmm, so systemd doesn't support read-only / ?
=== Adri2000_ is now known as Adri2000
[13:27] <stgraber> pitti: the risk with adding that rule is that if /var/lib/lxc is read-only on purpose, starting the container will remount it read-write both in and outside the container
[13:28] <stgraber> (we had a similar problem with the shutdown scripts remounting / read-only on shutdown which would remount the whole partition read-only on the host. We had to block that with apparmor)
[13:30] <pitti> stgraber: hm, shouldn't "slave" only apply to one direction, not both?
[13:32] <stgraber> pitti: I think that's right for slave, but your suggest line also allows "mount -o remount,rw /"
[13:33] <stgraber> or maybe not
[13:33] <pitti> stgraber: ah, because of the "in"
[13:33] <pitti> yeah, maybe there's a way to say "AND" there
[13:34] <stgraber> "mount options=(rw, slave) -> /,"
=== greyback|away is now known as greyback
[14:27] <sil2100> hm, where does the pending-sru document take the list of bugs from that require verification for a given SRU?
[14:31] <stgraber> sil2100: the .changes (or its parsed version)
[14:33] <sil2100> hm, strange then... ah, or maybe indeed
[15:04] <pitti> jdstrand: ah, many thanks for your hint how to speed up aa-clickhook!
[15:04] <jdstrand> yeah, I hadn't thought of that before :) I am updating the man page so others can benefit
[15:12] <sil2100> stgraber: anyway, thanks!
=== salem_ is now known as _salem
[15:30] <kdeuser56> suppose I have kernel version. Where do I find ubuntus config file for that kernel version?
[15:30] <kdeuser56> (when the kernel is not installed)
[15:34] <rbasak> kdeuser56: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=tree;f=debian.master/config;hb=HEAD
[15:35] <rbasak> (that's for Trusty obv.)
[15:35] <rbasak> And the git tags there map the version numbers
[15:37] <kdeuser56> rbasak: I have a script that handles the kernel version over a variable ... now I want a wget command that fetches the configuration of that kernel for me ... any more generic idea (otherwise I would have to guess versions etc.)
[15:38] <kdeuser56> rbasak: is there a central archive that has all .config for all kernels?
[15:38] <rbasak> kdeuser56: download the deb into /tmp, extract it manually there and look for the config?
[15:38] <rbasak> kdeuser56: the central archive *is* the git repo, AIUI.
[15:38] <rbasak> kdeuser56: all the information you need is in the git repository as far as I understand. You just need to extract it.
[15:39] <rbasak> kdeuser56: you don't need to guess versions. They're all in the git repo as tags.
[15:39] <rbasak> kdeuser56: if you want to know what version of a package is in a particular release, you can either use the rmadison tool or parse Packages.gz with grep-dctrl or something directly.
[15:39] <rbasak> kdeuser56: also try #ubuntu-kernel to speak to real Ubuntu kernel folks who might know more.
[15:40] <kdeuser56> rbasak: could you give me an example command to fetch the a version for extraction?
[15:40] <kdeuser56> rbasak: (I do not have the necessary experience with git :-()
[15:45] <kdeuser56> rbasak: I could simply use wget for http://kernel.ubuntu.com/~kernel-ppa/mainline/ ... the annoying thing is the ubuntu release name appended at the end ...
[15:45] <jdstrand> cjwatson: hey, can you think of any reason why adding override files to /var/lib/apparmor/clicks would trip up click (I would take care of the click-apparmor hook). eg, /var/lib/apparmor/clicks/foo.json.override alongside /var/lib/apparmor/clicks/foo.json
[15:46] <jdstrand> I could just create another directory
[15:47] <cjwatson> jdstrand: should be fine as long as it doesn't match your Pattern
[15:47] <jdstrand> cool, thanks
[15:48] <kdeuser56> rbasak: ok thanks anyway for your help
[15:58] <pitti> slangasek, infinity, kees: TB meeting in 2 mins
[15:59] <pitti> mdeslaur: ^
[15:59]  * slangasek nods
[15:59] <mdeslaur> ack
[15:59] <mdeslaur> pitti: what's the channel name again?
[16:00] <mdeslaur> pitti: nm, found it
[16:00] <pitti> #ubuntu-meeting-2
=== gaughen_ is now known as gaughen
=== _salem is now known as salem_
[16:30] <bdmurray> pitti: Do you know why the libmad0 dbgsym packages are so out of date? http://ddebs.ubuntu.com/pool/main/libm/libmad/
=== roadmr is now known as roadmr_afk
[17:09] <dholbach> seb128, it's installable now :)
[17:09] <seb128> dholbach, yeah, it migrated to release, well done!
[17:09] <dholbach> seb128, well, it was just last 5 metres I had to walk :)
[17:10] <seb128> dholbach, ;-)
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== xnox is now known as xnox_
[21:29] <ari-tczew> cjwatson: M-o-M is broken
[21:31]  * ari-tczew has no read backlog, maybe it's already confirmed
[21:32] <cjwatson> ari-tczew: fixed the latest problem.  at some point this will show up at a time when I have enough time to make it more robust rather than fixing the symptoms ...
[21:34] <ari-tczew> cjwatson: I guess how it's annoying. thanks for your engagement!
[21:35] <xnox_> GOOOOOOAL!
[21:35] <xnox_> OMG! =)
=== xnox_ is now known as Eisbrecher
=== Eisbrecher is now known as Eisbrecher_xnox
[21:36] <juliank> Yeah, Eisbrecher_xnox
[21:36] <juliank> I can't write in every channel at the same time
[22:38] <smoser> bdmurray, could you look at https://code.launchpad.net/~smoser/ubuntu-reports/cloud-tools-next/+merge/226047
=== _salem is now known as salem_
[22:51] <bdmurray> smoser: merged
[23:08] <smoser> thanks, bdmurray
=== tkamppeter_ is now known as tkamppeter