[02:31] who here likes ubuntu === pgraner-gym is now known as pgraner-afk === superm1_ is now known as superm1 [05:20] Good morning [05:21] 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] infinity: oops, did you see that glibc fails to unpack now? [05:23] infinity: I'm aware of debian bug 776257, could it be that? [05:23] Debian bug 776257 in patch "Fails to apply patch with dangling symlink" [Serious,Open] http://bugs.debian.org/776257 [05:24] would be weird if patch would have gotten broken in two different ways [05:31] 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] pitti: I saw the test failure, but I can't reproduce it, so I have no idea what autopkgtest is doing differently. [06:18] pitti: Downloading the source and running dpkg-source -x works fine. [06:18] infinity: I can reproduce it easily here [06:19] infinity: i. e. mere apt-get source glibc under vivid [06:19] pitti: Oh. Maybe my patch isn't up to date. Didn't see the bug was patch, not dpkg. [06:19] infinity: do you have patch 2.7.3-1? [06:19] pitti: No, 2.7.1-7 ... Hence why I couldn't reproduce. [06:19] pitti: Anyhow, I *could* fix the git-updates patch, but really, patch needs fixing. [06:20] 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] infinity: yes, indeed [06:20] pitti: Given that my git-updates patch is auto-generated, I don't really want to mangle it to work around bugs. [06:20] anyway, I need to leave for the train station, bbl [06:20] pitti: Thanks for the bug pointer, though, I was stumped. [07:07] infinity: yeah, me too when I saw the systemd bug report [07:08] infinity: was that what you pinged me about last night? [07:25] good morning [07:49] pitti: It was, yeah. [07:55] morning [07:55] infinity: that might be on purpose [07:56] not 100% sure [07:56] in case other packages depend on it [07:57] infinity: /usr/share/bug/xserver-xorg-core/script is a symlink to ../xserver-xorg-core-lts-utopic/script [08:05] oh you mean the specific packages, hmm.. [08:06] I'll fix that for the -vivid backprot [09:07] 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] pitti, I didn't find why. And it is just for gmsh/mesa. [09:11] pitti, you can force the result in the history file [09:16] jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough [09:21] jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough [09:21] (echo in here) [09:22] I got disconnected after lagging for 5 mins, I wasn't sure if my last message went through :) [09:22] :P [09:22] ... through .... through [09:22] mlankhorst: I forced gmsh, mesa should propagate now [09:27] wom 21 [09:27] oh my [09:31] thanks === greyback__ is now known as greyback [09:42] hi dear developers [09:43] 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] of course I can do the merge and give it to you for review [09:55] hi folks, why virtualbox/precise-proposed didn't migrate yet? [09:55] in proposed since 2015-01-16 [10:05] pitti: no, I wasn't aware (it was a security upload). I'll look - thanks. [10:13] Looks like pinba-engine-mysql just needs a no change rebuild every time there's a new microrelease of MySQL. [10:14] I wonder if that means its uninstalling in stable releases as well. [10:23] Indeed it does. [10:23] 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] I'd argue that the strict versioning is wrong, mind. There should not be any ABI breaks in microreleases. [10:24] Nobody has complained, either. There are no Launchpad bugs for the package. [10:26] Ubuntu popcon reports: 1 install, no votes. [10:28] Looks like it's been blocked from jessie for almost a year for the same reason. [10:28] Don't think Ubuntu popcon really works any more, so I wouldn't use that for data [10:28] No uploads in Debian in that time. [10:32] (unrelated) How do I find reverse dependencies for a virtual package? [10:32] apt-cache rdepends doesn't seem to know about these; nor "reverse-depends" [10:32] Do I need to resort to grep-dctrl? === oSoMoN_ is now known as oSoMoN [10:51] 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] systemd in -proposed drops the obsolete libsystemd-{login,journal,daemon,id128-}0 libs, but there are no reverse dependencies any more [10:52] all of these binary packages install just fine in a vivid-proposed schroot [10:52] and libguestfs0 now depends on libsystemd0 only [10:52] (and that rebuild already propagated) [10:53] any idea what I can do to find out what britney is complaining about? [10:53] 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] 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] And indeed, congrats making it another year. [10:56] didrocks: btw, I sorted out https://translations.launchpad.net/ubuntu/vivid/+source/systemd/+imports [10:56] should appear in the next langpacks [10:59] didrocks: heya, I hear we are getting bluez5 in vivid? any ETA on that? ;) [10:59] sitter: I think that's more a question for cyphermox? [11:01] and i guess it really depends how fast the phone can get ported over [11:02] can someone please move xfdesktop4 from trusty-proposed to -updates? bug 1365965 [11:02] bug 1365965 in xfdesktop4 (Ubuntu Trusty) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1365965 [11:02] pitti: hmm, let's see [11:04] ogra_: that isn't even ported yet :O [11:06] pitti: libguestfs0 still Depends: libsystemd-journal0 [11:06] 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] It's put in there by a substvar which comes from some data in the source tree [11:10] ah yeah [11:10] ./appliance/packagelist.in:81: libsystemd-journal0 [11:16] 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] Laney, cjwatson: no, I already checked that debian/control doesn't have a hardcoded dep (it did, but I fixed those) [11:43] I rebuilt it locally, and it only depends on libsystemd0; ubuntu4 now also does that [11:44] ah, I'll try to update ./appliance/packagelist.in too, although I don't see how that affects the built debs [11:45] It's via a twisty chain of stuff [11:45] I didn't bother to fully investigate but it's fairly clear from ${appliance:Depends} === _salem is now known as salem_ [12:02] sitter: depends on the phonefundation team for Touch, blocked on their kernel and integration [12:02] sitter: I noticed that rsalveti put that on their list for the next few weeks [12:03] goody, thanks for the update :) [12:03] yw! === MacSlow is now known as MacSlow|lunch [12:07] infinity: around? [12:07] (mysql) [12:20] rbasak: hrm, interesting, but also a PITA for something potentially nobody uses :) [12:28] mdeslaur: yeah. I'm tempted to ignore it unless someone complains, given that it's not in jessie and appears unmaintained. [12:29] rbasak: +1 [12:29] mdeslaur: (except to no-change rebuild in vivid and future development releases which we need for proposed migration) [12:29] oh, vivid didn't migrate? sorry about that, I had not noticed === doko_ is now known as doko [12:34] didrocks: pitti: i'm starting to work on "/dev/null to remove wants" set of patches for systemd === dholbach_ is now known as dholbach [12:34] at the moment only did a trivial: systemctl --system --global enable to generate symlinks in /lib [12:34] instead of /etc [12:34] where shall i send this work in progress? [12:34] and/or publish. [12:35] xnox: maybe we should get some kind of upstream agreement? [12:35] didrocks: we do. [12:35] hum, I missed that message on the ML [12:36] 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] on github [12:36] xnox: but not on the --global -> symlinks [12:37] didrocks: yeah, but it's kind of convenient to have whilst hacking on these things =) [12:37] 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] otherwise running --enable and iterating moving things from /etc to /lib is pain. [12:41] xnox: well, I would really wait for the sprint, as there is no clear agreement, even with debian, on the finale decision [12:42] didrocks: i need this not for debian ;-) [12:43] cjwatson: hi, can you please look at bug 1409433? [12:43] bug 1409433 in perlqt (Ubuntu) "Please demote perlqt to universe" [Undecided,New] https://launchpad.net/bugs/1409433 [12:43] xnox: and not in ubuntu then ? [12:43] didrocks: elsewhere [12:46] mitya57: Just the demotions? [12:50] cjwatson: yes, not only perlqt, but the list in bug description [12:50] Yeah, I think you missed a couple from that even, but I'm checking component-mismatches [12:51] qimageblitz and smokegen can go too [12:52] Great [12:58] cyphermox: I uploaded your ppp from -proposed, libcapi20-3 from unstable and merged isdnutils to my PPA. [12:59] 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] cyphermox: libcapi20-3 is already in NEW. (https://launchpad.net/ubuntu/vivid/+queue?queue_state=0&queue_text=) [13:03] I'd be wary of NEWing libcapi20-3 until the new isdnutils source is also on its way into the archive [13:03] If new libcapi goes to -release, we have to rebuild all reverse depends. (http://paste.ubuntu.com/9897689/) [13:03] Just to avoid problems with the overwritten binary [13:04] 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] cjwatson: should do I to upload isdnutils right now? [13:04] Unless the dependencies are wrong [13:04] I don't know, I haven't reviewed it :) [13:05] mitya57: . [13:05] cjwatson: do you need to review? I thought I have permissions ;-) [13:05] ari-tczew: I don't, but you asked me a question to which I don't have the answer without reviewing it :) [13:06] cjwatson: thanks a lot [13:07] cjwatson: so if you'd be nice to answer it would be good, because we're staying in the place :) [13:07] However, isdnutils needs ppp to get built. [13:07] cjwatson: launchpad still thinks pyqt5 is in main: https://launchpad.net/ubuntu/+source/pyqt5/5.4+dfsg-1~ubuntu1/+publishinghistory [13:07] ppp is waiting in -proposed. :( [13:07] ari-tczew: I'm not blocking it [13:08] 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] I'm happy to accept the libcapi20-3 sync once there's an isdnutils dep-waiting on it [13:09] cjwatson: ok, I'll upload it [13:10] mitya57: https://launchpad.net/ubuntu/+source/pyqt5/+publishinghistory clarifies, there was a separate upload in release vs. -proposed [13:10] mitya57: sorted now [13:12] cjwatson: oh yes, I should have said that, thanks anyway [13:12] urgh, everybody moves away from isdn ... [13:32] cjwatson: ok, isdnutils is dep-waiting already [13:48] pitti, https://launchpadlibrarian.net/195907605/buildlog_ubuntu-vivid-ppc64el.openjdk-8_8u40~b22-1_FAILEDTOBUILD.txt.gz [13:49] ugh, and is there a way to tell oemstrip to leave some files untouched? === salem_ is now known as _salem [14:11] ari-tczew: libcapi20-3 accepted [14:12] cjwatson: cool, thanks. I'll rebuilt all reverse-depends. [14:12] s/rebuillt/rebuild === MacSlow|lunch is now known as MacSlow [14:35] doko: hm, is that a timeout or something? I don't see an error message [14:36] ah yes, I see it at the end [14:36] pitti, yes, but a timeout during stripping? and how can I tell oemstrip not to touch libjvm.so? [14:38] (it's pkgstriptranslations) [14:38] 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] there are no .po files [14:39] and ppc64el should be one of the fastest [14:39] doko: as for your question, debian/rules can export NO_PKG_MANGLE=1 [14:40] pitti, that would be all or nothing [14:44] ari-tczew: thanks for looking into isdnutils [14:44] I had started but couldn't make sense of the new libcapi20-3, I didn't think to look in new [14:44] what's the source package for it? [14:46] cyphermox: you're welcome, [14:46] cyphermox: https://launchpad.net/ubuntu/+source/libcapi20-3/1:3.27-1 [14:46] ah [14:47] cyphermox: these two binaries were shipped in isdnutils, but they have been splitted out to separate source libcapi20-3 (link above) [14:48] yeah, I saw [14:48] cyphermox: I saw you've merged nm-applet. have you been dreaming about that? [14:48] what do you mean? [14:48] it's not quite a merged [14:48] cyphermox: I guess you've spent a half of night :P [14:48] I've taken it a few steps closer to being mergeable [14:49] nah, actually it took far less time than I had expected [14:49] I had more trouble with an accessibility patch than with the indicator patch [14:49] not bad [14:50] cyphermox: what are the next steps to do? [14:50] plugins from universe? [14:50] network-manager-pptp, which I had already started [14:50] that will unblock things [14:51] after that yes, the other plugins [14:51] also, whatever libcapi reverse-depends. [14:52] 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] cyphermox: I'm on it in the evening [14:53] till all libcapi20-3 builds are ready [14:54] arm64 is still waiting [14:54] ari-tczew: ok, in that care let me know when you have time, because I'll start on them [14:54] hallyn, stgraber: ah, systemd with the user lxc cgroup permission fix finally went in [14:55] cyphermox: ok. I hope in a few hours rebuilds are ready. [14:55] * ari-tczew is going away. exams @school this weekend. === dannf` is now known as dannf [14:59] pitti: yay! === _salem is now known as salem_ === pgraner-afk is now known as pgraner [15:27] hi, I tried the latest vivid-server-amd64.iso today http://cdimage.ubuntu.com/ubuntu-server/daily/20150127/ [15:27] and found an issue: Jan 27 14:39:30 in-target: The following packages have unmet dependencies: [15:28] 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] but I am not sure where is the best place to report this bug. [15:28] May someone tell me where to report this issue? Thanks. === salem_ is now known as _salem [15:38] taihsiang: https://bugs.launchpad.net/ubuntu-cdimage since that's an image build problem [15:41] I would need some help from some AA to remove makedumpfile from the sync-blacklist so I can sync it from experimental === caribou_ is now known as caribou [15:42] cjwatson, thanks === rcj is now known as Guest88089 [15:43] 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] 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] cjwatson, understood. thanks for the clear explanation. === _salem is now known as salem_ [15:48] caribou: done [15:49] cjwatson: many thanks sir [16:21] rbasak, any news on https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ? [16:21] Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged] [16:21] jibel: bah, so who broke php :) [16:21] pitti: o/ [16:22] rbasak: I got a gazillion test regressions as php seems uninstallable now [16:22] pitti: yeah, that's expected. I needed to rebuild a new php-json after uploading php5. That's done now. [16:22] right, that's one of the first items in the pkgProblemResolver output [16:23] 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] pitti: need to rebuild everything that depended on the old ABI. About 50. I just uploaded the rebuilds a few minutes ago. [16:24] I'm not sure how that maps to the dep8 tests exactly. [16:24] So I wasn't going to ask for retests until those builds had finished. [16:24] 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] rbasak: and the rest we just retry tomorrow morning then [16:24] rbasak: thanks for the heads-up [16:25] 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] rbasak: no problem at all -- the smiley was deliberate :) [16:26] :) [16:26] Though not totally sure they're going to manage openjdk-6 in finite time. Oh well [16:26] rbasak: we have -proposed exactly for this; I was just a bit surprised when I looked in my mailbox [16:31] pitti: howdy, systemd question for you.... [16:32] pitti: does /usr/sbin/service need any additional logic to start/stop/status systemd services? [16:32] pitti: it does a good job of being a layer of abstraction between sysvinit and upstart services [16:33] pitti: it crosses my mind that perhaps some new logic might be needed for systemd services... [16:33] kirkland: what do you mean wrt. "new logic"? === roadmr is now known as roadmr_afk [16:34] 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] these get alogn with sysv, upstart, and systemd [16:35] like "service foo start" [16:35] pitti: exactly :-) (fwiw, I wrote /usr/sbin/service many moons ago) [16:35] kirkland: oh, that was you? didn't know that :) [16:35] pitti: indeed :-) [16:35] # * August 2008 - Dustin Kirkland [16:36] pitti: the earliest code was a port from RH, but it grew far beyond that, with upstartedness [16:36] 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] kirkland: as far as I'm aware, invoke-rc.d and service fully support all three now [16:37] kirkland: utopic's still had some bugs, though, so I'm talking "vivid" here [16:37] pitti: fantastic, I should have known you were on top of it :-) === Guest88089 is now known as rcjenn [16:38] pitti: ah, look at that (I just opened the code, which I should have done BEFORE opening my mouth) :-) [16:38] kirkland: no worries at all :) [16:40] CVE-2015-0235 [16:40] ** 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-0235) [16:40] ubottu: thanks, that was fast :) [16:40] ivoks: I am only a bot, please don't think I'm intelligent :) [16:52] 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] rbasak, no problem. If there's anything I can do to speed things up do drop me a line. [16:55] hi, I'm setting a preseed. What's the diff between d-i apt-setup and apt-mirror-setup? [16:56] hmm.. maybe that's not the channel for this doubt, sorry === roadmr_afk is now known as roadmr [17:05] stgraber: oh, and if you could confirm that your machine with the bond interface is booting/working correctly now, I'd appreciated [17:06] stgraber: I made some guesses about reproducing it (do you use ifenslave?) === apw is now known as jsalisbury === jsalisbury is now known as apw [17:06] pitti: that machine uses ifenslave, yes and I'll check in about two weeks [17:06] being 7000km away from it, not feeling like taking the chance :) [17:06] stgraber: ok; using ifenslave is the most important bit of it (I don't know if there's another way) [17:07] stgraber: with ifenslave, the reason for the hang was quite clear [17:08] ah yeah, ifup bond0 waits for ifup of ethX (or the other way around depending on the order they're brought up) [17:08] stgraber: so, should be all good now [17:11] stgraber, tks ... 7000km ... just strech your arm a bit [17:21] 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] DktrKranz: ping? [17:33] DktrKranz: regarding https://bugs.kde.org/show_bug.cgi?id=343376 [17:33] KDE bug 343376 in VNC "KRDC crashes when connecting to Mac server" [Grave,Unconfirmed] === directhex_ is now known as directhex [17:48] rbasak: I was not around, it was 5am. [17:50] * cyphermox -> lunch [17:54] doko, apologies its taken me a while to find time but component-mismatches is now alot cleaner - less maven explosion [17:57] infinity: I never know what timezone you're in :) [17:57] infinity: I'm EOD now. Can we chat tomorrow? [17:58] rbasak: I never know what timezone I'm in either, and sure. [18:00] jamespage, much appreciated === greyback__ is now known as greyback === salem_ is now known as _salem === ubott2 is now known as ubottu === yp is now known as ypwong === apw_ is now known as apw [21:52] 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] 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] 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] semiosis, mmm. OK. So if I depend on 'foo seems worth a try [22:00] 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] Afternoon everyone [22:15] 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] If not, can you suggest an appropriate one? [22:24] nijopa: #ubuntu would also be appropriate. In general, https://wiki.ubuntu.com/DebuggingProgramCrash#Installing_debug_symbols_manually [22:25] nijopa: (The gcc tools have a bunch of -dbgsym packages with the stripped symbols) [22:40] RAOF - thanks [22:41] I've found the debug packages, and I know about how to do the install [22:42] 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] For example, what appears to be the top level debug symbol package only contains a handful of files [22:43] when I'd expect it to contain more, or install a bunch of dependencies. [22:43] It's not a big deal - I can build the toolchain from scratch easily enough [22:47] 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.