=== rcj is now known as Guest84361
=== RoozbehShafiee__ is now known as RoozbehShafiee
[07:29] <pitti> doko_: lintian is fixed now, binutils is a valid candidate nwo
[07:30] <pitti> mvo: thanks for fixing software-properties!
[07:30]  * pitti fixes the aptdaemon failure
[07:48] <mvo> pitti: sure, yw
[08:01] <Mirv> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
[08:04] <LocutusOfBorg1> morning developers
[08:04] <LocutusOfBorg1> hi Mirv do you patch pilot today?
[08:05] <LocutusOfBorg1> quick question, can you see bug 1397558 ?
[08:05] <ubottu> Error: Launchpad bug 1397558 could not be found
[08:05] <LocutusOfBorg1> it is a security issue, a merge from debian
[08:06] <Mirv> LocutusOfBorg1: for a bit at least, yes! no, I don't see that issue either unfortunately :( maybe it's then security team only.
[08:06] <LocutusOfBorg1> ok unmark
[08:06] <LocutusOfBorg1> can you please try again?
[08:07] <LocutusOfBorg1> bug 1397558
[08:07] <ubottu> bug 1397558 in tcpdump (Ubuntu) "please merge tcpdump from debian" [Undecided,New] https://launchpad.net/bugs/1397558
[08:07] <Mirv> LocutusOfBorg1: now it works
[08:07] <LocutusOfBorg1> wonderful :)
[08:07] <LocutusOfBorg1> I'm the previous uploader, trivial merge
[08:07] <Mirv> LocutusOfBorg1: I've to disappoint though by being a mere MOTU, not core-dev :(
[08:08] <LocutusOfBorg1> no problem, next sponsor will maybe have a look :)
[08:08] <Mirv> I'd guess so, yes
[08:08] <LocutusOfBorg1> I was wondering if it was showing up on the queue
[08:09] <Mirv> I think it should now, after the next refresh
[08:09] <LocutusOfBorg1> yep, thanks
[08:11] <dholbach> good morning
[08:21] <tkamppeter> mvo, hi
[08:22] <mvo> tkamppeter: hi till, sorry, haven't goten to your mail yet, working on backlog this morning though
[08:23] <tkamppeter> mvo, after some investigations the problem has chenged, now it is bug 1397750.
[08:23] <ubottu> bug 1397750 in aptdaemon (Ubuntu) "Not able to install packages using the PackageKit D-Bus API" [High,New] https://launchpad.net/bugs/1397750
[08:25] <tkamppeter> mvo, the original problem is solved as the system had accidentally PackageKit instead of aptdaemon installed. After fixing that, the original problem points are solved. Now the problem is that the package ID does not get correctly interpreted when the actual installation of the package happens.
[08:25] <mvo> tkamppeter: aha, thanks
[08:29] <tkamppeter> mvo, and other functions, like the one to list the package's files understand the package ID.
[08:35] <Mirv> would any core-dev be willing to sponsor frafu's bug fix which I made a branch of? lp:~timo-jyrinki/ubuntu/vivid/onboard/onboard_fix1378739_1376764
[08:36] <Mirv> bug links etc at https://code.launchpad.net/~timo-jyrinki/ubuntu/vivid/onboard/onboard_fix1378739_1376764/+merge/243259
[08:37] <mvo> tkamppeter: oh, so its just install that does not?
[08:41] <tkamppeter> mvo, yes, only this pk.installPackage().
[08:42] <seb128> Mirv, hey, I can do that
[08:44] <Mirv> seb128: thanks!
[09:28] <Mirv> pitti: could you take a look at https://code.launchpad.net/~yuningdodo/ubuntu/trusty/usb-creator/usb-creator.lp1361474+lp1300361-recreate-udisks-client/+merge/232852 ? I've built and tested it with various cases on 14.04 now as explained in the comment.
=== vrruiz_ is now known as rvr
[09:46] <Mirv> LocutusOfBorg1: yes the tcpdump security bug now is visible in the sponsoring page. meanwhile, I'll take a look/test at your earlier ettercap SRU as that's in universe.
[09:54] <LocutusOfBorg1> Mirv, honestly I would like to see an SRU of everything is now in vivid and testing...
[09:57] <Mirv> LocutusOfBorg1: I know, but unless each of the new version's commits can fulfill the SRU criteria, it's a bit tough to sell for the SRU process.
[09:58] <LocutusOfBorg1> it has been two ettercap releases that are almost completely bug fixes
[09:59] <LocutusOfBorg1> when we have new features we usually disable them with cmake parameters, and being both debian and upstream maintainer gives me the power to be sure about it :)
[10:50] <pitti> ricotz: stable patch queue> just didn't get to that yet, but will do now
[10:55] <cousteau> what's the channel for package maintenance?  I want to ask why moonlight is not in repositories anymore
[11:05] <ricotz> pitti, hi, alright, thanks
=== greyback_ is now known as greyback
=== _salem is now known as salem_
[11:17] <pitti> ricotz: or I would if I would find an effective git invocation that does that :)
[11:17] <rbasak> cousteau: it was left unmaintained: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638565 and https://launchpad.net/ubuntu/+source/moon/+publishinghistory under Oneiric.
[11:17] <ubottu> Debian bug 638565 in ftp.debian.org "RM: moon -- RoQA; outdated, NPOASR, outdated" [Normal,Open]
[11:18] <cousteau> I see
[11:21] <cousteau> I think I'll better find other alternatives to Silverlight rather than trying to install an unmaintained program
[11:22] <cousteau> rbasak, thanks!
[11:48] <pitti> ricotz: meh no, that's broken
[11:48] <pitti> ricotz: current v217-stable doesn't even build -- I'll rather wait for 218 then
[11:49] <ricotz> pitti, oh, really, i just noticed the 216 and 217 tags are not pushed to the stable repo
[11:50] <ricotz> iirc there is a small script mentioned in the changelog to fetch the queue
[11:50] <pitti> ricotz: I did fetch the patches, but they cause build errors; apparently undeclared patch dependencies
[11:50] <ricotz> hmm, i see :\
[11:51] <ricotz> doesnt count for a good maintenance over there
[11:59] <pitti> ricotz: I take that back, this is due to another patch; I fix that first, and then try the stable series again
[11:59] <pitti> ricotz: anyway, last commit to v217-stable was on Nov 11, quite old already
[11:59] <ricotz> pitti, ok, although there are 50 patches on top of the release
=== MacSlow is now known as MacSlow|lunch
[12:53] <shadeslayer> it's a mess I tells ya
[12:53] <shadeslayer> brr
=== MacSlow|lunch is now known as MacSlow
[13:07] <mardy> jdstrand: hi! About confinement of account plugins: I didn't think about using the aa_* functions, and I went for ubuntu-app-launch2 instead (because I was looking at PayUI, and that's how they do it)
[13:08] <mardy> jdstrand: do you think I should change to use aa_change_profile() instead, and go back the previous implementation (using just QProcess)? It would be a rather quick change, so I wonder if you would recommend one method over the other
[13:19] <Mirv> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== eliasps_ is now known as eliasps
[14:11] <LocutusOfBorg1> sorry cjwatson you were mentioned on the changelog https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 Indeed wasn't your code, but the previous one
[14:11] <ubottu> Launchpad bug 1266492 in evolution-data-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Confirmed]
[14:11]  * LocutusOfBorg1 thinks that monday shouldn't be a workday
[14:12] <LocutusOfBorg1> sorry again
[14:26] <balloons> mvo, ping again :-) I keep missing you. I'm curious about a couple things. 1) Multi-arch support for the click, so click build can automagically target multiple arches (using schroots?) 2) This bug seems to prevent us from being able to install from the store on x86 https://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611
[14:26] <ubottu> Launchpad bug 1396611 in click (Ubuntu) "Can't install click packages with pkcon" [Undecided,Confirmed]
=== oSoMoN_ is now known as oSoMoN
[15:05] <brainwash> pitti: I've encountered https://bugzilla.redhat.com/show_bug.cgi?id=1159117 while testing systemd 217 from proposed (backported to utopic)
[15:05] <ubottu> bugzilla.redhat.com bug 1159117 in systemd "systemd 217 show dependency loop and won't start gdm" [Urgent,Closed: rawhide]
[15:07] <pitti> brainwash: that shoudl be fixed in -2 (just uploaded to experimental) and -2ubuntu1 (just preparing for vivid)
[15:07] <pitti> brainwash: it's part of the v217-stable fixes
[15:07] <pitti> brainwash: backport from -proposed> livin' on the edge, eh? :-)
[15:07] <brainwash> pitti: great, I will test it later
[15:08] <brainwash> https://launchpad.net/~unit193/+archive/ubuntu/systemd from Unit193
[15:09] <brainwash> systemd is pretty stable, so I'm not that worried about using the latest release
=== Guest84361 is now known as rcj
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[15:21] <didrocks> barry: hey, how are you?
[15:22] <barry> didrocks: hi, good!  and you?  i'm in a meeting atm
[15:22] <didrocks> barry: I'm good as well, thanks! feel free to answer when your meeting ends then, there is no hurry :)
[15:22] <didrocks> barry: we did have an interesting session at last UOS about "preventing people to shoot in their feet by sudo pip install" (same for rubygem) where aquarius argued heavily we should avoid those behaviors
[15:23] <didrocks> barry: to not be too intrusive (especially with sysadmins having their scripts I guess), I have in my mind the following suggestions:
[15:24] <didrocks> barry: having the ubuntu developer tools setting an environment variable like PROTECT_DEVS_USE_LOCAL, and then patching pip/rubygem to bails out by default if this env variable is set (and linking to a wiki page so that they understand exactly why and how to fix this)
[15:25] <didrocks> barry: another patch would be that "pip install" (without sudo) doesn't try to install by /usr/local by default and give a better error, I can do this as well
[15:25] <didrocks> just wanted your thoughts on this :)
[15:25] <pitti> stgraber, jodh: I believe I captured most of the work in https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration as WI now; please double-check, though
[15:26] <didrocks> pitti: add grub entry to boot with upstart -> done locally at least ;) I might add some btw, like the fallback X session if you don't mind
[15:26] <pitti> didrocks: please do
[15:51] <mvo> balloons: hi, sorry, super busy, let me look at your question
[15:53] <pitti> zul: can you please look into http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-taskflow ?
[15:53] <pitti> zul: it's uninstallable (missing python-ordereddict)
[15:53] <pitti> apw: ^ FYI
[15:53] <zul> pitti:  yep
[15:53] <apw> pitti, ack thanks
[15:54] <pitti> zul: thanks
[15:54] <pitti> doko_: btw, binutils still didn't propagate -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has some uninstallabilities?
[15:55] <mvo> balloons: could you file a bug about the multi-arch clicks ? do you want to generate multiple clicks? or a single "fat click"?
[15:56] <balloons> mvo, yes a single fat click. I was successful in manually building one, and it goes into the store, installs across devices all fine. But click itself can't build it
[15:57] <barry> didrocks: my understanding is that in some (not too distant) future, pip --user will be the default outside of virtualenvs.  imo, that's the right way to go, i.e. no --user *inside* venv by default, but --user *outside* venv by default.  that should go a long way to making pip sane on ubuntu
[15:58] <barry> didrocks: i'd be very happy to consider making --user the default now-ish in debuntu
[15:58] <didrocks> barry: oh, that sounds really nice! do you want a patch for this?
[15:59] <sergiusens> balloons: building fat clicks has been possible for a while, and 'click build' works fine if you gve it the right layout
[15:59] <balloons> sergiusens, I'm happy to be informed. I didn't file a bug on it because I'm not sure how it's supposed to be happening now, or if it's not yet built, etc
[16:00] <barry> didrocks: yes!  also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725848
[16:00] <ubottu> Debian bug 725848 in python-pip "python-pip: default install method for non-root users should be --user" [Normal,Open]
[16:00] <didrocks> barry: opened, will send you something your way for debian tomorrow I guess :)
[16:00] <barry> didrocks: sounds great, thanks
[16:00] <didrocks> barry: thanks for the feedback :)
[16:01] <sergiusens> balloons: I did this really quick for the ci engine as a base template sort of thing: http://bazaar.launchpad.net/~sergiusens/uci-engine/click/view/head:/click-builder/click_builder/clickbuilder.py
[16:01] <sergiusens> balloons: feel free to use as inspiration
[16:01] <barry> didrocks: note dstufft's comment, there does need to be a way to turn off --user and actually, outside of a venv, i'd be happy if that mythical --no-user complained and exited if uid != 0
[16:02] <balloons> sergiusens, awesome thanks. I'll have a look at it after my call
[16:02] <barry> didrocks: there's also code in python-pip's quilt patches to determine whether your inside or outside a venv.  it should work for both python-virtualenv (py2 and py3) and pyvenv (py3)
[16:02] <barry> *you're
[16:02] <barry> it's been a while since i caught up on that github thread
[16:03] <balloons> so sergiusens the idea is you have chroots for each arch and this cobbles them together?
[16:03] <didrocks> barry: agreed on --no-user + complain if uid != 0 :) (and ack on the virtualenv one)
[16:05] <sergiusens> balloons: that was what I was going for; but you can't get too much into 'click' itself without breaking the concept of simple packaging
[16:05] <balloons> so I guess my question for mvo is what sort of support will be built in to click itself for this?
[16:08] <doko_> pitti, yep, known. will care about it later today
[16:09] <balloons> mvo, and when you have a moment again, I'm curious about the store bug as it's stopping installation of packages from x86 installs. Want to make sure it's filed in the proper place, etc.
[16:10] <pitti> doko_: no hurry, just wanted to keep up updated
[16:12] <bdmurray> seb128: did you find that unity-settings-daemon segfault?
[16:12] <seb128> bdmurray, we found/fixed it, but I'm concerned that e.u.c didn't register it when it was impacting every single laptop user and that we know a good number of people reported it
[16:13] <dobey> balloons: that's not an issue with the store. it's an issue with click/pkcon integration. so filing it under click is the right place i think
[16:13] <bdmurray> seb128: do you have an OOPS ID for any of those reports?
[16:14] <seb128> pitti, ^ do you have the oops id for the report you did about the usd/upower issue?
[16:17] <seb128> bdmurray, it looks like https://errors.ubuntu.com/problem/7689f87da805c668a249ff41702cf7706a046e37
[16:17] <seb128> bdmurray, I wonder if those just took a while to get retraced
[16:18] <seb128> though e.g pitti's one is not in that bucket it seems
[16:18] <bdmurray> seb128: there is a backlog for amd64 (a week) but we are on top of i386 (for the most part)
[16:18] <seb128> k
[16:18] <seb128> so that probably explains it
[16:19] <bdmurray> seb128: I'm submitting an RT to dump the amd64 queue again and we are moving to scaling stack for the retracers real soon now.
[16:19] <pitti> hm, do we really just have i386 traces there?
[16:19] <pitti> ah
[16:19] <seb128> do you know if the backlog is a temporary issue?
[16:19] <seb128> k
[16:19] <bdmurray> seb128: yes, temporary we haven't added any new amd64 retracers for a while.
[16:20] <bdmurray> pitti: any luck with bug 1370230 yet?
[16:20] <ubottu> bug 1370230 in Apport "apport-retrace has become slower" [High,Triaged] https://launchpad.net/bugs/1370230
[16:20] <pitti> still swamped :(
[16:20] <mvo> balloons: would you mind filing a bug about the click build for multi-arch? just so that its tracked ?
[16:20] <pitti> and TBH with all the snappy stuff now being thrown my way it's not going to get better anytime soon, so anyone who wants to have a go at this please do
[16:21] <mvo> balloons: the install bug seems to be a issue with the packagekit backend  - it appears it tires to install the click as a deb instad of as a click
[16:21] <mvo> balloons: so thats a click-bug
[16:21] <bdmurray> pitti: alright, I'll have a look then. What about bug 1394798 for which I added a patch?
[16:21] <ubottu> bug 1394798 in Apport "Contents.gz files exist multiple times in sandboxes" [Undecided,Confirmed] https://launchpad.net/bugs/1394798
[16:21] <balloons> mvo, yes I will file a bug for multi-arch. Thanks for confirming the bug is in the right spot
=== arges` is now known as arges
[16:22] <mvo> balloons: something similar was reported some days ago
[16:22] <didrocks> shadeslayer: hey, so, we do have the transitions ppa with bluez5 (working as checked with pulseaudio) done, mind uploading bluedevil (I can sponsor you if you can't upload) there? https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
[16:23] <shadeslayer> didrocks: ok, I can put it on my todo for tomorrow, is that alright?
[16:23] <shadeslayer> I didn'
[16:23] <shadeslayer> I didn't realize that the transition work had been done so quickly :)
[16:25] <didrocks> shadeslayer: that's perfect, thanks! (Not everything is in yet TBH, but we did validate the base is working :))
[16:25] <ogra_> shadeslayer, just as yourself "could it be on a phone install ?" ... if the answer is yes, then you can be sure the transition is done in no time ;)
[16:25] <ogra_> *ask
[16:25] <shadeslayer> :D
[16:25] <seb128> apw, hey, dunno if you noticed bug 1377378, it seems it started with your upload on https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu7
[16:25] <ubottu> bug 1377378 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_renderer_get_buffer_for_head()" [Medium,New] https://launchpad.net/bugs/1377378
[16:25] <didrocks> ogra_: this is more desktop-centric for now than phonish TBH. Testing on the phone would be next step ;)
[16:26] <didrocks> (of course, before pushing to -proposed)
[16:26] <pitti> bdmurray: queued, I'll have a look tomorrow morning at this; you just need this in trunk, right?
[16:26] <smoser> when would i expect that http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ would have a 'utopic-netboot' entry like at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/
[16:26] <bdmurray> pitti: correct. it likely doesn't make a huge difference, but every little bit helps.
[16:27] <smoser> i'd expect it since linux-generic-lts-utopic and friends are available in trusty (https://launchpad.net/ubuntu/+source/linux-meta-lts-utopic)
[16:28] <smoser> normally i ping infinity by name for such queries. ;)
[16:29] <jdstrand> mardy: hi! I'm going to point you at tyhicks on the recommendation. ual *should* be doing the right thing, but tyhicks may have more insight
[16:29] <mardy> jdstrand: OK, thanks
[16:30] <apw> seb128, hmmm nope not noticed that one
[16:30] <seb128> apw, ok, now you did I guess ;-)
[16:30] <apw> yep now i did
[16:36] <tyhicks> mardy: sorry but I'm not very familiar with how the account plugins are being confined
[16:36] <tyhicks> mardy: I'll take a look at the code and will get back to you
[16:42] <mardy> tyhicks: the code is here: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/click-plugins/+merge/243296
=== cmagina_ is now known as cmagina
[16:48] <seb128> wgrant, hey, did you enable langpacks exports for vivid (dpm mentioned he usually pings you to enabled those)? (looking to https://translations.launchpad.net/ubuntu/vivid/+language-packs suggest it's not on yet?)
[16:58] <seb128> bdmurray, I got an email about https://errors.ubuntu.com/problem/e43c6a36473bb0fa132807674f9dff8bc5bbcf8e being a possible sru regression in "nautilus version 1:3.10.1-0ubuntu9.4 to trusty", but it has reports for 0ubuntu8 ... can you clear that off the list and let the update be rolled out?
[16:59] <seb128> bdmurray, do you know why the email was generated since 0ubuntu8 has reports and it's < 0ubuntu9.4?
[17:01] <bdmurray> seb128: likely because it was never reported about 9.3
[17:02] <seb128> bdmurray, k, I guess it's just random enough that that didn't happen yet
[17:02] <seb128> but it's not a regression from the change for sure
[17:02] <bdmurray> seb128: okay, I'll override it then
[17:04] <bdmurray> seb128: actually there were multiple emails about nautilus, I'll review all of them
[17:04] <seb128> bdmurray, thanks, let me know if you need more info/testing
=== greyback is now known as greyback|afk
[18:11] <tyhicks> mardy: hey - I got a chance to look at all the components involved
[18:12] <tyhicks> mardy: I think you're doing it the best way already by using ual
[18:13] <tyhicks> mardy: if you were actually spawning the process yourself then you'd need to use aa_change_profile but you're already trusting ual for so much that you might as well trust it for setting up proper confinement, too
[18:16] <tyhicks> mardy: also, if you called aa_change_profile(), then the plugin's profile would need to allow all of the stuff that libubuntu-app-launch does behind ubuntu_app_launch_start_multiple_helper()
[18:16] <tyhicks> that wouldn't be ideal
=== ValicekB_ is now known as ValicekB
[18:38] <rharper> arges: I'm trying to test out the updated qemu package for bug 1370199,  I've got trusty-proposed enabled, when I try a apt-get install qemu/trusty-proposed it shows the right package, but doesn't actually start the install ... what am I messing up?
[18:38] <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
[18:44] <arges> rharper: i'm not sure, can you pastebin the output?
[18:45] <rharper> http://paste.ubuntu.com/9333888/
[18:45] <rharper> arges: ^^
[18:59] <arges> rharper: how did you setup apt for enabling -proposed?
[18:59] <rharper> added the line from the wiki page
[19:00] <rharper> http://paste.ubuntu.com/9334116/
[19:05] <arges> rharper: i just did this today and the only difference was that I added the apt/preferences to change the pin priority
[19:05] <rharper> odd
[19:05] <rharper> ok, well, lemme try the apt/prefs
[19:05] <arges> rharper: can you try teh same with qemu-kvm instead?
[19:05] <rharper> yeah
[19:05] <arges> (not that i think that would make a different)
[19:06] <rharper> that worked
[19:06] <arges> perhaps its something to do with how qemu is packaged? maybe hallyn would have a better idea
[19:07] <rharper> arges: yeah.  thanks for the tip, testing out this now in a trusty container to see if the /dev/kvm gets created
[19:07] <rharper> thanks!
[19:33] <mardy> tyhicks: thanks a lot, that's good to know!
=== roadmr is now known as roadmr_afk
[20:00] <cyphermox> mterry: I was wondering if you could have another quick look at the three MIRs I submitted; the packages will be looked after by the desktop team
[20:02] <mterry> cyphermox, done
[20:03] <cyphermox> thanks
=== broder__ is now known as broder
[20:13] <wgrant> seb128: I see two langpacks on that page.
[20:14] <seb128> wgrant, what page?
[20:15] <wgrant> seb128: The langpack page you linked.
[20:17] <seb128> wgrant, is that an issue? I've not clue what needs to be done, dpm just hinted me that the export needs to be enabled
[20:18] <wgrant>  Full language pack: 2014-12-02 02:03:16 EST download icon
[20:18] <wgrant> The export *is* enabled, and there are langpacks there.
[20:23] <seb128> great
[20:23] <arges> rharper: so i believe bug 1292234 is an upstream issue, however the only variable that seems to cause it is using ext3 vs ext4 as the host filesystem. So this could be some obscure ext3 bug only triggered by qcow2 snapshotting...
[20:23] <ubottu> bug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed] https://launchpad.net/bugs/1292234
=== roadmr_afk is now known as roadmr
[21:12] <rharper> arges: I saw your update ... that's quite interesting...
[21:13] <rharper> arges: it still feels someone related to extent mapping, but i'm outta my depth w.r.t ext3 vs ext4 internals
[21:13] <arges> rharper: would there be ext3 features I could tweak to isolate that?
[21:13] <rharper> I don't think those are exposed
[21:13] <rharper> ext4 allowed for delayed extent allocation (hence the feature bit)
[21:14] <rharper> which allowed for more contiguous allocations by applications
[21:14] <rharper> we're using which cache mode?
[21:14] <rharper> default?  writeback ?
[21:14] <rharper> writethrough is default (aka O_DSYNC)
[21:15] <arges> rharper: writethrough
[21:15] <rharper> I wonder if playing with the mode there matters much ... eaiser to play with if we have a reasonable reproducer -- will kick that off sometime today ; need to create an ext3 filesystem to play with though
[21:16] <arges> rharper: i also tested with latest and greatest qemu/linux and it still reproduces. so afaik this is an upstream issue somewhere
[21:17] <rharper> arges: but older qemu works ok?
[21:17] <rharper> aka, qemu-kvm 1.0 or whatever was packaged in precise ?
[21:17] <arges> rharper: i should check that out... could reverse bisect
[21:18] <rharper> right, I suspect it's related to IO flushing....
[21:19] <rharper> arges: if the recreate ever gets really reliable, there is a block io system trace which might prove interesting to compare between versions
[21:20] <arges> rharper: it seems fairly reliable... we could just set it in a loop to retry like 5 times
[21:20] <rharper> i'd be really surprised if it was an actual ext3 bug
[21:20] <arges> me too
[21:20] <rharper> more likely an application error with flushing data .. it's not like the fs is corrupt
[21:20] <rharper> rather data within the file is
[21:22] <rharper> arges: so something with trying is to use cache=directsync (aka OSYNC|ODSYNC)
[21:22] <rharper> err, ODSYNC and ODIRECT -- sync writes and no host page-caching
[21:23] <arges> rharper: i'll give that a shot
=== yp is now known as Guest72231
=== barry` is now known as barry_
=== slangase` is now known as slangasek
=== roadmr_ is now known as roadmr
=== barry_ is now known as barry
[21:32] <arges> rharper: cache=directsync still shows the failure
=== Pici is now known as Guest74903
=== xnox_ is now known as xnox
=== Guest72231 is now known as ypwong
=== Trevinho_ is now known as Trevinho
=== robru_ is now known as robru
=== psivaa_ is now known as psivaa
[21:59] <rharper> arges: interesting ...
[22:00] <rharper> very confusing why this is a ext3 only issue...
=== sarnold_ is now known as sarnold
=== salem_ is now known as _salem