=== ming is now known as Guest53326
[02:15] <teward> did the old issue somewhere around 2012/2013 or something where backports can't build-dep on backports ever get fully resolved?
[02:17] <cjwatson> teward: Yes, that was https://bugs.launchpad.net/launchpad/+bug/888665
[02:17] <ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released]
[02:18] <teward> cjwatson: ahhh, nice, glad to see that's resolved, that put a nail in the coffin for ZNC backports for some time (since the swig libraries are never new enough xD)
[04:05] <aeoril> infinity you still need a tech writer?
=== wolsen_ is now known as wolsen
[05:38] <pitti> Good morning
[05:49] <mightyiam> Yo what codename do I use for upgrading to devel, please?
[06:03] <pitti> mightyiam: that's the thing we are all waiting for :)
[06:03] <pitti> there is no devel series yet, it's blocked on getting a name from sabdfl
[06:16] <mightyiam> pitti, thank you
=== geser_ is now known as geser
[08:16] <pitti> doko_, cjwatson, wgrant: working on pkg-create-dbgsym now, for the binary version bug 1448247
[08:16] <ubottu> bug 1448247 in pkg-create-dbgsym (Ubuntu W-series) "pkg-create-dbgsym creates -dbgsym packages with the source version, not the binary version" [Critical,In progress] https://launchpad.net/bugs/1448247
[08:18] <wgrant> pitti: Great, thanks. We should do a main test rebuild on scalingstack once you have something that seems to work.
[08:19] <wgrant> pitti: What's your approach for the fix?
[08:20] <pitti> wgrant: this can't be fixed solely in dh_strip, so I'll divert dh_builddeb or whatever calls dpkg-gencontrol and update binary versions there
[08:20] <wgrant> Yeah, dh_builddeb or dh_gencontrol make sense.
[08:20] <pitti> I'll add a test case with a source that produces such different binary versions first
[08:20] <wgrant> Tests? Pfeh.
[08:20] <pitti> doko pointed to failed build logs, but I figure they are gone now (it got rebuilt after you switched off ddebs)
[08:21] <pitti> but it's fairly clear what happens, I figure LP verifies binary versinos between a deb and its ddeb
[08:21] <wgrant> Right.
[08:21] <pitti> wgrant: had a good flight back?
[08:21] <wgrant> pitti: s/back/to Malta/
[08:21] <wgrant> So yes, it was the easiest international flight ever :P
[08:21] <pitti> wgrant: oh, right
[08:58] <ev> pitti: thanks!
[09:01] <wgrant> pitti: If you need to test, the same checks are performed on PPAs with ddebs enabled. If you want a test PPA, I can enable the flag for just that.
[09:02] <pitti> ev: hey Evan! (for anything in particular? :-) )
[09:02] <ev> 7:48 AM <pitti> ev: yes, to verify correct Depends:; but tests can have Restrictions: needs-recommends
[09:02] <ev> and hi :)
[09:02] <pitti> wgrant: I suppose the requirement is that the binary versions of ddeb and deb are identical, right?
[09:02] <pitti> ev: ah ;)
[09:02] <pitti> wgrant: I'll do that with the local test suite (I have a test now, currently reengineering the actual logic)
[09:06] <wgrant> pitti: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archiveuploader/nascentupload.py#L339
=== cimi is now known as Cimi
=== bladernr_ is now known as bladernr-malta
=== Malsasa_ is now known as Malsasa
=== pete-woods1 is now known as pete-woods
[11:11] <pitti> wgrant, cjwatson, doko_: I have this working now, in lp:ubuntu/pkg-create-dbgsym
=== willcooke_ is now known as willcooke
[11:18] <cjwatson> pitti: Would it be worth an rm -f $dp/DEBIAN/add_to_files.pkg-create-dbgsym if -a isn't in use, on the principle of idempotency or something?
=== olli is now known as Olli
[11:22] <pitti> cjwatson: dh_gencontrol already does that if it exists, what do you mean?
[11:22] <cjwatson> pitti: But thanks, that all looks sound to me.  Stick it in a PPA and we can at least test-build gcc-5 against it?
[11:23] <pitti> cjwatson: I also suggest test-building binutils and systemd (see my recent bug followup)
=== MacSlow is now known as MacSlow|lunch
[11:24] <pitti> yep, will create a PPA now
[11:24] <cjwatson> pitti: I mean that the pkg_create_dbgsym stage should rm -f that file if the option isn't set, to make sure the option state is unambiguous either way; but never mind, I just noticed that pkg_create_dbgsym can be run multiple times so this is an incorrect suggestion
[11:25] <pitti> hm, where do I create a PPA on https://launchpad.net/~ubuntu-core-dev
[11:25] <pitti> https://launchpad.net/~ubuntu-core-dev/+activate-ppa is "not allowed here" for me, hmm
[11:26] <pitti> we can't create per-team PPAs any more?
[11:26] <Laney> pitti: I think you need to be the owner (DMB here)
[11:27] <Laney> Want one?
[11:27] <pitti> Laney: please
[11:27] <pitti> Laney: "ddeb-test" or so
[11:27] <Laney> done
[11:27] <pitti> Laney: danke
[11:28] <pitti> wgrant, cjwatson: can you please mark https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test for creating dbgsyms?
=== ahasenac` is now known as ahasenack
[11:30] <cjwatson> pitti: done
[11:30] <pitti> danke
[11:31] <pitti> p-c-d uploaded, I'll upload binutils, systemd, and gcc-5 after it's published
[11:31] <pitti> (or rather, copy sources from vivid to the PPA)
[12:20] <mitya57> We are missing a 15.04 announcement in https://launchpad.net/ubuntu/+announcements (does anybody read that?)
=== MacSlow|lunch is now known as MacSlow
[12:52] <ScottK> pitti: autopkgtest is claiming regressions on both your policykit-1 and systemd SRUs for vivid.  Would you please have a look.
[12:53] <pitti> ScottK: ah, will do, thanks; we'll have to retry upstart some ten times, due to bug 1429756
[12:53] <ubottu> bug 1429756 in linux (Ubuntu Vivid) "FTBFS: upstart test_job_process fails in majority of cases / Kernel returning unexpected EIO at end of file" [High,In progress] https://launchpad.net/bugs/1429756
[12:54] <ScottK> pitti: I'm guessing you know who to talk to regarding problems in the autopkgtest infrastructure.  ;-)
[12:54] <pitti> ScottK: heh, yes; although in these cases it's flaky tests
=== _salem is now known as salem_
=== ara is now known as Guest54483
[14:50] <pitti> ScottK: both succeeded now
[14:51] <ScottK> Great.
[14:51] <ScottK> pitti: There are quite a number of regressions showing for pending SRUs.  It might be useful for someone who knows the autopkgtest stuff to go through them and see what's real (and mark those verification failed) and what's a test issue.
[14:54] <pitti> ScottK: utopic should be okay; trusty has quite a number of failures indeed; we talked about those on the core sprint and fixed some issues, but the others are still TODO indeed
[14:55] <ScottK> OK.  As long as someone is looking into it.
[15:33] <Ionic> fun with launchpad, second iteration...
[15:34] <Ionic> now a package is completely missing. I suspect this to be the case due to it being empty.
[15:34] <Ionic> while that's generally a bad thing, because (at least) Debian supports and endorses empty dummy packages as a transition method, the package *shouldn't* be empty in the first place
[15:35] <Ionic> additionally, I cannot reproduce the problem with pbuilder-dist on my own system
[15:36] <ScottK> Ionic: We have transitional packages exactly like Debian, so that's not it.
[15:37] <Ionic> the package should contain a symlink that is created in the install phase within the destroot
[15:38] <Ionic> ScottK: well, the package isn't being created *by launchpad*, while everythings looks fine when using pbuilder-dist. that's what I'm not getting.
[15:39] <ScottK> Right.  I'm not disputing anything other than thinking Ubuntu and Debian are somehow different when it comes to transitional packages.
[15:39] <Ionic> ScottK: I didn't know the dummy package policies for Ubuntu. they could have been different from Debian (particularily because I don't think "dummy packages" are a good idea anyway)
[15:40] <Ionic> but that's my personal opinion, as it will leave dummy packages on people's systems.
[15:41] <Ionic> again, not too bad, as those will be uninstalled with the next dist-upgrade or autoclean operation. all RPM-based package managers frown upon empty dummy packages, though (mostly because their package managers do not automatically delete them at some point)
[15:41] <ScottK> They should be section oldlibs and go away at some point, so it's not a real issue.
[15:43] <Ionic> anyway, the point is that the package should NOT be empty in the first place, and even if it was, I would expect a package to be built
[15:43] <Ionic> I have genuinely no idea how to debug this, because it's non-reproducible via pbuilder-dist
=== elopio_ is now known as elopio
[15:58] <rsalveti> bdmurray: Saviq: how to extract the crash file from https://errors.ubuntu.com/oops/461670b4-eb7a-11e4-bb71-fa163e525ba7, for example?
[15:59] <rsalveti> like the core dump
=== salem_ is now known as _salem
[16:09] <bdmurray> rsalveti: generally the core dumps are only temporarily available, we don't store every coredump forever
[16:09] <bdmurray> rsalveti: What are you trying to find out?
[16:33] <Ionic> I can even see the symlink being created that should be part of that package
[16:34] <Ionic> ln -s -f "/usr/lib/x86_64-linux-gnu"/libNX_Xinerama.so.1 /build/buildd/nx-libs-3.5.0.32/debian/tmp/usr/lib/nx/X11/Xinerama/libXinerama.so.1
[16:34] <Ionic> but it's never included in the package, although the .install file contains "usr/lib/nx/X11/"
=== essembe is now known as sbeattie
[17:00] <Ionic> *sigh*
[17:01] <Ionic> and pbuilder-dist foo withlog build ...dsc doesn't work either
[17:01] <Ionic> "pbuilder-dist: Error: "withlog" is not a recognized argument."
[17:07] <Ionic> seems like a log file is always created in the results dir as foo.build
[17:07] <Ionic> and the option was removed some time ago
[17:07] <Ionic> (but the manpage is still referencing it)
[17:09] <sbeattie> bdmurray: hey, I'm kinda confused by https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1449088 ; the bug title apport generated has clamav-daemon 0.98.6+dfsg-1ubuntu4 failing to upgrade, but the dpkg telminal-log.txt attachement makes has the postinst for clamav-daemon 0.98.6+dfsg-1ubuntu2 failing. Any idea why the discrepancy?
[17:09] <ubottu> Launchpad bug 1438745 in clamav (Ubuntu Vivid) "duplicate for #1449088 package clamav-daemon 0.98.6+dfsg-1ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [High,Fix released]
[17:13] <bdmurray> sbeattie: nope, that's weird. There's also no reference to clamav-daemon in DpkgHistoryLog.txt
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== Guest83237 is now known as pfsmorigo
=== tnkhanh_ is now known as tnkhanh
=== hjd_1 is now known as hjd
[18:34] <ScottK> sbeattie and bdmurray: Not sure why it's titled that way, but the error being reported is the one that was present in ubuntu2 and fixed in ubuntu4 (ubuntu3 got eaten by launchpad)
[18:39] <sbeattie> ScottK: one of the reasons to dig into it a bit was to make sure that that ubuntu4 actually fixed the issue, and/or the respin due to the lp ddeb issue didn't accidentally drop the fix.
[18:42] <ScottK> The simplest way to do that is extract the postinst and look at that line.  If says $DEBCONFFILE it's fixed.  If it says $DEBCONFILE, it's not.
=== oSoMoN__ is now known as oSoMoN
=== kenvandine_ is now known as kenvandine
[19:45] <aeoril> infinity poke
=== tnkhanh_ is now known as tnkhanh
=== iulian_ is now known as iulian
[20:34] <infinity> aeoril: Yeah, I completely forgot about your offer last week when we were actually doing the release.
[20:41] <aeoril> infinity oh well, maybe some other time :)
[20:54] <infinity> Riddell: I don't suppose you were planning to ask to re-spin your vivid ISOs, were you?
[20:55] <infinity> Riddell: Cause if not, I can't see any point in SRUing ubiquity.
[20:57] <ScottK> infinity: How about if one is doing an online install and asked for package updates to be installed?  Doesn't that upgrade Ubiquity?
[20:58] <infinity> ScottK: ICBW, but I don't think ubiquity updates and re-execs itself.  I'm not a ubiquity expert, though.
[20:59]  * ScottK thought it did, but not an expert either.
[20:59] <Riddell> infinity: isn't there an update ubiquity option from within ubiquity?
[20:59] <infinity> Turns out that "rgrep update" in the ubiquity source is entirely unhelpful. ;)
[20:59] <Riddell> infinity: also we have derivatives who will want it
[21:02] <infinity> Hrm, I do see mention of "upgrading the installer" in the changelog.
[21:02] <infinity> Scary.
[21:02] <infinity> I've never noticed/used this feature.
[21:02] <infinity> Riddell: Alright, objection retracted.
[21:41] <sarnold> spacex feed for today, just doing a countdown so far https://youtu.be/nBwAYT_ogj4
[21:44] <infinity> sarnold: Hrm, that doesn't seem to work in our default ffox config.  Annoying.
=== tnkhanh_ is now known as tnkhanh
=== _salem is now known as salem_
[22:05] <infinity> pitti: This ecryptfs diff is causing me to drink.  Heavily.
[22:26] <ScottK> infinity: Doesn't being awake have the same effect on you generally?
[22:27] <ScottK> Not that I'm one to talk ...
[22:27] <infinity> ScottK: Only on days ending in Y.
[22:27] <ScottK> :-)
[22:41] <sarnold> that ecryptfs diff _earned_ it though :)
[22:43] <infinity> sarnold: srsly.
[22:44] <infinity> sarnold: Second set of eyes appreciated.  Destructively altering partition tables isn't something I take lightly.
[22:45] <infinity> sarnold: The diff in vivid-proposed/unapproved, to be clear.
[22:46] <sarnold> infinity: is this it? https://launchpadlibrarian.net/204338055/ecryptfs.debdiff
[22:47] <sarnold> (I've got that in my history from the bug report)
[22:47] <infinity> http://launchpadlibrarian.net/204337329/ecryptfs-utils_107-0ubuntu1_107-0ubuntu1.1.diff.gz
[22:47] <infinity> They might match, but that's the one pitti uploaded.
[22:48] <sarnold> thanks; iirc the only thing I I thought of last week was that 'printf' might be preferable to 'echo', and that alone didn't seem worth mentioning
[22:55] <sarnold> infinity: why is the postinst calling sudo?
[23:13] <infinity> sarnold: For exactly zero good reason.
[23:14] <infinity> sarnold: Ditto for setup-swap, I imagine.  Given that the rest of that script can't possibly work without root.
[23:16] <infinity> sarnold: Any other complaints from your review?  I'm rejecting for the sudo thing alone, since sudo in a postinst is potentially hangtastic if the system's resolver is slightly out of whack.
[23:16] <sarnold> infinity: jeeze I didn't think about the resolver.. I just figured someone'd have funky local configs that causes sudo to fail somehow..
[23:16] <sarnold> infinity: that was it though
[23:20] <infinity> sarnold: The echo vs printf thing doesn't seem like a concern, as he's implicitly calling coreutils echo.  If a user replaces /bin/echo, they probably get to keep both pieces.
[23:20] <sarnold> yeah
[23:21] <sarnold> it's just one of the little things about shell scripting that grabs my attention every time though. heh
[23:21]  * infinity nods.
=== salem_ is now known as _salem
[23:27] <sarnold> ("needless use of sudo in a script already running as root"? that takes three tries to spot.. and I missed one.)
=== tnkhanh_ is now known as tnkhanh