[00:02] nacc: well, I ruled out the upcoming pcre-8.38-7.fc23 update pending as a potential solution [00:02] I just checked it, and I still get the same backtrace [00:06] Pharaoh_Atem: thanks for doing that [00:07] Pharaoh_Atem: yeah, I think it's a *new* bug, but i'm not sure; I believe i at one point in a sbuild env, built upstream pcre directly from source and it also segfaulted [00:08] nacc: I figured that this is a new bug [00:08] but with how hairy libpcre is, you never know [00:26] so if i've got a fix, knowing we're past FF, for an actual bug (already filed), do i subscribe sponsors or release at this point? as i can't upload myself? [00:31] rbasak: can you update usd with logwatch 7.4.2 from debian/unstable? I'll merge and post the debdiff to get that sync'd [00:38] slangasek: php-imagick fixes (final ones) posted [00:38] that shoudl free up php7.0 and php-defaults [00:39] slangasek: i'll look at symfony and php-proxy-manager next, after i file a few non-php bugs :) [00:44] nacc: Bugfixes don't break Feature Freeze, the key word there is "feature". [00:45] infinity: yep, understood, just wasn't sure who to subscribe to the bug, exactly [00:45] infinity: from what you said, it sounds like i should still subscribe sponsors? [00:45] nacc: Same workflow as pre-FF, unless it needs an exception (which it doesn't sound like it does). [00:46] infinity: ok, thanks! [00:46] nacc: (ie: If you had upload rights, you should just be firing bugfixes at the archive without asking, without upload rights, find a sponsor, only bug the release team if you're breaking the freeze) [00:46] infinity: right, makes sense to me! [00:47] infinity: thanks again [01:26] hey. [01:26] so cloud-inti writes a bunch of systmed .service files. [01:26] in /lib/systemd/system/ [01:26] and i've moved those to /root/store (random directory, pretty sure systemd isn't looking there) [01:26] then rebooted [01:27] systemd-analyze dump [01:27] ^ that still knows about these jobs. [01:27] how ? [01:27] what do i have to do? i've told it 'systemctl daemon-reload' [01:27] which i wouldnt have thought mattered across a reboot [01:28] smoser: try systemctl list-unit-files ? [01:29] that doesnt show them. [01:30] ah [01:30] /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cloud-config.service [01:30] hm.. well then. [01:30] thank you deb-systemd-helper-enabled for being so... helpful [01:39] thanks sarnold [01:40] smoser: black magic is fun :( [01:41] and now, my friend 'Hash sum mismatch' has come to visit while i'im trying to sbuild. [01:41] thanks to you too [01:50] anyone have an idea on how i'd convince dh_systemd_enable to disable the jobs it previously enabled . [01:50] upgrade i no longer want them there. [02:05] well, filed bug. [02:05] https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1552999 [02:05] Launchpad bug 1552999 in init-system-helpers (Ubuntu) "dh_systemd_enable not able to disable on upgrade" [Undecided,New] [02:05] if anyone wants to add some help. please feel free. === robert_ancell_ is now known as robert_ancell === juliank_ is now known as juliank === pepee- is now known as pepee [05:19] pitti: the s390x karchive seem stuck forever at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src [05:34] Mirv: Retried. [05:37] infinity: Oh say, think those crazy archive admins would merge irssi? :P [05:38] Unit193: Not really the responsibility of archive admins to do merges. [05:39] No, but they'd approve or reject after FF. [05:39] FF not being Firefox. [05:39] Unit193: That would be the release team. And I'd probably allow it, if I had more info. [05:39] Unit193: Like, what's changed, do all the rdeps work with it, etc. [05:46] good morning [05:47] infinity: thank you [05:47] Good morning [05:47] good morning [05:49] New upstream release, always great to get the latest (when it's had quite a few bug fixes even more so) before something's to be supported for a few years. ;) [05:51] https://sigma.unit193.net/source/irssi_0.8.18-1ubuntu1.dsc looks like it, I believe. [05:59] Mirv: Looks like that did the trick, you're migrating. [06:16] superm1: thanks, so we still use wl; it appears that the brcmfmac firmware is reasonably free even? (it's in linux-firwmare) [06:17] nacc: right, apparently dpkg-source spits out some unexpected jitter on stdout; I'll see if I can reproduce this [06:18] Mirv: ah, some remaining fallout from yesterday's infra problems; next britney run will catch u [06:18] p [06:22] nacc: or just sign your .dsc to avoid the error :) [06:22] nacc: but indeed this should be filtered out [06:28] yes it did indeed migrate just minutes after infi_nity's restart [06:28] nacc: also, which runner is that? lxc? qemu? [06:30] nacc: can you please file a bug with the full log and invocation? I can't reproduce this even with an unsigned package, this must be something more subtle [06:46] nacc: ah, LXC runner? indeed I get something there, apparently still a regression with lxc-attach stream handling (~rc1 still works) [07:10] pitti: yes, it works pretty well overall too [07:20] robru, Mirv: FYI, we can now easily mass-retry failed or stuck "in progress" tests in silos; retry-autopkgtest-regressions --silo 050 --state RUNNING [07:20] so no need to fiddle around with request.cgi URLs if it happens for more than three or so packages [07:20] or no need to remove pending.json [07:21] pitti: how is "silo" determined? is that just a reference to the PPA name? [07:21] robru: it determines the landing-XXX bit in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-036/excuses.yaml [07:22] pitti: is it hardcoded to key off "landing-" specifically? I'm currently working on a total rewrite of how the train handles PPAs (creating them dynamically rather than allocatinng from a pool), and the new way is to have them simply numbered. can your script cope with this change? [07:22] robru: not right now, but it can be adjusted trivially [07:23] robru: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002 [07:23] pitti: ok, look for that in a month or two ;-) [07:23] robru: this was a quick hack to salvage landing 036 and 050 which fell victim to yesterday's infra work [07:23] and writing this 10-line patch was way faster (and more satisfying) than cobbling together the right commands manually :) [07:24] pitti: no worries, just be aware that "landing-%s" will eventually need to be just "%s" [07:24] robru: yep, and then we'll just update it in the script [07:24] robru: probably it'll become --ci-train then, and you are expected to specify the full name [07:24] cool [07:25] robru: I suppose we could alredy do this right now [07:25] robru: as long as the bit in the URL and the actual PPA name match [07:25] pitti: well if you do it now then everybody will have to type landing- all the time [07:25] pitti: yeah that's the plan [07:25] robru: well, we expect this to get run less than once a month, and I don't want many people to actually run it :) [07:26] pitti: heh, then I guess it doesn't matter [07:28] ./retry-autopkgtest-regressions --ci-train landing-050 --state RUNNING [07:28] pitti: looks good [07:28] robru: ^ ok, it's like that now; that shoudl be compatible with the future [07:28] perfet [07:28] perfect [07:28] http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002 [07:29] pitti: did you just --overwrite a publicly-pushed commit? naughty! [07:29] *shrug*, it was there for like 10 seconds [07:40] my kvm hosts have lost network for some reason, but only those that use dhcp [07:40] err guests [07:45] dunno if kicking the bridge around might break them, or if it's just the router dchp acting funny === dgadomski_ is now known as dgadomski [08:00] looks like the bridge doesn't work at all.. [08:19] pitti: I just noticed there is indeed such a script in my ubuntu-archive-tools folder :) [08:21] Mirv: right, you can run it, and it'll dutifully spit out the run-autopkgtest commands; but you can't run *those* [08:21] (as they need to be run on snakefruit) [08:21] ah [08:21] r-a-r just downloads excuses.yaml and generates commands on stdout, it's harmless [09:12] nacc: logwatch> done, I think. [09:19] nacc: workaround to unblock you: adt-run -l /dev/null; I filed this a bug 1553097 [09:19] bug 1553097 in lxc (Ubuntu) "latest LXC breaks autopkgtest's LXC runner" [Undecided,New] https://launchpad.net/bugs/1553097 [09:31] nacc: ok, got it, iz lxc bug; so use that workaround, or the lxd runner, or downgrade lxc [09:40] is xorg 1.18 in 16.04 rootless? [09:42] tseliot: ah, ubuntu-drivers-common tests fail now because they test fglrx; I'll change them to something else, like wl or nvidia [09:42] tseliot: however, there's also a lot of fglrx code i gpu-manager which should be dropped; can you please do that, as you are much more familiar with that? [09:43] tjaalton, ^^^ [09:44] pitti, tseliot, is there anything replacing fglrx? or opensource drivers better now and doing everything the ati ones were doing? [09:44] LocutusOfBorg: rootless? [09:44] * seb128 just curious [09:44] LocutusOfBorg: it's supported, needs *dm support (lightdm doesn't have it) [09:45] seb128: I was asked to remove fglrx yesterday, as it doesn't get updates any more and doesn't work with the new X.org ABI; and allegedly the FOSS drivers are now good enough [09:45] yes [09:45] good enough or as good? [09:45] define "as good" [09:46] foss stack is much better in some areas [09:46] so tjaalton this change has no effect on ubuntu? https://packages.qa.debian.org/x/xorg-server/news/20150821T010032Z.html [09:46] dunno, start a good recent games and get as many fps [09:46] there will be a GL blob for that [09:46] power management is an important point too [09:46] I mean the xorg-legacy package [09:46] yeah tseliot is backporting a lot for amdgpu kernel driver, including power management.. will be in 4.4.0-11 or such [09:46] k, so there still are going to be binary parts shipped by amd? [09:46] at some point [09:47] LocutusOfBorg: no, nvidia does pull it in though, so once lightdm does support rootless, nvidia would still work [09:47] or gdm [09:48] seb128: amdgpu performance is quite close to fglrx though [09:48] cool [09:48] and mesa 11.2 has a FFE [09:48] tjaalton, I guess we should have something in the 16.04 notes [09:48] so I guess we'll be in a good position with 16.04, just have to be a bit aggressive.. [09:48] and maybe an email on ubuntu-devel [09:49] yeah [09:49] because usersa re going to wonder where is their fglrx drivers [09:49] even if they don't need it, if we don't explain why it's missing it's going to create confusion [09:49] sure [09:50] the transition is still blocked by two MIR's [09:50] new deps on s390x & arm [09:50] (drivers) [09:50] hmm or was it the virtualbox tests, xorg meta package is probably separate [09:52] tjaalton, dunno, I'd be somewhat surprised to find s390x blocking something graphical... [09:52] pitti, fyi bug 1553110 [09:52] bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 [09:52] infinity, ^^^ you might be interested [09:52] smb: it's the addition of xserver-xorg-input-void to x-x-input-all on s390x [09:52] ogra_: wow [09:53] tjaalton, ah ok. yeah "void" describes the graphical experience there... [09:53] tseliot: autopkgtest fix pushed, but I don't upload yet as the cleanup should be done too [09:53] another option is to just drop it, but arm probably still wants -freedreno in main [09:55] tsdgeos: xserver-xorg-input-mouse [09:55] erk [09:55] tsdgeos: sorry, wrong ping [09:55] tjaalton: xserver-xorg-input-mouse [09:55] can be removed [09:55] tjaalton: ... wants to go to universe, can you confirm? [09:55] replaced by -evdev I suppose [09:56] like others on https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1541369 [09:56] Launchpad bug 1541369 in xserver-xorg-video-s3 (Ubuntu) "remove stale xorg drivers from the archive" [Wishlist,New] [09:56] tjaalton: ah, thanks; will do now [09:56] tjaalton: will they be removed in debian too, or is that ubuntu specific somehow? [09:56] vmmouse used to depend on -mouse, but that dep was actually removed upstream six years ago [09:56] gone from debian already [09:57] not mouse, since it had the dependency not too long ago [09:57] yeah we've used -evdev for years, and next up will be -libinput [09:57] -keyboard is also still in debian [09:57] hmm [09:57] I'll check [09:58] because they have kfreebsd [09:58] actually mouse for the same reason [09:59] but we don't have !linux [09:59] ah [09:59] *zap* [10:00] pitti: define clean-up please? [10:00] tseliot: git grep fglrx [10:01] seb128: do we have a draft of the release notes? If so, I can write a few lines about it [10:01] tseliot, tjaalton: actually, what happens on upgrades of systems that have fglrx currently installed? does ubuntu-drivers set an xorg.conf which forces the driver, or does it just configure it and retains auto-detection? [10:01] good point [10:01] gpu-manager does quite a bit on such systems (I have no idea what exactly, though) [10:02] tseliot, I don't know, I would expect that be a section on the wiki that is updated during the cycle ... let me find it [10:02] pitti: when users upgrade to the new X, fglrx will be removed, gpu-manager will detect that, and remove the xorg.conf [10:02] oh [10:02] ah, good [10:02] tseliot: so I suppose some gpu-manager code for fglrx will still be necessary, just not all of it (the setup part) [10:03] thanks tjaalton [10:03] pitti: yes, I'd rather not remove that code yet, as it would make backports to previous Ubuntu releases harder than they need to be [10:04] tseliot: ah, ok; then I guess I should keep the fglrx support in UbuntuDrivers/detect.py as well for the time being [10:04] tseliot: good, then I'll upload this to fix the tests [10:04] tseliot: unless you still have something? [10:06] pitti: yes, please, let's keep the code there for now. I have nothing to upload ATM [10:06] apw: OOI, what happened to the seeding of the linux-meta packages? [10:06] pitti: BTW, if you could approve my nvidia packages in Xenial NEW, that would be very welcome ;) [10:07] tseliot, I don't find a wikipage :-/ [10:08] Laney, do you know if there is already a wikipage somewhere for release notes? [10:08] I though we had one through the cycle [10:08] adding infos during alpha/beta/etc [10:08] but I can't find it [10:09] pitti, i thought we were making that use a * thing, and i actually thought you'd already done it:) [10:09] seb128: not one that I know of - probably one will be created for Beta 2 though [10:09] tseliot, ^ I guess need to wait a bit then [10:09] Laney, thanks [10:09] apw: no, I understood it like you were going to double-check and update the seeds, but they are still on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; misunderstanding? [10:09] seb128: IIRC the ubuntu-release-notes project is for this [10:10] or someone could start the page I suppose [10:10] seb128: ok, I'll be waiting for that then [10:10] XenialXerus/ReleaseNotes [10:10] tseliot, or create the page [10:10] tseliot: no nvidia stuff in https://launchpad.net/ubuntu/xenial/+queue?queue_state=0 [10:11] tseliot: I would create it now so that nobody forgets [10:12] tseliot: nevermind, saw it now, scrolled off [10:14] Laney, seb128: err... https://wiki.ubuntu.com/XenialXerus/ReleaseNotes [10:15] tseliot, yeah, I think that Laney was just hitting the url and suggesting creating it [10:15] no need for me to create it then :) [10:16] ? [10:16] it doesn't exist yet [10:16] cit does [10:16] just still for wily [10:17] tseliot: I just made it [10:18] you can go fill in your section now [10:18] Laney: yep, thanks === marcusto_ is now known as marcustomlinson\ === marcustomlinson\ is now known as marcustomlinson [10:27] Mirv, I’m looking into bug #1342031 (for webbrowser-app), and I have a doc package named qtdeclarative5-ubuntu-web-plugin-doc, should that one be renamed too, and if so do I add a transitional dummy package? [10:27] bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Medium,Triaged] https://launchpad.net/bugs/1342031 [10:30] pitti: thanks a lot! [10:44] Mirv, note that qtdeclarative5-ubuntu-web-plugin-doc doesn’t have any rdepends, it looks safe to not make a transitional dummy package for it [10:44] oSoMoN: yes to both [10:44] Mirv, even considering the above? [10:44] oSoMoN: still, for people who have it currently installed to get the new one [10:44] ok, got it [10:45] oSoMoN: and thanks for the MIR, looks good! [10:45] Mirv, what section does the -doc dummy package belong to? doc, or oldlibs? [10:47] oSoMoN: that's an excellent question, I think I've seen that used, maybe because there is no other "old*" section. anyone on the channel with better knowledge please enlighten. [10:49] Mirv, according to https://wiki.debian.org/Renaming_a_Package, setting the section to oldlibs allows tools like deborphan to suggest removal of the package once there aren't any more reverse-dependencies installed [10:58] oSoMoN: right, the only thing I haven't seen explicitly said is "please use oldlibs section for all transitional packages", but I indeed have thought that is the case [10:59] oSoMoN: thanks for starting that btw, we can get rid of more old names and transitional packages in 2 months then [10:59] since there is upgrade path for 14.04 LTS -> 16.04 LTS upgraders [11:00] Mirv, yeah, it had been on my backlog for a long time, I thought it’d be good to get it done in time for 16.04 [11:07] seb128, Laney: ok, I've added a few lines about fglrx in the release notes [11:08] tseliot, looks good, thanks! [11:42] barry, hey - just tripped over an interesting niggle - pip includes a vendored pkg_resources (v19.4) which behaves a little differently to the pkg-resources in packages (20.1.1) [11:43] barry, https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/unit/meter/test_notifications.py#L274 works ok with 19.4, but not with 20.1.1 (always uses the full, not relative paths...) [11:43] anyway I patched into ceilometer... [11:43] I guess that would need to happen in pip itself otherwise xenial will have different pip to the rest of the world.... [11:50] Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 === _salem is now known as salem_ [14:11] jamespage: pip isn't supposed to contain any vendored packages. we strip out the _vendor directory [14:12] barry, hmm where is that coming from then [14:13] * jamespage looks some more [14:13] barry, oh its quite possible that when tox creates the venvs, it installs pip from pypi which brings that in [14:13] * jamespage checks... [14:13] jamespage: also, just syncpackaged new version of pip to xenial. shouldn't change this bit of it, but just fyi [14:14] jamespage: oh yeah, it'll do that if you don't tell tox otherwise! [14:14] barry, my god this is confusing.,.. [14:14] barry, I think that's what it is [14:15] jamespage: you can set sitepackages=True and install the debs. also, i think there are ways to tell tox never to download from pypi. check the docs (something like setting the indexserver to the discard port on localhost) [14:15] (that'll likely error out if you don't have a distro package installed) [14:15] barry, indeed [15:08] barry, you are assuming i understood the structure i was dereferencing..... i tried combos until it worked ;-) [15:08] * xnox <3 TDD [15:08] xnox: tried and true method :) [15:12] xnox, any idea about bug #1552914 ? [15:12] bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,New] https://launchpad.net/bugs/1552914 [15:15] Saviq, yes, doko broke things =) [15:15] Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 updated [15:15] xnox, half a year ago and noone noticed? ;) [15:16] Saviq, i was not working on ubuntu half a year ago.... [15:16] xnox, but you were working on it since! ;D [15:16] canfix? ;) [15:17] pitti: ree bug 814115 - thanks! it would really help for debugging failures [15:17] bug 814115 in OpenQuake (deprecated) "Celery worker fails to send result message" [Critical,Fix released] https://launchpad.net/bugs/814115 [15:17] debian bug 814115 [15:17] Debian bug 814115 in autopkgtest "autopkgtest: $ADTTMP does not survive until --shell-fail/-s" [Normal,Open] http://bugs.debian.org/814115 [15:17] barry: yep, looking into it now [15:17] \o/ [15:18] stgraber: what's the word on indicator-datetime pulling in obsolete deps? [15:30] barry: ok, got it :) [15:32] pitti: awesome! [15:37] pitti: no response from the merge proposal, I think I'll just upload it and they'll deal with merging things later [15:56] hey. [15:58] rbasak: thanks! wil merge today [15:58] pitti: thanks! [16:00] i have a stupid question. [16:01] file in debian/ gets installed by dh_install. debian/open-iscsi.install [16:03] what is the right way to ensure its installed executable ? [16:04] Make sure it is executable to start off with? [16:04] is that right ? [16:04] You can chmod it in d/rules if needed. [16:04] (usually only if upstream have it wrong) [16:04] well its debian/ [16:04] so , its ours [16:04] Ah. Is it a "3.0 (quilt)" source package? [16:04] no. its a file in debian/ [16:05] debian/iscsi-network-interface.rules => /lib/udev/rules.d/70-iscsi-network-interface.rules [16:05] What does debian/source/format say? [16:05] quilt 3.0. but its dh_install from ^ [16:05] Then you can mark it executable in the source package. [16:05] And it should end up executable on the installed system. [16:05] yeah. that just felt brittle [16:05] smoser: does it not automatically? i'm reading the debian manual about it ... it probably doesn't hurt to mark it executable in the source [16:06] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install [16:06] it does not do it automatically. [16:06] ok [16:06] smoser, debian.rules files should not be executable. [16:06] smoser, sorry, .rules files under debian. [16:06] If you're concerned about things not working otherwise then it's fine to override_dh_install [16:06] xnox, its not that style of rules. [16:06] it's a udev rule, right? [16:06] yeah. its a udev rule [16:07] namespace collision :) [16:07] smoser, i think then you want to e.g. [16:07] override_dh_installudev: [16:07] smoser: it seems "better" to override dh_install, but i'm not sure [16:07] dh_installudev [16:08] chmod +x debian/$pkg/lib/udev/rules.d/*.rules # or some such [16:08] smoser: rather than assuing te permissions in the tarball are maintained, etc [16:08] I prefer to keep the permission in one place and think the source package chmod is fine. That keeps d/rules smaller, which I prefer. [16:08] heh [16:08] nacc, i think dh_installudev will strip the permissions anyway, and/or dh_fixperms thing. [16:08] But no harm in doing it explicitly in the rules file. [16:09] smoser, if dh_fixperms "reverts" the chmod+x you'll need to override that too, with e.g. dh_fixperms -X [16:09] xnox: yeah, that's what I guess I meant ... not sure what the other commands do to the file during install [16:09] If dh_fixperms reverts it, then maybe worth looking into why you need it that way? [16:09] also fair :) [16:09] BTW, while we're asking this sort of question... [16:10] smoser, usually people place "binaries" into /lib/udev and just rules in the rules.d directory.... [16:10] I didn't think udev.rules needed to be exec [16:10] smoser, but i know that you are not a "usual" person. [16:10] bah [16:10] sorry [16:10] fail [16:10] none of them are exec on my system, at least [16:10] debian/net-interface-handler /lib/open-iscsi [16:10] that one is the file [16:10] ah [16:11] I'd like to use dh_install --fail-missing to manage a complex package (mysql). But then how do I maintain a list of excludes? With -X, or is there a better way for a larger list? [16:11] And, why is dh_install --fail-missing complaining about manpages installed using dh_installman and specified in a .manpages file, and is it right to have to exclude those specifically or is there something else that should be going on? [16:12] dh_install doesn't have a built-in way to maintain more excludes, but you could always generate the options using shell command substitution. [16:12] cjwatson: that's a good idea. I just wanted to check that there wasn't some better way I was missing. Thanks! [16:19] rbasak: is that dh_install complaining or dh_installman [16:21] rbasak, so http://paste.ubuntu.com/15281670/ look ok ? [16:21] i also chmod 755 on the file, but that does not show up in debdiff (which is kind of why i find it brittle) [16:23] nacc: dh_install complaining using --fail-missing about manpages installed by dh_installman (not sure what order but the dh sequencer order) [16:23] smoser: IMHO, it's debdiffs that are brittle! [16:23] git manages it fine. [16:23] well, yes. [16:24] $(CURDIR)/ is a little redundant but I guess that pattern comes from Debian and you didn't want to deviate? Assuming that works, it looks fine. [16:24] yeah, the ones above use CURDIR [16:25] s/needs to be/is/ if you like. [16:25] And if you want me to be really pedantic, you're adding an unnecessary blank line in line 24 :-P [16:25] cyphermox, http://paste.ubuntu.com/15281670/ [16:25] indeed i am. [16:25] rbasak: hrm, that seems odd ... does that mean you're specifying the manpage to be installed then? (I don't know what the dh_install line looks like) [16:25] i will dlean that. [16:27] nacc: https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/tree/debian/mysql-server-5.7.manpages?h=5.7v3_pre2 is what dh_installman picks up [16:27] nacc: but then dh_install --fail-missing (if we switch to that in d/rules) complains about all those manpages again. [16:27] (I'm told) [16:30] rbasak: hrm, interesting -- that doesn't seem like it should be on my reading ofthe manapges, but you certainly know more than I do :) [16:31] nacc: I only know as much as the manpages :) [16:31] Thanks for looking. I could file a bug at some point I guess. [16:34] rbasak: :) it seems like it might be an ordering thing, but it's hard to say, and given you do have a workaroudn presuming it's an issue [16:49] nacc: yeah we can just use dh_install --fail-missing -X ... [17:00] cjwatson, rbasak: I think modern debhelper versions can read list of excluded files from debian/not-installed [17:00] ≥ 9.20151004 according to the changelog [17:00] (never tried that myself) [17:00] mitya57: ah, neat! Thanks. Any idea where that is documented? Google doesn't find anything. [17:01] It's documented in dh_install(1) here [17:01] Thanks again! [17:02] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240 [17:02] Debian bug 436240 in debhelper "debhelper: exclude file for dh_install --list-missing" [Wishlist,Fixed] [17:02] Yw! [17:02] http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_install.1.html has it [17:02] Skuggen: ^^ [17:02] in moinmoin how do i type CamelCase word without it generating a link to CamelCase page? [17:02] rbasak: and seems to be referring to exactly your issue in one of the comments :) [17:03] Ah, nice [17:04] xnox, try an exclamation sign, i.e. !CamelCase [17:04] mitya57, thanks! [17:06] that was from https://moinmo.in/HelpOnLinking#Preventing_Automatically_Generated_Links [17:09] mitya57: So it does! Not sure how I missed that. [17:12] seb128, hello! Is a11y-profile-manager a package the desktop team is OK with owning / subscribing to? (in the context of MIR bug 1552507) [17:12] bug 1552507 in a11y-profile-manager (Ubuntu) "[MIR/FFE] Promoting a11y-profile-manager to main." [Undecided,Incomplete] https://launchpad.net/bugs/1552507 [18:27] ogra_: Commented. [18:27] infinity, i'm batteling other issues too here ... [18:28] OOOH ! [18:28] lol [18:28] infinity, my other issue is that despite linbudev being in that ldd output, i dont end up with it inside the initrd [18:29] ogra_: Curious. Is that also unique to running under fakechroot? [18:29] definitely, since normal built initrds used to work [18:29] * infinity nods. [18:30] other hooks all get their libs just fine too [18:33] ogra_: Of course, you say that copy_exec fail because of the ld.so issue. It's possibly it's aborting before getting to libudev. [18:33] s/fail/fails/ [18:33] well, my outer build script now has a mkdir /lib64 and i copy the linker there [18:33] Oh. Gross. ;) [18:33] so mkinitramfs moves on without error [18:33] Right. Hrm. [18:34] yeah ... i have worse hacks in the making currently though :P [18:34] If you didn't, it wouldn't be you. [18:34]