=== geser_ is now known as geser [07:05] I have a case where dh_install turns a symlink into an empty folder. (please assist) [07:06] 0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$grep local install [07:06] amd64/local /usr/lib/sagemath [07:08] 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] 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] 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] ah [07:08] is this query supposed to go to ubuntu-packaging. [07:08] soz [08:30] pipedream: I think you should link using dh_link, after installing everything else [08:59] pipedream: also your packaging looks broken, there should not be "amd64" hardcoded or "local" [09:00] Will dh_link overwrite an existing directory? [09:00] 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] so I copy a built binary (including the open source tree) into place [09:00] ppa:aims/sagemath [09:00] www.sagemath.org [09:01] so the packaging is temporarily broken but fulfilling a community need for several years [09:01] "broken" [09:01] it uses dh_install to copy stuff into place, as if it were a binary package [09:01] never mind that [09:01] 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] ? [09:02] all the other 1000 symlinks un subfolders work fine [09:03] pipedream: dh_link will overwrite existing files (it uses ln -sf internally) [09:05] pipedream: I don't remember the details, but I think you really shouldn't do the linking manually before the dh_install [09:07] sorry, which linking manuall? [09:07] Oh, the stuff in the source tree [09:07] I don't do it in the packaging [09:07] I inherit a source tree with many symlinks [09:09] pipedream: Did you try to collaborate with Debian Science team? I see there are some not-very-old sage-related packages there. [09:09] Like http://anonscm.debian.org/cgit/debian-science/packages/sagenb.git/ [09:10] Yes, I do [09:11] 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] in the meantime, we need an auto-update single click install [09:11] does dh_link always run after dh_install, or in the order of my rules file? [09:13] If you are using dh(1), then dh_link is run after dh_install* [09:18] (also WHY does dh_install chagne a symlink into a folder ... ) [09:19] File a bug if you think it's wrong :) [09:19] it looks like ln -sf will create a symlink inside the folder, not replace the folder [09:20] mitya57: not sure it is wrong, not experienced enough with packaging [09:20] mitya57: many thanks, it will take me some hours to test [09:20] I may have to just fix it in a postinst :( [09:21] postinst is not needed, you can fix it in override_dh_install [09:21] ah [09:26] Could I add a dh_link in my override_dh_install just before running dh_install? [09:28] Can you just call it after, preferably using debian/*.links? [11:55] From my test with ln -sf, the symlink would be inside the folder not replacing it [11:56] So I built a PPA with before dh_install (in my override_dh_install) a line: [11:56] 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] this at least fixes the bug for now [11:57] I still want to figure out the root cause and do that better === ara is now known as Guest54483 === elopio_ is now known as elopio [16:10] what's the general time before a backport request for Universe is looked at? [16:10] (from filing with requestbackport to final processing) === essembe is now known as sbeattie [17:31] 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] micahg: OK, no rush, it's just a prerequisite backport for a ZNC backport. [17:32] I saw the znc/swig backport requests [17:32] yeah those're the related ones [17:32] (swig is the prereq) [19:22] 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] yes, it should [19:22] (sorry i'm a little lazy today, and don't want to open my web browser xD) [19:23] OK [19:23] 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] (otherwise I'll go edit the description shortly) [19:23] (when done) [19:24] that's fine, it's set to incomplete waiting on you, so no rush [19:31] i have a thousand things on my radar due today so meh [19:31] :P [19:37] teward: no rush, can be whenever you get to it [20:02] 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] since iirc a Utopic test is necessary for the backport. [20:02] micahg: do you need me to file a separate backport bug against trusty-backports and utopic-backports for the znc backport? [20:04] 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] (it just adds a second task) [20:04] s/it/requestbackport) [20:05] 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] 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] or mark the existing package-targeted bug as a dupe against the backports target bug, but meh [20:06] that's fine, whatever is easiest for you [20:06] sometimes I copy/paste from requestbackport, sometimes I file a new one [20:09] mmm [20:19] micahg: what do we do about reverse suggests? [20:19] i'm not 100% familiar on testing those so a primer/explanation would be nice [20:19] not required [20:20] micahg: so where it says Reverse-Suggests under Reverse Dependencies in the output of requestbackport, i can ignore those reverse-suggests? [20:20] suggests are nice to have packages that enhance functionality, but aren't required [20:20] (the relevant source packages don't build-dep) [20:20] yes [20:20] I'll make a note there, thanks. [20:21] 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] I don't think you have to worry about those unless something else depends on it [20:22] OK - it's listed though in the 'install and run' tests. [20:22] can I mark it as "Test Not required" or is an installation test sufficient [20:22] yeah, that's automated output [20:22] installation should be fine [20:23] i'll make a note as to why it doesn't need a runtest (as it's just debug symbols) [20:27] 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] Launchpad bug 1449248 in utopic-backports "Please backport znc 1.6.0-2 (universe) from vivid" [Undecided,New] [20:27] ok, thanks [20:27] (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] I'll keep an eye on my email === iulian_ is now known as iulian [20:31] OK. the swig3.0 test is done though since it built without incident on Trusty in that PPA per our discussion. [20:32] 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] (because i'm paranoid about details xD) [20:33] thanks, I like details :D [21:08] 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] teward: is that a fix needed in later releases? [21:11] 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] it also needs the fix for Trusty as well [21:11] ok, let's fix it in the later releases and backport the fixed version then [21:11] OK [21:14] 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:14] Launchpad bug 1445163 in Tracker for teward's PPAs "[znc] Modules using `libicu-dev` features won't compile under Trusty" [Medium,Triaged] [21:16] ok, I can give you tasks for all the releases once there's an Ubuntu bug [21:17] yep i'll nominate [21:20] 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] micahg: are you able to approve Vivid nomination for a bug (https://bugs.launchpad.net/ubuntu/+source/znc/+bug/1449271) [21:20] Launchpad bug 1449271 in znc (Ubuntu) "znc-dev 1.6 will not compile modules which need libicu functions." [Undecided,New] [21:21] added for trusty-vivid [21:21] micahg: that will only apply to backports - 1.4 and earlier don't have the issue [21:22] oh, haha, right [21:22] (it affects Trusty - Vivid with 1.6.x but not preexisting variants in Trusty and Utopic) [21:22] I thoguht we had 1.6 in trusty and utopic for some reason :-/ [21:22] not yet :P [21:22] fixed :) [21:22] micahg: granted my PPA does have it, but that's based off the Debian pacakge anyways :P [21:22] and those won't be affected once vivid is fixed :) [21:25] 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] (assuming that's the only fix in the Debian upload) [21:26] i only just filed it in Debian [21:26] the system hasn't returned the bug number yet [21:27] 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] lol bugs.debian.org is slow in catching up xD [21:30] micahg: agreed, hopefully Patrick Matthai is fast to respond/handle. [21:34] well, in the interim i tested the other components of the ZNC source package and they work so meh [21:40] ok, so at least the swig backport can go forward [22:03] micahg: correct. [22:03] micahg: which would block any other backport anyways (ZNC or others needing swig3.0 although I don't know what does off hand)