[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://<IP_ADDRESS>/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 =)


[00:14] <pleia2> freedom \o/
[00:14] <pleia2> it was a long work week :)
[00:15] <akk> Enjoy!
[17:14] <jamie> morning every one happy saturday
[17:14] <sn9> i'm at CLSWest
[17:14] <sn9> there is no wifi here, would you believe it?
[17:17] <akk> I would.
[17:18] <akk> That's pretty normal for non-expensive conferences, really.
[17:18] <sn9> there is a connection info sheet for the wifi, but the signal doesn't reach the room
[17:20] <akk> That's normal for wifi everywhere, IME.
[17:21] <sn9> heh
[17:21]  * akk remembers d wandering around a hotel grounds with his laptop and finally finding a signal under the stairway near the ice machine
[17:21] <akk> then getting a bad bump on his head when he stood up forgetting he was sitting under the stairs
[17:22] <sn9> :/
[17:31] <sn9> bbiab


[01:59] <Traveler22> Hello fellow java developers, my name is Justin Cater. Me and my team have created a site dedicated to java development. We are trying to create a link between java developers, to communicate, share ideas, solve common problems, push our innovativation and creativity to the max. We would appreciate if you paid us a visit at http://sites.google.com/site/kioubsite/ any comment would be highly appreciated. And do not forget to chec


[01:44] <pecisk> hi there, anyone can help me with EVMS? I try to apply evms source patches from evms.sf.net to Edgy kernel, but it says that it is already aplied. It seems in Edgy EVMS patches are included in default, aren't they?
[01:56] <thom> yes
[01:58] <pecisk> ohhh
[01:58] <pecisk> cool
[01:58] <pecisk> thanks
[01:58] <pecisk> :)
[05:28] <foo> http://paste.ubuntu-nl.org/35091/ - any ideas on this high load?  I'm thinking it's a disk issue
[07:32] <khermans_> anyone familiar with dhcp3? -- i want all PXE booting hosts to grab the bootfile, but I don't want to specify 1000 hardware addresses manually in the conf file -- any ideas?
[10:45] <lullabud> anybody have any luck connecting with Xnest from ubuntu to CDE on solaris 10?
[11:04] <foo> lullabud: Nope, I haven't tried that
[11:05] <foo> lullabud: What's Xnest and CDE?
[11:11] <lullabud> dork.
[11:11] <lullabud> i pitty the foo'
[11:11] <foo> :D
[11:16] <lullabud> solaris man, SOLARIS!
[11:16] <lullabud> ...drives me nuts.
[11:18] <maswan> start with installing a better window manager?
[11:18] <lullabud> well, if i could log in in order to get a gui terminal that let's me actually use vim without having buffer problems i could get right on that.
[11:19] <lullabud> i mean, it seems to be all solaris problems.  i can't connect with Xnest from ubuntu or os x.
[11:21] <maswan> doesn't solaris come with a gnome session choice these days by default even?
[11:23] <lullabud> hmm... good question, but the answer is no.  however, it looks like it's working with some alternate java desktop environment instead of CDE.
[11:23] <lullabud> this looks like a windows/gnome frankenstien
[11:23] <lullabud> but hey, it worked!  thanks maswan!
[11:23] <lullabud> the solaris guys weren't even as helpful. :)
[11:36] <kbrooks> hi
[11:36] <jimcooncat> If I do an nfs export, would a 1GB network keep up with a hard drive?
[11:41] <lullabud> jimcooncat:  depends on how much you're transferring.
[11:42] <lullabud> jimcooncat:  it also depends on how much nfs cache you have on the client, and what kind of read/write you're doing.
[11:42] <jimcooncat> thanks lullabud
[11:43] <jimcooncat> I was curious about performance vs. a local hard drive
[11:43] <lullabud> jimcooncat:  well, it really depends on what you're doing.
[11:43] <jimcooncat> I guess if a lan is faster than an ide bus
[11:44] <lullabud> if you're serving up a web root that's not much size, and you have a large enough local cache for all the files, it will actually go at near local disk speed.
[11:44] <jimcooncat> exporting /home in a busy office
[11:44] <jimcooncat> really
[11:44] <lullabud> ah, true that.  it's surely faster than a single IDE channel.
[11:44] <jimcooncat> a lot of cache
[11:45] <lullabud> i'm not very experienced with it, but that's my understanding of how it works.  files are read from the NFS server, cached locally on the client...
[11:45] <lullabud> so long as the files don't change on the server, they are read off the local cache, if they're still there.
[11:46] <jimcooncat> i wonder if I could preload it back after a reboot
[11:46] <lullabud> i'm sure there are ways to do that.  even if they're hacks.
[11:47] <jimcooncat> Never mind, I'd have to be saving the cache state all the time
[11:47] <lullabud> the local cache is on disk anyways.
[11:47] <lullabud> actually....
[11:48] <lullabud> i don't know that for sure.
[11:48] <jimcooncat> oh, I didn't realize you were talking a hard disk cache
[11:48] <jimcooncat> I thought you meant RAM
[11:49] <lullabud> honestly, i hadn't even considered the idea that it would store it merely in RAM.  i assumed it'd have a disk cache... it would make sense that it could be configured either way.
[11:49] <lullabud> looks like http://nfs.sf.net has a lot of good info.
[11:49] <jimcooncat> good, thanks for the link
[11:51] <lullabud> y/w


