=== freeflying is now known as freeflying_away
[00:50] <xnox> Laney: did i break transition tracker or has it not updated yet?
[00:51] <xnox> (see my recent commits on +junk)
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
[05:04] <pitti> Good morning
=== freeflying_away is now known as freeflying
[06:34] <tvoss_> doko, ping
[06:38] <tvoss_> cjwatson, you might know, too: which package contains the STL pretty printers for gdb?
[06:47] <tvoss_> doko, we are looking into getting pretty printers for the STL working and would need some help :)
[06:58] <pitti> RAOF: hey Chris, how are you?
[06:58] <pitti> RAOF: are you still doing SRU? it would be great if some SRU member could accept the postgresql uploads for all releases (it has an MRE, no packaginag changes, all auto-tested, so shoudl be easy)
[06:58] <pitti> people keep asking me for them..
[06:59] <RAOF> pitti: Sure.
[07:13] <dholbach> good morning
[07:16] <RAOF> pitti: 9.1 or 8.4?
[07:16] <RAOF> pitti: Or, I guess, both?
[07:16] <pitti> RAOF: both for precise, 9.1 for quantal/raring, 8.4 for lucid
[07:16]  * RAOF will deal with that after dinner, it seems.
[07:17] <rbasak> infinity: what do you think about an SRU for http://launchpadlibrarian.net/144462697/dpkg_1.16.10ubuntu2_1.16.10ubuntu3.diff.gz? We're backporting juju-core for the cloud archive, to build against a barely modified Precise, and so I we need to carry that dpkg patch - either in the cloud archive or as an SRU in precise-updates.
[07:18] <rbasak> I assumed we'd need to carry it but just noticed 1.16.1.2ubuntu7.1 and wondered.
[07:18] <rbasak> (we'll probably need to carry it in the short term anyway, so we can have a working juju-core on Thursday)
[07:21] <pitti> RAOF: thanks (btw, no need to actually review the upstream diff that much)
[07:28] <pitti> slangasek, xnox: I tested automatic and manual partitioning with EFI in qemu, and manual partitioning on my workstation, and it has always worked, so it seems this bug either got fixed, or I can't reproduce it any more
[07:39] <soren> cjwatson: I'd never heard of RUNPATH before... Reading the docs about it, I'm a bit confused then RPATH would be preferable over over RUNPATH  (particularly since man ld-linux.so(8) explicitly says RPATH is deprecated).
[08:15] <Laney> xnox: looking
[08:15] <xnox> Laney: thanks.
[08:15] <Laney> woah
[08:16] <Laney> didn't expect you to be up
[08:16]  * xnox why not?
[08:16] <Laney> 14/10 01:50:54 <xnox>
[08:16] <xnox> oh that... =) well..... release week jibbies.
[08:17] <infinity> mlankhorst: xdiagnose could do without all the .git noise in the package.  Can you build it with '-i -I'?
[08:17] <mlankhorst> yeah just delete it, I'll ask for tjaalton to responsor, didn't notice it. :P
[08:19] <infinity> rbasak: I'd be happy to SRU that back ASAP.
[08:19] <infinity> rbasak: It's easy enough to validate and push through without a 10-day wait, IMO.
[08:20] <rbasak> infinity: thanks. I'll get on to it now then. What do you think about regressions for rebuilds of other armhf packages? I can't think of anything specific, but it does seem to have a rather large window.
[08:21] <infinity> rbasak: Hrm?  It shouldn't cause any regressions.
[08:21] <infinity> rbasak: I need to SRU to add ppc64el too, let me prep it.
[08:22] <rbasak> infinity: yeah I can't think of anything either. Just that it has the potential to impact many things.
[08:22] <rbasak> infinity: OK, I'll leave the patch/upload to you then? I'll do the bug paperwork.
[08:22] <infinity> rbasak: It shouldn't impact anything.  If things have the new ABI tags, they'd pass both tests, if they lack the new ABI tag, they'll fall through to the old test, if they lack both, they'll fail as always.
[08:23] <rbasak> Right.
[08:23] <infinity> rbasak: And yes, please SRUify the bug for me, that would be great.
[08:23] <Laney> xnox: It has the revision, waiting to see if it runs normally
[08:27] <caribou> I need advice from someone familiar with start-stop-daemon in init-scripts;
[08:27] <caribou> the stud init-script stop portion uses --pidfile (as the start section) which restricts the SIGKILL to the parent PID
[08:27] <caribou> if I understand it correctly
[08:28] <caribou> but STUD has children processes so when we do 'invoke-rc.d stud restart', the start comes in while the children still have the socket open and fails
[08:29] <caribou> bug 1123950
[08:29] <ubottu> bug 1123950 in stud (Ubuntu Precise) "/etc/init.d/stud restart does not start the daemon" [Medium,In progress] https://launchpad.net/bugs/1123950
[08:30] <caribou> my question is : would it be a problem to remove the --pidfile from the 'start-stop-daemon --stop' while keeping it in use in the 'start-stop-daemon --start' section ?
[08:31] <caribou> the --pidfile in the start section is required so STUD can start multiple instances
[08:32] <xnox> Laney: looks good. Hm I wonder why it didn't update before? how often is it cronned for?
[08:32] <xnox> Laney: (after the move)
[08:33] <Laney> I found a missing occurence of arm64
[08:33] <Laney> (in the runner script)
[08:35] <rbasak> infinity: the bug is ready
[08:35] <rbasak> (bug 1187722)
[08:35] <ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,New] https://launchpad.net/bugs/1187722
[08:36] <cjwatson> tvoss_: I always assumed those were in the gdb package itself
[08:36] <cjwatson> soren: I think RUNPATH is generally better, it's just newer
[08:39] <infinity> rbasak: Cool, I'll upload today, and we co do a quick verification turnaround.
[08:39] <infinity> rbasak: Verifying my ppc64el change takes about half a second, so that won't hurt your chances. :)
[08:39] <rbasak> Thank you!
[08:39] <rbasak> jamespage: ^^ infinity will SRU the dpkg fix to Precise
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[09:06] <xnox> Laney: ah, ok. and why is boost1.53 still there? i thought that should be auto-garbage collected (or is it removed only after X days of not being updated or some such?) /me's memory is fuzzy
[09:07] <Laney> xnox: 3 days
[09:07] <infinity> caribou: The point of pidfile is to limit the stopping to only the thing you started.  If children take a while to eff off, you might want to find a way around that...
[09:09] <caribou> infinity: yeah, I understood that, but in the case of stud, it loops through the whole set of parents to stop them anyway so I thought that stopping all procs at once would be acceptable
[09:10] <infinity> caribou: It loops through all the parents *it started*, I assume.  Not all the occurrenced of that process name on the host.  Subtle, but important, difference.
[09:10] <caribou> infinity: the alternative is to have stud manage the ramping of of his children when the parents is told to exit, which is what the Debian maintainer suggest
[09:10] <infinity> caribou: Having the parent not exit until all the children do is probably the right answer.
[09:11] <caribou> infinity: indeed; ok that answers my query; thanks
[09:12] <caribou> infinity: in the case of stud; it does stop --pidfile on all the stud configurations present in /etc/stud so that would be all of them anyway but it is indeed a better solution
[09:13] <infinity> caribou: That's not all of them on the system, that's all of them on that root.
[09:13] <infinity> caribou: Think chroots.
[09:14] <caribou> infinity: yup, true I have too much of a server centric view
[09:14] <caribou> infinity: and this is *exactly* the clarification I was after!
[09:14] <infinity> caribou: I have a server-centric view too, clearly just different types of servers. ;)
[09:16] <caribou> infinity: btw, we have a current workaround to add a "sleep 1" in the start sequence that seems to work; does that sound like a valid option for SRU up until we get the final fix from Debian ?
[09:16] <caribou> I have a debian bug opened on this one btw
[09:17] <infinity> caribou: A sleep is an icky but valid workaround, a second seems optimistic, if it could potentially be under load or running on a slow machine.
[09:17] <caribou> bug 1123950
[09:17] <ubottu> bug 1123950 in stud (Ubuntu Precise) "/etc/init.d/stud restart does not start the daemon" [Medium,In progress] https://launchpad.net/bugs/1123950
[09:17] <caribou> infinity: ok, I'll look into it
[09:44] <infinity> rbasak: What was the bug number for that?  I didn't seem to mention it in my previous changelog entry (naughty me).
[09:47] <rbasak> infinity: bug 1187722
[09:47] <ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,New] https://launchpad.net/bugs/1187722
[09:56] <infinity> rbasak: http://paste.ubuntu.com/6235232/ <-- Sanity check.
[09:56]  * rbasak looks
[09:59] <rbasak> infinity: lgtm
[10:05] <infinity> rbasak: Alright, I'll do a quick test build and local test and then upload and see if I can find a fellow SRU member to review and let it in for me.
[10:10] <rbasak> infinity: FWIW, before I spoke to you earlier I verified that the patch applied against dpkg precise successfully builds saucy golang on precise. Just another (non-SRU-team, non-dpkg-uploader) data point.
[10:11] <infinity> rbasak: Shiny, it's uploaded.
[10:11] <infinity> cjwatson: Can I get you to do a quick SRU review of dpkg in precise-proposed?  We need to fasttrack this for server team stuff.
[10:19] <cjwatson> infinity: done
[10:19] <infinity> cjwatson: Danke.
=== Sweetsha1k is now known as Sweetshark
=== tkamppeter_ is now known as tkamppeter
[10:54] <infinity> rbasak: Once that builds, want to re-verify your bug with the archive binaries?  I'll verify my bug.
[10:55] <infinity> rbasak: Oh, look, it's already built and published, even.
[11:01] <rbasak> infinity: ack. Working on it.
=== MacSlow is now known as MacSlow|lunch
=== gusch is now known as gusch|lunch
[11:03] <wgrant> didrocks: Around? unity needs a trivial arm64-specific patch to build there (just extending the existing -fPIC that's conditional on amd64 and armhf to arm64). But it would need to be uploaded quickly.
[11:04] <wgrant> didrocks: Is it reasonably practical to get something like that in ASAP, or does the autolander make it awkward?
[11:04] <didrocks> wgrant: we can always fast-pass the merge in trunk
[11:04] <didrocks> wgrant: let me look at what's in trunk that was not released
[11:04] <wgrant> I'll pretend I know what that means.
[11:04] <infinity> Ideally very fast, I intend to lock down the archive for seeded uploads after I've had lunch.
[11:05] <infinity> But I'd like to see this fix in for kicks, if we can make it.
[11:05] <didrocks> wgrant: first, do you have a MP somewhere?
[11:05] <wgrant> No, I'm still downloading the branch
[11:05] <wgrant> if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
[11:05] <wgrant> is the line, needs to also match "aarch64"
[11:06] <didrocks> infinity: there are 2 commits in unity trunk that are not released yet, if I test that quickly, does the release team +1 for them?
=== freeflying is now known as freeflying_away
[11:08] <infinity> didrocks: Toss me a quick diff somewhere?
[11:08] <infinity> didrocks: But if they're both bugfixes and obviously sane, I'm fine with that.
[11:09] <didrocks> infinity: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3567 and http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3568
[11:10] <didrocks> they seem sane to me, I want to give them a 10 minutes poke first though
[11:10] <lool> didrocks, infinity: http://paste.ubuntu.com/6235437/
[11:10] <lool> debdiff
[11:13] <infinity> didrocks: Both those look fine to me.
[11:13] <didrocks> infinity: I'm currently testing, as soon as wgrant has the MP ready, I'll push that and run a build
[11:13] <infinity> didrocks: If those test fine, and you grab wgrant's change, we'll call that the final non-SRU upload for the release. :P
[11:13] <didrocks> infinity: \o/
[11:14] <cjwatson> infinity: (ubiquity, possibly)
[11:14] <wgrant> No changelog change required?
[11:14] <didrocks> oh no, wanted to be the latest!
[11:15] <didrocks> wgrant: no, just give a sane commit message :)
[11:15] <infinity> cjwatson: I meant the final non-sru unity upload.
[11:15] <infinity> cjwatson: I'm confident that we'll have installer uploads.
[11:15] <infinity> cjwatson: I have to do one or two myself still. :/
[11:16] <infinity> Okay, lunch.  Back in a bit.
[11:16] <cjwatson> ah right
[11:19] <wgrant> didrocks: https://code.launchpad.net/~wgrant/unity/arm64-pic/+merge/190919
[11:20] <didrocks> wgrant: pushing your change to trunk and then kicking a rebuild
[11:20] <didrocks> thanks :)
[11:20] <wgrant> Thank you :)
[11:22] <lool> didrocks: are you running the ci stuff?
[11:22] <lool> didrocks: can kick it if you like
[11:22] <didrocks> lool: already on the page
[11:22] <didrocks> (started)
[11:22] <lool> already merged I guess
[11:23] <didrocks> yep
[11:23] <lool> and cu2d building ok
[11:32] <doko> tvoss_, hi
[11:33] <tvoss_> doko, hey
[11:33] <doko> tvoss_, should be in the libstdc++6-4.8-dbg package
[11:33] <tvoss_> doko, those are all python2, and gdb is linked against python 3
[11:35] <doko> tvoss_, wait, I had a patch for that ...
[11:36] <tvoss_> doko, would be quite helpful :) plus: can we wire that up to our retracing infrastructure, too? Would love to have more readable stack traces
=== freeflying_away is now known as freeflying
=== tvoss_ is now known as tvoss|dentist
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
[12:16] <steveire> Is it known that clang++ doesn't work with the stl in 13.10?
=== gusch|lunch is now known as gusch
[12:18] <steveire> http://pastebin.kde.org/pzd9fvzs2
=== tvoss|dentist is now known as tvoss
[12:59] <tvoss> doko, did you have any luck digging up your patches?
[13:08] <sabdfl_> hi folks, quick q re whoopsie in syslog
[13:09] <sabdfl_> seems like I have a steady stream of debugging info there - whoopsie online / offline
[13:09] <sabdfl_> is that expected, or a bug? can we dial back on the chatter?
=== sabdfl_ is now known as sabdfl
=== mbiebl_ is now known as mbiebl
[13:17] <ev> sabdfl: yes, filed as https://bugs.launchpad.net/whoopsie/+bug/1239690
[13:17] <ubottu> Ubuntu bug 1239690 in Whoopsie "syslog doesn't need to know about offline / online" [Medium,Confirmed]
=== zyga-to-canada is now known as zyga
[13:35] <doko> tvoss, won't be for saucy
[13:36] <tvoss> doko, can you point me to the patch?
[13:37] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches/libstdc%2B%2B-python3.diff?view=log
[13:39] <sabdfl> ack, thanks ev
[13:39] <rbasak> infinity: verification-done on bug 1187722. Thanks!
[13:39] <ubottu> bug 1187722 in dpkg (Ubuntu Precise) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [Undecided,Fix committed] https://launchpad.net/bugs/1187722
[13:56] <tedg> xnox, Hmm, did you push to this branch?  https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190847
[13:56] <xnox> tedg: yes.
[13:56] <xnox> tedg: on behalf of doko (he didn't want to deal with branches/upstream merger / daily landing etc)
[13:57] <tedg> xnox, Hmm, seems LP doesn't think there's any diff...
[13:57] <xnox> tedg: i believe that's in the archive already thus, needs merge into upstream branches to unbreak integration.
[13:57] <xnox> tedg: LP sent me an OOPS via email failing to generate diff.
[13:57] <cjwatson> LP is on "updating diff" implying it oopsed
[13:57] <cjwatson> xnox: delete the branch and repush
[13:57] <cjwatson> (and probably re-MP)
[13:57] <xnox> cjwatson: ok.
[13:57] <cjwatson> that's usually the simplest way
[13:58] <xnox> hm, branch is updating as well.
[13:58] <cjwatson> might want to keep the MP window open in a tab :)
[13:58] <cjwatson> s/window //
[13:58] <cjwatson> xnox: same thing
[13:58] <xnox> ack.
[13:58] <cjwatson> rare on small branches, sadly pervasive on large ones like ... er, LP itself
[13:59] <cjwatson> so I've got used to it
[13:59] <xnox> ok. first time happening to me =)
=== JanC_ is now known as JanC
[14:08] <xnox> tedg: https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190967
[14:08] <xnox> tedg: better?
[14:09] <tedg> xnox, No hugs and kisses in the MR? ;-)
[14:09] <tedg> xnox, Thanks!  Approved.
[14:09] <xnox> =)
[14:10]  * xnox blows a kiss to PS jenkins integrator
=== shadeslayer_ is now known as shadeslayer
=== davidcalle_ is now known as davidcalle
[15:09] <psusi> anyone know how to translate a UTF-16 string into whatever the native C string format the process is using?
[15:20] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
[15:22] <xnox> psusi: libicu?
[15:23] <tvoss> slangasek, ping
[15:24] <pitti> psusi: wcrtomb() convers a wchar_t string to an UTF-8 char string; that might be what you want?
[15:24] <pitti> psusi: sorry, that's for an individual character; you probably want wcsrtombs()
[15:25] <psusi> pitti: I don't have a wchar_t, I have UTF-16
[15:26] <pitti> psusi: iconv_open("UTF-16", "UTF-8");
[15:26] <pitti> psusi: or use libicu (haven't tried that, though)
[15:26] <psusi> there's really nothing in the standard C library to do that?
[15:26] <psusi> I hate to add another dependency
[15:27] <cjwatson> libiconv is a bit fiddly but not hopelessly painful
[15:27] <cjwatson> If you're already using glibc, it's there
[15:27] <pitti> libiconv is reasonably close to glibc, isn't it?
[15:27] <psusi> ohh
[15:27] <cjwatson> It's built into glibc on GNUish systems
[15:27] <cjwatson> It's not in every libc
[15:27] <psusi> well here's the other thing... I don't know if I want to convert it to UTF-8... doesn't the locale determine the proper encoding, which may not be UTF-8?
[15:28] <cjwatson> nl_langinfo (CODESET)
[15:28] <pitti> yes, that's right; if you want to directly show that on stdout or so (most toolkits actually always expect UTF-8 as input regardless of the locale)
[15:28] <cjwatson> again somewhat libc-dependent, there are bits in e.g. gnulib to help
[15:29] <cjwatson> so with gnulib it's locale_charset ()
[15:29] <psusi> well parted right now is using the w*mb* family of functions and passes around char *
[15:29] <cjwatson> parted uses gnulib, so it wouldn't be particularly painful to add more modules from there
[15:29] <cjwatson> in fact you already have locale_charset
[15:30] <cjwatson> and for that matter all the iconv bits
[15:30] <doko> xnox, did you get feedback from ev about whoopsie's b-d on valgrind?
[15:30] <psusi> the problem seems to be that when it reads a UTF-16 string from the gpt, it discards the upper 8 bits and calls it a char *... for non ascii strings, that leaves it with bogus encodings when it tries to convert that to wchar_t from the locale encoding
[15:31] <cjwatson> if you have a known source encoding you should store it in that encoding if you need to round-trip, and iconv to the locale encoding for display
[15:31] <psusi> so I need a char * that instead has valid encodings in whatever the correct locale is
[15:31] <cjwatson> char * is just a sequence of 8-bit characters, it would depend on the function you're using to read into it what gets discarded, not on the type as such
[15:31] <xnox> doko: he is in front of me, and says he does not care for saucy about that =)
[15:32] <xnox> doko: since no-one will be using whoopsie for a while on arm64.
[15:32] <cjwatson> although for the case you're talking about I would be inclined to treat the GPT data as a byte array except when converting for display
[15:32] <psusi> right.. the function just has a loop assigning each 16 bit source char to an element in the char *, thus discarding the upper 8 bits
[15:32] <xnox> doko: i'll fix it in saucy? or do you want it for bragging points?
[15:32] <cjwatson> haha
[15:33] <cjwatson> yeah, that's not too smart
[15:33] <psusi> the name is displayed and I think also sometimes substitued into messages that are then translated with gettext
[15:33] <cjwatson> But surely the code itself gives you the answer
[15:33] <cjwatson>   char name[37];
[15:33] <cjwatson>   for (i = 0; i < 72 / sizeof (efi_char16_t); i++)
[15:33] <cjwatson>     gpt_part_data->name[i] =
[15:33] <cjwatson>       (efi_char16_t) PED_LE16_TO_CPU ((uint16_t) pte->PartitionName[i]);
[15:34] <cjwatson> rather suggests (reasonably) that name should be an array of efi_char16_t
[15:34] <psusi> so with the 8 high bits chooped off, it doesn't survive the trip through gettext to wchar_t and back to utf-8 for printing
[15:34] <psusi> cjwatson: sure, but then get_name and set_name only pass/excpect a char *
[15:34] <psusi> so it needs converted
[15:34] <cjwatson> either that, or, if it's more convenient for iconv, a byte array in whatever endianness is correct
[15:35] <cjwatson> psusi: right, get_name and set_name are to/from display clearly, and want converters at their borders
[15:35] <cjwatson> psusi: but I'd suggest that you should otherwise store in a fairly raw format, since otherwise you may introduce round-trip errors
[15:35] <doko> xnox, just did see avtivity-log-manager dep-waiting, but that's an ev package too. but well, with his new hat on ... ;)
[15:35] <psusi> aye
[15:36] <cjwatson> the user's encoding may not be able to represent all the characters in the label, for instance
[15:36] <psusi> right
[15:36] <cjwatson> iconv () takes pointers to char * buffers
[15:36] <cjwatson> which is fair enough, so that would suggest you just want to fix the loop there to be less rubbish
[15:37] <cjwatson> I can sort of see what it's trying to do in _partition_generate_part_entry
[15:37] <psusi> yea... fix the terrible loop, and convert in the get/set methods
[15:37] <cjwatson> You could instead do *((efi_char16_t) &gpt_part_data->name[i]) = ...
[15:38] <cjwatson> or something like that.  But I'm not sure that's the clearest option
[15:39] <cjwatson> actually i * 2 and bump the size of the array
[15:39] <cjwatson> you get the idea :)
[15:40] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
[15:41] <cjwatson> psusi: bug 1220165 is indeed weird, but reproducible every time here.  I wish we were using udev cookies in the right way
[15:41] <ubottu> bug 1220165 in parted (Ubuntu) "Error informing the kernel about modificatons" [Critical,Triaged] https://launchpad.net/bugs/1220165
[15:42] <psusi> cjwatson: iirc, cookies are a device-mapper thing arent' they?
[15:42] <cjwatson> psusi: they're a fairly general concept that device-mapper happens to be one thing that implements
[15:42] <psusi> cjwatson: so who is adding the partition?  did we enable a partx rule or something?  a change event that makes someone else open the device shouldn't cause that...
[15:43] <cjwatson> I've seen buggy udev rules in the past that responded to change events that way
[15:43] <cjwatson> they're a proper nightmare to track down
[15:43] <psusi> what way?
[15:43] <cjwatson> by opening the device ...
[15:43] <psusi> sure, we have plenty of those
[15:43] <psusi> but they won't cause that error
[15:43] <cjwatson> oh I think I see what you mean
[15:43] <cjwatson> hmm
[15:44] <psusi> this has to be someone else actually ADDING the partition, after it has successfully been removed
[15:44] <cjwatson> I wish I could find a way to instrument this without it vanishing
[15:44] <psusi> can you set a kprobe on the blkpg stuff?
[15:44] <psusi> or trace
[15:45] <xnox> doko: pushed fix to lp:whoopsie, but infinity doesn't want it in, as it wasn't ev who proposed the fix =))))))
[15:45] <psusi> and besides partitioning tools, the only other thing I know of that adds partitions is partx
[15:45] <psusi> so unless someone added a udev rule to run partx -a...
[15:46] <cjwatson> there is /lib/udev/rules.d/95-partx.rules
[15:46] <cjwatson> kpartx sorry
[15:46] <cjwatson> (and a similar thing for dmraid but I doubt it's that)
[15:46] <psusi> right, those only apply to dm
[15:47] <cjwatson> the kpartx rules should also only be for dm-*
[15:47] <cjwatson> but, let me try removing them and seeing what happens
[15:48] <cjwatson> nope, not kpartx
[15:48] <psusi> blast... doesn't seem to be a kernel trace event in the partition add path
[15:48] <psusi> yea, kpartx just creates a new dm device anyhow, doesn't know about BLKPG
[15:49] <psusi> it's regular partx that does that
[15:49] <psusi> unless... someone is calling BLKRRPRT?
[15:51] <cjwatson> I could strace -f udevd; it'll probably make the bug vanish, but I could look for block ioctls
[15:51] <psusi> I'd say kprobe it at the source in the kernel... get exactly what you want without dragnetting and changing timing
[15:52] <psusi> just one printk in those two ioctls
[15:52] <cjwatson> psusi: I can't realistically install a new kernel; which existing trace event would you suggest?
[15:52] <cjwatson> (I've not used kprobes before - if you have a recipe I'd appreciate it)
[15:52] <psusi> I don't see an existing trace event... and I've not yet figured out how to use kprobes myself either
[15:53] <psusi> but supposedly it is fairly simple to add a printk somewhere, build and insert the module, and bam
[15:54] <psusi> where fairly simple is, as usual, once you climb the initial learning curve ;)
[15:54] <cjwatson> stracing udev didn't perturb the bug away, actually
[15:54] <cjwatson> but it also doesn't show any BLKPG* or BLKRRPART
[15:55] <psusi> it wouldn't be issued by udev directly but by something it executes
[15:55] <cjwatson> yes I used -f, of course
[15:55] <psusi> ahh, right
[15:55] <cjwatson> are you sure that a duplicate add is the only possible cause of EBUSY here?
[15:56] <psusi> only way I can see... you only get to the add call if the remove succeeds or fails with ENXIO
[15:56] <cjwatson> also happens if the add attempt overlaps an existing partition
[15:57] <psusi> i.e. the device was removed, or already does not exist
[15:57] <psusi> ohh, right
[15:57] <psusi> aha!
[15:57] <cjwatson> or if the partition number already exists, or if kzalloc fails
[15:58] <psusi> I bet it's overlapping
[15:58] <cjwatson> let me strace parted_server to see what it's doing
[15:59] <psusi> yea... didn't think of this when I made the patch to avoid removing and re-adding unmodified partitions
[16:00] <psusi> there's a higher numbered partition ( thus has not been removed yet ) that overlaps with the partition we are trying to add
=== Amaranthus is now known as Amaranth
[16:02] <psusi> yea... that loop needs to be split in two passes... first remove partitions that don't match the new table, then loop again adding the new ones after the first loop has already removed all of the modified old ones
[16:04] <psusi> so yea, it isn't a race at all ;)
[16:06] <cjwatson> 17:00 <cjwatson> psusi: hm, this is an "erase disk" install
[16:06] <cjwatson> 17:01 <cjwatson> psusi: but maybe some of the partitions happen to coincide in extent
[16:06] <cjwatson> psusi: yes, looking at the trace, there's an add with no matching remove
[16:06] <psusi> working up a patch now
[16:07] <cjwatson> what's the bug?  you're a little ahead of me here
[16:07] <cjwatson> in fact, it's attempting a resize, not an add
=== chrisccoulson_ is now known as chrisccoulson
[16:07] <cjwatson> 4041  16:02:52.716798 ioctl(6, BLKPG, {0x3 /* BLKPG_??? */, flags=0, datalen=152, {start=1048576, length=52613349376, pno=1, devname="/dev/sda1", volname=""}}) = -1 EBUSY (Device or resource busy)
[16:07] <psusi> I guess you lagged out... I think there's an existing partition on the disk that we are wiping out and it overlaps the new partition we are trying to add
[16:08] <psusi> but it has a higher partition number than the one we are trying to add
[16:08] <cjwatson> 3 == BLKPG_RESIZE_PARTITION
[16:08] <cjwatson> just checking that theory against the logs
[16:08] <psusi> so it hasn't been removed yet
[16:08] <cjwatson> yeah, that's right
[16:08] <cjwatson> prior state:
[16:09] <cjwatson> 1   1048576-28468895231     28467846656     primary ext4
[16:09] <cjwatson> 6   28469886976-52615446527 24145559552     logical ext4
[16:09] <cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
[16:09] <cjwatson> desired state:
[16:09] <cjwatson> 1   1048576-52614397951     52613349376     primary ext4    /dev/sda1
[16:09] <cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
[16:09] <slangasek> tvoss: asynchronous pong
[16:09] <tvoss> slangasek, pong
[16:10] <tvoss> ah, sorry :)
[16:10] <tvoss> slangasek, wanted to check on the mem leak? was that fixed?
[16:12] <slangasek> tvoss: it is not fixed, we haven't root caused it yet; jodh has been working on it
[16:12] <slangasek> tvoss: please pick his brain about the progress :)
[16:12] <tvoss> slangasek, yup :)
[16:12] <tvoss> jodh, ^
=== charles_ is now known as charles
=== dpm is now known as dpm-afk
[16:27] <cjwatson> psusi: more than happy to test things here BTW
[16:27] <cjwatson> since I have a nice 100% reproducer handy
[16:29] <psusi> cjwatson: about to email you the git patch
[16:29] <cjwatson> psusi: awesome
[16:37] <jodh> tvoss: still investigating I'm afraid: putting together a simple dbus server + client (without upstart and (with+without) nih) to try to simulate the problem.
[16:37] <jodh> tvoss: trigger it even.
[16:37] <tvoss> jodh, is there any way we can get valgrind results?
[16:38] <jodh> tvoss: there are valgrind logs on the bug if you're interested. However, neither I nor slangasek have been able to get it to show the leak.
[16:39] <psusi> cjwatson: patch sent... I haven't tested it though
[16:39] <tvoss> jodh, do you have a theory in which subcomponent the leak might occure?
[16:40] <jodh> tvoss: all our findings are on the bug. We believe the problem is in libdbus "somewhere". That's about as much detail as we've got so far.
[16:42] <psusi> off to lunch
[16:42] <cjwatson> psusi: OK, I'll look it over, thanks!
[16:50] <tvoss> jodh, looking, thx
[16:54] <jodh> tvoss: progress! see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/59
[16:54] <ubottu> Ubuntu bug 1235649 in unity (Ubuntu Saucy) "uevent spam causes libdbus client code in session upstart to consume massive amounts of memory on Ubuntu Touch" [Undecided,New]
[16:59] <tvoss> jodh, \o/
[17:01] <tvoss> jodh, might be an artifact of pool allocation, though
[17:01] <tvoss> jodh, a though: does nih replace libdbus memory allocation routines? I would think that it tries to force libdbus to allocate from a preallocated memory slice to avoid malloc at all cost
[17:03] <jodh> tvoss: no - nih does have its own alloc rouintes. But it just makes libdbus calls and is careful to document which nih routines return memory managed by dbus rather than nih.
[17:04] <tvoss> jodh, got a link to source?
[17:05] <jodh> tvoss: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libnih/saucy/files/head:/nih/
[17:06] <infinity> sarnold: Any hope for bug #1220434?
[17:06] <ubottu> bug 1220434 in curtin (Ubuntu) "[MIR] curtin" [Undecided,New] https://launchpad.net/bugs/1220434
[17:18] <DiegoTc> hi bkerensa
[17:18] <DiegoTc> hi lfaraone
[17:20] <apachelogger> pitti: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/446 it appears you'll also need to add kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer
[17:21] <apachelogger> or source package kubuntu-debug-installer kubuntu-firefox-installer kubuntu-web-shortcuts kubuntu-notification-helper
[17:22] <apachelogger> oh, template list is actualy  kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer notificationhelper kcm-notificationhelper
[17:30] <DiegoTc>  /join #ubuntu-locoteams
[19:10] <Riddell> apachelogger: I am not sure thy will need to be added to the language packsbeacuse they are in universe
=== thomi_ is now known as thomi
[19:43] <tedg> ev, What's the LP project for the geoip data?
[19:51] <thad_> pitti: logind gets stuck in PrepareForSleep mode after suspend/hibernate, it happens occasionally, but I already saw it on two complete different machines. should I file a new lp report or continue commenting on this one bug 1234469 ?
[19:51] <ubottu> bug 1234469 in network-manager (Ubuntu) "Network does not come up after resuming from suspend." [Medium,Confirmed] https://launchpad.net/bugs/1234469
[19:54] <pitti> thad_: I think that bug is the very issue, so continuing investigation there is fine
[19:56] <thad_> pitti: alright, guess I'll test kernel 3.10 and 3.12 to get some more information, not quite sure how to debug this systemd/logind "madness" :)
[19:57] <pitti> thad_: thanks; you can run logind in the foreground to see what it's doing, perhaps there's an error message somewhere
[19:59] <thad_> ok, hopefully I can gather some useful debugging information
[20:15] <psusi> so what if characters can't be reprepsented in your current code page?  it looks like iconv fails the conversion by default, or has an option to ignore... shouldn't you substitute a generic block like character like you get when you don't have the correct font installed?
[20:51] <cjwatson> psusi: sounds like you want //TRANSLIT
[20:51] <cjwatson> psusi: changing the default behaviour would break things that use iconv to tell whether something is valid text in a given encoding
[20:51] <psusi> cjwatson: the man page says it tries to use multiple similar characters, but isn't clear on what happens if it just plain won't work... like if you are using straight asci or latin1
[20:52] <cjwatson> You tend to get "?" for ASCII//TRANSLIT
[20:52] <psusi> ok... sounds good then, maybe I'll use that
[20:53] <psusi> cjwatson: that patch work out earlier?
[20:53] <cjwatson> Just testing it now following your clarification
[20:54] <cjwatson> That still fails, but a bit differently
[20:54] <cjwatson> Now fails to add (or resize?) /dev/sda5
[20:55] <psusi> what's sda5?
[20:55] <cjwatson> Which is odd since that should've been in the exact same position as before
[20:56] <cjwatson> Yeah, same before and after
[20:56] <cjwatson> 5   52615446528-53686042623 1070596096      logical linux-swap      /dev/sda5
[20:57] <cjwatson> Oh, you have no handling in the add loop for same start/length before and after
[20:58] <psusi> doh!
[20:59] <cjwatson> so lift the start/length handling up out of the ifdef I guess
[20:59] <cjwatson> want me to just do the obvious fix?
[20:59] <psusi> sure
[21:00] <psusi> it's just slightly tricky because of the #ifdef for the resize
[21:00] <psusi> you want to handle unchanged partitions with or without the resize
[21:01] <psusi> bbl, heading home
[21:36] <cjwatson> psusi: This is looking better now - http://paste.ubuntu.com/6237966/
[21:36] <cjwatson> (My changes are around lines 81-105)
[21:38] <cjwatson> Seems to work, trying a resize
[21:43] <psusi> cjwatson, looks good
[21:43] <cjwatson> There's no single non-confusing view of this change, unfortunately, apart from looking at the patched source file
[21:44] <cjwatson> The patch is enough of a refactoring that it's difficult to read on its own, and a patch of the patch is even worse ...
[21:44] <cjwatson> psusi: Thanks very much for the help - I'll get this into Debian as well once I'm not in such a hurry
[21:45] <cjwatson> And have slept
[21:46] <psusi> hehe, yep
=== salem_ is now known as _salem
=== freeflying is now known as freeflying_away