# /srv/irclogs.ubuntu.com/2015/04/27/#ubuntu-motu.txt

pipedream pipedream === geser_ is now known as geser I have a case where dh_install turns a symlink into an empty folder. (please assist) 07:05 0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$grep local install 07:06 amd64/local /usr/lib/sagemath 07:06 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 07:08 pipedream: I think you should link using dh_link, after installing everything else 08:30 pipedream: also your packaging looks broken, there should not be "amd64" hardcoded or "local" 08:59 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:00 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:01 ? 09:02 all the other 1000 symlinks un subfolders work fine 09:02 pipedream: dh_link will overwrite existing files (it uses ln -sf internally) 09:03 pipedream: I don't remember the details, but I think you really shouldn't do the linking manually before the dh_install 09:05 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:07 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:09 Yes, I do 09:10 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:11 If you are using dh(1), then dh_link is run after dh_install* 09:13 (also WHY does dh_install chagne a symlink into a folder ... ) 09:18 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:19 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:20 postinst is not needed, you can fix it in override_dh_install 09:21 ah 09:21 Could I add a dh_link in my override_dh_install just before running dh_install? 09:26 Can you just call it after, preferably using debian/*.links? 09:28 From my test with ln -sf, the symlink would be inside the folder not replacing it 11:55 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:56 I still want to figure out the root cause and do that better 11:57 === ara is now known as Guest54483 === elopio_ is now known as elopio what's the general time before a backport request for Universe is looked at? 16:10 (from filing with requestbackport to final processing) 16:10 === essembe is now known as sbeattie 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:31 I saw the znc/swig backport requests 17:32 yeah those're the related ones 17:32 (swig is the prereq) 17:32 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:22 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:23 that's fine, it's set to incomplete waiting on you, so no rush 19:24 i have a thousand things on my radar due today so meh 19:31 :P 19:31 teward: no rush, can be whenever you get to it 19:37 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:02 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:04 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:05 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:06 mmm 20:09 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:19 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:20 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:21 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:22 i'll make a note as to why it doesn't need a runtest (as it's just debug symbols) 20:23 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 20:27 === iulian_ is now known as iulian OK.  the swig3.0 test is done though since it built without incident on Trusty in that PPA per our discussion. 20:31 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:32 thanks, I like details :D 20:33 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:08 teward: is that a fix needed in later releases? 21:10 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:11 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:14 ok, I can give you tasks for all the releases once there's an Ubuntu bug 21:16 yep i'll nominate 21:17 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:20 added for trusty-vivid 21:21 micahg: that will only apply to backports - 1.4 and earlier don't have the issue 21:21 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:22 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:25 i only just filed it in Debian 21:26 the system hasn't returned the bug number yet 21:26 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:27 micahg: agreed, hopefully Patrick Matthai is fast to respond/handle. 21:30 well, in the interim i tested the other components of the ZNC source package and they work so meh 21:34 ok, so at least the swig backport can go forward 21:40 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) 22:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!