[00:19] <slangasek> xnox: so I definitely have current bash-completion installed, and bash is definitely not completing filenames for me... I'm ready to start pulling my hair out :)
[00:38] <Unit193> slangasek: Yes, I have bash-completion problems as well, in Trusty and Debian.
[05:38] <pitti> Good morning
[06:48] <RAOF> pitti: Good morning.
[06:48] <pitti> hey RAOF
[06:52] <pitti> RAOF: thanks for the _add() error fix, just reviewed
[06:57] <RAOF> pitti: Are you likely to get around to implementing evemu-format playback support anytime soon?
[06:58] <pitti> RAOF: not in a matter of days, but if you guys need it for Mir I can add some priority to that
[06:58] <pitti> RAOF: so far nobody really needed it, so I didn't pay much attention to it
[06:58] <RAOF> Well, it looks like it's required for any acceptance tests with input recordings, thanks to the magic of time_t.
[07:02] <pitti> RAOF: yeah, or doing per-arch recordings
[07:02] <pitti> RAOF: record&replay generally is rather arch specific, at least with endianess
[07:02] <pitti> RAOF: most ioctls work (on the same endianess) as most of them are rather carefully constructed to work on multi-arch
[07:02] <pitti> RAOF: i. e. with explicit int lengths etc.
[07:03] <pitti> but pure user-space stuff often doesn't
[07:03] <RAOF> So are *almost* all of the evdev bits. Just the little time_t in struct timespec.
[07:03] <pitti> still weird why time_t wouldn't be 64 bit on 32 bit archs
[07:03] <RAOF> Because it wasn't in the past?
[07:04] <pitti> it'll change by 2038 :)
[07:04] <RAOF> Indeed :)
[07:17] <RAOF> Ok. Time to EOD anyway.
[07:30] <dholbach> good morning
[07:36] <mardy> Riddell: hopeful Monday pong :-)
[07:40] <dkessel> Good morning dholbach
[08:00] <dholbach> hi dkessel
[08:40] <xnox> slangasek: =( there are more bash-completion patches floating around, but i'm not sure about applying them.
[08:41] <xnox> slangasek: i'd rather see it fixed rather than reverting bash upload.
[08:41] <xnox> =/
[08:45] <StevenK> xnox: Or you could just tell people to use zsh? WCPGW, right?
[08:47] <xnox> StevenK: i'm sure i'll get more support to switch to eshell by default, than to switch to zsh.
[08:48] <StevenK> xnox: No, clearly we need to wait for Lennart to write a shell, then have multiple flamewars about switching to it as the default.
[08:50] <hyperair> and this shell shall have native pulseaudio and systemd integration!
[08:50] <hyperair> whatever that means
[08:51] <hyperair> (while also reimplementing all the functionalities of a DE)
[08:51] <darkxst> I *want* a shell with GNOME integration ;) who cares about auto-completion...
[08:51] <hyperair> lawl
[08:51] <darkxst> ^ it is sorely broken right now though ;(
[08:52] <hyperair> oh and it's going to be modular, so it'll have multiple daemons!
[08:52] <darkxst> hyperair, hang on, shouldnt it be monilithic so it takes however as much as possible?
[08:52] <hyperair> non non
[08:53] <hyperair> it should be modular, but everything needs to be in the same git repository because a lot of code will be shared between each module!
[08:53] <darkxst> "monolithic so it takes over as much as possible" apparently I can't type too well in the dark ;)
[08:53] <hyperair> well, systemd isn't monolithic
[08:54] <hyperair> it's just very "tightly integrated" with the rest of its other daemons
[08:54] <hyperair> like networkd or udev or the other stuff
[08:54] <zequence> Hi. Got a package that would need to be uploaded soonish. It's a FFe, and doesn't show in the sponsors queue. It was uploaded to the archives once already, but was rejected due to some lintian warnings, which are gone now Bug: 946591
[08:54] <hyperair> oh yes, here's the idea. the entire gnome should enter lennart-shell.git
[08:54] <hyperair> zequence: FFe approved or not?
[08:56] <zequence> hyperair: I need to ask in the mail list?
[08:56] <hyperair> zequence: try poking some ubuntu-release folk
[08:57] <zequence> This was not a FFe originally, but became one
[08:57] <zequence> hyperair: Ok. Thanks
[08:57] <hyperair> ^ that should trigger any hilight rules for ubuntu-release people lurking in the channel, so sit tight and wait, i think
[08:57] <hyperair> or you could ask in #ubuntu-release
[08:57] <hyperair> once the FFe's approved, you can get it uploaded
[08:58] <hyperair> is that for main or universe?
[08:58] <zequence> universe
[08:58] <zequence> ubuntustudio stuff
[08:58] <hyperair>  isee
[08:58] <hyperair> is the ubuntustudio stuff not in main?
[08:59] <zequence> no. I think only Canonical maintained is in there?
[08:59] <zequence> All of our packages are in universe
[09:00] <hyperair> i see
[09:00] <hyperair> okay, i can help you upload it once you get your FFe acked
[09:00] <zequence> ..except one, I think (ubiquity-slideshow-ubuntustudio)
[09:00] <zequence> hyperair: Thanks
[09:01] <zequence> (no, that one was in universe as well)
[09:23] <MacSlow> tsdgeos, hey Albert...
[09:23] <MacSlow> tsdgeos, can you re-check https://code.launchpad.net/~macslow/unity-notifications/dont-ignore-placeholder/+merge/206950
[09:24] <tsdgeos> MacSlow: sure
[09:24] <MacSlow> tsdgeos, I've updated the info and related MP-descriptions (explaining dependencies)
[09:24] <MacSlow> tsdgeos, thx
[09:31] <MacSlow> tsdgeos, yes... it the "PlaceHolder" for the synchronous notification (e.g. volume up/down) once we'll get a Design and UX for it.
[09:50] <jamespage> infinity, the libgcrypt11-dev preference change you made in percona-xtrabackup - is that something I should pick into my next upload in Debian?
[10:17] <Riddell> mardy: I uploaded signon-qt with a change to stop qt4 and qt5 cmake files overlapping
[10:21] <mardy> Riddell: thanks!
[11:42] <Mirv> there's a new hud release pending and tested, but I'd need a core dev ack for the packaging changes: http://162.213.34.102/job/landing-002-2-publish/55/artifact/packaging_changes_hud_13.10.1+14.04.20140314-0ubuntu1.diff
[11:48] <cjwatson> Mirv: ack assuming that somebody is also landing libdbusmenu-qt5-dev 0.9.3
[11:49] <mlankhorst> what exact date is quantal EOL?
[11:49] <didrocks> Mirv: does it build on arm64?
[11:50] <didrocks> not sure it was in the silo having it
[11:50] <Mirv> thanks colin, yes libdbusmenu-qt5-dev 0.9.3 is part of the same landing
[11:50] <Mirv> didrocks: yes it did
[11:50] <Mirv> (but not on powerpc/ppc64el)
[11:50] <didrocks> Mirv: excellent, one issue to remove from the list :)
[11:51] <didrocks> Mirv: yeah, expected
[11:51] <didrocks> thanks!
[11:52] <Mirv> mlankhorst: I'd expect Apr 18th, since it was release October 18th 2012
[12:01] <mlankhorst> ah k, it wasn't clear from the wiki
[13:43] <slangasek> xnox: so as noted, the tab completion is not the only regression I've seen; the change in reverse-search behavior and ^C handling are also rather disruptive.  Do you think we're going to get all of these fixed in time for 14.04?  If not, I think a revert is in order
[13:43] <slangasek> xnox: (and how did this even land, post-FF?)
[13:45] <xnox> slangasek: "how did this even land, post-FF", without FFe -> talk to the AA who upload it ;-)
[13:46] <slangasek> xnox: yes, I certainly will when he's back, just wondering if you knew some mitigating circumstances that I did not :)
[13:47] <xnox> slangasek: nah, just seb128 complaining a lot that "it should not have landed without FFe"
[13:47] <xnox> =)
[13:48] <seb128> it should not indeed
[13:57] <xnox> slangasek: there is a patch for bash posted that should fix unquoting/completion bugs. I don't see patches about reverse-search behaviour / ^C handling.
[14:02] <barry> xnox, slangasek what's the bug about revsearch and ^C?
[14:13] <slangasek> barry: revsearch> a failed revsearch, instead of giving you a visual bell, now just changes the prompt to 'failed reverse-i-search' and lets you continue typing
[14:14] <barry> slangasek: ew, yeah i see that too :(
[14:14] <slangasek> barry: ^C> if you're in the middle of a wrapped line and ^C, the prompt is placed at the next line below the current prompt, without clearing the text
[15:25] <cjwatson> infinity: https://launchpadlibrarian.net/168801577/buildlog_ubuntu-trusty-i386.installation-locale_1.5_FAILEDTOBUILD.txt.gz looks like an eglibc bug to me.  It's using 'copy "i18n"' in its LC_MONETARY declaration; eglibc's localedata/locales/i18n sets int_curr_symbol to "<U0058><U0044><U0052><U0020>" i.e. "XDR ", which http://www.iso.org/iso/currency_codes has registered to the IMF; but locale/iso-4217.def doesn't contain "XDR"
[15:25] <cjwatson> infinity: do you agree?  it looks as though a locale/iso-4217.def resync would fix this ...
[15:37] <bdmurray> tseliot: given that hybrid-detect is no longer in ubuntu-drivers common shouldn't /etc/init/hybrid-gfx.conf be changed?
[15:38] <tseliot> bdmurray: I forgot to make the package remove the file from /etc but I'll fix it soon
[15:39] <bdmurray> tseliot: okay, sounds good
[16:00] <cjwatson> pitti: Can you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5717053 (pkgbinarymangler)?  That's a lot of test failures
[16:02] <pitti> cjwatson: ouch, indeed; I'll look at that
[16:05] <cjwatson> thanks
[16:06] <pitti> cjwatson: I figure this is just a test issue, otherwise trusty would have exploded already; so not an "OMG drop everything immediately" emergency
[16:09] <cjwatson> Yeah, presumably
[16:10] <pitti> right, I get the very same in a local run now
[16:11] <pitti> finishing the phonesim PIN investigation, then looking at that
[16:11] <pitti> xnox: ok to upload your ofono fix for the python3-dbus dependency?
[16:11] <pitti> that breaks stuff ATM
[16:12] <pitti> (already asked last week, but I guess it got drowned)
[16:13] <cjwatson> seb128: do you think we can disentangle the various arch-restrictions we put in for the friends/signon/account-plugins cluster?
[16:13] <cjwatson> seb128: they should be unnecessary now that we have Qt 5.2
[16:13] <cjwatson> (I think)
[16:13] <xnox> pitti: oh, yes please.
[16:13] <xnox> pitti: do you want me to upload, or will you?
[16:13] <seb128> cjwatson, that should be fine I think yes
[16:13] <pitti> xnox: I don't mind; I mostly wondered why you didn't alreayd, as it's an obvious fix
[16:14] <pitti> xnox: or is that in CI these days?
[16:14] <xnox> pitti: oh, i thought it needs "landers landings et al". If it's just dput, i can do it.
[16:14] <pitti> awe: can we just dput the python3-dbus dependency fix for ofono-scripts, or is ofono in CI now?
[16:15] <xnox> cjwatson: hm, infinity  and i did disentangle some of those already. account-plugins -> done, signon -> done. dee-qt ftbfs is the blocker to get ubuntu-ui-toolkit which should get us more things building.
[16:15] <awe> pitti, we have a bzr branch for the ofono packaging...
[16:15] <pitti> awe: yes, I know, and xnox fixed it there already
[16:15] <cjwatson> xnox: dee-qt's done as of this morning
[16:15] <xnox> cjwatson: \o/
[16:16] <cjwatson> and hud
[16:16] <pitti> awe: can we just dput that, or does it need the CI landing exercise now?
[16:16] <xnox> excellent!
[16:16] <awe> what's the diff???  I'm working with it now, and it looks like ofono-script specifies all the right packages
[16:16] <pitti> awe: just python-dbus → python3-dbus dep
[16:16] <cjwatson> so yeah, in fact libfriends can build again, in theory; let me try that
[16:17] <pitti> awe: that got missed from converting ofono-scripts to py3
[16:17] <awe> pitti, hmmm that's present in the branch I'm working with.  Lemme check the master
[16:17] <pitti> awe: yes, it is already committed, just not uploaded yet
[16:17] <xnox> cjwatson: src:qml-friends is arch-restricted.
[16:18] <awe> ah..ok
[16:18] <pitti> . o O { core-dev isn't what it used to be }
[16:18] <cjwatson> xnox: yeah, I expect there's more to disentangle.  thanks.  perilously close to the touch stack being arch-sane again though ...
[16:18] <Laney> pitti: Pretty sure you could upload, especially if it's in trunk
[16:18] <awe> pitti, we have a blocker that needs to get resolved first ( a ftb on ppc64le ); I'll work with seriusens or rsalveti to get an upload to happen
[16:18] <awe> pitti are you blocked by this?
[16:19] <pitti> awe: not me personally, but I figure it could cause some test failures in CI
[16:19] <xnox> awe: ppc64el ftbfs is not a blocker, it never built on it, thus it would migrate just fine.
[16:19] <pitti> awe: ppc64el is not a blocker, .... yes
[16:19] <Laney> it's easy for CI uploads to say "yes I really do want to upload"
[16:19] <xnox> awe: please just upload.
[16:19] <Laney> so dputs shouldn't really be a problem
[16:19] <cjwatson> xnox: unity-action-api needs lttng made optional - I'm working on that
[16:19] <cjwatson> (for ubuntu-ui-toolkit)
[16:20] <pitti> Laney: ah, right; it was teh committing which is the CI controlled thing these days
[16:20] <cjwatson> actually maybe not, I see it's built
[16:20] <cjwatson> I was thinking of unity-scopes-api
[16:20] <xnox> cjwatson: i did unwind portions of lttng packages.... maybe more can be fixed, we have a few things of that already. Let me look.
[16:20] <awe> xnox, I can't, as I don't have the rights...  as I said, I'll work with rsalveti or sergiusens to get it uploaded
[16:20] <pitti> xnox: right, so dput should be fine
[16:20] <cjwatson> xnox: yeah, so did I
[16:20] <cjwatson> xnox: I know how to do it, thanks
[16:20] <xnox> cjwatson: ok.
[16:20] <pitti> awe: no worries, xnox or I will; I just wondered about landing through CI
[16:21] <cjwatson> xnox: (https://code.launchpad.net/~cjwatson/upstart-app-launch/porting/+merge/210385 in my case)
[16:21] <rsalveti> we were planning to land this via CI
[16:21] <rsalveti> which should happen today still
[16:21] <Laney> Yeah, CI train makes you explicitly do something about archive uploads
[16:23] <xnox> cjwatson: not needed anymore, liblttng-ust-dev is available on ppc64el.
[16:24] <xnox> cjwatson: or am i missing something?
[16:24] <cjwatson> xnox: oh.  lttng-tools isn't though
[16:25] <cjwatson> xnox: ok, I didn't realise you'd ported that ...
[16:25] <cjwatson> xnox: fancy doing ltt-control as well then? :)
[16:25] <xnox> cjwatson: i was bored on the weekend unwinding things.
[16:26] <cjwatson> You sure were :)
[16:29] <xnox> cjwatson: i have a new thing stuck however - db5.3 "gained" test-suite errors on arm64 (as seen in -proposed and the test-archive rebuild), which blocks openldap.
[16:29] <xnox> cjwatson: openldap has test-suite failure further down in the test-suite upon using mdb, which i have prepared to disable for now (it's already disabled on !linux) i guess test-suite never got that far to notice that.
[16:34] <Laney> xnox: please forward the ust changes ;-)
[16:34] <xnox> Laney: yeah.
[16:35] <xnox> Laney: i'm on lttng-dev mailing list feeding upstream patches.
[16:36] <Laney> cool
[16:38] <xnox> cjwatson: ltt-control built.
[16:38] <cjwatson> thanks
[16:41] <infinity> jamespage: I don't think Debian needs that, no.  Debian (whether they know it or not) is in the process of a slow organic gcrypt transition.
[16:41] <infinity> jamespage: I just didn't want that transition in Ubuntu for trusty.
[16:41] <jamespage> infinity, ack
[16:43] <infinity> cjwatson: eglibc, or locales?  I still haven't re-integrated that (running out of time for that to be a sane option, but maybe if I land it in the next couple of days)
[16:43] <cjwatson> infinity: eglibc itself
[16:43] <cjwatson> (I think)
[16:44] <cjwatson> xnox: ltt-control> you didn't do arm64
[16:46] <infinity> cjwatson: Whoa, more backscroll, you sorted dee-qt?
[16:47] <cjwatson> infinity: Yeah, tsdgeos and I figured out a workaround between us anyway; but it seems to be a linker bug
[16:47] <cjwatson> It's basically https://bugreports.qt-project.org/browse/QTBUG-36129 and http://lists.linaro.org/pipermail/linaro-toolchain/2014-January/003942.html
[16:48] <cjwatson> infinity: But building with PIE works around it for now (wibble wibble linker horror)
[16:48] <infinity> s/PIE/pie/
[16:48] <infinity> Also, wheeeee.
[16:48] <cjwatson> So we have ubuntu-ui-toolkit everywhere now, once powerpc catches up anyway
[16:49] <infinity> That sounds a whole lot like something I wish I hadn't asked about.
[16:49] <cjwatson> Yup
[16:49] <xnox> cjwatson: =( sorry.
[16:49] <cjwatson> infinity: If you fancy teaching mir how to do big-endian GLPixelBuffers or whatever it is, we might even be able to get that part of the stack ;-)
[16:51] <cjwatson> https://code.launchpad.net/~cjwatson/mir/stdint-include/+merge/211340 should sort mir/arm64, and http://paste.ubuntu.com/7109133/ on top of that makes most of the tests pass on ppc64el; I haven't sorted out whether the rest is just my build environment being wonky, which it might be
[16:53] <infinity> cjwatson: Making mir endian-clean should be something they should have done from the get-go.  If I find "free time", I can look into it, though.
[16:54] <cjwatson> I don't disagree, but at least there's a clear TODO for it
[16:56] <xnox> cjwatson: infinity: cause clearly ubuntu-touch on ppc64el with a 7 foot watcom screen is a must for our tradeshow large audience demos =)
[16:56] <cjwatson> xnox: Looks like ubuntu-sdk-libs-dev is still not multiarch-installable, but I filed https://code.launchpad.net/~cjwatson/webbrowser-app/multiarch/+merge/211350 to disentangle the next bit
[16:57] <cjwatson> xnox: Well, yeah, but multiway-entangled archive and all that; and we probably *will* want it on arm64 at some point
[16:57] <xnox> cool.
[16:57] <tarpman> xnox: speaking of openldap. did you test the db5.1->db5.3 change on a system with slapd installed? I just tried that upgrade and it looks like it needs the database dumped and reloaded (but maybe I missed something)
[17:01] <xnox> tarpman: no i did not, but it does stop slapd, does dump_database and reapplies them in postinst, thus it should just work.
[17:07] <ogra_> xnox, will you make sure there is an android rebuild for your initramfs touch change ?
[17:08] <xnox> ogra_: not needed.
[17:08] <ogra_> ?
[17:08] <xnox> ogra_: but i can make one.
[17:08] <ogra_> it wont be picked up
[17:08] <xnox> ogra_: i know.
[17:08] <ogra_> and it would be good to set it break asap to fix it ;)
[17:08]  * ogra_ grins
[17:14] <tarpman> xnox: the db is always dumped, yes, but reloaded (by default) only when upgrading past the slapd version mentioned in database_format_changed; anyway, I'll spin up a new VM and double-check I'm telling the truth
[17:15] <xnox> tarpman: right, that makes sense, I didn't bump those.
[17:16] <xnox> tarpman: that would be great! thansk!
[17:21] <didrocks> xnox: you are merging back your changes in upstream trunk, right?
[17:24] <xnox> didrocks: which ones?
[17:24] <didrocks> xnox: libhud-qt and so on
[17:26] <xnox> didrocks: oh is libhud-qt under ci-train? it looked as if it was untouched since forever and last uploads were from daily-release bot which is not operating anymore?
[17:26] <xnox> didrocks: i'll walk through my uploads and sync things up.
[17:26] <didrocks> xnox: well, everything which was under daily-release will go over ci-train
[17:26] <didrocks> xnox: thanks a lot :)
[17:26] <didrocks> and thanks for the fixes
[17:26] <didrocks> now that we have the toolkit finally built on all arch, I feel more confident
[17:27] <didrocks> I'm afraid about libusermetrics though
[17:27] <xnox> didrocks: meh, it's boring rebuilds work, we totally should have dropped arch restrictions in the "no change rebuilds against qt 5.2"
[17:27] <didrocks> build-dep on valgrind
[17:27] <didrocks> xnox: +1 I thought this was done :/
[17:27] <xnox> didrocks: we don't have valgrind, but that's an easy build-dep to be make arch-dependant, we did it in a lot of other packages, so no worries.
[17:28] <didrocks> xnox: ah? ok, trusting you then :)
[17:28] <cjwatson> https://launchpadlibrarian.net/168403467/libusermetrics_1.1.1%2B14.04.20140120-0ubuntu1_1.1.1%2B14.04.20140305-0ubuntu1.diff.gz already has the clue
[17:28] <cjwatson> it's just that it was incorrectly done in a negative way rather than a positive way
[17:29] <cjwatson> should've been "enable valgrind only where valgrind is available", not "avoid valgrind on armhf"
[17:29] <didrocks> ok, something for my tomorrow if nobody beats me to it
[17:29] <cjwatson> well, also should be Build-Depends: valgrind [amd64 armhf i386 powerpc], but that's easy
[17:29] <didrocks> then unity8 should be available on all archs from my quick look
[17:29] <cjwatson> no, still mir
[17:30] <didrocks> cjwatson: argh, yeah, you're right
[17:30] <cjwatson> for which see a few dozen lines up here
[17:30] <cjwatson> 16:51 <cjwatson> https://code.launchpad.net/~cjwatson/mir/stdint-include/+merge/211340 should sort mir/arm64, and http://paste.ubuntu.com/7109133/ on top of that makes most of the tests pass on ppc64el; I haven't sorted out whether the rest is just my build
[17:30] <cjwatson>                  environment being wonky, which it might be
[17:30] <cjwatson> and the endianness porting for powerpc
[17:30] <didrocks> kgunn: as you are going to land a Mir, can you get that one in, please? ^
[17:30] <didrocks> kgunn: we are trying to have you building on all archs to enables top of the stack
[17:30] <didrocks> enable*
[17:32] <cjwatson> if we'd be willing to maybe have some failures visible in build logs which don't block migration, I'd be happy to file an MP with the arch-any bits too
[17:32] <kgunn> didrocks: so you want it in now ? if so i guess i can rebuild....
[17:33] <cjwatson> I think it might take a while to get mir ported to the last two arches though
[17:33] <didrocks> ok so maybe let's get kgunn doing his landing and just after it, dealing with your branch
[17:33] <kgunn> ok...
[17:33] <xnox> didrocks: kgunn: did 1.6 land already?! i'd rather have inprogress landing go in already.
[17:34] <xnox> didrocks: kgunn: we want more velocity, not less =) so no need to constantly reconfigure/delay prepared&tested fixes.
[17:35] <didrocks> xnox: well, it wasn't tested yet
[17:35] <xnox> didrocks: well, your/landing/mir folks call  then=)
[17:41] <xnox> cjwatson: looks like unity-scopes-shell needs more pie
[17:42] <xnox> cjwatson: https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.4.0+14.04.20140312.3-0ubuntu1 similar to dee-qt
[17:43] <cjwatson> Right, I'm not sure whether tsdgeos was planning to just turn off symbolic-functions in qtbase
[17:43] <cjwatson> it's definitely not ideal to have to whack-a-mole this
[18:12] <tarpman> xnox: installed a new saucy vm, installed slapd, upgraded to trusty: slapd fails to start because the db is still in db5.3 format. want a bug?
[18:12] <tarpman> s/still in 5.3/still in 5.1
[18:40] <sarnold> pitti: hello :) 1293156 hasn't yet been handled by the trusty retracers yet, they look unhappy again
[18:49] <infinity> tarpman: Looks like it needs a database_format_changed tweak, I'll get that.
[18:49] <infinity> xnox: Sorting tarpman's issue.
[18:51] <tarpman> infinity: cheers! in case it matters, bugs.debian.org/738641 is the debian side
[18:53] <debfx> infinity: do you mind if I sync libgcrypt20 1.6.1-2? it doesn't provide libgcrypt-dev anymore.
[18:53] <infinity> debfx: Why bother?
[18:54] <infinity> debfx: If it will have no rdeps (and it won't), makes more sense to just let it autosync in for trusty+1
[18:55] <debfx> not all software is packaged
[18:56] <infinity> If you think there's a legitimate third-party need for a newer gcrypt, sure.  Sync away.
[19:02] <debfx> I might be biased as it's my software, but it certainly benefits from the new gcrypt version.
[19:16] <smb> infinity, Would you have time to look into bug 1290743. Not sure comment #4 was the ok or what exactly would be the ok. The sources would be either in my ppa or on chinstrap
[19:19] <infinity> smb: On my TODO for today.
[19:19] <smb> infinity, \o/ Thanks
[20:49] <bdmurray> roaksoax: is the syslinux task on bug 1092265 valid?
[21:27] <infinity> xnox: Any idea what went wrong with your db5.3 upload on arm64?
[21:37] <bdmurray> xnox: do you know how to update app-install-data-ubuntu?
[21:55] <slangasek> xnox, infinity: speaking of things wrong with db5.3 uploads, I noticed that openldap was uploaded to trusty to rebuild against db5.3; but there's an on-disk logfile change, which means this requires a database dump/restore in the maintainer scripts (Debian bug #738641)
[21:58] <xnox> slangasek: infinity: there is nothing wrong with my db5.3 same/similar failure is present in the archive rebuild without my patch. I didn't investigate it.
[21:59] <xnox> bdmurray: i have done it once before using mvo's branches. Let me kick off a tarball generation.
[22:01] <infinity> slangasek: Already fixed in ubuntu8
[22:02] <infinity> slangasek: http://launchpadlibrarian.net/169846224/openldap_2.4.31-1%2Bnmu2ubuntu7_2.4.31-1%2Bnmu2ubuntu8.diff.gz
[22:02] <xnox> infinity: i read that at first "already fixed in unity8" and was utterly confused =)))))
[22:03] <infinity> Hrm, though maybe I should have made that ubuntu8 for the 2 people who upgraded to 5, 6, and 7, and didn't get their DB migrated. :/
[22:03] <xnox> infinity: those 2 people can die another day ;-)
[22:04] <infinity> xnox: Right, I didn't assume that Andy's patch broke DB on arm64, just that it's now broken for $some_reason.
[22:04] <slangasek> infinity: oh. why is ubuntu5 still the latest in trusty?
[22:04] <infinity> xnox: Also, are you applying that patch to DB 5.1 and DB 6.0 too?
[22:05] <infinity> slangasek: Because 6 and 7 were FTBFS on ppc64el due to the kernel pagesize change.
[22:05] <infinity> slangasek: 8 built fine, now that db5.3 is fixed.
[22:05] <xnox> infinity: i wanted to drop db5.1 from the archive for trusty. But not sure about the last 3 packages that only migrated to db5.3 in trusty.
[22:05] <slangasek> infinity: oh hah, right
[22:05] <xnox> infinity: e.g. how it interracts with openldap upgrade.
[22:06] <xnox> infinity: i didn't debug arm64 build-failure yet. looks as cryptic as dee-qt one.
[22:06] <infinity> xnox: Dropping it doesn't affect upgrade paths.
[22:06] <slangasek> xnox: openldap does its db export in the preinst because it doesn't trust db versions to be around
[22:06] <infinity> The trick is that the preinst runs against the old binaries to dump the DB, then  you upgrade, and reload.
[22:06] <infinity> The old library doesn't need to be in the archive for that.
[22:07] <xnox> infinity: right, in that case i'll drop 5.1 from "db-utils-all" (or whatever that one was) and file db5.1 removal request.
[22:07] <infinity> And it's obviously on your disk, or your old slapd no workie.
[22:07] <xnox> infinity: re:db6.0 nothing is using it in the archive, and in debian it was suggested to be removed completely due to change of license.
[22:07] <infinity> xnox: Hrm, cyrus-common might do this differently, though.
[22:07] <infinity> xnox: No idea how this db-upgrade-util thing works.
[22:08] <infinity> xnox: If db6.0 is to be removed, remove it, if it's not, fix it. :P
[22:08] <slangasek> there are some that have preinsts that do evil local copies of the binaries into a private dir :P
[22:09] <infinity> Okay, so cyrus depends on libdb5.1 in precise, and this db-upgrade-util thing in trusty.
[22:09] <infinity> Probably worth sorting out WTF that does before dropping it. :P
[22:09] <xnox> upgrader package - it just provides/depends such that db5.1_dump db5.1_load db5.1_upgrade etc are available on the path... nothing else.
[22:18] <infinity> Man, I am so done with Monday.
[22:21] <infinity> slangasek: If you want to upload (or approve an NMU) openldap to Debian to move to 5.3 and bump the upgrade magic number, I'll just megre that back to Ubuntu over my change.
[22:22] <slangasek> infinity: I don't want to approve an NMU, because I have a new upstream version staged in git which I've been waiting to upload until I knew the answer to this thing; in turn that's probably not mergeable for trusty
[22:22] <slangasek> (though tjaalton would probably appreciate it if it were)
[22:22] <infinity> slangasek: Ahh, kay.  That works too.
[22:23] <infinity> slangasek: So, yes, the answer is that the DB format changes, I just had someone complain this morning, hence my Ubuntu upload to bump the dump/reload magic version. :P
[22:24] <slangasek> infinity: right ;)
[22:27] <tarpman> infinity: fwiw, I looked at trusty this morning exactly because I'd posted about it on the debian bug last night ;)
[22:27]  * tarpman will be *so* embarrassed if it turns out to have been unnecessary
[22:28] <infinity> tarpman: Well, IRC backscroll claims that you tested an upgrade and it broke.
[22:29] <tarpman> I did! twice.
[22:29] <infinity> tarpman: So, I'm assuming you were right. :)
[22:29] <infinity> tarpman: And my fixed upload should fix it.
[22:29] <tarpman> three, if you count sid last night
[22:29] <tarpman> yeah, I'll confirm that as soon as the builds finish (still running tests last I looked...)
[22:30] <infinity> (Though, I'll note that my upload didn't fix it for people who upgraded to a ubuntu5 already and didn't fix their own breakage...)
[22:30] <infinity> tarpman: Yeah, the builds all finished and then LP exploded, so they're working on it again.  Whee.
[22:30] <tarpman> people running slapd on trusty? I feel like your "2" is a high estimate for that...
[22:30] <tarpman> me and tjaalton I suppose :)
[22:30] <slangasek> tarpman: if you're wrong, I'll have no choice but to mark you as the openldap maintainer and run away
[22:30] <tarpman> :D
[22:31] <infinity> slangasek: That maintainer list is long enough already.
[22:31] <infinity> slangasek: Especially given the last two uploads being NMUs...
[22:32] <slangasek> infinity: there you go, stigmatizing NMUs
[22:33] <infinity> slangasek: I have nothing against NMUs.  The more, the merrier.
[22:33] <slangasek> infinity: note the changelog, where the second NMU was to fix the fact that the first was broken ;)
[22:33] <infinity> slangasek: I just find it particularly fun in that case, given the impressive length of the maintainer list.
[22:44] <tjaalton> tarpman: i don't run it, but need a libkdap built against nss, not done that part yet though :)
[22:45] <tjaalton> meh, libldap
[23:41] <juliank> I fixed bug 1288718 today hours before I could access it.
[23:41] <juliank> Independent bug discovery!
[23:47] <xnox> bdmurray: i'm fighting with archive-index here and I think i'll just package it up and upload it into ppa. After-all it needs/wants fast unsplit mirror access... which a distro/ppa builder will give me =)