| alexlist | pgquiles_: thats what we end up doing until the upstream 3rd pty software vendor comes up with a version compiled with gcc 5.2 ... | 00:32 |
|---|---|---|
| pgquiles_ | alexlist: then move your application to C++11 ABI too :-) | 00:36 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| psusi | does anyone have experience with IP multicast? I'm trying to figure out what is wrong with mediatomb... it currently has its .service file run route add -n 239.0.0.0 netmask 255.0.0.0 eth0, and ifconfig eth0 allmulti... but shouldn't these be entirely unneeded if it were programmed right? | 02:12 |
| psusi | that is to say, shouldn't it be using the sockets api to subscribe to the multicast group and send packets to the right interfaces, without the startup script running these commands? | 02:13 |
| hallyn | pitti: mbiebl: is there a way (rm some stampfile) to get just the fakeroot debian/rules binary part of a systemd package build to be re-done? (I changed one file, want just that rebuilt) | 03:42 |
| pitti | Good morning | 06:13 |
| pitti | hallyn: it heavily depends on the packaging, but try debuild/dpkg-buildpackge with -nc ? | 06:13 |
| hallyn | pitti: was specifically asking about sytemd :) but will try that next time, thx | 06:14 |
| hallyn | good night :) | 06:15 |
| * hallyn out | 06:15 | |
| pitti | hallyn: I suggest building with CFLAGS="-O0 -g", it's muuuch faster | 06:17 |
| pitti | hallyn: good night! | 06:17 |
| pitti | slangasek: cantor> ah, so that's a case where test-simulated-installing the individual debs from -proposed works, but several of them as a whole; I'll have a closer look at that, and either robustify our fallback to un-pinned, or maybe infinity's suggestion works even better | 06:24 |
| pitti | slangasek: curious that it did find that "uninstallable with partial -proposed" on i386/amd64 | 06:25 |
| pitti | slangasek: It can be reproduced locally rather easily, I just need to do an autopkgtest release; doing that now | 06:25 |
| pitti | slangasek: err, "soon" -- after looking at the trigger prio thing | 06:25 |
| pitti | (giving this some field testing is the reason why I didn't release it yet) | 06:26 |
| slangasek | pitti: "trigger prio thing"? | 06:27 |
| pitti | slangasek: sorry, I meant changing the apt pinning the way Adam suggested | 06:27 |
| slangasek | pitti: but ok, thanks for the clarification on cantor | 06:27 |
| slangasek | ah right on | 06:27 |
| pitti | I actually thought I tried with higher prios already, but maybe not high enough | 06:27 |
| slangasek | I think the threshold is 500 | 06:28 |
| slangasek | and I guess I read the manpage wrong | 06:28 |
| pitti | yeah, I remembered right -- merely bumping 100 to 800 for -proposed still doesn't fix my test case | 06:30 |
| slangasek | pitti: ok you and infinity get to scratch your heads together then :) | 06:32 |
| pitti | but I'll try this on cantor and lxd, if it makes things any better | 06:32 |
| pitti | slangasek: and in any case I have cantor and lxd (and possibly others) to at least fix the regressing tests :) | 06:34 |
| slangasek | right ;) | 06:34 |
| slangasek | meanwhile I'm overriding for octave so we can make progress on the transition | 06:34 |
| pitti | slangasek: that won't actually propagate yet as it seems, so I can still look at it while it's in proposed, yes | 06:36 |
| === cpaelzer_ is now known as cpaelzer | ||
| pitti | slangasek, stgraber: ooh, I know what's wrong -- we still dist-upgrade the whole testbed to -proposed (things like sqlite or kernel, which are in the default install), which then conflicts with the apt pinning that we set up | 07:02 |
| pitti | (unrelated to that apt pinning not working in every case, but explaining the test regressions) | 07:03 |
| pitti | in fact, in the new regime we don't actually *want* to upgrade the whole testbed, I think | 07:03 |
| pitti | only the packages we are testing | 07:03 |
| pitti | it gives us better coverage for testing low-level packages, but it's incompatible with that new pinning isolation approach | 07:04 |
| dkessel | good morning | 07:23 |
| dholbach | good morning | 07:37 |
| ginggs_ | Logan, doko: can i go ahead and sync openblas? you had a "build everywhere" patch and now the new version builds on all the ubuntu archs https://buildd.debian.org/status/package.php?p=openblas&suite=unstable | 07:48 |
| pitti | slangasek: removed your hint again, octave is green again (and it's stuck on the graphicsmagick transition) | 08:53 |
| mapreri | can somebody help me make some sense of these failures? https://launchpad.net/ubuntu/+source/sigil/0.9.0+dfsg-1 | 09:01 |
| pitti | infinity, Laney: FYI, I documented the improved tmpfail handling and also added the SIGHUP vs. SIGTERM bits to https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration | 10:09 |
| decci | Hello Developers | 10:25 |
| decci | I am trying to build multiple .deb packages. One .DEB package worked fine but while I am trying to use the same rule file for multiple packages it throws dh_builddeb: -P was specified, but multiple packages would be acted on | 10:26 |
| cjwatson | decci: this will probably be easier to debug if you pastebin your rules file | 10:28 |
| decci | cjwatson: Sure | 10:29 |
| decci | cjwatson: http://pastebin.com/CKx62rB4 | 10:34 |
| decci | cjwatson: While I tried creating .DEB with 1 package entry in control file, it worked. But while I added two more package entries into control file, it complained | 10:34 |
| decci | dh_builddeb: -P was specified, but multiple packages would be acted on | 10:36 |
| cjwatson | decci: ok, that has a number of flaws | 10:37 |
| decci | cjwatson: like? | 10:38 |
| cjwatson | you shouldn't be calling so many dh_* commands in override_dh_install, to start with - that should only be modifying the behaviour of dh_install | 10:38 |
| cjwatson | and you probably have no real need to pass --tmpdir to dh_builddeb | 10:38 |
| decci | cjwatson: I skipped dh $@ --with autotools-dev --with autoreconf --parallel --builddirectory=_build | 10:38 |
| cjwatson | you would be better off installing files to the right place rather than overriding tmpdir | 10:39 |
| decci | cjwatson: What is the right way? | 10:39 |
| cjwatson | which probably simply means setting buildroot = debian/dang (assuming that that's your package name) | 10:39 |
| decci | cjwatson: I usually do is dh_make >> !cmake >> debian/rules build >> debian/rules binary | 10:39 |
| cjwatson | but it depends on what delta.mk does | 10:39 |
| decci | cjwatson: It just has variables for lib, opt and etc placement | 10:40 |
| cjwatson | decci: debian/rules should be the entry point and should take care of calling cmake or whatever | 10:40 |
| decci | cjwatson: Few queries I have | 10:41 |
| xnox | hallyn: i has no internets at home yet =) | 10:41 |
| xnox | hallyn: when i haz internets i'll be happy to do things. | 10:41 |
| decci | cjwatson: Say I have precompiled source code | 10:41 |
| decci | cjwatson: I went to source directory | 10:42 |
| cjwatson | precompiled source code makes no difference, if that's the case you just have debian/rules not do the build pass, it usually actually simplifies things | 10:42 |
| decci | cjwatson: Ran dh_make -f ../delta.tar.gz -p delta_6.2.0 | 10:42 |
| decci | cjwatson: okay | 10:42 |
| decci | cjwatson: Then ran cmake command with cmake -DDO_STAGING=FALSE -G 'Unix Makefiles' -DCMAKE_INSTALL_PREFIX=/tmp/INST/620/64 -DCMAKE_BUILD_TYPE=Release -DBUILD_ARCH=m64 -DRELEASE_MAJOR=6 -DRELEASE_MINOR=2 -DRELEASE_MICRO=0 -DSIGN_JARS=FALSE -DOBFUSCATE_JARS=FALSE -DTKT_NO=1234 -DREV_NO=1234 . | 10:43 |
| decci | cjwatson: then debian/rules build | 10:43 |
| cjwatson | ok, seriously, don't | 10:43 |
| cjwatson | debian/rules should be the thing that calls cmake | 10:43 |
| decci | cjwatson: :( | 10:44 |
| cjwatson | (possibly via helpers) | 10:44 |
| cjwatson | and for sensibly-laid-out cmake packages, dh will do most of the hard work for you | 10:44 |
| decci | cjwatson: you mean I can skip cmake..but DCMAKE_INSTALL_PREFIX refers to /tmp/INST/620/64 | 10:44 |
| cjwatson | dh will set a more sensible CMAKE_INSTALL_PREFIX | 10:45 |
| decci | cjwatson: where my required directories and files are stored to be picked up | 10:45 |
| cjwatson | /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm: -DCMAKE_INSTALL_PREFIX=/usr | 10:45 |
| cjwatson | but you can override that in override_dh_auto_build if you need to | 10:45 |
| cjwatson | /tmp/INST/620/64 is a seriously weird place for files to end up in the built package | 10:46 |
| decci | cjwatson::( | 10:46 |
| decci | cjwatson: Looks like I have been doing things wrongly | 10:46 |
| decci | cjwatson: though I was able to create a single package | 10:47 |
| decci | cjwatson: Any reference which can help me with example how to proceed when one has precompiled source and cmake ready | 10:47 |
| cjwatson | decci: so, my starting point for what you're describing would be something roughly like http://paste.ubuntu.com/13226226/ | 10:47 |
| decci | cjwatson: let me go through | 10:47 |
| cjwatson | you can add more stuff to the dh_auto_build line if you need to, to pass other cmake options | 10:47 |
| cjwatson | and I might have got some of the paths a bit wrong because I don't know all the detials | 10:48 |
| cjwatson | *details | 10:48 |
| decci | cjwatson: So dont we need dh_install, dh_builddeb | 10:48 |
| cjwatson | decci: dh will call those automatically | 10:48 |
| cjwatson | that's its purpose | 10:48 |
| decci | cjwatson: not even dh_install | 10:48 |
| cjwatson | dh calls that | 10:49 |
| decci | cjwatson: okay | 10:49 |
| cjwatson | see "man dh" | 10:49 |
| cjwatson | the point of these override rules is that you can have a rules file that says "just do the sensible thing" and then override it for the bits where you need non-default behaviour | 10:49 |
| decci | cjwatson: and where shall I put my directory which I want to install like /opt /etc | 10:49 |
| cjwatson | debian/<package-name>.dirs | 10:49 |
| cjwatson | debian/dang in my example should be replaced with debian/<package-name> where <package-name> is the binary package you want to install that stuff into | 10:50 |
| cjwatson | oh, in fact my example probably wants to be http://paste.ubuntu.com/13226240/ so that you can still use debian/*.install files | 10:50 |
| cjwatson | (i.e. override_dh_install changed to be "dh_install + more stuff" rather than just the custom stuff) | 10:50 |
| cjwatson | decci: ^- | 10:51 |
| decci | cjwatson: Do I need to simply dump all my diretory udner debian/<package-name>.dirs | 10:52 |
| decci | cjwatson: What about buildroot? | 10:53 |
| decci | cjwatson: Let me try following your rules file and see if that works | 10:53 |
| cjwatson | I would strongly recommend reading the debhelper docs - the .dirs file is documented in "man dh_installdirs" | 10:53 |
| cjwatson | for buildroot, well, that depends what that actually does | 10:54 |
| cjwatson | but normally, the way this works when you have multiple binaries is that you install your stuff to debian/tmp (or more usually let debhelper sort that out for you) and then you have .install files that select which bits of the upstream-installed tree to put into which binaries | 10:55 |
| cjwatson | you should make sure that it's actually worth multiple binary packages, since it's somewhat inevitably more work to keep track of what goes where | 10:55 |
| decci | cjwatson: I am trying that now..rules file ready..just need to dump .dir | 10:56 |
| decci | cjwatson: 2 min | 10:56 |
| decci | cjwatson: but normally, the way this works when you have multiple binaries is that you install your stuff to debian/tmp (or more usually let debhelper sort that out for you) and then you have .install files that select which bits of the upstream-installed tree to put into which binaries | 10:56 |
| decci | cjwatson: The above recommendation is what I tried too..let me show what I actually did.. | 10:57 |
| ara | cjwatson, tjaalton: hello! This bug has been verified for some days in trusty-proposed and it is quite critical to have it in updates, can any of you review it, please? | 10:59 |
| ara | https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1480217 | 10:59 |
| ubottu | Launchpad bug 1480217 in nautilus (Ubuntu Trusty) "Nautilus background handling screwed when changing scaling factor." [High,Fix committed] | 10:59 |
| ara | or pitti ^ | 11:00 |
| ara | :) | 11:00 |
| pitti | ara: it's been 5 days, and we normally require 7 | 11:01 |
| ara | pitti, ah, great, good to know :) | 11:01 |
| pitti | ara: as an explanation why it hasn't been moved yet | 11:01 |
| pitti | ara: if that's super-urgent, we can expedite of course | 11:01 |
| ara | this one is a bit urgent, yes, but it is good to know the 7-day rule | 11:02 |
| tjaalton | and works around a crasher in the intel X driver, giving more time to bisect it.. | 11:06 |
| rbasak | Is there a known bug in lintian in Wily? I'm getting a false positive on postinst-must-call-ldconfig but can't reproduce with lintian on sid. | 11:06 |
| * rbasak ignores the error | 11:08 | |
| decci | cjwatson: http://paste.ubuntu.com/13226314/ | 11:08 |
| pitti | ara: released | 11:09 |
| ara | pitti, fantastic, thanks a lot | 11:09 |
| decci | cjwatson: I tried specifying .install file where I have added entries for files..but where shall I actually add those directories to ..will debian/tmp the right directory to put? | 11:09 |
| decci | cjwatson: Does the pastebin looks good | 11:10 |
| doko | ginggs_, sure | 11:15 |
| decci | cjwatson: tried running it lets see how it goes | 11:16 |
| cjwatson | decci: so, "delta-dang" is not one of the package names you've listed in debian/control, so that won't work | 11:17 |
| cjwatson | decci: nor will the "Depends: delta-dang (>= blah)" in a couple of places in debian/control | 11:18 |
| cjwatson | decci: also, debian/dang in debian/rules should be replaced with debian/delta-eng or debian/delta-dang-snmp or debian/delta-dang-dev or something, depending on which package you want those ld.so.conf.d files to go in | 11:18 |
| decci | cjwatson: That I am going to correct..just an example ... | 11:19 |
| decci | cjwatson: One thing to ask - how will debian/rules binary know to pick up all directory under debian/tmp | 11:19 |
| decci | cjwatson: is what buildroot enough to help it | 11:19 |
| cjwatson | decci: dh_install will expect to be able to copy those files from under debian/tmp; normally you shouldn't need to hardcode that though, because dh_auto_install will run "make install DESTDIR=$(pwd)/debian/tmp" or equivalent for you | 11:20 |
| cjwatson | any vaguely well-written upstream build system should honour that | 11:20 |
| decci | cjwatson: Great info | 11:20 |
| cjwatson | decci: buildroot is entirely your stuff, debhelper doesn't know or care about it | 11:21 |
| decci | cjwatson: What about Depends section in control file, say for a package if I mention Depends: (foo1), (foo2) and that is not current built..will the .DEB packaging proceed | 11:22 |
| cjwatson | in general most variables that you set in debian/rules are up to you, unless specifically documented otherwise | 11:22 |
| cjwatson | decci: an unsatisfiable Depends won't prevent the build from completing, but you might end up with a .deb you can't install | 11:23 |
| decci | cjwatson: So it means if I install it on ubuntu machine, it will throw error saying it is dependend upon foo2 wwhich has to be installed | 11:23 |
| decci | cjwatson: correct | 11:23 |
| cjwatson | decci: right | 11:23 |
| decci | cjwatson: So it is suggested to install the foo2 first and then install this package | 11:24 |
| decci | cjwatson: got your point | 11:24 |
| cjwatson | well, most people will use apt which handles that automatically, but yes, if you install with dpkg -i then you have to deal with that yourself | 11:24 |
| decci | cjwatson: it was great info..I am going to start from fresh with correct pkg name which u suggest and see if that helps | 11:24 |
| cjwatson | this is entirely necessary behaviour of course, since you're typically depending on all sorts of things that aren't part of your source package | 11:24 |
| decci | cjwatson: I wonder if there would be more easy way..I loved checkinstall but it lacks rules part right | 11:25 |
| decci | cjwatson: debreate is GUI based but quite slow | 11:25 |
| cjwatson | decci: well, I'm the wrong person to ask about that | 11:25 |
| decci | cjwatson:I understand...an official way is debian doc | 11:26 |
| ginggs_ | thanks doko | 11:28 |
| decci | cjwatson: One question - delta-dang.install under http://paste.ubuntu.com/13226314/...does it install those directory | 12:14 |
| decci | cjwatson: sbin doesnt occur under opt/dang/dang | 12:15 |
| decci | cjwatson: so wonder what this file actually does | 12:15 |
| cjwatson | decci: if it doesn't occur there, why did you write the file that way? | 12:17 |
| cjwatson | decci: "man dh_install" explains what *.install files do | 12:17 |
| cjwatson | please do read it | 12:17 |
| === _salem is now known as salem_ | ||
| decci | cjwatson: Look in my rules I specify mkdir, touch and mv to copy , create files..here and there which is required..so I wanted to understand what actually entries under .install doing | 12:18 |
| decci | cjwatson: ok will read it | 12:18 |
| cjwatson | decci: you can always do things by hand, but where possible it's more robust, simpler, and clearer to use declarative forms rather than big piles of shell | 12:19 |
| decci | cjwatson: The rules went fine.During dh_install part , http://paste.ubuntu.com/13226669/ | 12:27 |
| cjwatson | decci: you should only be putting something in *.install if the upstream build system installs it | 12:28 |
| cjwatson | otherwise, I don't have enough context of this build system to advise | 12:29 |
| decci | cjwatson: Do I need .dir directory which u suggested to dump all the directories to | 12:30 |
| decci | cjwatson: I was mistakenly dumping everything under /tmp...i think debian/tmp is being created while rule is run | 12:31 |
| decci | cjwatson: So I would need .dir directory too | 12:31 |
| decci | cjwatson: correct? | 12:31 |
| cjwatson | the purpose of debian/*.dirs (which is "dirs", not "dir", and is a file, not a directory) is to declare that you need a bunch of mkdir commands run by dh_installdirs; nothing else | 12:32 |
| cjwatson | installing to /tmp is a serious mistake, fix that first | 12:32 |
| cjwatson | the upstream build system ought to be installing to where DESTDIR says, and creating directories as needed | 12:33 |
| decci | cjwatson: Can you help me with an example..little confusing | 12:35 |
| decci | cjwatson: you can take http://paste.ubuntu.com/13226669/ as an example | 12:35 |
| cjwatson | not at the moment, I'm sorry, run out of time for this | 12:35 |
| decci | cjwatson: Just need to udnerstand dh_install | 12:35 |
| pgquiles_ | decci: you may need to run dh_instal with --sourcedir=debian/tmp/ | 12:43 |
| pgquiles_ | and that's assuming you are actually installing to debian/tmp, by default .dirs creates directores under debian/packagename | 12:43 |
| cjwatson | or 'echo 9 >debian/compat' so that it uses more modern behaviour by default | 12:46 |
| cjwatson | (assuming that's currently missing or set to something less than 7) | 12:46 |
| === francisco is now known as Guest69743 | ||
| === hikiko is now known as hikiko|ln | ||
| decci | ok | 13:09 |
| decci | cjwatson: compat is set to 7 | 13:10 |
| decci | pgquiles_: but debian/tmp is something which is being created as it is buildroot. | 13:13 |
| decci | cjwatson: where do I need to dump the directories which I want to push to debian/tmp | 13:16 |
| decci | pgquiles_: where do I need to dump the directories which I want to push to debian/tmp | 13:18 |
| === hikiko|ln is now known as hikiko | ||
| hallyn | xnox: is that scheduled soon or are you like waiting for fiber to be laid down in february or something? :) | 13:53 |
| === awe is now known as awe|afk | ||
| xnox | hallyn: i'm awaiting for a fibre modem to arrive. | 14:02 |
| xnox | hallyn: the fibre is in place. | 14:02 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| cyphermox | good morning! | 14:07 |
| === Elimin8r is now known as Elimin8er | ||
| roadmr | hey folks! I need to make the checkbox source package produce only dummiy binaries for upgrading purposes. Is it ok if the source package contains only a debian directory? | 14:17 |
| Laney | roadmr: you could also make the new package provide the old binaries | 14:19 |
| cjwatson | yeah, the latter approach would be more usual, although the former is OK | 14:19 |
| roadmr | oh good idea... let me ask the new package folks | 14:20 |
| === Tm_Tr is now known as Guest15900 | ||
| === awe|afk is now known as awe | ||
| hallyn | xnox: swanky :) for me, high bw is reserved for my servers, sadly | 14:46 |
| pitti | sitter: ah, I see some kde tests got fixed for the "command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C | 15:12 |
| pitti | " thingy | 15:12 |
| pitti | sil2100: AFAICS, kcoreaddons, kio, and kde-runtime are still left | 15:12 |
| pitti | err, sitter ^ | 15:12 |
| pitti | greyback, sil2100: FYI, seems qtmir FTBFS on armhf now: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/q/qtmir/20151111_122235@/log.gz | 15:14 |
| sitter | yofel: ^ | 15:15 |
| sil2100 | pitti: you pinging me again! | 15:16 |
| sil2100 | ;p | 15:16 |
| greyback | CLOCK_MONOTONIC undeclared?? | 15:16 |
| pitti | greyback: yeah, that's what the log says; not sure, might be a change/regression in new kernel? | 15:17 |
| yofel | pitti: I fixed all of that as far as I know, but as 35 of my uploads were rejected, I first need to develop a way to keep the kubuntu packageset in sync with reality. Then I'll upload the rest. | 15:17 |
| yofel | (regarding kde tests) | 15:18 |
| pitti | yofel: oh cool, thank you! | 15:19 |
| greyback | pitti: that's coming in via lttng headers that qtmir includes. Looking to see where that symbol might have gone | 15:22 |
| pitti | doko: the python{2.7,3.4,3.5} regressions actually do look related to the new openssl: http://paste.ubuntu.com/13227864/ | 15:23 |
| pitti | doko: does that magic "options" number need to be adjusted for the new openssl, or is that actually a bug in openssl? | 15:23 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openssl | 15:23 |
| pitti | yofel: FYI, kwin (https://launchpad.net/ubuntu/+source/kwin/4:5.4.2-0ubuntu2) FTBFS on symbols mismatches | 15:24 |
| roaksoax_ | pitti: so, I'm running into an issue where the tests seems to be failing, even though all the tests have run successfully. Anychance you can take a look? http://paste.ubuntu.com/13227887/ | 15:27 |
| roaksoax_ | my guess is that it is: adt-run: DBG: / tests-tree rmtree /var/lib/jenkins/workspace/maas-trusty-trunk-manual/results/tests-tree | 15:28 |
| roaksoax_ | Build step 'Execute shell' marked build as failure | 15:28 |
| pitti | roaksoax_: what prints that ^, a Jenkins job? | 15:31 |
| mdeslaur | pitti, doko: python tests need to be fixed to match how I've disabled sslv3 | 15:38 |
| yofel | pitti: I know, I'll patch that later today (there was some upstream discussion involved) | 15:38 |
| pitti | mdeslaur: ah, that's the missing 0x2000000? | 15:40 |
| mdeslaur | pitti: yeah...it's making some assumptions there....there also seems to be sslv3 tests later on too which probably will fail | 15:41 |
| mdeslaur | pitti, doko: I'll fix them | 15:41 |
| pitti | mdeslaur: thanks for the heads-up; does that apply to Debian's openssl too? | 15:42 |
| pitti | doko usually keeps the python* in sync | 15:42 |
| pitti | or perhaps the test should just be loosened | 15:42 |
| mdeslaur | debian broke abi with their change, so a lot of things will be breaking there | 15:42 |
| pitti | so at worst, "options in [2164261887, 2197816319]" | 15:43 |
| mdeslaur | yeah, I'll try and make it work both ways | 15:43 |
| === Ursinha_ is now known as Ursinha | ||
| dholbach | can somebody moderate my mail to u-d-a? | 16:56 |
| cjwatson | dholbach: done | 17:14 |
| dholbach | thanks cjwatson | 17:14 |
| mapreri | the sigil builds on xenial are failing due to apt failures that don't make sense to me, can some of you take a look at them? (they are all the same) https://launchpadlibrarian.net/225723080/buildlog_ubuntu-xenial-amd64.sigil_0.9.0%2Bdfsg-1_BUILDING.txt.gz | 17:15 |
| Laney | mapreri: Looks like libjs-jquery-scrollto isn't installable because we don't have jquery >= 1.8 | 17:17 |
| cjwatson | libjs-jquery-scrollto : Depends: libjs-jquery (>= 1.8) but 1.7.2+dfsg-3ubuntu2 is to be installed | 17:18 |
| cjwatson | bah, too slow | 17:18 |
| mapreri | oh, right :\ | 17:19 |
| mapreri | Laney: cjwatson: but shouldn't LP figure this out *before* trying to build it? | 17:19 |
| mapreri | and put the package in depwait | 17:19 |
| mapreri | and also, xenial/release contains an installable version of libjs-jquery-scrollto that does not need libjs-jquery (>= 1.8), why not trying that | 17:20 |
| cjwatson | mapreri: the problem is that that depwait could be resolved in multiple different ways | 17:22 |
| cjwatson | mapreri: it wouldn't be accurate to set a depwait on libjs-jquery (>= 1.8), because libjs-jquery-scrollto might stop depending on it | 17:22 |
| cjwatson | mapreri: and beyond that this gets combinatorial-explody | 17:22 |
| mapreri | (it won't) | 17:22 |
| cjwatson | yeah but LP doesn't know that | 17:23 |
| cjwatson | mapreri: so we don't set depwaits more than one level down | 17:23 |
| cjwatson | to avoid the situation where there's an outdated depwait that will never clear by itself | 17:23 |
| mapreri | cjwatson: any reason why apt can't figure out to use an outdated version of libjs-jquery-scrollto which is installable? | 17:24 |
| cjwatson | no idea | 17:24 |
| cjwatson | possibly just trying to avoid having to do exponential backtracking | 17:25 |
| mapreri | ok | 17:26 |
| mapreri | i'll just ignore it, hopefully somebody will merge a newer version of jquery and everything will fix by itself | 17:28 |
| greyback | pitti: https://code.launchpad.net/~gerboland/qtmir/xenial-armhf-fix/+merge/277282 fixes that qtmir issue here. How to land? Make a silo? | 18:56 |
| elbrus | pitti: my latest upload of dbconfig-common fails to pass the autopkgtests on armhf only, everytime for another reason which all look unrelated to dbconfig-commoon... what is the best way forward? | 19:21 |
| elbrus | http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/xenial/armhf/ | 19:21 |
| slangasek | pitti: it appears britney is waiting for a test result from libpdl-stats-perl on amd64 triggered by gsl/2.0+dfsg-1ubuntu1, but the request looks like it was lost because there was another libpdl-stats-perl test running at the same time with a different trigger | 19:29 |
| slangasek | pitti: (manually triggered now) | 19:30 |
| ponycorn | Hey guys, are there any plans to update the gpg iso signing keys? To my knowledge, 1024 bit DSA keys are not considered safe anymore? | 19:35 |
| mdeslaur | ponycorn: bug 1363482 | 19:50 |
| ubottu | bug 1363482 in ubuntu-keyring (Ubuntu) "ubuntu-keyring includes 1024D keys" [High,Confirmed] https://launchpad.net/bugs/1363482 | 19:50 |
| cjwatson | (answered on #ubuntu-release, too) | 19:59 |
| ponycorn | Awesome, thank you mdeslaur and ubottu, and sorry for posting this in multiple channels | 20:07 |
| === salem_ is now known as _salem | ||
| robert_ancell | slangasek, infinity, could someone have a look at the lightdm 1.14.3 SRU for vivid? It's got a feature that's important for the phone. | 20:54 |
| mbiebl | hallyn: not sure if your question was answered, but I think this is standard dh7 behaviour | 22:03 |
| mbiebl | I assume dh keeps stamp files in debian/, but I actually dunno if you can remove one of those to trigger a new make run | 22:03 |
| mbiebl | what you can do, to speed up the build, is to not run the test-suite and skip the udeb build | 22:04 |
| mbiebl | export DEB_BUILD_OPTIONS="nocheck noudeb" | 22:04 |
| pitti | elbrus: indeed; it either fails with "hostname: Temporary failure in name resolution | 22:06 |
| pitti | elbrus: or | 22:06 |
| pitti | ERROR: encoding "UTF8" does not match locale "en_US" DETAIL: The chosen LC_CTYPE | 22:06 |
| pitti | elbrus: ^ not sure if that's intended and part of the test case? | 22:07 |
| pitti | elbrus: anyway, I'll have closer look tomorrow morning and reproduce; I might just set it to "always failed" (then it'll promote), but at least figure out some details | 22:07 |
| === retoaded is now known as retoaded_afk | ||
| pitti | slangasek: libpdl-stats-perl> hm, we shouldn't "lose" results, and britney also tracks them by-trigger; looking at log files | 22:08 |
| pitti | slangasek: I see two runs for ADT_TEST_TRIGGERS=gsl/2.0+dfsg-1ubuntu1 now -- if you manually triggered once, the other was from britney itself? | 22:21 |
| pitti | slangasek: could it just have been busy queues? | 22:21 |
| pitti | capacity and cloud breakage is continuing problem.. | 22:22 |
| pitti | slangasek: actually there's three results | 22:22 |
| pitti | 2015-11-11 20:09:45, 2015-11-11 19:34:21, and 2015-11-11 19:27:48 | 22:23 |
| pitti | slangasek: so at least the latter was finished before your manual one | 22:23 |
| leezer3 | Looking for a little help here; I appear to have taken over development of an abandoned game, which is available in the Ubuntu repositories, but has a couple of critical bugs, which means it no longer works full-stop for most users. | 22:35 |
| leezer3 | I'm rather unclear as to what/ who I should be talking to to get a patch into the repositories; I've tried mailing the package maintainer, who appears to be MIA, and I've discovered the patch pilot page on the wiki, which has kinda sent me here :) | 22:36 |
| leezer3 | my source is on Github at the minute, and the version that the repos have was behind what I started modifying, so there's a lot of code differences. | 22:37 |
| leezer3 | I don't claim my source is ready for primetime, but I'm looking for help on the process so that when it is, this can be sorted out :) | 22:38 |
| slangasek | pitti: oh. yes it could have been busy queues; the fact that scheduled tests don't show up on autopkgtest.u.c is rather inconvenient... | 23:26 |
| === _salem is now known as salem_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!