Hello, i changed my mind also is there any way to report success for yesterdays build i forgot yesterday? or is it to late then


[00:12] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [arm64] (lunar-proposed/universe) [0.1.0-1] (no packageset)
[00:12] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [armhf] (lunar-proposed/universe) [0.1.0-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (focal-proposed) [2.04-1ubuntu47.5]
[00:18] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26.16]
[00:39] <blackboxsw> vorlon: manual verification done on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1999159
[00:39] -ubottu:#ubuntu-release- Launchpad bug 1999159 in cloud-init (Ubuntu) "cloud-init restarts during package upgrade when it shouldn't, regenerating SSH host keys on Azure Focal" [High, In Progress]
[00:54] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.173.4]
[00:54] <vorlon> blackboxsw: do you want it released immediately?
[01:13] <blackboxsw> vorlon it's getting late. I'm guessing we wait until Monday on this. I had hoped to get this in before the weekend in case people are performing upgrades on the weekend for 22.4.2, but this symptom has been out there since Sept. so maybe it's a smaller potential pool of exposure than I thought.
[01:20] <blackboxsw> vorlon: given that cloud-images only have -security pocket configured for unattended upgrades, the exposure here are people that are scheduling upgrades during downtime before rolling out services. So, I'm actually thinkings we don't need to expedite today. but sooner rather than later would be helpful
[01:47] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [riscv64] (lunar-proposed/universe) [0.1.0-1] (no packageset)
[07:31] <vorlon> blackboxsw: ok. I am not around on Monday to do the SRU release fyi
[07:54] <LocutusOfBorg> hello, something looks not working on britney side?
[07:54] <LocutusOfBorg> I: [2022-12-09T07:17:30+0000] -  finish: [gap,gap-float,gap-guava,gap-io,-libgap7/amd64,-libgap7/arm64]
[07:54] <LocutusOfBorg> but gap didn't migrate
[07:54] <LocutusOfBorg> vorlon, ^^
[07:55] <LocutusOfBorg> also, since you are on i386 foo list
[07:55] <LocutusOfBorg> missing build on i386: libgav1-1, libgav1-bin, libgav1-dev (from 0.18.0-1)
[07:55] <LocutusOfBorg> meh
[07:56] <vorlon> LocutusOfBorg: why do you expect it to have migrated? the output I see is:
[07:56] <vorlon>  finish: [gap,gap-float,gap-guava,gap-io,-libgap7/amd64,-libgap7/arm64]
[07:56] <vorlon> endloop: 5+0: a-0:a-0:a-0:i-1:p-0:r-3:s-1
[07:56] <vorlon>     now: 11+0: a-5:a-1:a-0:i-1:p-0:r-3:s-1
[07:56] <vorlon> that says it tried the hint and uninstallability increased
[07:56] <vorlon>     * amd64: python3-sage, python3-sagetex, sagemath, sagemath-jupyter, sagetex
[07:56] <vorlon>     * arm64: python3-sage
[07:56] <LocutusOfBorg> so, I still fail to parse that output
[07:56] <LocutusOfBorg> after only 20 years or so
[07:56] <LocutusOfBorg> nice
[07:58] <vorlon> looking at libgav1, clearly lunar doesn't think it's supposed to be built
[08:02] <vorlon> ok it's no longer needed, binaries removed (along with various others that are detected)
[08:12] <LocutusOfBorg> vorlon, I issued a sagemath rebuild, but I really don't think it is compatible with newer sphinx newer gap, newer gcc and so on
[08:12] <LocutusOfBorg> ∙ ∙ Updating sagemath would introduce bugs in testing: #1013399, #1020576, #1022254, #1022278
[08:12] <LocutusOfBorg> can't we just kick them out from release to proposed
[08:12] <LocutusOfBorg> ?
[14:03] <jchittum> blackboxsw & vorlon : I agree that automated upgrades of cloud-init will be low, but it's a very high profile user base, with a possibly wide blast, showing a possible security issue (it's _not_ a security issue, but it'll _look_ like one to a user, right? it'll look like a MITM).
[14:03] <jchittum> regarding the cloud-init bug from yesterday (wish i had threading)
[14:04] <bdrung> tjaalton, can you accept the tzdata update (LP: #1998321). it's seven days old
[14:04] -ubottu:#ubuntu-release- Launchpad bug 1998321 in tzdata (Ubuntu Kinetic) "tzdata 2022g release" [Undecided, Fix Committed] https://launchpad.net/bugs/1998321
[14:05] <jchittum> Considering we've had a few oopses on our Azure pushes lately, we should probably move more quickly, and make sure the various Azure support groups are aware of manual checks and timelines
[14:07] <rbasak> bdrung: we don't like releasing on Fridays!
[14:07] <rbasak> It sounds like cloud-init may on balance need an exception to that, but I'l leave it to vorlon. We'll want an AA around over the weekend in that case.
[14:10] <bdrung> rbasak, sadly this tzdata update contains short of notice changes
[14:16] <rbasak> Maybe it's OK if someone is going to hang around for cloud-init anyway :)
[14:21] -queuebot:#ubuntu-release- Unapproved: ca-certificates-java (jammy-proposed/main) [20190909 => 20190909ubuntu1] (core, i386-whitelist)
[14:22] <jchittum> once i see blackboxsw back online, we can have a chat on timing and what we think possible blast is. I might get someone from Azure Linux Systems Group on the horn too and get their opinion. My worry is if someone does do a Friday upgrade (heh) they'll end up in a weird situation till a Monday release. But if the LSG team is aware, and we think it's a low probability of manual upgrade, and we have workaround steps...
[14:22] <jchittum> then Monday is preferable.
[14:23] <jchittum> cloud-init work-around, in a manual scenario, is setting up a serial connection and checking cloud-init logs for verification
[14:29] <tjaalton> bdrung: no release on a friday I'm afraid
[14:31] <bdrung> then please on monday
[15:30] <seb128> sil2100, hey. checking the build log of the desktop iso today https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntu it's still mentioning canary-ship-live is that expected?
[15:53] -queuebot:#ubuntu-release- Unapproved: edk2 (focal-proposed/main) [0~20191122.bd85bf54-2ubuntu3.3 => 0~20191122.bd85bf54-2ubuntu3.4] (no packageset)
[15:53] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (kinetic-proposed/main) [2.791 => 2.791.1] (desktop-core, i386-whitelist)
[16:11] <bdmurray> bdrung: Is the ICU update as important as the main tzdata update?
[16:11] <bdrung> bdmurray, for PHP users, yes
[16:20] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (lunar-proposed/main) [2.06-2ubuntu15 => 2.06-2ubuntu16] (core, i386-whitelist)
[16:37] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (lunar-proposed/main) [2.06-2ubuntu16 => 2.06-2ubuntu16] (core, i386-whitelist)
[16:41] <juliank> sil2100, vorlon: ^ fresh lunar grub binaries to approve :)
[17:10] <bdmurray> vorlon: init-system-helpers is missing an i386 build because it depends on fakechroot which is missing and i386 build because it gained a new dep on gnu-which for which we don't have an i386 build
[17:24] <vorlon> jchittum, blackboxsw, rbasak: I was asking about immediate release yesterday precisely because I am EOY tomorrow and not committed to being around over the weekend, or next week
[17:26] <blackboxsw> +1 on this vorlon(same) Had  a chat with jchittum and we can document how it understand this race if affects a system and get it to MSFT folks in the event that they get any support tickets on this. We think it's unlikely to hit the majority of vms due to the fact that is a pkg upgrade issue which is typically only handled in upgrade windows.
[17:26] <blackboxsw> we'll look to Monday likely and chat with sil-2100 then
[23:20] -queuebot:#ubuntu-release- New binary: nebula [amd64] (lunar-proposed/universe) [1.6.1+dfsg-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: nebula [ppc64el] (lunar-proposed/universe) [1.6.1+dfsg-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: nebula [arm64] (lunar-proposed/universe) [1.6.1+dfsg-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: nebula [s390x] (lunar-proposed/universe) [1.6.1+dfsg-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: nebula [armhf] (lunar-proposed/universe) [1.6.1+dfsg-1] (no packageset)


