=== tmpRAOF is now known as RAOF
[05:05] <pitti> Good morning
[05:06] <pitti> infinity: sudo> erk, sorry; debugging leftover, I'll reupload
[05:06] <pitti> sarnold: ^
[05:19] <pitti> sarnold, infinity: reuploaded and tested again
[05:19] <pitti> with dropped sudo and /bin/echo -> printf
[05:19] <pitti> thanks for spotting!
[05:30] <rlaager> Now that Ubuntu has moved to systemd, is it the plan to update packages to use systemd timers instead of cron jobs?
[05:32] <pitti> rlaager: all in due time; we still want/need to support upstart until at least 16.04 LTS, and the phone hasn't been switched yet
[05:34] <rlaager> pitti: I ask because if that's the eventual plan, I will update my packages at $WORK sooner (i.e. for the next LTS) rather than later, and it will also affect my suggestions and patches to Ubuntu packages, both in and out of the official repositories.
[05:35] <pitti> rlaager: it hasn't been officially discussed, but once we stop supporting upstart I see no reason to not use timers
[05:44]  * Unit193 sighs.
[05:55] <ari-tczew> when vivid+1 is going to be open?
[06:00] <pitti> ari-tczew: whenever we get a name
[06:02] <Unit193> And someone has been slacking on the naming of it. ;)
[06:04] <pitti> yeah, this is a non-delegatable task, I'm afraid
[06:24] <pitti> wgrant, cjwatson: gcc-4.9 built in the PPA, but again failed to upload: do you know what https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test/+build/7362665 means?
[06:33] <wgrant> pitti: Huh, that reminds me of a bug I fixed in it in 2009.
[06:34] <wgrant> pitti: I suspect one of the binaries may have been missing a version in its Source field.
[06:34] <wgrant> pitti: It's looking for an epoched source version.
[06:34] <pitti> wgrant: some binaries indeed have an epoch (that was what the whole bug was about)
[06:34] <pitti> but the source shouldn't need one?
[06:35] <wgrant> pitti: But the binaries need to specify their source package.
[06:35] <wgrant> If the name is different, they have a Source: foo field
[06:35] <pitti> wgrant: what does "missing a version in its Source field" mean?
[06:35] <wgrant> If the version is also different, they have a Source: foo (1.2.3)
[06:35] <pitti> missing Source: field, or missing Version:?
[06:35] <pitti> ooh!
[06:35] <wgrant> eg. apt-cache show lib32gcc1
[06:35] <pitti> I didn't know that
[06:35] <wgrant> Source: gccgo-5 (5.1~rc1-0ubuntu1)
[06:36] <pitti> I don't test for that, might be in the mangler
[06:36] <pitti>  Package: fixincludes
[06:36] <pitti>  Source: gcc-4.9 (4.9.2-10ubuntu13)
[06:36] <pitti>  Version: 1:4.9.2-10ubuntu13
[06:36] <pitti> so that looks ok, right?
[06:36] <pitti>  Package: fixincludes-dbgsym
[06:36] <wgrant> hat is correct.
[06:36] <pitti>  Source: gcc-4.9
[06:36] <pitti>  Version: 1:4.9.2-10ubuntu13
[06:36] <pitti> but that would be wrong then
[06:37] <wgrant> Indeed.
[06:37] <pitti> wgrant: ack, thanks!
[06:37]  * pitti goes to fix that
[06:37] <wgrant> I don't remember what exactly my old fix was.
[06:37] <wgrant> Ohh, unless it was adding the Source field in the first place.
[06:37] <wgrant> launchpadlibrarian.net/35716468/pkg-create-dbgsym_0.31_0.32.diff.gz
[06:48] <dholbach> good morning
[08:33] <jasabella> hi!
[08:52] <wgrant> pitti: I think it's reasonable to not fix lucid.
[08:52] <wgrant> It's worth looking at any major differences precise and trusty, though.
[08:52] <pitti> wgrant: I backported the fixes to precise
[08:52] <pitti> there are a lot more which could be backported, but let's not do everything at once
[08:53] <wgrant> Right, just wondering ifthere's anything else interesting for failedtoupload reasons.
[08:54] <pitti> there were some fixes to improve the debug links etc., but none that refer to uploading except perhaps cjwatson's Architectures: fix (which I included)
[08:54] <wgrant> Right.
[08:56] <pitti> wgrant: so I'll let gcc-4.9 finish building for vivid; if that succeeds, I'll upload gcc for precise, trusty, and utopic
[08:56] <wgrant> Yep, sounds good to me.
[08:56] <wgrant> gcc is good at breaking the world.
[08:56] <pitti> and I'll copy binutils and some other package for precise once p-c-d publishes for precise
[08:56] <wgrant> If it works, everything that uses debhelper probably does.
[08:57] <wgrant> p-c-d ftbfs on precise
[08:57] <pitti> binutils is interesting as it calls pkg_create_dbgsym by hand, no debhelper
[08:57] <wgrant> Yep
[08:57] <pitti> wgrant: no, fixed in pitti2 (publishing)
[08:57] <wgrant> The kernel is also interesting, though it worked fine when we tested it last week.
[08:57] <wgrant> Ahh
[08:57] <wgrant> Oh, the kernel may not actually use p-c-d
[08:57] <pitti> but that doesn't ... yes
[08:57] <wgrant> Since it produces -dbgsym .debs and then renames them to ddeb...
[08:57] <pitti> it builds .ddebs, but entirely by itself
[08:58] <wgrant> It does use p-c-d, but not to build the main packages.
[08:58] <wgrant> It has some weird autocreated ddebs which are crazy, but they upload at least.
[08:58] <pitti> binutils copied
[08:59]  * pitti wonders what to use instead of systemd for precise and trusty -- some complex multi-binary thing which produces ddebs and has epochs
[08:59] <pitti> well, gcc should do for that
[09:00] <pitti> oh, binutils -- that needs fixing to actually add the ddebs to the .changes
[09:00]  * pitti uploads that
[09:05] <caribou> I'm working on fixing a bug both in Ubuntu & Debian so I updated the existing bug on Debian but not getting any response from the maintainer. Should I get someone else in Debian to upload the fix or just add a delta to Ubuntu until the debian maintainer wakes up ?
[09:06] <melodie> hello
[09:06] <melodie> caribou which package?
[09:07] <caribou> melodie: python-pywbem
[09:07] <melodie> who is mentioned as maintainers/packages in the .desc file?
[09:07] <caribou> melodie: bug #1434991
[09:07] <ubottu> bug 1434991 in pywbem (Ubuntu Vivid) "python attributeError 'SSLTimeoutError' after upgrade" [Medium,In progress] https://launchpad.net/bugs/1434991
[09:07] <caribou> melodie: lemme check
[09:08] <caribou> melodie: Maintainer: Benjamin Kaduk <kaduk@mit.edu>
[09:08] <caribou> Uploaders: Russ Allbery <rra@debian.org>, Sam Hartman <hartmans@debian.org>
[09:08] <caribou> maybe I should email each one directly instead of relying on the bug update
[09:09] <melodie> wait a sec
[09:09] <melodie> what about https://bugs.launchpad.net/ubuntu/+source/pywbem/+bug/1434991/comments/6 ?
[09:09] <ubottu> Launchpad bug 1434991 in pywbem (Ubuntu Vivid) "python attributeError 'SSLTimeoutError' after upgrade" [Medium,In progress]
[09:10] <caribou> melodie: it's been two weeks now & didn't hear anything from the bug
[09:10] <melodie> caribou when you report a bug in Debian bugs (at debian-mentors I think? you might want to check) you can add the maintainers and packages in copy
[09:10] <caribou> melodie: the bug already existed, I just updated it
[09:11] <melodie> caribou it's not all that fast, if you don't get a response after 3 months you can poke them again
[09:11] <melodie> caribou did you see the last comment in your bug report?
[09:11] <caribou> melodie: I won't wait 3 months to fix the bug in Ubuntu
[09:11] <melodie> caribou what will you do?
[09:12] <melodie> maybe could you add a ppa?
[09:12] <caribou> melodie: add an Ubuntu delta to the package
[09:12] <melodie> ok
[09:12] <melodie> I also seek help for a little thing
[09:12] <caribou> melodie: ppa is not an anwser to existing bugs in our archives
[09:13] <melodie> caribou ok!
[09:13] <melodie> very good
[09:13] <caribou> melodie: thanks for your answers btw,
[09:13] <melodie> my thing is about redshift, I'd like to ask confirmation about this: is "vidmode" enabled, or is it not enabled, as I suspect? http://pastebin.com/index/VXsafnbU
[09:14] <melodie> caribou welcome!
[09:15] <melodie> caribou btw, what is your package name in the Debian repos?
[09:15] <melodie> pywbm isn't found
[09:15] <caribou> melodie: python-pywbem
[09:16] <caribou> melodie: pywbem is the source pkg
[09:17] <melodie> caribou have you tried the updated version from Debian?
[09:17] <melodie> or the one from vivid?
[09:18] <melodie> (same thing as updated from Debian)
[09:18] <caribou> melodie: the bug is in all versions up to debian/SID
[09:18] <melodie> 0.8.0 then?
[09:19] <zyga> pitti: hey, do you remember bug https://bugs.launchpad.net/intltool/+bug/377872
[09:19] <ubottu> Launchpad bug 377872 in intltool "having a way to specify a source format in the potfiles list would be nice" [High,Triaged]
[09:20] <caribou> melodie: sid has 0.8.0~dev650-1
[09:22] <melodie> caribou is your bug here too? https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-pywbem;dist=unstable
[09:22] <caribou> melodie: yes, it's also referenced in the LP btg
[09:22] <caribou> s/btg/bug
[09:23] <melodie> what is "btg" ?
[09:23] <melodie> ih
[09:23] <melodie> oh
[09:23] <melodie> bug ok
[09:24] <melodie> caribou you say it is there, but I only see #780264 ?
[09:24] <melodie> unless they thought it wasn't an "outstanding bug" ?
[09:24] <caribou> melodie: yep, that's the one. don't bother; I sent and email to the maintainer & uploders. I'll see what they say
[09:24] <pitti> zyga: I didn't see this before, but it's comprehensible enough
[09:25] <melodie> caribou ok. can you confirm for my question? as "vidmode" not enabled? Is looking for the compiled libs with ldd the right way to go?
[09:26] <zyga> pitti: you commented on the gnome counterside IIRC
[09:26] <melodie> I am hunting the bugs in redshift and redshift-gtk, to get it to work as it should.
[09:26] <caribou> melodie: I don't know about "vidmode", but if you want the list of shared libraries, ldd will do it, hes
[09:26] <caribou> s/hes/yes
[09:26] <zyga> pitti: I wanted to ask if you know of a workaround for this, so a project that's not C-based that still uses po/POTFILES.in and intltools
[09:27] <caribou> melodie: good thing, I'm being hit by this one too
=== vrruiz_ is now known as rvr
[09:27] <melodie> I just posted 2 bug reports
[09:27] <melodie> with solutions
[09:27] <caribou> melodie: bug # ?
[09:27] <melodie> https://bugs.launchpad.net/ubuntu/+source/redshift/+bug/1188961/comments/8
[09:27] <ubottu> Launchpad bug 1188961 in redshift (Ubuntu) "gtk-redshift don't work at startup" [Medium,Triaged]
[09:28] <pitti> zyga: I think in a project of mine I craeted a temporary .py symlink to the executable python script, then call intltool, then remove the symlink again
[09:28] <melodie> I am not yet satisfied because it works way better in Archlinux, and I will compile from sources to see if adding all options help
[09:29] <zyga> pitti: thanks, I'll try that
[09:29] <melodie> caribou if you are interested you can follow the link from that one bug report, and there, I added the links to the sources of my research
[09:30] <melodie> else, there is a very recent update available at the redshift project site: https://github.com/jonls/redshift/releases
[09:32] <caribou> melodie: reading...
[09:32] <melodie> caribou sure... I'm going to install the dev tools now (my install is fresh) so I can compile from git
[10:08] <melodie> caribou I compiled and installed successfully with a max of options (looking into configure.ac too) and the compile from git works, but I still don't know why there is no UI for the configuration side.
[10:09] <melodie> caribou I will need to track down what is different with the redshift I have in Archlinux
[10:24] <wgrant> pitti: Nice, gcc-4.9 built.
[10:24] <wgrant> That's a *lot* of binaries.
[10:24] <pitti> at last!
[10:24] <pitti> wgrant: ok, then I'll throw in the precise/trusty/utopic gccs :)
[10:25] <pitti> wgrant: systemd/trusty also does that, there's a libgudev dbgsym and libgudev is epoch'ed
[10:25] <wgrant> Aha
[10:28] <pitti> wgrant: there, more buildd fodder :)
[10:29] <pitti> wgrant: but I'm fairly certain that this will work now, at least for trusty/utopic (as that's pretty much exactly the same); hopefully also for precise
[10:30] <cjwatson> Worth also remembering that we'll need to copy this into -security.
[10:30] <cjwatson> I think?
[10:30] <wgrant> up
[10:30] <pitti> yes, I think so
[10:30] <cjwatson> Unless the security PPAs build against -updates.
[10:34] <pitti> for the initial hump/tests, having it in -proposed should be enough, as all builds except -security only use that (so copying to -updates isn't very urgent)
[10:34] <wgrant> -security needs it very soon.
[10:34] <wgrant> Or their builds will fail or do the wrong thing once we turn on the flag.
[10:34] <pitti> so assuming the gcc builds work in all releases, I'll upload them to the -proposed queues
[10:34] <wgrant> Yep
[10:34] <pitti> do you think we need more tests before accepting them?
[10:34] <wgrant> I think if the known weird packages work then everything else should be tractable.
[10:34] <pitti> yes, I agree
[10:34] <wgrant> I'd like to do a main rebuild, but scalingstack lcy01 remains unhappy.
[10:34] <wgrant> I guess we could do a non-virt amd64 rebuild, since the buildds aren't doing anything else anyway...
[10:34] <melodie> caribou this is the tool I was seeking for, isn't available in the repositories: http://www.webupd8.org/2010/07/redshiftgui-protects-your-eyes-when.html
[10:40] <melodie> caribou the project page, if you are interested, http://maoserr.github.io/projects/redshiftgui/
[10:48] <mpt> cyphermox, Wellark_: What’s the difference between “Wi-Fi security: LEAP” and “Wi-Fi security: WPA Enterprise” + “Authentication: LEAP”?
[11:35] <mdeslaur> dholbach: FYI, moving my patch piloting to tomorrow as I have an emergency at the moment
=== MacSlow is now known as MacSlow|lunch
[11:59] <dholbach> mdeslaur, sure sure
=== MacSlow|lunch is now known as MacSlow
=== tnkhanh_ is now known as tnkhanh
=== gammax90 is now known as gammax
[13:44] <cyphermox> mpt: it's two very different types of security for wifi networks. One is using straight LEAP for the passphrase (generating dynamic WEP keys), the other is the more typical authentication over 802.1x
=== _salem is now known as salem_
[14:00] <zbenjamin> jdstrand: ping, do you have some time to talk about the framework validation issue bzoltan pinged you about a few days ago?
[14:02] <mpt> cyphermox, thanks. I’m collapsing the 802.1x authentication options into the main security menu, so I think I’ll call the former “LEAP” and the latter “WPA Enterprise LEAP”
[14:03] <jtaylor> doko_: how high are the changes clang in vivid gets a sru if I provide an upstream patch?
[14:03] <cyphermox> mpt: there may be some others that are confusing/ambiguous, or need to be added in the future
[14:03] <cyphermox> mpt: also, different WPA enterprise methods require different fields
[14:08] <mpt> cyphermox, but your “generating dynamic WEP keys” then makes me wonder why “LEAP” and “Dynamic WEP” are distinct options :-]
[14:09] <pitti> wgrant, cjwatson: all builds done in the PPA, spot-checking ddebs LGTM; I uploaded the stuff to the -proposed review queues
[14:10] <pitti> doko_: ^ FYI
[14:10] <cyphermox> mpt: there is more than one way to generate dynamic wep keys
[14:12] <cyphermox> mpt: one design that looks solid is what Android does. I bet the iPhone is also pretty much handling things the same way. I'm guess that is what you're aiming for?
[14:13] <mpt> (╯°□°）╯︵ ʎǝʞ dǝʍ
[14:14] <cjwatson> pitti: Excellent, thanks
[14:14] <mpt> cyphermox, <https://wiki.ubuntu.com/Networking#wi-fi-authentication-variations>
[14:23] <arges> infinity: whats the status on Vivid sru's? should I be holding off on reviewing tomorrow until w is open for business?
[14:25] <mardy> Laney: hi! Was there something you were expecting me to do for bug 1432613? If so, please let me know -- it was not my intention to drop the ball :-)
[14:25] <ubottu> bug 1432613 in Online Accounts: Account plugins "Facebook and MSN shutting down" [High,In progress] https://launchpad.net/bugs/1432613
[14:25] <Laney> mardy: yes, we need to upload this to all Ubuntu releases
[14:26] <Laney> probably not the dropping packages/conflicts part there though - just let them be empty & update the descriptions
[14:27] <melodie> please, does someone know where software-properties-gtk write the changes done? Especially the kinds of updates it is configured to provide? (never - LTS only - each new version) ?
[14:27] <mardy> Laney: by "upload" do you literally mean upload (if so, I'm afraid I can't help, I don't have the rights) or creating MPs for the citrain?
[14:27] <mardy> Laney: maybe I can prepare the branches, and you do the upload?
[14:27] <Laney> mardy: The train can do the upload, we just need to get it in one way or another
[14:28] <mardy> Laney: OK, I'll prepare the MPs then
[14:28] <cyphermox> mpt: yeah, it's not ideal :/
[14:28] <wgrant> melodie: That's /etc/update-manager/release-upgrades
[14:29] <melodie> wgrant thank you!
[15:09] <mardy> Laney: while I'm a it, I think it'd be good to backport also the fix for bug 1430694. OK?
[15:09] <ubottu> bug 1430694 in Online Accounts: Account plugins "Update Facebook permissions to 2.0 API" [High,In progress] https://launchpad.net/bugs/1430694
[15:09] <Laney> mardy: sure
[15:09] <Laney> just add the SRU information to the bugs
[15:09] <mardy> Laney: OK
[15:09] <Laney> description / test case / regression potential
[15:09] <Laney> thanks!
[15:19] <mardy> Laney: done: can you nominate bug 1430694 for Utopic and Trusty (Vivid is already OK)?
[15:19] <ubottu> bug 1430694 in Online Accounts: Account plugins "Update Facebook permissions to 2.0 API" [High,In progress] https://launchpad.net/bugs/1430694
[15:19] <Laney> k
[15:20] <Laney> mardy: done
[15:43] <mardy> Laney: do you remember what was the trick to get pagination working in bzr? I must have broken something, and now I've always to type "bzr log | less" explicitly...
=== doko_ is now known as doko
[15:43] <Laney> mardy: I am using https://launchpad.net/bzr-pager
[15:46] <mardy> Laney: thanks!
[15:47] <mardy> Laney: about the backports, should I backport the packaging fixes to vivid, at least? or not backport them at all?
[15:52] <Laney> mardy: without them, the packages will just be empty, right?
[15:52] <Laney> s/packages/package/
[15:53] <mardy> Laney: not really; the account-plugin-facebook will contain the other (working) services; and this is correct
[15:54] <Laney> I mean the wlm one
[15:54] <mardy> Laney: the live plugin will contain the live plugin, to create the account; but then, you won't have any use for this account
[15:55] <Laney> can we just not ship this plugin?
[15:55] <Laney> I think it'd be safer for SRU to not change the packages around
[15:55] <mardy> Laney: I agree that for Utopic and Trusty we can leave it like this, but I guess we could fix it for vivid
[15:55] <Laney> vivid is stable now too
[15:57] <mardy> Laney: we can make it empty, indeed, but I'm wondering if someone could develop an app which could use the live plugin (maybe for IMAP?)
[15:57] <mardy> Laney: then they'd want to depend on account-plugin-live, but not being able to use it, if it's empty
[15:58] <mardy> Laney: so, IMHO it's better either to force the removal of the package, or to keep it, though fairly useless
[15:58] <Laney> we could drop the recommends
[15:58] <Laney> but keep the package
[15:58] <mardy> Laney: +1
[15:59]  * Laney nods
[15:59] <pitti> fginther: hey! would you mind actually attaching the log in bug 1449632?
[15:59] <ubottu> bug 1449632 in fatrace (Ubuntu) "fatrace autopkgtests assume access to certain CPU registers" [Undecided,New] https://launchpad.net/bugs/1449632
[15:59] <pitti> fginther: which -cpu option are you using there, so that I can reproduce this?
[15:59] <fginther> pitti, oops. sorry about that
[16:00] <infinity> arges: vivid SRUs don't block on W in any way.  Review away.
[16:01] <fginther> pitti, there is no --cpu option for creating nova instances, but there may be a way to determine what the openstack cloud is configured to use. I'll try to get back to you on that
[16:01] <arges> infinity: ack
[16:01] <fginther> pitti, log file is attached.
[16:02] <fginther> pitti, I have to run, but will be back later if you leave any questions
[16:02] <mdeslaur> pitti, kees, infinity, stgraber, slangasek: tech board meeting?
[16:02] <pitti> x86      SandyBridge  Intel Xeon E312xx (Sandy Bridge)
[16:02] <pitti> fginther: nevermind, that ^ I guess
[16:06] <mardy> Laney: which target branch should I use for the MPs for empathy? I don't find any "14.04" or "trusty" branches, should I create them?
[16:06] <slangasek> mdeslaur: hmm; unfortunately sprinting this week, don't think I can attend, sorry
[16:06] <Laney> mardy: Make a new one if we haven't SRUed that release before
[16:06] <pitti> fginther: nevermind, can reproduce
[16:06] <Laney> edit Vcs-Bzr in debian/control to point to it... I usually just append the release name e.g. ubuntutrusty
[16:07] <mardy> Laney: this means that it hasn't, right? http://packages.ubuntu.com/search?suite=trusty&section=all&arch=any&keywords=empathy&searchon=sourcenames
[16:08] <Laney> mardy: https://launchpad.net/ubuntu/+source/empathy <- actually we did for trusty but looks like no vcs
[16:08]  * Laney makes one
[16:11] <Laney> mardy: okay, lp:~ubuntu-desktop/empathy/ubuntutrusty exists now
[16:12] <mardy> Laney: thanks; and as a matter of fact, I wouldn't have had the permissions to push to that branch
[16:12] <mardy> Laney: can you please do the same for utopic and vivid?
[16:13] <Laney> I will once there is something to push there
[16:13] <Laney> i.e. your branch
[16:13] <Laney> you can bzr branch -r tag:<the ubuntu version> to get the right revision to start from
[16:14] <mardy> yep, ok
[16:14] <sarnold> pitti: thanks for the ecryptfs fixes; I know a lot of users have hit that..
[16:15] <pitti> sarnold: yeah; I tried to be defensive, that's why it's a relatively large shell script
[16:16] <sarnold> :)
[16:26] <mdeslaur> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Break Time | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
[16:31] <mardy> Laney: do I understand correctly, that given "version-0ubuntuX" as stable release, the update should be "version-0ubuntuX.1" in debian/changelog?
[16:32] <Laney> mardy: If that version is only in one release, otherwise use (e.g.) .14.04.1
[16:32] <Laney> see: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[16:45] <mardy> Laney: ok, here are the branches: lp:~mardy/empathy/lp1432613-vivid and lp:~mardy/empathy/lp1432613-utopic
[16:45] <mardy> Laney: if you create the stable branches, I'll create the MPs
[16:45] <mardy> Laney: hopefully I picked the right base revision :-)
[16:52] <Laney> mardy: looks good, no need for MP - I'll just push them
[16:59] <mardy> Laney: ok, cool; for trusty, and for all versions of account-plugins, I created MPs and subscribed you
[16:59] <Laney> Looking
[17:00] <Laney> I'll have to go in a minute, perhaps someone else can help you upload them
[17:07] <Laney> mardy: or I can dput tomorrow (bypassing the train)
=== dholbach_ is now known as dholbach
[18:18]  * cyphermox -> late lunch
=== bduncan_ is now known as bduncan
[19:08] <bobbyz> Hi guys.  I'm working on creating some upstart scripts and I've been referring to http://upstart.ubuntu.com/cookbook/.  I'm trying to use the 'start on starting <service>' and 'stop on stopping <service>' directives to establish dependencies and it's working in all cases except one: For some reason, I have to manually start the dependent service at least once, or it won't start when the dependee runs on boot.  Is that a known
[19:08] <bobbyz>  issue?  Am I missing a directive?  My config is here: https://gist.github.com/ziuchkovski/5a78c21aaf16fba9952f
[19:08] <bobbyz> So basically I have to 'sudo service start sidekiq-worker1' at least once, or else when I reboot it isn't started, even though it's dependee service, 'sidekiq' is supposedly started/running
[19:36] <greyback_> bobbyz: is upstart also starting a job called "sidekiq"? Is the sidekiq job depending on some startup signal? (e.g. "start on filesystem/mountall/login-session-start"
[19:37] <bobbyz> greyback_: The sidekiq jobs is set for 'start on runlevel [2345]'
[19:37] <greyback_> bobbyz: and that's working, yeah?
[19:37] <bobbyz> Supposedly...it's just a dummy job in that it doesn't do anything: https://gist.github.com/ziuchkovski/5a78c21aaf16fba9952f#file-sidekiq-conf-L7
[19:37] <bobbyz> It's more of a marker to trigger and control a group of worker jobs
[19:38] <bobbyz> so 'service sidekiq status' does show started/running on reboot
[19:38] <bobbyz> but the dependent worker jobs all say 'stopped/waiting'
[19:38] <greyback_> bobbyz: ok, then upstart started it at least
[19:38] <bobbyz> unless I start them manually and reboot again, at which point they all start
[19:39] <greyback_> so it works after a reboot?
[19:39] <bobbyz> it works after reboot if I manually start those worker jobs at least once
[19:39] <bobbyz> if I don't they don't start on reboot
[19:39] <bobbyz> so I thought maybe I'm missing a directive
=== salem_ is now known as _salem
[19:40] <greyback_> not that I can think of, you seem to be doing the right thing
[19:42] <bobbyz> ok, I'll dig more on my side then...maybe there's something else going on
[19:42] <bobbyz> thanks for taking a look, I appreciate it
[19:44] <greyback_> well I'd stick a line in your worker job to ensure it's being started at all - perhaps something else is stopping them immediately?
[20:15] <bobbyz> good idea, I'll try that out
=== zigo_ is now known as zigo
[20:52] <Unit193> How would one go about a security update for trusty?  Icecast2 looks like it needs Debian #782120, CVE-2015-3026.
[20:52] <ubottu> Debian bug 782120 in icecast2 "icecast2: icecast can be remotely killed by anyone if using <authentication type="url"> and stream_auth option (CVE-2015-3026)" [Important,Open] http://bugs.debian.org/782120
[20:52] <ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3026)
[20:57] <melodie> hi Unit193
[20:57] <Unit193> Howdy.
[21:01] <infinity> Unit193: Meet mdeslaur.
[21:01] <infinity> mdeslaur: Meet Unit193.
[21:02]  * Unit193 runs.
[21:02] <infinity> Unit193: Short answer, though, for universe security updates, you prepare an update, hand it off to the security team to build in their PPA, and they release it for you.
[21:03] <Unit193> infinity: Sounds easy enough.  Trying to do the Debian one now.
[21:04] <infinity> Unit193: Oh, and mdeslaur clocked out 30m ago, apparently.  You might want to try poking him tomorrow if he doesn't wander by his computer and say hi tonight.
[21:06] <Unit193> infinity: Alright.  Thanks for the information.
[21:16] <sarnold> Unit193: this is the url we stuff in all the launchpad bugs asking for universe security updates: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
[21:17] <sarnold> Unit193: our cve tracker has a few more open issues for icecast2, if you're going to prepare an update can you please look them over as well? thanks http://people.canonical.com/~ubuntu-security/cve/pkg/icecast2.html
[21:23] <Unit193> sarnold: Lovely...  Too bad you can't just upgrade to a fixed version. :P
=== _salem is now known as salem_
[21:24] <sarnold> Unit193: yeah, I know what you mean..
[21:25] <Unit193> (I'm already running 2.4.2, which has json output fixes as well.  Oh well.)
[21:41] <Unit193> sarnold: With a quick glance, http://paste.openstack.org/show/1gwZe6bjxp8zCKoKw9hn look almost sane?
[21:44] <sarnold> Unit193: nice; we like to include some dep-3 tags in the patches to indicate where they came from, and we like to format the changelogs with SECURITY UPDATE: as a leader, and - CVE-yyyy-nnnn as a standalone line, in case someone's got a text parser for it, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[21:45] <Unit193> Dangit.
[22:01] <Unit193> http://paste.openstack.org/show/gA31ndECVL75qvx9Vdhv/ I officially dislike security updates.
[22:03] <Unit193> sarnold: I know it's not great, but eh.
[22:03] <sarnold> Unit193: but that looks fantastic! :)
[22:03] <sarnold> Unit193: please attach to a bug, mdeslaur ought to get to it tomorrow :) thanks!
[22:04] <Unit193> sarnold: I'm pretty sure I'll leave future ones to you fellas.  I suppose I have to file a security bug now too.  Bleh.
[22:06] <sarnold> Unit193: so I shouldn't get my hopes too much and go dangling http://people.canonical.com/~ubuntu-security/cve/universe.html around? :)
[22:07] <Unit193> sarnold: Haha, noooo. :P  I'm still working on pushing all my local changes back into Debian or Ubuntu for that matter. :P
[22:07] <sarnold> Unit193: oof :) and I've thought before how nice it would be to have some time to go pushing distro changes back up to upstreams..
[22:09] <melodie> hi
[22:10] <Unit193> sarnold: Just not having it in my own repo would be a start, at least.  Problem is when you don't want to become the new maintainer in Debian! :P  LP 1449771, btw.
[22:10] <ubottu> Error: Launchpad bug 1449771 could not be found
[22:10] <melodie> what does it take as pre-required steps, to compile the sources of a lib in a chroot?
[22:16] <Unit193> I set the urgency to 'high', because I had just prepped the jessie-security fix.  wiki says Ubuntu ignores it, so it should be fine.
[22:35] <infinity> Unit193: We don't completely ignore urgency, but we ignore it enough for it to mostly not matter.
[22:35] <infinity> Unit193: To be fair, for all but sid, Debian pretty much ignores it too.
[22:36] <Unit193> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-building
[22:36] <infinity> Unit193: In that *-security is already prioritized higher on the buildds, and security uploads don't have a migration period.
[22:36] <Unit193> infinity: But right, thanks.  I'm sure I'll have to fix something there too. :/
[22:36] <infinity> Unit193: Yeah, I think the Debian security team just sets "high" (or higher) to hint things like package frontends to say "hey, this is important".
[22:37] <Unit193> Ah.
[22:37] <infinity> Unit193: Which isn't an entirely unreasonable thing to do in Ubuntu too, if people use similar frontends.
[22:37] <infinity> Unit193: But in both cases, it has almost 0 effect on the uploads, since buildds prefer security, and there's no britney migration in the way.
[22:37] <Unit193> infinity: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging could likely use a change then.
[22:38] <infinity> Unit193: Less interesting in Ubuntu proper, as our preferred GUI package updater (update-manager) already highlights security updates via their apt source.
[22:39] <infinity> (Which fails miserably for people who discover that all -security updates are mirrored to -updates and disable the former, but whatever)
[22:40] <Unit193> infinity: Right, though I don't personally use that.  That's also a bad idea if you use, for example, mirror://mirrors.ubuntu.com/US.txt but hey.  And, at least security updates seem slightly easier in Ubuntu, thanks to sarnold.
[22:41] <infinity> Unit193: From my POV as core-dev and a DD, I'd say they're about equally as annoying, but that's the price you pay for being able to upload something that will have zero bake time before it's slammed onto end users' machines.  Need checks and balances in place to make sure what ends up out there isn't crap.
[22:42]  * Unit193 notes down infinity is a DD, for future use... ;)
[22:42] <Unit193> infinity: Alright, well lets hope this works then...
[22:44]  * infinity notes that he's been a DD for 13 years, and wonders where the time's gone.
[22:44] <mdeslaur> Unit193: thanks for the bug and the debdiff, I'll take a look at it first thing tomorrow
[22:45] <Unit193> mdeslaur: Great, thanks.
[22:45] <Unit193> infinity: I'm going for packageset and eventually DM once I can get some gpg sigs.
[22:51] <Unit193> mdeslaur: Bah, sorry.  I mistargetted that. :/
[22:52] <mdeslaur> that's fine, you can't accept the target nominations anyway
[22:53] <Unit193> That is, target distro trusty and not trusty-security.
[22:54] <infinity> Unit193: trusty is fine.
[22:54] <infinity> Unit193: The security team are literally the only people who target by pocket and they're wrong. :P
[22:54] <Unit193> Haha.
[22:55] <mdeslaur> heh
[22:55] <mdeslaur> infinity: are you saying we don't need to do it anymore?
[22:55] <infinity> mdeslaur: You would only need to do it if you were uploading directly to the archive, which you can't do anyway.
[22:55] <mdeslaur> hrm
[22:55] <infinity> mdeslaur: Notice how you need to use special PPA paths to make it work (or edit .changes) in your case, since PPAs themselves only know about release pockets.
[22:56] <mdeslaur> right, perhaps worth revisiting on a rainy day
[22:57] <infinity> mdeslaur: That was tongue-in-cheek, mind you.  In the non-PPA archive model, foo-security is correct, since foo is rewritten to foo-proposed, which you don't want.
[22:57] <infinity> mdeslaur: It's just that the non-PPA path isn't one you can take in the current model anyway, so you're causing yourself weird pain (but your tools take care of the pain, AFAIK).
[22:58] <mdeslaur> right, I'd have to actually modify my tools to change the behaviour at this point
=== pat__ is now known as pmcgowan
[23:00] <infinity> mdeslaur: When I slam security kernels through your PPA, I just target trusty, cause nyah nyah, that's why, but whatever works for you. :)
=== salem_ is now known as _salem