| === catbus1 is now known as catbus1-afk | ||
| pitti | Good morning | 03:58 |
|---|---|---|
| pitti | infinity: ah, so the linux -2.2 efi thing could just be rejected? thanks for cleaning up | 03:59 |
| infinity | pitti: if by rejected, you mean accepted, then yes. | 04:01 |
| pitti | infinity: ok | 04:02 |
| Mirv | would there be a core dev around to ack UITK packaging changes? it seems mainly using more default Qt build options and some more documentation/examples. https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff | 05:12 |
| pitti | +export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get CPPFLAGS) | 05:12 |
| pitti | is that actually necessary? this looks redundant | 05:12 |
| pitti | or does the build system not respect CPPFLAGS? | 05:13 |
| pitti | moving the mkdir/cp stuff from dh_install to dh_build seems wrong | 05:14 |
| pitti | this is installation, thus happening under fakeroot; it's only to debian/tmp/, but it still feels like the wrong direction | 05:14 |
| pitti | --fail-missing is now specified twice | 05:14 |
| pitti | Mirv: ^ so, I don't see anything which I'd consider a blocker, just several things which look odd | 05:15 |
| infinity | pitti: The point of the core-dev review is to block on odd. :) | 05:16 |
| infinity | pitti: Don't let 'em be sloppy. | 05:16 |
| pitti | Mirv: oh, and don't call dh_auto_build in override_dh_install (not a change from this version, but that's most definitively wrong) | 05:17 |
| pitti | this might all "work" by chance, but it's utterly confusing and unnecessarily hard to maintain and understand | 05:18 |
| Mirv | pitti: thanks for all the input, I'll bring them to bzoltan/zbenjamin and discuss | 05:24 |
| Mirv | pitti: I'm sure their next question would be "but it was QA granted, can we publish it and fix the issues later by filing a bug now?" | 05:26 |
| Mirv | so I'm just saving time by asking at this point | 05:26 |
| pitti | I'm actually more concerned why this was moved around without giving a rationale in the changelog | 05:27 |
| pitti | building docs in dh_install and installing docs in dh_build is just wrong | 05:27 |
| pitti | so, we know how the "we'll fix it later" goes, but if there's a way to file a bug that will actually stick (milestoning, or assigning to someone, or what not), ok for me | 05:28 |
| Mirv | ok. I'll get answers but file and assign the bug already now for all those question marks. | 05:30 |
| pitti | Mirv: thanks | 05:30 |
| Mirv | thanks to you. | 05:30 |
| Mirv | bug #1481584 filed | 05:35 |
| ubottu | bug 1481584 in ubuntu-ui-toolkit (Ubuntu) "Fix reported packaging question marks / issues in UITK" [High,New] https://launchpad.net/bugs/1481584 | 05:35 |
| infinity | pitti: Did autopkgtest chroots used to have deb-src URIs in sources.list? | 06:00 |
| infinity | pitti: Trying to figure out if the apport regression in vivid is an infrastructure regression or test regression. | 06:01 |
| pitti | infinity: where "used to have" == pre-cloud or the ancient stuff that we had in saucy/trusty? | 06:01 |
| pitti | ah, vivid; hang on | 06:01 |
| infinity | pitti: Although, it passed on cloud infra on Jul 14, started failing on Jul 17... | 06:02 |
| pitti | we used to have deb-src, but this test is for a "sandbox" with its own apt sources, so it shouldn't even matter | 06:03 |
| pitti | infinity: I'll have a closer look | 06:03 |
| infinity | pitti: Not so sure about that. The logs show deb-src being the difference here, I think. | 06:03 |
| infinity | pitti: The successful logs have Source in the initial update, the failures don't. | 06:03 |
| infinity | pitti: Still arguably a broken test, mind you, but yeah. | 06:04 |
| pitti | infinity: ah, so that sounds like a plausible reason then | 06:04 |
| infinity | pitti: Not sure if the spec gives any reason to assume deb-src would be available, but I've not read it end-to-end. | 06:05 |
| pitti | I added this to userdata some weeks ago: | 06:05 |
| pitti | apt_sources: | 06:05 |
| pitti | - source: deb \$MIRROR \$RELEASE restricted multiverse | 06:05 |
| pitti | - source: deb-src \$MIRROR \$RELEASE restricted multiverse | 06:05 |
| pitti | apparently that dropped the main apt sources | 06:05 |
| pitti | (which is supposed to add additional ones only) | 06:06 |
| infinity | pitti: Actually, weirder still, the succesful logs show an apt-get update to start, the newer logs don't. | 06:06 |
| infinity | pitti: So even if deb-src was in sources.list, the lists wouldn't have been downloaded. Unless that's happening before the log starts now. | 06:07 |
| infinity | pitti: Oh. But an update happens way later, and does include Sources. Now I'm just confused. | 06:08 |
| infinity | pitti: and too tired to make sense. | 06:08 |
| infinity | pitti: So I'll go to bed instead. :P | 06:08 |
| pitti | infinity: so e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid/vivid/amd64/a/apport/20150730_003039@/log.gz | 06:11 |
| pitti | Sources is part of apt-get update at the very top, and that's the only update that I see | 06:11 |
| pitti | so, not that | 06:11 |
| * pitti queues for investigation | 06:13 | |
| pitti | wah wah cmake | 06:15 |
| dholbach | good morning | 06:57 |
| pitti | infinity, slangasek: hm, are you binNEWing stuff before builds on all arches are done? (e. g. I was waiting for gmsh/armhf before newing them) | 08:44 |
| om26er | pitti, Hi! is there a way to include and install pypy package along with debs for autopkg test run ? | 08:47 |
| pitti | om26er: your test can do whatever it wants to, including calling pypy or pip install | 08:47 |
| pitti | (not sure what a "pypy package" is) | 08:48 |
| om26er | pypi | 08:49 |
| pitti | ah, ok | 08:49 |
| pitti | om26er: pypy is an actual thing (compiled python), hence my confusion :) | 08:49 |
| om26er | pitti, so the way you temporary install packages on the phone in /tmp ? I was hoping if I could do the same for a source that is not in ubuntu yet. | 08:50 |
| pitti | om26er: pip has a mode to install to $HOME/.local, doesn't it? | 08:50 |
| om26er | pitti, I didn't look into that. Will take a look. | 08:51 |
| ochosi | dpm: ping | 09:03 |
| doko | pitti, when you reassign to release, please set the severity to normal as well | 09:22 |
| pitti | doko: oh, ok; I'll adjust the ones I sent today | 09:22 |
| doko | do you upload these too to unstable? | 09:22 |
| doko | also: block <this issue> by 790756 | 09:22 |
| pitti | doko: no, so far I'm just sending patches and tagging | 09:23 |
| pitti | doko: I included the "block" thingy | 09:23 |
| pitti | doko: I could upload them as 2-day NMUs I figure | 09:24 |
| doko | pitti, but then please don't yet reassign ... the release team wonders what happens, and the package owner doesn't see things anymore | 09:24 |
| pitti | doko: right, I don't reassign (as per our IRC chat a few days ago) | 09:24 |
| doko | yep doing the NMUs would be nice, if all other b-d's are ready | 09:24 |
| pitti | tag 791079 confirmed patch | 09:25 |
| pitti | user release.debian.org@packages.debian.org | 09:25 |
| pitti | usertag 791079 + transition | 09:25 |
| pitti | block 791079 by 790756 | 09:25 |
| pitti | that's what I'm doing right now | 09:25 |
| doko | ahh, I see | 09:25 |
| dpm | hi ochosi, please feel free to ping questions directly | 09:25 |
| pitti | doko: ack, I'll NMU the 6 I did so far; but it's all delayed/2, so I think we should still upload them directly to wily? | 09:25 |
| doko | sure | 09:25 |
| pitti | doko: (and sync them back later) to avoid another 3 days delay | 09:25 |
| ochosi | dpm: sure, just wanted to make sure i don't disturb you doing anything else, also i wanted to quickly pm you if you don't mind (since it's not really a u-dev matter) | 09:25 |
| dpm | ochosi, sure, no need to ask permission to pm, feel free to go ahead :) | 09:26 |
| doko | seb128, Laney: please tell LazyShark that libreoffice is done (armhf build pending) | 09:27 |
| seb128 | doko, k | 09:30 |
| Laney | doko: can you please note in the pad when you see things fixed in debian/NEW? | 09:32 |
| Laney | no point us working on them then | 09:32 |
| doko | Laney, will try, but will be away 'til Monday | 09:33 |
| doko | pitti, Laney: so all transitions were at least tried once until now? | 09:35 |
| pitti | "all transitions"? | 09:35 |
| Laney | I uploaded the rest of the ones from your debian build logs that didn't have symbols files | 09:35 |
| Laney | but we saw yesterday that some things were missing from there | 09:36 |
| Laney | so I can't say it is "all" | 09:36 |
| doko | yeah, but it should be safe, to remove the block-proposed from gcc-5 and see what happens. everything else should be blocked by the new packages | 09:36 |
| pitti | doko: oops, my important->normal change was probably wrong -- this should only be done when reassinging to release@, but we don't do that? | 09:36 |
| Laney | I've been reassigning to release | 09:37 |
| doko | pitti, yep, sorry for the confusion | 09:37 |
| Laney | because the bug told me to | 09:37 |
| Laney | is that not good? | 09:37 |
| doko | if you NMU yes | 09:37 |
| Laney | haven't been | 09:37 |
| pitti | I just NMUed libvsqplitepp (and about to do some others) | 09:37 |
| Laney | and didn't forward the scripted deltas that I uploaded yesterday | 09:37 |
| Laney | doing that individually seems quite daunting :/ | 09:38 |
| pitti | should the bugs be reassigned now? and why? (still sounds a bit strange) | 09:38 |
| Laney | might save that as a debconf task or something | 09:38 |
| pitti | Laney: yeah, I'm only forwarding patches after I fixed the FTBFS, i. e. package specific changes; forwaring a thousand scripted patches seems a bit pointless | 09:38 |
| Laney | NMUing them to speed the transition along in Debian feels like it would be useful though | 09:38 |
| Laney | but there's a risk of false positives without analysis | 09:39 |
| doko | you are allowed to do 2day delayed NMUs. so NMUing and reassigning would be the best | 09:39 |
| doko | be sure that all b-d's are ready | 09:39 |
| pitti | doko: OOI, why reassign in this case? | 09:40 |
| Laney | did someone prune the "appear to be transitioned in Debian" list? | 09:41 |
| pitti | Laney: yes, for the bits that I synced/built/NEWed | 09:41 |
| Laney | ah, great | 09:41 |
| pitti | Laney: there's 3 left which we can't do yet | 09:41 |
| pitti | I left a comment | 09:42 |
| pitti | two of them should be syncable this afternoon | 09:42 |
| Laney | yeah, I see those, just wondered about the rest | 09:42 |
| pitti | well, it's a TODO list -- stuff that's done should just disappear | 09:42 |
| Laney | 05/08 08:35:57 <doko> GCC 5 stuff in NEW: rtmidi rtaudio tinyxml guichan | 09:42 |
| pitti | I'm also pruning the FTBFS and others | 09:42 |
| willcooke | Laney, sladen - hi, did you manage to get that font zip file sorted? | 10:08 |
| pitti | doko: this (ipe) does not look like an ABI break to me: http://paste.ubuntu.com/12005903/ - WDYT? | 10:09 |
| pitti | doko: or is that the __cxx114 thingy? | 10:10 |
| pitti | doko: I was wondering because a rebuild in sid still generates libstdc++6 (>= 4.6) only, not >= 5 | 10:10 |
| Laney | willcooke: not yet I'm afraid, still standing by | 10:11 |
| doko | pitti: the bumped dependency on libstdc++ only appears if you reference any of the new symbols in libstdc++. | 10:11 |
| doko | but the library defines some cxx11 symbols on its own, so yes, I'd say an ABI break | 10:12 |
| pitti | doko: ok, thanks for checking | 10:12 |
| willcooke | Laney, thanks. | 10:12 |
| * pitti goes on with NMUing then | 10:12 | |
| sladen | willcooke: no, was prioritising other actual _potential to block_ stuff | 10:24 |
| willcooke | sladen, nw, any idea of an ETA, or if you can let me or Laney know what needs doing we can have a stab at it | 10:26 |
| doko | wtf, onboard manually depends on every single shared library??? | 10:32 |
| pitti | some build systems just outsmart themselves | 10:39 |
| sidi | Is this the right channel for Unity development? | 10:40 |
| Laney | sidi: #ubuntu-unity | 10:40 |
| sidi | thanks Laney | 10:40 |
| pitti | ah, d-shlibmove -- apparently that needs a --suffix=v5 or so, /me tries | 10:40 |
| doko | pitti, I fixed d-shlibmove, needs --v5 | 10:43 |
| pitti | doko: ah, I used --suffix=v5 | 10:43 |
| doko | hmm, I tried that too ... anyway | 10:44 |
| pitti | /usr/bin/d-shlibmove: [--suffix=v5] is not a valid shared library file name | 10:46 |
| pitti | meh | 10:46 |
| seb128 | hum | 10:47 |
| seb128 | grub-efi-amd64 fails to configure on my wily test laptop | 10:47 |
| seb128 | it bails out on | 10:47 |
| seb128 | "ERROR: cannot determine partition label for rootfs" | 10:47 |
| seb128 | does anyone has an idea how to solve it?. | 10:47 |
| pitti | doko: ah, --v5 is in wily only; I'm trying to fix sid too | 10:50 |
| doko | pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794561 | 10:50 |
| ubottu | Debian bug 794561 in src:d-shlibs "d-shlibmove could use a --v5 option" [Normal,Open] | 10:50 |
| seb128 | hum | 10:52 |
| seb128 | it's upgrade-gru | 10:52 |
| seb128 | it's upgrade-grub which fails on that error | 10:52 |
| pitti | doko: ah, thanks; reading the code, --suffix should work as well; maybe only "--suffix v5", not "--suffix=v5", trying with the former | 10:52 |
| pitti | doko: ah! --suffix v5 works! \o/ | 10:54 |
| doko | I love Jonas too | 10:55 |
| pitti | debian/control.in.in, yummy ;) | 10:56 |
| doko | rbasak, https://bugs.launchpad.net/bugs/1481333 is this seen in -proposed as well? | 10:58 |
| ubottu | Launchpad bug 1481333 in gcc-5 (Ubuntu) "internal compiler error: in final_scan_insn, at final.c:3020" [Undecided,Incomplete] | 10:58 |
| doko | pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794587 | 11:19 |
| ubottu | Debian bug 794587 in libvpb1 "man page is part of both libvbp0 and libvbp1" [Serious,Open] | 11:19 |
| * Laney sees d-shlibmove for the first time | 11:23 | |
| doko | don't take a second look | 11:23 |
| Laney | heh | 11:24 |
| Laney | hm, control.in.in too - pitti, were you talking about ucommon? | 11:25 |
| pitti | Laney: no, libsass | 12:04 |
| pitti | doko: argh, thanks; I'll upload a Conflicts:/Replaces: | 12:05 |
| doko | pitti, as a break to the library uploads, could we walk throught the failing autopkg tests triggered by gcc-5? | 12:06 |
| doko | Laney, pitti: http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/ this was triggered before the GCC change. could you have a look? | 12:09 |
| pitti | doko: looks "just" flaky at first sight, I'll retry a few times | 12:16 |
| pitti | doko: uploaded C/R for vpb-driver, thanks for pointing out | 12:18 |
| pitti | Laney, doko: BTW, do you know whether it's normal that ftp://ftp-master.debian.org/pub/UploadQueue/DELAYED/2-day/ is empty? | 12:21 |
| pitti | dput -e 2 ftp-master succeeded, but I never got any kind of mail from ftpmaster | 12:22 |
| doko | pitti, beware, exiv2 in debian NEW with a different library name. maybe we should merge that (new upstream) | 12:25 |
| pitti | doko: ah yes, quite a bunch of rdepends | 12:30 |
| pitti | doko: we can't download stuff from Debian new, but I can piece it together from packaging svn | 12:30 |
| doko | pitti, please update rdeps in main too after that | 12:31 |
| pitti | ack | 12:31 |
| doko | I'm already running a wily-proposed desktop | 12:31 |
| pitti | added to pad | 12:32 |
| pitti | doko: meh -- they didn't commit 0.25-1 to svn :( | 12:36 |
| pitti | doko: so I guess we'll have to wait for Debian NEW | 12:37 |
| doko | pitti, will appear in incoming soonish | 12:37 |
| pitti | we might get a few rebuilds against v5 by then, so we'll just have to do it again | 12:37 |
| pitti | *shrug* | 12:37 |
| pitti | doko: oh, was it just NEWed? | 12:37 |
| doko | yes | 12:37 |
| pitti | nice | 12:37 |
| pitti | ok, postponing that until it hits incoming, and continuing FTBFS fixing by then | 12:38 |
| pitti | Laney: ok, you stole my color, I switched to red now :) | 12:39 |
| bzoltan_ | pitti: infinity: refering to the UITK packaging issues -> I have addressed all your comments in this MR -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/packaging_fixes_lp1481584/+merge/267012 The CFLAGS exports I used straight from the Qt packages. It is like that in all debian packages too. | 12:45 |
| pitti | bzoltan_: ah, that looks nicer already, thanks | 12:46 |
| pitti | bzoltan_: I still don't understand why this CFLAGS dance is necessary, though | 12:47 |
| bzoltan_ | pitti: thank you for point out ... The CFLAGS I do not get either. | 12:47 |
| Laney | pitti: no mail from DELAYED - I just check https://ftp-master.debian.org/deferred.html after a bit | 13:08 |
| Laney | don't know where the files end up living | 13:08 |
| pitti | Laney: aah! that's what replaces https://people.debian.org/~djpig/delayed.html, thanks! | 13:08 |
| Laney | showing your age there :P | 13:08 |
| pitti | Laney: great timing! at the very second you say that I asked in #debian-release :) | 13:08 |
| Laney | ha | 13:09 |
| pitti | Laney: libdynamicedt3d1.6 wasn't renamed in the octomap source; on purpose, or doesn't the script get along multiple libs? | 13:16 |
| seb128 | slangasek, cjwatson, cyphermox, hey, who is looking after grub issues nowadays? | 13:17 |
| Laney | pitti: The script tries to rename only the packages with changed symbols | 13:18 |
| pitti | Laney: ah, cool | 13:18 |
| pitti | Laney: I'll verify in the (fixed) builds, but good to know | 13:19 |
| Laney | if the test rebuild is to be believed then this looks right | 13:19 |
| Laney | (octomap & octovis) | 13:19 |
| cjwatson | seb128: cyphermox | 13:20 |
| cjwatson | (afaik) | 13:20 |
| seb128 | cjwatson, thanks | 13:20 |
| pitti | Laney: ah! all tmpfails fixed :) | 13:37 |
| Laney | :-O | 13:38 |
| Laney | even n-m/vivid? | 13:38 |
| pitti | Laney: this morning we had tmpfails for all packages with "network" in the name | 13:38 |
| pitti | Laney: *all* | 13:38 |
| pitti | Laney: well, vivid is just a "real" failure now | 13:38 |
| pitti | (it needs the same "disable 80211.a" change that cyphermox applied to wily) | 13:38 |
| pitti | Laney: that was a funny parsing bug of "nova show" (for finding the IP) | 13:39 |
| doko | pitti, http://incoming.debian.org/debian-buildd/pool/main/e/exiv2/ | 13:39 |
| pitti | I wish nova had some --machine-readable thingy instead of having to parse ascii art tables | 13:39 |
| pitti | doko: yay, fake-syncing | 13:39 |
| pitti | doko: I'll upload rebuilds after it published | 13:40 |
| doko | slangasek, Laney, pitti: so geos, spatialite, postgis, gdal have a build-dependency cycle now ... | 13:43 |
| doko | was looking at these to fix autopkg test failures for gcc-5, but running out of time now | 13:44 |
| pitti | doko: geos built fine, WDYM? | 13:44 |
| pitti | oh, you mean the latter 3 have not co-installable build-deps now? | 13:45 |
| doko | yes | 13:46 |
| Laney | doko: looks like you can turn off spatialiate in gdal | 13:53 |
| pitti | meh, exiv2 FTBFS on 32 bit arches | 14:01 |
| pitti | ah, just symbols madness | 14:01 |
| rbasak | doko: that bug doesn't affect MySQL in Ubuntu yet (AFAIK). Upstream reported it - we'll need to wait for them to reply I think. | 14:06 |
| doko | Laney, thanks. and found: https://launchpad.net/ubuntu/+source/opencv/2.4.9+dfsg-1ubuntu5 | 14:07 |
| doko | rbasak, thanks for checking | 14:07 |
| Laney | joyous | 14:07 |
| doko | rbasak, is anybody checking for image installability using wily-proposed? | 14:07 |
| rbasak | doko: I don't think so, no. | 14:08 |
| doko | rbasak, I asked smoser in the past, but never got a reply | 14:09 |
| pitti | Laney: do you happen to know how to untangle a C++ per-arch symbols mismatch like https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz ? | 14:25 |
| pitti | Laney: if so, quick tutorial appreciated (I've never done this) | 14:26 |
| pitti | or anyone C++ savvy ^ | 14:26 |
| rbasak | doko: matsubara is the QA contact on our team. Maybe he knows? He'd be the person to speak to about it anyway but I don't see him online right now. | 14:38 |
| Laney | pitti: ah, is that size_t? | 14:43 |
| pitti | Laney: it's in some "string" class obviously, but apart from that this is just gobbledigok to me :( | 14:43 |
| pitti | Laney: size_t in a string class sounds plausible, though | 14:44 |
| pitti | at least it fails on the three 32 bit arches and succeeds on the three 64 | 14:44 |
| * Laney runs it through c++filt | 14:44 | |
| Laney | GET https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz | zcat | c++filt | vim - # or so | 14:44 |
| * pitti uploads the next FTBFS fix in teh meantime | 14:44 | |
| === vrruiz_ is now known as rvr | ||
| pitti | Laney: do you need a hand with ucommon? (that hasn't changed in a while) | 14:45 |
| Laney | I got confused about it | 14:45 |
| Laney | now d-shlibmove is failing and I didn't get to the bottom of why yet | 14:46 |
| Laney | yeah these look like size_t | 14:46 |
| Laney | I think the state of the art, unless it changed while I wasn't looking, is to use pkgkde-symbolshelper for those | 14:47 |
| Laney | you can do some subst thing so it substitutes the right type per-arch with that | 14:47 |
| Laney | or you can include two versions with the right arch= for each one | 14:47 |
| Laney | (which is obviously more brittle but easier to get going now) | 14:47 |
| pitti | Laney: the .symbols doesn't have any arch=, nor size_t, I wonder how previous versions did that | 14:48 |
| pitti | oh! all symbols say "0.25", so apparently they just added that | 14:49 |
| pitti | isn't there some sane way to put demangled symbols into *.symbols instead of this arch specific mess? | 14:49 |
| Laney | it still demangles to the actual type and not size_t | 14:51 |
| Laney | but yes, you can c++filt them | 14:51 |
| Laney | (c++)"<c++filted thing>" | 14:52 |
| pitti | ah, so that wouldn't even help | 14:52 |
| pitti | Laney: as this is totally new in 0.25-1, would it be okay to drop it temporarily for us and let the DD sort out the symbols? | 14:53 |
| pitti | "this" -> the .symbols file | 14:53 |
| Laney | I saw an example yesterday or so where doko split 32/64 bit specific symbols out into different files and included them | 14:53 |
| Laney | but I can't find it now :( | 14:54 |
| doko | pitti, look if this is managed with the kde symbols helper | 14:56 |
| * pitti looks at omnievents -- no reverse deps, last upload 2011, obsolete stuff -- shouldn't we rather just remove this? | 14:56 | |
| pitti | (I fixed it in wily, wondering whether to NMU or not) | 14:57 |
| pitti | doko: I'd say no, nothing "kde"ish in debian/rules or control | 14:57 |
| pitti | they just added the .symbols file without any changes to debian/rules | 14:58 |
| Laney | pitti: meh, new d-shlibs breaks ucommon | 15:00 |
| Laney | it's added some new and wrong quoting | 15:00 |
| pitti | Laney: new in Ubuntu or new in Debian? | 15:01 |
| pitti | Laney: I tried "--suffix v5" (which works in Debian, for NMUing), and that works; I didn't try the ubuntu specific --v5 | 15:01 |
| Laney | it's a call to objdump which dies | 15:02 |
| Laney | and doesn't with 0.58 | 15:02 |
| === Tm_Tr is now known as Guest98434 | ||
| hallyn | dannf: when you ran test-qemu.py ,did you first go into the scripts/qemu and scripts/libvirt subdirectories and wget the files the readmes say to get? | 15:58 |
| hallyn | maybe i'll post a MR to do that automatically | 15:59 |
| dannf | hallyn: yeah. | 15:59 |
| hallyn | hm | 15:59 |
| hallyn | not good | 15:59 |
| Laney | xnox: did you fix the moc/BOOST_JOIN thing? | 15:59 |
| dannf | its weird - it complained the file wasn't there - but it was | 15:59 |
| dannf | and then the tests ran | 15:59 |
| dannf | w/o the file they didn't | 15:59 |
| dannf | hallyn: i also think its funny that it downloads the key insecurely, the tarball insecurely, then verifies the tarball w/ the key... but i guess it doesn' tmake things *worse* :) | 16:00 |
| hallyn | i assume someone had intended to embed a public key into the bzr tree and neve got around to it | 16:03 |
| dannf | yeah, i guess i could MP that instead of whining | 16:04 |
| hallyn | dannf: fwiw i wont' be able to look at that today i don't think; if you still have trouble tomorrow pls shout | 16:04 |
| dannf | hallyn: ok | 16:05 |
| === catbus1-afk is now known as catbus1 | ||
| pitti | doko, Laney: just in case you wonder, removing libsass from wily-proposed; the DD does not want this transitioned, and there are no rdepends | 16:29 |
| pitti | (also cancelled the NMU) | 16:30 |
| === rbanffy_ is now known as rbanffy | ||
| === a7med is now known as Neo31 | ||
| doko | rbasak, please could you merge libecap? background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791117 | 19:03 |
| ubottu | Debian bug 791117 in src:libecap "libecap: library transition may be needed when GCC 5 is the default" [Important,Open] | 19:03 |
| rbasak | Should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable? | 19:03 |
| rbasak | doko: looking | 19:03 |
| doko | soonish would be good, then we don't need to rename the library package | 19:04 |
| rbasak | kickinz1: Blocking fix for 794536: squid3: FTBS on GCC-5 | 19:04 |
| rbasak | doko: arges is taking it. | 19:05 |
| doko | ta | 19:05 |
| kickinz1 | rbasak, thanks | 19:05 |
| doko | slangasek, Laney, pitti: so renaming all libs first, without rebuilding all rdeps is a good way to find cyclic dependencies ;-P | 19:12 |
| doko | now coming to a solution for postgis/spatialite/gdal | 19:12 |
| doko | Laney, did you make progress with opencv? | 19:12 |
| rbasak | In case it got missed: should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable? | 19:18 |
| rbasak | infinity: ^^ any opinion on that please? | 19:18 |
| rbasak | I'm leaning towards invoke-rc.d but am wondering if there's any existing best practice on that | 19:19 |
| infinity | rbasak: Not sure there's a policy or even established best practice, but in my mind, anything a *maintainer* does should use invoke-rc.d, so a sysadmin can override with policy-rc.d | 19:21 |
| infinity | rbasak: So, that's not just dpkg maintainer scripts, but any script you ship that wants to fiddle with services, including logrotate. | 19:21 |
| infinity | rbasak: Policy might say something sort of like that somewhere, but I don't recall seeing it. | 19:22 |
| infinity | rbasak: /etc/network/if-up.d/ntpdate seems to follow this, for instance. | 19:23 |
| infinity | And openssh-server. | 19:23 |
| rbasak | infinity: understood, with the reasoning. Thanks! | 19:23 |
| infinity | rbasak: So, yeah. invoke away. | 19:23 |
| arges | cyphermox: i see you are having a productive SRU day | 19:24 |
| arges | cyphermox: reviewing a lot of your packages now | 19:24 |
| infinity | rbasak: So, on my system, that would make the logrotate scripts for samba and rsyslog buggy. And probably rightfully so. | 19:24 |
| infinity | rbasak: Eww, and speech-dispatched double-buggy, it calls /etc/init.d/foo directly. | 19:24 |
| infinity | Gross. | 19:25 |
| infinity | rbasak: Thanks, I didn't want to know this. | 19:25 |
| cyphermox | arges: yeah, those are all special magic, don't hesitate to include infinity, he was delegating to me ;) | 19:25 |
| infinity | cyphermox: Half the reason to delegate to you was so I could do the reviews. | 19:26 |
| infinity | arges: So, yeah, if you're not comfy reviewing ppc64-diag, I'll hit it up after breakfast. | 19:26 |
| rbasak | infinity: well, I didn't ask you to look :) | 19:32 |
| rbasak | infinity: rcj is just fixing this kind of thing in freeradius and so I just wanted to make sure that we fix it the right way. | 19:33 |
| infinity | rbasak: I can't help looking. | 19:33 |
| infinity | rbasak: And now I know the world is a little bit less shiny than I hoped. | 19:33 |
| barry | infinity: ping re python-apt and apt (since mvo isn't around and you did the last upload to apt in wily) | 19:34 |
| infinity | barry: I feel like your ping lacks content. | 19:35 |
| barry | infinity: python-apt b-d's on apt (>= 1.0.10) but 1.0.9.10ubuntu6 is in w-p | 19:36 |
| barry | infinity: what's the eta for 1.0.10 in wily? | 19:36 |
| barry | infinity: (sorry, was clicking around ;) | 19:36 |
| infinity | barry: Man, David only uploaded it to unstable two days ago! | 19:37 |
| barry | infinity: it == apt? | 19:37 |
| arges | infinity: ok either way I was just about to look at ppc64-diag | 19:37 |
| infinity | barry: I hadn't had any intention of taking over the merges there, so no ETA. Why did we merge python-apt? | 19:37 |
| arges | infinity: in fact i'll just handle that | 19:37 |
| barry | infinity: dunno! i just started looking at this, and mvo isn't around | 19:38 |
| barry | infinity: ok, no worries, i'll figure something out | 19:39 |
| infinity | barry: Huh. That's fishy. We had a delta, so the sync would have been forced, but I see no mail to -changes telling me who did it. :/ | 19:39 |
| infinity | barry: If it was mvo, I'd expect he plans to do apt as well. | 19:40 |
| barry | infinity: probably/hopefully so | 19:40 |
| infinity | barry: Oh, the delta might be tiny anyway. | 19:41 |
| infinity | barry: Lemme look at it after I (finally) eat breakfast. | 19:41 |
| barry | infinity: ack, thx | 19:41 |
| infinity | barry: Based on David's changelog, 1.0.10 might just be the C++ transition, no scary. Unless his changelog is a lie. | 19:42 |
| barry | infinity: and there's a changelog in pyapt for the gcc transition too | 19:42 |
| infinity | barry: Right. I'll poke this bear with a stick in ~1h. | 19:43 |
| infinity | When my stomach stops with the hate. | 19:43 |
| barry | infinity: i'll wait for the tonal change from stomach roar to bear roar | 19:43 |
| doko | rbasak, arges: accepted libecap. please schedule building the rdepends once the package is published | 19:45 |
| arges | ok | 19:47 |
| doko | infinity, mvo comes back next week. this should have time | 19:47 |
| arges | doko: just to confirm, I need to no-change rebuild on any libecap rdepends | 19:49 |
| doko | arges, yes, but only once you see/can install the package in your own chroot | 19:52 |
| barry | infinity: fwiw, i bump the bd's down to 1.0.9 and python-apt built locally just fine | 19:54 |
| infinity | barry: Yeah, I assumed it would, but may as well keep the sync if merging apt isn't too painful. | 19:56 |
| barry | infinity: +1 | 19:56 |
| infinity | barry: If apt thwarts my efforts, I'll just introduce a python-apt delta. | 19:56 |
| infinity | ypwong: You around? | 20:51 |
| infinity | ypwong: cyphermox and I are considering respinning ubuntukylin 14.04.3 ISOs to fix https://bugs.launchpad.net/ubuntukylin/+bug/1380981 but only if you guys are happy with another build. | 20:53 |
| ubottu | Launchpad bug 1380981 in Ubuntu Kylin "In UEFI mode, default langauge in Ubiquity language chooser is not Simplified Chinese" [Critical,New] | 20:53 |
| Laney | doko: didn't look at opencv | 21:01 |
| doko | Laney, I did =) openexr wasn't rebuilt. took the new upstream from experimental | 21:02 |
| Laney | nice | 21:02 |
| rbasak | infinity: logrotate postrotate script: silently ignore failure on sending reload signal? Logic: if daemon isn't running, failure to send re-open signal isn't a problem. | 21:29 |
| rbasak | infinity: some logrotate scripts do this, but the logrotate manpage examples don't seem to. | 21:29 |
| infinity | rbasak: Been a while since I wrote logrotate stuff, but it really depends on what cron spam you think is justified. | 21:34 |
| infinity | rbasak: If a failed reload could actually be a failure, the admin might like to know that his daemon died overnight. | 21:34 |
| infinity | rbasak: So, sort of depends on the init setup and what you do or don't know about state. | 21:35 |
| rbasak | infinity: for freeradius then, I think the answer is to not fail silently. Though if the sysadmin deliberately wants the service to remain stopped, then he'll get spam. I think that's OK. | 21:35 |
| infinity | rbasak: The canonical example of this from my years in the trenches was fighting with apache logrotate scripts that had to stop/start because of $reasons (reload/graceful didn't DTRT and close all the logs), but because it can take several months to stop a heavily-loaded apache, it might fail to start again. | 21:38 |
| infinity | rbasak: In that case, having the cron spam was invaluable, both to frustrated sysadmins who needed to fix it, and to us because we got notified that our packages sucked. :P | 21:38 |
| Laney | LocutusOfBorg1: You want to use your new powers to transition lucene++ for GCC5? :) | 21:42 |
| * Laney cooks up a diff anyways | 21:43 | |
| hallyn | dannf: fwiw on my system all tests passed with your debdiff | 23:05 |
| hallyn | something funky going on with your vm probably | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!