[07:05] <pipedream> I have a case where dh_install turns a symlink into an empty folder. (please assist)
[07:06] <pipedream> 0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$grep local install
[07:06] <pipedream> amd64/local /usr/lib/sagemath
[07:08] <pipedream> 0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$ls -ldp ../amd64/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax /usr/lib/sagemath/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax/
[07:08] <pipedream> lrwxrwxrwx 1 jan  jan    32 Apr 17 23:19 ../amd64/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax -> ../../../../../../share/mathjax//
[07:08] <pipedream> drwxr-xr-x 2 root root 4096 Apr 25 06:39 /usr/lib/sagemath/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax//
[07:08] <pipedream> ah
[07:08] <pipedream> is this query supposed to go to ubuntu-packaging.
[07:08] <pipedream> soz
[08:30] <mitya57> pipedream: I think you should link using dh_link, after installing everything else
[08:59] <mitya57> pipedream: also your packaging looks broken, there should not be "amd64" hardcoded or "local"
[09:00] <pipedream> Will dh_link overwrite an existing directory?
[09:00] <pipedream> mitya57: this is a large open source tree currently packaged as a binary package as debianization is in progress for 6 years now
[09:00] <pipedream> so I copy a built binary (including the open source tree) into place
[09:00] <pipedream> ppa:aims/sagemath
[09:00] <pipedream> www.sagemath.org
[09:01] <pipedream> so the packaging is temporarily broken but fulfilling a community need for several years
[09:01] <pipedream> "broken"
[09:01] <pipedream> it uses dh_install to copy stuff into place, as if it were a binary package
[09:01] <pipedream> never mind that
[09:01] <pipedream> why does dh_install take a folder into place and then take folder/path/path/path/symlink and change symlink into a folder
[09:02] <pipedream> ?
[09:02] <pipedream> all the other 1000 symlinks un subfolders work fine
[09:03] <mitya57> pipedream: dh_link will overwrite existing files (it uses ln -sf internally)
[09:05] <mitya57> pipedream: I don't remember the details, but I think you really shouldn't do the linking manually before the dh_install
[09:07] <pipedream> sorry, which linking manuall?
[09:07] <pipedream> Oh, the stuff in the source tree
[09:07] <pipedream> I don't do it in the packaging
[09:07] <pipedream> I inherit a source tree with many symlinks
[09:09] <mitya57> pipedream: Did you try to collaborate with Debian Science team? I see there are some not-very-old sage-related packages there.
[09:09] <mitya57> Like http://anonscm.debian.org/cgit/debian-science/packages/sagenb.git/
[09:10] <pipedream> Yes, I do
[09:11] <pipedream> That is in progress since 2008, died in 2010, resurfaced 2 years ago, and is a long term project to get almost 100 package version in debian right
[09:11] <pipedream> in the meantime, we need an auto-update single click install
[09:11] <pipedream> does dh_link always run after dh_install, or in the order of my rules file?
[09:13] <mitya57> If you are using dh(1), then dh_link is run after dh_install*
[09:18] <pipedream> (also WHY does dh_install chagne a symlink into a folder ... )
[09:19] <mitya57> File a bug if you think it's wrong :)
[09:19] <pipedream> it looks like ln -sf will create a symlink inside the folder, not replace the folder
[09:20] <pipedream> mitya57: not sure it is wrong, not experienced enough with packaging
[09:20] <pipedream> mitya57: many thanks, it will take me some hours to test
[09:20] <pipedream> I may have to just fix it in a postinst :(
[09:21] <mitya57> postinst is not needed, you can fix it in override_dh_install
[09:21] <pipedream> ah
[09:26] <pipedream> Could I add a dh_link in my override_dh_install just before running dh_install?
[09:28] <mitya57> Can you just call it after, preferably using debian/*.links?
[11:55] <pipedream> From my test with ln -sf, the symlink would be inside the folder not replacing it
[11:56] <pipedream> So I built a PPA with before dh_install (in my override_dh_install) a line:
[11:56] <pipedream> dh_link ../../../../../../share/mathjax/ /usr/lib/sagemath/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax
[11:56] <pipedream> this at least fixes the bug for now
[11:57] <pipedream> I still want to figure out the root cause and do that better
[16:10] <teward> what's the general time before a backport request for Universe is looked at?
[16:10] <teward> (from filing with requestbackport to final processing)
[17:31] <micahg> teward: anywhere from a few minutes to weeks unfortunately, but I can have a look later if no one beats me to it
[17:31] <teward> micahg: OK, no rush, it's just a prerequisite backport for a ZNC backport.
[17:32] <micahg> I saw the znc/swig backport requests
[17:32] <teward> yeah those're the related ones
[17:32] <teward> (swig is the prereq)
[19:22] <teward> micahg: with regard to the swig backport request, would a build test in the same backport build tests PPA I'm already using (whcih only has the swig package) work?  I can't test locally right now due to not having a Linux system to test with.
[19:22] <micahg> yes, it should
[19:22] <teward> (sorry i'm a little lazy today, and don't want to open my web browser xD)
[19:23] <teward> OK
[19:23] <teward> micahg: can you un-X the box for the install/run test for swig3.0 itself for me as i'm in the middle of another task that takes precedence
[19:23] <teward> (otherwise I'll go edit the description shortly)
[19:23] <teward> (when done)
[19:24] <micahg> that's fine, it's set to incomplete waiting on you, so no rush
[19:31] <teward> i have a thousand things on my radar due today so meh
[19:31] <teward> :P
[19:37] <micahg> teward: no rush, can be whenever you get to it
[20:02] <teward> micahg: build tests are running, although I went ahead and also did the backportpackage for 'znc' pointing at the PPA for upload destination for both Trusty and Utopic
[20:02] <teward> since iirc a Utopic test is necessary for the backport.
[20:02] <teward> micahg: do you need me to file a separate backport bug against trusty-backports and utopic-backports for the znc backport?
[20:04] <micahg> requestbackport can file both at once, or if you want to use the existing bug that was filed for ZNC,  you can add a second task
[20:04] <micahg> (it just adds a second task)
[20:04] <micahg> s/it/requestbackport)
[20:05] <teward> micahg: right, i know it can file both at once - my question is if you want to for the existing bug against ZNC that requested the backport in the wrong manner
[20:05] <teward> i'm tempted to file via requestbackport and then reference the bug against Ubuntu's ZNC package in it like I did for the swig dependency.
[20:06] <teward> or mark the existing package-targeted bug as a dupe against the backports target bug, but meh
[20:06] <micahg> that's fine, whatever is easiest for you
[20:06] <micahg> sometimes I copy/paste from requestbackport, sometimes I file a new one
[20:09] <teward> mmm
[20:19] <teward> micahg: what do we do about reverse suggests?
[20:19] <teward> i'm not 100% familiar on testing those so a primer/explanation would be nice
[20:19] <micahg> not required
[20:20] <teward> micahg: so where it says Reverse-Suggests under Reverse Dependencies in the output of requestbackport, i can ignore those reverse-suggests?
[20:20] <micahg> suggests are nice to have packages that enhance functionality, but aren't required
[20:20] <teward> (the relevant source packages don't build-dep)
[20:20] <micahg> yes
[20:20] <teward> I'll make a note there, thanks.
[20:21] <teward> micahg: what about debug symbols?  In the past 'install' was the only test needed, with previous ZNC backports back in pre-Trusty or something, i forget how long it's been since i did a backport req of it xD
[20:22] <micahg> I don't think you have to worry about those unless something else depends on it
[20:22] <teward> OK - it's listed though in the 'install and run' tests.
[20:22] <teward> can I mark it as "Test Not required" or is an installation test sufficient
[20:22] <micahg> yeah, that's automated output
[20:22] <micahg> installation should be fine
[20:23] <teward> i'll make a note as to why it doesn't need a runtest (as it's just debug symbols)
[20:27] <teward> micahg: filed as https://bugs.launchpad.net/trusty-backports/+bug/1449248 - i just need to wait for the PPAs to finish publishing then I'll do runtime tests.  Assuming I still have a utopic VM.  If not i"ll have to go find a Utopic ISO or something to test with...
[20:27] <micahg> ok, thanks
[20:27] <teward> (the previous bug on this has been marked as a dupe of this one, because that's the easiest thing to do in this case)
[20:27] <micahg> I'll keep an eye on my email
[20:31] <teward> OK.  the swig3.0 test is done though since it built without incident on Trusty in that PPA per our discussion.
[20:32] <teward> micahg: also note that for the ZNC backport request, I've gone and actually defined the run tests and the install tests, and why -dbg has no run test.
[20:32] <teward> (because i'm paranoid about details xD)
[20:33] <micahg> thanks, I like details :D
[21:08] <teward> micahg: there needs to be one tiny packaging fix to make the dev tools work fine, and it just needs to call upon libicu-dev in the build deps for znc-dev... :/  that's already existing in Utopic and makes module builds work seamlessly.  (This is a bug identified in my PPA version for ZNC stable (from Debian) as well, and I have it on my radar to test Debian as well)
[21:10] <micahg> teward: is that a fix needed in later releases?
[21:11] <teward> micahg: yes, in utopic and vivid, and while I could easily debdiff it in a matter of seconds it still needs upstreamed to Debian
[21:11] <teward> it also needs the fix for Trusty as well
[21:11] <micahg> ok, let's fix it in the later releases and backport the fixed version then
[21:11] <teward> OK
[21:14] <teward> micahg: there's no Ubuntu bug on it, yet, but I know for a fact Trusty, Utopic, and Vivid are affected per https://bugs.launchpad.net/teward-ppas/+bug/1445163 which is actually where the unofficial ZNC PPA (based directly off Debian) is tracked.
[21:16] <micahg> ok, I can give you tasks for all the releases once there's an Ubuntu bug
[21:17] <teward> yep i'll nominate
[21:20] <teward> i'm targeting it to Vivid, actually, since that's affected, and a backport of 1.6 from Vivid would be impacted by this bug
[21:20] <teward> micahg: are you able to approve Vivid nomination for a bug (https://bugs.launchpad.net/ubuntu/+source/znc/+bug/1449271)
[21:21] <micahg> added for trusty-vivid
[21:21] <teward> micahg: that will only apply to backports - 1.4 and earlier don't have the issue
[21:22] <micahg> oh, haha, right
[21:22] <teward> (it affects Trusty - Vivid with 1.6.x but not preexisting variants in Trusty and Utopic)
[21:22] <micahg> I thoguht we had 1.6 in trusty and utopic for some reason :-/
[21:22] <teward> not yet :P
[21:22] <micahg> fixed :)
[21:22] <teward> micahg: granted my PPA does have it, but that's based off the Debian pacakge anyways :P
[21:22] <micahg> and those won't be affected once vivid is fixed :)
[21:25] <micahg> easiest thing is probably to get it fixed in Debian, sync'd to w, sru backport to vivid, and then regular backport to t and u
[21:25] <micahg> (assuming that's the only fix in the Debian upload)
[21:26] <teward> i only just filed it in Debian
[21:26] <teward> the system hasn't returned the bug number yet
[21:27] <micahg> well, it's simple enough to SRU on its own, but if Debian is quick to fix, consistent package versions make updates easier :0
[21:27] <teward> lol bugs.debian.org is slow in catching up xD
[21:30] <teward> micahg: agreed, hopefully Patrick Matthai is fast to respond/handle.
[21:34] <teward> well, in the interim i tested the other components of the ZNC source package and they work so meh
[21:40] <micahg> ok, so at least the swig backport can go forward
[22:03] <teward> micahg: correct.
[22:03] <teward> micahg: which would block any other backport anyways (ZNC or others needing swig3.0 although I don't know what does off hand)