[00:11] 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] 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] 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 === juliank is now known as Guest41416 === juliank_ is now known as juliank === cody-somerville_ is now known as cody-somerville [03:46] pitti: hey... so you wrote a patch for systemd-shim "Clean up closing logind sessions". [03:47] it inserts a cgroup release agent (regardless of whether one was already defined) which, when a cgrou pis emptied, stops a session [03:47] 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] 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] pitti: would you boject to patching systemd-shim to not insert the release agent if one is already set? [03:49] (it's poor manners to do otherwise :) [03:56] or can i just get rid of that since in all real installs we expect to be using real systemd [03:57] hallyn: why not just move to systemd on the phone? [03:57] just let upstart die… for all of our sakes :) [04:04] Son_Goku: not in my power [04:04] :’( [04:04] I think it just has to do with some user jobs, i'm sure they'll be switching soon [04:05] :( [04:08] can you plea for them to move asap? [04:12] nah i'm gonna lobby for openrc. [04:12] i kid! [04:12] daemontools 4 life! [04:12] we have a bsd init job for cgmanager [04:13] (for slackware) [04:13] 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] but this point is not that point [04:20] hallyn: haha :) [04:21] all right, that fixes it. I'll sling a debdiff over to pitti after find some more kleenex to dry my tears [04:23] hm, no, i was wrong. drat. [04:25] meh, bad patch. [05:00] pitti: http://paste.ubuntu.com/15264990/ [05:02] ugh. minus the debug statements [05:03] pitti: maybe http://paste.ubuntu.com/15264999/ instead [05:03] hallyn: you may be the only person I know who debugs a string with strlen() :) [05:03] 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] sarnold: well i wanted to catch the length of a dbus reply for an empty string :) [05:04] :) [05:08] then again, now my vm has a corrupt fs. did my patch somehow contribute to that? [05:14] Pharaoh_Atem: last thought of the night (it's a good one) -- phpunit --process-isolation makes twig not segfault [05:14] Pharaoh_Atem: which i think means we have a php bug [05:15] that sounds ungood [05:15] huh Begin: Running /scripts/init-bottom ... Warning: overlayroot: debug is busted [05:15] hallyn: -that- sounds like a clear suggestion to EOD :) [05:22] i'm open to suggestions, i'll tkae that one [05:22] \o [05:46] good morning [06:33] 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] hallyn: http://paste.ubuntu.com/15264999/ LGTM [06:36] hallyn: ah, src/cgmanager.{h,c}, I thought that was some piece of standard code being copied around into various projects [06:36] hallyn: let's test this for a few days, then I'll apply it upstream and upload it to Debian too [06:36] hallyn: thanks! [06:45] pitti: cool, thanks. [06:46] 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] 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] i think conflicts [06:49] no, breaks sounds more accurate per the docs [06:51] hallyn: it should Breaks: (<< fixed_version) [06:52] kewl, pushing htat, and calling it a day - thx [06:53] Skuggen: the pastebin you showed to me yesterday? that looked reasonable, if you also replicated dh_systemd_*'s postrm and prerm code [06:53] 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] pitti: But the #DEBHELPER# code will also do the 'proper' starting of the service that should happen at the end [06:59] Skuggen: so you need to things *between* enable and start? OOI, what is that? [07:02] 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] And we added running mysql_upgrade as part of postinst instead of relying on users doing it manually [07:05] Skuggen: right, but can't that happen before the debhelper stuff? [07:05] i. e. [07:06] if [ "$1" = configure ] && have_older_db; then mysql_upgrade; fi [07:06] #DEBHELPER [07:06] 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] 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] Skuggen: *confused* I thought you said the service must *not* be running yet for upgrading? [07:19] so doing #DEBHELPER# first and then call mysql_upgrade? [07:19] Skuggen: I should probably purge my entire brain state about this and we'll start over :) [07:19] Hehe [07:20] I might be able to move all the upgrade-related stuff after #DEBHELPER#, with some reshuffling [07:20] (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] Skuggen: so I think the question is "do you need to anything *within* the #DEBHELPER# generated code" [07:23] 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] Hopefully not. I'll give it a try. Thanks for the help :) [07:45] good morning [07:50] pitti: thanks for agreeing that "changing" enviroment features for tests is a bad thing [07:50] pitti: I didn't realize that my first paragraph could have been so misleading until you repled on the RT ticket - thanks [07:51] 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] cpaelzer: I'm not convinced at all that we use -cpu host right now [07:52] cpaelzer: I've seen "SandyBridge" on all our clouds, on the semaphoreci.com clouds, etc. [07:52] it seems it's just a default -cpu SandyBridge in openstack [07:52] i. e. I think we are currently using that ^ [07:52] pitti: that is how I read kuhlmannt RT post [07:54] 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] 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] cpaelzer: *nod*, I yet have to see an x86 cloud instance which is something else [07:56] 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] pitti: waitnig for IS replies to your post now, thanks for testing your scalingstack instances [07:58] 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] cpaelzer: we have testinfo.json which has some info like the running kernel version, environment variables, etc. [07:59] we can certainly add stuff to that [07:59] e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/udisks2/20160301_213435@/result.tar [07:59] that contains testinfo.json [08:03] pitti: just parsed through it - interesting [08:03] 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] pitti: I could fetch my data by just manually constructing the link thou [08:03] pitti: any reason not to add that link there as well? [08:05] cpaelzer: I'd rather expand it into the debci log [08:06] we have three links there already, adding more isn't helping confusion [08:06] pitti: agreed [08:06] cpaelzer: indeed it's just replacing log.gz with result.tar in the URL [08:08] pitti: IMHO the dbci log could take a plain /proc/cpuinfo, on s390x maybe also /proc/sysinfo - that would be great [08:08] pitti: I also thought about lshw, but that is too heavyweight [08:09] cpaelzer: perhaps #processors and the model name [08:09] the full thing is quite big [08:09] pitti: processor, model and flags of one of them? [08:09] ok [08:09] cpaelzer: mind reporting a bug against autopkgtest about that, as a reminder? [08:09] I'll do [08:09] thanks [08:09] great [08:13] 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] pitti: I guess the answer is no [08:13] the answer to "who" is "no"? [08:13] pitti: but would it be possible to add e.g. a full sosreport into those tarballs AFTER failing tests? [08:13] cpaelzer: adt-run writes testinfo.json [08:14] cpaelzer: it could go into artifacts.tar.gz (certainly not into results.tar) [08:14] cpaelzer: but I don't want to do this by default really, as you don't need it for most tests [08:14] so if your test wants to depend on sosreport and use it, please feel free [08:15] pitti: ok, so if anybody wants it make it test specific - I'm absolutely ok with that - thanks [08:15] 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] pitti: Simply moving everything that needed a running server below #DEBHELPER# does the trick. Thanks! === willcooke_ is now known as willcooke [09:36] 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] That's about bug 1551351 for reference [09:36] bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351 [09:42] 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] pitti, there's all kinds of unsatisfiable depends, both on vivid (how ¿?) and xenial (proposed migration?) [09:42] much of unsatisfaction [09:42] they can get no... [09:43] satisfactioon [10:15] is there a way to see what autosynced from Debian between certain dates (2016-02-17 - end of auto sync period)? [10:19] Mirv, I don't think we have a list for those, but autosync stopped on the 18 iirc [10:20] yeah I know, something magic happened between the morning of 17th and 19th that breaks generation of top-level-domain data [10:20] but we're closing in anyway with oSoMoN [10:22] Mirv, how are those generated? [10:24] 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] 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] Mirv, oSoMoN, grep changed on the 17th and created issues for e.g ubiquity [10:25] thank you :) [10:25] * debian/rules: Build under C.UTF-8 locale. grep 2.23 causes broken debconf [10:25] templates to be built under the C locale. [10:25] mitya57: I see you committed set -e to qtbase, have you already found the grep error? [10:25] if it's that one [10:25] that's what pitti did to ubiquity ^ [10:25] seb128: ah, it sounds like my guess is the correct one <- oSoMoN [10:26] so, I'll prepare a real silo with C.UTF-8 set and start a build and go to lunch [10:26] Skuggen: cool! that's so much easier and robust [10:27] Mirv, https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1547466 [10:27] Launchpad bug 1547466 in grep (Ubuntu) "grep switches into binary mode while processing a text file" [High,New] [10:27] sorry that it has bitten you as well, seems like you spent several days trying to figure that out [10:27] Saviq: ah, I know -- looks like this is from xnox' recent component check [10:27] we should perhaps have reverted the grep update :-/ [10:27] xnox: ^ I think we need to disable the component checking if PPAs are involved [10:28] pitti, right, because ppas only have 'main' [10:28] pitti, but we don't run britney excuses against ppas... or do we?! [10:28] xnox: we do, silos do that [10:29] pitti, ok =) i'm so out of date. Do you want me to look into this? [10:29] xnox: I'll have a look, should be fairly simple [10:29] 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] xnox: I don't see how squid3 depends on squid [10:31] essentially calls to get_dependency_solvers should change component to MULTIVERSE and then things are ignored, "if PPA:" or some such. [10:31] or maybe we need a britney.conf feature flag for components missmatches. [10:31] 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] xnox: I think we should just disable the check if ADT_PPAS is set [10:32] seb128, heh... so it turned out to be a problem for other people, too. :) [10:32] smb, grep you mean? [10:32] xnox: change "if allowed_component(component, package[COMPONENT]):" to "if self.options.adt_ppas or allowed_component()" perhaps? [10:32] seb128, yep. [10:33] smb, yeah, Mirv and oSoMoN just spent several days investigating qt regressions [10:33] Mirv, and confirmed, running a local build with LANG=C LC_ALL=C generates a broken qurltlds_p.h [10:33] which turned out to be due to that [10:33] xnox: oh, nevermind, the squid3 binary in -proposed indeed has Pre-Depends: squid (>= 3.5.12-1ubuntu1) [10:33] rbasak: ^ please run check-mir on your squid merge [10:33] superm1, well, nevermind [10:34] 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] if there wasn’t one already, a unit test should be added to grep [10:34] rbasak: ah, unping [10:34] xnox: so for squid, apparently squid3 now builds a squid transitional package, so this is a case of component-mismatches [10:34] oSoMoN: thanks [10:35] apparently 'squid' is the new main package, and squid3 is a transitional [10:35] 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] xnox, rbasak: it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt , I promoted squid now [10:36] seb128, yeah -> more obscure problem. :) Guess I was kinda lucky that Xen failed to build then [10:36] is anyone looking at the grep issue? [10:37] I don'T think so (yet). I think I could not convince Brian it is broken [10:38] 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] pitti, squid3 package builds squid package in both release & proposed, and in both cases it's in universe. [10:38] xnox: right, so we caught the component-mismatches in britney [10:38] xnox: I just wasn't aware of the squid3 -> squid transition [10:38] so it seems all fine [10:38] pitti, right yes, i see that now. [10:39] xnox: http://paste.ubuntu.com/15265997/ should work, right? (no testsuite..) [10:39] Mirv, yeah, still it's a behaviour change and impacting our things with the current buildds setup [10:39] pitti, looks good! cowboy that in =) [10:39] seb128: yep [10:40] 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] pitti, thanks :) [10:48] 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] pitti: [squid] that's right, thanks for sorting it. [10:57] seb128, not like that sounds the discussion is going well... [10:57] yeah... [10:58] it would feel safer reverting the behaviour change for xenial [10:58] or we might end up wasting quite some more time chasing weird issues where we should focus on bugfixing for the lts [10:59] 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] I tend to agree. Even worse with that example of some backup tool silently failing... [11:01] who would the right person to do that call? foundations? [11:04] guess foundations but not sure which person... slangasek ? [11:10] 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] ok [11:41] 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] Laney, I won't have time to look at the tomahawk thing in the next days :-/ [11:50] dholbach: ok, well keep it on the queue then === _salem is now known as salem_ [11:52] LocutusOfBorg: sorry, what's wrong with ubuntukylin-meta? [11:54] and FWIW, we really ought to switch to C.UTF-8 by default on buildds and the like [11:54] tell me one good reason why one would still want 'C' in 2016 [12:01] pitti, https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html :) [12:33] 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] Saviq: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html is good again now [12:48] pitti, great, thanks [12:49] LocutusOfBorg: re (sorry, out for lunch); ok, I'll update the seeds now [12:53] LocutusOfBorg: ugh, it wasn't updated since wily [13:08] LocutusOfBorg: uploaded === directhex_ is now known as directhex [13:16] thanks! [13:28] I can't run sudo on schroots after updating to xenial, can someone confirm the same? [13:28] WFM [13:28] ok then :) [13:29] maybe schroot dir/overlay/mount dir has "nosuid" or so? [13:31] maybe, it's on /run/shm [13:32] tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) [13:32] yes, that can't work then [13:32] must've been changed [13:36] 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] Any tips, what I am doing wrong? [13:39] zequence, you there? hi [13:39] ubuntustudio-meta is the last blocker for fonts-android migration [13:42] 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] zequence, look e.g. lp: #1546847 [13:43] 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] and https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html [13:53] LocutusOfBorg: I can update that as well, while I'm at it [13:56] pitti, it would be awesome :) [13:56] just note: the fonts-noto is about 100MB, while droid fallback is 1MB [13:56] 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] cjwatson: is there some way to prevent the daily builder to use that option? [13:57] mardy_: No. [13:58] But IIRC there is a way to make that work at the source package level ... [13:58] cjwatson: I've found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377 [13:58] Debian bug 735377 in dpkg-dev "dpkg-source: 3.0 (native) silently ignores many binary files by default" [Normal,Open] [13:59] cjwatson: but it doesn't seem to work here, it looks like the -I given from the commandline is "stronger" [14:00] mardy_: Which source format? [14:00] cjwatson: actually, I've tried both 1.0 and 3.0 (native), and I'm getting the problem with both of them [14:01] mardy_: I think debian/source/options ought to be workable somehow, though possibly only for 3.0. [14:01] mardy_: Beyond that I probably can't help at the moment. [14:04] barry, your deja-dup patch makes some sense. But I have a counter-proposal. Working on it myself [14:04] barry, (my counter proposal just closes a couple issues with my original python-gi patch) [14:09] good morning! [14:09] hi cyphermox [14:09] mterry: cool, thanks [14:09] hey mdeslaur [14:10] 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] so sorry, I can't do this [14:10] cyphermox, wait until you catch up (about the good) ;) [14:10] LocutusOfBorg: you need someone from https://launchpad.net/~ubuntustudio-dev/+members [14:11] smb: ah? [14:11] LocutusOfBorg: perhaps you can do a MP? [14:12] 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] smb: I hate you! :) [14:12] :) [14:13] pitti I can bother Ross for this then [14:13] MP what is? [14:13] 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] or cjwatson ^^^ [14:13] smb: to fix dhclient for what? [14:13] cyphermox, to work again in xenial [14:14] bug #? [14:14] cyphermox, bug 1551351 [14:14] bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351 [14:16] * cyphermox reads and observes dhclient's behavior locally [14:16] cyphermox, tl;dr is that bind9.10 drops the export library in favour of a combined one which breaks dchlient [14:16] mmkay [14:16] well, I see that here it has renewed.. [14:17] LocutusOfBorg: not me [14:17] but I haven't checked if it's because NM did something to it, for instance [14:17] cyphermox, hm... could be ... the installs I looked on where server kind (ifupdown) [14:18] cyphermox, there is that discussion as reference https://lists.isc.org/pipermail/bind-users/2015-February/094640.html [14:18] yeah I'm reading that [14:18] I doubt using bundled sources (assuming there are still any) would help [14:19] well, that's not entirely true [14:19] I have no difficulty believe it would work; it's just not right unless there is no way to fix bind [14:20] .. or to fix isc-dhcp itself [14:21] cyphermox, i'd appreciate your thoughts on https://bugs.launchpad.net/curtin/+bug/1551937 . i tried to summarize in comment 7. [14:21] Launchpad bug 1551937 in curtin "lvm and multipath and xenial not happy together" [High,Confirmed] [14:21] 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] mkay [14:23] hi guys, quick policy question about a package that was in proposed but rejected [14:23] lets wait for zequence :) [14:23] 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] ahasenack: As far as the archive is concerned, it doesn't matter. [14:24] 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] 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] 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] ahasenack: *Personally* I would find it clearer to use a different version, but it's not a policy requirement to do so. [14:25] 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] ahasenack: It does. [14:25] ok, thx [14:25] 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] ahasenack: At least for the purpose of version checks. It still exists in the rejected queue, but duplicates are allowed there. [14:27] 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] or should I merge the entries into one? [14:27] ahasenack: Up to you. [14:27] ok [14:27] thx again [14:28] 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] smoser: it would be necessary to look also at the bindings file, and the output of multipath -ll from the initramfs [14:30] Mirv, I confirm that packages in silo 12 fix the regression in webbrowser-app’s unit tests [14:30] cyphermox, i put thebindings file there. [14:30] see comment 6 [14:30] Mirv, as far as I’m concerned, that silo is good to land (when armhf packages are done building of course) [14:32] 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] 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] oSoMoN: oh you found the silo, thanks! :) [14:32] (but you could tell me; yet comment 5 seems to point to the fact that there may have been) [14:33] 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] 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] cyphermox, the problem is that one expects spaces in its bindings file [14:34] and one does not [14:34] and as curtin i have to know that [14:34] and in an upgrade from trusty to xenial, the system is goign to be hosed [14:34] err, what? [14:35] 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] the wwid for the drives in that system have spaces in them. [14:36] and in xenial, multipath -r will write /etc/multipath/bindings with multiple consecutive spaces turned into a '_'. [14:36] in trusty, that file has to have the spaces. [14:37] if i upgrade from trusty to xenial, i'm going to have the spaces [14:37] and on reboot, i'm going to fail to find root [14:37] 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] so the postinst is going to edit that file ? [14:37] only your last statement is incorrect; the upgrade should be handled by multipath-tools [14:37] and anyone writing that file for both is just going to have to "know" this. [14:38] yes [14:38] that's the fun part is writing installers :) [14:38] *in [14:40] do you have a suggestion on how to know which behavior? [14:40] what do you mean? [14:41] what format for bindings and wwid is completely dependent on the release [14:41] it comes from which version of multipath-tools is in use [14:46] mterry: you rock, thanks [14:47] barry, how close are we now to a python2 free image? [14:48] 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] i can't currently do that. [14:49] as i dont have the modules [14:49] ah, multipath -r writes the bindings [14:50] you could modprobe them if it needs to do multipath stuff? [14:51] mterry: i think the only things left to deal with are system-config-printer-{common,gnome} [14:51] 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] mterry: those also pull in samba-libs [14:51] mterry: once we take those off, we can unseed `python` and then the rest should just fall off [14:55] barry: I thought system-config-printer-* was already converted to py3? [14:56] Son_Goku: it is, but they depend on samba-libs which transitively pulls in python2 :( [14:56] what?! [14:56] couldn’t you make like a samba-libs-nopython thingy? [14:56] Son_Goku: apparently it is not that simple [14:56] :’( [14:57] wait, why does system-config-printer need Samba [14:57] doesn’t it use IPP? [14:58] system-config-printer-common -> python3-smbc -> libsmbclient -> samba-libs [14:59] O.o [14:59] http://fedora.portingdb.xyz/pkg/system-config-printer/ [14:59] I don’t see python3-smbc [15:00] barry: where’s python3-smbc coming from? [15:01] Son_Goku: [15:01] % apt-cache show system-config-printer-common | grep -i depends [15:01] Depends: python3-cups (>= 1.9.60), python3-smbc, python3-dbus, python3-cupshelpers === pepee- is now known as pepee [15:06] bah, infinity is out today ? [15:06] ogra_: i believe so, yes [15:06] sad .. [15:07] cyphermox, well, maybe. i did result in trusty deploying lvm on top of multipath before knowing of this difference [15:09] so as for now, i'm quite blissful in my ignorance. [15:09] barry: I’m super confused about that [15:10] Son_Goku: any insight is appreciated [15:11] I know that python-smbc was required at one point [15:11] but according to the Fedora spec, it’s not required anymore [15:12] Son_Goku: python3-smbc, but i think you're saying that it might be an old dependency that can get dropped? === tvoss|lunch is now known as tvoss [15:12] ah, I see now [15:12] it’s an optional dependency [15:12] barry: http://pkgs.fedoraproject.org/cgit/rpms/system-config-printer.git/tree/system-config-printer.spec#n57 [15:12] It’s set as “Suggests” now [15:13] it is not required for the program to function [15:13] that’s as of system-config-printer 1.5.7 [15:14] 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] Son_Goku: it's worth a try, thanks [15:14] no problem [15:14] sorry, but my "usual uploaders" for dpdk seem to be currently all busy/on vacation [15:14] 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] 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:15] barry, Son_Goku, check with tkamppeter [15:15] barry: looks like you guys are on a snapshot release, so you should be able to successfully downgrade python3-smbc to Suggests [15:15] seb128: yes for sure, before i upload anything [15:16]