[01:03] <DarwinElf> tomreyn, 18.04... but the point is, recovery networking doesn't work--because there's no /etc/init.d/networking !  Most garbage recovery system I've ever seen... have to conclude Ubuntu is not a serious OS
[01:37] <DarwinElf> tomreyn, 18.04... but the point is, recovery networking doesn't work--because there's no /etc/init.d/networking !  Most garbage recovery system I've ever seen... have to conclude Ubuntu is not a serious OS
[01:37] <DarwinElf> oops
[01:37] <DarwinElf> recently I had to boot to recovery, and it didn't have networking!  How do I (re)install the service that would show up as /etc/init.d/networking ?
 how to open a website in a linux browser with a virtualbox web server. I can open the website with ip but not with dns
[02:52] <valorie> @zen40 -- I never had any difficulty
[02:53] <valorie> you do have to set it up to share connectivity with the base system
 DistroTube - Video About Linux and Open Source … https://www.distrotube.com/blog/seven-things-to-avoid-on-linux/
 @Rutvikm, This is great for non-programmer Linux users
[03:29] <rodrigo> I have some kind of panel or widget on my desktop. It shows an hamburguer icon and the name of the current Activity. I clicked somewhere and it got there. I cant seem to remove it. I can click and move it around. It sticks up bottom left or right. WHen clicked it shows some options like leave, lock screen, undo, add widgets. What is it and how to I remove it?
 How to display battery percentage in full size alongside gui battery indicator in panel?
 Display battery percentage just adds a barely visible miniscule overlay atop gui battery icon in system tray widget
[07:25] <lordievader> Good morning
[11:52] <BluesKaj> Howdy folks
 Hi
 @Rutvikm, Hello
[14:58] <jedab> hows it going?
[15:09] <Luna__> Listening to todays episode now
[15:09] <Luna__> https://www.linux4everyone.com/23-manjaro-linux-laptops
[15:12] <BluesKaj> Luna__, no more spamming please!
[16:49] <coolgamezzz> hello everybody, i am new here
 @popeydc, Hey @popeydc I believe it's stock from 18.04 with an additional DKMS module from Tuxedo, and the Nvidia drivers. Backports are enable and updates applied. For gospel on this checkout KFocus.org hth 🥰
 @Sick_Rimmit, Thanks!
[18:52] <eeos> Hi everybody! I have a somewhat disconcerting behaviour on kubutnu 18.04 LTS 64 bits. Some of the flatpaks installations (but not all) do not appear in Discover software, but they appear in the CLI.
[18:53] <eeos> Anyone else experiencing the same issue?
[19:26] <calcmandan> eeos can you give an example?
[21:09] <IrcsomeBot2> josebenaque was added by: josebenaque