[00:02] <Pharaoh_Atem> nacc: well, I ruled out the upcoming pcre-8.38-7.fc23 update pending as a potential solution
[00:02] <Pharaoh_Atem> I just checked it, and I still get the same backtrace
[00:06] <nacc> Pharaoh_Atem: thanks for doing that
[00:07] <nacc> 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] <Pharaoh_Atem> nacc: I figured that this is a new bug
[00:08] <Pharaoh_Atem> but with how hairy libpcre is, you never know
[00:26] <nacc> 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] <nacc> 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] <nacc> slangasek: php-imagick fixes (final ones) posted
[00:38] <nacc> that shoudl free up php7.0 and php-defaults
[00:39] <nacc> slangasek: i'll look at symfony and php-proxy-manager next, after i file a few non-php bugs :)
[00:44] <infinity> nacc: Bugfixes don't break Feature Freeze, the key word there is "feature".
[00:45] <nacc> infinity: yep, understood, just wasn't sure who to subscribe to the bug, exactly
[00:45] <nacc> infinity: from what you said, it sounds like i should still subscribe sponsors?
[00:45] <infinity> nacc: Same workflow as pre-FF, unless it needs an exception (which it doesn't sound like it does).
[00:46] <nacc> infinity: ok, thanks!
[00:46] <infinity> 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] <nacc> infinity: right, makes sense to me!
[00:47] <nacc> infinity: thanks again
[01:26] <smoser> hey.
[01:26] <smoser> so cloud-inti writes a bunch of systmed .service files.
[01:26] <smoser> in /lib/systemd/system/
[01:26] <smoser> and i've moved those to /root/store (random directory, pretty sure systemd isn't looking there)
[01:26] <smoser> then rebooted
[01:27] <smoser> systemd-analyze dump
[01:27] <smoser> ^ that still knows about these jobs.
[01:27] <smoser> how ?
[01:27] <smoser> what do i have to do? i've told it 'systemctl daemon-reload'
[01:27] <smoser> which i wouldnt have thought mattered across a reboot
[01:28] <sarnold> smoser: try systemctl list-unit-files ?
[01:29] <smoser> that doesnt show them.
[01:30] <smoser> ah
[01:30] <smoser> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cloud-config.service
[01:30] <smoser> hm.. well then.
[01:30] <smoser> thank you deb-systemd-helper-enabled for being so... helpful
[01:39] <smoser> thanks sarnold
[01:40] <Pharaoh_Atem> smoser: black magic is fun :(
[01:41] <smoser> and now, my friend 'Hash sum mismatch' has come to visit while i'im trying to sbuild.
[01:41] <smoser> thanks to you too
[01:50] <smoser> anyone have an idea on how i'd convince dh_systemd_enable to disable the jobs it previously enabled .
[01:50] <smoser> upgrade i no longer want them there.
[02:05] <smoser> well, filed bug.
[02:05] <smoser> https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1552999
[02:05] <smoser> if anyone wants to add some help. please feel free.
[05:19] <Mirv> pitti: the s390x karchive seem stuck forever at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
[05:34] <infinity> Mirv: Retried.
[05:37] <Unit193> infinity: Oh say, think those crazy archive admins would merge irssi? :P
[05:38] <infinity> Unit193: Not really the responsibility of archive admins to do merges.
[05:39] <Unit193> No, but they'd approve or reject after FF.
[05:39] <Unit193> FF not being Firefox.
[05:39] <infinity> Unit193: That would be the release team.  And I'd probably allow it, if I had more info.
[05:39] <infinity> Unit193: Like, what's changed, do all the rdeps work with it, etc.
[05:46] <cpaelzer> good morning
[05:47] <Mirv> infinity: thank you
[05:47] <pitti> Good morning
[05:47] <Mirv> good morning
[05:49] <Unit193> 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] <Unit193> https://sigma.unit193.net/source/irssi_0.8.18-1ubuntu1.dsc looks like it, I believe.
[05:59] <infinity> Mirv: Looks like that did the trick, you're migrating.
[06:16] <pitti> superm1: thanks, so we still use wl; it appears that the brcmfmac firmware is reasonably free even? (it's in linux-firwmare)
[06:17] <pitti> nacc: right, apparently dpkg-source spits out some unexpected jitter on stdout; I'll see if I can reproduce this
[06:18] <pitti> Mirv: ah, some remaining fallout from yesterday's infra problems; next britney run will catch u
[06:18] <pitti> p
[06:22] <pitti> nacc: or just sign your .dsc to avoid the error :)
[06:22] <pitti> nacc: but indeed this should be filtered out
[06:28] <Mirv> yes it did indeed migrate just minutes after infi_nity's restart
[06:28] <pitti> nacc: also, which runner is that? lxc? qemu?
[06:30] <pitti> 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] <pitti> nacc: ah, LXC runner? indeed I get something there, apparently still a regression with lxc-attach stream handling (~rc1 still works)
[07:10] <superm1> pitti: yes, it works pretty well overall too
[07:20] <pitti> 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] <pitti> so no need to fiddle around with request.cgi URLs if it happens for more than three or so packages
[07:20] <pitti> or no need to remove pending.json
[07:21] <robru> pitti: how is "silo" determined? is that just a reference to the PPA name?
[07:21] <pitti> robru: it determines the landing-XXX bit in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-036/excuses.yaml
[07:22] <robru> 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] <pitti> robru: not right now, but it can be adjusted trivially
[07:23] <pitti> robru: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002
[07:23] <robru> pitti: ok, look for that in a month or two ;-)
[07:23] <pitti> robru: this was a quick hack to salvage landing 036 and 050 which fell victim to yesterday's infra work
[07:23] <pitti> and writing this 10-line patch was way faster (and more satisfying) than cobbling together the right commands manually :)
[07:24] <robru> pitti: no worries, just be aware that "landing-%s" will eventually need to be just "%s"
[07:24] <pitti> robru: yep, and then we'll just update it in the script
[07:24] <pitti> robru: probably it'll become --ci-train then, and you are expected to specify the full name
[07:24] <robru> cool
[07:25] <pitti> robru: I suppose we could alredy do this right now
[07:25] <pitti> robru: as long as the bit in the URL and the actual PPA name match
[07:25] <robru> pitti: well if you do it now then everybody will have to type landing- all the time
[07:25] <robru> pitti: yeah that's the plan
[07:25] <pitti> 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] <robru> pitti: heh, then I guess it doesn't matter
[07:28] <pitti> ./retry-autopkgtest-regressions  --ci-train landing-050 --state RUNNING
[07:28] <robru> pitti: looks good
[07:28] <pitti> robru: ^ ok, it's like that now; that shoudl be compatible with the future
[07:28] <robru> perfet
[07:28] <robru> perfect
[07:28] <pitti> http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1002
[07:29] <robru> pitti: did you just --overwrite a publicly-pushed commit? naughty!
[07:29] <pitti> *shrug*, it was there for like 10 seconds
[07:40] <tjaalton> my kvm hosts have lost network for some reason, but only those that use dhcp
[07:40] <tjaalton> err guests
[07:45] <tjaalton> dunno if kicking the bridge around might break them, or if it's just the router dchp acting funny
[08:00] <tjaalton> looks like the bridge doesn't work at all..
[08:19] <Mirv> pitti: I just noticed there is indeed such a script in my ubuntu-archive-tools folder :)
[08:21] <pitti> Mirv: right, you can run it, and it'll dutifully spit out the run-autopkgtest commands; but you can't run *those*
[08:21] <pitti> (as they need to be run on snakefruit)
[08:21] <Mirv> ah
[08:21] <pitti> r-a-r just downloads excuses.yaml and generates commands on stdout, it's harmless
[09:12] <rbasak> nacc: logwatch> done, I think.
[09:19] <pitti> nacc: workaround to unblock you: adt-run -l /dev/null; I filed this a bug 1553097
[09:31] <pitti> nacc: ok, got it, iz lxc bug; so use that workaround, or the lxd runner, or downgrade lxc
[09:40] <LocutusOfBorg> is xorg 1.18 in 16.04 rootless?
[09:42] <pitti> 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] <pitti> 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] <LocutusOfBorg> tjaalton, ^^^
[09:44] <seb128> pitti, tseliot, is there anything replacing fglrx? or opensource drivers better now and doing everything the ati ones were doing?
[09:44] <tjaalton> LocutusOfBorg: rootless?
[09:44]  * seb128 just curious
[09:44] <tjaalton> LocutusOfBorg: it's supported, needs *dm support (lightdm doesn't have it)
[09:45] <pitti> 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] <tjaalton> yes
[09:45] <seb128> good enough or as good?
[09:45] <tjaalton> define "as good"
[09:46] <tjaalton> foss stack is much better in some areas
[09:46] <LocutusOfBorg> so tjaalton this change has no effect on ubuntu? https://packages.qa.debian.org/x/xorg-server/news/20150821T010032Z.html
[09:46] <seb128> dunno, start a good recent games and get as many fps
[09:46] <tjaalton> there will be a GL blob for that
[09:46] <pitti> power management is an important point too
[09:46] <LocutusOfBorg> I mean the xorg-legacy package
[09:46] <tjaalton> yeah tseliot is backporting a lot for amdgpu kernel driver, including power management.. will be in 4.4.0-11 or such
[09:46] <seb128> k, so there still are going to be binary parts shipped by amd?
[09:46] <tjaalton> at some point
[09:47] <tjaalton> LocutusOfBorg: no, nvidia does pull it in though, so once lightdm does support rootless, nvidia would still work
[09:47] <tjaalton> or gdm
[09:48] <tjaalton> seb128: amdgpu performance is quite close to fglrx though
[09:48] <seb128> cool
[09:48] <tjaalton> and mesa 11.2 has a FFE
[09:48] <seb128> tjaalton, I guess we should have something in the 16.04 notes
[09:48] <tjaalton> so I guess we'll be in a good position with 16.04, just have to be a bit aggressive..
[09:48] <seb128> and maybe an email on ubuntu-devel
[09:49] <tjaalton> yeah
[09:49] <seb128> because usersa re going to wonder where is their fglrx drivers
[09:49] <seb128> even if they don't need it, if we don't explain why it's missing it's going to create confusion
[09:49] <tjaalton> sure
[09:50] <tjaalton> the transition is still blocked by two MIR's
[09:50] <tjaalton> new deps on s390x & arm
[09:50] <tjaalton> (drivers)
[09:50] <tjaalton> hmm or was it the virtualbox tests, xorg meta package is probably separate
[09:52] <smb> tjaalton, dunno, I'd be somewhat surprised to find s390x blocking something graphical...
[09:52] <ogra_> pitti, fyi bug 1553110
[09:52] <ogra_> infinity, ^^^ you might be interested
[09:52] <tjaalton> smb: it's the addition of xserver-xorg-input-void to x-x-input-all on s390x
[09:52] <pitti> ogra_: wow
[09:53] <smb> tjaalton, ah ok. yeah "void" describes the graphical experience there...
[09:53] <pitti> tseliot: autopkgtest fix pushed, but I don't upload yet as the cleanup should be done too
[09:53] <tjaalton> another option is to just drop it, but arm probably still wants -freedreno in main
[09:55] <pitti> tsdgeos: xserver-xorg-input-mouse
[09:55] <pitti> erk
[09:55] <pitti> tsdgeos: sorry, wrong ping
[09:55] <pitti> tjaalton: xserver-xorg-input-mouse
[09:55] <tjaalton> can be removed
[09:55] <pitti> tjaalton: ... wants to go to universe, can you confirm?
[09:55] <pitti> replaced by -evdev I suppose
[09:56] <tjaalton> like others on https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1541369
[09:56] <pitti> tjaalton: ah, thanks; will do now
[09:56] <pitti> tjaalton: will they be removed in debian too, or is that ubuntu specific somehow?
[09:56] <tjaalton> vmmouse used to depend on -mouse, but that dep was actually removed upstream six years ago
[09:56] <tjaalton> gone from debian already
[09:57] <tjaalton> not mouse, since it had the dependency not too long ago
[09:57] <tjaalton> yeah we've used -evdev for years, and next up will be -libinput
[09:57] <pitti> -keyboard is also still in debian
[09:57] <tjaalton> hmm
[09:57] <tjaalton> I'll check
[09:58] <tjaalton> because they have kfreebsd
[09:58] <tjaalton> actually mouse for the same reason
[09:59] <tjaalton> but we don't have !linux
[09:59] <pitti> ah
[09:59] <pitti> *zap*
[10:00] <tseliot> pitti: define clean-up please?
[10:00] <pitti> tseliot: git grep fglrx
[10:01] <tseliot> seb128: do we have a draft of the release notes? If so, I can write a few lines about it
[10:01] <pitti> 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] <tjaalton> good point
[10:01] <pitti> gpu-manager does quite a bit on such systems (I have no idea what exactly, though)
[10:02] <seb128> 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] <tseliot> pitti: when users upgrade to the new X, fglrx will be removed, gpu-manager will detect that, and remove the xorg.conf
[10:02] <tjaalton> oh
[10:02] <pitti> ah, good
[10:02] <pitti> tseliot: so I suppose some gpu-manager code for fglrx will still be necessary, just not all of it (the setup part)
[10:03] <LocutusOfBorg> thanks tjaalton
[10:03] <tseliot> 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] <pitti> tseliot: ah, ok; then I guess I should keep the fglrx support in UbuntuDrivers/detect.py as well for the time being
[10:04] <pitti> tseliot: good, then I'll upload this to fix the tests
[10:04] <pitti> tseliot: unless you still have something?
[10:06] <tseliot> pitti: yes, please, let's keep the code there for now. I have nothing to upload ATM
[10:06] <pitti> apw: OOI, what happened to the seeding of the linux-meta packages?
[10:06] <tseliot> pitti: BTW, if you could approve my nvidia packages in Xenial NEW, that would be very welcome ;)
[10:07] <seb128> tseliot, I don't find a wikipage :-/
[10:08] <seb128> Laney, do you know if there is already a wikipage somewhere for release notes?
[10:08] <seb128> I though we had one through the cycle
[10:08] <seb128> adding infos during alpha/beta/etc
[10:08] <seb128> but I can't find it
[10:09] <apw> pitti, i thought we were making that use a * thing, and i actually thought you'd already done it:)
[10:09] <Laney> seb128: not one that I know of - probably one will be created for Beta 2 though
[10:09] <seb128> tseliot, ^ I guess need to wait a bit then
[10:09] <seb128> Laney, thanks
[10:09] <pitti> 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] <Laney> seb128: IIRC the ubuntu-release-notes project is for this
[10:10] <Laney> or someone could start the page I suppose
[10:10] <tseliot> seb128: ok, I'll be waiting for that then
[10:10] <Laney> XenialXerus/ReleaseNotes
[10:10] <seb128> tseliot, or create the page
[10:10] <pitti> tseliot: no nvidia stuff in https://launchpad.net/ubuntu/xenial/+queue?queue_state=0
[10:11] <Laney> tseliot: I would create it now so that nobody forgets
[10:12] <pitti> tseliot: nevermind, saw it now, scrolled off
[10:14] <tseliot> Laney, seb128: err... https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
[10:15] <seb128> tseliot, yeah, I think that Laney was just hitting the url and suggesting creating it
[10:15] <tseliot> no need for me to create it then :)
[10:16] <seb128> ?
[10:16] <seb128> it doesn't exist yet
[10:16] <pitti> cit does
[10:16] <pitti> just still for wily
[10:17] <Laney> tseliot: I just made it
[10:18] <Laney> you can go fill in your section now
[10:18] <tseliot> Laney: yep, thanks
[10:27] <oSoMoN> 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:30] <tseliot> pitti: thanks a lot!
[10:44] <oSoMoN> 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] <Mirv> oSoMoN: yes to both
[10:44] <oSoMoN> Mirv, even considering the above?
[10:44] <Mirv> oSoMoN: still, for people who have it currently installed to get the new one
[10:44] <oSoMoN> ok, got it
[10:45] <Mirv> oSoMoN: and thanks for the MIR, looks good!
[10:45] <oSoMoN> Mirv, what section does the -doc dummy package belong to? doc, or oldlibs?
[10:47] <Mirv> 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] <oSoMoN> 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] <Mirv> 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] <Mirv> oSoMoN: thanks for starting that btw, we can get rid of more old names and transitional packages in 2 months then
[10:59] <Mirv> since there is upgrade path for 14.04 LTS -> 16.04 LTS upgraders
[11:00] <oSoMoN> 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] <tseliot> seb128, Laney: ok, I've added a few lines about fglrx in the release notes
[11:08] <seb128> tseliot, looks good, thanks!
[11:42] <jamespage> 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] <jamespage> 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] <jamespage> anyway I patched into ceilometer...
[11:43] <jamespage> I guess that would need to happen in pip itself otherwise xenial will have different pip to the rest of the world....
[11:50] <oSoMoN> Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080
[14:11] <barry> jamespage: pip isn't supposed to contain any vendored packages.  we strip out the _vendor directory
[14:12] <jamespage> barry, hmm where is that coming from then
[14:13]  * jamespage looks some more
[14:13] <jamespage> 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] <barry> jamespage: also, just syncpackaged new version of pip to xenial.  shouldn't change this bit of it, but just fyi
[14:14] <barry> jamespage: oh yeah, it'll do that if you don't tell tox otherwise!
[14:14] <jamespage> barry, my god this is confusing.,..
[14:14] <jamespage> barry, I think that's what it is
[14:15] <barry> 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] <barry> (that'll likely error out if you don't have a distro package installed)
[14:15] <jamespage> barry, indeed
[15:08] <xnox> barry, you are assuming i understood the structure i was dereferencing..... i tried combos until it worked ;-)
[15:08]  * xnox <3 TDD
[15:08] <barry> xnox: tried and true method :)
[15:12] <Saviq> xnox, any idea about bug #1552914 ?
[15:15] <xnox> Saviq, yes, doko broke things =)
[15:15] <oSoMoN> Mirv, https://code.launchpad.net/~osomon/webbrowser-app/qml-module-naming/+merge/288080 updated
[15:15] <Saviq> xnox, half a year ago and noone noticed? ;)
[15:16] <xnox> Saviq, i was not working on ubuntu half a year ago....
[15:16] <Saviq> xnox, but you were working on it since! ;D
[15:16] <Saviq> canfix? ;)
[15:17] <barry> pitti: ree bug 814115 - thanks! it would really help for debugging failures
[15:17] <barry> debian bug 814115
[15:17] <pitti> barry: yep, looking into it now
[15:17] <barry> \o/
[15:18] <pitti> stgraber: what's the word on indicator-datetime pulling in obsolete deps?
[15:30] <pitti> barry: ok, got it :)
[15:32] <barry> pitti: awesome!
[15:37] <stgraber> pitti: no response from the merge proposal, I think I'll just upload it and they'll deal with merging things later
[15:56] <smoser> hey.
[15:58] <nacc> rbasak: thanks! wil merge today
[15:58] <nacc> pitti: thanks!
[16:00] <smoser> i have a stupid question.
[16:01] <smoser> file in debian/ gets installed by dh_install. debian/open-iscsi.install
[16:03] <smoser> what is the right way to ensure its installed executable ?
[16:04] <rbasak> Make sure it is executable to start off with?
[16:04] <smoser> is that right ?
[16:04] <rbasak> You can chmod it in d/rules if needed.
[16:04] <rbasak> (usually only if upstream have it wrong)
[16:04] <smoser> well its debian/
[16:04] <smoser> so , its ours
[16:04] <rbasak> Ah. Is it a "3.0 (quilt)" source package?
[16:04] <smoser> no. its a file in debian/
[16:05] <smoser> debian/iscsi-network-interface.rules => /lib/udev/rules.d/70-iscsi-network-interface.rules
[16:05] <rbasak> What does debian/source/format say?
[16:05] <smoser> quilt 3.0. but its dh_install from ^
[16:05] <rbasak> Then you can mark it executable in the source package.
[16:05] <rbasak> And it should end up executable on the installed system.
[16:05] <smoser> yeah. that just felt brittle
[16:05] <nacc> 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] <nacc> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
[16:06] <smoser> it does not do it automatically.
[16:06] <nacc> ok
[16:06] <xnox> smoser, debian.rules files should not be executable.
[16:06] <xnox> smoser, sorry, .rules files under debian.
[16:06] <cjwatson> If you're concerned about things not working otherwise then it's fine to override_dh_install
[16:06] <smoser> xnox, its not that style of rules.
[16:06] <nacc> it's a udev rule, right?
[16:06] <smoser> yeah. its a udev rule
[16:07] <nacc> namespace collision :)
[16:07] <xnox> smoser, i think then you want to e.g.
[16:07] <xnox> override_dh_installudev:
[16:07] <nacc> smoser: it seems "better" to override dh_install, but i'm not sure
[16:07] <xnox>     dh_installudev
[16:08] <xnox>      chmod +x debian/$pkg/lib/udev/rules.d/*.rules # or some such
[16:08] <nacc> smoser: rather than assuing te permissions in the tarball are maintained, etc
[16:08] <rbasak> 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] <nacc> heh
[16:08] <xnox> nacc, i think dh_installudev will strip the permissions anyway, and/or dh_fixperms thing.
[16:08] <rbasak> But no harm in doing it explicitly in the rules file.
[16:09] <xnox> smoser, if dh_fixperms "reverts" the chmod+x you'll need to override that too, with e.g. dh_fixperms -X
[16:09] <nacc> xnox: yeah, that's what I guess I meant ... not sure what the other commands do to the file during install
[16:09] <rbasak> If dh_fixperms reverts it, then maybe worth looking into why you need it that way?
[16:09] <nacc> also fair :)
[16:09] <rbasak> BTW, while we're asking this sort of question...
[16:10] <xnox> smoser, usually people place "binaries" into /lib/udev and just rules in the rules.d directory....
[16:10] <nacc> I didn't think udev.rules needed to be exec
[16:10] <xnox> smoser, but i know that you are not a "usual" person.
[16:10] <smoser> bah
[16:10] <smoser> sorry
[16:10] <smoser> fail
[16:10] <nacc> none of them are exec on my system, at least
[16:10] <smoser> debian/net-interface-handler           /lib/open-iscsi
[16:10] <smoser> that one is the file
[16:10] <nacc> ah
[16:11] <rbasak> 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] <rbasak> 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] <cjwatson> 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] <rbasak> cjwatson: that's a good idea. I just wanted to check that there wasn't some better way I was missing. Thanks!
[16:19] <nacc> rbasak: is that dh_install complaining or dh_installman
[16:21] <smoser> rbasak, so  http://paste.ubuntu.com/15281670/ look ok ?
[16:21] <smoser> 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] <rbasak> nacc: dh_install complaining using --fail-missing about manpages installed by dh_installman (not sure what order but the dh sequencer order)
[16:23] <rbasak> smoser: IMHO, it's debdiffs that are brittle!
[16:23] <rbasak> git manages it fine.
[16:23] <smoser> well, yes.
[16:24] <rbasak> $(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] <smoser> yeah, the ones above use CURDIR
[16:25] <rbasak> s/needs to be/is/ if you like.
[16:25] <rbasak> And if you want me to be really pedantic, you're adding an unnecessary blank line in line 24 :-P
[16:25] <smoser> cyphermox, http://paste.ubuntu.com/15281670/
[16:25] <smoser> indeed i am.
[16:25] <nacc> 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] <smoser>  i will dlean that.
[16:27] <rbasak> 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] <rbasak> nacc: but then dh_install --fail-missing (if we switch to that in d/rules) complains about all those manpages again.
[16:27] <rbasak> (I'm told)
[16:30] <nacc> 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] <rbasak> nacc: I only know as much as the manpages :)
[16:31] <rbasak> Thanks for looking. I could file a bug at some point I guess.
[16:34] <nacc> 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] <rbasak> nacc: yeah we can just use dh_install --fail-missing -X ...
[17:00] <mitya57> cjwatson, rbasak: I think modern debhelper versions can read list of excluded files from debian/not-installed
[17:00] <mitya57> ≥ 9.20151004 according to the changelog
[17:00] <mitya57> (never tried that myself)
[17:00] <rbasak> mitya57: ah, neat! Thanks. Any idea where that is documented? Google doesn't find anything.
[17:01] <mitya57> It's documented in dh_install(1) here
[17:01] <rbasak> Thanks again!
[17:02] <nacc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240
[17:02] <mitya57> Yw!
[17:02] <rbasak> http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_install.1.html has it
[17:02] <rbasak> Skuggen: ^^
[17:02] <xnox> in moinmoin how do i type CamelCase word without it generating a link to CamelCase page?
[17:02] <nacc> rbasak: and seems to be referring to exactly your issue in one of the comments :)
[17:03] <Skuggen> Ah, nice
[17:04] <mitya57> xnox, try an exclamation sign, i.e. !CamelCase
[17:04] <xnox> mitya57, thanks!
[17:06] <mitya57> that was from https://moinmo.in/HelpOnLinking#Preventing_Automatically_Generated_Links
[17:09] <cjwatson> mitya57: So it does!  Not sure how I missed that.
[17:12] <mterry> seb128, hello!  Is a11y-profile-manager a package the desktop team is OK with owning / subscribing to?  (in the context of MIR bug 1552507)
[18:27] <infinity> ogra_: Commented.
[18:27] <ogra_> infinity, i'm batteling other issues too here ...
[18:28] <ogra_> OOOH !
[18:28] <ogra_> lol
[18:28] <ogra_> infinity, my other issue is that despite linbudev being in that ldd output, i dont end up with it inside the initrd
[18:29] <infinity> ogra_: Curious.  Is that also unique to running under fakechroot?
[18:29] <ogra_> definitely, since normal built initrds used to work
[18:29]  * infinity nods.
[18:30] <ogra_> other hooks all get their libs just fine too
[18:33] <infinity> 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] <infinity> s/fail/fails/
[18:33] <ogra_> well, my outer build script now has a mkdir /lib64 and i copy the linker there
[18:33] <infinity> Oh.  Gross. ;)
[18:33] <ogra_> so mkinitramfs moves on without error
[18:33] <infinity> Right.  Hrm.
[18:34] <ogra_> yeah ... i have worse hacks in the making currently though :P
[18:34] <infinity> If you didn't, it wouldn't be you.
[18:34] <ogra_> (all stuff i hope to drop once fakechroot works again :)
[18:36] <infinity> The best part about that ldd wrapper is that it fails to do the one useful thing that a wrapper SHOULD do in that situation (filter out libfakechroot!)
[18:36] <ogra_> yeah, totally
[18:37] <ogra_> root@localhost:/# grep touch initramfs-tools-ubuntu-core-0.7.28/build-initrd.sh  .... touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/fakechroot/libfakechroot.so
[18:37] <ogra_> touch $ROOT/usr/lib/$DEB_HOST_MULTIARCH/libfakeroot/libfakeroot-sysv.so
[18:37] <ogra_> works but makes a lot of noise about "library to short" in the build logs ...
[18:39] <ogra_> hmm, so now i have an initrd with libudev ... but my hack to add it actually spilled errors ... that doesnt really help :P
[18:39]  * ogra_ starts over without the hack ... perhaps i'm hllucinating now ... it shouldnt be there 
[18:48] <ogra_> building again ... perhaps that libudev thing was a red herring
[18:51]  * zyga hugs ogra_ and initrd hacking
[18:51] <zyga> how come other OSes don't have initrds :P
[18:52] <ogra_> they are not as cool
[18:53] <ogra_> zyga, usually i dont need to hack actually ... if the tools work :)
[19:02] <ogra_> wow, so with my linker hack libudev actually ends up where it should ... now thats weird
[19:15] <ogra_> argh !
[19:15] <ogra_> initramfs-tools-ubuntu-core_0.7.29_source.changes
[19:15] <ogra_> err
[19:15] <ogra_> /usr/share/initramfs-tools/hooks/zz-fix-arm64-linker ignored: not executable
[19:26] <ogra_> ogra@styx:~/Arbeitsfläche$ abootimg-unpack-initrd initrd.img-core-0.7.30
[19:26] <ogra_> 10730 Blöcke
[19:26] <ogra_> ogra@styx:~/Arbeitsfläche$ ls ramdisk/lib/aarch64-linux-gnu/|grep udev
[19:26] <ogra_> ogra@styx:~/Arbeitsfläche$
[19:26] <ogra_> WTF !
[19:26] <ogra_> why does it work if i run the build script in a chroot but not on the buildd
[19:27] <ogra_> i clearly have libudev in my local build
[19:53] <nacc> rbasak: sent a merge requst for logwatch to get us up to 7.4.2-1