[00:11] <rbasak> Pharaoh_Atem: that it's a different source package name is just a technicality really. We all know the new name is derived from the old name. It would be sensible for bugs to carry over.
[00:12] <rbasak> Pharaoh_Atem: though as I say, if there's a good reason it's fine to comment on bugs saying that they are presumed fixed in Xenial and marked Fix Released or Incomplete or whatever as appropriate.
[01:01] <nacc_> Pharaoh_Atem: what a doozy -- learned a bit of twig syntax, wrote a test php & template that is identical to the one that causes the testsuite to segfault ... and no segfault. But if I remove the two utf8 files from the tests, no segfaults. So it is in those files. I'm now worried there is some corrupted state in php itself
[03:46] <hallyn> pitti: hey...  so you wrote a patch for systemd-shim "Clean up closing logind sessions".
[03:47] <hallyn> it inserts a cgroup release agent (regardless of whether one was already defined) which, when a cgrou pis emptied, stops a session
[03:47] <hallyn> this is wreaking havoc on a xenial system if you install upstart-sysv, lxc1, and fix cgroup-lite the way we need to for phone :)
[03:48] <hallyn> upon login, /etc/pam.d/common-session tells systemd to create cgroups;  then it has libpam-cgfs do the same;  the cgroups created by systemd are cleared, teh release agent called, the session stopped, login session terminated
[03:49] <hallyn> pitti: would you boject to patching systemd-shim to not insert the release agent if one is already set?
[03:49] <hallyn> (it's poor manners to do otherwise :)
[03:56] <hallyn> or can i just get rid of that since in all real installs we expect to be using real systemd
[03:57] <Son_Goku> hallyn: why not just move to systemd on the phone?
[03:57] <Son_Goku> just let upstart die… for all of our sakes :)
[04:04] <hallyn> Son_Goku: not in my power
[04:04] <Son_Goku> :’(
[04:04] <hallyn> I think it just has to do with some user jobs, i'm sure they'll be switching soon
[04:05] <Son_Goku> :(
[04:08] <Son_Goku> can you plea for them to move asap?
[04:12] <hallyn> nah i'm gonna lobby for openrc.
[04:12] <hallyn> i kid!
[04:12] <sarnold> daemontools 4 life!
[04:12] <hallyn> we have a bsd init job for cgmanager
[04:13] <hallyn> (for slackware)
[04:13] <hallyn> sarnold: well at some point you'd like to stop rewriting the lowe rlayers so you can build higher layers on top of them :)
[04:13] <hallyn> but this point is not that point
[04:20] <sarnold> hallyn: haha :)
[04:21] <hallyn> all right, that fixes it.  I'll sling a debdiff over to pitti after find some more kleenex to dry my tears
[04:23] <hallyn> hm, no, i was wrong.  drat.
[04:25] <hallyn> meh, bad patch.
[05:00] <hallyn> pitti: http://paste.ubuntu.com/15264990/
[05:02] <hallyn> ugh.  minus the debug statements
[05:03] <hallyn> pitti: maybe http://paste.ubuntu.com/15264999/ instead
[05:03] <sarnold> hallyn: you may be the only person I know who debugs a string with strlen() :)
[05:03] <hallyn> pitti: basically that is needed becaues when I push http://paste.ubuntu.com/15265000/ I wil lotherwise cause upstart-based xenial deploys to refuse logins
[05:04] <hallyn> sarnold: well i wanted to catch the length of a dbus reply for an empty string :)
[05:04] <sarnold> :)
[05:08] <hallyn> then again, now my vm has a corrupt fs.  did my patch somehow contribute to that?
[05:14] <nacc_> Pharaoh_Atem: last thought of the night (it's a good one) -- phpunit --process-isolation makes twig not segfault
[05:14] <nacc_> Pharaoh_Atem: which i think means we have a php bug
[05:15] <sarnold> that sounds ungood
[05:15] <hallyn> huh   Begin: Running /scripts/init-bottom ... Warning: overlayroot: debug is busted
[05:15] <sarnold> hallyn: -that- sounds like a clear suggestion to EOD :)
[05:22] <hallyn> i'm open to suggestions, i'll tkae that one
[05:22] <hallyn> \o
[05:46] <cpaelzer> good morning
[06:33] <pitti> hallyn: systemd-shim> sounds good; this code isn't very good, it has never been thoroughly tested with running systemd side by side, just for making logind work under upstart (where nothing else fiddles with cgroups)
[06:35] <pitti> hallyn: http://paste.ubuntu.com/15264999/ LGTM
[06:36] <pitti> hallyn: ah, src/cgmanager.{h,c}, I thought that was some piece of standard code being copied around into various projects
[06:36] <pitti> hallyn: let's test this for a few days, then I'll apply it upstream and upload it to Debian too
[06:36] <pitti> hallyn: thanks!
[06:45] <hallyn> pitti: cool, thanks.
[06:46] <hallyn> pitti: noob question, but it's late and i'm not trusting my judgement - the cgroup-lite needs systemd-shim to be the newer version.  should it conflicts or breaks on the <= old version?
[06:46] <Skuggen> pitti: Did you have a chance to look at the deb-systemd-helper use we have in the mysql 5.7 postinst, to see if it looks safe?
[06:46] <hallyn> i think conflicts
[06:49] <hallyn> no, breaks sounds more accurate per the docs
[06:51] <pitti> hallyn: it should Breaks: (<< fixed_version)
[06:52] <hallyn> kewl, pushing htat, and calling it a day - thx
[06:53] <pitti> Skuggen: the pastebin you showed to me yesterday? that looked reasonable, if you also replicated dh_systemd_*'s postrm and prerm code
[06:53] <pitti> Skuggen: still wondering if it wouldn't be simpler to just move the #DEBHELPER# tag further up in the postinst and let the code be autogen'ed
[06:54] <Skuggen> pitti: But the #DEBHELPER# code will also do the 'proper' starting of the service that should happen at the end
[06:59] <pitti> Skuggen: so you need to things *between* enable and start? OOI, what is that?
[07:02] <Skuggen> Updating an existing database to mysql-5.7 requires running mysql_upgrade, which (unfortunately) is a client that needs to connect to a running server
[07:03] <Skuggen> And we added running mysql_upgrade as part of postinst instead of relying on users doing it manually
[07:05] <pitti> Skuggen: right, but can't that happen before the debhelper stuff?
[07:05] <pitti> i. e.
[07:06] <pitti> if [ "$1" = configure ] && have_older_db; then mysql_upgrade; fi
[07:06] <pitti> #DEBHELPER
[07:06] <Skuggen> Yes, but I need to start the service to be able to run mysql_upgrade, which is what the systemd_helper commands are for
[07:07] <Skuggen> Well, I could run mysqld manually and wait in a loop for it to be ready, but we moved away from that because it's also not very robust
[07:18] <pitti> Skuggen: *confused* I thought you said the service must *not* be running yet for upgrading?
[07:19] <pitti> so doing #DEBHELPER# first and then call mysql_upgrade?
[07:19] <pitti> Skuggen: I should probably purge my entire brain state about this and we'll start over :)
[07:19] <Skuggen> Hehe
[07:20] <Skuggen> I might be able to move all the upgrade-related stuff after #DEBHELPER#, with some reshuffling
[07:20] <Skuggen> (there's also some checking/fixing of password access for the maintenance user used to run upgrade, but should be able to refactor it)
[07:22] <pitti> Skuggen: so I think the question is "do you need to anything *within* the #DEBHELPER# generated code"
[07:23] <pitti> if yes, then you need to do things manually or apply some seddery; if not, then things are easy, and you just need to strategically place the #DEBHELPER# token
[07:24] <Skuggen> Hopefully not. I'll give it a try. Thanks for the help :)
[07:45] <dholbach> good morning
[07:50] <cpaelzer> pitti: thanks for agreeing that "changing" enviroment features for tests is a bad thing
[07:50] <cpaelzer> pitti: I didn't realize that my first paragraph could have been so misleading until you repled on the RT ticket - thanks
[07:51] <cpaelzer> pitti: I tihnk it is now up to all the involved parties to consider if changing from host-cpu to sandbridge would break anything else (due to the fact that it is a global config)
[07:51] <pitti> cpaelzer: I'm not convinced at all that we use -cpu host right now
[07:52] <pitti> cpaelzer: I've seen "SandyBridge" on all our clouds, on the semaphoreci.com clouds, etc.
[07:52] <pitti> it seems it's just a default -cpu SandyBridge in openstack
[07:52] <pitti> i. e. I think we are currently using that ^
[07:52] <cpaelzer> pitti: that is how I read kuhlmannt RT post
[07:54] <cpaelzer> pitti: well I just took "The current configuration in nova is unset for cpu_mode which means it should default to host-model " for granted, but I just saw your post checking it
[07:55] <cpaelzer> pitti: and I understand that we assume at least one of the systems runs on >sandybridge which means your check confirms that it is not running as "host-cpu"
[07:56] <pitti> cpaelzer: *nod*, I yet have to see an x86 cloud instance which is something else
[07:56] <cpaelzer> pitti: I really wonder what that was two weeks ago where sse3 wasn't there - it is a shame that we can't timewarp and do a proc/cpuinfo and such there
[07:57] <cpaelzer> pitti: waitnig for IS replies to your post now, thanks for testing your scalingstack instances
[07:58] <cpaelzer> actually - do we already (if not should we?) do an environment report in the adt-* output that we could check that in logs after the fact?
[07:59] <pitti> cpaelzer: we have testinfo.json which has some info  like the running kernel version, environment variables, etc.
[07:59] <pitti> we can certainly add stuff to that
[07:59] <pitti> e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/udisks2/20160301_213435@/result.tar
[07:59] <pitti> that contains testinfo.json
[08:03] <cpaelzer> pitti: just parsed through it - interesting
[08:03] <cpaelzer> pitti: there are no links from what I consider a packages CI overview to that result.tar (e.g. http://autopkgtest.ubuntu.com/packages/o/openvswitch-dpdk/xenial/amd64/)
[08:03] <cpaelzer> pitti: I could fetch my data by just manually constructing the link thou
[08:03] <cpaelzer> pitti: any reason not to add that link there as well?
[08:05] <pitti> cpaelzer: I'd rather expand it into the debci log
[08:06] <pitti> we have three links there already, adding more isn't helping confusion
[08:06] <cpaelzer> pitti: agreed
[08:06] <pitti> cpaelzer: indeed it's just replacing log.gz with result.tar in the URL
[08:08] <cpaelzer> pitti: IMHO the dbci log could take a plain /proc/cpuinfo, on s390x maybe also /proc/sysinfo - that would be great
[08:08] <cpaelzer> pitti: I also thought about lshw, but that is too heavyweight
[08:09] <pitti> cpaelzer: perhaps #processors and the model name
[08:09] <pitti> the full thing is quite big
[08:09] <cpaelzer> pitti: processor, model and flags of one of them?
[08:09] <pitti> ok
[08:09] <pitti> cpaelzer: mind reporting a bug against autopkgtest about that, as a reminder?
[08:09] <cpaelzer> I'll do
[08:09] <cpaelzer> thanks
[08:09] <pitti> great
[08:13] <cpaelzer> pitti: before I open the bug one more thing to clarify, I don't know who controls the results.tar or artifacts.tar.gz
[08:13] <cpaelzer> pitti: I guess the answer is no
[08:13] <pitti> the answer to "who" is "no"?
[08:13] <cpaelzer> pitti: but would it be possible to add e.g. a full sosreport into those tarballs AFTER failing tests?
[08:13] <pitti> cpaelzer: adt-run writes testinfo.json
[08:14] <pitti> cpaelzer: it could go into artifacts.tar.gz (certainly not into results.tar)
[08:14] <pitti> cpaelzer: but I don't want to do this by default really, as you don't need it for most tests
[08:14] <pitti> so if your test wants to depend on sosreport and use it, please feel free
[08:15] <cpaelzer> pitti: ok, so if anybody wants it make it test specific - I'm absolutely ok with that - thanks
[08:15] <pitti> i. e. most tests aren't that hardware specific, and having sosreport in all of them woudl just be a waste of resources, and also it's another potential point of brittleness
[08:31] <Skuggen> pitti: Simply moving everything that needed a running server below #DEBHELPER# does the trick. Thanks!
[09:36] <smb> Hm anybody here got experience with bind9/isc-dhcp packaging. Looks to me like in order to unbreak dhcp one needs to (fake) moving back to a less-featured libbind to build dhcp. There is something in there for udeb, but I am not sure that would be the right thing.
[09:36] <smb> That's about bug 1551351 for reference
[09:42] <Saviq> pitti, morning, did you see the recent britney results in silos? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-076/excuses.html https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html
[09:42] <Saviq> pitti, there's all kinds of unsatisfiable depends, both on vivid (how ¿?) and xenial (proposed migration?)
[09:42] <Mirv> much of unsatisfaction
[09:42] <Saviq> they can get no...
[09:43] <Saviq> satisfactioon
[10:15] <Mirv> is there a way to see what autosynced from Debian between certain dates (2016-02-17 - end of auto sync period)?
[10:19] <seb128> Mirv, I don't think we have a list for those, but autosync stopped on the 18 iirc
[10:20] <Mirv> yeah I know, something magic happened between the morning of 17th and 19th that breaks generation of top-level-domain data
[10:20] <Mirv> but we're closing in anyway with oSoMoN
[10:22] <seb128> Mirv, how are those generated?
[10:24] <Mirv> seb128: http://code.qt.io/cgit/qt/qtbase.git/plain/util/corelib/qurl-generateTLDs/main.cpp called from http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/plain/debian/generateTLDs.sh?h=ubuntu - but it does not fail locally, only on builders
[10:24] <Mirv> so what I'm next trying is settings C.UTF-8 as the locale in debian/rules, just a wild guess now that it was found that there's something wrong with the generation
[10:24] <seb128> Mirv, oSoMoN, grep changed on the 17th and created issues for e.g ubiquity
[10:25] <Mirv> thank you :)
[10:25] <seb128>   * debian/rules: Build under C.UTF-8 locale. grep 2.23 causes broken debconf
[10:25] <seb128>     templates to be built under the C locale.
[10:25] <Mirv> mitya57: I see you committed set -e to qtbase, have you already found the grep error?
[10:25] <Mirv> if it's that one
[10:25] <seb128> that's what pitti did to ubiquity ^
[10:25] <Mirv> seb128: ah, it sounds like my guess is the correct one <- oSoMoN
[10:26] <Mirv> so, I'll prepare a real silo with C.UTF-8 set and start a build and go to lunch
[10:26] <pitti> Skuggen: cool! that's so much easier and robust
[10:27] <seb128> Mirv, https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1547466
[10:27] <seb128> sorry that it has bitten you as well, seems like you spent several days trying to figure that out
[10:27] <pitti> Saviq: ah, I know -- looks like this is from xnox' recent component check
[10:27] <seb128> we should perhaps have reverted the grep update :-/
[10:27] <pitti> xnox: ^ I think we need to disable the component checking if PPAs are involved
[10:28] <xnox> pitti, right, because ppas only have 'main'
[10:28] <xnox> pitti, but we don't run britney excuses against ppas... or do we?!
[10:28] <pitti> xnox: we do, silos do that
[10:29] <xnox> pitti, ok =) i'm so out of date. Do you want me to look into this?
[10:29] <pitti> xnox: I'll have a look, should be fairly simple
[10:29] <pitti> xnox: what I'd like you to do is to have a look at the ubuntu excuses, like http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#squid3
[10:30] <pitti> xnox: I don't see how squid3 depends on squid
[10:31] <xnox> essentially calls to get_dependency_solvers should change component to MULTIVERSE and then things are ignored, "if PPA:" or some such.
[10:31] <xnox> or maybe we need a britney.conf feature flag for components missmatches.
[10:31] <LocutusOfBorg> superm1, please please on the next upload drop fonts-droid on mythtv https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
[10:31] <pitti> xnox: I think we should just disable the check if ADT_PPAS is set
[10:32] <smb> seb128, heh... so it turned out to be a problem for other people, too. :)
[10:32] <seb128> smb, grep you mean?
[10:32] <pitti> xnox: change "if allowed_component(component, package[COMPONENT]):" to "if self.options.adt_ppas or allowed_component()" perhaps?
[10:32] <smb> seb128, yep.
[10:33] <seb128> smb, yeah, Mirv and oSoMoN just spent several days investigating qt regressions
[10:33] <oSoMoN> Mirv, and confirmed, running a local build with LANG=C LC_ALL=C generates a broken qurltlds_p.h
[10:33] <seb128> which turned out to be due to that
[10:33] <pitti> xnox: oh, nevermind, the squid3 binary in -proposed indeed has Pre-Depends: squid (>= 3.5.12-1ubuntu1)
[10:33] <pitti> rbasak: ^ please run check-mir on your squid merge
[10:33] <LocutusOfBorg> superm1, well, nevermind
[10:34] <smb> seb128, I was fearing it could also cause more obsure problems. Build fails only if grep is used to produce new sources on a build
[10:34] <oSoMoN> if there wasn’t one already, a unit test should be added to grep
[10:34] <pitti> rbasak: ah, unping
[10:34] <pitti> xnox: so for squid, apparently squid3 now builds a squid transitional package, so this is a case of component-mismatches
[10:34] <Mirv> oSoMoN: thanks
[10:35] <pitti> apparently 'squid' is the new main package, and squid3 is a transitional
[10:35] <seb128> smb, well, in this case that was not a build failure but some runtime issues due to buggy top-level-domain data generated
[10:35]  * xnox should have run update the chdist before looking into it, or like have more coffee
[10:35] <pitti> xnox, rbasak: it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt , I promoted squid now
[10:36] <smb> seb128, yeah -> more obscure problem. :) Guess I was kinda lucky that Xen failed to build then
[10:36] <seb128> is anyone looking at the grep issue?
[10:37] <smb> I don'T think so (yet). I think I could not convince Brian it is broken
[10:38] <Mirv> this is linked to C.UTF-8 not being the default locale which has been a discussion topic for years. it gives grey hairs to many who build Python packages
[10:38] <xnox> pitti, squid3 package builds squid package in both release & proposed, and in both cases it's in universe.
[10:38] <pitti> xnox: right, so we caught the component-mismatches in britney
[10:38] <pitti> xnox: I just wasn't aware of the squid3 -> squid transition
[10:38] <pitti> so it seems all fine
[10:38] <xnox> pitti, right yes, i see that now.
[10:39] <pitti> xnox: http://paste.ubuntu.com/15265997/ should work, right? (no testsuite..)
[10:39] <seb128> Mirv, yeah, still it's a behaviour change and impacting our things with the current buildds setup
[10:39] <xnox> pitti, looks good! cowboy that in =)
[10:39] <Mirv> seb128: yep
[10:40] <pitti> Saviq: ok, britney fix pushed, so silo excuses should update within the next 2 hours; sorry about that
[10:40]  * pitti keeps the page  open to check after lunch
[10:41] <Saviq> pitti, thanks :)
[10:48] <seb128> Mirv, oSoMoN, smb, seems like it's being discussed upstream on the grep list, http://lists.gnu.org/archive/html/bug-grep/2016-02/msg00036.html
[10:48] <rbasak> pitti: [squid] that's right, thanks for sorting it.
[10:57] <smb> seb128, not like that sounds the discussion is going well...
[10:57] <seb128> yeah...
[10:58] <seb128> it would feel safer reverting the behaviour change for xenial
[10:58] <seb128> or we might end up wasting quite some more time chasing weird issues where we should focus on bugfixing for the lts
[10:59] <oSoMoN> Mirv, so according to the upstream discussion, the correct fix is to invoke grep with -a, not LANG=C LC_ALL=C, is that what you’re doing?
[10:59] <smb> I tend to agree. Even worse with that example of some backup tool silently failing...
[11:01] <seb128> who would the right person to do that call? foundations?
[11:04] <smb> guess foundations but not sure which person... slangasek ?
[11:10] <Mirv> oSoMoN: I used the LC_ALL (same as ubiquity), it should be fine for now and I'd guess Debian will switch to -a which I'll notice in a future merge
[11:11] <oSoMoN> ok
[11:41] <LocutusOfBorg> pitti, can you please have a look at ubuntukylin-meta wrt http://lists.gnu.org/archive/html/bug-grep/2016-02/msg00036.html ?
[11:42] <dholbach> Laney, I won't have time to look at the tomahawk thing in the next days :-/
[11:50] <Laney> dholbach: ok, well keep it on the queue then
[11:52] <pitti> LocutusOfBorg: sorry, what's wrong with ubuntukylin-meta?
[11:54] <pitti> and FWIW, we really ought to switch to C.UTF-8 by default on buildds and the like
[11:54] <pitti> tell me one good reason why one would still want 'C' in 2016
[12:01] <LocutusOfBorg> pitti, https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html :)
[12:33] <seb128> pitti, yeah, but meanwhile the builders are on C locales and we have people wasting days chasing random side effect of that grep update
[12:47] <pitti> Saviq: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html is good again now
[12:48] <Saviq> pitti, great, thanks
[12:49] <pitti> LocutusOfBorg: re (sorry, out for lunch); ok, I'll update the seeds now
[12:53] <pitti> LocutusOfBorg: ugh, it wasn't updated since wily
[13:08] <pitti> LocutusOfBorg: uploaded
[13:16] <LocutusOfBorg> thanks!
[13:28] <tjaalton> I can't run sudo on schroots after updating to xenial, can someone confirm the same?
[13:28] <pitti> WFM
[13:28] <tjaalton> ok then :)
[13:29] <pitti> maybe schroot dir/overlay/mount dir has "nosuid" or so?
[13:31] <tjaalton> maybe, it's on /run/shm
[13:32] <pitti> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
[13:32] <pitti> yes, that can't work then
[13:32] <tjaalton> must've been changed
[13:36] <phatina> hi, I am trying to create several *.deb packages from a single tarball (binary, libraries, header files), but I can't make desired files (listed in ./debian/package.install) to appear in the packages. Every tutorial I found recommends to use "single binary" type of package (bzr dh-make ...)
[13:36] <phatina> Any tips, what I am doing wrong?
[13:39] <LocutusOfBorg> zequence, you there? hi
[13:39] <LocutusOfBorg> ubuntustudio-meta is the last blocker for fonts-android migration
[13:42] <cjwatson> phatina: put your source package somewhere for people to look at and then it will be easier to work out what you've done wrong
[13:43] <LocutusOfBorg> zequence, look e.g. lp: #1546847
[13:43] <LocutusOfBorg> and https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
[13:53] <pitti> LocutusOfBorg: I can update that as well, while I'm at it
[13:56] <LocutusOfBorg> pitti, it would be awesome :)
[13:56] <LocutusOfBorg> just note: the fonts-noto is about 100MB, while droid fallback is 1MB
[13:56] <mardy_> cjwatson: hi! I have a daily recipe on launchpad, which doesn't work because it needs to include some .so files but they are being removed when building the tarball, because launchpad passes the -I option to dpkg-buildpackage
[13:57] <mardy_> cjwatson: is there some way to prevent the daily builder to use that option?
[13:57] <cjwatson> mardy_: No.
[13:58] <cjwatson> But IIRC there is a way to make that work at the source package level ...
[13:58] <mardy_> cjwatson: I've found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377
[13:59] <mardy_> cjwatson: but it doesn't seem to work here, it looks like the -I given from the commandline is "stronger"
[14:00] <cjwatson> mardy_: Which source format?
[14:00] <mardy_> cjwatson: actually, I've tried both 1.0 and 3.0 (native), and I'm getting the problem with both of them
[14:01] <cjwatson> mardy_: I think debian/source/options ought to be workable somehow, though possibly only for 3.0.
[14:01] <cjwatson> mardy_: Beyond that I probably can't help at the moment.
[14:04] <mterry> barry, your deja-dup patch makes some sense.  But I have a counter-proposal.  Working on it myself
[14:04] <mterry> barry, (my counter proposal just closes a couple issues with my original python-gi patch)
[14:09] <cyphermox> good morning!
[14:09] <mdeslaur> hi cyphermox
[14:09] <barry> mterry: cool, thanks
[14:09] <cyphermox> hey mdeslaur
[14:10] <pitti> LocutusOfBorg: argh -- I can't push to https://code.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.xenial, and they explicitly seed fonts-droid
[14:10] <pitti> so sorry, I can't do this
[14:10] <smb> cyphermox, wait until you catch up (about the good) ;)
[14:10] <pitti> LocutusOfBorg: you need someone from https://launchpad.net/~ubuntustudio-dev/+members
[14:11] <cyphermox> smb: ah?
[14:11] <pitti> LocutusOfBorg: perhaps you can do a MP?
[14:12] <smb> cyphermox, one never know whether a morning really is good. :) Well speaking of, haven't I seen your name i bind9/isc-dhcp changelogs, too
[14:12] <cyphermox> smb: I hate you! :)
[14:12] <smb> :)
[14:13] <LocutusOfBorg> pitti I can bother Ross for this then
[14:13] <LocutusOfBorg> MP what is?
[14:13] <smb> cyphermox, well, I think I got a rough idea what needs to be done to fix dhclient but not how to tell the packaging
[14:13] <LocutusOfBorg> or cjwatson ^^^
[14:13] <cyphermox> smb: to fix dhclient for what?
[14:13] <smb> cyphermox, to work again in xenial
[14:14] <cyphermox> bug #?
[14:14] <smb> cyphermox, bug 1551351
[14:16]  * cyphermox reads and observes dhclient's behavior locally
[14:16] <smb> cyphermox, tl;dr is that bind9.10 drops the export library in favour of a combined one which breaks dchlient
[14:16] <cyphermox> mmkay
[14:16] <cyphermox> well, I see that here it has renewed..
[14:17] <cjwatson> LocutusOfBorg: not me
[14:17] <cyphermox> but I haven't checked if it's because NM did something to it, for instance
[14:17] <smb> cyphermox, hm... could be ... the installs I looked on where server kind (ifupdown)
[14:18] <smb> cyphermox, there is that discussion as reference https://lists.isc.org/pipermail/bind-users/2015-February/094640.html
[14:18] <cyphermox> yeah I'm reading that
[14:18] <cyphermox> I doubt using bundled sources (assuming there are still any) would help
[14:19] <cyphermox> well, that's not entirely true
[14:19] <cyphermox> I have no difficulty believe it would work; it's just not right unless there is no way to fix bind
[14:20] <cyphermox> .. or to fix isc-dhcp itself
[14:21] <smoser> cyphermox, i'd appreciate your thoughts on https://bugs.launchpad.net/curtin/+bug/1551937 . i tried to summarize in comment 7.
[14:21] <smb> cyphermox, Somehow there seems to be one part of build (currently) done for udeb which drops epoll and threads, but whether that would be an option
[14:22] <cyphermox> mkay
[14:23] <ahasenack> hi guys, quick policy question about a package that was in proposed but rejected
[14:23] <LocutusOfBorg> lets wait for zequence :)
[14:23] <ahasenack> once I have a new fix, do I need to build upon the proposed one, or can I start fresh from the one that is in the distro?
[14:23] <cjwatson> ahasenack: As far as the archive is concerned, it doesn't matter.
[14:24] <smb> cyphermox, The timeline made me wonder. Somehow the change to bind9.10 seemed to have happened last year December. But dhclient breaking seems to match with a recent upload of doko that says stop building against the export lib.
[14:24] <ahasenack> cjwatson: ok, if I upload something to proposed again, with the same version and release numbers, but different contents (because it's a different fix), it won't be rejected?
[14:24] <cjwatson> ahasenack: Consider it just like the question of whether if a branch is rejected you should commit on top or prepare a new branch.  (i.e. depends on the circumstances)
[14:24] <cjwatson> ahasenack: *Personally* I would find it clearer to use a different version, but it's not a policy requirement to do so.
[14:25] <ahasenack> cjwatson: that's fine, I was wondering about that check that ppas do, if it applies here as well (same version, different content). Looks like proposed really "forgets" the package then?
[14:25] <cjwatson> ahasenack: It does.
[14:25] <ahasenack> ok, thx
[14:25] <cyphermox> smb: ok, seems like maybe the issue is "just" epoll. I can look in bind9 source to see if there's an obvious clue
[14:25] <cjwatson> ahasenack: At least for the purpose of version checks.  It still exists in the rejected queue, but duplicates are allowed there.
[14:27] <ahasenack> cjwatson: can the final debian changelog include the proposed one that was rejected? The fix wasn't incorrect, just not enough, so it will still be there in the new upload, plus a new fix
[14:27] <ahasenack> or should I merge the entries into one?
[14:27] <cjwatson> ahasenack: Up to you.
[14:27] <ahasenack> ok
[14:27] <ahasenack> thx again
[14:28] <smb> cyphermox, Ok. I guess that would be a cleaner solution if it would work. I was thinking about faking an export style parallel lib... but I agree that is not really desirable if it can be avoided
[14:29] <cyphermox> smoser: it would be necessary to look also at the bindings file, and the output of multipath -ll from the initramfs
[14:30] <oSoMoN> Mirv, I confirm that packages in silo 12 fix the regression in webbrowser-app’s unit tests
[14:30] <smoser> cyphermox, i put thebindings file there.
[14:30] <smoser> see comment 6
[14:30] <oSoMoN> Mirv, as far as I’m concerned, that silo is good to land (when armhf packages are done building of course)
[14:32] <cyphermox> smoser: well, sure, but I really mean *from the initramfs*, seeing bindings and wwids and the output of multipath -l  from the same environment and install
[14:32] <cyphermox> smoser: sorry but otherwise it's not clear whether there are changes in curtin between the point you got the serial log and the point you wrote comment 6
[14:32] <Mirv> oSoMoN: oh you found the silo, thanks! :)
[14:32] <cyphermox> (but you could tell me; yet comment 5 seems to point to the fact that there may have been)
[14:33] <mardy_> cjwatson: nope, I studied the dpkg-source code and there just isn't a way to override a -I given from the command line (no matter what the source format is) :-(
[14:33] <cyphermox> smoser: that said, multipath -l is really the most interesting part of it all, IIRC you *should* see things not have whitespace on xenial.
[14:34] <smoser> cyphermox, the problem is that one expects spaces in its bindings file
[14:34] <smoser> and one does not
[14:34] <smoser> and as curtin i have to know that
[14:34] <smoser> and in an upgrade from trusty to xenial, the system is goign to be hosed
[14:34] <cyphermox> err, what?
[14:35] <oSoMoN> Mirv, yeah, I’m really anxious to get this resolved, and I suspected you had a silo build going on already, so it wasn’t hard to find it :)
[14:35] <smoser> the wwid for the drives in that system have spaces in them.
[14:36] <smoser> and in xenial, multipath -r will write /etc/multipath/bindings with multiple consecutive spaces turned into a '_'.
[14:36] <smoser> in trusty, that file has to have the spaces.
[14:37] <smoser> if i upgrade from trusty to xenial, i'm going to have the spaces
[14:37] <smoser> and on reboot, i'm going to fail to find root
[14:37] <cyphermox> trusty had spaces (if the drive make/model had), xenial does not, and we handle this through the postinst for multipath-tools where appropriate
[14:37] <smoser> so the postinst is going to edit that file ?
[14:37] <cyphermox> only your last statement is incorrect; the upgrade should be handled by multipath-tools
[14:37] <smoser> and anyone writing that file for both is just going to have to "know" this.
[14:38] <cyphermox> yes
[14:38] <cyphermox> that's the fun part is writing installers :)
[14:38] <cyphermox> *in
[14:40] <smoser> do you have a suggestion on how to know which behavior?
[14:40] <cyphermox> what do you mean?
[14:41] <cyphermox> what format for bindings and wwid is completely dependent on the release
[14:41] <cyphermox> it comes from which version of multipath-tools is in use
[14:46] <barry> mterry: you rock, thanks
[14:47] <mterry> barry, how close are we now to a python2 free image?
[14:48] <cyphermox> smoser: tbh, if you want to make it easy on yourself you may want to run multipath -W to create the wwids file for you, then you could run multipath -l and parse the output to create the bindings file
[14:49] <smoser> i can't currently do that.
[14:49] <smoser> as i dont have the modules
[14:49] <cyphermox> ah, multipath -r writes the bindings
[14:50] <cyphermox> you could modprobe them if it needs to do multipath stuff?
[14:51] <barry> mterry: i think the only things left to deal with are system-config-printer-{common,gnome}
[14:51] <cyphermox> smoser: if you don't start up with understanding multipath though, it will be fun and dangerous to try to add stuff like lvm on top of it
[14:51] <barry> mterry: those also pull in samba-libs
[14:51] <barry> mterry: once we take those off, we can unseed `python` and then the rest should just fall off
[14:55] <Son_Goku> barry: I thought system-config-printer-* was already converted to py3?
[14:56] <barry> Son_Goku: it is, but they depend on samba-libs which transitively pulls in python2 :(
[14:56] <Son_Goku> what?!
[14:56] <Son_Goku> couldn’t you make like a samba-libs-nopython thingy?
[14:56] <barry> Son_Goku: apparently it is not that simple
[14:56] <Son_Goku> :’(
[14:57] <Son_Goku> wait, why does system-config-printer need Samba
[14:57] <Son_Goku> doesn’t it use IPP?
[14:58] <barry> system-config-printer-common -> python3-smbc -> libsmbclient -> samba-libs
[14:59] <Son_Goku> O.o
[14:59] <Son_Goku> http://fedora.portingdb.xyz/pkg/system-config-printer/
[14:59] <Son_Goku> I don’t see python3-smbc
[15:00] <Son_Goku> barry: where’s python3-smbc coming from?
[15:01] <barry> Son_Goku:
[15:01] <barry> % apt-cache show system-config-printer-common | grep -i depends
[15:01] <barry> Depends: python3-cups (>= 1.9.60), python3-smbc, python3-dbus, python3-cupshelpers
[15:06] <ogra_> bah, infinity is out today ?
[15:06] <barry> ogra_: i believe so, yes
[15:06] <ogra_> sad ..
[15:07] <smoser> cyphermox, well, maybe. i did result in trusty deploying lvm on top of multipath before knowing of this difference
[15:09] <smoser> so as for now, i'm quite blissful in my ignorance.
[15:09] <Son_Goku> barry: I’m super confused about that
[15:10] <barry> Son_Goku: any insight is appreciated
[15:11] <Son_Goku> I know that python-smbc was required at one point
[15:11] <Son_Goku> but according to the Fedora spec, it’s not required anymore
[15:12] <barry> Son_Goku: python3-smbc, but i think you're saying that it might be an old dependency that can get dropped?
[15:12] <Son_Goku> ah, I see now
[15:12] <Son_Goku> it’s an optional dependency
[15:12] <Son_Goku> barry: http://pkgs.fedoraproject.org/cgit/rpms/system-config-printer.git/tree/system-config-printer.spec#n57
[15:12] <Son_Goku> It’s set as “Suggests” now
[15:13] <Son_Goku> it is not required for the program to function
[15:13] <Son_Goku> that’s as of system-config-printer 1.5.7
[15:14] <Son_Goku> obviously, the Suggests line is a bit of an error, as it needs to be python3-smbc, but I think that should clear up your issue
[15:14] <barry> Son_Goku: it's worth a try, thanks
[15:14] <Son_Goku> no problem
[15:14] <cpaelzer> sorry, but my "usual uploaders" for dpdk seem to be currently all busy/on vacation
[15:14] <cpaelzer> I prepared an upload in bug 1551601 and would be super happy if somebody could take that a look today for review and (if ok) upload
[15:15] <seb128> barry, Son_Goku, check with tkamppeter
[15:15] <Son_Goku> barry: looks like you guys are on a snapshot release, so you should be able to successfully downgrade python3-smbc to Suggests
[15:15] <barry> seb128: yes for sure, before i upload anything
[15:16] <Son_Goku> I’m going to have to ping the maintainer of system-config-printer to change that Suggests line
[15:16] <Son_Goku> because it’s wrong
[15:18] <ogra_> slangasek, around ?
[15:18] <barry> ogra_: probably not ;)
[15:18] <ogra_> bah
[15:19] <ogra_> why is everyone i could ask about my issue off today :P
[15:19] <barry> ogra_: it's your lucky day i guess
[15:19] <ogra_> yeah
[15:21] <barry> Son_Goku: unfortunately, it looks like there are definitely still imports of smbc in the code
[15:21] <barry> well 2
[15:21] <Son_Goku> dammit, where?
[15:21] <barry> in pysmb.py and troubleshoot/CheckNetworkServerSanity.py
[15:22] <Son_Goku> that’s in system-config-printer?
[15:22] <barry> the latter is protected by a try/except (a dubious bare one, but there nonetheless)
[15:22] <barry> Son_Goku: i'm looking in the xenial source package
[15:22] <barry> Son_Goku: yes
[15:23] <Son_Goku> hmm
[15:23] <Son_Goku> the pysmb imports are supposed to be runtime optional deps
[15:23] <Son_Goku> it’s a bug if they are mandatory anywhere
[15:23] <barry> Son_Goku: what does pysmb.py do?
[15:23] <barry> (it is installed as part of system-config-printer-common)
[15:24] <barry> ah, it's imported in newprinter.py, but again wrapped in a bare try/except
[15:24] <Son_Goku> yep
[15:24] <Son_Goku> pysmb is the module that actually handles discovery and attachment of printers on a Samba network
[15:24] <Son_Goku> it should be split out
[15:25] <barry> it's in probe_printer.py too
[15:25] <Son_Goku> that package should be Recommends/Suggests, with python3-smbc as a Requires on that package instead of system-config-printer-common
[15:25] <barry> well, that's indeed one way of handling things: install on demand
[15:25] <Son_Goku> now I *definitely* need to talk to someone in Fedora about this
[15:25] <Son_Goku> this is a problem, because we’re not handling this correctly
[15:26] <barry> i'll relay this to tkamppeter and see if we can come up with something
[15:26] <Son_Goku> from what I can tell, though, even if it remains in the *-common package
[15:26] <seb128> barry, Son_Goku, would splitting that out mean that samba discovering would work out of the box?
[15:26] <Son_Goku> it should be fine, because when pysmb import fails, it’ll just keep going
[15:27] <seb128> +not
[15:27] <Son_Goku> seb128: if the printers are only available through Samba (which is rare these days), then yes
[15:27] <barry> seb128: that's what i would think too
[15:27] <Son_Goku> but most networked printers are available through IPP and JetDirect, and those will work
[15:27] <seb128> k, I don't know enough about printers to know how common that is
[15:27] <seb128> would be nice to hear from tkamppeter on the topic
[15:28] <barry> seb128: i don't know whether it would be acceptable to do what mterry just did for deja-dup, i.e. install on demand.  but then deja was already set up to do that so it was an easy change
[15:28] <barry> seb128: yes, for sure.  i am going to craft an email to u-d@ about it
[15:28] <seb128> barry, would we pull that stack in as soon as you open the printer config?
[15:28] <Son_Goku> the other alternative is to remove system-config-printer entirely, and that’s a crappy idea
[15:29] <barry> Son_Goku: or complete the port of samba, but that ain't gonna happen for 16.04 :(
[15:29] <seb128> barry, because there is no way to know in advance if smb is going to be useful and to know if we should install it
[15:29] <barry> seb128: yeah, i don't know.
[15:29] <smb> seb128, I _am_ always useful :-P
[15:29] <seb128> smb, :-)
[15:29] <barry> :)
[15:30] <seb128> sorry for pinging
[15:30] <barry> smb: can we install you on demand?
[15:30] <Son_Goku> barry: the FreeIPA guys have been wringing with this issue as well
[15:30] <barry> i know :(
[15:30] <smb> barry, there might be a service delay... :)
[15:30] <barry> :)
[15:30] <Son_Goku> of course, they also are damn near close to making it so Heimdal isn’t required for Samba AD DC, which is awesome
[15:31] <tkamppeter> seb128, s-c-p should not have any depends/Recommends/Suggests on python-* must be all python3-*, if not something was overlooked. This I could quickly fix.
[15:31] <barry> tkamppeter: hi!
[15:31] <barry> tkamppeter: that's not the issue
[15:31] <tkamppeter> seb128, s-c-p is totally Python3.
[15:31] <Son_Goku> tkamppeter: I discovered the issue in the Fedora packaging
[15:31] <Son_Goku> the Ubuntu one is fine
[15:31] <barry> tkamppeter: the problem is that there is still a transitive Depends on samba-lib and that pulls in python 2
[15:31] <Son_Goku> well, ish
[15:31] <seb128> tkamppeter, it's python3-smbc and the python3 part is fine, but it depends on libsmbclient which depends on samba-libs which is the issue
[15:32] <tkamppeter> seb128, this is a problem the Samba maintainers have to fix.
[15:32] <barry> tkamppeter: agreed, long term.  but what can we do for 16.04?
[15:33] <barry> tkamppeter: these are the last two deps keeping py2 on the desktop iso
[15:33] <Son_Goku> tkamppeter: s-c-p already is capable of running without python3-smbc installed
[15:33] <Son_Goku> as the samba functionality is an optional runtime dependency
[15:34] <Son_Goku> the overwhelming majority of networked printers expose via IPP and JetDirect rather than Samba, so it shouldn’t be a problem to downgrade python3-smbc to Suggests like Fedora did
[15:34] <tkamppeter> seb128, as the Samba dependency is probably hard-defined and not be removable for the LTS, I would degrade the python3-smbc to Suggests:.
[15:34] <seb128> tkamppeter, that was the suggestion, we just wanted to check what you think
[15:35] <tkamppeter> seb128, who wants to connect to a Windows printer has to pull the full-fledged Python2 from Universe then.
[15:35] <barry> tkamppeter: still main, but yes
[15:35] <barry> tkamppeter: so you're happy with a change that just demotes python3-smbc?
[15:36] <tkamppeter> seb128, I would very very much appreciate if the Samba guys could sort out the problem (hope it does not need a rewrite of Samba), as there should be many users who want to access a printer on Windows.
[15:36] <seb128> barry, I wonder if that's really a win to drop it from the iso if it means dropping useful features and still have in in main/supported and pulled it in on the first occasion for a non trivial number of users
[15:37] <tkamppeter> seb128, can you ask the Samba guys (or report a bug) asking them to lift this Python2 dependency, assuring that python3-smbc does not pull Python2?
[15:37] <barry> seb128: i think it's still useful because it reduces the size and complexity of the iso by not having two full python runtimes
[15:37] <tkamppeter> seb128, or did you already talk with them and they told it is not possible?
[15:38] <seb128> tkamppeter, barry seems to say that it's too much work to be done this cycle
[15:38] <tkamppeter> barry, are you one of the Samba maintainers?
[15:39] <barry> yes, especially because upstream still hasn't fully embraced py3, so it's not just a smop
[15:39] <barry> tkamppeter: i am not
[15:39] <barry> but i have talked to jelmer, petr, and others who are trying to get upstream samba on board
[15:39] <barry> i guess the more people knocking at their door the better ;)
[15:40] <tkamppeter> seb128, I cannot do anything else then demoting dependencies. And I cannot introduce new code which makes Samba unneccessary for accessing printers on Windows. Ans so we have only Samba which is still a Python2-based solution.
[15:41] <tkamppeter> seb128, s-c-p is Py3, but Samba is still Py2, so either no Windows printer/server access or Py2 pull-in.
[15:41] <seb128> tkamppeter, right
[15:41] <barry> tkamppeter: right
[15:41] <tkamppeter> seb128, meaning that I can only demote python3-smbc to Suggests.
[15:42] <seb128> barry, not my call at the end but I think that loosing the "working out the box" experience is costing more than having some python binaries on the iso
[15:42] <tkamppeter> seb128, barry, seems that the last Py2-based core part of our OS is Samba.
[15:43] <barry> seb128: if it's not tkamppeter's call, i'm not sure who's it is.  obviously i want this change, but i cannot gauge how onerous it will be on our users
[15:43] <barry> tkamppeter: yes for sure it is the biggest blocker right now
[15:44] <barry> tkamppeter: how can we move forward?
[15:44] <tkamppeter> barry, is there no way of splitting binary packages to get rid of the Py2 dependency?
[15:45] <seb128> barry, I don't know,  we don't really have a product manager to define the cost/benefit there
[15:45] <tkamppeter> barry, if s-c-p calls Samba code to do its Windows printer discovery and access, is then actually Py2 code executed?
[15:45] <barry> tkamppeter: my understanding is that there isn't.  i actually asked jelmer about this, but he told me (iiuc) that there are calls back into the python runtime from c code, so a split (as i did with libpeas) isn't feasible
[15:47] <barry> tkamppeter: i don't think so.  i think the problem is that there are too many intertwined dependencies in samba-libs, and *that's* the thing that needs upstream support to unwind.  so anything that ultimately depends on samba-libs will pull in py2
[15:47] <barry> even if it doesn't need it :(
[15:47] <Son_Goku> barry: is the samba-libs stuff not split out into a python-samba package?
[15:47] <Son_Goku> err, the python stuff in samba-libs
[15:47] <tkamppeter> barry so the program flow is more or less Py3 (scp) -> C (libsmbclient) -> Py2?
[15:48] <Son_Goku> crap, that isn’t possible
[15:48] <Son_Goku> why are normal C libraries linking to libpython2.7?!
[15:48] <barry> tkamppeter: no, at runtime it shouldn't cross back into py2
[15:48] <Son_Goku> tkamppeter: some of the libraries link to it, but s-c-p’s usage does not invoke py2 at all
[15:49] <kyrofa> Logan, re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815205#10 . Is that a texinfo bug, then, you think? Or misuse by sbcl?
[15:49] <Son_Goku> otherwise it would crash
[15:49] <Son_Goku> because the py2 interpreter library would be loaded into the same area the py3 one was
[15:49] <barry> hmm.  i wonder:
[15:49] <barry> % apt-cache show samba-libs | grep -i Depends
[15:49] <barry> Depends: libldb1 (<< 2:1.1.25~), libldb1 (>> 2:1.1.24~), libacl1 (>= 2.2.51-8), libattr1 (>= 1:2.4.46-8), libbsd0 (>= 0.5.0), libc6 (>= 2.15), libcap2 (>= 1:2.10), libcups2 (>= 1.6.0), libgnutls30 (>= 3.4.2), libldap-2.4-2 (>= 2.4.7), libpam0g (>= 0.99.7.1), libpopt0 (>= 1.14), libpython2.7 (>= 2.7), libtalloc2 (>= 2.1.0), libtdb1 (>= 1.3.0), libtevent0 (>= 0.9.25), libwbclient0 (= 2:4.3.3+dfsg-1ubuntu3), python-talloc (>= 2.0.6),
[15:49] <barry> zlib1g (>= 1:1.1.4)
[15:50] <barry> doko recently uploaded a python3-talloc.  i wonder if we can create a samba-libs-py3 that is exactly the same but deps on python3-talloc and not libpython2.7.  i honestly have no idea what libsmbclient would do with that
[15:51] <barry> tkamppeter: do you know how i could test the windows printer discovery if i don't have a windows printer on my network?
[15:52] <smoser> cyphermox, you are right about multipath and lvm and such.
[15:52] <Son_Goku> barry: unfortunately, same sadness here… http://fpaste.org/332250/93393314/
[15:53] <smoser> going to have to learn more to do that.
[15:53] <tkamppeter> barry, yes. You simply need to run a Samba server on a Linux machine. Have CUPS queues on your Samba server and share them. Then they are also shared by the Samba server, as Windows printers.
[15:55] <barry> tkamppeter: i see, thanks.  let me do some more investigation.  i'll ping or file a bug if/when i learn more
[15:55] <tkamppeter> barry, OK.
[15:55] <barry> i just want to see if depends'ing samba-libs on python3-talloc is a feasible option
[15:56] <barry> (well samba-libs-py3 or some such)
[16:07] <bdmurray> xnox: Could you have a look at bug 1550823?
[16:09] <cyphermox> smb: I think we should ask doko and lamont about the bind9/dhcp stuff; probably reverting the removal of the -export libs, which presumably also built with --disable-epoll would be good enough to let everything work correctly
[16:09] <cyphermox> lamont: FWIW; I'm talking about bug 1551351
[16:09] <xnox> bdmurray, ok
[16:09] <xnox> bdmurray, please subscribe foundations bugs to s390-zfcp
[16:09] <xnox> bdmurray, for MIR
[16:10] <lamont> cyphermox: see also debian/experimental for what mgilbert is doing with dhcp
[16:10] <smb> cyphermox, ok, yeah I was going to ask doko but he does not seem to be around today
[16:10] <cyphermox> ah?
[16:10] <lamont> it was his recommendation to drop the export libs, iirc
[16:11] <cyphermox> nothing appears in exp for isc-dhcp...
[16:11] <cyphermox> at least, according to tracker.d.o
[16:12] <cyphermox> lamont: did you see that bug before?
[16:12] <lamont> 9.10 was originally an upload to experimental (9.10.0rc2 iirc), which then FF finally got me off my butt to upload 9.10 to experimental(for dhcp coord) and xenial (9.10.3.dfsg.P2-{1..4} because I sucked)
[16:12] <lamont> I have not seen that bgu
[16:13] <lamont> and, tbf, core-dev work is all non-core hours for me
[16:13] <cyphermox> seems like the removing export bit might be wrong
[16:13] <cyphermox> lamont: oh, I'm not asking you to fix it, just you know better than me about this stuff on account of maintaining these packages
[16:13] <lamont> the goal (which upstream adopted) was to stop shipping 2 copies of the shared libs
[16:13] <cyphermox> ok
[16:15] <lamont> old isc-dhcp shipped a copy of the library source in the dhcp source, and we finally illed that off, and bind now ships all of it... the ultimately-correct path is probably going to be one that lets us deliver one shlibset, even if it means a runtime option or such craziness to toggle behavior, rather than compile-time switch
[16:15] <smb> lamont, There is just some other discussion that sounds like upstream shipped bind9.10 before dhcp could handle all the goodness
[16:15] <smb> lamont, https://lists.isc.org/pipermail/bind-users/2015-February/094640.html
[16:15] <lamont> smb: I think so.
[16:15] <cyphermox> hey, this is over a year old
[16:16] <smb> cyphermox, oops
[16:16] <lamont> OTOH, mgilbert (of isc-dhcp maintainerhood for debian) wants to go this route, and I think it'll have issues befroe _their_ freeze, so...
[16:16] <cyphermox> let's see how fedora deal with it, if it's using export, then I'll revert the change
[16:16] <lamont> cyphermox: bind9.10 first landed in xenial about tue 23rd Feb.  has never landed in sid
[16:16] <smb> cyphermox, I somehow missed the date part completely
[16:17] <lamont> cyphermox: please also get mgilbert's (oftc) input
[16:17] <cyphermox> smb: well, I'm saying over a year ago because both 4.3.2 (where this started happening according to the ML) and 9.10 where released somewhere in feb 2015
[16:17] <lamont> actually "gilbert" on oftc iirc
[16:18] <lamont> cyphermox: gilbert is co-maint on bind9, and part (all??) of the maint team for isc-dhcp, on debian.
[16:18] <smb> cyphermox, Yeah, and it so much matched what I saw that I did not wonder about its age
[16:19] <cyphermox> pinged him
[16:19] <cyphermox> heh
[16:22] <smb> cyphermox, just found a vm which I have not updated since dhcp broke, which shows it (dhclient to be in a poll_schedule_timeout instead of a futex_wait_(something)). I can leave that as is if we need something to compare to
[16:27] <cyphermox> the fact that it writes futex_wait_xyz doesn't mean much
[16:27] <cyphermox> here there's one thread in futex wait, one thread in epoll_wait, etc.
[16:29] <smb> cyphermox, ok, maybe means only its different. would the fact that for the new case I did a strace -p <pid> -ff and that also showed only one line of doing a futex wait call
[16:30] <smb> mean anything?
[16:31] <cyphermox> means you should have different files on disk too, ending in the pid..
[16:33] <smb> cyphermox, iirc in the new world there would only be one (no other thread)... but give  me a min I am installing a second vm locally to have both worlds in parallel
[16:34] <cyphermox> why should there just be one thread/
[16:34] <cyphermox> ?
[16:35] <smb> problem might be wait time related as other pids seem to show up only when there is activity
[16:36] <cyphermox> well strace will only write stuff when there is activity
[16:37] <cyphermox> anyway, I don't know enough of dhcp and bind libraries interactions to know what to do about this
[16:37] <cyphermox> I pinged gilbert on oftc, we'll see if the bug rings a bell
[16:37] <smb> cyphermox, ok. and thanks
[16:37] <cyphermox> fwiw; here dhclient works correctly with NM
[16:38] <cyphermox> I changed my renew time on the router to 5 minutes and I do see things being renewed every 5 minutes
[16:43] <smoser> hey
[16:43] <smoser> i typed:
[16:43] <smoser>  apport
[16:43] <smoser> on xenial and see
[16:44] <smoser> $ apport-collect 1552319
[16:44] <smoser> You need to run 'sudo apt-get install python-apport' for apport-collect to work.
[16:44] <smoser> are we hoping to make that go to python3-apport ?
[16:44] <smoser> as
[16:44] <smoser> 0 upgraded, 26 newly installed, 0 to remove and 10 not upgraded.
[16:44] <smoser> Need to get 5,265 kB of archives.
[16:44] <smoser> After this operation, 26.6 MB of additional disk space will be used.
[16:45] <cyphermox> smb: of course, on fedora they once built isc-dhcp against bind 9.10; and switched back to 9.9, but not explanation why
[16:45] <smb> cyphermox, heh... so I got the new vm running now and strace dhclient... lets see
[16:46] <cyphermox> ok
[16:52] <smb> cyphermox, right, so dns just removed the dynamic hostname of newvm due to not renew the lease. Meanwhile newvm strace -ff showed no activity whatsoever while old(er)vm did renew its lease which also showed up as strace activity
[16:56] <smb> cyphermox, is NM also using /sbin/dhclient -1 -v -pf <pidfile> -lf <leasefile> -I -df <ipv6leasefile> <interface> still (that does not seem to have changed though) and the main process is in "futex(0x7fb54906b0a4, FUTEX_WAIT_PRIVATE, 5, NULL" ?
[16:56] <cyphermox> smb: I don't know why that's happening, let's wait for mgilbert to respond, or doko to be around to look into this
[16:56] <cyphermox> /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d/network-manager.dhclient-eth1.pid -lf /var/lib/NetworkManager/dhclient-fabd6433-ac16-415b-aade-2298001b6f73-eth1.lease -cf /var/lib/NetworkManager/dhclient-eth1.conf eth1
[16:58] <smb> cyphermox, ok. Just was wondering whether it might be something obvious... I think I add at least that info to the bug report
[16:59] <cyphermox> another option may be "just" something broken in dhclient-script, I saw a bug on the BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800914 -- that might not be related at all though
[17:01] <smb> I guess a lot is possible
[17:07] <pitti> smb: py3-apport> yes, but we need a working python3-launchpadlib for that; see bug 1153671 for a list of blockers
[17:07] <pitti> err, smoser ^
[17:07] <pitti> smb: sorry, tab fail
[17:07] <smb> pitti, happens  :)
[17:07] <pitti> ogra_: so, what's up with /lib64?
[17:08] <ogra_> pitti, just trying to get you a proper log
[17:08] <pitti> l
[17:08] <ogra_> but the board fails again with broken /dev/urandom ... *sigh*
[17:09] <smoser> pitti, thanks.
[17:10] <ogra_> pitti, so adding set -x to /usr/share/initramfs-tools/hook-functions the end of my update-initramfs output looks like http://paste.ubuntu.com/15268324/
[17:10] <ogra_> pitti, the stuff from line 22 to the end shouldnt even be there
[17:10] <ogra_> (there is no hook that could trigger it)
[17:11] <ogra_> the former (and actualy last) hook ends at 21
[17:12] <ogra_> pitti, the script i use is build-initrd.sh from the initramfs-tools-ubuntu-core srouce package (note this isnt cleaned up yet and still has a lot of phone hacks just commented out yet)
[17:12] <jderose> cyphermox: so from studying syslog, it seems NetworkManager is bringing up networking correctly, just oem-config-firstboot isn't utilizing it. is it possible oem-config-firstboot just isn't loading the ubi-network.py and ubi-wireless.py plugins?
[17:12] <ogra_> the current call i use is: fakechroot chroot ./build update-initramfs -c -kcore-1234 -v
[17:13] <ogra_> (in a specifically set up chroot)
[17:16] <pitti> ogra_: what's the code that corresponds to http://paste.ubuntu.com/15268324/? obviously not the /usr/share/initramfs-tools/hook-functions on xenial?
[17:17] <pitti> oh, I mis-looked
[17:17] <ogra_> it is copy_exec mainly ... from that file
[17:17] <ogra_> (with set -x set)
[17:18] <pitti> ogra_: and /usr/share/initramfs-tools/hooks/resize ? (that's not on my system); it's allegedly the  thing that failed?
[17:18] <ogra_> pitti, no, it isnt ... i can remove that one and it will still fail ... it is shipped in initramfs-tools-ubuntu-core
[17:18] <ogra_> pitti, the lines after line 22 from the pastebin are always executed ... regardless
[17:19] <pitti> ………………………………………………………………echo "Calling hook ${cs_x}"
[17:19] <ogra_> i.e. no matter which hooks are there
[17:19] <pitti> …………………………………………fi
[17:19] <pitti> …………………………………………${initdir}/${cs_x} && ec=$? || ec=$?
[17:19] <pitti> that's apparently from there (the ec=1)
[17:19] <pitti> I just don't see "Calling hook" in the log
[17:19] <ogra_> because it isnt a full log ...
[17:20] <ogra_> i need to reboot the board abd start from scratch (cant run update-initramfs anymore because /dev/urandom on the board went crazy)
[17:20] <pitti> ogra_: can you add set -x to /usr/share/initramfs-tools/hooks/resize ?
[17:21] <ogra_> pitti, i can just remove the hook and it will still fail the same
[17:21] <pitti> I mean, that's the one that fails, so that's the one we need to look at, no?
[17:21] <ogra_> but yeah, if you feel like :)
[17:21] <ogra_> no
[17:21] <ogra_> thats a lie
[17:21] <ogra_> it isnt the hook
[17:21] <pitti> well, *that* hook can't fail then, does another one fail after that?
[17:21] <ogra_> it is just that the code that fsails runs after the last hook
[17:22] <ogra_> let me reboot the board so i get /dev/urandom back
[17:22] <ogra_> silly stuff ... lsb_release is called but needs urandom ...
[17:23] <ogra_> pitti, oh, i actually have such a log ... i added set -x to resize earlier
[17:23] <ogra_> http://paste.ubuntu.com/15267323/
[17:23] <pitti> ogra_: /dev/urandom -> /dev/zero ? *grin*
[17:23] <ogra_> haha
[17:25] <pitti> ogra_: so taht fails on copying /sbin/resize2fs (parted still worked)
[17:25] <ogra_> pitti, here is a full run with set -x in hook-funtions ...
[17:26] <pitti> [ -f /lib64/ld-linux-aarch64.so.1 ]
[17:26] <pitti> so that fails
[17:26] <zequence> pitti: fonts-droid should be changed to fonts-android?
[17:26] <ogra_> pitti, here is a full run after rm'ing the resize script http://paste.ubuntu.com/15268536/
[17:27] <pitti> zequence: no, fonts-noto AFAIK
[17:27] <ogra_> pitti, the hooks are a red herring ... it is code that runs *after* the hooks
[17:27] <ogra_> or at the end of the last hook regardless what that is
[17:27] <pitti> ogra_: yeah, so that fails on chown
[17:28] <ogra_> right, totally random
[17:28] <pitti> ogra_: no, it's fails somewhere in copy_exec
[17:28] <ogra_> right
[17:28] <pitti> the hooks also call copy_exec or stuff a lot
[17:28] <ogra_> but only on the last hook
[17:28] <pitti> [ -f /lib64/ld-linux-aarch64.so.1 ]
[17:28] <ogra_> yes
[17:28] <pitti> ogra_: no, it fails in the middle
[17:28] <pitti> ogra_: I'd bet this is a fakechroot bug on arm64, needing an update for current glibc
[17:28] <ogra_> pitti, search for lib64 in either of th logs
[17:28] <pitti> there's a quadzillion __xstat* calls that need to be implemented
[17:28] <ogra_> it is only called at the very end once
[17:29] <pitti> unless the symlink is actually broken
[17:29] <pitti> (or doesn't exist)
[17:29] <pitti> [ -e /lib64/ld-linux-aarch64.so.1 ]
[17:29] <zequence> Right, saw the bug report now. Going to make the changes now
[17:29] <pitti> that does work
[17:29] <ogra_> pitti, how does that work, there is no /lib64 dir anywhere
[17:29] <pitti> ogra_: my recommendation: run the whole thing under strace, and then we compare what stat() says
[17:29] <ogra_> oh my
[17:30] <pitti> ogra_: err, what?
[17:30] <ogra_> that will be gigabytes of logs data
[17:30] <pitti> ogra_: well, if there's indeed no /lib64, that explains the stat failure indeed
[17:30] <ogra_> pitti, ubuntu (nor debian) have ever had /lib64
[17:30] <pitti> by why is the dir missing?
[17:30] <pitti> wut?
[17:30] <pitti> ogra_: no, it must be there
[17:30] <ogra_> no
[17:30] <pitti> lrwxrwxrwx 1 root root 32 Feb 17 00:01 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.21.so
[17:30] <ogra_> oh
[17:30] <ogra_> oh !
[17:31] <pitti> that's glibc/linker ABI
[17:31] <ogra_> so why dont we have it on arm64
[17:31] <ogra_> hah
[17:31] <cjwatson> yes, the dynamic linker has historically been in /lib64 on that arch even though nothing else is
[17:31] <cjwatson> but that's totally arch-specific
[17:31] <cjwatson> no reason to carry it over to arm64
[17:31] <cjwatson> or not necessarily a reason; I don't have the linker paths for all arches in my head
[17:31] <pitti> well, the point is, copy_exec() should mkdir it if it isn't there
[17:31] <ogra_> ubuntu@localhost:~$ uname -m
[17:31] <ogra_> aarch64
[17:31] <ogra_> ubuntu@localhost:~$ ls /|grep lib
[17:31] <ogra_> lib
[17:31] <ogra_> ubuntu@localhost:~$
[17:32] <ogra_> cjwatson, well, there is that armhf hackery that adam did in mkinitramfs for the linker ... i wonder if we need something like that for arm64
[17:33]  * ogra_ just got some food ... back in 10-15min
[17:33] <pitti> + copy_file library /lib64/ld-linux-aarch64.so.1
[17:34] <pitti> so it ceratinly *tries* to copy the file, but if that file doesn't even exist, then we need to debug back how it got that name
[17:34] <ogra_> right
[17:35] <pitti> /lib64 isn't hardcoded in either i-t or i-t-u-core
[17:35] <ogra_> no, it gets it from soe ldd or some such
[17:35] <ogra_> *some
[17:36] <pitti> …………………………………………nonoptlib=$(echo "${x}" | sed -e 's#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#')
[17:36] <pitti> that's the first occurrence of /lib64, in ${x}
[17:36] <pitti> and that's from a line in ldd
[17:37] <ogra_> yeah
[17:37] <pitti> ogra_: what's the output of ldd /usr/lib/initramfs-tools/bin/wait-for-root ?
[17:37] <pitti> ogra_: I think that's the exec it's currently copying when /lib64 appears
[17:37] <ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/usr/lib/initramfs-tools/bin/wait-for-root
[17:37] <ogra_> 	linux-vdso.so.1 =>  (0x0000007fa9e20000)
[17:37] <ogra_> 	libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007fa9de8000)
[17:37] <ogra_> 	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa9c9f000)
[17:37] <ogra_> 	/lib/ld-linux-aarch64.so.1 (0x0000005570feb000)
[17:37] <ogra_> 	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa9c73000)
[17:38] <ogra_> no lib64
[17:38] <pitti> ldd /lib/x86_64-linux-gnu/libc-2.21.so
[17:38] <pitti> sorry
[17:38] <pitti> ldd /lib/aarch64-linux-gnu/libc-2.21.so
[17:39] <ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/aarch64-linux-gnu/libc.so.6
[17:39] <ogra_> 	/lib/ld-linux-aarch64.so.1 (0x0000005562908000)
[17:39] <ogra_> 	linux-vdso.so.1 =>  (0x0000007f8406d000)
[17:39] <ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/ld-linux-aarch64.so.1
[17:39] <ogra_> 	statically linked
[17:41] <pitti> ogra_: can you add some extra echo/output of ldd  into hook-functions:copy_exec()?
[17:41] <ogra_> what exactly ?
[17:41] <pitti> somewhere in copying /usr/lib/initramfs-tools/bin/wait-for-root the transitive ldd output stumbles over /lib64
[17:42] <pitti> for example, here:
[17:42] <pitti> ……………………for x in $(ldd "${src}" 2>/dev/null | sed -e '
[17:42] <pitti> ...
[17:42] <ogra_> hmm
[17:42] <pitti> do that instead:
[17:42] <pitti> ldd_out=$(ldd ...)
[17:42] <pitti> echo "--------"
[17:42] <pitti> echo "ldd output of ${src}:"
[17:42] <pitti> echo "$ldd_out"
[17:42] <pitti> for x in $ldd_out
[17:42] <ogra_> i wonder if it is actually th sed call that turns  /lib/aarch64-linux-gnu/ into /lib64 in the end
[17:43] <ogra_> by stipping out chars
[17:43] <ogra_> will add, but i need to quickly finish dinner ... gimme a bit
[17:43] <pitti> ogra_: right, hence my proposal to show what that actually does, for each binary
[17:43] <ogra_> yeah
[17:43] <pitti> ogra_: as it's not entirely obvious to me
[17:43] <pitti> ogra_: ok, have dinner, I need to make a phone call and pack my basketball stuff
[17:43] <ogra_> k
[17:53] <cyphermox> jderose: yes, exactly, will look in a bit
[17:53] <jderose> cyphermox: awesome, thanks!
[17:54] <pitti> ogra_: err, you did the ldd "outside" the fakechroot, right? that might not be the same
[17:55] <ogra_> no no ... all fine ... fakechroot is called at the very top level
[17:57] <ogra_> hmm, or not
[17:59] <ogra_> there is some issue with the syntax ...
[18:00] <ogra_> Adding binary /sbin/parted
[18:00] <ogra_> + cp -pP /sbin/parted /var/tmp/mkinitramfs_4KkPDA//sbin/parted
[18:00] <ogra_> + /usr/bin/ldd /sbin/parted
[18:00] <ogra_> ldd: /sbin/parted: No such file or directory
[18:00]  * ogra_ scratches head
[18:00] <ogra_> a line above it copies parted but ldd doesnt find it ...
[18:02] <ogra_> http://paste.ubuntu.com/15268819/
[18:03] <ogra_> it seems it doesnt hit that code path at all
[18:04] <ogra_> pitti, how did you get the idea it is wait-for-root btw ? i dont see it there anywhere
[18:05] <ogra_> (i see it at the very start of the run)
[18:05] <ogra_> oooh !!!
[18:06] <ogra_> ignore my former comment i'm blind :P
[18:06] <ogra_> it is indeed wait-for-root that has /lib64/ld-linux-aarch64.so.1 in its ldd output
[18:07] <ogra_> see lines 384, 394 and 400 of the last paste
[18:07] <ogra_> sooo ...
[18:08] <ogra_> lets see what happens if i create /lib64 in the chroot and copy the linker there ;)
[18:08] <davmor2> ogra_: wow that is impressive touch typing ;)
[18:09] <pitti> ogra_: bazinga!
[18:10] <ogra_> http://paste.ubuntu.com/15268877/ ...
[18:10] <ogra_> + echo Building cpio /boot/initrd.img-core-1234.new initramfs
[18:10] <ogra_> Building cpio /boot/initrd.img-core-1234.new initramfs
[18:10] <ogra_> \o/
[18:10] <pitti> ogra_: so the only thing that's missing is an effing mkdir -p?
[18:10] <ogra_> and a cp
[18:11] <ogra_> after all it wants to pull /lib64/ld-linux-aarch64.so.1 from /lib64
[18:11] <ogra_> but i can easily add that to the build script
[18:11] <pitti> ogra_: oh, you mean nothing copies ld.so into the chroot?
[18:11] <ogra_> it comes from /lib
[18:11] <pitti> ogra_: well, if you don't have /lib64 in a real aarch64 xenial system, then it seems something went wrong with linking wait-for-root?
[18:11] <ogra_> but there is no /lib64 at all
[18:11] <ogra_> yeah
[18:12] <ogra_> who owns that ?
[18:12] <ogra_> ah
[18:12] <ogra_> initramfs-tools-bin
[18:12] <pitti> wait-for-root: wait-for-root.o
[18:12] <pitti> ……………………$(CC) $(LDFLAGS) -o $@ $< $(UDEV_LIBS)
[18:13] <pitti> UDEV_LIBS = $(shell $(PKG_CONFIG) --libs libudev)
[18:13] <xnox> apw, could you please promote s390-zfcp from universe to main? MIR approved -> https://bugs.launchpad.net/ubuntu/+source/s390-zfcp/+bug/1552218
[18:13]  * cyphermox -> lunch
[18:13] <pitti> ogra_: can you check that pkg-config? maybe that brings in the /lib64
[18:13] <ogra_> you are assuming i have the source here :P
[18:13] <pitti> ogra_: gcc -g -Wall -O2    -c -o wait-for-root.o wait-for-root.c
[18:13] <pitti> hm, no, not really
[18:14] <pitti> (from https://launchpadlibrarian.net/237016603/buildlog_ubuntu-xenial-arm64.initramfs-tools_0.122ubuntu3_BUILDING.txt.gz)
[18:14] <ogra_> that doesnt look like there is any pkg-config
[18:14] <pitti> and gcc  -o wait-for-root wait-for-root.o -ludev
[18:14] <pitti> right
[18:14] <pitti> ogra_: OOI, does ldd of libudev.so have any /lib64 stuff? or any other libraries in /lib ?
[18:14] <ogra_> lets see
[18:14] <pitti> seems odd to not have /lib64 but things linking to it
[18:15] <pitti> ogra_: so, to sum up, you have a h4ck1sh workaround to at least continue experiments, but we haven't really solved the mystery yet
[18:16] <ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# ldd build/lib/aarch64-linux-gnu/libudev.so.1
[18:16] <ogra_> 	linux-vdso.so.1 =>  (0x0000007f85daf000)
[18:16] <ogra_> 	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f85d4c000)
[18:16] <ogra_> 	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f85c03000)
[18:16] <ogra_> 	/lib/ld-linux-aarch64.so.1 (0x000000555f57c000)
[18:16] <pitti> ok, so that's not it
[18:16] <ogra_> pitti, not more hackish than the rest of the script currently, so i'm fine :)
[18:16] <pitti> ogra_: touché
[18:16] <ogra_> i need to clean up all that mess anyway :)
[18:16] <ogra_> its all still half touch ... which required a lot more hackery
[18:17] <ogra_> i guess i can cut it down to ten lines in the end ... or some such :)
[18:17] <pitti> ogra_: it might be worth a try whether initramfs-tools from -proposed is any different (toolchain change or what not)
[18:17] <ogra_> but that wait-for-root is definitely broken
[18:17] <pitti> ogra_: I suppose if you try to start wait-for-root it crashes?
[18:17] <pitti> instead of getting an "Usage:" help
[18:18] <ogra_> nope
[18:18] <ogra_> it waits properly
[18:18] <ogra_> root@localhost:/initramfs-tools-ubuntu-core-0.7.20# time build/usr/lib/initramfs-tools/bin/wait-for-root /dev/mmcblk0p1 10
[18:18] <ogra_> real	0m10.040s
[18:18] <ogra_> ...
[18:18] <ogra_> seems to work just properly
[18:19] <ogra_> i guess the linker is clever enough to translate it ?
[18:19] <ogra_> just not under fakechroot ?
[18:19] <pitti> ogra_: hm, maybe, that's the bit I'm not familiar with
[18:19] <pitti> ogra_: strace is your friend :)
[18:19] <ogra_> yeah
[18:20] <pitti> you can also see how fakechroot mangles the paths
[18:20] <ogra_> well, let me apply the workaround and get the package ready so i unblock the others :)
[18:20] <pitti> ogra_: sorry, need to leave to basketball now
[18:20] <ogra_> pitti, thanks so much for leading me the right way
[18:21] <pitti> ogra_: I'll be back around 22:45, and will check IRC again
[18:21]  * ogra_ hugs pitti 
[18:21]  * pitti hugs ogra_
[18:21] <ogra_> i'll be fine now
[18:21] <ogra_> wait-for-root under fakechrot is fine too
[18:26]  * ogra_ uploads
[18:58] <nacc_> Pharaoh_Atem: any experience debugging pcre jit :)
[18:58] <nacc_> Pharaoh_Atem: I think gdb doesn't really like doing it, as functions tend to disappear
[19:01] <Pharaoh_Atem> nacc_: remember when I said earlier about this bug making me want to cry?
[19:01] <nacc_> Pharaoh_Atem: :)
[19:01] <nacc_> Pharaoh_Atem: well, i've got the breakpoitns and stuff working, i can see the value flip
[19:01] <nacc_> Pharaoh_Atem: did you see my comment from last night?
[19:01] <nacc_> we do have a workaround of sorts
[19:02] <Pharaoh_Atem> I'm extremely tempted to just say fuck it and shut off pcre.jit
[19:02] <nacc_> Pharaoh_Atem: i'm not sure where the bug is yet, though
[19:02] <Pharaoh_Atem> that's true
[19:03] <nacc_> Pharaoh_Atem: because if it is in pcre, we do need to fix it, i'd say :)
[19:04] <Pharaoh_Atem> damn it
[19:04] <Pharaoh_Atem> you're right :(
[19:53] <nicolas17> https://wiki.ubuntu.com/ is down
[20:07] <nacc_> Pharaoh_Atem: ok, so in the short-term, i'm  happy to push a debdiff to use --process-isolation for twig's tests, but then three other tests fail ... http://paste.ubuntu.com/15269619/
[20:07] <nacc_> Pharaoh_Atem: any ideas?
[20:11] <mwhudson> infinity: this time for sure (?) https://launchpad.net/~mwhudson/+archive/ubuntu/go16-trusty/+packages
[20:30] <slangasek> nacc_: is this run-tests.php script not part of the source for php-imagick?
[20:30] <nacc_> slangasek: it's generated during the build
[20:31] <nacc_> slangasek: i've got further iwth phpunit again ... i'm a bit worried it's a racy failure
[20:31] <nacc_> that is run-tests.php happens to not show it
[20:31] <nacc_> but phpunit does
[20:31] <nacc_> as it only hpapens sometimes when i run the tests in question manually
[20:34] <nacc_> slangasek: so it's not available in the autopkgtest unless we re-run configure (or i could package it up, i guess, but that doesn't seem very clean to me)
[20:35] <slangasek> nacc_: ok, so one of the options for debian/tests/control is to require a source package build
[20:35] <slangasek> I don't remember the syntax offhand
[20:35] <slangasek> but if you have a generated script that comes from the source and is only used for the test suite, that's the right way to do it, not packaging it up
[20:36] <nacc_> slangasek: ok, that's what i was tempted to do ... but i don't want to just paper over a possible real error
[20:36] <nacc_> i'm debugging it now
[20:36] <nacc_> slangasek: for twig, i think we're going to need to do a patch for the short-term, as i've got bugs filed with upstream, but don't know how to debug it much further on my own
[20:36] <rbasak> Restriction: build-needed
[20:36] <nacc_> slangasek: will post a ubuntu4 debdiff
[20:36] <slangasek> nacc_: ok
[20:37] <rbasak> """
[20:37] <rbasak>     Please use this considerately, as for large builds it unnecessarily
[20:37] <rbasak>     builds the entire project when you only need a tiny subset (like the
[20:37] <rbasak>     tests/ subdirectory). It is often possible to run ``make -C tests``
[20:37] <rbasak>     instead, or copy the test code to ``$ADTTMP`` and build it there
[20:37] <rbasak>     with some custom commands.
[20:37] <rbasak> """
[20:37] <rbasak> s/Restriction/Restrictions/
[20:37] <rbasak> HTH
[20:37] <nacc_> rbasak: ah thanks ...
[20:37] <nacc_> slangasek: so the other thing is that debian made this chagne ... and it's unclear if it was a good idea in the first place :)
[20:38] <nacc_> ongoing discussions about that :)
[20:40] <nacc_> slangasek: so should i be putting in versioned depenendencies on phpunit now? so taht we get the one from proposed that depends o php-xml?
[22:05] <pitti> ogra_: ah, no further discussion here, any luck?
[22:08] <pitti> apw: binNEWed the kernel FYI
[22:09]  * pitti cleans up kernel NBS while he's at it
[22:24] <apw> pitti: thanks :-)
[22:27] <ogra_> pitti, all good, the binaries just landed in the archive
[22:31] <ogra_> (well, still in proposed, but they shoould migrate soon)
[22:49] <nacc_> rbasak: slangasek: fyi, it's Restrictions: build-needed (note need the s)
[23:08] <slangasek> nacc_: no, we shouldn't be declaring versioned dependencies on phpunit - though the new version of php-cli should declare a versioned Breaks against the old phpunit
[23:12] <nacc_> slangasek: ok, i'll update my debdiff for twig then ... and send a new debdiff for php-defaults?
[23:37] <nacc_> Pharaoh_Atem: am i right in reading the php builds that ZTS is off in debian/ubuntu?