=== achernya_ is now known as achernya
[04:28] <Mirv> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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: Mirv
=== yuning is now known as yuning-brb
=== yuning-brb is now known as yuning
[06:07] <pitti> Good morning
[06:19] <pitti> zul: here now, I was on holiday on Fri
[06:19] <Mirv> good morning
[06:26] <thopre01> Hi there. Is it possible to create a backport for an unsupported release of Ubuntu (say 11.04 for instance)
[06:27] <thopre01> ?
[06:28] <TheMuso> thopre01: It may be technically possible, but it wouldn't be done for an unsupported release.
=== barrypri1 is now known as barryprice
[06:39] <thopre01> TheMuso: Ok, that was my question
[06:39] <thopre01> Thanks
[06:40] <thopre01> Backports can be done for LTS right?
[06:43] <Mirv> thopre01: LTS or any normal release. at the moment only 12.04 LTS and 14.04 LTS are supported as 14.10 is not out yet.
[06:47] <thopre01> Mirv: Sure. That's what I thought. Thanks both of you
[07:03] <dholbach> good morning
[07:11] <Mirv> morning dholbach
[07:11] <dholbach> hi Mirv
[07:11]  * Mirv happy to be able to do more during patch pilot as a MOTU
[07:15]  * dholbach hugs Mirv
[08:08] <Laney> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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: Mirv, Laney
[08:09] <pitti> Laney: hey
[08:10] <pitti> Laney: I did a few syncs already, currently looking at the libgweather updates, and I'll take the three langpack-locales ones
[08:11] <Laney> 'kay
[08:16] <Mirv> pitti: so hmm, syncing new micro releases don't need FFe?
[08:16] <pitti> bug fixes only -> no new features
[08:17] <Mirv> right, so if the new micro release is sufficiently bug fixes only
[08:17] <Mirv> I could have done a couple of those then
[08:18] <pitti> Mirv: MP status> ah, I see "merged" and "rejected" too, must be a matter of being an uploader for that package or not?
[08:18] <Mirv> the minitube for example does seem a bit more than just bug fixes (adding some unity & gnome 3 action)
[08:18] <pitti> Mirv: I set https://code.launchpad.net/~filip-sohajek/ubuntu/utopic/silversearcher-ag/fix/+merge/232369 to rejected now, to avoid confusion
[08:19] <Mirv> pitti: well I'm MOTU now so I should have been a possible uploader for that
[08:20] <Mirv> pitti: maybe it's still something core-dev vs. motu that gives you those extra options, even in a case of universe package
[08:20] <pitti> Mirv: yeah, maybe
[08:20] <Mirv> that might be a bug, though
[08:31] <pitti> Laney: looking at libchamplain sync now, then I'll stop
[08:31] <Laney> pitti: okay, I'm distracted by an upgrade failure anyway
[08:32] <Mirv> I'll look at grace
[08:33] <Mirv> dholbach: there seems to be multiple active piloters today, possibly reshuffling calendar could make sense
[08:33] <Mirv> at least I can be freely moved around
[08:33] <dholbach> Mirv, there's always different piloters scheduled on a day
[08:34] <Mirv> dholbach: sure, I just think on some days there are less active ones (no-one does @ pilot in etc)
[08:35] <Laney> Mirv: just assign yourself to a bug when you take it for sponsoring
[08:40] <Mirv> that makes sense
[08:45] <dholbach> Mirv, yes, that's right, but it's a bit hard to anticipate who might be active and who isn't
[08:45] <Laney> also I've been slacking
[08:45] <Laney> lemme come back in 10 minutes :)
[08:45] <Laney> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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: Mirv
[08:45] <dholbach> Mirv, if you have a look at http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=raw you can see a table that's commented out, which I use as a basis for the schedule
=== seb128_ is now known as seb128
[08:54] <ara> infinity, hi! when you are around, could you please have a look to these pending packages on the precise queue, please? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=fglrx
[08:55] <ara> infinity, they fix an important bug and they have been in the queue for 3 weeks now
[08:55] <ara> infinity, thanks!
[08:55] <Laney> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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: Mirv, Laney
[08:57] <Mirv> dholbach: oh, interesting, so Lane_y just happens to patch pilot today, not by schedule. cool.
[08:58] <Laney> I always move myself around
[08:58] <Laney> and try to keep the PP calendar entry accurate
[08:58] <Mirv> I've been also slacking waiting for the MOTU application to be handled, so I should probably do some extra shifts
[09:31] <pitti> smoser, infinity: wolfe-0[3456] seem AWOL; any idea what's going on?
[09:32] <pitti> or is that due to lamont's VPN reorg?
[09:32] <mlankhorst> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-qtcreator-plugin-ubuntu/ARCH=amd64,label=adt/267/console how is that test spawned?
[09:32] <mlankhorst> just running qtcreator-launch directly works for me..
[09:34] <pitti> mlankhorst: check in its debian/tests/<testname>; but the current versions do succeed, so apparently this got fixed in the meantime?
[09:35] <mlankhorst> it happens because of mesa
[09:35] <mlankhorst> which is weird.. there is no GLX there..
[09:35] <pitti> mlankhorst: xvfb does support it if you use 24 bit depth
[09:35] <pitti> (with llvmpipe)
[09:36] <mlankhorst> what's the default depth?
[09:37] <pitti> 8 with xvfb-run
[09:37] <pitti> (so you have to explicitly add a -screen)
[09:38] <mlankhorst> hm weird it does run it with 1024x768x24
[09:39] <mlankhorst> qemu: terminating on signal 15 from pid 59347
[09:39] <pitti> mlankhorst: as I said, the recent test runs did succeed; #267 is likely from an older version?
[09:39] <mlankhorst> pitti: no the newer mesa is deleted from the archive
[09:39] <mlankhorst> I want to reproduce the failure so I can investigate it
[09:39] <pitti> ah, or that
[09:40] <pitti> mlankhorst: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-qtcreator-plugin-ubuntu/278/ ran two days ago, was a newer mesa removed over the weekend?
[09:40] <pitti> mlankhorst: I can re-run the test manually if it helps
[09:40] <pitti> (still not sure what you are trying to do)
[09:42] <mlankhorst> yeah
[09:47] <mlankhorst> pitti: I want to debug why glx creation was failing with mesa 10.3
[09:49] <mlankhorst> but I see the test is run with qemu, how is it invoked?
[09:50] <pitti> mlankhorst: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test describes how we run tests in CI
[09:51] <pitti> mlankhorst: but if you have the deps installed, merely running debian/tests/qtcreator-launch shoudl actually reproduce that as well
[09:51] <pitti> mlankhorst: perhaps what happesn in that test is that it doesn't wait for Xvfb to sufficiently start up
[09:51] <pitti> it's not using xvfb-run, but Xvfb directly
[09:52] <mlankhorst> yeah
[09:52] <mlankhorst> well that oculd be possible
[09:52] <mlankhorst> but it was working before, so unless it changes the timing..
[09:53] <mlankhorst> it looks more like some kind of interaction with llvmpipe or something
[10:07] <mlankhorst> oh there we go, can reproduce it with those instructions, thanks :)
[10:08] <mlankhorst> adt-run -s --setup-commands 'apt-get install -y python-software-properties; apt-add-repository -y ppa:canonical-x/x-staging; apt-get update' qtcreator-plugin-ubuntu --- qemu adt-utopic-amd64-cloud.img
[10:20] <pitti> mlankhorst: ah, nice! note you can add -s to get a shell after the test failure
[10:20] <pitti> mlankhorst: then you can ssh into the VM (it prints the commands for that) and investigate
[10:20] <mlankhorst> yeah
[10:22] <lamont> pitti: I added another net to the vpn, but legacy or new should work the same..
[10:23] <lamont> pitti: still an issue?
[10:23] <mlankhorst> ok got something, goodie :)
[10:23] <mlankhorst> name of display: :100
[10:23] <mlankhorst> Error: couldn't find RGB GLX visual or fbconfig
[10:24] <pitti> lamont: yes, it is; but it might very well be that the host (wolfe-XX) itself is down
[10:24] <pitti> lamont: I can't reach it from home (through batuan), nor can the CI lab talk to it
[10:24] <mlankhorst> weird.. same test in my chroot works..
[10:24] <pitti> lamont: so I'll wait for smoser/infinity to have a look at the wolfe host
[10:25] <lamont> pitti: ok.  I'm not actually here until 2.5 hrs from now -- there shouldn't be anything about the vpn, other than several batuan vpns were restarted friday -- reconnect would recover if needed
[10:25] <pitti> lamont: I'm not using VPN there, I just use batuan as a ProxyCommand (as advised back then)
[10:25] <pitti> (for ssh)
[10:26] <lamont> yeah - legacy is 100% unaffected, other than me restarting most of the vpns on batuan
[10:26] <pitti> lamont: ack, thanks for the heads-up
[10:26] <lamont> fwiw, I believe that the new vpn should get you to everywhere you can go legacy -- if not, scream soon
[10:27] <lamont> (unrelated to the restarts, but I had a productive weekend)
[10:27] <lamont> afk
[10:29] <Mirv> pitti: I wonder if you could bookmark yuning's https://code.launchpad.net/~yuningdodo/ubuntu/trusty/usb-creator/usb-creator.lp1361474+lp1300361-recreate-udisks-client/+merge/232852 for evaluation at some point?
[10:30] <Mirv> I can do some testing if wanted with various combos, but I can't upload it anyway
[10:33] <pitti> Mirv: is that actually a backport to trusty, or does that need fixing in utopic, too?
[10:35] <Mirv> pitti: it's a backport of 0.2.62/utopic and one line from 0.2.60/utopic
[10:35] <Mirv> two lines, that is
[10:35] <pitti> Mirv: ah good, thanks
[11:02] <Laney> mitya57: do you know what happened to https://code.launchpad.net/~saiarcot895/ubuntu/trusty/openscenegraph/armhf-support/+merge/230835 ?
[11:03] <Laney> I see it in trusty/rejected
[11:05] <rbasak> Laney: I think it was intentionally rejected so the contributor could add a fix for bug 1339264 as well, which I think he's now done and updated the MP.
[11:06] <ubottu> bug 1339264 in openscenegraph (Ubuntu) "Missing FreeType support in 14.04 LTS package" [Undecided,Confirmed] https://launchpad.net/bugs/1339264
=== mpt_ is now known as mpt
[11:17] <Laney> rbasak: ta
=== MacSlow is now known as MacSlow|lunch
[12:30] <pitti> jodh: hey James! FYI, you can apt-get install systemd-sysv now, all tasks in bug 1351306 are done now
[12:30] <ubottu> bug 1351306 in upstart (Ubuntu) "Cannot uninstall upstart and install systemd-sysv" [Low,Fix released] https://launchpad.net/bugs/1351306
[12:32] <jodh> pitti: nice - thanks!
=== MacSlow|lunch is now known as MacSlow
[12:50] <Mirv> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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: Laney
[13:11] <smoser> pitti, whats up?
[13:11] <pitti> smoser: wolfe-0[3456] are unreachable
[13:12] <pitti> smoser: is the VM host down, or just the VMs themselves, or is it a networking problem?
[13:12] <smoser> i'll check
[13:12] <pitti> smoser: unreachable from both my home as well as the QA lab (jenkins)
=== tedg is now known as ted
[13:14] <smoser> pitti, ok. wolfe (host) is down. i will get it back up today. i'd like to update firmware while its down though (even though that is unplanned)
[13:14] <smoser> unless you want to insist otherwise.
[13:14] <pitti> smoser: nah, I don't meddle with how you manage this machine :) (and I don't have any idea about that hw anyway :) )
[13:14] <pitti> smoser: thanks!
[13:15] <smoser> pitti, no. i was just asking if you wanted it up immediately
[13:15] <pitti> smoser: nah, it's not that urgent
=== _salem is now known as salem_
[14:21] <camako> pitti, is the new umockdev (0.8.8-1) going to be released on rtm and trusty also?
=== mwenning is now known as mwenning-needs-c
=== timrc-afk is now known as timrc
=== mwenning-needs-c is now known as mwenning
[14:56] <pitti> camako: I can copy it to RTM if you need; we don't normally put new upstream releases into stable Ubuntu releases, so for trusty we'd rather do an SRU with some fixes
[14:57] <pitti> camako: but at the same time nothing in trusty needs the new umockdev?
[15:00] <camako> pitti, ack about the rtm... As for trusty, Mir, as it stands, can work under trusty, and we 'd like  to keep it this way, if possible. So when the (Mir) MP requiring this umockdev fix lands, some of our unit tests will be failing on trusty.
[15:02] <pitti> camako: https://launchpad.net/ubuntu-rtm/+source/umockdev/0.8.8-1
[15:04] <camako> pitti, thanks... So do I need to do anything to get the binaries incorporated on my end or will this do it?
[15:05] <pitti> camako: that'll do for RTM; for trusty, if you want this, you can negotiate with the SRU team if they'd accept a backport in trusty-updates
[15:05] <pitti> camako: or, if you only need a single fix (or two) from 0.8.8, we can backport that
[15:05] <camako> pitti, ok will do.. thanks for your help
[15:06] <camako> pitti, I only need the fix abt O_TMPFILE that I sent a few weeks ago..
[15:06] <tkamppeter> pitti, hi
[15:07] <pitti> camako: ah, because there were a lot more Mir triggered changes
[15:07] <tkamppeter> pitti, bug 1355136 seems to be stuck. Should it not get fixed any time soon?
[15:07] <ubottu> bug 1355136 in xubuntu-meta (Ubuntu) "Add recommends printer-driver-brlaser package in -desktop installations" [High,Confirmed] https://launchpad.net/bugs/1355136
[15:08] <pitti> tkamppeter: wow, quite incredible that ubuntu-meta has not been uploaded *a single time* in utopic
[15:11] <tkamppeter> pitti, this would mean that every new package introduction on the way from Trusty to Utopic was handled by dependencies in regular packages.
[15:11] <pitti> tkamppeter: or that any seed change hasn't become active
[15:12] <pitti> tkamppeter: I'm rebuilding it now, let's see what the fallout is
=== bladernr_30kFeet is now known as bladernr_
[15:14] <pitti> tkamppeter: uploaded
[15:15] <tkamppeter> pitti, thanks.
=== Guest13468 is now known as balloons_
[15:30] <seb128> could somebody from the SRU team copy the trusty/verified SRUs with > 1 week to -updates?
[15:30] <seb128> there are a  bunch of 10 to 12 days old verified items in there
[15:58] <ara> infinity, ping
[16:00] <bdmurray> sarnold: I've found a fair number of bugs w/ modified sbin/start-stop-daemon. What do you think is the next step?
[16:22] <pitti> jodh: progress on bug 1374521 and a question to you
[16:22] <ubottu> bug 1374521 in systemd (Ubuntu) "networking.service races with kernel interface detection, ifup@.service is not being triggered" [Undecided,In progress] https://launchpad.net/bugs/1374521
[16:23] <cjwatson> bdmurray,sarnold: check installer logs; my guess is that many of these are due to installs that failed in the middle of the bit where start-stop-daemon is replaced with a dummy script, but which were perhaps far enough along for people to muddle along and use them as a real system
[16:24] <jodh> pitti: yeah, we'd thought of that, but stgraber has reservations about that approach
[16:25] <pitti> jodh: btw, congrats -- you made the boot so fast to outperform the kernel :)
[16:25] <bdmurray> cjwatson: got it, thanks
[16:25] <pitti> jodh: (honestly -- it's nice that this works so fast now!)
[16:25] <jodh> pitti: just don't tell lennart :)
[16:26] <stgraber> pitti: Ubuntu doesn't use allow-hotplug, starting to support it would require a lot of updates all over the place, so I really would rather not do that now
[16:26] <pitti> stgraber: what do you mean with "ubuntu doesn't use"? Ubuntu's d-i on server?
[16:26] <pitti> (our ifupdown obviously supports and documents it)
[16:27] <stgraber> pitti: I mean none of our ifupdown scripts know use that ifupdown class
[16:27] <stgraber> s/use //
[16:30] <pitti> stgraber: which scripts? (I'm learning a lot today :) )
[16:30] <stgraber> pitti: bridge-utils, vlan and ifenslave mostly
[16:30] <stgraber> pitti: all the scripts which ship udev hooks and have to figure out whether the thing that just showed up is the base for an interface defined somewhere in /e/n/i
[16:31] <pitti> stgraber: ah, you mean these look for "auto" interfaces
[16:31] <stgraber> yep
[16:31] <stgraber> they use ifquery and list auto interfaces
[16:31] <pitti> so I guess we need to also call ifup --allow=auto then and live with ifup being called twice
[16:31] <pitti> (or actually three times)
[16:32] <stgraber> that's fine, it's actually what we already do today. The networking job which just does an ifup -a is a catch all in case the event bringup didn't happen.
[16:32] <infinity> pitti: Hey, did anyone have a poke at wolfe for you?
[16:32] <infinity> pitti: Without looking, I'm going to assume it's the same problem that host has always had.
[16:32] <stgraber> so in most cases ifup will already have been called at the time the device appeared, then again when hitting the catch all
[16:32] <pitti> infinity: smoser was, and updating firmware and do other admin things while he's at it
[16:32] <stgraber> but since ifupdown isn't entirely stupid, it knows it's already been brought up and doesn't actually do anything
[16:33] <infinity> pitti: Oh, shiny.  With any luck, one of those things might magically fix it.
[16:33] <infinity> (Not that I'm holding my breath)
[16:33] <pitti> stgraber: right, it's not going to actually break anything, it's just some unnecessary calls
[16:38] <smoser> pitti, how important are the system syou had there?
[16:39] <smoser> hm.. pitti see private query
[16:39] <pitti> smoser: well, we don't block on ppc64el test results, but it'd still be nice to get autopkgtest results for that platform
[16:39] <pitti> smoser: I'm happy to move to other systems, of course
[16:41] <pitti> jodh: ok, need to stop for today; I got the ifup@.service triggering fixed, I'll adjust it to also cover "auto" interfaces then
[16:41] <pitti> stgraber: thanks for the heads-up
[16:42] <pitti> jodh: i. e. I'll upload tomorrow morning, after proper testing
[16:42] <jodh> pitti: great, thanks. chat then.
=== seelaman is now known as IS_hr_bot
=== IS_hr_bot is now known as seelaman
=== roadmr is now known as roadmr_afk
[17:45] <Riddell> LocutusOfBorg1: you did the cmake merge? was there any reason for that?
[17:53] <bdmurray> tinoco: on which release does the fix for bug 1316125 work for you?
[17:53] <ubottu> bug 1316125 in autofs (Ubuntu Trusty) "Autofs leak file descriptors when reloaded (-HUP) and daemon may stop working on high # of shares/reloads" [Undecided,Fix committed] https://launchpad.net/bugs/1316125
=== cmagina_ is now known as cmagina
[18:05] <tinoco> bdmurray: precise
[18:06] <bdmurray> tinoco: its helpful to identify that in the bug so the SRU team knows which release can have the package released to -updates.
[18:06] <tinoco> bdmurray: makes total sense, want me to update it with all releases tested ?
[18:06] <bdmurray> tinoco: yes, please
[18:06] <tinoco> i can provide output based on testcase (since it is straight forward)
[18:07] <tinoco> bdmurray: will get back to you as soon as its ready
[18:27] <tinoco> bdmurray: updating bug .. will finish precise and saucy in a bit
[18:27] <tinoco> trusty ready
[18:27] <tinoco> bdmurray: tks!
[18:37] <tinoco> bdmurray: done
=== roadmr_afk is now known as roadmr
[18:51] <hallyn> slangasek: hi - no hurry on this, but i've uploaded the new cgmanager release for jessie to https://mentors.debian.net/package/cgmanager - which has the listkeys which stgraber will eventually want.  not expecting it to hit utopic or anything so as i say no hurry, but if you get a chance to look+sponser that'd be great
[19:05] <slangasek> hallyn: as you prefaced this with "no hurry", probably best if you send me an email, otherwise it will surely fall off my radar :-)
[19:07] <hallyn> slangasek: will do, thanks
[19:18] <jtaylor> bdmurray: I can't see the error report you are refering to in bug 1358870 whats it about?
[19:18] <ubottu> bug 1358870 in python-numpy (Ubuntu Trusty) "update numpy to 1.8.2 in trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1358870
[19:19] <bdmurray> jtaylor: http://pastebin.ubuntu.com/8460854/
[19:21] <jtaylor> bdmurray: thats harmless, there are no changes to f2py in numpy 1.8.2
[19:21] <jtaylor> it just throws an exception if you give it invalid fortran
[19:21] <jtaylor> which triggers appoart apparently
[19:21] <jtaylor> I guess it needs a whitelist
[19:22] <bdmurray> jtaylor: okay, thanks for looking
[19:27] <jtaylor> whats https://errors.ubuntu.com/problem/5e17937e252e97cc744a4a8e89a0bc2ea8dace02 about?
[19:29] <jhenke_> hi, does anybody knows about problems with the de archive mirror (de.archive.ubuntu.com)? I got BADSIG errors and after clearing the lists in /var/lib/apt/lists now apt is complaining about hash mismatch (on 14.10)
[19:30] <sarnold> jhenke_: the .de mirror was giving people some problems last week or two weeks back, so it's been checked recently and given a clean bill of health... could you remove all your /var/lib/apt/lists/* and then re-run apt-get update?
[19:30] <bdmurray> jtaylor: package:python-numpy:1:1.8.1-1ubuntu1:subprocess new pre-removal script returned error exit status 127
[19:31] <infinity> sarnold: He said he did that.
[19:31] <jhenke_> sarnold just did that, now apt complains about hash mismatch
[19:31] <sarnold> infinity: gah. I so suck a reading.
[19:31] <infinity> jhenke_: A mismatch could just be bad timing on your part (started apt-get update in the middle of a mirror pulse)... Try again and see if it still hates you?
[19:31] <sarnold> and writing apparently.
[19:32] <sarnold> jhenke_: it seems a great many hash sum mismatches filed in launchpad come from dying hardware; check also your dmesg for errors from your drives
[19:32] <infinity> jhenke_: That mirror should be pulsed every 4h, but for a short window, there's a chance that you start your update with the old dists/ tree (and, thus, the old Releases file), and then dowload a new Packages file that doesn't match.
[19:32] <jhenke_> sarnold it is a VM so I rule out hardware malfunction (as the host OS is just running fine)
[19:33] <infinity> But it's also possible the mirror is dying/slow, and needs another poke with a stick.
[19:33] <jhenke_> infinity just retried, same hash mismatch
[19:33] <infinity> jhenke_: Fun, kay.
[19:33] <jhenke_> W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/utopic/main/source/Sources  Hash-Summe stimmt nicht überein
[19:33] <jhenke_> (sorry got de lang pack installed)
[19:33] <infinity> jhenke_: Can you report it on #ubuntu-mirrors?  And, for now, I'd advise switching to gb.archive.ubuntu.com and see if that clears it up.
[19:34] <jhenke_> infinity will do, thanks
[19:35] <infinity> jtaylor: Only one report, and pretty much no info to go by, could be anything.
=== balloons_ is now known as balloons
[19:35] <infinity> jtaylor: And probably not numpy's fault.
=== balloons is now known as Guest63150
=== Guest63150 is now known as balloons_
[19:36] <infinity> bdmurray: Is there no way we can, at the very least, get the apt/dpkg terminal log for auto-submitted dpkg errors like that?
[19:36] <infinity> bdmurray: They're completely useless with no log.
[19:36] <infinity> bdmurray: (And I'd rather just drop them on the floor than have useless noise I can't debug)
[19:39] <bdmurray> infinity: we should be able to get the dpkg terminal log file
[19:40] <infinity> bdmurray: That would be hugely helpful.  In cases like the numpy one jtaylor pointed out, with a single submission, it's probably not a bug in the package at all, but a local issue.  But one can't really know without seeing the output.
[19:40] <infinity> (Well, one can't always know when seeing the output either, but it's a start)
[19:41] <infinity> The part where it's saying it can't run the *new* prerm script is a hint that the system might just be fundamentally busted, since it only tries that after the *old* one fails somehow.
[19:42] <bdmurray> slangasek: the fix for bug 1351137 should mean that crashes are reported by default because /var/lib/apport/autoreport is created correct?
[19:42] <ubottu> bug 1351137 in apport (Ubuntu) "ubuntu-system-settings-wizard does not create /var/lib/apport/autoreport on first boot" [Critical,Fix released] https://launchpad.net/bugs/1351137
[19:50] <slangasek> bdmurray: yes, that's what it /should/ mean
[19:53] <bdmurray> slangasek: it works for me but the default whoopsie test is failing because /var/lib/apport/autoreport doesn't exist...
[19:54] <bdmurray> http://ci.ubuntu.com/smokeng/utopic/touch_stable/mako/63:20140929:20140923/10741/default/1751732/
[20:00] <nadrimajstor> Is pattern [ x"$foo" != x"" ] still needed/in use ?
=== jhenke_ is now known as jhenke
=== salem_ is now known as _salem
=== balloons_ is now known as balloons
[22:01] <cjwatson> nadrimajstor: POSIX shell doesn't need the leading x and can manage just fine with [ "$foo" ], but some other shells need it in corner cases where the expansion of $foo might be a test operator; notably Solaris was really late to switch to a Korn-flavoured shell for /bin/sh rather than its very old traditional Bourne shell, and only did so in Solaris 11.  As a result the habit is still quite widespread among people who care about ...
[22:01] <cjwatson> ... portability to other Unix systems.
[22:04] <slangasek> or those who cargo-culted from people who care about portability to other Unix systems ;)
[22:04] <cjwatson> Some of us did both. :-)
[22:04] <infinity> Heh.
[22:05] <cjwatson> Certainly habits like this take a very long time to die out, if they ever do.
[22:05] <infinity> I gave up on that construct as a conscious protest against Solaris /bin/sh
[22:05] <cjwatson> The autoconf documentation is kept fairly well up to date with which workarounds are needed for which systems.
[22:06] <cjwatson> infinity: I only discovered literally just now while sanity-checking my draft answer to nadrimajstor that they'd finally fixed /bin/sh in Solaris 11
[22:06] <infinity> cjwatson: I wasn't aware that they finally got with the times in 11.  What do they ship as /bin/sh now?
[22:06] <cjwatson> ksh93
[22:06] <infinity> How modern.
[22:06] <cjwatson> http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html
[22:06] <cjwatson> You were expecting zsh?
[22:06] <infinity> I was expecting ash or bash.
[22:06] <infinity> Since they've shipped bash in /usr/xwhatever for eons.
[22:07] <cjwatson> ksh93 probably isn't an awful choice, at least.  Sure better than the Bourne thing.
[22:07] <infinity> Anything's better than their old shell.
[22:08] <infinity> I'd just taken it as a given that I couldn't write shell scripts that behaved on Solaris without the first snippet being -x /usr/whatever/bash && exec /path/to/bash $0
[22:08] <cjwatson> I think they already had ksh lying around somewhere too.
[22:08]  * nadrimajstor Can I rephrase my question :)
[22:09] <infinity> nadrimajstor: Did you want a new answer? :)
[22:09] <cjwatson> Sure, maybe you didn't want a dissertation on archaic shells :)
[22:09] <infinity> nadrimajstor: The short answer to your question is "no, no one needs x$foo = x anymore"
[22:09] <nadrimajstor> infinity: Thank you.
[22:09] <cjwatson> I gave you the longer version because you said "/in use". :-)
[22:09] <infinity> test -z "$foo" is much saner.
[22:10]  * nadrimajstor also likes cjwatson answer
[22:10] <cjwatson> Technically, nadrimajstor was asking about [ x"$foo" != "" ], whose modern version is simply [ "$foo" ]
[22:10] <infinity> And, indeed, the other workaround for Solaris, if you use full paths (don't), cause they had a /bin/test that wasn't as braindead as the sh builtin.
[22:10] <infinity> cjwatson: [ is test.
[22:10] <infinity> (You know this, mind you)
[22:11] <cjwatson> [ -n "$foo" ] (or test -n "$foo") works as well but is unnecessary
[22:11] <cjwatson> infinity: Yes, I was quibbling about -n vs. -z.
[22:11] <infinity> Oh, sure, I got my test backward, cause I forgot the example.
[22:11] <cjwatson> And the lack of necessity of -n. :-)
[22:12] <infinity> Wait, when did [ and test move to /usr/bin?
[22:12] <cjwatson> The autoconf documentation is a fantastic catalogue of people clearly having had very bad days.
[22:12] <cjwatson>      Within a command
[22:12] <cjwatson>      substitution, 'echo 'string\c'' will mess up the internal state of
[22:12] <cjwatson>      ksh88 on AIX 6.1 so that it will print the first character 's'
[22:12] <cjwatson>      only, followed by a newline, and then entirely drop the output of
[22:12] <cjwatson>      the next echo in a command substitution.
[22:12] <infinity> Fallout from Fedora's /usr merge, or has that been broken for years?
[22:13] <cjwatson> $ schroot -c lenny-i386 which test
[22:13] <cjwatson> /usr/bin/test
[22:13] <infinity> Years it is.
[22:13] <cjwatson> Presumably on the theory that in practice you can just use your shell's builtin.
[22:13] <infinity> Not that it matters, since we ship shells with sane builtins.
[22:13] <infinity> But it still feels wrong.
[22:17] <nadrimajstor> Can anyone point me to some guidelines on providing default confs and symlinking to /etc ?
[22:18] <nadrimajstor> Oh... Crucial part... I'm making a native 3.0 .deb without source.
[22:21] <maxb> nadrimajstor: I think you might need to explain "default confs and symlinking to /etc" a bit more
[22:22]  * nadrimajstor is a bit confused about pre|post and inst|rm
[22:22] <infinity> nadrimajstor: Symlinking out of /etc is generally a sign you've done something wrong.  The two ways (excluding fancy things like ucf) that one provides a default config file are either to (a) ship it in /etc as a conffile, or (b) ship it in /usr/share/<package> and copy it to /etc on first install in the postinst (and never again).
[22:23] <infinity> nadrimajstor: The first is the preferred method for something whose default mostly works and only needs the occasional tweak by the admin, the second is probably better if your config file is more of a template that you expect people to heavily mangle and never look like yours again.
[22:24] <ari-tczew> cjwatson: ping on bug 1234612, any plans there?
[22:24] <ubottu> bug 1234612 in memtest86+ (Ubuntu) "Please merge memtest86+ 5.0.1 release from Debian - memtest86 in Ubuntu 14.04 LTS is 2 years old (v4.2.0)!" [Low,Confirmed] https://launchpad.net/bugs/1234612
[22:28] <nadrimajstor> infinity: I have a specific need to remove conf file upon package removal. :(
[22:28] <cjwatson> ari-tczew: I have no plans and don't think I should be the blocker, but it also seems like a change that should be made near the start of a release cycle rather than towards the end; it takes a while to shake out bugs there.
[22:29] <infinity> nadrimajstor: Right, so you do that in postrm, if you manually copied it there in postinst.
[22:29] <infinity> nadrimajstor: If it's a shipped conffile, it'll be removed automatically on package purge, if you manually place it in /etc, you need to manually remove it in posrtrm when $1 is "purge".
[22:31]  * nadrimajstor off to use newly gained knowledge 
[22:33] <cjwatson> infinity: Coincidentally I just saw a link to http://www.in-ulm.de/~mascheck/various/shells/ ...
[22:33] <infinity> cjwatson: Dear god, http://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html
[22:34] <cjwatson> More detail than anyone not already having an absolutely terrible day needs.
[22:34]  * nadrimajstor will pretend that he did not see the content of that page
[22:34] <infinity> cjwatson: Thankfully, all my days are terrible, so this can't hurt.
[22:35] <cjwatson> http://www.in-ulm.de/~mascheck/bourne/  search for 2014 ...
=== _salem is now known as salem_
=== salem_ is now known as _salem
[23:32] <darkxst> tracker autopkgtest failure looks like adt-run itself blew up, way before even getting to the tests
[23:39] <cjwatson> darkxst: Yeah, I've seen a couple of those.  Retried, thanks