=== _salem is now known as salem_ === salem_ is now known as _salem [01:44] okay [01:44] cloned the branch to a private +junk one [01:44] cloned the recipe [01:44] let's go building this... [01:54] hm, that failed, looks like I'm missing something [02:07] hm, the failure is probably because it's missing a ppa at build time [02:16] via "edit dependencies" somewhere, ok [02:25] hmmm... [02:25] we are using an own version of debhelper [02:26] a rebuild only for lucid, though [02:27] the other dists are using the normal ubuntu debhelper [02:27] weird way to do a backport, but meh... that explains the build failure [03:50] ok, that worked for all builds this time... diff time [03:55] RAOF: yes, I can reproduce the problem by building on launchpad :( [03:56] Ionic: ...! [03:56] https://code.launchpad.net/~ionic/+archive/ubuntu/test-ppa/+packages [03:56] the one commit that is different is touch dummy [03:56] for launchpad to actually create new packages because of the first failure [03:57] I bet if I was also pushing a dummy commit to the X2Go release repo, the new packages would be "broken" [03:58] gonna diff the build logs now [03:58] I have seen one difference already [03:58] dpkg was updated [03:58] patch version 9 to 10 [03:59] (I'm sorry if I'm getting on your nerves, but this is so very odd for me) [04:01] Nah, that's ok. It's very odd for me, too :) [04:02] libc versions differ, too, but that shouldn't... well, who knows [04:02] it's related, to some degree [04:03] and dpkg was updated from: Get:3·http://ftpmaster.internal/ubuntu/·precise-security/main·dpkg·amd64·1.16.1.2ubuntu7.5·[18... -> Get:3·http://ftpmaster.internal/ubuntu/·precise-security/main·dpkg·amd64·1.16.1.2ubuntu7.6·[18... [04:03] Is that using imake??? [04:04] yep [04:04] it's based upon Xorg 6.9... [04:04] I know, I know [04:05] What's the underlinked library? [04:05] Or binary, I guess. [04:06] other differences: multiarch-support updated, binutils updated, dpkg-dev updated, libdpkg-perl updated [04:06] underlinked binary: usr/lib/nx/bin/nxagent (package nxagent) [04:06] actually, it's not really "underlinked" [04:06] the library shows up in ldd's output, but not in DT_NEEDED [04:07] so it's "underlinked", in quotes [04:07] libssl has also been updated, but I figure that's unimportant [04:07] Highly likely. [04:07] just like gpgv and gnupg [04:08] or libgrypt* or libtasn* or gnutls... [04:08] (the security team seems to be doing its job, though, so I'll give you that) [04:08] Have you determined whether nxagent directly uses symbols from the things in ldd but not DT_NEEDED? Because if it doesn't then this is expected (and should be harmless) behaviour. [04:08] Yeah, our security team is on the ball :) [04:09] I haven't done that [04:11] I'll checkout the debug symbols and take a look [04:12] it seems not to be using XDamage* symbols [04:12] (at least not according to nm ./usr/lib/debug/usr/lib/nx/bin/nxagent | grep -i XDamage) [04:13] You can also find that with objdump -T nxagent | grep UND; that'll give you the list of symbols that need to be resolved to load nxagent. [04:15] And objdump -T $CANDIDATE_LIBRARY | grep .text will get you the list of symbols exported from that library. [04:16] It *should* be possible to do some seddery or something to match these up; that's left as an exercise for the reader :) [04:16] But if the binary isn't directly using the XDamage* symbols then it shouldn't be getting a DT_NEEDED entry against the library providing those symbols. [04:19] looks like there are really no symbols used [04:20] Doesn't explain why you're only just seeing this, of course. [04:22] yep [04:23] I kinda bet it was the dpkg update [04:23] err, dpkg-dev [04:23] dpkg-gensymbols is part of dpkg-dev, sorry [04:24] But that's not going to change whether or not nxagent is actually linked with libnxdamage, though. [04:24] Hm, lunch time!@ [04:27] yes [04:27] so, even while no symbols are being used, we still link to libnx-xdamage1 etc. [04:27] making the binary fail to start if that library is not available [04:43] Ionic: But I thought you said nxagent had no DT_NEEDED entry for libnx-xdamage? That would imply that it *doesn't* need libnx-xdamage (except if some library it *does* use needs libnx-xdamage, in which case that library should carry the dependency). [04:44] RAOF: yes, but the makefile is still linking to it [04:44] which is probably wrong to begin with [04:45] If the binary doesn't have a DT_NEEDED entry, then the binary is not linked with it. You'll be running into the -as-needed default there, I guess. [04:46] well, gcc is not called with -Wl,-as-needed [04:48] If I read the entrails of gcc -dumpspecs correctly, --as-needed is the default, so you'd need to explicitly pass --no-as-needed to disable it. [04:48] hum [04:51] looks like it [04:52] It might be time to circle round to... what was the actual *problem* again? :) [04:52] there's something else though, it also adds --no-add-needed [04:53] but that looks like the default behavior anyway [04:53] good question [04:53] to be honest, I do not know what the *actual* problem is [04:53] a user reported "it's not working" [04:54] after he was told to run nxagent manually to see if it even starts up, he determined libnx-xdamage1, *xfixes* and *xtst* were missing on his system [04:54] which made nxagent fail to start [04:56] the weird part is that the libraries should still have been present on the system [04:56] Lacking xfixes is a really “basically everything now fails” situation, yes. [04:56] wait, let me look it up [04:57] maybe it was damage, composite and tst [04:57] oh, meh [04:57] damage, randr and xtst [04:57] That's still a “Apps using GTK or Qt don't start” situation. [04:58] Hm. [04:58] the weird part is that damage, randr and tst are dependencies of libxcompshad3 [04:59] ... which is a dependency of nxagent [04:59] Have they just flat out broken their system? [04:59] so I don't understand how the user got into his broken state in the first place [04:59] possible [04:59] because it doesn't make sense [05:00] I though find it odd the the 3 libraries that he mentioned the three libraries that were explicitly removed from nxagent's Depends: [05:00] (+ grammar) [05:01] Yeah, that's curious. [05:01] I though find it odd, that the 3 libraries that he mentioned were the packages "explicitly" (or rather implicitly though dh_shlibdeps) removed from nxagent's Depends: [05:02] so I'm a little bit careful to blame it on user error [05:02] What debugging output do you have from their system? [05:03] (and I still don't know what causes the removal in the first place. https://launchpadlibrarian.net/202647030/dpkg_1.16.1.2ubuntu7.5_1.16.1.2ubuntu7.6.diff.gz looks totally unrelated... and that was the dpkg change) [05:03] oh, don't go there [05:03] an incomplete list of installed packages, because he grepped wrongly [05:04] never told him, but the list isn't really helpful... [05:04] Heh [05:04] http://permalink.gmane.org/gmane.linux.terminal-server.x2go.user/2937 [05:05] should have rather grepped for "nx" only... [05:06] wrong message though [05:06] http://comments.gmane.org/gmane.linux.terminal-server.x2go.user/2904 [05:12] at that point, he installed the libraries though, so I can't just ask him for the complete "old" output... [05:12] And once he installed the libraries everything worked? [05:12] looks like it [05:12] "eureka" sounds like it fixed his problem [05:13] http://permalink.gmane.org/gmane.linux.terminal-server.x2go.user/2929 [05:41] Ionic: Hm... you've done some package splitting recently? [05:44] I wonder if there isn't some combination of packages that would have satisfied dependencies without installing nx-xdamage et al... [05:46] yep [05:46] well, not splitting, but renaming [05:46] from libnx-xdamage to libnx-xdamage IIRC [05:46] err, from libnx-xdamage to libnx-xdamage1 [05:49] basically from unversioned lib packages to versioned lib packages [05:52] I wouldn't know any solution set that would have been satisfied without the nx libs, though [05:53] and the upgrade path looked smooth for other users [05:53] (minus the first messup that broke stuff on ubuntu because launchpad is overriding the dist tag) === BinLi_afk is now known as BinLi [06:53] shouldn't libvirt-bin shutdown guests on vivid? [06:54] don't think the initscript is doing that, the upstart job did [06:57] hm, that or debian (guest) doesn't log shutdown === Guest87529 is now known as mwhudson === marcusto_ is now known as marcustomlinson [08:25] * mwhudson grumbles at git-buildpackage, pbuilder etc === BinLi is now known as BinLi-afk [10:26] pitti: ping [11:25] Laney, hi, thanks for syncing youtube-dl -- would you mind doing the same for https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1443773 [11:25] Launchpad bug 1443773 in plank (Ubuntu) "FFe: Sync plank 0.9.0-1 (universe) from Debian experimental (main)" [Undecided,New] [11:25] pitti: can you remind me again how to make a commit to apport? [11:38] Sweet5hark: can we update the breeze icons in libreoffice or is it too late (asks the artists) === MacSlow is now known as MacSlow|lunch [12:04] hi doko [12:04] you there? [12:04] gcc version 5.0.1 20150413 (prerelease) [gcc-5-branch revision 222064] (Debian 5.1~rc1-1) [12:04] I don't understand that "5.0.1" vs "5.1" [12:04] did they make a mistake? === _salem is now known as salem_ [12:46] pitti: I still have a couple of random breakages on proposed-migration, any thoughts on how to fix? === MacSlow|lunch is now known as MacSlow [13:29] good morning! [13:30] h [13:30] hey cyphermox [13:31] hey seb128 [13:33] cyphermox, how is Canada? [13:33] I don't know, I'm in Texas :) [13:33] oh, ok [13:33] hehe [13:34] I think Catou said it was snowing yesterday again, a bit [13:34] waouh, winter is not over yet for you?! [13:34] here we are in summer mode [13:34] 25°C sunny [13:34] yeah, not quite there yet [13:35] also, Summer for abolished, there was a memo [13:35] lol [13:35] it's now 8 months winter, 2 months fall and two months spring [13:35] ;) [13:37] well, no summer is fine, if it means avoiding the 40°C days, but that's too much winter! [13:41] seb128: I agree ;) [13:42] good morning [13:42] seb128: but the fact that it's still winter and probably depressing to some people is the only way I can explain people fighting in universities in Quebec :P [13:42] Riddell: I committed your vivid apport fix to trunk, thanks [13:42] pitti: hey! [13:42] cyphermox, they do?! [13:42] Riddell: autopkgtest failures> which one? [13:42] sadly [13:43] cyphermox: I always heard it was two seasons: winter and construction. [13:44] ScottK: sounds about right [13:45] pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#knewstuff [13:45] seb128: http://ici.radio-canada.ca/regions/montreal/2015/04/13/004-uqam-conflit-professeurs-critiquent-presidente-syndicat-nevert.shtml [13:45] urg [13:45] pitti: but kate and okteta are both green in the builds [13:45] Riddell: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-okteta/lastBuild/ARCH=i386,label=adt/console [13:45] ^ kate failure, looks like an API change somewhere? [13:45] FTBFS [13:45] pitti: "Server not found" [13:45] documentinfoview.cpp:29:23: fatal error: KIconLoader: No such file or directory [13:46] Riddell: ah, public jenkins is broken again? le sigh.. [13:46] Riddell: I'll ask the CI team [13:46] we pinged them earlier [13:47] Laney: ah, thanks [13:47] Riddell: kate: http://paste.ubuntu.com/10826776/ [13:47] Riddell: sorry, that was okteta ^ [13:48] Riddell: kate: http://paste.ubuntu.com/10826784/ [13:51] thanks pitti === roaksoax is now known as roaksoax-afk [14:27] pitti: may I have your opinion on bug 1444502 please? Odd situation that matsubara ended up in just now. [14:27] bug 1444502 in sysvinit (Ubuntu) "sysv-rc uses /sbin/runlevel without depending on a package that provides it" [Undecided,New] https://launchpad.net/bugs/1444502 [14:27] dist-upgrade fixed it, but I think it should have been prevented by dependencies [14:36] rbasak: (sorry, sprint hectic/delay) I followed up to the bug with a quick proposal [14:36] does that sound alright to you? [14:40] pitti: I think so, yes, since init pre-depends on systemd-sysv | upstart-sysv and both provide /sbin/runlevel. [14:40] pitti: as long as there isn't some broader way to solve this? [14:40] rbasak: right, that was the idea; we don't want to hardcode systemd-sysv just yet, as we still want to support upstart-sysv for a while, and definiitvely need that on the phone [14:40] rbasak: well, "init" is Essential: [14:41] rbasak: it should really Not Happen™ that you don't have it [14:41] rbasak: it used to be not essential, so perhaps matsubara was upgraeding from intra-vivid where this wasn't the case [14:41] pitti: ah, but that only happened recently, right? So matsubara might have had an older init package that wasn't essential? [14:42] pitti: maybe safe to invalidate this bug then. An essential package does indirectly provide /sbin/runlevel. [14:42] rbasak: yeah; but "init" didn't exist in utopic/trusty either [14:42] So only upgrade from beta is affected when not using dist-upgrade. [14:42] rbasak: I mean, apt-get upgrade from a previous release is already evil, bad, wrong, and crying "broken!" [14:43] I'm not sure if we can ever get this truly right, "upgrade" shold not exist really [14:43] "apt upgrade" is fine, but not apt-get upgrade [14:43] pitti: so are you +1 to mark the bug Invalid? [14:44] rbasak: fine with me too [14:45] I don't think additional deps on init hurt, but I'm not sure how much of a real use case the above is [14:45] Beta users need to know to dist-upgrade and not just apt-get upgrade. [14:46] tyhicks, hey, any news about the schroot/ecryptfs issues? if it's not fixed for vivid do you think we should add a note discouraging people who want to develop for ubuntu touch to enable ecryptfs? [14:46] Other stuff will be broken too otherwise [14:46] seb128: hey - I'm hoping to get back to those bugs [14:47] rbasak: yeah, we basically never test/support apt-get upgrade; it's probably ok for -security/-updates in many cases, but not otherwise [14:47] seb128: there are some higher priority things that I've got to tend to first [14:47] thanks rbasak, pitti [14:48] seb128: if we do add a note for users, it is important to note that it is *any* filesystem mounted at /home/USER and not just ecryptfs [14:52] tyhicks, right, but it's likely that not many users do create a speciifc /home/USER partition, where ecryptfs is a checkbox in the installer which is sort of recommended if you want more security [14:52] tyhicks, so ecryptfs is likely going to be the most common case [14:54] agreed [15:07] seb128: hmmm, Riddell asked about updating the icon theme for libreoffice/vivid again. Its low risk, but we are really later [15:07] seb128: s/later/late/ your take? [15:08] Sweet5hark, I'm not in the release team, check with them I guess [15:08] it looks like the sort of change that can be SRUed to me [15:09] seb128: true. Its just replacing a tarball in ./debian ... [15:10] seb128: so, lets punt that for an sru ... [15:10] wfm [15:10] it's not an installation issue so SRU should be alright [15:40] Riddell: ah, kate succeeded now [15:47] pitti, jibel: can you have a look at the gcc-4.8 migration? [15:47] 4.9 it is === dholbach_ is now known as dholbach [20:02] mvo: Will the lack of newline at the end of /etc/system-image/writable-paths cause problems? [20:06] writable? [20:06] I thought that was just Samba. [20:08] infinity: I think not, but I can double check [21:17] mvo: Did you determine that your lack of newline on your upload was fine? === salem_ is now known as _salem [21:42] Anyone else unable to reach http://kernel.ubuntu.com/~kernel-ppa/mainline/ [21:46] FunnyLookinHat: same [21:46] blech. [21:46] elfy, purduelug? [21:47] Oh nope - close to another nick I know :D [21:47] lol === Ionic is now known as Guest82589 === Guest82589 is now known as Ionic [23:29] pitti: Where are you? === Madkiss_ is now known as Madkiss === ming is now known as Guest25942 === \b is now known as benonsoftware === tmpRAOF is now known as RAOF === wolsen_ is now known as wolsen