=== geser_ is now known as geser
pipedreamI have a case where dh_install turns a symlink into an empty folder. (please assist)07:05
pipedream0 jan@snapperkob:~/src/sagemath-upstream-binary/sagemath-upstream-binary/debian$grep local install07:06
pipedreamamd64/local /usr/lib/sagemath07:06
pipedream0 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
pipedreamlrwxrwxrwx 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
pipedreamdrwxr-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
pipedreamis this query supposed to go to ubuntu-packaging.07:08
mitya57pipedream: I think you should link using dh_link, after installing everything else08:30
mitya57pipedream: also your packaging looks broken, there should not be "amd64" hardcoded or "local"08:59
pipedreamWill dh_link overwrite an existing directory?09:00
pipedreammitya57: this is a large open source tree currently packaged as a binary package as debianization is in progress for 6 years now09:00
pipedreamso I copy a built binary (including the open source tree) into place09:00
pipedreamso the packaging is temporarily broken but fulfilling a community need for several years09:01
pipedreamit uses dh_install to copy stuff into place, as if it were a binary package09:01
pipedreamnever mind that09:01
pipedreamwhy does dh_install take a folder into place and then take folder/path/path/path/symlink and change symlink into a folder09:01
pipedreamall the other 1000 symlinks un subfolders work fine09:02
mitya57pipedream: dh_link will overwrite existing files (it uses ln -sf internally)09:03
mitya57pipedream: I don't remember the details, but I think you really shouldn't do the linking manually before the dh_install09:05
pipedreamsorry, which linking manuall?09:07
pipedreamOh, the stuff in the source tree09:07
pipedreamI don't do it in the packaging09:07
pipedreamI inherit a source tree with many symlinks09:07
mitya57pipedream: Did you try to collaborate with Debian Science team? I see there are some not-very-old sage-related packages there.09:09
mitya57Like http://anonscm.debian.org/cgit/debian-science/packages/sagenb.git/09:09
pipedreamYes, I do09:10
pipedreamThat 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 right09:11
pipedreamin the meantime, we need an auto-update single click install09:11
pipedreamdoes dh_link always run after dh_install, or in the order of my rules file?09:11
mitya57If 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
mitya57File a bug if you think it's wrong :)09:19
pipedreamit looks like ln -sf will create a symlink inside the folder, not replace the folder09:19
pipedreammitya57: not sure it is wrong, not experienced enough with packaging09:20
pipedreammitya57: many thanks, it will take me some hours to test09:20
pipedreamI may have to just fix it in a postinst :(09:20
mitya57postinst is not needed, you can fix it in override_dh_install09:21
pipedreamCould I add a dh_link in my override_dh_install just before running dh_install?09:26
mitya57Can you just call it after, preferably using debian/*.links?09:28
pipedreamFrom my test with ln -sf, the symlink would be inside the folder not replacing it11:55
pipedreamSo I built a PPA with before dh_install (in my override_dh_install) a line:11:56
pipedreamdh_link ../../../../../../share/mathjax/ /usr/lib/sagemath/local/lib/python2.7/site-packages/sagenb-0.11.4-py2.7.egg/sagenb/data/mathjax11:56
pipedreamthis at least fixes the bug for now11:56
pipedreamI still want to figure out the root cause and do that better11:57
=== ara is now known as Guest54483
=== elopio_ is now known as elopio
tewardwhat'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
micahgteward: anywhere from a few minutes to weeks unfortunately, but I can have a look later if no one beats me to it17:31
tewardmicahg: OK, no rush, it's just a prerequisite backport for a ZNC backport.17:31
micahgI saw the znc/swig backport requests17:32
tewardyeah those're the related ones17:32
teward(swig is the prereq)17:32
tewardmicahg: 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
micahgyes, it should19:22
teward(sorry i'm a little lazy today, and don't want to open my web browser xD)19:22
tewardmicahg: 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 precedence19:23
teward(otherwise I'll go edit the description shortly)19:23
teward(when done)19:23
micahgthat's fine, it's set to incomplete waiting on you, so no rush19:24
tewardi have a thousand things on my radar due today so meh19:31
micahgteward: no rush, can be whenever you get to it19:37
tewardmicahg: 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 Utopic20:02
tewardsince iirc a Utopic test is necessary for the backport.20:02
tewardmicahg: do you need me to file a separate backport bug against trusty-backports and utopic-backports for the znc backport?20:02
micahgrequestbackport can file both at once, or if you want to use the existing bug that was filed for ZNC,  you can add a second task20:04
micahg(it just adds a second task)20:04
tewardmicahg: 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 manner20:05
tewardi'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
tewardor mark the existing package-targeted bug as a dupe against the backports target bug, but meh20:06
micahgthat's fine, whatever is easiest for you20:06
micahgsometimes I copy/paste from requestbackport, sometimes I file a new one20:06
tewardmicahg: what do we do about reverse suggests?20:19
tewardi'm not 100% familiar on testing those so a primer/explanation would be nice20:19
micahgnot required20:19
tewardmicahg: so where it says Reverse-Suggests under Reverse Dependencies in the output of requestbackport, i can ignore those reverse-suggests?20:20
micahgsuggests are nice to have packages that enhance functionality, but aren't required20:20
teward(the relevant source packages don't build-dep)20:20
tewardI'll make a note there, thanks.20:20
tewardmicahg: 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 xD20:21
micahgI don't think you have to worry about those unless something else depends on it20:22
tewardOK - it's listed though in the 'install and run' tests.20:22
tewardcan I mark it as "Test Not required" or is an installation test sufficient20:22
micahgyeah, that's automated output20:22
micahginstallation should be fine20:22
tewardi'll make a note as to why it doesn't need a runtest (as it's just debug symbols)20:23
tewardmicahg: 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
ubottuLaunchpad bug 1449248 in utopic-backports "Please backport znc 1.6.0-2 (universe) from vivid" [Undecided,New]20:27
micahgok, thanks20: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
micahgI'll keep an eye on my email20:27
=== iulian_ is now known as iulian
tewardOK.  the swig3.0 test is done though since it built without incident on Trusty in that PPA per our discussion.20:31
tewardmicahg: 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
micahgthanks, I like details :D20:33
tewardmicahg: 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
micahgteward: is that a fix needed in later releases?21:10
tewardmicahg: yes, in utopic and vivid, and while I could easily debdiff it in a matter of seconds it still needs upstreamed to Debian21:11
tewardit also needs the fix for Trusty as well21:11
micahgok, let's fix it in the later releases and backport the fixed version then21:11
tewardmicahg: 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
ubottuLaunchpad bug 1445163 in Tracker for teward's PPAs "[znc] Modules using `libicu-dev` features won't compile under Trusty" [Medium,Triaged]21:14
micahgok, I can give you tasks for all the releases once there's an Ubuntu bug21:16
tewardyep i'll nominate21:17
tewardi'm targeting it to Vivid, actually, since that's affected, and a backport of 1.6 from Vivid would be impacted by this bug21:20
tewardmicahg: are you able to approve Vivid nomination for a bug (https://bugs.launchpad.net/ubuntu/+source/znc/+bug/1449271)21:20
ubottuLaunchpad bug 1449271 in znc (Ubuntu) "znc-dev 1.6 will not compile modules which need libicu functions." [Undecided,New]21:20
micahgadded for trusty-vivid21:21
tewardmicahg: that will only apply to backports - 1.4 and earlier don't have the issue21:21
micahgoh, haha, right21:22
teward(it affects Trusty - Vivid with 1.6.x but not preexisting variants in Trusty and Utopic)21:22
micahgI thoguht we had 1.6 in trusty and utopic for some reason :-/21:22
tewardnot yet :P21:22
micahgfixed :)21:22
tewardmicahg: granted my PPA does have it, but that's based off the Debian pacakge anyways :P21:22
micahgand those won't be affected once vivid is fixed :)21:22
micahgeasiest thing is probably to get it fixed in Debian, sync'd to w, sru backport to vivid, and then regular backport to t and u21:25
micahg(assuming that's the only fix in the Debian upload)21:25
tewardi only just filed it in Debian21:26
tewardthe system hasn't returned the bug number yet21:26
micahgwell, it's simple enough to SRU on its own, but if Debian is quick to fix, consistent package versions make updates easier :021:27
tewardlol bugs.debian.org is slow in catching up xD21:27
tewardmicahg: agreed, hopefully Patrick Matthai is fast to respond/handle.21:30
tewardwell, in the interim i tested the other components of the ZNC source package and they work so meh21:34
micahgok, so at least the swig backport can go forward21:40
tewardmicahg: correct.22:03
tewardmicahg: 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!