[05:46] <cpaelzer> good morning
[05:56] <slangasek> rbasak: mariadb-10.0 seems to have a lovely SIGBUS on armhf at build time, that makes default-libmysqlclient-dev uninstallable
[06:37] <pitti> Good morning
[06:50] <cpaelzer> good morning Pitti
[06:53] <pitti> hey cpaelzer, how are you?
[06:56] <cpaelzer> pitti: fine fighting a weird FTBFS - just the right thing for a foggy morning
[06:56] <cpaelzer> pitti: I hope you are good as well
[06:56] <cpaelzer> pitti: I realized we see again in a few weeks
[06:56] <pitti> cpaelzer: Fails To Be Fair and Sunny?
[06:56] <pitti> cpaelzer: I am, yes!
[06:57] <pitti> cpaelzer: indeed, next week Bucharest and start of Dec the cloud sprint
[06:57] <cpaelzer> The Dec one for me
[08:19] <rbasak> slangasek: ah. I want a delta to switch back to MySQL in Ubuntu anyway, so I'll do that now.
[08:22] <LocutusOfBorg> thanks rbasak
[08:23] <LocutusOfBorg> I retried once again mariadb
[08:23] <LocutusOfBorg> it failed even on amd64 now
[08:23] <LocutusOfBorg> isn't it possible to avoid such delta?
[08:26] <rbasak> Exactly which delta do you mean?
[08:27] <rbasak> The one against mysql-defaults?
[08:27] <rbasak> I suppose I could dynamically adjust the control file. It seems more effort though.
[08:28] <rbasak> I would like to do it eventually, but for the moment it seems easier with a delta.
[08:40] <LocutusOfBorg> I think fixing mariadb-10 can save a delta and time
[08:41] <LocutusOfBorg> I'm talking about stuff like gambas3, vtk6 and so on
[08:43] <rbasak> I don't follow.
[08:48] <LocutusOfBorg> they are entangled with mariadb-10 because of mysql-default
[08:54] <Laney> If you fix mysql-defaults to be installable then things start being buildable
[08:57] <Laney> rbasak: are you aware of https://launchpadlibrarian.net/290831960/upload_11078266_log.txt ?
[08:57] <rbasak> No, I only just noticed that my upload was rejected. Thanks
[08:57] <Laney> from a quick peruse, looks like mysql should stop building that package
[09:01] <rbasak> Laney: yes, that's the plan. I didn't think I needed to do that right now to fix mysql-defaults though, as that should go higher?
[09:01] <rbasak> Just my next mysql-5.7 upload.
[09:02] <rbasak> (which is only a tiny delta from what is in sid)
[09:02] <rbasak> This MySQL/MariaDB stuff is messy :-(
[09:04] <Laney> rbasak: It means that mysql-5.7 can't be uploaded as it tries to publish an older version of a binary package
[09:04] <rbasak> Yes, I will fix that.
[09:05] <Laney> thanks!
[09:12] <Son_Goku> tvoss, did you have any luck reproducing my issue with mir builds?
[10:50] <cpaelzer> I'm currently on fixing a FTBFS caused by us having default ldflag "-Bsymbolic-functions" which Debian does not - to complete my personal Ubuntu history lesson I wanted to ask if anybody has a pointer/link to the reasoning to add it for us (it seems we have this for ages - 13.10 I think)
[10:53] <jbicha> cpaelzer: not quite what you're asking but in gedit's rules file, we use   export DEB_LDFLAGS_MAINT_STRIP := -Wl,-Bsymbolic-functions
[10:56] <cpaelzer> jbicha: yeah I found that in fox1.6, tango and lapack
[10:56] <cpaelzer> jbicha: my fix is already based on that - just wanted to complete my understanding of the whole thing
[10:57] <cpaelzer> jbicha: actually IMHO the best example is in fox1.6 is written by doko in a way to make it debianizable
[10:57] <cpaelzer> jbicha: useful in case you want to get to no-delta with a package having just that left
[10:58] <ginggs> cpaelzer: https://wiki.ubuntu.com/ToolChain/CompilerFlags links to an libxfont1 bug with some explanation
[10:58] <cpaelzer> ginggs: thanks, that seems to be a bookmark worthy page for packaging in general
[12:33] <arges> rbasak: did debootstrap get SRUd? (saw the message from earlier)
[12:38] <rbasak> arges: powersj has bug 1636583. Not sure if that's ready for sponsorship yet (he hasn't subscribed ~ubuntu-sponsors)
[12:40] <arges> rbasak: yea no debdiffs, but whats in the ppa seems correct
[12:41] <rbasak> He'll be online in ~3 hours I think.
[12:41] <arges> ok
[12:50] <LocutusOfBorg> jbicha, please syncpackage lirc -d experimental -s costamagnagianfranco
[12:50] <LocutusOfBorg> thanks
[12:52] <LocutusOfBorg> ops -f
[13:00] <dupondje> slangasek: https://packages.qa.debian.org/f/freetds.html guess this should get updated once :) I see your maintainer of it
[13:00] <dupondje> its actually quite broken atm :(
[13:45] <rbasak> src:mysql-defaults MIR should be a no-op. mysql-common is moved from a package already in main, and the rest is just metapackages.
[13:59] <powersj> rbasak: arges: will make the debdiffs shortly
[14:18] <JordiGH> What's the trust model for a PPA? Anyone can setup a PPA and possibly server malware from it, right?
[14:19] <JordiGH> *serve
[14:19] <rbasak> Correct. Though you can only upload "source", somebody could call a malicious binary "source" and upload that.
[14:19] <rbasak> It would be a code of conduct violation of course, if that matters. In other words, it'd be removed upon notification I expect.
[14:20] <JordiGH> I see, thanks.
[14:20] <xnox> JordiGH, one must sign up for launchpad account; sign code of conduct; and upload open-source code only; but that's all procedural questions, indeed one can serve mallicious code; however when discovered, it would be blocked / removed.
[14:21] <JordiGH> How is the source-only thing enforced? Files with null bytes are rejected?
[14:21] <rbasak> It isn't enforced.
[14:21] <xnox> JordiGH, nothing is enforced.
[14:22] <xnox> (there are no technological barriers in place, any valid source package is accepted, and it should manage to generate binary debs)
[14:22] <xnox> JordiGH, are you looking to host proprietary software with viruses? =)
[14:23] <JordiGH> No, just purely hypothetically. Someone in #emacs got an Emacs from some PPA and it seems to be misbehaving. It's more likely that it was an error, not malice. Just curious how likely malice was possible.
[14:24] <xnox> JordiGH, at one point the free UbuntuOne accounts hosted the leading pirated warez & movies share site contents in Turkey.
[14:24] <Unit193> Hah really?  Niiice.
[14:25] <JordiGH> Heh, well, from where I'm standing, filesharing isn't malice, although it's not nice to overwhelm Ubuntu's infrastructure with something it wasn't intended for.
[14:25] <xnox> JordiGH, emacs in the ubuntu archive is good enough for most things. things that misbehave are possibly ELPA installed packages, or nightly builds which be definition are asking for trouble =)
[14:25] <xnox> JordiGH, yeah, our sysadmins noticed the bill for all the download traffic.
[14:46] <powersj> rbasak: uploaded debdiffs, however not sure if that really captured the fact that the files are symlinks :\
[14:47] <rbasak> powersj: ah, in that case do you want to stick the source packages somewhere I can download them?
[14:48] <rbasak> eg. people.canonical.com. Or alternatively I can use the PPA if the upload is identical except for the version numbers.
[14:48] <powersj> I can upload the new versions to the ppa real quick that way you don't have to mess with the version number, does that work?
[14:49] <rbasak> That has a tendency to mess up the PPA
[14:49] <rbasak> Well, technically it won't, but any users of the PPA won't upgrade to the archive versions then.
[14:49] <powersj> ah good point
[14:50] <rbasak> I'm quite happy to mangle the version numbers. It doesn't really take any more effort.
[14:50] <powersj> rbasak: ok then lets do that
[14:50] <rbasak> OK looking
[15:02] <rbasak> powersj: uploaded. yakkety needed to be 2.1, which I only noticed after uploading, so I uploaded a second one of 2.1. ubuntu3 will need to be rejected since it already exists in zesty.
[15:02] <rbasak> arges: ^ still around?
[15:03] <powersj> rbasak: my bad forgot to check zesty version
[15:03] <caribou> I have yet another question about the samba static library story : given that I created pam_winbind-static & libwinbind-client-static libraries to be used to link winbind, those libraries should also be included in their respective package along with their shared counterparts right?
[15:04] <caribou> pitti: this is the question I asked you yesterday
[15:04] <pitti> caribou: why would we ship the static (.a) libraries?
[15:05] <caribou> pitti: that's what I'm wondering now; it was not in the initial debdiff
[15:06] <pitti> caribou: I would never ship a static .a library unless there is a very convincing reason to do so
[15:07] <caribou> pitti: the reason behind the use of static lib is to avoid ABI breakage when samba upgrade samba-libs & libpam-winbind/libnss-winbind are not yet upgraded
[15:08] <pitti> caribou: yes, I know, but that only applies to linking the built PAM module against it
[15:08] <pitti> which is all internal to the package build -- there is no reason to also ship that built .a file
[15:08] <pitti> which is what your question was about, no?
[15:08] <caribou> pitti: yeah, I had second thoughts so I prefer to ask
[15:09] <caribou> pitti: thanks for confirming my guess
[15:09] <pitti> caribou: i. e. the package list shouldn't change, just that the PAM modules will get bigger and drop their dependencies to libsmb
[15:10] <caribou> pitti: thanks, was being too cautious
[15:10] <pitti> caribou: no worries, better safe than sorry when it comes to stable updates :)
[15:10] <caribou> pitti: especially with samba & winbind; don't want to have all those users unable to login
[15:29] <slangasek> rbasak: ok, I thought it was meant to be switching back, wondered what was happening there... packages have been building against the wrong implementation for 5 days now, we'll need to rebuild those the other way I guess?
[15:32] <rbasak> slangasek: yeah I missed that I needed to apply a delta when autosync got turned on, sorry. Yes, we need to rebuild the other way. I think LocutusOfBorg is taking care of it.
[15:33] <slangasek> ok
[15:33] <slangasek> fwiw it wasn't autosync
[15:33] <rbasak> Ah
[15:34] <LocutusOfBorg> slangasek, I did the
[15:34] <LocutusOfBorg> them
[15:34] <LocutusOfBorg> they are listed in -release
[15:35] <LocutusOfBorg> I BTW just looked for packages in update_excuses with "depends mariadb-10 (not considered)"
[15:35] <slangasek> yep
[15:35] <LocutusOfBorg> not sure if we have something that has never been rebuilt, and then not shown on that page
[15:41] <rbasak> LocutusOfBorg: based on apt-cache rdepends libmariadbclient18 on zesty-proposed, I agree with that list.
[16:39] <jbicha> bdmurray: I looked at https://errors.ubuntu.com/problem/18b5e69225bd63387d958707585693d52919b7c4 and all 3 16.10 reports appear to be from
[16:39] <jbicha> /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so which is shipped by gnome-shell
[16:41] <CliveGerard> Hi, it looks like I need some help - I've logged on to UbuntuOne and tried to create a "derivative subpage" - It seems to create it but wont let me edit it! Do I need special permission?
[16:42] <CliveGerard> Is this a question for ubuntu-doc or somewhere else?
[17:04] <jbicha> bdmurray: I figured out how to duplicate the bug with both the old and new versions of webkit2gtk so please set phased-updates to ignore that error, see bug 1636616
[17:11] <bdmurray> jbicha: Will do, thanks for digging into that!
[17:55] <hallyn> mwhudson: hi, do you guys plan to backport golang 1.7 to xenial?  (I assume not, but have to start somwhere with my questions :)
[17:57] <hallyn> mwhudson: apparently there is a bug with non-string keys serialized to json which is fixed in 1.7 (i'm not sure which commit it is unfortunately, only heard second-hand and haven't dug in yet); wondering how much work i'll have to do for that,
[17:57] <hallyn> mwhudson: or whether i should just install from upstream and forget the golang package
[18:19] <ogra_> barry, (noticing you are not in #snappy i'll ask here) ... did you ever test one of the dailies on your BBB ? i.e. http://people.canonical.com/~ogra/snappy/all-snaps/daily/
[18:19] <ogra_> i tested it last about 10 days ago but had none of the issues you see
[18:19] <ogra_> (it is a bit irritating that you run into so many probs)
[18:20] <barry> ogra_: i haven't tested any of the dailies, i shoudl do that (and get on #snappy
[18:20] <ogra_> the oops you see should actually be fixed in edge
[18:21] <ogra_> we have a new linux-bbb snap there
[18:21] <barry> ogra_: i did build with ubuntu-image -c edge
[18:21] <ogra_> hmm
[18:22] <ogra_> barry, in any case the oops comes from the onboard NIC, if you use a USB NIC it should be fine
[18:23] <ogra_> (that is how i worked around it until ppisati landed the fix)
[18:23] <barry> ogra_: ah, that must be why dhcp isn't working then?
[18:23] <tdaitx> question about packaging a GPLv2 binary that links to GPLv3+ binutils: a developer I know asked me how to package hsdis for openjdk due to license conflicts... hsdis is made of 2 GPLv2 files that rely on binutils (GPLv3) for debugging, so it is clear that building and distributing that binary is trouble, are there other ways to package it that would avoid such trouble? maybe something similar to dkms where the binaries are build when the user
[18:23] <tdaitx> installs it? are there packages with a similar story?
[18:23] <ogra_> right
[18:23] <barry> ogra_: i don't have a usb nic.  but let me try the daily
[18:50] <barry> ogra_: today's daily still kernel oopses
[18:51] <ogra_> weird, it didnt for me
[18:51] <ogra_> (but that was when i tested the proposed kernel)
[18:51] <ogra_> i'll test again tomorrow
[18:51] <barry> ogra_: cool
[18:51] <ogra_> barry, but no cloud-init i hope :)
[18:51] <barry> ogra_: no cloud-init!
[18:51] <ogra_> yay
[18:51] <barry> progress
[18:52] <ogra_> i'll have to check with paolo why the patch isnt there then
[18:52] <barry> ogra_: cool, thanks.  let me know.  i'm going to move on to other things for the rest of the day
[18:52] <ogra_> +1
[18:52] <ogra_> (unless you want to fix the oops ;) )
[20:04] <jbicha> bdmurray: how do I find my errors.ubuntu.com System Identifier to see errors reported from this computer?
[20:08] <bdmurray> jbicha: /var/lib/whoopsie/whoopsie-id
[20:09] <infinity> tdaitx: Which part of binutils does it link against?
[20:10] <tdaitx> infinity, I haven't checked, just got the question a while ago and found a few posts/comments that no one had binaries because of license conflict
[20:10] <tdaitx> infinity, what should I look for exactly?
[20:11] <infinity> tdaitx: Well, look for what it's linking. :P
[20:11] <infinity> tdaitx: The binutils source isn't under a uniform license.
[20:11] <infinity> libiberty, for instance, is LGPL2+
[20:12] <tdaitx> infinity, oh, I see, let me check that then, thanks for the heads up on this
[20:14] <infinity> tdaitx: bfd is potentially more problematic, though it would seem almost no one pays attention to that conflict... :/
[20:16] <infinity> tdaitx: But, the longer answer is that if it's linking GPL3+ code, the source in question should be licensed as GPL2+, and it'll become 3+ defacto when distributed as a whole.
[20:16] <infinity> tdaitx: If it's 2-only, upstream might want to fix that, since they've created an impossible situation for downstreams.
[20:17] <tdaitx> infinity, and folks had asked for oracle to do just that more than once, it's just 2 files, but they never did it
[20:17] <infinity> Fun, fun.
[20:17] <tdaitx> hsdis is only used for debugging, it's not exactly a part of openjdk
[20:17] <mwhudson> hallyn: i have no real plans to backport golang 1.7 to xenial, no
[20:18] <mwhudson> hallyn: you can install from ppa:~gophers/archive though
[20:19] <tdaitx> infinity, it links to: bfb, libiberty, and opcodes
[20:19] <infinity> Yeah, pretty sure bfd is GPL3+
[20:19] <infinity> So, sucks to be you, basically.
[20:20] <tdaitx> infinity, so, building it during package install (like dkms) is not an option?
[20:21] <infinity> It's a hackish option, sure.  If you want the package to depend on a toolchain just for that.
[20:21] <infinity> (honestly, the concept of dkms is pretty letter-of-the-law-but-spirit-of-a-complete-jerk anyway, but meh)
[20:21] <tdaitx> yeah, I know
[20:21] <infinity> The reason everyone gets away with it for dkms is because Linux upstream really doesn't care. :P
[20:22] <infinity> binutils being an FSF project, they might care more.  OTOH, I suspect libbfd is used in all sorts of places it shouldn't be.
[20:23] <tdaitx> infinity, anyway, any chance a package like that would be accepted? or would it have to live inside a ppa?
[20:23] <infinity> Anyhow, legally, we could probably allow such an abomination in the archive.  Technically, is it really important enough to be worth the hassle?
[20:23] <infinity> From a legal standpoint, PPAs follow the same rules as the archive.
[20:23] <infinity> Anyone who uses PPAs to skirt the law is in massive violation of our TOS and, well, the law.
[20:24] <tdaitx> depends on what "important" means... any user that needs to debug openjdk has to build hsdis by himself, which is a hassle
[20:25] <tdaitx> but usually anyone looking to debug openjdk can probably figure out how to build it (still a hassle though)
[20:28] <tdaitx> infinity, and I think that oracle's lawyers asked exactly how important it was for them to decide if they would allow the gpl2+ change... the last thread about it died after devs said they couldn't comment on it and had forwarded the issue to higher powers
[20:29] <tumbleweed> win 62
[20:29] <tumbleweed> err
[20:30] <Unit193> Bingo.
[20:32] <infinity> tdaitx: FWIW, RedHat's just taken the hard line of "incompatible license, go away" as well.
[20:32] <infinity> tdaitx: I'm honestly more comfy with that, especially in terms of pressuring Oracle.
[20:33] <infinity> tdaitx: If we come up with a sketchy legal hack, then they'll be less likely to listen to anyone about fixing the license.
[20:33] <infinity> tdaitx: However, a README.hsdis that details *how* to build it would be an alright compromise.
[20:33] <tdaitx> the situation has not changed for years, I doubt the right people care about it
[20:34] <tdaitx> infinity, right, that is a good suggestion, I will see to at least have that file written down
[20:34] <infinity> (ie: apt-get source openjdk && apt-get install build-essential binutils-source && make -C foo/bar BINUTILS=/usr/src/thing ARCH=whee)
[20:35] <infinity> binutils-source is probably overkill, if you can make it work with binutils-dev, which already has the right static libs built.
[20:35] <tdaitx> yeah, I think so
[20:35] <tdaitx> infinity, thanks for the help =)
[20:36] <infinity> tdaitx: So, I wouldn't even be against you providing that as a script that just DTRT, where I'm likely to want to draw the line is the package install triggering it automatically.
[20:37] <infinity> tdaitx: But if you do it as a script, you can also write an autopkgtest that runs it (and throws away the results), so you can be sure that new binutils or new openjdk don't regress the magic.
[20:37] <infinity> tdaitx: Then you can be fairly confident with saying "just run this if you need hsdis", and you're good to go.
[20:37] <tdaitx> infinity, that is an awesome idea! and I have just added autopkgtests to the latest openjdk-8, so this is a nice addition
[20:38] <infinity> tdaitx: Maybe bonus points if the script has a quick "this will combine incompatibly-licensed code from openjdk and binutils, this is fine for local use, but you can not redistribute it" confirmation before it does the thing.
[20:39] <infinity> Which (a) sort of covers our butts, and (b) is a nice reminder of WHY we're making the user do this silly thing manually.
[20:41] <tdaitx> indeed
[20:44] <infinity> "If you think this is silly, please complain to Larry Ellison, PO Box #1234, Station M..."
[20:45] <Unit193> Hah. :D
[20:45] <infinity> Although, I have much larger complaints for Larry, if you happen to track him down. :P
[20:49] <Unit193> infinity: BTW, any idea why src:geoip hasn't sync'd?  Is it still catching up?
[21:10] <infinity> Unit193: autosyncs aren't on yet until we're sure Perl's in a happy place.
[21:10] <infinity> Which it might be now.  I've not looked today.
[21:11] <Unit193> Ah, I see.  Thought I saw some syncs slipping past already.  Sorry for the poke then.
[21:11] <pitti> no, there are still two metric tons of rebuilds missing
[21:11] <tsimonq2> infinity: To repeat myself from a few days ago, if there's something that I can help with that has an easy solution, don't be afraid to ping. ;)
[21:11] <infinity> pitti: Well, I define "happy place" as "autosync won't break the world", not "it's ready to transition to the release pocket".
[21:12] <pitti> well, we have openmpi+perl+mysql entangled already -- I think we should better wait until that landed
[21:12] <infinity> Perhaps fair.
[21:12] <mwhudson> @pilot in
[21:20] <hallyn> mwhudson: ok thx
[21:21]  * hallyn tries out how to use that archive
[21:22] <mwhudson> hallyn: golang-1.X-go installs to /usr/lib/go-1.X so you'll need to add /usr/lib/go-1.X/bin to PATH
[21:23] <hallyn> right, i'm doing this as part of a machine setup in a juju charm, so i'll need to redirect
[21:23] <mwhudson> ah
[22:23] <mwhudson> nacc: ayt?
[22:23] <nacc> mwhudson: pong
[22:23] <mwhudson> nacc: can you operate the git import machinery?
[22:23] <nacc> mwhudson: yeah, which src package?
[22:23] <mwhudson> nacc: aptitude
[22:24] <nacc> mwhudson: ack, will ping you when its done
[22:24] <mwhudson> nacc: awesome, thanks
[22:30] <nacc> smoser: given that putting changelog entries in the commits is a 'nice to have', why don't we just not make it fatal when we can't obtain it?
[22:30] <nacc> smoser: that would fix LP: #1636529 as well, afaict
[22:41] <mwhudson> LocutusOfBorg: hey, re https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1632357, has llvm-toolchain-3.6 been removed from sid or something?
[22:41] <mwhudson> LocutusOfBorg: or is there some strange bit of history here i'm not getting?
[22:42] <nacc> it does look to be only in testing now
[22:43] <mwhudson> and only at 1:3.6.2-3
[22:43] <nacc> yeah, strange publishhistory says 3.6.2-4 got deleted 12 days ago
[22:46] <mwhudson> this is why patch piloting is hard, 30 mins of poking to just get more confused
[22:46] <nacc> mwhudson: https://packages.qa.debian.org/l/llvm-toolchain-3.6/news/20161014T115303Z.html
[22:46] <nacc> mwhudson: looks like they are moving to 3.8/3.9 and maybe 4.0 only
[22:47] <mwhudson> nacc: in which case syncing the package looks a bit pointless :)
[22:47] <nacc> mwhudson: we only need 3.6 for clamav, aiui, and I believe folks were working on making that compatible with 3.8
[22:47] <mwhudson> i guess we should consider following
[22:47] <nacc> ack
[22:51] <nacc> mwhudson: yeah, and it looks like libclamav7 in sid now just doesn't use llvm at all
[22:52] <nacc> mwhudson: so presumably we need to merge/sync that and then we can demote, at least
[22:54] <mwhudson> ah yeah, doesn't look like we're too far behind
[22:57] <mwhudson> bit scary though :)
[22:59] <nacc> mwhudson: yeah, i'd push back, probably, and caribou and LocutusOfBorg can resolve it :)
[23:10] <jbicha> tumbleweed: you're in 62+ IRC channels? how do you get any work done?
[23:13] <tumbleweed> jbicha: good question :P
[23:13] <mwhudson> nacc: yeah
[23:13] <mwhudson> nacc: how goes the aptitude import, what sort of timeframe should i expect?
[23:13] <jbicha> I mean it would probably help if people like me aren't pinging you all the time either ;)
[23:14] <nacc> mwhudson: it's up to karmic right now, hopefully w/in the next 15 minutes, presuming we don't get any parse errors :)
[23:14] <mwhudson> nacc: ok
[23:14] <tumbleweed> jbicha: naah, I was out getting coffee. Some of those are work channels. And many are idle. The rest I don't really read, but vaguely watch
[23:36] <nacc> mwhudson: it's pushing up to the git repository now
[23:43] <nacc> mwhudson: sorry it's taking so long, first imports take a while :)
[23:46] <nacc> mwhudson: alright, pushed, https://code.launchpad.net/~usd-import-team/ubuntu/+source/aptitude/+git/aptitude
[23:49] <mwhudson> nacc: thanks!
[23:49] <nacc> mwhudson: np