[02:31] <nagromlt> who here likes ubuntu
[05:20] <pitti> Good morning
[05:21] <pitti> infinity: ah, ok; they don't have anything in particular in their status other than an obsolete error message, so I didn't dare and turn them to auto again
[05:23] <pitti> infinity: oops, did you see that glibc fails to unpack now?
[05:23] <pitti> infinity: I'm aware of debian bug 776257, could it be that?
[05:24] <pitti> would be weird if patch would have gotten broken in two different ways
[05:31] <pitti> rbasak: did you see that mysql-5.5 is stuck in -proposed as it seems to make pinba-engine-mysql-5.5 uninstallable?
[06:18] <infinity> pitti: I saw the test failure, but I can't reproduce it, so I have no idea what autopkgtest is doing differently.
[06:18] <infinity> pitti: Downloading the source and running dpkg-source -x works fine.
[06:18] <pitti> infinity: I can reproduce it easily here
[06:19] <pitti> infinity: i. e. mere apt-get source glibc under vivid
[06:19] <infinity> pitti: Oh.  Maybe my patch isn't up to date.  Didn't see the bug was patch, not dpkg.
[06:19] <pitti> infinity: do you have patch 2.7.3-1?
[06:19] <infinity> pitti: No, 2.7.1-7 ... Hence why I couldn't reproduce.
[06:19] <infinity> pitti: Anyhow, I *could* fix the git-updates patch, but really, patch needs fixing.
[06:20] <pitti> infinity: in the systemd package I worked around that by changing my patch to not create a dangling symlink, but it was trivial there
[06:20] <pitti> infinity: yes, indeed
[06:20] <infinity> pitti: Given that my git-updates patch is auto-generated, I don't really want to mangle it to work around bugs.
[06:20] <pitti> anyway, I need to leave for the train station, bbl
[06:20] <infinity> pitti: Thanks for the bug pointer, though, I was stumped.
[07:07] <pitti> infinity: yeah, me too when I saw the systemd bug report
[07:08] <pitti> infinity: was that what you pinged me about last night?
[07:25] <dholbach> good morning
[07:49] <infinity> pitti: It was, yeah.
[07:55] <mlankhorst> morning
[07:55] <mlankhorst> infinity: that might be on purpose
[07:56] <mlankhorst> not 100% sure
[07:56] <mlankhorst> in case other packages depend on it
[07:57] <mlankhorst> infinity: /usr/share/bug/xserver-xorg-core/script is a symlink to ../xserver-xorg-core-lts-utopic/script
[08:05] <mlankhorst> oh you mean the specific packages, hmm..
[08:06] <mlankhorst> I'll fix that for the -vivid backprot
[09:07] <pitti> jibel: did you see anything weird about the gmsh test? i. e. always failed on i386, always passed on amd64, but britney considers it a regression?
[09:11] <jibel> pitti, I didn't find why. And it is just for gmsh/mesa.
[09:11] <jibel> pitti, you can force the result in the history file
[09:16] <pitti> jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough
[09:21] <pitti> jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough
[09:21] <Laney> (echo in here)
[09:22] <pitti> I got disconnected after lagging for 5 mins, I wasn't sure if my last message went through :)
[09:22] <Laney> :P
[09:22] <pitti> ... through .... through
[09:22] <pitti> mlankhorst: I forced gmsh, mesa should propagate now
[09:27] <highvoltage> wom 21
[09:27] <highvoltage> oh my
[09:31] <mlankhorst> thanks
[09:42] <LocutusOfBorg1> hi dear developers
[09:43] <LocutusOfBorg1> mdeslaur, how do you feel about getting openssl 1.0.2 into vivid? Just asking since you said that the merge was in hold until the next release
[09:43] <LocutusOfBorg1> of course I can do the merge and give it to you for review
[09:55] <LocutusOfBorg1> hi folks, why virtualbox/precise-proposed didn't migrate yet?
[09:55] <LocutusOfBorg1> in proposed since  2015-01-16
[10:05] <rbasak> pitti: no, I wasn't aware (it was a security upload). I'll look - thanks.
[10:13] <rbasak> Looks like pinba-engine-mysql just needs a no change rebuild every time there's a new microrelease of MySQL.
[10:14] <rbasak> I wonder if that means its uninstalling in stable releases as well.
[10:23] <rbasak> Indeed it does.
[10:23] <rbasak> mdeslaur: ^^ something to be aware of. Looks like a no change rebuild is required for every release for every mysql 5.5 microrelease if we don't want to break pinba-engine-mysql.
[10:24] <rbasak> I'd argue that the strict versioning is wrong, mind. There should not be any ABI breaks in microreleases.
[10:24] <rbasak> Nobody has complained, either. There are no Launchpad bugs for the package.
[10:26] <rbasak> Ubuntu popcon reports: 1 install, no votes.
[10:28] <rbasak> Looks like it's been blocked from jessie for almost a year for the same reason.
[10:28] <Laney> Don't think Ubuntu popcon really works any more, so I wouldn't use that for data
[10:28] <rbasak> No uploads in Debian in that time.
[10:32] <rbasak> (unrelated) How do I find reverse dependencies for a virtual package?
[10:32] <rbasak> apt-cache rdepends doesn't seem to know about these; nor "reverse-depends"
[10:32] <rbasak> Do I need to resort to grep-dctrl?
[10:51] <pitti> Laney, cjwatson: hm, so I don't understand why systemd breaks libguestfs at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[10:52] <pitti> systemd in -proposed drops the obsolete libsystemd-{login,journal,daemon,id128-}0 libs, but there are no reverse dependencies any more
[10:52] <pitti> all of these binary packages install just fine in a vivid-proposed schroot
[10:52] <pitti> and libguestfs0 now depends on libsystemd0 only
[10:52] <pitti> (and that rebuild already propagated)
[10:53] <pitti> any idea what I can do to find out what britney is complaining about?
[10:53] <pitti> there's some NBS involved here, but I can't possibly remove the old libs from vivid before -6ubuntu1 gets promoted to vivid
[10:54] <Unit193> Laney: Re: popcon.  At least right now, it's broken (not updating the page correctly) again, but since it's opt-in anyway...  Normally rt needs poked to fix it, and it seems to break every few months.
[10:54] <Unit193> And indeed, congrats making it another year.
[10:56] <pitti> didrocks: btw, I sorted out https://translations.launchpad.net/ubuntu/vivid/+source/systemd/+imports
[10:56] <pitti> should appear in the next langpacks
[10:59] <sitter> didrocks: heya, I hear we are getting bluez5 in vivid? any ETA on that? ;)
[10:59] <pitti> sitter: I think that's more a question for cyphermox?
[11:01] <ogra_> and i guess it really depends how fast the phone can get ported over
[11:02] <brainwash> can someone please move xfdesktop4 from trusty-proposed to -updates? bug 1365965
[11:02] <Laney> pitti: hmm, let's see
[11:04] <sitter> ogra_: that isn't even ported yet :O
[11:06] <cjwatson> pitti: libguestfs0 still Depends: libsystemd-journal0
[11:06] <cjwatson> pitti: if you tried to rebuild to make shlibdeps go away, then I think perhaps it has a hardcoded dep in debian/control
[11:09] <Laney> It's put in there by a substvar which comes from some data in the source tree
[11:10] <cjwatson> ah yeah
[11:10] <cjwatson> ./appliance/packagelist.in:81:  libsystemd-journal0
[11:16] <ari-tczew> cyphermox: the merge for isdnutils from unstable is quite ready, but now came another problem. libcapi20-3 is now in separated package, which we need yet to sync.
[11:43] <pitti> Laney, cjwatson: no, I already checked that debian/control doesn't have a hardcoded dep (it did, but I fixed those)
[11:43] <pitti> I rebuilt it locally, and it only depends on libsystemd0; ubuntu4 now also does that
[11:44] <pitti> ah, I'll try to update ./appliance/packagelist.in too, although I don't see how that affects the built debs
[11:45] <cjwatson> It's via a twisty chain of stuff
[11:45] <cjwatson> I didn't bother to fully investigate but it's fairly clear from ${appliance:Depends}
[12:02] <didrocks> sitter: depends on the phonefundation team for Touch, blocked on their kernel and integration
[12:02] <didrocks> sitter: I noticed that rsalveti put that on their list for the next few weeks
[12:03] <sitter> goody, thanks for the update :)
[12:03] <didrocks> yw!
[12:07] <rbasak> infinity: around?
[12:07] <rbasak> (mysql)
[12:20] <mdeslaur> rbasak: hrm, interesting, but also a PITA for something potentially nobody uses :)
[12:28] <rbasak> mdeslaur: yeah. I'm tempted to ignore it unless someone complains, given that it's not in jessie and appears unmaintained.
[12:29] <mdeslaur> rbasak: +1
[12:29] <rbasak> mdeslaur: (except to no-change rebuild in vivid and future development releases which we need for proposed migration)
[12:29] <mdeslaur> oh, vivid didn't migrate? sorry about that, I had not noticed
[12:34] <xnox> didrocks: pitti: i'm starting to work on "/dev/null to remove wants" set of patches for systemd
[12:34] <xnox> at the moment only did a trivial: systemctl --system --global enable to generate symlinks in /lib
[12:34] <xnox> instead of /etc
[12:34] <xnox> where shall i send this work in progress?
[12:34] <xnox> and/or publish.
[12:35] <didrocks> xnox: maybe we should get some kind of upstream agreement?
[12:35] <xnox> didrocks: we do.
[12:35] <didrocks> hum, I missed that message on the ML
[12:36] <xnox> didrocks:  in december archives lennart said that he will take patches that cleanly implement logic as specified to "unwant if symlink target is to /dev/null" I believe i've added links to the messages from lennart on the pad
[12:36]  * xnox makes a git repository
[12:36] <xnox> on github
[12:36] <didrocks> xnox: but not on the --global -> symlinks
[12:37] <xnox> didrocks: yeah, but it's kind of convenient to have whilst hacking on these things =)
[12:37] <xnox> didrocks: plus e.g. i imagine we would want packaging to use --system --global to genere symlinks at package built time or some/such.
[12:37] <xnox> otherwise running --enable and iterating moving things from /etc to /lib is pain.
[12:41] <didrocks> xnox: well, I would really wait for the sprint, as there is no clear agreement, even with debian, on the finale decision
[12:42] <xnox> didrocks: i need this not for debian ;-)
[12:43] <mitya57> cjwatson: hi, can you please look at bug 1409433?
[12:43] <didrocks> xnox: and not in ubuntu then ?
[12:43] <xnox> didrocks: elsewhere
[12:46] <cjwatson> mitya57: Just the demotions?
[12:50] <mitya57> cjwatson: yes, not only perlqt, but the list in bug description
[12:50] <cjwatson> Yeah, I think you missed a couple from that even, but I'm checking component-mismatches
[12:51] <cjwatson> qimageblitz and smokegen can go too
[12:52] <mitya57> Great
[12:58] <ari-tczew> cyphermox: I uploaded your ppp from -proposed, libcapi20-3 from unstable and merged isdnutils to my PPA.
[12:59] <ari-tczew> cyphermox: Every from those packages built fine. You can try to use it. (https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+packages?field.name_filter=&field.status_filter=published&field.series_filter=vivid)
[13:00] <ari-tczew> cyphermox: libcapi20-3 is already in NEW. (https://launchpad.net/ubuntu/vivid/+queue?queue_state=0&queue_text=)
[13:03] <cjwatson> I'd be wary of NEWing libcapi20-3 until the new isdnutils source is also on its way into the archive
[13:03] <ari-tczew> If new libcapi goes to -release, we have to rebuild all reverse depends. (http://paste.ubuntu.com/9897689/)
[13:03] <cjwatson> Just to avoid problems with the overwritten binary
[13:04] <cjwatson> The new libcapi won't go to the release pocket until all reverse-dependencies are rebuilt, I wouldn't expect?  proposed-migration should ensure that
[13:04] <ari-tczew> cjwatson: should do I to upload isdnutils right now?
[13:04] <cjwatson> Unless the dependencies are wrong
[13:04] <cjwatson> I don't know, I haven't reviewed it :)
[13:05] <cjwatson> mitya57: .
[13:05] <ari-tczew> cjwatson: do you need to review? I thought I have permissions ;-)
[13:05] <cjwatson> ari-tczew: I don't, but you asked me a question to which I don't have the answer without reviewing it :)
[13:06] <mitya57> cjwatson: thanks a lot
[13:07] <ari-tczew> cjwatson: so if you'd be nice to answer it would be good, because we're staying in the place :)
[13:07] <ari-tczew> However, isdnutils needs ppp to get built.
[13:07] <mitya57> cjwatson: launchpad still thinks pyqt5 is in main: https://launchpad.net/ubuntu/+source/pyqt5/5.4+dfsg-1~ubuntu1/+publishinghistory
[13:07] <ari-tczew> ppp is waiting in -proposed. :(
[13:07] <cjwatson> ari-tczew: I'm not blocking it
[13:08] <cjwatson> If you have the technical permission to upload it, you're taking responsibility for it, you think it's correct, and nobody's objecting, you should probably upload it :)
[13:08] <cjwatson> I'm happy to accept the libcapi20-3 sync once there's an isdnutils dep-waiting on it
[13:09] <ari-tczew> cjwatson: ok, I'll upload it
[13:10] <cjwatson> mitya57: https://launchpad.net/ubuntu/+source/pyqt5/+publishinghistory clarifies, there was a separate upload in release vs. -proposed
[13:10] <cjwatson> mitya57: sorted now
[13:12] <mitya57> cjwatson: oh yes, I should have said that, thanks anyway
[13:12] <doko> urgh, everybody moves away from isdn ...
[13:32] <ari-tczew> cjwatson: ok, isdnutils is dep-waiting already
[13:48] <doko> pitti, https://launchpadlibrarian.net/195907605/buildlog_ubuntu-vivid-ppc64el.openjdk-8_8u40~b22-1_FAILEDTOBUILD.txt.gz
[13:49] <doko> ugh, and is there a way to tell oemstrip to leave some files untouched?
[14:11] <cjwatson> ari-tczew: libcapi20-3 accepted
[14:12] <ari-tczew> cjwatson: cool, thanks. I'll rebuilt all reverse-depends.
[14:12] <ari-tczew> s/rebuillt/rebuild
[14:35] <pitti> doko: hm, is that a timeout or something? I don't see an error message
[14:36] <pitti> ah yes, I see it at the end
[14:36] <doko> pitti, yes, but a timeout during stripping? and how can I tell oemstrip not to touch libjvm.so?
[14:38] <pitti> (it's pkgstriptranslations)
[14:38] <pitti> doko: could it be that this is just a large build tree, and finding/taring the *.po files is slow on that builder?
[14:39] <doko> there are no .po files
[14:39] <doko> and ppc64el should be one of the fastest
[14:39] <pitti> doko: as for your question, debian/rules can export NO_PKG_MANGLE=1
[14:40] <doko> pitti, that would be all or nothing
[14:44] <cyphermox> ari-tczew: thanks for looking into isdnutils
[14:44] <cyphermox> I had started but couldn't make sense of the new libcapi20-3, I didn't think to look in new
[14:44] <cyphermox> what's the source package for it?
[14:46] <ari-tczew> cyphermox: you're welcome,
[14:46] <ari-tczew> cyphermox: https://launchpad.net/ubuntu/+source/libcapi20-3/1:3.27-1
[14:46] <cyphermox> ah
[14:47] <ari-tczew> cyphermox: these two binaries were shipped in isdnutils, but they have been splitted out to separate source libcapi20-3 (link above)
[14:48] <cyphermox> yeah, I saw
[14:48] <ari-tczew> cyphermox: I saw you've merged nm-applet. have you been dreaming about that?
[14:48] <cyphermox> what do you mean?
[14:48] <cyphermox> it's not quite a merged
[14:48] <ari-tczew> cyphermox: I guess you've spent a half of night :P
[14:48] <cyphermox> I've taken it a few steps closer to being mergeable
[14:49] <cyphermox> nah, actually it took far less time than I had expected
[14:49] <cyphermox> I had more trouble with an accessibility patch than with the indicator patch
[14:49] <ari-tczew> not bad
[14:50] <ari-tczew> cyphermox: what are the next steps to do?
[14:50] <ari-tczew> plugins from universe?
[14:50] <cyphermox> network-manager-pptp, which I had already started
[14:50] <cyphermox> that will unblock things
[14:51] <cyphermox> after that yes, the other plugins
[14:51] <cyphermox> also, whatever libcapi reverse-depends.
[14:52] <pitti> doko: hm, if it doesn't have any desktop files, gnome help, or translation files, then it's basically just a bunch of "find" commands; I can't see from the log where it's stuck :/ we'd need a set -x output, or just retry the build and see whether it gets further/hangs at a different place, and maybe inspect dmesg to see if it has a stuck process?
[14:53] <ari-tczew> cyphermox: I'm on it in the evening
[14:53] <ari-tczew> till all libcapi20-3 builds are ready
[14:54] <ari-tczew> arm64 is still waiting
[14:54] <cyphermox> ari-tczew: ok, in that care let me know when you have time, because I'll start on them
[14:54] <pitti> hallyn, stgraber: ah, systemd with the user lxc cgroup permission fix finally went in
[14:55] <ari-tczew> cyphermox: ok. I hope in a few hours rebuilds are ready.
[14:55]  * ari-tczew is going away. exams @school this weekend.
[14:59] <stgraber> pitti: yay!
[15:27] <taihsiang> hi, I tried the latest vivid-server-amd64.iso  today http://cdimage.ubuntu.com/ubuntu-server/daily/20150127/
[15:27] <taihsiang> and found an issue: Jan 27 14:39:30 in-target: The following packages have unmet dependencies:
[15:28] <taihsiang> Jan 27 14:39:30 in-target:  perl : Depends: perl-base (= 5.20.1-4) but 5.20.1-5 is to be installed
[15:28] <taihsiang> but I am not sure where is the best place to report this bug.
[15:28] <taihsiang> May someone tell me where to report this issue? Thanks.
[15:38] <cjwatson> taihsiang: https://bugs.launchpad.net/ubuntu-cdimage since that's an image build problem
[15:41] <caribou_> I would need some help from some AA to remove makedumpfile from the sync-blacklist so I can sync it from experimental
[15:42] <taihsiang> cjwatson, thanks
[15:43] <taihsiang> cjwatson, if I remember correct, it is very usual issue when playing around with a daily image. This kind of issues (package dependency, especially perl-*) happened to me several times.
[15:44] <cjwatson> taihsiang: This one is because the image build system's mirror didn't get properly updated when that image was being built, possibly a locking issue that we've run into before.
[15:46] <taihsiang> cjwatson, understood. thanks for the clear explanation.
[15:48] <cjwatson> caribou: done
[15:49] <caribou> cjwatson: many thanks sir
[16:21] <alexbligh1> rbasak, any news on https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
[16:21] <pitti> jibel: bah, so who broke php :)
[16:21] <rbasak> pitti: o/
[16:22] <pitti> rbasak: I got a gazillion test regressions as php seems uninstallable now
[16:22] <rbasak> pitti: yeah, that's expected. I needed to rebuild a new php-json after uploading php5. That's done now.
[16:22] <pitti> right, that's one of the first items in the pkgProblemResolver output
[16:23] <pitti> rbasak: ah, so we only need to rebuild few packages, not all of them?
[16:23]  * pitti restarts a random one to see
[16:23] <rbasak> pitti: need to rebuild everything that depended on the old ABI. About 50. I just uploaded the rebuilds a few minutes ago.
[16:24] <rbasak> I'm not sure how that maps to the dep8 tests exactly.
[16:24] <rbasak> So I wasn't going to ask for retests until those builds had finished.
[16:24] <pitti> rbasak: ah nice; so every package which did get an upload will at least trigger its own test and thus auto-fix itself
[16:24] <pitti> rbasak: and the rest we just retry tomorrow morning then
[16:24] <pitti> rbasak: thanks for the heads-up
[16:25] <rbasak> pitti: ack. Sorry I didn't warn in advance. I don't know how else I could have approached this, but I'll warn next time.
[16:25]  * cjwatson re-enables adare and ross for now
[16:25] <pitti> rbasak: no problem at all -- the smiley was deliberate :)
[16:26] <rbasak> :)
[16:26] <cjwatson> Though not totally sure they're going to manage openjdk-6 in finite time.  Oh well
[16:26] <pitti> rbasak: we have -proposed exactly for this; I was just a bit surprised when I looked in my mailbox
[16:31] <kirkland> pitti: howdy, systemd question for you....
[16:32] <kirkland> pitti: does /usr/sbin/service need any additional logic to start/stop/status systemd services?
[16:32] <kirkland> pitti: it does a good job of being a layer of abstraction between sysvinit and upstart services
[16:33] <kirkland> pitti: it crosses my mind that perhaps some new logic might be needed for systemd services...
[16:33] <pitti> kirkland: what do you mean wrt. "new logic"?
[16:34] <pitti> kirkland: btw, if you want to write anything which is portable between init systems, don't use systemctl, but invoke-rc.d (for package maintainer scripts) or "service" (for programs)
[16:34] <pitti> these get alogn with sysv, upstart, and systemd
[16:35] <pitti> like "service foo start"
[16:35] <kirkland> pitti: exactly :-)  (fwiw, I wrote /usr/sbin/service many moons ago)
[16:35] <pitti> kirkland: oh, that was you? didn't know that :)
[16:35] <kirkland> pitti: indeed :-)
[16:35] <pitti> #   * August 2008 - Dustin Kirkland <kirkland@canonical.com>
[16:36] <kirkland> pitti: the earliest code was a port from RH, but it grew far beyond that, with upstartedness
[16:36] <kirkland> pitti: anyway, I was just wondering if it needed anything else to support upstart, and I was checking if you guys were already on top of it
[16:37] <pitti> kirkland: as far as I'm aware, invoke-rc.d and service fully support all three now
[16:37] <pitti> kirkland: utopic's still had some bugs, though, so I'm talking "vivid" here
[16:37] <kirkland> pitti: fantastic, I should have known you were on top of it :-)
[16:38] <kirkland> pitti: ah, look at that (I just opened the code, which I should have done BEFORE opening my mouth) :-)
[16:38] <pitti> kirkland: no worries at all :)
[16:40] <ivoks> CVE-2015-0235
[16:40] <ivoks> ubottu: thanks, that was fast :)
[16:52] <rbasak> alexbligh1: sorry, I haven't forgotten. I'm asking around to see if anybody else can take it on. Otherwise it'll probably after I've got mysql 5.6 done, which is taking longer than I expected.
[16:52] <alexbligh1> rbasak, no problem. If there's anything I can do to speed things up do drop me a line.
[16:55] <pfsmorigo> hi, I'm setting a preseed. What's the diff between d-i apt-setup and apt-mirror-setup?
[16:56] <pfsmorigo> hmm.. maybe that's not the channel for this doubt, sorry
[17:05] <pitti> stgraber: oh, and if you could confirm that your machine with the bond interface is booting/working correctly now, I'd appreciated
[17:06] <pitti> stgraber: I made some guesses about reproducing it (do you use ifenslave?)
[17:06] <stgraber> pitti: that machine uses ifenslave, yes and I'll check in about two weeks
[17:06] <stgraber> being 7000km away from it, not feeling like taking the chance :)
[17:06] <pitti> stgraber: ok; using ifenslave is the most important bit of it (I don't know if there's another way)
[17:07] <pitti> stgraber: with ifenslave, the reason for the hang was quite clear
[17:08] <stgraber> ah yeah, ifup bond0 waits for ifup of ethX (or the other way around depending on the order they're brought up)
[17:08] <pitti> stgraber: so, should be all good now
[17:11] <ogra_> stgraber, tks ... 7000km ... just strech your arm a bit
[17:21] <doko> pitti, https://launchpadlibrarian.net/195961040/buildlog_ubuntu-vivid-ppc64el.openjdk-8_8u40~b22-1ubuntu1_UPLOADING.txt.gz  so no processes hanging, now just building with PKG_NO_MANGLE
[17:33] <semiosis> DktrKranz: ping?
[17:33] <semiosis> DktrKranz: regarding https://bugs.kde.org/show_bug.cgi?id=343376
[17:48] <infinity> rbasak: I was not around, it was 5am.
[17:50]  * cyphermox -> lunch
[17:54] <jamespage> doko, apologies its taken me a while to find time but component-mismatches is now alot cleaner - less maven explosion
[17:57] <rbasak> infinity: I never know what timezone you're in :)
[17:57] <rbasak> infinity: I'm EOD now. Can we chat tomorrow?
[17:58] <infinity> rbasak: I never know what timezone I'm in either, and sure.
[18:00] <doko> jamespage, much appreciated
[21:52] <alexbligh1> I have made a cockup on some software which has been deployed to some of our customers. In essence, when Ubuntu was at 12.04, I shipped package A with a version number of X (which was our internal s/w version and nothing to do with package A's version). Trusty now ships a more modern version of package A (let's say version Y), but unfortunately X>Y. This means apt-get upgrade doesn't upgrade the packages. Apart
[21:52] <alexbligh1>  from apologising for being an idiot, what is the safest way to remedy the situation without the customer having to type specific incantations? Package A is brought in by a package we ship.
[21:56] <semiosis> alexbligh1: i think you can make your package depend on a specific version (or range of versions, less than X) so that apt will pull in the trusty universe package
[21:58] <alexbligh1> semiosis, mmm. OK. So if I depend on 'foo<N' and foo 0.01 is in one repo, and foo 9.00 is in another, that will automatically take foo 0.01 rather than ignore foo 0.01 because it's outdated?
[21:59] <semiosis> seems worth a try
[22:00] <alexbligh1> semiosis, this is all a bit of a mess as (to my shame) I actually cocked up three of four packages which depend on eachother
[22:00]  * alexbligh1 buries head in hands
[22:14] <nijopa> Afternoon everyone
[22:15] <nijopa> Is this the appropriate channel to ask a quick question about getting debug symbols for the GCC toolchain under Ubuntu 14.04 LTS?
[22:15] <nijopa> If not, can you suggest an appropriate one?
[22:24] <RAOF> nijopa: #ubuntu would also be appropriate. In general, https://wiki.ubuntu.com/DebuggingProgramCrash#Installing_debug_symbols_manually
[22:25] <RAOF> nijopa: (The gcc tools have a bunch of -dbgsym packages with the stripped symbols)
[22:40] <nijopa> RAOF - thanks
[22:41] <nijopa> I've found the debug packages, and I know about how to do the install
[22:42] <nijopa> I'm actually having trouble installing them (getting dependency errors) and also, the contents don't appear to be what I'd expect.
[22:42] <nijopa> For example, what appears to be the top level debug symbol package only contains a handful of files
[22:43] <nijopa> when I'd expect it to contain more, or install a bunch of dependencies.
[22:43] <nijopa> It's not a big deal - I can build the toolchain from scratch easily enough
[22:47] <RAOF> nijopa: Yeah, you'd need to install all the individual debug packages; we don't do a “install all the symbols for the whole stack” metapackage.