[00:22] <bdmurray> slangasek: Does the RetraceFailure information make sense? https://errors.staging.ubuntu.com/oops/205498dc-7b4b-11e4-9ba5-fa163e1893a8
[00:31] <slangasek> bdmurray: it's a surprising failure, but it makes sense
[00:35] <bdmurray> slangasek: I guess I really meant are those new field useful
[00:38] <slangasek> bdmurray: yep - that's how I understood the question :) yes I think it's useful
=== fginther is now known as fginther`
=== fginther` is now known as fginther
=== DrKranz is now known as DktrKranz
[06:02] <pitti> Good morning
[06:03] <pitti> shadeslayer: can you please file a bug about this? I think adt-run should detect the number of available cores and use that as a default for parallel=N; we might also have a new option for this
[06:04] <pitti> shadeslayer: note that on ci.debian.net there is only one core, but for ubuntu there are two (or four for "big" packages)
[07:21] <pitti> hallyn: samba is breaking heaps of stuff, I'm uploading a no-change rebuild now; but it would still be good to merge (and I earned enough merges by cleaning up -proposed by now, I'm not going to do that one, too)
[07:52] <dholbach> good morning
[09:09] <mwhudson> is there any thing (service?) that checks whether two packages in the archive attempt to install a file to the same path?
[09:09] <mwhudson> (unless the packages conflict: each other or anything like that)
[09:14] <mwhudson> ah https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=treinen@debian.org
[09:17] <mwhudson> does anyone run that for ubuntu?
[09:52] <cjwatson> mwhudson: There used to be http://conflictchecker.ubuntu.com/possible-conflicts/, but as you can see from the index it's been unmaintained for some time
[09:53] <cjwatson> I forget who maintained that ...
[09:53] <cjwatson> Might be worth replacing it with something based on edos-file-overwrite nowadays, indeed
[09:53] <caribou> xnox: around ?
[09:53] <xnox> caribou: yeap
[09:54] <caribou> xnox: I saw your note on uploading makedumpfile latest to experimental
[09:54] <caribou> xnox: what's the benefit : being able to sync from there into Ubuntu ?
[09:55] <xnox> caribou: yes. and removing it from ubuntu's blacklist.
[09:56] <xnox> caribou: generally around freeze time one should switch sid -> experimental for all new uploads. That leaves room to continue using sid for release team unblocks.
[09:57] <xnox> caribou: or did a too new upstream version migrate to jessie and then was decided to be reverted by debian's release team? hence the mandatory epoch?
[10:02] <caribou> xnox: no, an old version stalled in jessie because of a grave bug that got fixed but not closed
[10:02] <caribou> xnox: and the newest version, which would be required for sid 3.16 kernel also got blocked
[10:03] <xnox> caribou: ah =/ right, then the fix up could have gone into testing-proposed-updates with no epoch-bump in sid for downgrade in version number....
[10:03] <xnox> meh, too late now.
[10:04] <caribou> xnox: the release team was not too enthusiastic about sending it direct to testing-proposed-updates
[10:04] <xnox> caribou: =))))))) release team are such sceptical people. i guess it's for the better.
[10:05] <caribou> xnox: carryin the epoch is no big deal. But I wasn't aware of the experimental usage around freeze
[10:06] <caribou> xnox: all that happened soon after I became officially DM so I missed a few things here & there. Will be better next time
[10:06] <xnox> caribou: =)))) yeah, no worries.
[10:07] <caribou> xnox: I want to 'fix' the latest version to work with systemd; then I'll upload 1:1.5.7-4 with it to experimental
[10:07] <caribou> xnox: the one in sid does
[10:08] <xnox> caribou: sounds good =)
[10:09] <mwhudson> cjwatson: cool, doesn't seem like it would be thaaaaaat hard
[10:09] <cjwatson> famous last words
[10:10] <mwhudson> cjwatson: heh, not promising anything in any way whatsoever
=== doko_ is now known as doko
[10:32] <doko> Laney, seb128: any idea about https://jenkins.qa.ubuntu.com/job/vivid-adt-glib2.0/21/ARCH=amd64,label=adt/  ?
[10:33] <doko> ScottK, Riddell: some new autopkg test failures for k* packages (triggered by gcc-4.9). any idea?
[10:34] <pitti> doko, ScottK, Riddell: already retried, the testbed machines are once again overloaded
[10:34] <doko> ahh, ok
[10:34] <pitti> doko: I'm watching the failures and press the buttons
[10:34] <seb128> doko, not sure, Laney was looking at the glib issue
=== _salem is now known as salem_
[12:08] <shadeslayer> pitti: will do
[13:00] <didrocks> shadeslayer: hey! I see nothing in the transition ppa for bluez5, do you need any help?
[13:01] <shadeslayer> didrocks: I got a release out of the bluedevil team yesterday, but still no libbluedevil, so I'm waiting for them to release the lib
[13:01] <shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1399177
[13:01] <ubottu> Launchpad bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Undecided,New]
[13:01] <didrocks> shadeslayer: do you think this will come in a matter of days? I would love starting a call for testing start of next week
[13:01] <shadeslayer> didrocks: let me ask the maintainer
[13:01] <didrocks> shadeslayer: thanks :)
[13:01] <shadeslayer> didrocks: yes, probably today/tomorrow
[13:02] <didrocks> shadeslayer: keep me posted!
[13:02] <shadeslayer> didrocks: will do :)
[13:02] <shadeslayer> let me check if I can upload things
[13:02] <didrocks> shadeslayer: core-devs should be able, but yeah, better to double-check :)
[13:02] <shadeslayer> nope, I'm not a core-dev
[13:02] <shadeslayer> so can't upload
[13:03] <shadeslayer> didrocks: I'll upload it to one of my PPA's and then someone can copy it over
[13:03] <didrocks> shadeslayer: sounds good!
[13:03] <shadeslayer> cool :)
[13:03] <didrocks> thanks again ;)
[13:03] <shadeslayer> yw :)
[13:04] <shadeslayer> sitter: ^^ I reckon we can CI bluedevil too
[13:04] <shadeslayer> assuming it's ported to KF5
[13:05] <sitter> as with everything alex does there is an unreleased frameworks port :P
[13:05] <sitter> though to be fair I think he didn't do the port
[13:08] <sitter> shadeslayer: having red the backlog I guess bluez5 wirst needs to transition to the archive. once it is in CIing it only depends on someone pinning a relase date/schedule/scope on the frameworks port
[13:08] <sitter> s/wirst/first
[13:25] <shadeslayer> sitter: roger
[13:42] <pitti> shadeslayer: thanks
[13:43] <shadeslayer> cheers
[13:45] <shadeslayer> didrocks: so, libbluedevil uploaded to https://launchpad.net/~rohangarg/+archive/ubuntu/kde-extra/+packages
[13:45] <shadeslayer> didrocks: could you copy it once it's built
[13:46] <didrocks> shadeslayer: excellent! this is the only one needed?
[13:46] <shadeslayer> didrocks: no, once libbluedevil is built, I need to upload the bluedevil
[13:46] <shadeslayer> the bluedevil xD
[13:49] <didrocks> heh ;)
[13:49] <didrocks> ok, will ping you once I copied and it's built there
[13:49] <shadeslayer> okie
[13:51] <shadeslayer> didrocks: bluedevil might take some time, I have to deal with this vodoo patch http://paste.ubuntu.com/9367508/
[13:52] <didrocks> shadeslayer: oh, RPATH fun! "enjoy" :p
[13:57] <shadeslayer> didrocks: yeah, not really sure if it makes sense to have that patch, since we have RPATH enabled on kdelibs and it should be propogating upwards to all of the things
[14:05] <dgadomski> hey cjwatson, did you manage to take a look at the 2 ubiquity bugs we discussed in DC? bugs #1386131 #1386153
[14:05] <ubottu> bug 1386131 in ubiquity (Ubuntu) "Preseeding encrypted lvm fails instead of asking for password" [Undecided,New] https://launchpad.net/bugs/1386131
=== zyga is now known as santa
=== santa is now known as zyga
[14:51] <GunnarHj> Hi pitti!
[14:52] <pitti> hey GunnarHj, how are you?
[14:52] <GunnarHj> pitti: Fine, thanks. You?
[14:52] <GunnarHj> pitti: If you have time: Anything you would like to say at http://askubuntu.com/questions/435954 or bug #1394929?
[14:52] <ubottu> bug 1394929 in glibc (Ubuntu) "Please provide 'locales-all' as in Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1394929
[14:52] <cjwatson> dgadomski: I committed the fix for one of them; I think one of my successors is going to have to pick up the other though
[14:53] <pitti> GunnarHj: ah, I talked about that with infinity a while ago; the intention is to bury langpack-locales and move them back to glibc, as the idea of maintianing locales on launchpad never took off (and probably isn't such a good idea in the first place)
[14:53] <cjwatson> dgadomski: actually that was a third one, bug 1386113
[14:53] <ubottu> bug 1386113 in ubiquity (Ubuntu) "Preseeding encrypted lvm fails with "An error occurred while creating the keyfile"" [High,Fix released] https://launchpad.net/bugs/1386113
[14:53] <pitti> GunnarHj: I think infinity has that planned, but I don't know when
[14:54] <GunnarHj> pitti: Aha, I see. Would it mean that locales-all would be available in Ubuntu?
[14:54] <pitti> GunnarHj: yes
[14:55] <dgadomski> cjwatson: exactly, the third one is fixed and tested by the user
[14:55] <GunnarHj> pitti: Ok, thanks.
[14:55] <dgadomski> cjwatson: do you have any particular names in mind to handle the other two?
[14:56] <cjwatson> dgadomski: hopefully slangasek can give you a name; I have seven working days left before moving to another position
[14:56] <dgadomski> cjwatson: oh, didn't know you are moving, thank you!
[14:57] <cjwatson> dgadomski: (still within Canonical, but I won't be doing installer work any more)
[15:01] <dgadomski> cjwatson: thanks and good luck with the new position
[15:06] <brainwash> slangasek: the xfce4 meta package is synced from debian and recommends "desktop-base" which installs debian wallpapers, a debian grub background and so on
[15:06] <brainwash> slangasek: would it be ok to drop it to suggests?
[15:06] <brainwash> bug 1080865
[15:06] <ubottu> bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865
[15:09] <shadeslayer> didrocks: bluedevil uploaded as well
[15:10] <Raydiation> hi, can i run sysvinit scripts in 14.04?
[15:11] <Raydiation> i would like to limit avoid upstart
[15:11] <Raydiation> -limit
[15:11] <Raydiation> and just support systemd + sysvinit
[15:11] <shadeslayer> Raydiation: yep
[15:12] <shadeslayer> Raydiation: see /etc/init.d/README
[15:12] <shadeslayer> Raydiation: note that systemd is not fully supported on 14.04
[15:13] <shadeslayer> Raydiation: /etc/init.d/skeleton is a example init file
[15:14] <Raydiation> ty
[15:14] <Raydiation> shadeslayer: yep unfortunately :P
[15:14] <Raydiation> the one init system to rule them all will make things sooo much easier
[15:14] <Raydiation> :D
[15:14] <Raydiation> at least for packaging cross distro software
[15:17] <Raydiation> Is the next release planned to include systemd?
[15:17] <Raydiation> as in 15.04?
=== roadmr is now known as roadmr_afk
[15:27] <cjwatson> Raydiation: It's likely to.
[15:30] <Raydiation> ty
[15:30] <bdmurray> seb128: fyi retrace failure reasons now appear on individual OOPS reports for recent retracings on errors.
=== roadmr_afk is now known as roadmr
=== Saviq_ is now known as Saviq
[16:21] <pitti> infinity, ScottK: any chance to accept postgresql-9.4 in the utopic queue? it's been there for two weeks now
[16:21] <pitti> (as per MRE)
[16:24] <infinity> pitti: What's it worth to you?
[16:27] <seb128> bdmurray, hey, nice, thanks for that
[16:28] <bdmurray> seb128: I plan on having information about the failures in the bucket real soon too
[16:29] <bdmurray> pitti: I'm on duty today and will have a look
[16:29] <seb128> cool
[16:30] <bdmurray> pitti: and the 25th is a bit short of two weeks
[16:34] <arges> xnox: hey, i see you're looking at intel/HLE errata fallout bugs. fyi I'm working on bug 1398975 to patch glibc
[16:34] <ubottu> bug 1398975 in glibc (Ubuntu Utopic) "hardware-assisted lock elision hazardous on x86" [Medium,In progress] https://launchpad.net/bugs/1398975
[16:34] <xnox> arges: yeah, what's up?
[16:34] <xnox> arges: if need / want testing, you can subscribe ~intel-team there are a few qa folks there.
[16:35] <arges> xnox: just letting you know since it seems like there are alot of various updates to do... intel-microcode, glibc, and I think you were looking at that new package... ucode something
[16:35] <xnox> arges: they generally test from -proposed though.
[16:35] <arges> xnox: awesome may do that
[16:35] <xnox> arges: i'm looking into making microcode to be installed by default. I'm not working on doing glibc updates, however. So thanks for doing that ;-)
[16:37] <arges> xnox: np. so trying to figure out what needs to be done for bug 1388889 since i was assigned it. does something need to be SRUed? or since you did the sync I assume the intel-microcode task is done?
[16:37] <ubottu> bug 1388889 in iucode-tool (Ubuntu) "[MIR] intel-microcode & iucode-tool (multiverse -> restricted)" [Undecided,Incomplete] https://launchpad.net/bugs/1388889
[16:43] <xnox> arges: i'm not sure, are you archive admin? in that case it needs promotion from multiverse->restricted..... if the mir report is complete.
[16:43] <arges> xnox: ah that makes sense, i'll bug infinity about it then : )
[16:44] <xnox> arges: i'm not sure why tim assigned it to you though.
[16:44] <xnox> arges: i didn't think he is on the mir team to approve such things.
[16:44] <xnox> arges: i'll remove assignee from you.
[16:44] <arges> yea not really sure : ) regardless seems like something an AA can do
[16:45] <xnox> mterry: should look at the bug again =) everything is fixed up in vivid as per review comments now.
[16:45] <xnox> when he has time that is.
[16:45] <mterry> xnox, the intel mir?
[16:46] <xnox> mterry: yeah.
[16:46] <mterry> xnox, can you subscribe the teams to the packages?
[16:46] <xnox> mterry: let me check.
[16:46]  * pitti hands some yummy Stollen to infinity
[16:47] <pitti> bdmurray: ah great, thanks!
[16:47] <xnox> mterry: no, i can't. =(
[16:47] <xnox> arges: are you admin for kernel team?
[16:47] <mterry> xnox, I don't think you need to be admin, just a member
[16:47] <xnox> or I guess, ogasawara, could you please subscribe ~intel-team and ~canonical-kernel to  intel-microcode & iucode-tool packages ?
[16:48] <arges> xnox: yea just for kernel stuff
[16:48] <xnox> Bug mail recipient
[16:48] <xnox>  Yourself
[16:48] <xnox>  One of the teams you administer
[16:48] <xnox> mterry: ^ and in the dropdown i don't see intel-team =(
[16:48] <mterry> ah
[16:49] <cjwatson> Yes, you need to be an admin
[16:58] <arges> xnox: ok another one is bug 1370352. so intel-microcode had microcode-20140913.dat reverted. I'm thinking we un-revert it once fixes are in place for glibc, plus if there are fixes needed to SRU from latest intel-microcode
[16:58] <ubottu> bug 1370352 in intel-microcode (Ubuntu Trusty) "[Feature] Intel new CPU microcode 20140913 " [Undecided,In progress] https://launchpad.net/bugs/1370352
[17:02] <xnox> arges: in vivid everything is fine - that is microcode is loaded extra early, /proc/cpuinfo never says that there is txt and everything works like a charm....
[17:03] <xnox> arges: the sync in vivid overwrote ubuntu's changes.
[17:03] <xnox> arges: as they are not needed anymore.
[17:03] <arges> xnox: ok so at this point anything needed to be SRUed
[17:03] <xnox> arges: with respect to SRU you probably only want to sru back glibc change
[17:03] <xnox> arges: without changing / sruing intel-microcode at all.
[17:03] <arges> xnox: that makes sense too
[17:04] <xnox> arges: if glibc doesn't use txt, even if present / no microcode updated everything is good.
[17:04] <xnox> arges: simply sruing the new intel-microcode will not help, as that is not installed by default. hence one must sru glibc, and that is sufficient for stable release.
[17:05] <arges> xnox: well i think the trend is the new microcodes are usually SRUed as updates even to stable releases
[17:06] <arges> but in that bugs case we hit the microcode update which blacklisted HLE instructions which were used by glibc which caused illegal opcodes.
[17:17] <ogasawara> xnox: fyi, I've added ~intel-team as a subscriber to both the intel-microcode and iucode-tools packages
[17:18] <xnox> ogasawara: thanks. mterry ^
[17:18] <ogasawara> xnox: I left off subscribing ckt since we're members of the intel-team
[17:18] <mterry> xnox, ogasawara: thanks, will look at MIR again today
[17:18] <xnox> ogasawara: ack.
[17:25] <bdmurray> ChrisTownsend: Could you add some information about how you verified bug 1363959?
[17:25] <ubottu> bug 1363959 in Nux trusty "compiz crashed with SIGSEGV in nux::WindowCompositor::DndEventCycle()" [High,In progress] https://launchpad.net/bugs/1363959
[17:53] <bdmurray> Laney, mvo: Where is vte2.91? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2842
[18:27] <bdmurray> arges: bug 1398975 is missing a trusty task
[18:27] <ubottu> bug 1398975 in glibc (Ubuntu Utopic) "hardware-assisted lock elision hazardous on x86" [Medium,In progress] https://launchpad.net/bugs/1398975
[18:30] <bdmurray> arges: oh, I see it now
[18:47] <ChrisTownsend> bdmurray: Well, there is no real repro case, so my verification is that it's been in Utopic for some time (and Vivid) and I've been running this nux since it was in the ci-train PPA (and -proposed after that).
[18:48] <ChrisTownsend> bdmurray: I wasn't sure how to put that in the verification note.
[18:58] <bdmurray> ChrisTownsend: just saying that would have helped
[18:58] <ChrisTownsend> bdmurray: Ok, I can still add it for completeness.
[18:59] <bdmurray> ChrisTownsend: okay, thanks
[18:59] <ChrisTownsend> bdmurray: No problem.  Sorry about the confusion.
[19:12] <kkirsche> hey everyone, I'm trying to get started with, what I think, should be the easiest of packaging tasks —— which is that I would like to take a the NodeJS package (v 0.10.25) and update it to the source found at http://nodejs.org (v. 0.10.33). I have gotten the source using bzr branch ubuntu:nodejs nodejs.dev, then gotten the upstream tarball (bzr get-orig-source). From here, cd.., then bzr branch nodejs.d
[19:12] <kkirsche> ev bug-1103044. I then update the files in bug-1103044 with the files from Node's source. dch -i and say it's an "Vendor update (LP: #1103044)" (no other changes made) and do bzr commit. I then use dpkg-source --commit so that dpkg is happy with the new changes. I then try bzr builddeb -S within the bug-1103044 branch, I get: "dpkg-source: fuzz is not allowed when applying patches." I tried quilt refresh an
[19:12] <kkirsche> d that spit out a bunch of warnings regarding trailing whitespace in their files but no errors that I could see. At this point I'm feeling a bit lost as to how to submit what I thought would be a simple vendor update. Any help would be appreciated. Thanks for your time and for reading this.
[19:12] <ubottu> Launchpad bug 1103044 in nodejs (Ubuntu) "outdated version of nodejs (ubuntu 12.04 / 12.10 / 13.04 / 14.04)" [Wishlist,Triaged] https://launchpad.net/bugs/1103044
=== roadmr is now known as roadmr_afk
[21:17] <bdmurray> Laney: Oh, its because I was using the dist-upgrader on utopic which doesn't have vte2.91.
=== salem_ is now known as _salem
[21:26] <rharper> arges: on the qemu 2.0 package I tested, I updated bug 1370199 -- I don't think it quite fixes the issue since it requires an extra (manual) step of doing an upstart job stop, start.  Any idea how to have the packaging trigger an upstart job stop, then job start ?
[21:26] <ubottu> bug 1370199 in qemu (Ubuntu Trusty) "qemu upstart job should create /dev/kvm in a container" [Undecided,Fix committed] https://launchpad.net/bugs/1370199
[21:27] <arges> rharper: might be something you can do in postinst. but not sure if there is a better way
[21:28] <arges> rharper: debian/<binary-package-name>.postinst is most likely teh place for it
[21:28] <rharper> arges: ok -- my deb packaging fu is quite low;  but if postinst is just shell script, then I think it could be hooked (unless dpkg already does something with
[21:28] <rharper> the upstart jobs
[21:28] <rharper> arges: ok, lemme see what (if any is in .postinst in qemu packaging)
[21:28] <arges> rharper: https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html highlight postinst
[21:28] <rharper> thanks for the pointer
[21:29] <arges> cool good luck
[21:29] <rharper> looks like a winner
[21:29]  * rharper shall see about a patch 
=== roadmr_afk is now known as roadmr
[23:31] <xnox> slangasek: unlike fancy steak, RTs should be _well done_ not raw / uncooked.
[23:31] <slangasek> xnox: um?
[23:32] <xnox> slangasek: RE: your conversation with evan on RT and pictures of food. =)
[23:33] <slangasek> xnox: sounds like ev is grossly misrepresenting the situation, this wasn't in RT ;)
[23:34] <ev> I represented nothing
[23:34] <infinity> Typical.
[23:34] <ev> ly awesome
[23:34] <xnox> slangasek: i think his irc is just that fancy looking, I mistook it for actual RT website snippet.
[23:34] <kees> doko: do you know if https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 is fixed in Trusty's gcc 4.8.2?
[23:34] <ubottu> gcc bug 58854 in target "[4.8 regression] "sub sp, fp, #40" hoisted above frame accesses" [Normal,Resolved: fixed]
[23:34] <ev> xnox: I use irccloud. My beard does not extend into the neck.
[23:35]  * xnox likes how all the cool people are still around.
[23:35] <infinity> xnox: You have a warped definition of "cool".
[23:35] <kees> doko: context is git.kernel.org/linus/7fc150543c73de71859631c8a6b17e3067fe7617
[23:36] <TheMuso> off
[23:36] <doko> kees, according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854#c8 it should be, commited in 2013-11
[23:36] <ubottu> gcc bug 58854 in target "[4.8 regression] "sub sp, fp, #40" hoisted above frame accesses" [Normal,Resolved: fixed]
[23:36]  * xnox has a rude beard comment i should keep to myself
[23:36] <TheMuso> ugh
[23:36] <TheMuso> Damn workspaces bug in vivid, keyboard focus not always switching over...
[23:36] <kees> doko: when is that, compared to the 4.8.2 release and Ubuntu's 4.8.2 compiler?
[23:37] <slangasek> wait, so ev posted a picture of our conversation about him posting pictures of food?
[23:37] <ev> captioned meta. I then contemplated getting the picture put on the quotes page, then posting that to facebook
[23:37] <xnox> slangasek: yes on instragram that got syndicated on my facebook news feed
[23:37] <infinity> kees: It was fixed in r204665, and trusty's at r209122
[23:37] <infinity> kees: So, unless it was later reverted (or reverted locally), it should be fixed.
[23:38] <doko> gcc-4.8 (4.8.2-19) unstable; urgency=medium
[23:38] <doko>   * Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
[23:38] <doko> kees, ^^^
[23:38] <kees> infinity, doko: ah-ha, okay, thanks! the bug id to svn revision to ubuntu svn revision was making my head hurt :)
[23:38] <xnox> kees: generally gcc uploads in ubuntu update from release + all changes in the stable branch. Thus it's always way ahead the point number.
[23:38] <kees> xnox: yeah, that's what I figured, but I just wanted to be sure.
[23:39] <xnox> =)
[23:39] <kees> it means upstream ARM kernel builds will blow up on Trusty now, though, thanks to the commit id I pasted...
[23:39] <kees> well, "it" doesn't mean it, Ubuntu's gcc is fine, so it's a false build failure.
[23:40] <infinity> Yeah, I think we knew about this.
[23:41] <kees> okay, cool. looks like I didn't build an ARM kernel since this landed in October :)
[23:41] <doko> yes, still have my 4.8.4 backport for trusty pending ...
[23:41] <infinity> It's an irritatingly heavy-handed commit on rmk's part.
[23:41] <kees> yawp
[23:42] <kees> especially since it's detectable.
[23:42] <infinity> Honestly, I'm just so happy that Russell is using tools from this century, it's hard to be mad.
[23:42] <kees> lol
[23:44] <sarnold> lol
=== Nigel_ is now known as G
[23:49] <ari-tczew> xnox: could you take a look on bug 1291827 please? I made a merge from Debian, would be nice to get it sponsored.
[23:49] <ubottu> bug 1291827 in ntfs-3g (Ubuntu) "STABLE Version 2014.2.15 " [High,Confirmed] https://launchpad.net/bugs/1291827
[23:53] <xnox> ari-tczew: i ponder if this is finally time to drop that patch and just do a sync from debian though.
[23:55] <xnox> cjwatson: so in 2011 s/syncio/sync was done in wubi, is ok to finally retire the syncio patch in ntfs-3g given the support levels of wubi these days?!