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