=== rww_ is now known as rww
[00:03] <xnox> trijntje: no.  and signed binaries are uploaded and available from the archive. see *-signed packages.
[00:04] <xnox> trijntje: so anyone can use them, furthermore they need to be distributed on the cd and to the users machines.
[00:33] <Netsnipe> utlemming: hey Ben
[00:33] <Netsnipe> are you in?
[00:35] <Netsnipe> is there anybody else in who's responsible for the EC2 AMI images for Ubuntu?
=== fginther|away is now known as fginther
[00:36] <Netsnipe> I'm looking for an ETA as to when the OpenSSL patched AMIs are going to be built.
[00:36] <sarnold> Netsnipe: what's up?
[00:37] <sarnold> ah, drat, no idea there. sorry. :)
[00:38] <Netsnipe> sarnold: any idea on who else I can speak to?
[00:41] <sarnold> zul, roaksoax_, rbasak_ ^^ are you guys the one to ask about ec2 ami images?
[02:02] <Netsnipe> is there anybody awake in here who's responsible for the EC2 AMI images for Ubuntu?
[02:03] <infinity> utlemming: ^
[02:04] <Netsnipe> infinity: I already pinged him.
=== sarnold_ is now known as sarnold
[02:17]  * hyperair wonders if the unity webapps extension has died again in chrome. =\
[02:34] <RAOF> cyphermox: Have you seen https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1296226 ? I've folded that into the network-manager branch as a part of piloting; it looks like that should get uploaded pre-Trusty, right?
[02:34] <ubottu> Launchpad bug 1296226 in network-manager (Ubuntu) "Patches rely on TARGET_DEBIAN to be defined" [Undecided,New]
[03:00] <RAOF> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
[03:13] <FourDollars> arges: Hi, could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 ?
[03:13] <ubottu> Launchpad bug 1303819 in bluez (Ubuntu) "Bluetooth menu's content disappeared after resume." [Undecided,New]
[03:14] <cyphermox> RAOF: yes, thanks. I'll take care of it in the morning (or if you want, feel free to upload)
[03:15] <FourDollars> cyphermox: Hi, could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 ?
[03:15] <ubottu> Launchpad bug 1303819 in bluez (Ubuntu) "Bluetooth menu's content disappeared after resume." [Undecided,New]
[03:16] <cyphermox> FourDollars: I'll be happy to, but in my morning
[03:16] <FourDollars> cyphermox: OK. Thanks a lot.
[03:16] <cyphermox> I'm just accidentally on; trying to follow the elections here and get some small tasks done unrelated to work :)
[03:17] <FourDollars> haha
[03:17] <cyphermox> FourDollars: ok, looked quickly
[03:18] <FourDollars> IRC should prompt some information about timezone. XD
[03:18] <cyphermox> seems to make sense if that -1 is a valid adapter ID to say that the adapter is not there :)
[03:18] <cyphermox> FourDollars: I'm in east coast north america
[03:19] <FourDollars> cyphermox: Take your time.
[03:19] <cyphermox> FourDollars: like I said, I'll check to upload only tomorrow; but it looks fine with a quick glance
[03:19] <cyphermox> thanks for looking into this
[03:20] <FourDollars> cyphermox: -1 is the initial value of this global variable.
[03:21] <cyphermox> awesome
[03:21] <FourDollars> cyphermox: So it is reasonable to set it back to -1 when there is no adapter available. (That is what I think.)
[03:21] <cyphermox> yes
[03:21] <FourDollars> And it does fix the problem. :)
[03:22] <FourDollars> cyphermox: Thanks again for your help. :)
[03:35] <RAOF> cyphermox: I've already got the stuff ready, so I'll upload. Thanks!
[03:43] <cyphermox> RAOF: hold on if it's not too late
[03:44] <cyphermox> there was a fix in the packaging branch, from pitti re: autopilot tests
[03:44] <RAOF> Yup; I folded that in.
[03:44] <RAOF> (Or, rather, I started with the packaging branch)
[03:44] <cyphermox> https://code.launchpad.net/~network-manager/network-manager/ubuntu
[03:44] <cyphermox> oh, cool
[04:47] <Mirv> I wonder if any core-dev would be available to call 'requestsync -d unstable pitivi' to sync pitivi for bug #1253009 ? the only thing I'm pondering about is whether it matters if the demoting to universe happens before or after the sync
[04:47] <ubottu> bug 1253009 in pitivi (Baltix) "[FFe] Please sync latest upstream release (0.9x) from Debian unstable - Pitivi developers recommends to use 0.92 or later" [Medium,Triaged] https://launchpad.net/bugs/1253009
[04:49] <Mirv> there's a branch too but intltool-update -p wouldn't be needed after pitivis is universe, so there are no changes left to keep in ubuntu
[04:56] <RAOF> Mirv: I don't _think_ it would be a problem if it were syncd before demotion; it'll just FTBFS until it is. That said, I'd prefer to be sure :)
[04:57] <infinity> RAOF: No, it should be demoted before it's attempted.
[04:57] <infinity> I'll sort this out.
[04:58] <infinity> (It'll only FTBFS if it's missing a build-dep, which the bug log doesn't make clear... And if it's built successfully and then demoted, it will have all the translations stripped)
[04:58] <infinity> So, first, we need to see why it's in main.
[04:58] <infinity> ubuntu.trusty/usb: * pitivi
[04:59] <infinity> I assume that.
[04:59] <infinity> It's been in main since lucid, I'm not sure just suddenly dropping support is the kindest thing to do.
[04:59] <RAOF> Huh. mterry found it only on the ubuntustudio dvd.
[05:00] <Mirv> thanks infinity for looking. mterry indeed also replied via e-mail that it should be safe to demote.
[05:01] <Mirv> I think the history was that it was either included or considered to be included by default at some point, but then dropped later.
[05:01] <infinity> Safe isn't the same as right.
[05:01] <infinity> Like I said, it's been in main since (at least) lucid.  If we wanted to be supporting it, we should be looking at its deps, not just dropping it on the floor.
[05:01] <infinity> But if we don't care about supporting it (or if, historically, we've not really supported it anyway), meh.
[05:02]  * infinity looks for evience of the latter.
[05:02] <infinity> So, there was one micro-release SRU in precise, and 0 SRUs or security updates in any other series'...
[05:02] <infinity> That points to "it wasn't really supported anyway, despite being in main".
[05:03] <ScottK> It's mostly used by Studio and IIRC they focus on LTS.
[05:03] <infinity> So, let's drop it from that seed and see what germinate has to say.
[05:03] <ScottK> So micro-release in precise doesn't surprise me.
[05:03] <infinity> ScottK: That was the Canonical desktop team (seb) that did that update.
[05:04] <ScottK> Oh.
[05:04] <infinity> ScottK: Though, maybe that was because it was in main and studio couldn't upload. :P
[05:04] <infinity> So, it might be best for them if it demotes anyway.
[05:04] <ScottK> Maybe.
[05:04]  * infinity follows the trail on that a bit more.
[05:06] <infinity> So, that was in response to bug #1001516
[05:06] <ubottu> bug 1001516 in pitivi (Ubuntu Precise) "Please SRU to PiTiVi 0.15.2" [High,Fix released] https://launchpad.net/bugs/1001516
[05:06] <infinity> Which claimed it was "completely broken" in precise.
[05:07] <infinity> There've been no other SRUs except for this one "it doesn't work at all for anyone" bug, so that leans to my "it wasn't really well supported to start with" argument.
[05:07] <Mirv> well, it was, and it again is. before the rewrite to gstreamer-editing-services it has struggled to be functional with GStreamer updates (even just 0.10 series updates)
[05:07] <infinity> So, I'm okay with demoting it.
[05:08] <infinity> I've committed the seed change, and will demote when c-m says it's okay, and then do the sync.
[05:08] <infinity> If anyone decides it really should be in main, there's still time to argue that case, and either neuter the package or MIR the deps.
[05:09] <Mirv> excellent, thanks infinity, users should rejoy this since they've a chance of doing some video editing
[05:09] <infinity> (An MIR for pitivi itself wouldn't seem necessary)
[05:09] <Mirv> neutering would not be possible fully, at least gstreamer-editing-services1.0 and gnonlin1.0 would be strict new dependencies from universe
[05:32] <infinity> Mirv: demoted and synced.
[05:35] <Mirv> \o/
[05:50] <pitti> Good morning
[05:54] <pitti> infinity, smoser: argh, wolfes are dpkg crashy again, rebooting
[05:55] <pitti> nevermind, seems someone already did last night
=== stub` is now known as stub
=== fabo_ is now known as fabo
[06:46] <dholbach> good morning
[06:46] <zyga> dholbach: good morning :)
[06:47] <dholbach> hi zyga
=== ikonia_ is now known as ikonia
[08:16] <cjwatson> hallyn_: when installing, there's only one user; what groups later-added users get put into is up to desktop components and such.  user-setup adds the first user to the sudo group if configured that way (there are expert installation paths where you can set a root password during installation instead)
[08:33] <zyga> hey, I need a DD to review a few RFS for debian (python modules and apps) that we need to urgently sync to 14.04, they were reviewed by our sponsor but he doesn't have time before evening today and we're in a rush. Is there anyone here that could help me?
[08:35] <zyga> mvo: hey, perhaps you could help?
[08:35] <mvo> zyga: can do in some minutes, do you have a link for me?
[08:36] <zyga> mvo: not really (we just used email before), those are in DPMT (plainbox, checkbox-ng) and PAPT (plainbox-provider-{resuorce-generic,checkbox})
[08:36] <zyga> mvo: all are in debian svn
[08:36] <zyga> mvo: and all got a round of review yesterday
[08:37] <zyga> *resource
[08:37] <mvo> zyga: aha, do you have links to the svn repo (e.g. on svn.debian.org)?
[08:37] <zyga> sure, let me dig those up for you
[08:38] <zyga> mvo: http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/ http://anonscm.debian.org/viewvc/python-modules/packages/checkbox-ng/ http://anonscm.debian.org/viewvc/python-apps/packages/plainbox-provider-resource-generic/ and http://anonscm.debian.org/viewvc/python-apps/packages/plainbox-provider-checkbox/
[08:57] <mvo> zyga: ok, I have a checkout of plainbox now, do you guys use svn-buildpackage? or just dpkg-buildpacakge? or something else?
[08:59] <zyga> mvo: we use svn-buildpackage
[08:59] <zyga> mvo: those are our first debian packages so we currently just follow the trend in DPMT and PAPT
[08:59] <zyga> mvo: all the tarballs are on pypi/launchpad
[08:59] <mvo> zyga: ok, so what are they using :) ?
[09:00] <zyga> mvo: svn-buildpackage
[09:01] <mvo> zyga: ok
=== vrruiz_ is now known as rvr
[09:38] <zyga> mvo_: do you have any updates on that? anything I can help with?
[09:38] <zyga> mvo_: I just saw, thanks!
[09:39] <mvo_> zyga: its building, do you mind if I commit a "debian/rules get-orig-source" target? this makes the tarball fetching/renaming automatic
[09:39] <zyga> mvo_: I don't mind, piotr typically doesn't want that but I'm sure he'll understand
[09:39] <mvo_> zyga: it also complaining that the post commit hook is not working
[09:39] <mvo_> zyga: what is he using/doing in order to get the orig tarball?
=== bluesabre1 is now known as bluesabre
=== Adri2000 is now known as Guest44106
=== bluesabre1 is now known as bluesabre
=== MacSlow is now known as MacSlow|lunch
=== pete-woods is now known as pete-woods-lunch
=== kitterma is now known as ScottK
[12:26] <smb> I know I am quite late for asking this: where would I need the smarts (and how would those have to look like) to make people who would have installed xen-hypervisor-(i386|amd64) installed in Precise, pick up xen-system-amd64? That is also both i386 and amd64 move to system-amd64 as there is no 32bit hypervisor anymore.
=== _salem is now known as salem_
[12:40] <xnox> smb: you want xen-hypervisor-4.1-amd64 & xen-hypervisor-4.1-i386 to migrate to xen-system-amd64, right?
[12:41] <xnox> smb: in that case you need to provide dummy/empty package named xen-hypervisor-4.1-amd64 and xen-hypervisor-4.1-i386, which have "Depends: xen-system-amd64"
[12:41] <smb> xnox, right. that would be a meta-package to ensure the whole system gets upgraded/installed.
[12:41] <xnox> smb: correct, and it's the only way to guarantee upgrade path, no-matter how the user choose to upgrade (dpkg, dselect, apt, aptitude, upgrade-manager, etc.)
[12:42] <smb> xnox, ok. thanks. then I add those to the current xen-4.4 source
[12:43] <xnox> smb: you probably want similar packages fro xen-system-i386, xen-hypervisor-4.4-amd64, xen-hypervisor-4.3-amd64, xen-hypervisor-4.2-i386, Package xen-hypervisor-4.2-amd64.... depending on which upgrade paths you are willing to support (or forgot to support =))) )
[12:45] <smb> xnox, Yeah, true. Especially since there likely is enough documentation out there telling people to use the hypervisor package as the base install selector. Which was true in the past.
=== vibhav is now known as Guest54498
=== pete-woods-lunch is now known as pete-woods
[13:09] <jibel> pitti, bug 1304403 is for you?
[13:09] <ubottu> bug 1304403 in ubuntu-release-upgrader (Ubuntu) "Precise to Trusty - all of main - fails: The package 'postgresql-server-dev-9.1' is marked for removal but it's in the removal blacklist" [Undecided,New] https://launchpad.net/bugs/1304403
[13:10] <pitti> hm, does that mean that some package conflicts with postgresql-9.1?
[13:11] <pitti> ah, found it in the apt log
[13:12] <brainwash> xnox: hey, did you already take a closer look at bug 1284910? sadly I'm not familiar with ubiquity and how it can be easily debugged/tested
[13:12] <ubottu> bug 1284910 in ubiquity (Ubuntu) "Xubuntu Beta 1 and Beta 2 installer has debian background wallpaper" [Critical,Confirmed] https://launchpad.net/bugs/1284910
[13:14] <brainwash> the last comment points to a commit which might be the cause for the wrong wallpaper
[13:15] <gioele> hello, I just run FWTS and it has found a series of failures. How should these be handled? Is there a place where they can be reported? Just in launchpad?
[13:16] <zyga> how long does it take from something to show up in debian sid to be syncable via requestsync?
[13:16] <jibel> pitti, actually the root cause seems to be the transition from libkadm5srv-mit8 to libkadm5srv-mit9
[13:17] <pitti> The following packages will be REMOVED:
[13:17] <pitti>   krb5-multidev libkrb5-dev libpq-dev postgresql-server-dev-9.1
[13:17] <pitti> jibel: that's what I get on dist-upgrade, so I indeed see that
[13:19] <jibel> pitti, the upgrade path is libkadm5srv-mit9 -> rb5-multidev -> libpq-dev -> postgresql-server-dev-9.1
[13:19] <jibel> but it refuses to upgrade -mit8 to -mit9
[13:27] <Laney> how do I do git reset --hard origin in bzr?
[13:29] <mvo> Laney: I assume bzr revert is not good enough as you want to go to the orgin base version?
[13:29] <Laney> mvo: indeed
[13:30] <Laney> I tried bzr revert -r :parent but that didn't do it
[13:31] <sergiusens> Laney: how about bzr uncommit -r revno && bzr revert ?
[13:31] <seb128> Laney, what is that git command doing?
[13:31] <seb128> Laney, can't you just uncommit&revert?
[13:32] <sergiusens> seb128: that's basically what it does
[13:33] <Laney> I want it to calculate it all for me
[13:33] <Laney> uncommit -r :parent makes bzr crash :D
[13:33] <mvo> Laney: yeah, I just tried the same trick with the same result :)
[13:34] <seb128> Laney, what are you trying to do?
[13:34] <seb128> why the -r?
[13:34] <seb128> just uncommit & revert?
[13:34] <Laney> I could have any number of commits
[13:35] <seb128> Laney, then uncommit -r <rev>?
[13:36] <mvo> Laney: have you tried asking in #bzr yet?
[13:36] <seb128> Laney, you can also pull --overwrite :p
[13:36] <cjwatson> "git reset --hard origin" is "I am completely giving up on everything I haven't pushed, please just reset my branch to origin and forget about the rest"
[13:36] <cjwatson> you could always rebranch
[13:36] <Laney> seb128: yeah I know I can do it manually
[13:36] <Laney> rebranch is "I'm giving up on this VCS now" :P
[13:37] <Laney> I'll ask in #bzr and give up
[13:37] <cjwatson> you should probably not start from the axiom that bzr is as flexible as git is with regard to moving branches around ...
[13:37] <seb128> I think pull --overwrite is smart enough to not do a full checkout
[13:38] <Laney> Actually that does look like it worked
=== dpm is now known as dpm-afk
[13:51] <Laney> seb128: seems like that is actually the right way
[13:51] <seb128> Laney, pull --overwrite?
[13:51] <Laney> yep
[13:51] <Laney>   If you want to replace your local changes and just want your branch to
[13:51] <Laney>   match the remote one, use pull --overwrite. This will work even if the two
[13:51] <seb128> cool ;-)
[13:51] <Laney>   branches have diverged.
[13:56] <Laney> tyhicks: thanks for the lightdm fixes, logout works for me now
[13:57] <seb128> Laney, tyhicks: \o/
[13:57] <mlankhorst> great :)
[13:57] <mvo> is there a equivalent for git-dch for bzr?
[13:58] <hallyn> cjwatson: yeah, talked to stgraber about it last night;  the problem is that if tasksel installs libvirt-bin during iso install, the postinst which adds all sudo group members to the libvirtd group doesn't find the initial user in sudo group  yet
[13:58] <seb128> mvo, not sure if there is a standard tool, but didrocks has one, the autolander generate changelogs from vcs commits at least
[13:59] <mvo> seb128: cool, maybe didrocks can give me a hint
[14:00] <seb128> mvo, he's off for exercice but I'm sure he's going to pong once he's back/done with backlog
[14:00] <mvo> thanks seb128
[14:00] <seb128> yw
[14:01] <tyhicks> Laney: good to hear! :)
[14:02] <cjwatson> hallyn: user-setup-apply does that after tasksel runs
[14:02] <cjwatson> hallyn: so things will need to tolerate that
[14:04] <hallyn> cjwatson: yes, i proposed a one-liner to user-setup in bug 1304008 ...
[14:04] <ubottu> bug 1304008 in libvirt (Ubuntu) "user not added to libvirtd group with iso trusty 'virtual machine host' installation method" [High,Triaged] https://launchpad.net/bugs/1304008
[14:05] <cjwatson> hallyn: why wouldn't we just add that to passwd/user-default-groups directly?
[14:05] <cjwatson> rather than getting the value from another place in the same package and then adding to it :)
[14:05] <hallyn> i thought that was only done with preseed.  is there a global default?
[14:05] <hallyn> (i didn't see it in user-setup)
[14:05] <cjwatson> debian/user-setup-udeb.templates
[14:05] <hallyn> sounds perfect :)
[14:06] <stgraber> oh, didn't think of that. I did think of passwd/user-default-groups but not about always setting libvirtd in there even in the non-libvirt case
[14:06] <hallyn> well the adduser line does || true so it's ok in non-libvirtd case,
[14:07] <cjwatson> hallyn: so yeah, I can do that now
[14:07] <hallyn> cjwatson: thanks!
[14:09] <seb128> can something stop/retry https://launchpad.net/~ci-train-ppa-service/+archive/landing-013/+build/5889261 ?
[14:09] <seb128> that seems to be hanging, I would like to get it retried without having to wait on the buildd job to timeout
[14:10] <Laney> has that happened before?
[14:10] <seb128> Laney, I don't know
[14:10] <seb128> Laney, other archs built fine
=== benrodrigue is now known as brod
[14:11] <seb128> we had transient tests issues for sure
[14:11] <seb128> but I don't know if that includes hangs or only fails
[14:12] <Laney> I'll try it
[14:12] <cjwatson> seb128: cancelled and I'll retry
[14:12] <Laney> ooh, who won?
[14:12] <cjwatson> I hit cancel before posting here ...
[14:12] <Laney> me too
[14:12] <cjwatson> anyway, it's running now
[14:13] <seb128> cjwatson, Laney: thanks
[14:23] <seb128> cjwatson, Laney: retry worked, thanks
[14:23] <Laney> cool
[14:31] <Riddell> pitti: could we add gpgsm back to gpgme to fix bug 1293704 ?
[14:31] <ubottu> bug 1293704 in gpgme1.0 (Ubuntu) "Kleopatra don't support s/mime" [High,Confirmed] https://launchpad.net/bugs/1293704
[14:32] <pitti> Riddell: sure, if you have a way to make that build and work with gpg 1 and 2, please go ahead
[14:32] <pitti> Riddell: I remember that I spent an hour or two on it and I didn't see how
=== Lutin is now known as Guest52020
[14:49] <pitti> stgraber: thanks for pointing out lxc-start -s!
[14:50] <stgraber> pitti: np, it's not the most advertised feature :)
[14:50] <pitti> stgraber: I greatly simplified adt-virt-lxc with that now
=== tkamppeter_ is now known as tkamppeter
[15:39] <pitti> jibel: so apparently bug 1304403 doesn't pop up in the automatic upgrade tests, right?
[15:39] <ubottu> bug 1304403 in ubuntu-release-upgrader (Ubuntu) "Precise to Trusty - all of main - fails: Broken transition from libkadm5srv-mit8 to libkadm5srv-mit9" [Undecided,New] https://launchpad.net/bugs/1304403
[15:40] <pitti> jibel: looking at this now (got distracted with some other stuff); at least if it's due to krb-dev it only affects server-dev, and this isn't important to keep after an upgrade
[15:40] <pitti> jibel: so perhaps we can just refine the regexp to not catch -dev, but I'll check if there's an easy way to nudge the upgrade
[15:41] <jibel> pitti, no, I found it while testing main_all manually. It is not automated due to the disk space it uses
[15:44] <pitti> jibel: at least upgrade-ubuntu-precise-trusty-server-tasks-amd64 covers the critical case of keeping -9.1 on upgrades
[15:49] <didrocks> mvo: hey! so I have something which isn't a separate binary unfortunately. It's quite linked to CI Train/cu2d as I ignore the commit message to generate the changelog if there is a manual change for that commit in the mainline in debian/control
[15:49] <didrocks> mvo: and on bzr upstream advice, the only way to achieve it with that constrain was to parse the output, so not very elegant…
[15:51] <mvo> didrocks: I have a solution for now https://code.launchpad.net/~mvo/bzr-builddeb/dch - need to find a bzr-buidlddeb upstream to figure out if this might go upstream
[15:53] <didrocks> mvo: oh nice, james_w can maybe review it ;)
[15:55] <mvo> didrocks: getting his feedback would be great, I'm sure there is tons to do
=== Guest52020 is now known as Lutin
[16:11] <Laney> slangasek: I guess https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive needn't call out the GPL/LGPL explicitly
[16:11] <jibel> mvo, I tried an upgrade with eglibc from your ppa (2.19-0ubuntu4) on amd64 and still have the prompt during upgrade from precise. and in text mode because libgtk-perl cannot be loaded.
[16:13] <slangasek> Laney: indeed not
[16:17] <cyphermox> pitti: could you please look into why your NM tests are still randomly failing? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-network-manager/
[16:17] <pitti> jibel: I have a simple and obvious fix, uploaded now; I tested it successfully in a chroot
[16:18] <cyphermox> pitti: in theory RAOF included your isolation-machine fix
[16:18] <pitti> cyphermox: they don't fail randomly, but very reliably; apparently 0.9.8.8-0ubuntu5 introduced some regression
[16:18] <pitti> cyphermox: yes, but that's only for the ppc64el and armhf tests (they are just skipped now)
[16:18] <pitti> I can have a look tomorrow, yes
[16:19] <jibel> pitti, nice, I'll wait before restarting the test then.
[16:19] <pitti> jibel: the release team still needs to review/ack it
[16:33] <cyphermox> pitti: the reason I say "fail randomly" is because those are issues in the tests, not in NM. With the exception of the PE stuff; these tests are things I verify and use routinely -- such as the killswitch connection restore, or suspend and resume
[16:56] <RFleming> Greets and salutations
[16:58] <RFleming> quick question re the heartbleed patch on OpenSSL
[16:58] <RFleming> over in #ubuntu lots of people are asking about the version number remaining the same
[16:58] <RFleming> 1.0.1 14 Mar 2012
[16:59] <RFleming> is the version number changing with the patch?
=== roadmr is now known as roadmr_afk
[17:02] <RFleming> ahh, openssl version -a to compare built on date.
[17:05] <tarpman> RFleming: also, ubuntu revision on the package version. e.g. in precise: ubuntu5.11->ubuntu5.12
[17:06] <cjwatson> Right, you should always look at the full package version.  It's often inappropriate to take entire new upstream releases.
[17:08] <RFleming> tarpman, the questions have been "I installed the patch, but it still shows 1.0.1 14 Mar 2012.  What gives?"
[17:08] <RFleming> but using the -a switch can show the patch has applied with the build date.
[17:09] <cjwatson> RFleming: Use "dpkg-query -W libssl1.0.0" instead.
[17:10] <RFleming> that doesn't really help
[17:10] <RFleming> :)
[17:10] <cjwatson> It sure does.
[17:10] <cjwatson> You can compare with https://launchpad.net/ubuntu/+source/openssl/+changelog
[17:10] <RFleming> I can yes... Joe user?
[17:11] <cjwatson> Or you can look at /usr/share/doc/libssl1.0.0/changelog.Debian.gz locally and see the fixed version there
[17:11] <cjwatson> I don't think expecting Joe User to remember a slew of independent version-discovery commands for lots of different packages (openssl is just today's problem) and correlate those against build dates is at all sensible
[17:12] <cjwatson> Oh, also, the package version numbers in which any given security vulnerability was fixed are listed in the USNs on security.ubuntu.com
[17:12] <cjwatson> http://www.ubuntu.com/usn/usn-2165-1/ in this case
[17:13] <cjwatson> So the instruction is "run 'dpkg-query -W libssl1.0.0' and make sure the version listed is at least that shown on http://www.ubuntu.com/usn/usn-2165-1/ for your release of Ubuntu"
[17:13] <RFleming> vs run openssl version -a and see if it was built yesterday?
[17:13] <cjwatson> That might help as a special case for today's problem, but you aren't giving people tools that will help them not need to ask the same question for the next vulnerability
[17:14] <RFleming> ahh, I see where you're going
[17:14] <cjwatson> And, for future things, build dates are often misleading for one reason or another
[17:15] <cjwatson> So if people rely on them it often leads to them wasting time on blind-alley questions
[17:15] <cjwatson> It's only not misleading in this case because we didn't get any advance notice of this CVE
[17:15] <RFleming> perhaps "run 'dpkg-query -W libssl1.0.0' and make sure the version listed is at least that shown on http://www.ubuntu.com/usn/usn-2165-1/ for your release of Ubuntu" should be made #ubuntu's MOTD
[17:22] <jpds> !sslbug | RFleming
[17:22] <ubottu> RFleming: A fix for the recent OpenSSL vulnerabilities (2014-0076 & 0160) has been pushed to the Ubuntu repositories, see http://www.ubuntu.com/usn/usn-2165-1/ and http://heartbleed.com/ for more information.
[17:27] <RFleming> that works :)
[17:38] <roaksoax> slangasek: do you have a few minutes to spare to approve maas from the unapproved queue? (It has important bugfixes that we would like to release)
=== bfiller is now known as bfiller_afk
=== WebbyIT is now known as rpadovani
=== Guest44106 is now known as Adri2000
=== roadmr_afk is now known as roadmr
[18:11] <slangasek> roaksoax: accepted
[18:13] <roaksoax> slangasek: thanks a lot!
=== bfiller_afk is now known as bfiller
[18:56] <mvo> jibel: thanks, same text as the previous one? then I will have a look tomorrow morning
[19:09] <arges> xnox: hi. looking at an trusty installer issue with a mellanox card. does the module need to be in /etc/network/devnames-static.gz in order for that card to be properly detected?
[19:10] <arges> xnox: when we get to the 'configure the network' dialog, other NICs show up, but not this mlx4 one.
[19:12] <arges> xnox: just realized its pretty late where you are, i'll send an email
[19:14] <xnox> arges: hey =) maybe try stgraber  =)
[19:15] <xnox> arges: i have no clue what you are on about =)))))
[19:15] <arges> xnox: hey! ok will do.. yea its installer questions
[19:16] <stgraber> arges: no idea
[19:16] <xnox> arges: well, networking configuration parts of it, which i don't deal with at all. Never heard of /etc/network/devnames-static.gz either. sounds weird to have gzip compressed files under /etc/network.
[19:16] <xnox> arges: if you need kernel modules, they should be packaged / included in the udebs
[19:16] <cjwatson> I'd expect it to just need to be set up so that the kernel/udev can automatically load the module for it
[19:16] <arges> yea, we're trying to figure out if this is a hw-detect issue or exists somewhere else
[19:17] <cjwatson> anything that requires manual hw-detect action is very much deprecated
[19:17] <cjwatson> please don't introduce more of it unless you have fully investigated the better alternatives and know why they won't work for you :)
[19:17] <xnox> arges: if you can't modprobe it / no kernel module to load, then well that's the first thing to do.
[19:17] <arges> xnox: the module is in nic-modules
[19:17] <arges> xnox: i can modprobe it just fine
[19:17] <arges> cjwatson: so the installer is using udev at that point?
[19:17] <cjwatson> yes
[19:18] <cjwatson> devnames-static is an escape hatch for ancient crufty stuff
[19:18] <arges> cjwatson: ok good to know.
[19:18] <cjwatson> it hasn't been touched at all in over five years
[19:19] <arges> cjwatson: xnox stgraber : thanks guys so looks like we need to setup udev properly to fix this
[19:20] <stgraber> arges: is that a Mellanox ethernet card or are you trying to get d-i to install using IP over IB?
[19:22] <arges> stgraber: this is a mlx4 IB card. just trying to detect it at this point
[19:22] <stgraber> arges: ok, because once you get past loading the ip over ib module and get netcfg to detect it, I can tell you things will fail pretty horribly
[19:23] <stgraber> dhclient fails over infiniband unless you generate a valid hardware identifier, put it in a conffile and pass that to dhclient
[19:23] <arges> stgraber: sounds like the next level of issues to deal with : )
[19:24] <rtg> stgraber, does it work with a static IP address ?
[19:25] <stgraber> rtg: it should, yes
[19:25] <stgraber> it's really just dhcp that's a bit weird and anything lower than IP (obviously)
[20:34] <jdstrand> slangasek: fyi, bug #1304657
[20:34] <ubottu> bug 1304657 in apt (Ubuntu) "world writable files in /var/lib/apt/lists" [Undecided,New] https://launchpad.net/bugs/1304657
[20:35] <slangasek> jdstrand: oh my
[20:36] <slangasek> jdstrand: follow-up q on bug
[20:38] <jdstrand> slangasek: hmmm, I did this in a vm. my desktop system doesn't have those rw files
[20:38] <jdstrand> I'm not sure how to do what you asked
[20:38] <saiarcot895> This probably isn't the right channel, but do GPG private keys need to be regenerated due to Heartbleed?
[20:38] <slangasek> jdstrand: 'apt-cdrom -d /mount/point add'?
[20:39] <jdstrand> saiarcot895: no
[20:39] <slangasek> saiarcot895: no
[20:39] <saiarcot895> Thanks jdstrand and slangasek
[20:40] <jdstrand> slangasek: give me a minute. I need to update a different vm and see what happens
=== salem_ is now known as _salem
[21:29] <jdstrand> slangasek: ok, responded. seems apt-cdrom is likely to blame
[21:30] <slangasek> jdstrand: huh - surprising, but thanks for checking
=== tinoco is now known as tinoco-away
=== bfiller is now known as bfiller_afk
=== hholtmann_ is now known as hholtmann
[22:11] <jdstrand> slangasek: curious if there is any word on bug #1298539?
[22:11] <ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
[22:13] <jdstrand> in related yet I think actually unrelated news, dhclient is starting unconfined even though the network-interface-security job ran (ie /run/network-interface-security exists)
[22:14] <jdstrand> in a new vm install, but not my laptop
[22:15] <jdstrand> which looking at the job, boggles me
[22:26] <slangasek> jdstrand: no word yet, sorry
[22:28] <slangasek> xnox: ^^ do you have another half a day somewhere between now and release to look at 1298539 on top of all your other bugs?  Or should I try to dig up some more time myself?
[22:29] <xnox> jdstrand: why apparmor is not an upstart job? (that question was on the back of my mind since forever)
[22:29] <jdstrand> ok, the dhclient issue is separate. seems there is a bug in qemu that prevents encrypted lvm from working in a vm unless you use 'nomodeset' (I was booting into singleuser then doing 'resume', which apparently unloaded the profiles)
[22:33] <sarnold> xnox: here's the historical reasoning https://lists.ubuntu.com/archives/upstart-devel/2011-December/001771.html
[22:33] <sarnold> xnox: improving apparmor's load is on our todo list for next cycle
[22:34] <jdstrand> xnox: let's just say its complicated
[22:35] <jdstrand> xnox: but there is the historical reference sarnold mentioned. we plan to do profile compiles in kernel postinst which then means we can do a simple apparmor upstart job super early in the boot process that won't affect boot times
[22:36] <jdstrand> (we can then employ the same technique during touch image generation and improve first boot startup times there too)
[22:37] <slangasek> jdstrand: hmmm, but now I'm wondering why lightdm starts before runlevel 2
[22:37] <jdstrand> but that isn't for 14.04. we wanted it, but alas, it didn't happen
[22:37] <slangasek> oh, it doesn't
[22:38] <slangasek> 'start on filesystem and runlevel [!06] [...]'
[22:39] <jdstrand> (to be fair, we only dreamt up how to do it in less than two months ago :)
[22:39] <jdstrand> and it is partially implemented. anyhoo, I digress
[22:39] <slangasek> jdstrand: ok, so on second glance, I don't understand how the start conditions we have here actually cause the behavior you're describing (of user processes being started up before the apparmor policy is applied)
[22:40] <jdstrand> slangasek: well, I don't either-- if you recall, it was you and infinity who discussed it and came up with that
[22:40] <slangasek> jdstrand: because the sysvinit script is run from /etc/init/rc-sysinit.conf, before we emit the 'runlevel' event later in the same job script; lightdm doesn't start until after we switch runlevels
[22:40] <jdstrand> slangasek: why are you talking about lightdm?
[22:41] <slangasek> jdstrand: because the user processes are all children of the login session?
[22:41] <jdstrand> cause of evince, firefox, etc?
[22:41] <slangasek> jdstrand: yeah
[22:41] <slangasek> you said you saw this problem in the wild on desktop installs?
[22:41] <jdstrand> well, I added that before the irc discussion
[22:41] <jdstrand> jj sees it on his desktop. infinity sees it on server
[22:41] <jdstrand> (many servers)
[22:42] <xnox> slangasek: jdstrand: on todays cloud images, servers and desktops i totally have tty2 & logged in and start executing things ahead of reaching runlevel 2. We have enough things upstartified, such that we should be fully up without sysv init scripts invoked yet, thus imho we should have apparmor job as upstart possibly just before runlevel 2 event.
[22:42] <slangasek> what infinity is seeing is "network starts after the getty"
[22:42] <slangasek> which is different
[22:42] <xnox> heck ubiquity installer is start on starting lightdm and that has full-blown desktop with network manager =)
[22:42] <slangasek> xnox: apparmor does run just before the runlevel 2 event, the problem is that the runlevel event is late due to slow network configuring
[22:43] <slangasek> jdstrand: so the problem that infinity had is not related to apparmor confinement, and won't be fixed by moving rcS earlier in the sequence
[22:43] <slangasek> that is, it'll prevent 'apparmor' from being one of the things spit out at the console, but he was getting console spew from both rcS and rc2
[22:43] <xnox> slangasek: hm? is this startpar bridge magic that init.d scripts are ahead of upstart jobs =))))) i see start on remote_fs
[22:44] <xnox> right.
[22:44] <slangasek> xnox: the apparmor script is in rcS, all of rcS is processed before runlevel is emitted (see above)
[22:45] <slangasek> net result, while we could do with not holding up rcS waiting for the network, making such a change doesn't fix whatever bug jdstrand is seeing
[22:46] <jdstrand> hrm
[22:47] <jdstrand> slangasek: I thought that initscripts ended up being executing in parallel to jobs?
[22:50] <xnox> and i also see my tty1 login prompt rutinely hidden by "spew", where as tty2 comes up quick. let me cranck up verbosity and see when tty1 comes up vs runlevel 2 has finished.
[22:50] <jjohansen> slangasek: I haven't dug into it, but I have repeatedly seen policy loaded after I have logged in, and say started firefox. So that the firefox is unconfined. It is not just an issue of the logging showing up late
[22:50] <jjohansen> now I haven't checked to see if this is happening for a while now, and it may be fixed
[22:51] <jdstrand> well, console spew is one thing, but it isn't security relevant
[22:51] <jjohansen> jdstrand: right, just saying it isn't just console spew
[22:51] <jdstrand> jjohansen: I can't reproduce myself. I thought I had something when I filed the bug, but don't see to have it now. I guess file a bug when you see it?
[22:52] <jdstrand> jjohansen: yeah, I hear you
[22:52] <xnox> jdstrand: the premise is that tty1.conf job is "start on stopped rc RUNLEVEL=2" and that we assert that by that time, all rc2.d is complete and thus all security profiles loaded and all "spew" is complete.
[22:52] <jdstrand> xnox: so, apparmor isn't in rc2
[22:53] <jdstrand> id is in rcS.d
[22:54] <jdstrand> it will be nice when we just have the upstart job...
[22:55] <xnox> jdstrand: given it's already in rcS it should make much differences to put it into an upstart job. But let me experiment here locally to see the ordering we are currently getting.
[22:56] <jdstrand> xnox: thomi
[22:56] <jdstrand> meh
[22:56] <jdstrand> thomi: nm
[22:56] <jdstrand> xnox: thanks
[22:56] <jdstrand> I have to step away for bit
[22:57] <jjohansen> jdstrand: I still think its weird that we don't do the upstart job and just block boot for a few seconds if policy needs to be compiled
[22:58] <xnox> jjohansen: jdstrand: yeah, ureadahed also delays initial boots - for the sake of speeds upon second boot.
[22:58] <jjohansen> yep
[23:15] <Netsnipe> hi everyone
[23:15] <Netsnipe> utlemming: are you there?
[23:31] <slangasek> jdstrand: init scripts in *rc2* execute in parallel to jobs that are 'start on runlevel'.  But apparmor is rcS, so not in parallel
[23:31] <slangasek> jjohansen: so I accept there may be a bug with firefox winding up unconfined, I just don't see any way that it could follow from what we're talking about in bug #1298539
[23:31] <ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
[23:53] <xnox> jdstrand: jjohansen: http://paste.ubuntu.com/7224096/ takes negligible amount of time if the caches are valid, and when stale seems faster that execing piles of shell. Ideally i'd not source /lib/apparmor/functions at all - and just rely on filebridge to generate an instance per profile to load.
[23:57] <sarnold> xnox: the end goal is to omre or less just call apparmor_parser /etc/apparmor.d/  and have it Do The Right Thing without goofing around in shell. the parser itself is almost entirely there now..