[02:50] <cyphermox> Logan: I don't know anything special about pytsk, feel free to take it.
[04:56] <dupingping> Hello everybody.
[04:57] <dupingping> http://askubuntu.com/questions/704868/ubuntu-source-package-dependency-tree
[04:57] <dupingping> Please help me.
[05:02] <RAOF> dupingping: You're essentially asking about: https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[05:02] <dupingping> RAOF: yes, thank you.
[05:08] <RAOF> So the answer is roughly “Yes, there's some infrastructure for it, but it runs on Debian servers”
[06:54] <Logan> cyphermox: cool thanks!
[06:55] <pitti> Godo morning
[07:25] <goddard> when i plug in an xbox one controller my entire system crashes
[07:26] <goddard> or rather locks up
[07:38] <Mirv> 18h after publishing, this will take a while.. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src (plus the problems with some of the kde tests)
[07:39] <pitti> Mirv: yeah, it's "this triggered > 1.000 tests" plus one of our clouds got broken again, so still some backlog
[07:40] <Mirv> pitti: ok
[07:47] <dholbach> good morning
[07:47] <pitti> Mirv: if you are interested, you can follow the queues at http://autopkgtest.ubuntu.com/running.shtml
[07:48] <Mirv> thanks, bookmarking!
[07:49] <pitti> Mirv: I'll also adjust excuses.html to point to that for the "in progress" ones
[07:50] <Mirv> the more inter-linking the better
=== highvolt1ge is now known as highvoltage
=== cpaelzer_ is now known as cpaelzer
[08:38] <pitti> stgraber: hm, I put proxy info into /etc/environment, but "lxd-images import ubuntu --alias ubuntu" still can't talk to http://cloud-images.ubuntu.com apparenlty (same issue with images.linuxcontainers.org); is there some config option to make it use a proxy?
[08:41] <pitti> stgraber: I also tried addinv these as "env" to /etc/init/lxd.conf (now the lxd process does have them), but no luck
[08:42] <pitti> stgraber: ah, nevermind, it's apparently our proxy itself
[08:44] <pitti> no, still the same issue now; wget works, lxd import says "Failed to retrieve the GPG key"
[08:50] <zaytsev> doko: hi i don't know if you hear this often enough, but just to let you know that your toolchain work (gcc packages for ubuntu lts) is highly appreciated
[08:56] <dupingping> hi everybody.
[08:56] <dupingping> what is the NMU?
[08:56] <dupingping> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[09:02] <ginggs> i need help with autopkgtest please, julia passed once and not again http://autopkgtest.ubuntu.com/packages/j/julia/xenial/amd64/
[09:03] <ginggs> it seems like it in running out of memory, do try using fewer and fewer cores until it works?
[09:04] <zaytsev> dupingping: non maintainer upload
[09:04] <dupingping> zaytsev: yes, thank you very much.
[09:26] <pitti> Laney, apw: yes, precise VMs now suddenly only have main and universe, no restricted any more; so tests for restricted packages fail
[09:26] <Laney> pitti: I was looking, yeah
[09:26] <Laney> https://launchpadlibrarian.net/224624242/cloud-init_0.6.3-0ubuntu1.22_0.6.3-0ubuntu1.23.diff.gz seems very likely
[09:27] <pitti> Laney: ah!
[09:27] <pitti> Laney: we didn't get a new precise cloud image with that yet
[09:27] <pitti> Laney: but I had to update the nova setup script for the fact that in all other releases restricted and multiverse now get enabled by default, adn stop adding them a second time
[09:28] <pitti> Laney: so, we need to take that old precise image, dist-upgrade it (this will also speed up tests), and save it back
[09:28] <Laney> and it looks like it's *adding* restricted/multiverse anyway
[09:28] <pitti> Laney: do you want to do that for getting the exercise, or want me to?
[09:28] <pitti> Laney: you can even use the existing create-nova-image-new-release script, it's doing exactly that
[09:29] <pitti> Laney: warning, image-create is a bit brittle on lcy01 (surprise!), could take a retry or two
[09:31] <Laney> pitti: I'm not sure which old image you mean
[09:31] <pitti> ubuntu/ubuntu-precise-12.04-i386-server-20151117-disk1.img
[09:31] <Laney> because this is before this cloud-init?
[09:31] <pitti> oh wait, that's after that RU
[09:31] <pitti> SRU
[09:31] <Laney>  Published on 2015-11-12
[09:34] <Laney> it looks like create-nova-image-new-release is overwriting sources.list anyway though?
[09:34]  * Laney is missing something
[09:34] <pitti> Laney: yes it is, but we only use that for xenial
[09:34] <pitti> Laney: for the others we use the normal cloud images, and just a setup script to clean them up
[09:35] <pitti> WTH
[09:35] <Laney> that> c-n-i-n-r?
[09:36] <pitti> Laney: ah, indeed! so the precise cloud image does not have these apt sources
[09:36] <pitti> cloud-init 0.6.3-0ubuntu1.22
[10:12] <ginggs> didrocks: hi, i think the last remaining items for suitesparse transition, LP: #1518985, are no-change rebuilds of gegl and lp-solve in main
[10:12] <ubottu> Launchpad bug 1518985 in suitesparse (Ubuntu) "Please merge suitesparse 1:4.4.5-2 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1518985
[10:25] <didrocks> ginggs: let's see if the patch pilots will get it, otherwise, I'll handle it in my next shift :)
[10:27] <seb128> I can have a look later
[10:27] <seb128> I'm probably going to pilot this afternoon (or tomorrow)
[10:28] <ginggs> didrocks, seb128: thanks!
[10:30] <didrocks> doko: seems like your twisted sync creates some dist-upgrade issues
[10:33] <cjwatson> didrocks: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806167
[10:33] <ubottu> Debian bug 806167 in python-twisted "python-twisted fails to upgrade because of missing/incorrect replaces/breaks" [Grave,Open]
[10:33] <didrocks> yeah, corresponding ubuntu one: bug #1521616
[10:33] <ubottu> bug 1521616 in twisted (Ubuntu) "package python-twisted-core 15.5.0-1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/conchftp.1.gz', which is also in package python-twisted-conch 1:15.2.1-1ubuntu2" [High,Triaged] https://launchpad.net/bugs/1521616
[10:34] <didrocks> Tue, 24 Nov 2015  starting to get hold
[10:34] <didrocks> old*ù
[10:34] <cjwatson> didrocks: Well, it was closed in between there, but reopened yesterday
[10:35] <didrocks> Replaces: python-twisted-conch (<< 15.4.0-1),
[10:36] <didrocks> yeah, it should be at least 15.2 (if not before)
[10:36] <cjwatson> didrocks: no, see the end of the Debian bug, it's a missing epoch
[10:36] <didrocks> cjwatson: ah, indeed :)
[10:37] <didrocks> doko: are you on this? I would prefer to not upload a fix to ubuntu only (but can do this and attach a patch to the bug report if you prefer)
[10:37] <didrocks> thanks cjwatson
[10:39] <caribou> Should rsyslog still bother about /dev/xconsole ?
[10:40] <caribou> it has been disabled & put as an example in upstream debian newest package
[11:27] <doko> didrocks, is this with -2 as well? -3 is still in NEW
[11:29] <didrocks> doko: yeah. Ah good, the fix is in NEW, just waiting then :)
=== _salem is now known as salem_
[13:16] <caribou> When removing specific packages during a merge (i.e. packages that depends on Universe), should the related files (README.blah, etc) be removed from the package or just left there ?
[13:19] <rbasak> caribou: it's fine to leave things in the package's source. For an Ubuntu delta, the smaller the delta the easier it is to manage, so I'd advocate leaving it there.
[13:19] <rbasak> caribou: in the source that is.
[13:19] <caribou> rbasak: thought so, I just wanted to confirm
[13:20] <rbasak> Not sure about leaving things in binary packages since that could be confusing for users.
[13:20] <caribou> rbasak: understood
[13:42] <cpaelzer> rbasak: smb: I need some advise - look at LP Bug 1521289
[13:42] <ubottu> Launchpad bug 1521289 in dpdk (Ubuntu) "DPDK with Xen" [Medium,Triaged] https://launchpad.net/bugs/1521289
[13:42] <cpaelzer> rbasak: smb: XEN_PMD builds fine after my fix in amd64, but not in i386
[13:43] <cpaelzer> rbasak: smb: I can't spend the effort to fix all othe XEN code in DPDK
[13:43] <cpaelzer> rbasak: smb: so my question qhat would usually be done - dropping XEN_PMD or would it be ok to only build it in amd64
[13:43] <cpaelzer> rbasak: smb: and by that create a functional difference betweeni386 and amd64?
[13:44] <rbasak> I wonder if it is an upstream bug that stops XEN_PMD working on i386 altogether, or is it our combined library choice that makes that happen?
[13:44] <cpaelzer> rbasak: upstream issue
[13:44] <cpaelzer> rbasak: I fixed the "failing with combined library" two hours ago
[13:45] <smb> cpaelzer, Without much time to read about this I would tend to not make things different
[13:45] <rbasak> Good job!
[13:45] <rbasak> I'd want upstream to fix the issue or make the build conditional automatically, rather than us.
[13:46] <rbasak> If that's not possible or wouldn't be in time, then I'd be OK with carrying a delta to do it in packaging, but as always I don't like us to be carrying deltas so only if it's really important to Ubuntu.
[13:46] <cpaelzer> rbasak: so you'd suggest another upstream patch that makes it conditional in dpdk upstream instead of our packaging
[13:46] <rbasak> As we're primarily KVM-focused, I'd say it's not important enough.
[13:46] <cpaelzer> rbasak: yeah that part of "not important" is why I don't want to fix the code for 32bit
[13:46] <rbasak> cpaelzer: I suggest that if upstream are willing to carry that patch then we'll use it by default, so I'd be fine with that with my Ubuntu hat on. I'm not sure if upstream want that or just want it fixed though.
[13:47] <rbasak> If upstream say that they want the bug fixed rather than worked around then that's perfectly reasonable. If I were upstream I'd probably say that, unless there's something fundamental about the feature that'll mean that it will never work or is obtuse on i386.
[13:47] <cpaelzer> rbasak: lets see if there is a simple makefile fix to disable it on i386 in upstream dpdk and let them discuss it on that
[13:50] <smb> cpaelzer, Would be helpful if you had any log about the failure with i386 _in_ the bug
[13:50] <cpaelzer> smb: "cast from pointer to integer of different size" we all have seen that way too often
[13:51] <cpaelzer> smb: I didn't want to fill the bug with only related info
[13:54] <smb> cpaelzer, So more or less the whole thing not well written. There is another thing I was wondering and that is whether this is really still required with newer dpdk where we also do not need other kernel modules (at least the dom0 part)
[13:54] <cpaelzer> smb: I already refused to include the kernel module for the dom0 part
[13:54] <smb> Might be something to ask upstream
[13:55] <cpaelzer> smb: this is about the XEN_PMD
[13:56] <smb> Yeah, but I don't know for sure anything about that either. And I could not promise to have time to figure it out
[14:00] <smb> cpaelzer, Most likely that part is only needed for Xen PV guests (other than dom0). Dom0 itself has access (usually) to pci device (that part I did check).
[14:00] <smb> So there uio-pci-generic should in theory be an option
=== barry` is now known as barry_
[14:41] <sil2100> cyphermox: hey! Just reminding about https://code.launchpad.net/~sil2100/network-manager-applet/merge_1.0.6_debian/+merge/279012 once you have a free moment ;)
[14:41] <sil2100> cyphermox: since I don't see robert_ancell around
[14:41] <cyphermox> oh, of course, thanks!
[14:51] <cyphermox> sil2100: approved. do you want to do the honours? ;)
[14:52] <sil2100> cyphermox: \o/ Sure, thanks :)
[14:52]  * cyphermox is totally not giving you TIL this way ;)
[14:59]  * sil2100 prepares upload and hopes nothing explodes
[15:31] <cyphermox> sil2100: are you merging the branch too or should I do it?
[15:31] <sil2100> cyphermox: I'll merge it after I dput :)
[15:31] <cyphermox> oh ok :)
[15:33] <seb128> cyphermox, sil2100, current version is 1.0.8 and did you see that robert_ancell had branches on bug #1467267 ?
[15:33] <ubottu> bug 1467267 in network-manager-pptp (Ubuntu) "Please sync to 1.0.6 from Debian (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1467267
[15:34] <sil2100> seb128: I don't see a network-manager-applet branch for 1.0.6 there
[15:43] <cyphermox> mdeslaur: hey
[15:43] <mdeslaur> hi cyphermox
[15:43] <cyphermox> such a crowd here this morning...
[15:44] <mdeslaur> yeah, oddly quiet
[15:53] <kirkland> didrocks: hi
[15:56] <didrocks> hey kirkland!
[15:56] <kirkland> didrocks: howdy
[15:56] <kirkland> didrocks: so I'm looking at this desktop icon problem
[15:56] <didrocks> kirkland: good good, yourself? :)
[15:57] <didrocks> yep, I guess
[15:57] <kirkland> didrocks: fine thanks
[15:57] <kirkland> didrocks: so I've cloned your source from git
[15:57] <didrocks> did you see my answer on the Exec=
[15:57] <kirkland> didrocks: I don't see your desktop file in there
[15:57] <kirkland> didrocks: yes, just trying that now
[15:57] <didrocks> kirkland: oh, I didn't push it, that was more a "we should try this"
[15:57] <kirkland> didrocks: it's not ideal, as I was previously supporting any terminal that someone wanted to run
[15:57] <kirkland> -Exec=env TERM=xterm-256color byobu
[15:57] <kirkland> +Exec=gnome-terminal --app-id us.kirkland.Terminals.byobu -e byobu
[15:58] <didrocks> kirkland: yeah, the gnome-terminal -> gnome-terminal-server changed impacted quite a bunch
[15:58] <kirkland> didrocks: so that someone could easily use konsole, xterm, uxvt, or whatever
[15:58] <kirkland> didrocks: so you have the same problem with weechat, then?
[15:58] <didrocks> hum, larsu had a look at gnome-terminal-server when the issue started to happened
[15:59] <didrocks> kirkland: yeah, I'm bound to gnome-terminal (it's a local desktop file)
[15:59] <didrocks> maybe larsu would have an idea to have this more generic ^
[15:59] <didrocks> kirkland: and yeah for g-t to not support backward compatibility :/
[15:59] <didrocks> (the wrapper is Laney's work, thanks to him!)
[15:59] <kirkland> didrocks: is this really a g-t problem?
[16:00] <kirkland> didrocks: I thought someone said it might be in bamf
[16:00] <didrocks> kirkland: yeah, they separate client and server
[16:00] <didrocks> so basically all client goes to one server if you don't specify anything
[16:00] <didrocks> so you only have one instance to match against
[16:00] <didrocks> (what bamf is doing…)
[16:00] <kirkland> didrocks: hrm
[16:01] <didrocks> if I'm correct, --app-id enables on the backend to have another g-t-s session
[16:01] <didrocks> and so another process to match, which has a different name
[16:01] <kirkland> didrocks: okay, so I can use anything in --app-id?
[16:01] <kirkland> didrocks: I tried to match your format
[16:01] <kirkland> didrocks: how does that link up with the right icon, then?
[16:01] <kirkland> didrocks: and, is that going to work, if someone uses my package backported in a ppa to, say, trusty?
[16:02] <didrocks> kirkland: that's a good question, we did this for backward compatibility (IIRC, it's not supported upstream anymore of something along that)
[16:02] <didrocks> kirkland: I'm afraid the trusty version doesn't have g-t-s support
[16:02] <didrocks> TBH, there is another way
[16:02] <didrocks> like shipping a .desktop and a service-like file
[16:02] <didrocks> (still bound to g-t)
[16:03] <kirkland> didrocks: I'm game for trying that
[16:03] <didrocks> but I would let the gnome guys to answer on this ^
[16:03] <kirkland> didrocks: can you point me to another example?
[16:03] <didrocks> I didn't look at this closely myself
[16:03] <didrocks> kirkland: looking for some if I can find any (or old discussion)
[16:03] <didrocks> but desrt and larsu would be way better ref than I
[16:04] <didrocks> kirkland: I'm still unsure how you would be able to ship a solution that isn't term-specific…
[16:04] <kirkland> didrocks: right
[16:04] <didrocks> (which isn't ideal)
[16:04] <kirkland> didrocks: well, I'm willing to do that if I have to, I guess
[16:04] <kirkland> didrocks: to be honest, trying to support konsole and other terminals is kind of a pain in the ass
[16:04] <kirkland> didrocks: when 99% of people just use the default terminal
[16:04] <didrocks> ah? you have other special cases on them?
[16:04] <didrocks> yeah…
[16:05] <kirkland> didrocks: no, just weird bugs that come up
[16:05] <didrocks> tmux bugs?
[16:05] <didrocks> or konsole ones?
[16:05] <kirkland> didrocks: people complaining about fonts or characters or colors that don't look good in some esoteric terminal application
[16:05] <didrocks> oh yeah, I can see that, or people changing profiles… :)
[16:07] <kirkland> didrocks: anyway, I had every intention on reverting that wmclass setting, as I clearly understood that wasn't the right fix
[16:08] <didrocks> kirkland: argh, desrt's pastebin expired…
[16:08] <kirkland> didrocks: but, I was trying to draw some attention to the real bug at the heart of this
[16:08] <larsu> haha
[16:08] <didrocks> kirkland: yeah, hence my "sorry" on the bug report, but that wasn't really liveable on xenial :)
[16:08] <larsu> didrocks: what's the exact question?
[16:08] <didrocks> larsu: g-t-s oh my g-t-s :p
[16:08] <didrocks> larsu: kirkland wants to match byobu when byobu is running in his terminal
[16:08] <kirkland> didrocks: and the fact that I think it's a major bug that ANY application's .desktop file can override gnome-terminal's icon
[16:08] <didrocks> the interesting part is:
[16:08] <larsu> Laney wrote a wrapper that makes the new g-t work like the old one (as seen fro mthe command line)
[16:09] <didrocks> byobu can run multiple terminals
[16:09] <didrocks> (like konsole, g-t…)
[16:09] <didrocks> so, I was going to point him to the --app-id to match correctly only byobu instances
[16:09] <didrocks> (with Laney's wrapper)
[16:09] <didrocks> is there anything better?
[16:09] <kirkland> didrocks: I could see a malicious application putting a potentially offensive image in your launcher :-o
[16:09] <larsu> make a profile, install a .desktop and .service file
[16:09] <larsu> you know the drill, no?
[16:09] <didrocks> kirkland: really agreed
[16:10] <didrocks> larsu: yeah, is there any example for this?
[16:10] <larsu> kirkland: it can do that without gnome-terminal as well, no?
[16:10] <didrocks> last one for desrt's pastebin
[16:10] <didrocks> it expired
[16:10] <didrocks> was*
[16:10] <larsu> oh ok, let me paste my irssi
[16:10] <kirkland> larsu: didrocks: can you show me how to create a .service file?
[16:10] <didrocks> kirkland: but yeah, agreed on a fundamental issue there :/
[16:11] <larsu> kirkland: http://paste.ubuntu.com/13625283/
[16:12] <larsu> I think you need to restart your session to make this work, but I'm unsure
[16:15] <kirkland> larsu: so, where would I install that .service file, at the system level?
[16:15] <kirkland> larsu: I see in your pastebin it's in your .local
[16:16] <larsu> kirkland: /usr/share/dbus-1/services
[16:21] <bdmurray> mvo: Can the fix for bug 1267059 be SRU'ed or does it need to be a backport?
[16:21] <ubottu> bug 1267059 in unattended-upgrades (Ubuntu Trusty) ""Unattended-Upgrade::Remove-Unused-Dependencies" does not work " [High,Triaged] https://launchpad.net/bugs/1267059
[16:23] <mvo> bdmurray: hello, sorry, I think you asked me before and I failed to reply :/ I thnk its fine to sru it, a backport is probably slightly less work as it should just build/work on 14.04
[16:24] <bdmurray> mvo: looking at the git commit log I had a hard time sorting out which commit ids are important. Do you happen to know?
[16:29] <mvo> bdmurray: I can probably find out which ones are the important ones
[16:29] <mvo> bdmurray: I can look over them after dinner
[16:29] <bdmurray> mvo: that'd be great
[16:31] <kirkland> larsu: okay, I need a little help getting the .service working
[16:32] <kirkland> larsu: I made the changes, built a package, installed, but not quite working
[16:33] <kirkland> larsu: http://paste.ubuntu.com/13625646/ <--- that's what I have so far
[16:49] <larsu> kirkland: what's the problem? The server process doesn't get started at all?
[16:49] <larsu> please use reverse domain names ;)
[16:52] <seb128> mardy, hey
[16:52] <seb128> when trying to add a google account to uoa (unity7, xenial) in a guest session I get that warning
[16:52] <seb128> (evolution-source-registry:15044): module-ubuntu-online-accounts-WARNING **: ubuntu_online_accounts_got_userinfo_cb: Failed to create ESource collection for AgAccount
[16:52] <seb128> is that a known issue?
=== jtaylor_ is now known as jtaylor
[17:02] <kirkland> larsu: ugh, those are so ugly :-)
[17:04] <larsu> heh
=== Pici is now known as Guest87554
=== Guest87554 is now known as Pici
[17:56] <kirkland> larsu: okay, so I have it working in 15.10/16.04, but byobu.desktop no longer works in 14.04
[17:59] <kirkland> larsu: it's the Terminal=True that's the problem
=== sarnold_ is now known as sarnold
[18:46] <mardy> seb128: no, that's not a known issue, at least to me :-)
=== rharper` is now known as rharper
=== salem_ is now known as _salem
=== s1aden is now known as sladen
[20:51] <juliank> I'm wondering: Is "debian/patches/gcc46-compatibility: don't break with old compilers and -DGNU_EFI_USE_MS_ABI." for gnu-efi still needed in xenial, or could that be synced now?
[20:52] <juliank> If it cannot be dropped, what is still using gcc 4.6 and why?
[20:53] <juliank> slangasek: You wrote the patch, what's your opinion?
[20:55] <slangasek> juliank: it's carried because we have SRUed newer versions of gnu-efi to older releases to ensure that the shim binary we ship there is rebuildable in the target distribution (for policy reasons, even though we do a binary copy)
[20:56] <slangasek> juliank: so e.g. precise has 3.0i, but precise-updates has 3.0u; and while we haven't SRUed any later version farther back than vivid yet, we did SRU 3.0.2 to vivid-updates on top of 3.0u in vivid release
[21:00] <juliank> So, if I see that correctly, the patch will be needed until precise EOL in late 2017?
[21:01] <juliank> (precise being the only distro with gcc older than 4.7)
[21:03] <juliank> I could merge the patch upstream though, so we do not have to keep a delta and could have gnu-efi automatically synced
[21:04] <juliank> (putting it into ubuntu.series, as we have no actual use for that in Debian)
[21:08] <juliank> Oh hi mvo, do you have a progress update on the apt transition?
[21:08] <mvo> juliank: hi, not yet unfortunately
[21:08] <juliank> :(
[21:08] <mvo> juliank: there is code that calculcated the expected entires from a Release file and uses that to try to give a smooth progress but …
[21:09] <mvo> juliank: I will look tomorrow, its not worse than the old one I think
[21:09] <mvo> but a bit annoying as I was really sure it would be (much) better :/
[21:09] <juliank> mvo: I meant about the apt 1.1 transition in Ubuntu, not about the update progress issue :)
[21:09] <mvo> anyway, tomorrow
[21:09] <mvo> juliank: ohhh, sorry
[21:10] <mvo> juliank: its looking really good I think, I need to double check, PK is missing obviously but the rest should be in
[21:10] <juliank> OK
[21:20] <dobey> hmm, is there some command i can run to list all the individuals whom have rights to upload a specific package?
[21:22] <cjwatson> dobey: edit-acl in lp:ubuntu-archive-tools can answer this kind of question, except you have to expand teams yourself.  edit-acl -s <source package> query
[21:30] <dobey> ah, and that's not packaged i guess. thanks
[21:53] <slangasek> juliank: precise EOL is in early 2017, but yes
[21:54] <slangasek> juliank: ftr I find per-distro patch files counterproductive; it just means that there's code in the Debian repo that not only hasn't been build-tested, it hasn't even been unpack-tested
[21:55] <juliank> Well, the latter part could be checked by running patch --dry-run
[21:56] <slangasek> juliank: but unless you make that check part of your testing process, having the package in sync with Debian isn't really beneficial to Ubuntu
[21:57] <slangasek> also I find it distasteful that dpkg-source -x would have different behavior on different distros
[21:58] <juliank> I can also apply it generally, there's no gcc 4.6 in Debian anymore, so it won't hurt there, and we'd all build the same code
[21:58] <slangasek> that would be fine with me, of course
[22:01] <juliank> I'll do that then after the current upload migrated to testing, together with disabling x32 support which does not build at all.
=== elopio_ is now known as elopio