| === geser_ is now known as geser | ||
| pipedream | I have a case where dh_install turns a symlink into an empty folder. (please assist) | 07:05 |
|---|---|---|
| pipedream | 0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$grep local install | 07:06 |
| pipedream | amd64/local /usr/lib/sagemath | 07:06 |
| 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 | 07:08 |
| mitya57 | pipedream: I think you should link using dh_link, after installing everything else | 08:30 |
| mitya57 | pipedream: also your packaging looks broken, there should not be "amd64" hardcoded or "local" | 08:59 |
| 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:00 |
| 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:01 |
| pipedream | ? | 09:02 |
| pipedream | all the other 1000 symlinks un subfolders work fine | 09:02 |
| mitya57 | pipedream: dh_link will overwrite existing files (it uses ln -sf internally) | 09:03 |
| mitya57 | pipedream: I don't remember the details, but I think you really shouldn't do the linking manually before the dh_install | 09:05 |
| 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:07 |
| 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:09 |
| pipedream | Yes, I do | 09:10 |
| 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:11 |
| mitya57 | If you are using dh(1), then dh_link is run after dh_install* | 09:13 |
| pipedream | (also WHY does dh_install chagne a symlink into a folder ... ) | 09:18 |
| 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:19 |
| 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:20 |
| mitya57 | postinst is not needed, you can fix it in override_dh_install | 09:21 |
| pipedream | ah | 09:21 |
| pipedream | Could I add a dh_link in my override_dh_install just before running dh_install? | 09:26 |
| mitya57 | Can you just call it after, preferably using debian/*.links? | 09:28 |
| pipedream | From my test with ln -sf, the symlink would be inside the folder not replacing it | 11:55 |
| 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:56 |
| pipedream | 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 | ||
| 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) | 16:10 |
| === essembe is now known as sbeattie | ||
| 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:31 |
| micahg | I saw the znc/swig backport requests | 17:32 |
| teward | yeah those're the related ones | 17:32 |
| teward | (swig is the prereq) | 17:32 |
| 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:22 |
| 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:23 |
| micahg | that's fine, it's set to incomplete waiting on you, so no rush | 19:24 |
| teward | i have a thousand things on my radar due today so meh | 19:31 |
| teward | :P | 19:31 |
| micahg | teward: no rush, can be whenever you get to it | 19:37 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| teward | mmm | 20:09 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| teward | i'll make a note as to why it doesn't need a runtest (as it's just debug symbols) | 20:23 |
| 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 |
| ubottu | Launchpad bug 1449248 in utopic-backports "Please backport znc 1.6.0-2 (universe) from vivid" [Undecided,New] | 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:27 |
| === iulian_ is now known as iulian | ||
| teward | OK. the swig3.0 test is done though since it built without incident on Trusty in that PPA per our discussion. | 20:31 |
| 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:32 |
| micahg | thanks, I like details :D | 20:33 |
| 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:08 |
| micahg | teward: is that a fix needed in later releases? | 21:10 |
| 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:11 |
| 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:14 |
| ubottu | Launchpad bug 1445163 in Tracker for teward's PPAs "[znc] Modules using `libicu-dev` features won't compile under Trusty" [Medium,Triaged] | 21:14 |
| micahg | ok, I can give you tasks for all the releases once there's an Ubuntu bug | 21:16 |
| teward | yep i'll nominate | 21:17 |
| 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:20 |
| ubottu | Launchpad bug 1449271 in znc (Ubuntu) "znc-dev 1.6 will not compile modules which need libicu functions." [Undecided,New] | 21:20 |
| 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:21 |
| 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:22 |
| 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:25 |
| teward | i only just filed it in Debian | 21:26 |
| teward | the system hasn't returned the bug number yet | 21:26 |
| 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:27 |
| teward | micahg: agreed, hopefully Patrick Matthai is fast to respond/handle. | 21:30 |
| teward | well, in the interim i tested the other components of the ZNC source package and they work so meh | 21:34 |
| micahg | ok, so at least the swig backport can go forward | 21:40 |
| 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) | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!