| === ev_ is now known as ev | ||
| === doko_ is now known as doko | ||
| arges | yes? | 01:54 |
|---|---|---|
| psusi | just saw a question on askubuntu about installing the gdb64 package on amd64 and it wants ot remove a bunch of important packages. It looks like this is an i386 only binary with no multi-arch header, so why is it even coming up as installable from amd64? | 02:26 |
| === ming is now known as Guest41611 | ||
| ari-tczew | infinity: hey, are you gonna to get debootstrap updated in trusty (incl. utopic's script), as well? | 04:12 |
| Logan_ | [13:55:46] <barry> infinity: are you SRU'ing a backport of debootstrap into trusty (for the utopic symlink)? | 04:12 |
| Logan_ | [14:00:56] <infinity> barry: I hadn't prepped one but, yes, I should do so for all supported releases. | 04:12 |
| pitti | infinity: yes, we found out why, missing .result files; we have them now, but they are broken | 04:15 |
| ScottK | ari-tczew: It's in the queue for ubuntu-sru review. | 04:27 |
| pitti | infinity: so what needs to happen now is to roll out current lp:auto-package-testing to tachash and poke all the jenkins jobs to update themselves; I can't do that unfortunately, needs jibel | 04:47 |
| === work_alkisg is now known as alkisg | ||
| jayaura | I believe this is a proper channel to ask. How do I get information on a kworker thread? I hdd is continuously being written by a kworker every second. I disabled journalling. | 05:41 |
| jayaura | How can i get more info on this kworker? On who's behalf is it working ? | 05:42 |
| jayaura | And, oh yes I'm on trusty | 05:42 |
| jayaura | its /proc/<TID>/stack doesnt give any useful information. | 05:45 |
| jayaura | [<ffffffff810846f1>] worker_thread+0x1d1/0x410 | 05:45 |
| jayaura | [<ffffffff8108b312>] kthread+0xd2/0xf0 | 05:45 |
| jayaura | [<ffffffff8172637c>] ret_from_fork+0x7c/0xb0 | 05:45 |
| jayaura | [<ffffffffffffffff>] 0xffffffffffffffff | 05:45 |
| alkisg | Hi, in 12.04+ the keyboard layout switching is managed by unity-settings-daemon instead of XKB. Due to Xorg limitations, unity-settings-daemon doesn't get notified when the layout switching shortcut is pressed inside full-screen applications that grab the keyboard (e.g. LP bug #388547). | 06:35 |
| alkisg | The result is that now that apps like `tuxpaint --fullscreen` etc are completely unusable for non-latin environments. | 06:35 |
| alkisg | In 12.04 we did manage to work around that issue by telling gnome not do manage the keyboard layout, but allow XKB to do it. In 14.04 that's not doable anymore because of unity-settings-daemon regressions. | 06:35 |
| ubottu | Launchpad bug 388547 in X.Org X server "Volume keys don't work inside a full-screen game" [Medium,Confirmed] https://launchpad.net/bugs/388547 | 06:35 |
| alkisg | My question is, if I spend a fair bit of time trying to file bugs and send patches in that direction (let XKB manage the keyboard), is Ubuntu willing to accept them even if Gnome does not? Or should I try to solve that upstream with Gnome first? | 06:35 |
| dholbach | good morning | 06:55 |
| GunnarHj | dholbach: Hi Daniel! | 07:56 |
| dholbach | hi GunnarHj | 07:58 |
| GunnarHj | dholbach: Thanks for your help yesterday with bug 1310738. | 07:58 |
| ubottu | bug 1310738 in Ubuntu "Please sync svtplay-dl from debian unstable" [Wishlist,Fix committed] https://launchpad.net/bugs/1310738 | 07:58 |
| GunnarHj | dholbach: Is there any chance that it can be queued to trusty as well, or would that need to be some kind of SRU? | 07:58 |
| dholbach | GunnarHj, hum - not sure how we go about adding new packages to stable releases | 07:59 |
| dholbach | ^ does anyone know? pitti maybe? | 07:59 |
| pitti | dholbach: it either needs to be synced to trusty-proposed *only* and then binary-copied to unicorn (not the usual approach though), or synced to utopic and uploaded as ~trusty to trusty-proposed (the usual approach) | 08:01 |
| pitti | GunnarHj: ^ | 08:01 |
| GunnarHj | dholbach, pitti: Thanks pitti. Sounds like it would be easiest then to remove it from the utopic queue and queue it to trusty instead. | 08:02 |
| pitti | the SRU team might still insist on building the utopic sync with the utopic tool chain | 08:05 |
| GunnarHj | pitti: Is "and uploaded as ~trusty to trusty-proposed" something else (aka easier) than the SRU process? | 08:06 |
| pitti | GunnarHj: no, that is the SRU process (and it's an SRU either way) | 08:08 |
| GunnarHj | pitti: Ok, I see. So then I suppose I'd better wait until it gets approved to utopic, and then SRU it. | 08:08 |
| GunnarHj | dholbach: ^ So I just wait and apply for an SRU later on. | 08:10 |
| dholbach | ok cool | 08:11 |
| dholbach | brb | 08:11 |
| dholbach | @pilot on | 08:26 |
| udevbot | (pilot (in|out)) -- Set yourself an in or out of patch pilot. | 08:26 |
| dholbach | @pilot in | 08:26 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, dholbach | ||
| pitti | cjwatson, infinity: is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html stuck or just busy? | 09:05 |
| cjwatson | pitti: It only cycles when the archive changes, normally | 09:22 |
| cjwatson | (Which is a slight problem for autopkgtests, but usually the archive is busy enough that it doesn't matter ...) | 09:23 |
| cjwatson | pitti: Do you need a manual run? | 09:23 |
| pitti | cjwatson: ah, ok | 09:23 |
| pitti | cjwatson: we just fixed a couple of autopkgtest bugs and the results files (which were making everything appear as RUNNING) | 09:23 |
| cjwatson | pitti: OK, let me run it manually | 09:23 |
| pitti | cjwatson: we just retriggered the worls, so maybe in an hour or so, when we have a bunch of results? | 09:23 |
| pitti | world, too | 09:23 |
| cjwatson | Oh, well, I already started it | 09:24 |
| cjwatson | But sure | 09:24 |
| dholbach | seb128, do you know if there is a reason we never updated gnome-bluetooth? | 09:46 |
| seb128 | dholbach, "never"? | 09:46 |
| dholbach | sorry, I meant "since 3.8.something" | 09:46 |
| seb128 | dholbach, the newer versions require bluez5 | 09:46 |
| dholbach | ahhh ok | 09:46 |
| seb128 | which is a big transition | 09:46 |
| seb128 | why? | 09:46 |
| seb128 | do you need something from 3.10? | 09:47 |
| dholbach | I was just looking at a SRU bug regarding a microsoft mouse or keyboard | 09:47 |
| seb128 | k | 09:47 |
| dholbach | 3.12 | 09:47 |
| seb128 | we can probably backport selected changes | 09:47 |
| seb128 | but updating is blocked on bluez | 09:47 |
| dholbach | and I helped fix a bug like that some time ago already | 09:47 |
| dholbach | ok, I see | 09:47 |
| dholbach | makes sense | 09:47 |
| seb128 | if that's a list of devices in some xml/test list, we should backport the update | 09:48 |
| seb128 | though I think I remember they slightly changed the format, so we might need to tweak or backport code changes as well | 09:48 |
| dholbach | no worries - I'll just take care of the single fix right now | 09:48 |
| seb128 | thanks | 09:49 |
| dholbach | seb128, do you know if anyone had a look at bluez5 already? | 09:50 |
| seb128 | dholbach, https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1162781 | 09:50 |
| ubottu | Launchpad bug 1162781 in bluez (Ubuntu) "bluez package out of date, 5.3 is available" [Wishlist,Triaged] | 09:50 |
| dholbach | aha! | 09:50 |
| dholbach | thanks | 09:50 |
| seb128 | yw | 09:50 |
| dholbach | seb128, you still know bug numbers by heart! :) | 09:50 |
| seb128 | that's likely going to happen this cycle | 09:50 |
| seb128 | dholbach, lol, I still use the awesome bar in an efficient way rather ;-) | 09:51 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| doko | pitti, jibel: are gcc-4.9 autopkg tests really running= | 10:00 |
| doko | ? | 10:00 |
| cjwatson | pitti: Oh, proposed-migration crashed | 10:05 |
| cjwatson | In adt-britney | 10:05 |
| cjwatson | pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2014-04-25/09:23:43.log | 10:05 |
| cjwatson | doko: ^- hence out of date | 10:06 |
| jibel | cjwatson, fixed in r341 | 10:19 |
| cjwatson | pulled, thanks | 10:20 |
| cjwatson | rerunning | 10:21 |
| jibel | doko, test crashed, re-running | 10:31 |
| cjwatson | pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html - happier? | 10:33 |
| doko | jibel, the subversion fail looks like an infrastructure problem | 10:40 |
| pitti | cjwatson: thanks; we might need a re-run in a bit | 10:45 |
| pitti | doko: you mean the libapache2-mod-svn install failure? | 10:46 |
| pitti | doko: that looks like the kind of transient failures with arches being out of sync, I'll retry it | 10:46 |
| doko | what should be out-of-sync at this time? | 10:49 |
| doko | cjwatson, infinity: any reason to keep the general freeze block? | 10:50 |
| doko | ahh, ruby-defaults is in place | 10:52 |
| pitti | doko: sorry, not out of sync; the postinst failed, not depends: | 10:54 |
| cjwatson | doko: I'm waiting for us to be sure of the autopkgtest stuff before dropping it | 10:57 |
| doko | cjwatson, sure, but libreoffice seems to be bit oversized for a test of libgcc1 ... | 10:58 |
| cjwatson | I mean in general | 10:58 |
| cjwatson | Like, making sure that we're actually picking up failures, which we weren't earlier | 10:59 |
| pitti | cjwatson: I think now-ish would be a good time for re-running britney; the queue is empty now, just testing a few stragglers | 10:59 |
| doko | cjwatson, sure, but how can you see this while the general block request i still in place? | 10:59 |
| pitti | to see the pass/fail/running for gcc | 10:59 |
| pitti | oh, no cdbs merge to do this cycle -- a first! | 11:00 |
| pitti | tribute to dh 9, I guess :) | 11:00 |
| cjwatson | doko: autopkgtest output is visible even with a block | 11:00 |
| cjwatson | pitti: running | 11:00 |
| pitti | doko: hmm, so both https://jenkins.qa.ubuntu.com/job/utopic-adt-subversion/3/ARCH=amd64,label=adt/console and https://jenkins.qa.ubuntu.com/job/utopic-adt-subversion/3/ARCH=i386,label=adt/console still fail in libapache2-mod-svn's postinst | 11:21 |
| * pitti sees if he's got enough bandwidth in the train to try and reproduce in a schroot | 11:22 | |
| pitti | ... meh, slow | 11:26 |
| === dayangkun is now known as dayangkun_afk | ||
| pitti | cjwatson: mind running britney again? everything except apport and eglibc has finished | 11:57 |
| pitti | there's still an awful lot of RUNNING on current excuses; I wonder if it's just out of date, or our .result files are still buggy | 11:57 |
| jibel | pitti, I think that the first run from this morning with the buggy output | 11:58 |
| jibel | pitti, I'll retry unar to verify | 11:59 |
| pitti | e. g. ceph is PASS, unar's test never succeeded (also in trusty), it's broken | 11:59 |
| pitti | jibel: no, cjwatson restarted it an hour ago | 11:59 |
| pitti | jibel: thanks (can't look at logs, keeps hanging) | 12:00 |
| jibel | pitti, but unar for example didn't run since 0701UTC | 12:00 |
| jibel | which before the fix | 12:00 |
| jibel | +is | 12:00 |
| pitti | ah right, I misremembered; https://jenkins.qa.ubuntu.com/job/trusty-adt-unar/? is all green | 12:01 |
| jibel | pitti, it's all red but marked running | 12:02 |
| pitti | jibel: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-unar/5/ARCH=i386,label=adt/console doesn't look like an infrastructure problem, though | 12:02 |
| pitti | jibel: perhaps missing dependency? | 12:02 |
| pitti | (which was installed in the bigger trusty VMs) | 12:03 |
| jibel | pitti, it fails because there is an error on stderr "Unable to create time zone ..." | 12:04 |
| pitti | yes, that's the error | 12:05 |
| pitti | or rather, failure | 12:05 |
| jibel | pitti, isn't it because the base VM is provisioned differently than in trusty? | 12:06 |
| cjwatson | pitti: It ran by itself 12 minutes ago - is that enough? | 12:06 |
| pitti | jibel: yes, surely; it's certainly not something liek a missing allow-stderr, as otherwise it would have failed ealier, too | 12:06 |
| pitti | cjwatson: yes, I think so | 12:07 |
| pitti | jibel: so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still has a lot of RUNNING for stuff which finished; still something wrong with *.results? | 12:07 |
| jibel | pitti, that's all the tests that have been triggered before 0700 | 12:09 |
| jibel | pitti, I re-ran unar to check if reconciliation is correct now and will do the other if it's fine | 12:10 |
| pitti | jibel: oh, ok; so we'll need to re-run ceph & friends? | 12:10 |
| jibel | pitti, in utopic VM /etc/timezone starts with a comment, is it valid? | 12:18 |
| jibel | pitti, if it is then it is a bug in unar testsuite | 12:19 |
| pitti | jibel: ah, systemd's timedatectl also fails, I'm currently looking at that | 12:19 |
| jibel | pitti, http://paste.ubuntu.com/7329429/ | 12:20 |
| pitti | jibel: hm, given we ship that kind of file in cloud images, I guess/hope it is.. | 12:20 |
| pitti | jibel: ah, in run-adt-test we copy the host's timezone into the VM, so we didn't notice | 12:21 |
| pitti | or rather, we set "timezone: $TZ" there, while adt-buildvm-ubuntu-cloud just hardcodes "timezone: Etc/UTC" | 12:23 |
| jibel | pitti, unar thinks otherwise. I added a comment in /etc/timezone and it returns a warning | 12:24 |
| jibel | ⟫ unar foo.zip | 12:24 |
| jibel | foo.zip: | 12:24 |
| jibel | Unable to create time zone for name: '# Created by cloud-init v. 0.7.5 on Thu, 24 Apr 2014 14:03:29 +0000 | 12:24 |
| pitti | yes, timedatectl also fails on that | 12:25 |
| pitti | actually no, it doesn't stumble over the comment, timedatectl is something else | 12:26 |
| pitti | right, I need to filter out comments in that test | 12:27 |
| pitti | ok, fixed in systemd | 12:29 |
| pitti | jibel: I'm still not sure whether comments are legit there (and frankly it seems like unnecessarily making things hard for programs) | 12:30 |
| pitti | jibel: but I think it's a good idea to copy the host's timezone like in run-adt-test, I'll do that | 12:30 |
| kirkland | infinity: doh, thanks | 12:32 |
| pitti | jibel: filed bug 1312701, will do that when I have bandwidth again (need cloud image for testing) | 12:34 |
| ubottu | bug 1312701 in autopkgtest (Ubuntu) "VM builds: Copy host's timezone" [Medium,In progress] https://launchpad.net/bugs/1312701 | 12:34 |
| jibel | pitti, so for unar the problem is in NSTimeZone.m in gnustep-base which loads /etc/timezone in a string and assumes it is the timezone. | 12:37 |
| * zyga sees objc and wonders what happens in #ubuntu-devel | 12:39 | |
| kirkland | infinity: thanks a lot for that; fix released | 12:40 |
| cjwatson | pitti,jibel: So is this just test setup / individual test suite problems, and we're confident that the p-m integration is working now? | 12:40 |
| === ikonia is now known as Guest8168 | ||
| jibel | cjwatson, I'm checking that tests marked RUNNING are leftover from this morning and going through the list of failures to confirm if they are problems in the testsuite or not | 12:45 |
| rbasak | Where can I get old Debian binaries - that were in sid but now superceded and never released? I'd like to reproduce an upgrade bug. | 12:49 |
| rbasak | Or do I need to rebuild them? | 12:49 |
| cjwatson | snapshot.debian.org is your best bet | 12:50 |
| rbasak | Ah - thanks. | 12:50 |
| === Guest8168 is now known as ikonia | ||
| xnox | cjwatson: jibel: so comparing http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/ and http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ there are "Red" tests in Trusty that are not at all present in "Utopic" view. Don't we want to trigger all tests against utopic, to have a baseline? | 12:59 |
| xnox | eg cherrypy3, bzrtools missing, unless i'm failing at jenkins navigation. | 12:59 |
| dholbach | @pilot out | 13:00 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox | ||
| zyga | hey, I just got http://paste.ubuntu.com/7329886/ (aptsources.distro.NoDistroTemplateException) | 13:36 |
| zyga | I assume that's just missing integration, is that something I can easily patch locally? | 13:37 |
| zyga | pitti: ^^ maybe you would know | 13:38 |
| * zyga looks at apt sources | 13:38 | |
| xnox | zyga: /usr/share/python-apt/templates/Ubuntu.info is not updated yet. | 13:38 |
| zyga | ah, thanks | 13:38 |
| xnox | zyga: you can just use "devel" instead on utopic, until fixed. | 13:39 |
| zyga | xnox: thanks | 13:39 |
| xnox | although that also has other caveats. | 13:39 |
| zyga | xnox: I noticed you uploaded a few packages to utopic yesterday | 13:39 |
| zyga | xnox: can I just patch that file inline quickly? | 13:40 |
| xnox | zyga: so 0.9.3.6 from unstable already has utopic. | 13:40 |
| * zyga looks | 13:40 | |
| xnox | zyga: so we just need that. | 13:40 |
| zyga | xnox: is that in proposed yet by any chance? | 13:41 |
| xnox | zyga: no it's nowhere at the moment. | 13:41 |
| * zyga gets the package from sid then | 13:41 | |
| zyga | xnox: I don't see 0.9.3.6 anywhere in sid, am I missing something? | 13:42 |
| xnox | zyga: hence "nowhere at the moment" =) http://packages.qa.debian.org/p/python-apt.html it got uploaded < 6h ago | 13:44 |
| xnox | zyga: and you know debian doesn't do dinstall every 5 minutes. | 13:44 |
| zyga | yeah | 13:44 |
| zyga | ok | 13:44 |
| roadmr | cgregan: want to join? if you'd rather not on account of feeling not too well, it's ok: https://plus.google.com/hangouts/_/calendar/YXJhLnB1bGlkb0BjYW5vbmljYWwuY29t.qdr2voggco0i1nc07alp84mokk | 14:02 |
| tkamppeter | mdeslaur, jdstrand, I have released cups-filters 1.0.53 with some security fixes, see https://bugs.linuxfoundation.org/show_bug.cgi?id=1204, https://bugzilla.novell.com/show_bug.cgi?id=871327. | 14:18 |
| ubottu | bugs.linuxfoundation.org bug 1204 in cups-filters "cups-browsed: unsupported BrowseAllow value lets cups-browsed accept from all hosts" [Major,Resolved: fixed] | 14:18 |
| ubottu | bugzilla.novell.com bug 871327 in Audits "AUDIT-0: cups browsed (code injection: CVE-2014-2707)" [Normal,New] | 14:18 |
| rsalveti | xnox: I updated bug 1305315 and the issue is that the linker binary, created with our own toolchain, contains a procedure linkage table, when it shouldn't | 14:21 |
| ubottu | bug 1305315 in gcc-i686-linux-android (Ubuntu) "Android container fails to start when built with the gcc-i686-linux-android toolchain" [Undecided,New] https://launchpad.net/bugs/1305315 | 14:21 |
| rsalveti | xnox: the linker itself can't have any plt | 14:21 |
| rsalveti | now I need to find out how to debug this issue specifically, and understand why our toolchain is generating the plt for the linker binary | 14:22 |
| xnox | rsalveti: yeah i saw the email updates, thanks a lot for debugging this. i have been dissecting aosp toolchain builds and there are a few patches and build-options that may be related to this. | 14:22 |
| rsalveti | xnox: any patch or option you think we should try? | 14:23 |
| rsalveti | if you have the links as well, that might be useful | 14:23 |
| xnox | rsalveti: they don't however do a bootstrap, so it's a bit different (they use prebuild bionic.so =/) | 14:23 |
| rsalveti | xnox: right, saw that as well | 14:23 |
| pitti | jibel: in the train I updated adt-virt-qemu to copy the host's timezone; I roll that out now so that unar and friends will work | 14:33 |
| cjwatson | pitti: Is that the last bit (ish)? It'd be nice to be able to open | 14:36 |
| jdstrand | tkamppeter: thanks | 14:36 |
| cjwatson | jibel: How goes the audit? | 14:36 |
| jibel | cjwatson, http://paste.ubuntu.com/7330086/ is the list of tests potentially failed because of the new testing env. I'm fixing the 2 first points. I am not sure about u-drivers-common and need a review from pitti if he hasn't already done so | 14:42 |
| caribou | infinity: is it normal that lintian on Debian build (makedumpfile) complains that ppc64el is an unknown architecture ? | 14:43 |
| caribou | infinity: this is to remove the remaining delta b/w ubuntu & debian for makedumpfile | 14:43 |
| ScottK | doko: FYI, the ruby2.1 maintainer accepted the changes I needed to make to get it to build in Ubuntu for Debian and the resulting sync is waiting in the queue. | 14:44 |
| cjwatson | caribou: Yes, we haven't got round to teaching lintian about ppc64el yet; you can safely ignore that | 14:46 |
| caribou | cjwatson: ok, thought so but just wanted to be sure; thanks | 14:46 |
| cjwatson | jibel: OK, none of those feel like opening blockers to me - would you agree? | 14:48 |
| pitti | jibel: rolled out, restarting systemd and unar | 14:49 |
| infinity | caribou: Err, which version of lintian? | 14:50 |
| infinity | caribou: That should be fixed in both sid and trusty. | 14:50 |
| caribou | infinity: lemme check | 14:50 |
| caribou | infinity: 2.5.10.3 | 14:51 |
| infinity | caribou: A version not shipped in any Ubuntu or Debian release. Well done. | 14:51 |
| infinity | caribou: Anyhow, 2.5.22 understands what ppc64el is, from trusty, sid, jessie, and wheezy-backports. | 14:52 |
| caribou | infinity: paste.ubuntu.com/7330345/ | 14:53 |
| caribou | infinity: don't ask me where it comes from then | 14:53 |
| infinity | caribou: That chroot needs an upgrade? :P | 14:54 |
| infinity | lintian | 2.5.22.1 | jessie | source, all | 14:54 |
| infinity | lintian | 2.5.22.1 | sid | source, all | 14:54 |
| infinity | caribou: Alternately, ftp.fr could be months out of date, but that seems unlikely. | 14:54 |
| caribou | infinity: most probably yes, I'm not up to date on my Debian VMs as I am with Ubuntu | 14:54 |
| xnox | caribou: from France? | 14:54 |
| caribou | xnox: yeah, that's where I live | 14:55 |
| jibel | cjwatson, I agree | 14:55 |
| xnox | caribou: =)))) bad joke for "where it comes from" | 14:55 |
| caribou | xnox: :) | 14:55 |
| pitti | jibel: ah, how did you whitelist linux? use a different -o option? (instead of /run/shm/) | 14:56 |
| cjwatson | infinity: Anything else you know of before we open, given that autopkgtest should be OK now? | 14:56 |
| pitti | jibel: I'll look into the $HOME thing | 14:56 |
| xnox | caribou: in my ~/.sbuildrc i have "$run_lintian = 1;" that way lintian is run at the end of build with the right and up-to-date lintain, e.g. sid's at the end of sid build, precise at the end of precise build etc. | 14:56 |
| cjwatson | Oh, I guess we should wait for the latest binutils to finish | 14:56 |
| caribou | xnox: thanks; I'll take note of that | 14:57 |
| infinity | cjwatson: If autopkgtest is okay, and doko signed off on his gcc-4.9 test results, I think we're good to open 'er up. | 14:58 |
| cjwatson | infinity: ppc64el/lintian> ah, I was assuming that because the table of file(1) output wasn't up to date that the rest wasn't either; OK | 14:58 |
| infinity | doko: Were you happy with your gcc-4.9 tests? | 14:58 |
| doko | I always am | 14:58 |
| infinity | cjwatson: lintian was just ages behind on a dpkg data import, we got that fixed in .22 | 14:59 |
| jibel | pitti, you built the base VMs with the default disk size? | 14:59 |
| cjwatson | infinity: I definitely want to get binutils consistent first, but that shouldn't take long | 14:59 |
| pitti | jibel: 4 GB, yes; can rebuild with a bigger one, but I thought that's what we used in the previous system too? | 14:59 |
| cjwatson | infinity: But I guess we can drop the block-all source, leave things frozen until binutils is done, and then open | 15:00 |
| infinity | doko: I didn't mean "are you generally content", I meant "did you look at and sign off on the testsuite output you were going to look at earlier" :P | 15:00 |
| doko | yes, they are ok, besides the usual fall-out for the hardening default flags | 15:01 |
| === negronjl is now known as negronjl-afk | ||
| infinity | doko: Kay, cool. Thanks. | 15:01 |
| * cjwatson removes the freeze block | 15:02 | |
| k1l | hi there. i see some confusing information about the EOL of 12.10. was it the 18th april or is it some other date? | 15:02 |
| * infinity wonders what's up with that subversion adt failure... | 15:03 | |
| infinity | rbasak: Can you look at that? | 15:03 |
| infinity | k1l: I'll send out an email today. It is extended by a tiny bit to give some overlap and unwind confusion between the 18mo->9mo support cycle change. | 15:04 |
| infinity | k1l: But I don't mind people pretending it's already EOL and upgrading today. :P | 15:05 |
| k1l | infinity: ok. there was some info ( idont get the source anymore) that it was the 18th april. i am fine with it already beeing EOL :) | 15:06 |
| infinity | doko: Your gnat is unbuildable in the archive (build-deps on a version that doesn't exist). | 15:19 |
| infinity | doko: 4.6, that is. | 15:20 |
| doko | infinity, yeah, won't fix anymore | 15:21 |
| doko | 4.9 looks fine | 15:21 |
| kees | we need to turn on -fstack-protector-strong by default in gcc-4.9 :) | 15:25 |
| seb128 | slangasek, hey | 15:30 |
| seb128 | slangasek, you know freetype best around, do you think you could have a look to https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1310728 and https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1310017 | 15:31 |
| ubottu | Launchpad bug 1310728 in freetype (Ubuntu) "face_flags overridden, leading to double free" [High,Triaged] | 15:31 |
| ubottu | Launchpad bug 1310017 in gnome-settings-daemon (Ubuntu) "freetype 2.5.x broke rendering of the default Korean font" [Undecided,Confirmed] | 15:31 |
| seb128 | slangasek, they both point to an upstream commit each (the second needs small changes to apply correctly) | 15:31 |
| seb128 | slangasek, they seem issues worth trying to fix in the LTS, but I don't know enough about freetype to be confident uploading those (though I guess I could do basic testing and throwing it to proposed and see how it goes) | 15:32 |
| infinity | kees: Is anyone else planning on using -strong by default, so we don't bear the sole burden of upstreaming fixes? | 15:58 |
| infinity | kees: (Sounds like the sort of thing SUSE might do, for instance...) | 15:58 |
| rbasak | infinity: looking | 16:01 |
| infinity | rbasak: The failure isn't in the tests, but actually in libapache2-mod-svn being installed. Which could be a testbed issue, or could be a dire critical bug in subversion or apache2. :P | 16:02 |
| infinity | rbasak: Given the latter, definitely worth looking into. | 16:03 |
| rbasak | ack | 16:03 |
| kees | infinity: no one has 4.9 yet | 16:04 |
| kees | infinity: but, fwiw, on a tiny subset of packages, chromeos has seen no problems. | 16:05 |
| rbasak | Hmm. This dep8 test looks familiar :) | 16:05 |
| rbasak | infinity: AFAICT, there's no problem in the archive itself. I can't make it break. | 16:06 |
| infinity | rbasak: And, yet... https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-subversion/3/ARCH=amd64,label=adt/artifact/results/log | 16:07 |
| rbasak | Yeah | 16:07 |
| rbasak | Any idea why the log appears a bit corrupt? | 16:07 |
| infinity | Does it? | 16:07 |
| rbasak | Line 31 | 16:07 |
| rbasak | Uh | 16:07 |
| rbasak | Line 287 | 16:08 |
| rbasak | Relatively numbering won't help :) | 16:08 |
| infinity | rbasak: Well, that's the failure I'm talking about. :P | 16:08 |
| rbasak | Or perhaps that's just stdout/stderr recombining wrong | 16:08 |
| infinity | Yeah. | 16:09 |
| infinity | i386 seems to fail similarly, though the log breaks differently. | 16:09 |
| rbasak | http://paste.ubuntu.com/7330782/ is what I just tried (amd64 in lxc) | 16:09 |
| rbasak | I did a dist-upgrade to utopic first | 16:09 |
| rbasak | Not precisely the same as the test environment, but I can't see why it would be any different if there's a bug in the archive. | 16:10 |
| infinity | Weirdly, I get a much larger set to install when I do it locally. | 16:10 |
| infinity | I guess the adt chroots aren't as clean as mine. | 16:11 |
| infinity | And yeah, doesn't break here. Bother. | 16:11 |
| infinity | pitti: HALP. | 16:11 |
| * ogra_ sees bug 997737 and senses the next referendum dawning | 16:12 | |
| ubottu | bug 997737 in ubiquity (Ubuntu) "Detroit is not in Canada, 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/997737 | 16:12 |
| rbasak | Unless it's an ordering thing. | 16:12 |
| infinity | ogra_: Bah, close enough. | 16:15 |
| ogra_ | :) | 16:16 |
| infinity | pitti: I can't reproduce https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-subversion/3/ARCH=i386,label=adt/artifact/results/log | 16:17 |
| infinity | pitti: Is there any way of reproducing the exact state (a package list of installed packages in that environment might help, as well as the apt cmdline that I wish was echoed to the logs but isn't) | 16:18 |
| infinity | jibel: ^ | 16:18 |
| jibel | infinity, I'm on it, I can reproduce it in the lab with autopkgtest/run-from-checkout subversion --- qemu cache/disks/adt-utopic-amd64-cloud.img | 16:24 |
| infinity | jibel: Also, how do I go about getting the right creds/access to retry jobs, so I don't keep bugging other people? | 16:25 |
| infinity | (Looks like a bunch failed due to a network blip or something causing DNS resolution failures) | 16:26 |
| jibel | infinity, someone playing with interfaces on one of the machine. I brought it offline | 16:28 |
| rbasak | infinity, jibel: I can't see why libapache2-mod-svn.postinst might fail, but if it does fail, it looks like it'll fail silently. | 16:30 |
| rbasak | Doesn't look like it could be anything but apache2 packaging (dh_apache2 etc) if it is a bug there. I can't see one. | 16:31 |
| infinity | rbasak: From the mangled output, it looked more likely that apache2 (or apache2-data) is failing... | 16:31 |
| rbasak | infinity: right, but see the last few lines. | 16:31 |
| infinity | But it's hard to tell, and without a reproducer I can play with locally, a bit of a mystery. | 16:31 |
| rbasak | That makes me pretty sure it's libapache2-mod-svn.postinst. And that fits the (broken) line 287. | 16:32 |
| infinity | Yeah, perhaps. | 16:32 |
| rbasak | infinity, jibel: reproduced. I duplicated the unpack and configure ordering. I'll dig further. | 16:37 |
| slangasek | seb128: I know enough about freetype to not be confident in any updates; please just do what you think is best :) | 16:38 |
| seb128 | slangasek, ok | 16:38 |
| infinity | mvo: Does that double-seek bug in apt need to be backported to trusty? | 16:54 |
| infinity | mvo: (Is that what was responsible for my sid chroots constantly failing to download Packages.xz sanely?) | 16:55 |
| mvo | infinity: that would be possible, I have prepared a backport to trusty with it | 16:55 |
| mvo | infinity: was collecting some more | 16:55 |
| mvo | fixes | 16:55 |
| infinity | mvo: Sure, it's probably not critical, but since the changelog claims it affects bzip as well (which is our default), I assume it's only a matter of time before I see it on trusty like I was seeing in sid... If that was the bug causing my issue. :P | 16:56 |
| mvo | infinity: not sure if thats the case, but I will upload a fix nevertheless probably later tonight | 16:59 |
| mvo | together with a fix for the apt tab completion | 16:59 |
| mvo | but gtg for dinner first :) | 16:59 |
| * mvo waves | 16:59 | |
| infinity | mvo: Happy eating. I need breakfast, thanks for the reminder. :) | 16:59 |
| mvo | haha | 16:59 |
| mvo | happy eating to you as well then | 17:00 |
| rbasak | infinity: it's a bug in apache2 packaging. Reproduced on sid, too. I'll file bugs. | 17:09 |
| rbasak | In the meantime, I don't see an easy workaround (or a trivial solution to the bug). | 17:09 |
| infinity | rbasak: Huh. Weird that it never tripped until now. :/ | 17:10 |
| infinity | rbasak: I guess I'll just ignore the failure for now, since it seems touchy to reproduce. | 17:10 |
| rbasak | It happens only if apache2 is unpacked and not configured when libapache2-mod-svn is configured. | 17:10 |
| infinity | rbasak: That's a prefectly reasonable state to expect your deps to be in. | 17:10 |
| rbasak | libapache2-mod-svn wants to enable dav_svn, which depends on dav, which is supplied by apache2 but not enabled. | 17:10 |
| infinity | rbasak: The obvious solution to that would be to make a2invoke or whatever it's called be a trigger. | 17:11 |
| infinity | rbasak: So all the calls run at the end of the dpkg run, instead of in postinst. | 17:11 |
| rbasak | infinity: that would make any real problems fail in trigger though. Also, aren't triggers sort of optional, in that if dpkg decided to run triggers at different times, the bug would still occur? | 17:12 |
| infinity | rbasak: The broken (and easy) solution would be to change all the deps to pre-deps. Please warn them against that, as it makes apt's life WAY harder. | 17:12 |
| rbasak | Well, libapache2-mod-svn doesn't even depend on apache2. | 17:12 |
| infinity | Oh! | 17:12 |
| rbasak | It only tries to enable the module if it thinks that it should (because apache2 is "installed") | 17:12 |
| infinity | That's the bug, then. | 17:12 |
| rbasak | Except it just checks for the presence of /usr/sbin/apache2-mainscript-helper, which is unpacked but apache2 is not configured in this case. | 17:13 |
| infinity | If it depends on a module from apache2, it needs a packaging level dep as well, obviously. | 17:13 |
| infinity | Sorry, I misread your ordering issue, I think. | 17:13 |
| rbasak | It doesn't really need apache2, since they allow for /etc/apache2/ to be managed by you entirely. | 17:13 |
| rbasak | (and for you to only use apache2-bin) | 17:13 |
| rbasak | But if you *do* have apache2 installed, then installing a module will automatically enable it. | 17:13 |
| infinity | Well, they allow, except for the postinst failing if not. | 17:13 |
| infinity | Unless that's all well-guarded. | 17:14 |
| rbasak | It is, mostly. Except for this. | 17:14 |
| infinity | Curious problem, I guess. | 17:14 |
| rbasak | If you don't have apache2 installed, then it's supposed to just not try to do anything in /etc/apache2/ | 17:14 |
| Logan_ | when will the UDD branches start appearing for utopia? | 17:16 |
| Logan_ | *utopic | 17:17 |
| === lfaraone_ is now known as lfaraone | ||
| rbasak | infinity, jibel: filed https://bugs.launchpad.net/debian/+source/apache2/+bug/1312854 (and Debian bug). Not sure how to fix - I'll see what Debian say. | 17:39 |
| ubottu | Launchpad bug 1312854 in apache2 (Ubuntu) "dh-apache2 causes a postinst failure when a package depends on an apache2-bin provided module" [High,Triaged] | 17:39 |
| pitti | infinity: there should be artifacts testbed-packages and <testname>-packages with the exact versions from that testrun | 17:40 |
| pitti | jibel: so want me to re-do the VMs? | 17:54 |
| pitti | for 50 GB, I mean? | 17:55 |
| pitti | jibel: doing now | 18:09 |
| doko | pitti, jibel: according to jenkins the binutils autopkg-test did succeed, however update_excuses isn't yet updated | 18:12 |
| === alkisg is now known as work_alkisg | ||
| infinity | doko: Did you drop a multiarch patch or something from binutils? | 18:43 |
| infinity | doko: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lintian/8/ARCH=amd64,label=adt/artifact/results/log | 18:43 |
| infinity | doko: binaries-libc-link: ld: cannot find -lm | 18:43 |
| infinity | doko: http://paste.ubuntu.com/7331812/ | 18:44 |
| infinity | doko: Looks everywhere except /usr/lib/x86_64-linux-gnu/libm.so | 18:44 |
| infinity | doko: We can't open with that, who knows what fun things it might break. :/ | 18:47 |
| infinity | doko: Want to fix, or just remove that version from proposed? | 18:47 |
| infinity | Oh, bah. If we remove it, all the compiler deps break too. | 18:48 |
| infinity | pitti, jibel: There's another case of tests myteriously falling off the list... | 18:51 |
| infinity | pitti, jibel: binutils should have triggered lintian (and it did), but eventually, the lintian failure just stopped showing up there. | 18:51 |
| infinity | pitti, jibel: If I hadn't caught it manually just now, that would have migrated. | 18:52 |
| infinity | pitti, jibel: I don't know what's causing this, but it *needs* to be fixed, or adt-britney is pretty much useless. :/ | 18:52 |
| infinity | doko: In fact, it skips looking in /usr/lib/$triplet and /lib/$triplet | 19:18 |
| infinity | doko: And ditto for local... | 19:21 |
| infinity | doko: So, old output: http://paste.ubuntu.com/7332024/ | 19:21 |
| infinity | doko: And new output: http://paste.ubuntu.com/7331812/ | 19:21 |
| === roadmr is now known as roadmr_afk | ||
| jobin_ | Hey, all! I am trying to check the status of cron service using sudo service cron status as a non-privileged user on ubuntu 14.04 desktop 64-bit but get a status: Unknown job: cron error in return. However, if I do the same thing on ubuntu 12.04 64-bit desktop I get the appropriate result. I notice that I can check the status if I am root on 14.04. Why is this happening and how can I solve this? | 19:50 |
| infinity | (base)adconrad@cthulhu:~$ sudo service cron status | 19:52 |
| infinity | [sudo] password for adconrad: | 19:52 |
| infinity | cron start/running, process 1106 | 19:52 |
| infinity | jobin_: Works for me? | 19:52 |
| Laney | Is it using the user session? (Can't test that here) | 19:53 |
| Laney | (i.e. does `status --system cron' work?) | 19:54 |
| jobin_ | infinity: Do you mean to say you can check the status without being root on 14.04? | 19:55 |
| infinity | jobin_: You said you were using "sudo service cron status" which *is* root. | 19:55 |
| infinity | jobin_: But if you're just using "status cron", then as Laney says, you need --system | 19:55 |
| infinity | (base)adconrad@cthulhu:~$ status cron | 19:55 |
| infinity | status: Unknown job: cron | 19:55 |
| infinity | (base)adconrad@cthulhu:~$ status --system cron | 19:55 |
| infinity | cron start/running, process 1106 | 19:55 |
| jobin_ | infinity: This is what i get: sudo service cron status status: Unknown job: cron | 19:56 |
| infinity | (base)adconrad@cthulhu:~$ service cron status | 19:56 |
| infinity | status: Unknown job: cron | 19:56 |
| infinity | (base)adconrad@cthulhu:~$ service cron status --system | 19:56 |
| infinity | cron start/running, process 1106 | 19:56 |
| infinity | If you prefer that syntax. | 19:56 |
| infinity | jobin_: You shouldn't need sudo/root at all, just --system | 19:56 |
| jobin_ | Laney: Yes, if I use --system as sudo service cron status --system then i get cron start/running, process 1152 | 19:57 |
| Laney | Job done | 19:57 |
| jobin_ | infinity: This is what I get for service cron status: status: Unknown job: cron | 19:57 |
| infinity | Why your sudo is behaving differently from mine in that regard is likely a local configuation thing. | 19:57 |
| Laney | It's probably passing through UPSTART_SESSION | 19:57 |
| infinity | Maybe you're intentionally preserving your environment, while mine scrubs it. | 19:57 |
| infinity | Preserving environment in sudo generally considered harmful, part III. | 19:58 |
| jobin_ | infinity: Oh yes, I see that i had aliases sudo as sudo -E for using my proxy variables, however, I get status: Unknown job: cron for service cron status but cron start/running, process 1152 for sudo service cron status | 20:01 |
| jobin_ | Laney: I don't need to use --system for service cron status on 12.04, but have to on 14.04, why is that? | 20:01 |
| Laney | You have an upstart instance running in your session in 14.04, which service is looking at in preference | 20:02 |
| jobin_ | Laney: I see that cron in /etc/init.d/cron is a soft link to upstart-jobs | 20:02 |
| jobin_ | Laney: No, I didn't get you there | 20:03 |
| infinity | jobin_: You might want to add http_proxy to env_keep in /etc/sudoers instead of preserving your ENTIRE user environment with "sudo -E". | 20:03 |
| infinity | jobin_: You're asking for trouble doing the latter. | 20:03 |
| jobin_ | infinity: yes, i would avoid that now on, but then how do you explain service cron status returning unknown job on 14.04 but not on 12.04? | 20:04 |
| Laney | jobin_: http://ifdeflinux.blogspot.co.uk/2013/04/upstart-user-sessions-in-ubuntu-raring.html is the feature | 20:04 |
| Laney | If that's available, which it is by default in 14.04, then service will behave differently (try to use the 'user' upstart) by default | 20:04 |
| infinity | jobin_: Because 14.04 uses user sessions, so "service" is looking at your user session, not the system session, and your user isn't running cron. | 20:04 |
| infinity | jobin_: So, "sudo service" will default to the system session (if you don't leak your user env), and "service blah blah --system" will poke at the system session bypassing your user session. | 20:05 |
| jobin_ | infinity: And what did | 20:06 |
| jobin_ | the version before 14.04 use? | 20:06 |
| infinity | jobin_: User sessions didn't exist in 12.04. I think Laney's explained this more than well enough, given this isn't a support channel. | 20:07 |
| jobin_ | infinity & Laney: I had to explain this on askubuntu.com. Do you mind if I share this transcript publicly? | 20:08 |
| ScottK | jobin_: It's already public and logged. | 20:08 |
| infinity | It's already public. | 20:08 |
| jobin_ | infinity: great! Thanks! | 20:09 |
| xnox | infinity: jobin_: initctl --system status cron | 20:35 |
| xnox | infinity: ah, sorted. | 20:36 |
| xnox | infinity: i however have a fix for "service" command to always look at system init, and not session. | 20:36 |
| === roadmr_afk is now known as roadmr | ||
| === roadmr is now known as roadmr_afk | ||
| ScottK | Can autocrats required | 21:39 |
| ScottK | Urgh. | 21:40 |
| ScottK | Can autopkgtests require network access? | 21:40 |
| xnox | ScottK: there is no such stanza in the spec - http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD | 21:41 |
| xnox | ScottK: i believe at the moment on ubuntu dep-8 runner there is network access to e.g. ubuntu mirror and a few similar resources, but not "general web" | 21:42 |
| xnox | ScottK: and i think on debian dep-8 runner (ci.debian.net) there is network access. | 21:42 |
| === brainwash_ is now known as brainwash | ||
| infinity | ScottK: autocrats can totally required. | 21:56 |
| infinity | ScottK: I think you'll find (as xnox says) that it's implementation specific right now, but a needs-intarwebs thing might not be a bad control variable to add. | 21:58 |
| infinity | ScottK: Then paranoid people can just skip those tests, while others can sort out a sane NAT or whatever strategy for their VMs. | 21:58 |
| infinity | ScottK: (Feel free to proposed and/or provide patches) | 21:58 |
| infinity | doko: I think I have your binutils thing fixed, will upload to Ubuntu and NMU to Debian as well, given the ickiness of the bug. | 21:59 |
| xnox | infinity: but about autocrats.... i'm not sure "a 1940s British single-engined three-seat high-wing touring monoplane" scale well enough - do you think would just lego models do? | 21:59 |
| === roadmr_afk is now known as roadmr | ||
| infinity | xnox: That sounds more like a decepticrat. Autocrats can't fly. | 22:00 |
| xnox | infinity: \o/ re:binutils. | 22:01 |
| xnox | "My Dad asked me last night why I carry my 1911 in the house, what am I afraid of? I looked him straight in the eye and said, “The Goddamn Decepticons.” He laughed, I laughed, the toaster laughed, I shot the toaster. It was a good time." | 22:01 |
| xnox | infinity: but when binutils would finish building & autopackage-tests finish -> you wouldn't still be around to open the archive, would you? | 22:02 |
| infinity | xnox: I will be. | 22:03 |
| infinity | xnox: When I'm satisfied with this binutils, I'll open the floodgates. | 22:03 |
| ScottK | infinity: Alternately I just go "Oh, that package can't do autopkgtests" and move on to other things. | 22:03 |
| infinity | ScottK: Yeah, or that. | 22:04 |
| infinity | ScottK: Though, if this is a package with build-time tests disabled for the same reason, that's a bit of a fail on our part. :/ | 22:04 |
| ScottK | It's a DNS module, so it's kind of hard to test without having a network to do DNS'y things. | 22:05 |
| infinity | (Unless literally off it its tests need interwebs, then maybe the tests need rewriting, or we indeed need a testbed with unfettered internet) | 22:05 |
| infinity | s/off/all/ | 22:05 |
| infinity | ScottK: Well, depends on the DNSy things, I suppose. | 22:05 |
| infinity | ScottK: But yeah, hard to know what you can and can't look up in a restricted network. | 22:05 |
| ScottK | Since it's python-dns, it's whole job it to ask questions of the DNS and get answers. | 22:06 |
| infinity | ScottK: FWIW, unlike our buildd network which can't even RESOLVE the outside world, I suspect the autopkgtest machines can resolve, just not connect. | 22:06 |
| xnox | ScottK: you could try doing a quick sample and throw it to the archive and see if it sticks. | 22:06 |
| infinity | ScottK: (But I dunno) | 22:06 |
| ScottK | I'd have to override some pretty low lever pieced of the python networking stack to mock up the right responses. | 22:07 |
| infinity | JABBERWOCKY: SEARCH_DIR("=/usr/x86_64-pep/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); | 22:08 |
| infinity | JABBERWOCKY2: SEARCH_DIR("=/usr/x86_64-pep/lib"); SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib"); | 22:08 |
| Unit193 | (Copied over from -motu, because I noticed the package is in main) So I finally decided to look at the problem rather than hold on to the saucy package. python-parsedatetime in trusty is a bit broken (gives traceback when you use gcalcli), and the way to fix it is either to update to a new version, or apply https://github.com/bear/parsedatetime/commit/51d47dd57a8ac78208aa69015d7e13bdf1bd3574 (and optionally: ... | 22:08 |
| infinity | That looks like a correct mangling, right? | 22:08 |
| Unit193 | ... https://github.com/bear/parsedatetime/commit/692168f4bd336efc07e7575dcde7012eaa1e2075 There were a fair amount of other bug fixes, I believe, so not sure which route you'd prefer. I'd prefer not to do the SRU paperwork myself, so I don't break something.) | 22:08 |
| infinity | Unit193: Do you have a bug filed with the above info? It'll probably get lost in IRC backscroll unless someone feels the urge to jump on it Right Now (which I don't). | 22:09 |
| Unit193 | infinity: I haven't, at least not yet, no. | 22:09 |
| ScottK | zul: I fixed kazoo for you in trusty, but it needs a merge now. Would you please take care of it. | 22:15 |
| infinity | Alright, one last test build without debugging statements, and then I'll throw lintian's failure against it and upload if all good. | 22:19 |
| * infinity crosses his fingers. | 22:20 | |
| infinity | doko: In case I have the wrong number and I'm SMSing into a void, I NMUd binutils to Debian for you, as well as the Ubuntu upload. Enjoy. | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!