| 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:11 |
|---|---|---|
| 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. | 00:12 |
| 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 | 01:01 |
| === juliank is now known as Guest41416 | ||
| === juliank_ is now known as juliank | ||
| === cody-somerville_ is now known as cody-somerville | ||
| hallyn | pitti: hey... so you wrote a patch for systemd-shim "Clean up closing logind sessions". | 03:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| hallyn | or can i just get rid of that since in all real installs we expect to be using real systemd | 03:56 |
| 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 :) | 03:57 |
| 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:04 |
| Son_Goku | :( | 04:05 |
| Son_Goku | can you plea for them to move asap? | 04:08 |
| 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:12 |
| 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:13 |
| sarnold | hallyn: haha :) | 04:20 |
| hallyn | all right, that fixes it. I'll sling a debdiff over to pitti after find some more kleenex to dry my tears | 04:21 |
| hallyn | hm, no, i was wrong. drat. | 04:23 |
| hallyn | meh, bad patch. | 04:25 |
| hallyn | pitti: http://paste.ubuntu.com/15264990/ | 05:00 |
| hallyn | ugh. minus the debug statements | 05:02 |
| 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:03 |
| hallyn | sarnold: well i wanted to catch the length of a dbus reply for an empty string :) | 05:04 |
| sarnold | :) | 05:04 |
| hallyn | then again, now my vm has a corrupt fs. did my patch somehow contribute to that? | 05:08 |
| 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:14 |
| 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:15 |
| hallyn | i'm open to suggestions, i'll tkae that one | 05:22 |
| hallyn | \o | 05:22 |
| cpaelzer | good morning | 05:46 |
| 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:33 |
| pitti | hallyn: http://paste.ubuntu.com/15264999/ LGTM | 06:35 |
| 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:36 |
| hallyn | pitti: cool, thanks. | 06:45 |
| 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:46 |
| hallyn | no, breaks sounds more accurate per the docs | 06:49 |
| pitti | hallyn: it should Breaks: (<< fixed_version) | 06:51 |
| hallyn | kewl, pushing htat, and calling it a day - thx | 06:52 |
| 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:53 |
| Skuggen | pitti: But the #DEBHELPER# code will also do the 'proper' starting of the service that should happen at the end | 06:54 |
| pitti | Skuggen: so you need to things *between* enable and start? OOI, what is that? | 06:59 |
| 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:02 |
| Skuggen | And we added running mysql_upgrade as part of postinst instead of relying on users doing it manually | 07:03 |
| pitti | Skuggen: right, but can't that happen before the debhelper stuff? | 07:05 |
| pitti | i. e. | 07:05 |
| 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:06 |
| 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:07 |
| pitti | Skuggen: *confused* I thought you said the service must *not* be running yet for upgrading? | 07:18 |
| 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:19 |
| 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:20 |
| pitti | Skuggen: so I think the question is "do you need to anything *within* the #DEBHELPER# generated code" | 07:22 |
| 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:23 |
| Skuggen | Hopefully not. I'll give it a try. Thanks for the help :) | 07:24 |
| dholbach | good morning | 07:45 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| cpaelzer | pitti: waitnig for IS replies to your post now, thanks for testing your scalingstack instances | 07:57 |
| 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:58 |
| 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 | 07:59 |
| 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:03 |
| pitti | cpaelzer: I'd rather expand it into the debci log | 08:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| Skuggen | pitti: Simply moving everything that needed a running server below #DEBHELPER# does the trick. Thanks! | 08:31 |
| === willcooke_ is now known as willcooke | ||
| 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:36 |
| ubottu | bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351 | 09:36 |
| 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:42 |
| Saviq | satisfactioon | 09:43 |
| Mirv | is there a way to see what autosynced from Debian between certain dates (2016-02-17 - end of auto sync period)? | 10:15 |
| seb128 | Mirv, I don't think we have a list for those, but autosync stopped on the 18 iirc | 10:19 |
| 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:20 |
| seb128 | Mirv, how are those generated? | 10:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| seb128 | Mirv, https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1547466 | 10:27 |
| ubottu | Launchpad bug 1547466 in grep (Ubuntu) "grep switches into binary mode while processing a text file" [High,New] | 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:27 |
| 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:28 |
| 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:29 |
| pitti | xnox: I don't see how squid3 depends on squid | 10:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| smb | I don'T think so (yet). I think I could not convince Brian it is broken | 10:37 |
| 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:38 |
| 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:39 |
| 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:40 | |
| Saviq | pitti, thanks :) | 10:41 |
| 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:48 |
| smb | seb128, not like that sounds the discussion is going well... | 10:57 |
| seb128 | yeah... | 10:57 |
| 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:58 |
| 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... | 10:59 |
| seb128 | who would the right person to do that call? foundations? | 11:01 |
| smb | guess foundations but not sure which person... slangasek ? | 11:04 |
| 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:10 |
| oSoMoN | ok | 11:11 |
| 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:41 |
| dholbach | Laney, I won't have time to look at the tomahawk thing in the next days :-/ | 11:42 |
| Laney | dholbach: ok, well keep it on the queue then | 11:50 |
| === _salem is now known as salem_ | ||
| pitti | LocutusOfBorg: sorry, what's wrong with ubuntukylin-meta? | 11:52 |
| 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 | 11:54 |
| LocutusOfBorg | pitti, https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html :) | 12:01 |
| 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:33 |
| pitti | Saviq: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html is good again now | 12:47 |
| Saviq | pitti, great, thanks | 12:48 |
| pitti | LocutusOfBorg: re (sorry, out for lunch); ok, I'll update the seeds now | 12:49 |
| pitti | LocutusOfBorg: ugh, it wasn't updated since wily | 12:53 |
| pitti | LocutusOfBorg: uploaded | 13:08 |
| === directhex_ is now known as directhex | ||
| LocutusOfBorg | thanks! | 13:16 |
| 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:28 |
| pitti | maybe schroot dir/overlay/mount dir has "nosuid" or so? | 13:29 |
| tjaalton | maybe, it's on /run/shm | 13:31 |
| 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:32 |
| 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:36 |
| LocutusOfBorg | zequence, you there? hi | 13:39 |
| LocutusOfBorg | ubuntustudio-meta is the last blocker for fonts-android migration | 13:39 |
| 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:42 |
| LocutusOfBorg | zequence, look e.g. lp: #1546847 | 13:43 |
| ubottu | Launchpad bug 1546847 in ubuntukylin-theme (Ubuntu) "Fonts-droid has been deprecated and removed, use fonts-droid-fallback instead of fonts-droid" [Undecided,New] https://launchpad.net/bugs/1546847 | 13:43 |
| LocutusOfBorg | and https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html | 13:43 |
| pitti | LocutusOfBorg: I can update that as well, while I'm at it | 13:53 |
| 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:56 |
| mardy_ | cjwatson: is there some way to prevent the daily builder to use that option? | 13:57 |
| cjwatson | mardy_: No. | 13:57 |
| 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:58 |
| ubottu | Debian bug 735377 in dpkg-dev "dpkg-source: 3.0 (native) silently ignores many binary files by default" [Normal,Open] | 13:58 |
| mardy_ | cjwatson: but it doesn't seem to work here, it looks like the -I given from the commandline is "stronger" | 13:59 |
| 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:00 |
| 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:01 |
| 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:04 |
| cyphermox | good morning! | 14:09 |
| mdeslaur | hi cyphermox | 14:09 |
| barry | mterry: cool, thanks | 14:09 |
| cyphermox | hey mdeslaur | 14:09 |
| 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:10 |
| cyphermox | smb: ah? | 14:11 |
| pitti | LocutusOfBorg: perhaps you can do a MP? | 14:11 |
| 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:12 |
| 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:13 |
| cyphermox | bug #? | 14:14 |
| smb | cyphermox, bug 1551351 | 14:14 |
| ubottu | bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351 | 14:14 |
| * 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| cyphermox | .. or to fix isc-dhcp itself | 14:20 |
| smoser | cyphermox, i'd appreciate your thoughts on https://bugs.launchpad.net/curtin/+bug/1551937 . i tried to summarize in comment 7. | 14:21 |
| ubottu | Launchpad bug 1551937 in curtin "lvm and multipath and xenial not happy together" [High,Confirmed] | 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:21 |
| cyphermox | mkay | 14:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| cyphermox | smoser: it would be necessary to look also at the bindings file, and the output of multipath -ll from the initramfs | 14:29 |
| 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| cyphermox | yes | 14:38 |
| cyphermox | that's the fun part is writing installers :) | 14:38 |
| cyphermox | *in | 14:38 |
| smoser | do you have a suggestion on how to know which behavior? | 14:40 |
| cyphermox | what do you mean? | 14:40 |
| 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:41 |
| barry | mterry: you rock, thanks | 14:46 |
| mterry | barry, how close are we now to a python2 free image? | 14:47 |
| 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:48 |
| 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:49 |
| cyphermox | you could modprobe them if it needs to do multipath stuff? | 14:50 |
| 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:51 |
| Son_Goku | barry: I thought system-config-printer-* was already converted to py3? | 14:55 |
| 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:56 |
| Son_Goku | wait, why does system-config-printer need Samba | 14:57 |
| Son_Goku | doesn’t it use IPP? | 14:57 |
| barry | system-config-printer-common -> python3-smbc -> libsmbclient -> samba-libs | 14:58 |
| 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 | 14:59 |
| Son_Goku | barry: where’s python3-smbc coming from? | 15:00 |
| 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:01 |
| === pepee- is now known as pepee | ||
| ogra_ | bah, infinity is out today ? | 15:06 |
| barry | ogra_: i believe so, yes | 15:06 |
| ogra_ | sad .. | 15:06 |
| smoser | cyphermox, well, maybe. i did result in trusty deploying lvm on top of multipath before knowing of this difference | 15:07 |
| smoser | so as for now, i'm quite blissful in my ignorance. | 15:09 |
| Son_Goku | barry: I’m super confused about that | 15:09 |
| barry | Son_Goku: any insight is appreciated | 15:10 |
| 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:11 |
| barry | Son_Goku: python3-smbc, but i think you're saying that it might be an old dependency that can get dropped? | 15:12 |
| === tvoss|lunch is now known as tvoss | ||
| 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:12 |
| 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:13 |
| 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:14 |
| ubottu | bug 1551601 in dpdk (Ubuntu) "DPDK init scripts need some hardening against broken specifications in /etc/dpdk/interfaces" [High,Triaged] https://launchpad.net/bugs/1551601 | 15:14 |
| 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:15 |
| 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:16 |
| ogra_ | slangasek, around ? | 15:18 |
| barry | ogra_: probably not ;) | 15:18 |
| ogra_ | bah | 15:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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 |
| === pepee- is now known as pepee | ||
| tkamppeter | seb128, meaning that I can only demote python3-smbc to Suggests. | 15:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:47 |
| 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:48 |
| 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 |
| ubottu | Debian bug 815205 in src:sbcl "sbcl: FTBFS due to TeX error" [Serious,Open] | 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:55 |
| barry | (well samba-libs-py3 or some such) | 15:56 |
| bdmurray | xnox: Could you have a look at bug 1550823? | 16:07 |
| ubottu | bug 1550823 in mdadm (Ubuntu Xenial) "checkarray doesn't work with sh = dash" [High,Triaged] https://launchpad.net/bugs/1550823 | 16:07 |
| 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 |
| ubottu | bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351 | 16:09 |
| xnox | bdmurray, please subscribe foundations bugs to s390-zfcp | 16:09 |
| xnox | bdmurray, for MIR | 16:09 |
| 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:10 |
| cyphermox | nothing appears in exp for isc-dhcp... | 16:11 |
| cyphermox | at least, according to tracker.d.o | 16:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| === psivaa_ is now known as psivaa | ||
| 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 |
| === FourDollars_ is now known as FourDollars | ||
| smb | cyphermox, I somehow missed the date part completely | 16:16 |
| === pepee- is now known as pepee | ||
| 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:17 |
| 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:18 |
| === balkamos_ is now known as balkamos | ||
| cyphermox | pinged him | 16:19 |
| cyphermox | heh | 16:19 |
| 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:22 |
| 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:27 |
| 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:29 |
| smb | mean anything? | 16:30 |
| cyphermox | means you should have different files on disk too, ending in the pid.. | 16:31 |
| 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:33 |
| cyphermox | why should there just be one thread/ | 16:34 |
| cyphermox | ? | 16:34 |
| smb | problem might be wait time related as other pids seem to show up only when there is activity | 16:35 |
| cyphermox | well strace will only write stuff when there is activity | 16:36 |
| 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:37 |
| cyphermox | I changed my renew time on the router to 5 minutes and I do see things being renewed every 5 minutes | 16:38 |
| smoser | hey | 16:43 |
| smoser | i typed: | 16:43 |
| smoser | apport | 16:43 |
| smoser | on xenial and see | 16:43 |
| 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:44 |
| 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:45 |
| cyphermox | ok | 16:46 |
| 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:52 |
| 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:56 |
| 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:58 |
| 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 | 16:59 |
| ubottu | Debian bug 800914 in isc-dhcp-client "isc-dhcp-client: dhclient-script fails with /bin/sh=/bin/dash after latest upgrade" [Important,Fixed] | 16:59 |
| smb | I guess a lot is possible | 17:01 |
| pitti | smb: py3-apport> yes, but we need a working python3-launchpadlib for that; see bug 1153671 for a list of blockers | 17:07 |
| ubottu | bug 1153671 in apport (Ubuntu) "Port to python3-launchpadlib" [Low,Triaged] https://launchpad.net/bugs/1153671 | 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:07 |
| 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:08 |
| smoser | pitti, thanks. | 17:09 |
| 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:10 |
| ogra_ | the former (and actualy last) hook ends at 21 | 17:11 |
| 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:12 |
| ogra_ | (in a specifically set up chroot) | 17:13 |
| 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:16 |
| pitti | oh, I mis-looked | 17:17 |
| ogra_ | it is copy_exec mainly ... from that file | 17:17 |
| ogra_ | (with set -x set) | 17:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| === pepee- is now known as pepee | ||
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| * ogra_ just got some food ... back in 10-15min | 17:33 | |
| pitti | + copy_file library /lib64/ld-linux-aarch64.so.1 | 17:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| cyphermox | jderose: yes, exactly, will look in a bit | 17:53 |
| jderose | cyphermox: awesome, thanks! | 17:53 |
| pitti | ogra_: err, you did the ldd "outside" the fakechroot, right? that might not be the same | 17:54 |
| ogra_ | no no ... all fine ... fakechroot is called at the very top level | 17:55 |
| ogra_ | hmm, or not | 17:57 |
| ogra_ | there is some issue with the syntax ... | 17:59 |
| 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:00 |
| ogra_ | http://paste.ubuntu.com/15268819/ | 18:02 |
| ogra_ | it seems it doesnt hit that code path at all | 18:03 |
| ogra_ | pitti, how did you get the idea it is wait-for-root btw ? i dont see it there anywhere | 18:04 |
| ogra_ | (i see it at the very start of the run) | 18:05 |
| ogra_ | oooh !!! | 18:05 |
| 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:06 |
| ogra_ | see lines 384, 394 and 400 of the last paste | 18:07 |
| ogra_ | sooo ... | 18:07 |
| 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:08 |
| pitti | ogra_: bazinga! | 18:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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 |
| ubottu | Launchpad bug 1552218 in s390-zfcp (Ubuntu) "[MIR] s390-zfcp" [Medium,Fix committed] | 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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_ | real0m10.040s | 18:18 |
| ogra_ | ... | 18:18 |
| ogra_ | seems to work just properly | 18:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| === pepee- is now known as pepee | ||
| * ogra_ uploads | 18:26 | |
| === mitya57_ is now known as mitya57 | ||
| 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 | 18:58 |
| 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:01 |
| 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:02 |
| nacc_ | Pharaoh_Atem: because if it is in pcre, we do need to fix it, i'd say :) | 19:03 |
| Pharaoh_Atem | damn it | 19:04 |
| Pharaoh_Atem | you're right :( | 19:04 |
| nicolas17 | https://wiki.ubuntu.com/ is down | 19:53 |
| === marga_ is now known as marga | ||
| 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:07 |
| mwhudson | infinity: this time for sure (?) https://launchpad.net/~mwhudson/+archive/ubuntu/go16-trusty/+packages | 20:11 |
| 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:30 |
| 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:31 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| nacc_ | ongoing discussions about that :) | 20:38 |
| 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? | 20:40 |
| === salem_ is now known as _salem | ||
| === utlemmin` is now known as utlemming | ||
| pitti | ogra_: ah, no further discussion here, any luck? | 22:05 |
| pitti | apw: binNEWed the kernel FYI | 22:08 |
| * pitti cleans up kernel NBS while he's at it | 22:09 | |
| apw | pitti: thanks :-) | 22:24 |
| ogra_ | pitti, all good, the binaries just landed in the archive | 22:27 |
| ogra_ | (well, still in proposed, but they shoould migrate soon) | 22:31 |
| nacc_ | rbasak: slangasek: fyi, it's Restrictions: build-needed (note need the s) | 22:49 |
| 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:08 |
| nacc_ | slangasek: ok, i'll update my debdiff for twig then ... and send a new debdiff for php-defaults? | 23:12 |
| === pepee- is now known as pepee | ||
| nacc_ | Pharaoh_Atem: am i right in reading the php builds that ZTS is off in debian/ubuntu? | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!