=== NCommand` is now known as NCommander
=== NCommander is now known as Guest84161
=== salem_ is now known as _salem
[04:28] <pitti> Good morning
=== lifeless_ is now known as lifeless
[05:34] <pitti> doko: are you okay with dropping python3-ldb again? it has no rdepends, is an Ubuntu specific delta, and needs the NBS python3-talloc to build (see http://people.canonical.com/~ubuntu-archive/nbs.html)
[05:43] <jbicha> pitti: if you're processing nbs, libwebkit-dev is only an alternate build-depends for those packages
[05:43] <pitti> jbicha: thanks!
[06:05] <doko> pitti: sure, we can do that
=== ochosi_ is now known as ochosi
=== happyaro1 is now known as happyaron
=== dinger-donger changed the topic of #ubuntu-devel to: To find big channels with unlocked topics, use /msg alis list * -min 100 -mode -t    Then you can join them and abuse their /topic for the lulz!
[08:17] <pitti> !op @ dinger-donger
[08:17] <ubottu> pitti: I am only a bot, please don't think I'm intelligent :)
[08:18] <dinger-donger> lol
[08:18] <pitti> dinger-donger: please leave the topic alone, this is vandalism
[08:18] <dinger-donger> pitti: fuck that
=== pitti changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== dinger-donger changed the topic of #ubuntu-devel to: To find big channels with unlocked topics, use /msg alis list * -min 100 -mode -t    Then you can join them and abuse their /topic for the lulz!  | I think pitti is a filthy homosexual
[08:19] <pitti> dholbach: what's the magic incantation to ping IRC ops? dinger-donger needs to be kickbanned
=== pitti changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[08:19] <pitti> Unit193: cheers
[08:20] <dholbach> thanks Unit193 and pitti
[08:21] <Unit193> Sure thing.
[08:21] <dholbach> I don't know of any magic incantations
[08:21] <dholbach> but I'm sure there are :)
[08:21] <pitti> I thought we had some kind of !ops or so
[08:21] <dholbach> yeah, I was about to suggest the same
[08:21] <pitti> and I'm sure I've seen it before, I just forgot
[08:21] <pitti> !help
[08:21] <ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[08:22] <pitti> !commands
[08:22] <ubottu> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
[08:22] <dholbach> haha
[08:22] <pitti> !nocookies
[08:23] <Unit193> pitti: Use it like: !ops | bar is spamming the topic
[08:23] <pitti> Unit193: ah, so my "!op @ bar" was close :)
[08:23] <Unit193> Yep.
[08:23] <pitti> !ops @ dholbach needs a hug
[08:23] <ubottu> pitti: I am only a bot, please don't think I'm intelligent :)
[08:23] <pitti> err
[08:23] <pitti> !ops | dholbach needs a hug
[08:23] <ubottu> dholbach needs a hug: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, rww, or thom!
[08:24] <pitti> sorry, unping -- already sorted out
[08:24]  * pitti hugs dholbach anyway
[08:24] <ikonia> pitti: can you stop that please
[08:24]  * pitti notices that this list of people is *very* outdated
[08:25] <pitti> Unit193: do you know how to update that list?
[08:26] <ikonia> it's just a bot factoid
[08:26] <ikonia> it can be updated pretty easy
[11:15] <Mirv> 1.5h of waiting publisher run so far, doh.
[11:15] <pitti> yeah, the entirety of LP and the DC have felt like tar since ~ yesterday :/
[11:16] <ogra_> someone sitting on a cable ?
[11:17]  * pitti blames the brexit, apparently lost fast connections to the UK :)
[11:18] <ogra_> we should temporary redirect to the US then ... at least until trump is elected
=== Guest84161 is now known as NCommander
=== NCommander is now known as Guest43443
[11:49] <JanC> why not move it to Germany instead?  :)
[11:50] <ogra_> :)
[11:52] <pitti> infinity: let there be Testsuite-Triggers: in britney! https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=4d7522ddb8
[11:52] <pitti> apw: ^ you were interested in this as well
[11:59] <ogra_> adam is off this week
=== hikiko is now known as hikiko|afk
[12:04] <apw> pitti, i am interested indeed.  I assume this is going to let me suck some of the random lists out into my packages ?
[12:04] <pitti> apw: yes
[12:04] <apw> pitti, like the link between the kernel and lxc ?
[12:05] <pitti> apw: for example, we should now make lxc or lxd grow a test dependency on linux-libc-dev or linux-generic or similar
[12:05] <pitti> lxc *and* lxd
[12:06] <apw> pitti, so lxd would say Test-Triggers: foo in its main debian/control file and that would mean changes to package foo will trigger that package's tests
[12:07] <apw> s/that package/lxd
[12:07] <pitti> correct
[12:07] <pitti> except that you shouldn't really set T-T: manually; if not present it gets computed from debian/tests/control in a reasonable way
[12:07] <infinity> pitti: Oh, yeah.  I forgot about that part of the implementation.  Did you implement merging of T-T and tests/control?
[12:08] <infinity> pitti: Cause I disagree.  Setting artificial test deps to get them in T-T is wrong. :P
[12:08] <infinity> (Even if I just did it in glibc...)
[12:08] <pitti> infinity: no, that is not yet implemented, it's still the initial debian implementation
[12:08] <pitti> (also, that's dpkg again, not britney)
[12:08] <infinity> pitti: Yeah, I meant the dpkg implementation.  I didn't read it.
[12:09] <infinity> pitti: Definitely should be merging debian/control and debian/tests/control, IMO.
[12:09] <pitti> infinity: well, linux-generic is not conceptually an artificial test dependency -- so far it's just been an implied one
[12:09] <infinity> pitti: Feels "dirty" to put manual deps on build-essential packages just to get triggers.
[12:09] <apw> pitti, and how do i say "all valid kernels"
[12:10] <infinity> Triggering on all kernels is trickier.
[12:10] <infinity> Right now, it would just be "list them all".
[12:10] <pitti> yeah, you can't right now, unless they all build a common binary
[12:10] <infinity> pitti: Which they can't, for obvious reasons.
[12:10] <pitti> for linux-* in particular the code in britney is still necessary/easiesr
[12:11] <pitti> this will mostly help for everything !linux so far
[12:11] <pitti> we often get regressions which are due to a changed test dep
[12:11]  * apw goes back to being interested (rather than excited)
[12:11] <infinity> Heh.
[12:11]  * infinity goes back to being on vacation.
[12:12] <pitti> infinity: heh, do that; let's talk about details of merging T-T when you are back
[12:12] <infinity> pitti: *nod*
[12:12] <infinity> pitti: It's not urgent by any means.  If people choose to use the feature as it is, it works to put things in test-deps, and they can move them later if they feel the urge.
[12:12] <infinity> pitti: Mostly, I think it'll be "prettier" for essential and build-essential, basically.  But my taste isn't everyone's.
[12:13] <pitti> infinity: right now the goal is to trigger on the actual real test deps
[12:13] <infinity> pitti: Yeahp, but essential are deps of *all* tests, and build-essential is a magic dep.
[12:13] <pitti> we can *also* use this to reduce the hardcoded trigger lists in britney, but that's more of a side result
[12:13] <infinity> pitti: And if you want explicit testing when shadow changes, do you list shadow in your deps, or as a trigger in debian/control?
[12:13] <infinity> pitti: Both work, but the latter seems more "right".
[12:14] <pitti> infinity: you can set T-T: manually of course; you just (right now) lose the automatic value computed by dpkg
[12:14] <infinity> pitti: Or, in the glibc case, I have "build-essential, binutils, gcc, linux-libc-dev" (well, a bit more complex, but basically that) which is equally weird. ;)
[12:14] <pitti> infinity: but yes, if you explicitly test shadow, then adding shadow into d/t/c Depends: would do it
[12:15] <infinity> pitti: Right, I don't think it makes sense to set it manually until it merges.
[12:15] <infinity> pitti: But, as I said, people can just use test-deps and ignore T-T in debian/control entirely for now, so the feature works.
[12:15] <infinity> (Which is what I'm doing)
[12:16] <infinity> Off to find breakfast to fuel more vacation gaming.
[12:16] <infinity> Toodles.
[12:16] <pitti> apw: so to your question: "all linux kernels" isn't declarative, we always need a piece of code to answer that
[12:16] <pitti> apw: so I think this part will stay in britney for a while
[12:16] <pitti> (or forever)
[12:16] <infinity> apw: Yeah, I think the only way to make "all kernels" declarative would be to have an all kernels meta that pulls in all kernels for each platform. :P
[12:16] <infinity> Which probably isn't what you really want either.
[12:17] <infinity> Cause what you really want is to test foo-on-raspi2 *running* raspi2 on a raspi2 device.
[12:17] <infinity> Installing the raspi2 kernel in an lxc on a -generic device tells you nothing about runtime deps.
[12:17] <infinity> s/deps/tests/
[12:17] <infinity> Though it works for testing build-time dkms stuff, I guess.
[12:18] <infinity> apw: Like, ideally, we should sort out a way to run x86 tests twice, once with -generic installed and once with -lowlatency.
[12:19] <infinity> apw: And it just gets way trickier for ARM, cause we may also need to target kernel foo to worker bar to match hardware.
[12:19] <infinity> apw: Considerations for a future iteration. :P
[12:22] <pitti> infinity: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-autopkgtest-test-classes FYI
[12:22] <pitti> apw and I discussed/designed this a while ago, but it didn't get implemented yet
[12:25] <infinity> pitti: Fancy.  I will avoid reading it until next Tuesday. ;)
=== _salem is now known as salem_
=== jtaylor_ is now known as jtaylor
=== JanC_ is now known as JanC
=== hikiko|afk is now known as hikiko
[14:22] <ddellav> can i get an archive admin to promote python-yaql and python-monascaclient to main please? There were approved MIR's but no promotion: https://bugs.launchpad.net/ubuntu/+source/python-yaql/+bug/1586069 https://bugs.launchpad.net/ubuntu/+source/python-monascaclient/+bug/1590836
=== alexisb-afk is now known as alexisb
[14:22] <ubottu> Launchpad bug 1586069 in python-yaql (Ubuntu) "[MIR] python-yaql" [Undecided,Fix released]
[14:22] <ubottu> Launchpad bug 1590836 in python-monascaclient (Ubuntu) "[MIR] python-monascaclient" [Undecided,Fix released]
=== bigon_ is now known as bigon
[14:59] <kgunn> tjaalton: ping
[15:00] <kgunn> ug this network
[15:00] <kgunn> tjaalton: ping
[15:06] <brendand> is there anything i can do to allow nested vms when using adt-virt-qemu?
[15:06] <brendand> with autopkgtest
[15:22] <pitti> brendand: it should mostly Just Work™
[15:22] <brendand> pitti, the thing is i'm getting 'ERROR    Host does not support any virtualization options' from virt-install
[15:22] <pitti> brendand: as a convenience there is /dev/baseimage which is the (read-only) block device of the image you passed to autopkgtest-qemu
[15:24] <pitti> brendand: can you run "-- qemu -d ...]"? there should be some "Detected KVM capable Intel host CPU, enabling nested KVM" or similar for AMD
[15:36] <rbasak> kvm_intel.ko should be loaded. Or AMD equiv.
[15:43] <tjaalton> kgunn: pong
[15:44] <kgunn> tjaalton: hey there, so i'm trying to rebuild mesa on dragonboard
[15:45] <kgunn> tjaalton: if i use dpkg-buildpackage will gallium be built as a default?
[15:45] <kgunn> figured you might know
[15:46] <tjaalton> kgunn: i'm not sure, check rules
[15:46] <kgunn> k
[15:47] <tjaalton> or d/control, if it build-depends on it
[15:55] <tjaalton> uh.. it==llvm
[15:55] <rcj> pitti, looks like theres a kpartx regression in util-linux for 2.28.1-1ubuntu1 in yakkety bug# 1618525
[15:57] <kgunn> tjaalton: so from rules...it seems to suggest on arm64 it will build gallium
[15:59] <tjaalton> kgunn: right, iirc that was a fairly recent change
[15:59] <tjaalton> can't check atm
[16:00] <ddellav> Also if possible we need someone on the MIR team to promote designate: https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1543748 It's passed it's security review
[16:00] <ubottu> Launchpad bug 1543748 in designate (Ubuntu) "[MIR] designate" [High,New]
[16:00] <kgunn> tjaalton: no worries...thanks for pointers anyhoo
[16:01] <slangasek> infinity, kees, stgraber: tb meeting?
[17:29] <doko> seb128, Laney, tjaalton, Mirv: is there anything which should migrate to the release pocket before starting a test rebuild?
[17:30] <seb128> doko, not that I know of no...
[17:37] <Mirv> doko: yes http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src has the gold linker disabling for powerpc. there's no actions from Kubuntu side on the KDE autopkgtest issues, they nowadays usually ask to ignore those. I don't see anything terribly worrysome in there in those failures.
[17:39] <Mirv> while ignoring those, the qtdeclarative-opensource-src below would also migrate to release pocket which has two fixes already in stable phone images
[17:39] <doko> ok, waiting for these
[17:39] <Mirv> doko: those are not happening without overriding the autopkgtests though
[17:39] <Mirv> if any archive admin wouldn't mind ^
[17:40] <doko> jamespage, rbasak: anything you want to have in the release pocket from the server side before a test rebuild?
[17:40] <Mirv> so akonadi-calendar bluez-qt kalarmcal kdeclarative kglobalaccel libkdegames modemmanager-qt5 networkmanager-qt5  (and akonadi in the sense its s390x test seems stuck but is required)
[17:44] <acheronuk> I know yofel said we (kubuntu) simply don't have the resources ATM to address those failures
[17:46] <doko> Mirv: that's a release-team action, not an archive-team action. please could you ask on #ubuntu-release?
[17:51] <slangasek> Mirv: akonadi-calendar claims abi compliance checker passes on armhf and s390x but fails on x86 + ppc64el; would like to understand this failure to be sure it's really not an interface regression before overriding those failures
[17:52] <slangasek> bluez-qt is ok, non-ABI-changing symbol drop
[17:52] <slangasek> OTOH it's also easily fixed...
[18:01] <slangasek> Mirv: bluez-qt fix uploaded; the rest are all dh_acc regressions, which I would want to know the truth of before overriding
[18:02] <Mirv> doko: sorry, right
[18:03] <jamespage> ddellav, coreycb: hey ping me tomorrow and we'll go through the seed process for designate otherwise it will bounce straight back into universe
=== Guest43443 is now known as NCommander
[18:03] <coreycb> jamespage, ok that'd be good to learn about
[18:03] <doko> slangasek, Mirv: when were these dh_acc regressions run?
[18:03] <Mirv> slangasek: thanks for the bluez-qt, I also saw that's easy one. I've asked on #kubuntu-devel and associated people were pinged. they are low on people who know about the autopkgtests (which are inherited from Debian) right now though.
[18:04] <Mirv> doko: I think the relevant time frame might be "after libc update"
[18:04] <Mirv> compared to the earlier build + autopkgtests which was after GCC6 but before libc6
[18:05] <doko> Mirv: if these were run with earlier versions than gcc-6 6.1.1-12 then please retry
[18:07] <Mirv> doko: looks like gcc-6 6.2.0-1ubuntu12 (and gcc 4:6.1.1-1ubuntu2)
[18:07] <doko> hmm, ok
[18:07] <Mirv> at least for akonadi-calendar
[18:07] <Mirv> anyway, I can't stay a moment longer now, see you in 10h
[18:09] <doko> I love it that dh_acc is soo verbose
[18:09] <doko> xnox: ^^^ ;-P
[18:09] <slangasek> doko: several times, as linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
[18:09] <xnox> there was one bug that i filed that dh_acc was failing on qt stuff.
[18:10] <xnox> i didn't debug the failures again after doko reverted "upstream fix" to unbreak dh_acc
[18:10] <xnox> there might be gcc leaked symbols in the dh_acc output that need updating....
[18:10] <slangasek> xnox: do you have a bug # for that?
[18:10] <doko> that could be too
[18:11] <xnox> the reverted upstream fix or the guess that there are gcc leaked symbols since that?
[18:11] <xnox> the latter is just a wild guess, based on previous abi migration
[18:11] <xnox> (note we don't have an abi migration this time around, apart from some cases when we do)
[18:11] <xnox> (because upstream "fixed" abi tags in templates resolutions...)
[18:12] <doko> no, the reversion is just a removed inline attribute. the original issue that such files are not built with GCC 6 is not yet fixed
[18:32] <slangasek> xnox: a bug # for what you filed about dh_acc failing on qt stuff...
[18:33] <xnox> doko, ah.
[18:34] <xnox> it was not the bug that i filed.... let me recall where it was, it was pointed out to me by mirv/doko or some such.
[18:36] <doko> xnox, slangasek: the upstream issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72813 (and the r198733 commit is now reverted in the packages)
[18:36] <ubottu> gcc.gnu.org bug 72813 in c++ "[6/7 Regression] atomic header cannot be compiled into translation unit with -fkeep-inline-functions" [Normal,New]
[18:38] <xnox> and that's dh_acc with qt bug, beacause dh_acc uses that flag & qt things include atomic header eventually which fail to compile
[18:38] <doko> right, but that is now reverted
=== JanC is now known as Guest64850
=== JanC_ is now known as JanC
[20:12] <tjaalton> doko: I don't have anything
[20:17] <acheronuk> LP: #1609273
[20:17] <ubottu> Launchpad bug 1609273 in kxmlgui (Ubuntu) "kxmlgui fails autopkgtest (abi compliance)" [Undecided,New] https://launchpad.net/bugs/1609273
[20:17] <doko> tjaalton: ack
[20:28] <semiosis> bdmurray: adding test instructions to the bugs now
[20:29] <semiosis> bdmurray: done for bug 1565985
[20:29] <ubottu> bug 1565985 in livecd-rootfs (Ubuntu Xenial) "vagrant vb ubuntu/xenial64 cannot mount synced folders" [High,In progress] https://launchpad.net/bugs/1565985
[20:30] <semiosis> bdmurray: bug 1561250 already has a pretty concise description with how to reproduce/test
[20:30] <ubottu> bug 1561250 in livecd-rootfs (Ubuntu Xenial) "Xenial vagrant image is missing its hostname in /etc/hosts" [High,In progress] https://launchpad.net/bugs/1561250
[20:35] <bdmurray> semiosis: sudo echo is the testcase for bug 1561250?
[20:35] <ubottu> bug 1561250 in livecd-rootfs (Ubuntu Xenial) "Xenial vagrant image is missing its hostname in /etc/hosts" [High,In progress] https://launchpad.net/bugs/1561250
[20:35] <semiosis> sudo anything
[20:35] <bdmurray> okay, cool
[20:35] <semiosis> sudo does a localhost lookup, apparently
[20:35] <sarnold> lol "see the error ^^^^"
[20:36] <semiosis> s/localhost/current hostname/
[20:37] <semiosis> and how am I now able to edit the descriptions of those bugs I did not create?  did someone grant me that authority?
[20:37] <bdmurray> anybody can edit bug descriptions
[20:37] <semiosis> oh ha!  never noticed that
[20:53] <tdaitx> what are the usual suspects on a "Build killed with signal TERM after 150 minutes of inactivity"?
[20:53] <tdaitx> Some context: sometimes openjdk builds fail during the build and while I can see make's message "recipe for target blah/blah failed" + "dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2" on the ppa's build page the build isn't killed right away... While I can reproduce the failure itself, I am unable to reproduce this hang+timeout on a sbuild/chroot build, so I wonder where I should be looking into
[20:54] <tdaitx> slangasek, infinity, xnox, pitti ^ are you somewhat familiar with this?
[21:06] <cjwatson> tdaitx: That indicates that your build left a stale process behind that we didn't manage to clean up.
[21:06] <cjwatson> tdaitx: launchpad-buildd (unfortunately) currently uses sbuild in sudo mode, which isn't quite as good at cleaning up processes as the more usual schroot mode is.
[21:07] <cjwatson> tdaitx: I'd suggest instrumenting debian/rules to dump a process tree on error, at which point you should be able to see what's going on locally.
[21:07] <tdaitx> cjwatson, right, I will try that way then, thanks! =)
[21:15] <robert_ancell> slangasek, hey, who do I need to bribe to let snapd-glib into yakkety?
[21:15] <slangasek> robert_ancell: I take bribes
[21:16] <slangasek> robert_ancell: and I've been working through the NEW queue slowly ;)
[21:17] <robert_ancell> slangasek, it's gone up a bit in priority since we're going to need it to solve bug 1616943 properly
[21:17] <ubottu> bug 1616943 in gnome-software (Ubuntu Yakkety) "Can't auth against U1 in g-s" [High,Confirmed] https://launchpad.net/bugs/1616943
[21:17] <robert_ancell> i.e. will need to be SRUd back to Xenial
[21:18] <slangasek> ok
[21:18] <robert_ancell> slangasek, thanks
[21:19] <robert_ancell> slangasek, and a heads up, I'm currently finishing a new binary package for it "snapd-login-service" and once we're happy with the API I'll do a soname bump. Both of which will need archive admin approval right?
[21:20] <slangasek> yes
[21:21] <slangasek> binary review tends to be lighter weight though
[21:51] <robert_ancell> A question about multi-arch. I have a package (snapd-glib) that provides a library and a service. When I build the package the service is installed into /usr/lib/x86_64-linux-gnu/snapd-login-service but I get the lintian warning "E: snapd-login-service: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/snapd-login-service"
[21:51] <robert_ancell> Should I ignore the warning or should I change something in my packaging?
[21:51] <robert_ancell> Packaging in lp:~ubuntu-desktop/snapd-glib/ubuntu if anyone is interested
[21:52] <robert_ancell> (The service is installed into $(libexecdir) via autotools)
=== salem_ is now known as _salem
=== Guest31658 is now known as hloeung
[22:25] <slangasek> robert_ancell: maybe you want to build with --libexecdir=/usr/lib ?  I apologize for getting the default wrong in debhelper when adding multiarch support originally
[22:25] <robert_ancell> slangasek, that's what I was wondering. I noticed a number of packages seem to not be setting this. But if this is the correct behaviour I'll switch to that.
=== hloeung is now known as Guest28002
=== Guest28002 is now known as hloeung
[22:56] <slangasek> robert_ancell: please use the current debian/copyright spec, Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[22:56] <robert_ancell> slangasek, ok
[22:56] <robert_ancell> My copy-pasting is caught out again! ;)
[22:56] <slangasek> robert_ancell: also, what does it mean when you say 'License: LGPL-2 LGPL-3'?
[22:56] <slangasek> the same code is made available under either license?
[22:57] <robert_ancell> slangasek, yeah, that's what we ended up doing for liblightdm-gobject for some reason.
[22:57] <slangasek> robert_ancell: ok.  standard syntax would be 'LGPL-2 or LGPL-3', then
[22:57] <robert_ancell> And I just copied the same. I couldn't find our licence policy on the Wiki
[22:57] <robert_ancell> ok
[22:57] <slangasek> LDFLAGS+=-Wl,--as-needed
[22:57] <slangasek> not needed in Ubuntu
[22:58] <Unit193> slangasek: Might want to https that link, or lintian will give a warning.
[22:58] <slangasek> curiously, lintian didn't care about the http pointing to a wrong url ;)
[22:58] <robert_ancell> slangasek, has anything changed in the spec or is just the link wrong?
[22:59] <slangasek> robert_ancell: the spec has likely changed since the svn rev you reference, yes - and lintian will then tell you about it :)
[22:59] <robert_ancell> slangasek, lintian was only giving me that one warning about the libexec issue here
[23:00] <slangasek> robert_ancell: yeah, because non-standard debian/copyright is allowed... but if you use the standard it'll do much more analysis
[23:00] <robert_ancell> ah
[23:00] <slangasek> robert_ancell: anyway, none of these are blockers, so 0.8-0ubuntu1 source accepted
[23:01] <robert_ancell> slangasek, thanks! I'm prepping 0.10-0ubuntu1 right now and it will have those fixes.