[04:19] <pitti> Good morning
[04:23] <veebers> Morning pitti :-)
[05:26] <pitti> cjwatson, lamont, infinity: most of the virt builders are "cleaning", looks like they're stuck?
[05:28] <pitti> wgrant: ^ or maybe you know
[05:29] <wgrant> pitti: Let me see.
[05:29] <wgrant> That is rather broken indeed.
[05:30] <pitti> I'm going to put another big chunk of work on the buildds soon /me sighs at g++
[05:30] <wgrant> pitti: Ah, no, it's fine.
[05:30] <wgrant> Just lots of small kubuntu-ci builds.
[05:30] <pitti> and they don't manifest as an actual build, but as "cleaning"?
[05:31] <wgrant> (ubuntu-archive-tools' "manage-builders -v" is informative here; it whines when things are stuck for more than a few minutes)
[05:31] <wgrant> kubuntu-ci has a lot of small builds starting at the same time.
[05:31] <wgrant> So they all finish quickly, and leave a lot of builders cleaning at the same time, so they queue a bit.
[05:31] <pitti> wgrant: ah, ok; thanks for checking!
[05:31] <pitti> cjwatson, lamont, infinity: unping then ^
[05:32] <wgrant> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20150810/20150811/ <- suddenly a queue from nowhere.
[05:32] <wgrant> We can possibly increase the reset concurrency a bit now, but it's very rarely a problem like this.
[05:32] <wgrant> And this'll resolve itself in maybe 10 minutes.
=== ara_ is now known as ara
[07:33] <dholbach> good morning
=== _ is now known as Guest58868
[08:00] <darkxst> jdstrand, thoughts on https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1466290/comments/13? core GNOME is pretty blocked on this and feature freeze is fast approaching
[08:00] <ubottu> Launchpad bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New]
[08:04] <doko> pitti, do you care about http://autopkgtest.ubuntu.com/packages/a/apport/wily/amd64/
[08:04] <pitti> doko: yes, I do; I just fixed one regression, looking at the other right now
[08:05] <pitti> doko: related to the first one -- is it really intended to have /usr/bin/gcc-5 instead of /usr/bin/gcc-5.2 ?
[08:05] <pitti> doko: (it's one of the issues that hold up binutils and gcc-5)
[08:06] <pitti> lintian also ought to be fixed now
[08:06] <pitti> (didn't run yet)
[08:07] <doko> pitti, yes, next major release will be 6.x
[08:12] <highvoltage> win 26
[09:03] <doko> Laney, pitti: could you work on more "binNMU's" today?
[09:04] <pitti> doko: I could; I'm currently working on finishing some transitions that we started in Ubuntu, resolving FTBFS etc.
[09:04] <pitti> not sure what is more urgent
[09:04] <Laney> going to look at the state soon
[09:04] <doko> good as well
[09:05] <Laney> I'm working on a deduplication script for the tracker atm
[09:05] <doko> looks like slangasek wants to force gcc-5 and gcc-defaults to -release tonight to see what else migrates
[09:07] <pitti> ah, my merged lintian passes again \o/, that should unblock another 4 packages
[09:08] <pitti> doko: doing a final test run of apport, then uploading this; should unblock binutils and gdb
[09:09]  * pitti runs for some errands while this runs
[09:12] <pitti> doko: right, this should flush quite some things, e. g. gcc5 -> mozjs24 -> {gjs,cjs} (and presumably much more)
[09:12] <pitti> from a quick look, all teh regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 also appear somewhere else (where they are better to track)
[09:16] <doko> pitti, I'm working with kubuntu to get the kde related things done. however there are four others: ruby-re2 libwx-scintilla-perl gprbuild freecad
[09:16] <doko> now afk, going back home with the train
[09:20] <ricotz> pitti, hey :), some likely important packages which aren't on that list: scribus, vlc
[09:22] <pitti> doko: I'm already looking on freecad
[09:23] <pitti> doko: ruby-re2 needs transition of re2, I can NMU to Debian/sync/re-build in Ubuntu
[09:23] <pitti> please use the pad -- tracking on IRC is too hard
[09:25] <pitti> doko: adding re2 for me
[10:04] <pitti> ricotz: scribus and vlc don't have autopkgtests; doko's list was regressions from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 which aren't KDE-ish
=== dholbach_ is now known as dholbach
[10:40] <Mirv> seeing libcolumbus1v5 rename brigs me the memory that no-one has really combed the libraries that are actually deprecated and not in use anymore... there's cruft from earlier phone efforts in the archives
[10:40] <pitti> Mirv: please do let us know which ones we can just remove
[10:41] <Mirv> yeah, worth doing so
[10:41] <Mirv> let me think a bit and see if I come up with any that I can verify
[11:04] <Mirv> pitti: ok I've some 15 source packages now collected.. made a pad for it: http://pad.ubuntu.com/drop-obsolete-phone-packages
[11:04] <Mirv> sil2100: can you check the above too? ^ and say if something seems not to be removed from archives in wily
[11:06] <Mirv> pete-woods: are libcolumbus, unity-voice and libdbusmenu-qt to be continued to be used on 16.04 LTS unity 7 desktop?
[11:06] <pete-woods> Mirv: unity-voice technically isn't used any more
[11:06] <pete-woods> but the others are
[11:06] <pitti> Mirv: thanks! will process once sil2100 signs off
[11:06] <pete-woods> unity-voice has a dependency, though
[11:06] <pete-woods> so would need to remove that from HUD first
[11:07] <pete-woods> then you will also get space savings from the voice definition files
[11:07] <Mirv> pete-woods: yes, I noticed I've unity-voice installed on my desktop
[11:07] <pete-woods> Mirv: it's not used, because there is no UI to invoke the voice recognition any more
[11:08] <pete-woods> after HUD was pulled from the phone
[11:09] <Mirv> pete-woods: thanks for the explanation! so some benefit could be had by at least dropping the dependency. I filed bug #1483210 now.
[11:09] <ubottu> bug 1483210 in hud (Ubuntu) "drop unity-voice dependency from HUD, remove unity-voice from archives" [Undecided,New] https://launchpad.net/bugs/1483210
[11:09] <pete-woods> Mirv: thanks
[11:11]  * sil2100 looks
[11:21] <Laney> can anyone see why https://launchpad.net/ubuntu/+source/open-vm-tools/2:9.10.2-2822639-1ubuntu2/+build/7763199 happens?
[11:22] <pitti> Laney: hm, seems to work in my amd64 -proposed chroot
[11:22] <pitti> "apt-get build-dep open-vm-tools", I mean
[11:23] <Laney> right, I tried sbuilding it
[11:50] <cjwatson> Laney: open-vm-tools is in main, the mentioned build-deps are in universe
[11:50] <cjwatson> ... and with that, holiday
[11:50] <Laney> huh
[11:51] <Laney> Oh, there was a new upstream release waiting in proposed already
[11:51] <Laney> I had subconsiously discounted that due to it only being a no-change rebuild
[11:51] <Laney> utlemming: ^^^ any chance you could take a look at that?
=== _salem is now known as salem_
[12:06] <apw> xack
[13:36] <pitti> infinity: why is fisher03 on manual?
[13:36] <pitti> (asking because we could really use some more ppc64el horsepower)
[13:36] <pitti> I just retried to revive denneed04, let's see how it goes
[13:42] <pitti> apw: cheers
[13:46] <pitti> apw: want to do another one?
[13:47] <pitti> Mirv: does this happen to tell anything to you? http://paste.ubuntu.com/12048072/
[13:47] <pitti> Mirv: I just added a change to add -fPIC to the CXXFLAGS, which apparently was respected (as it appears in the c++ line now), but I'm still getting that error
[13:58] <apw> pitti, damn, so much of this is pending for lack of build resources, gah
[13:58] <pitti> Mirv: ah, it seems this error message is utterly confusing; it rather objects to being built with -fPIE it seems
[13:58] <pitti>     (!defined(__PIC__) || (defined(__PIE__) && defined(Q_CC_GNU) && Q_CC_GNU >= 500))
[13:58] <pitti> so Qt does not want to be built with -fPIE on gcc > 5
[13:59] <pitti> apw: that too; it's annoying to see updates on the trackers and when waiting for retrying/uploading followup transitions, but so far there's still enough first-level stuff to do :/
[13:59] <Mirv> pitti: ..yes, so I think this is the last change that went into 5.4.2 we luckily had before the GCC5 transition began: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9
[13:59] <pitti> Mirv: hm, that commit description is equally wrong/confusing then
[14:00] <pitti> or maybe it *is* the intention, then the code is wrong?
[14:00] <pitti> Mirv: so should I drop -fPIE from gnuplot5?
[14:02] <Mirv> pitti: yes it seems they do want to ban the usage of -fPIE
[14:02] <pitti> too bad, it's quite nice for ASLR
[14:02] <Mirv> on x86 only, to be exact, since reduce relocations (-Bsymbolic) is only used on x86 with Qt
[14:03] <pitti> Mirv: oh right, it actually does build on any !x86 arch: https://launchpad.net/ubuntu/+source/gnuplot5/5.0.1+dfsg1-2build1
[14:04] <pitti> Mirv: but it's impractical to drop this by-arch, as a package like gnuplot can't know on which arches we enabled -Bsymbolic
[14:04]  * pitti tries to drop it from all arches then
[14:05] <Mirv> pitti: yes, and the upstream might change to enable it for other archs too but there's a binutils bug on armhf that was thought to be fixed but isn't so it's currently as it is
[14:05] <Mirv> https://bugreports.qt.io/browse/QTBUG-47350
[14:06] <Mirv> we did have -reduce-relocation explicitly set at one point but with Qt 5.4 upgrade it caused Unity 8 to show black screen on arm because of this buggy behavior, so now we accept what upstream defaults to
[14:07] <pitti> Mirv: ack, thanks for the pointers!
[14:10] <Mirv> pitti: you're welcome! I'm happy I battled with Qt 5.4.2 in June without anyone specifically asking for it, since now this problem was largely resolved before GCC5 transition began. GCC5's painful enough as it currently stands.
=== juliank0 is now known as juliank
[14:10] <pitti> wah, wah, wah, still doesn't build
[14:10] <pitti> and why on earth is it so utterly hard to actually find the error message in a build log
[14:14] <pitti> Mirv: hm, I patched out the addition of -fPIE in configure.in and configure, but it still creeps in; might that come from some pkg-config stuff from Qt itself?
[14:15] <pitti> "grep -r fPIE" is empty now
[14:15] <pitti> (and so is "fpie")
[14:19] <Mirv> pitti: hardening flags? see https://launchpad.net/ubuntu/+source/poppler/+changelog
[14:21] <pitti> Mirv: ah!
[14:23] <pitti> Mirv: ok, one step further, but it's *still* there
[14:24] <pitti> actually, it's not
[14:24] <pitti> Mirv: oh! so I *do* need to use -fPIC, but must not use -fPIE
[14:24] <Mirv> pitti: yes!
[14:25] <pitti> but that is wrong
[14:25] <pitti> PIC isn't for executables
[14:25] <pitti> that's PIE
[14:27] <Mirv> I thought PIC was superset of PIE, but I'm not really knowledgeable at that level
[14:28] <pitti> I thought PIC -> shlibs, PIE -> exes
[14:33] <pitti> finally!
[14:33] <pitti> thanks Mirv, builds at last
[14:35] <Mirv> no problem
[14:53] <davmor2> pitti: ofcourse PIE is not for executable PIE is for eating hmmmmm PIE!!!!
[14:56] <pitti> davmor2: it's summer! "pie" is spelt "ice cream" now.
[14:57] <tdaitx> pitti, you might have seen these already, but I found a couple link that might help: http://code.qt.io/cgit/qt/qtbase.git/plain/dist/changes-5.4.2 https://bugreports.qt.io/browse/QTBUG-45755 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
[14:57] <ubottu> gcc.gnu.org bug 65886 in target "[5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic" [Normal,New]
[14:57] <davmor2> pitti: Baked Alaska is still PIE
[14:58] <pitti> tdaitx: thanks; the "changes" is quite useful (it's what the git commit Mirv pointed to did)
[15:00] <tdaitx> hmm... right, I missed that one
[15:01] <tdaitx> although the Changelog itself does add that "Applications using qmake or cmake >= 2.8.12 as their build system will adapt automatically. Applications using an older release of cmake in combination with GCC 5.x need to change their CMakeLists.txt to add Qt5Core_EXECUTABLE_COMPILE_FLAGS to CMAKE_CXX_FLAGS. In particular, applications using cmake >= 2.8.9 and < 2.8.11 will continue to build with the -fPIE option and invoke the special compatibility mode
[15:01] <tdaitx> if using GCC 4.x."
[15:04] <infinity> pitti: Because I forgot I was working on it.  D'oh.  Fixing.
[15:08] <tdaitx> pitti, btw, thanks for the fixing the Changelog of the 2 ftbfs fixes I made the other week... one question: what is the right procedure to add those links when creating the debdiff? at added the debdiff at the time I created the LP bug and used submittodebian to create the bug at debian... seems like I should first create the bugs and only then attach the patches, right?
[15:08] <pitti> tdaitx: you can do that, but adding the bug refs as a sponsor isn't a big deal
[15:08] <pitti> tdaitx: creating an LP bug is instant, so doing that, and re-doing the debdiff is simple
[15:09] <pitti> tdaitx: the Debian BTS is a much worse beast and there are some delays involved
[15:09] <tdaitx> indeed
[15:09] <infinity> The only real delay is greylisting.
[15:09] <infinity> Use the BTS often enough, and it's delay-free.
[15:09] <infinity> So, obviously, file more bugs!
[15:09] <tdaitx> sweet
[15:09] <tdaitx> =)
=== gshereme is now known as gshereme|away
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== tdaitx is now known as tdaitx|lunch
[16:25] <Riddell> ricotz: ping, you rebuild openconnect?
[16:25] <Riddell> I need it rebuilt for plasma-nm, do you know the status of that in the ubuntu archive?
=== Malsasa_ is now known as Malsasa
[16:42] <ricotz> Riddell, how do you mean? the -proposed pocket doesnt provide a rebuild yet, feel free push one
=== Malsasa_ is now known as Malsasa
[17:07] <Odd_Bloke> arges: I mistakenly "fixed" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1381776 in trusty when it actually only appears in precise.
[17:07] <ubottu> Launchpad bug 1381776 in cloud-init (Ubuntu) "cloud init depends on python-serial but does not declare it" [Medium,Confirmed]
[17:08] <Odd_Bloke> arges: But there isn't actually an impact on the installed package, so can we let that through and fix the needlessly added dependency in the next SRU?
[17:09] <Odd_Bloke> arges: (As in, the package is determined as a dependency by debhelper's Python stuff, so the requirements of the package haven't changed, just the Build-Depends)
=== tdaitx|lunch is now known as tdaitx
[17:10] <arges> Odd_Bloke: so if it isn't needed in trusty why not just fail the -proposed version and then when the next upload comes along we just overwrite it
[17:11] <Odd_Bloke> arges: Would we be able to expedite getting that in to the archive and out of -proposed?  We've got another SRU that we want to do that is fairly time-critical.
[17:11] <Odd_Bloke> arges: (But contains big enough changes that trying to verify everything all at once would have been painful)
[17:12] <arges> Odd_Bloke: we can overwrite the current version in proposed. Does it just contain that one fix?
[17:13] <Odd_Bloke> arges: The version in -proposed fixes three bugs; the only change needed to that package would be to fix this problem.
[17:13] <Odd_Bloke> (Well, fixes 2 bugs and this non-bug)
[17:14] <arges> Odd_Bloke: ok in that case verifying #1464253 and then 'verifying' 1381776 would help (perhaps comment on how its a non-bug fix and what your plan is in the next upload)
[17:17] <Odd_Bloke> arges: Ack, thanks.  Both of those bugs are now verified.
[17:19] <arges> Odd_Bloke: another helpful thing would be to ensure all development tasks are marked either 'invalid' or 'fix released'
[17:19] <arges> at least for bug 1381776
[17:19] <ubottu> bug 1381776 in cloud-init (Ubuntu) "cloud init depends on python-serial but does not declare it" [Medium,Confirmed] https://launchpad.net/bugs/1381776
[17:20] <Odd_Bloke> arges: So that should reflect the status in the development release (i.e. not a problem)?
[17:21] <arges> Odd_Bloke: yea so if its not a bug in development its probably 'invalid' or if its already fixed 'fix released'
[17:21] <Odd_Bloke> arges: Ack, will make sure I do that in future.
[17:22] <arges> Odd_Bloke: np
[17:23] <arges> Odd_Bloke: ok so just to confirm cloud-init in precise/trusty/vivid can be released, then you'll upload a new one here soon for the next update
[17:24] <Odd_Bloke> arges: Yep, they are all ready for release.
[17:24] <arges> ok
[17:24] <Odd_Bloke> And I will start preparing the new SRU tomorrow morning.
[17:24] <Odd_Bloke> (As I'm about to EOD)
[17:27] <arges> ok
[17:46] <israeldahl> Hi, is there anyway to make PowerPC debs in a PPA?  I don't think I am allowed to manually upload them.
[17:49] <teward> not an expert but i don't think so...?
[17:49] <maxb> That's more a question for #launchpad, but there are no virtualized PPC builders, so you'd need a PPA enabled to use non-virtual builders, which I *think* is only an option for people employed by Canonical for security reasons
[17:50] <israeldahl> thanks guys...
[17:50] <israeldahl> is the other option to create a repository then?
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[18:44] <infinity> mterry: Hah, nice clash on the lxd MIR. :)
[18:44] <infinity> mterry: I guess now it's REALLY assigned to ubuntu-security.
[18:44] <infinity> Twice!
[18:46] <mterry> infinity, hah  :)
[19:07] <doko> hmm, after today's updates, my mouse cursor on the wily-proposed desktop disappears after some time
[19:07] <doko> Laney, seb128: ^^^ any idea?
[19:07] <seb128> not really no, sorry
[19:31] <tjaalton> doko: try a VT switch and back, or suspend/resume cycle
[19:32] <doko> tjaalton, vt switch didn't help. will try suspend/resume next time
[20:01] <doko> jamespage, smoser: mongodb ping ... you last updated the package in 2014 ...
[20:03] <smoser> doko, you're pinging because its ftbfs ?
[20:04] <doko> smoser, yes
[20:04] <doko> smoser, and we need it for the transition
[20:05] <smoser> i'll poke and see if we cant get someone to look at it.
[20:06] <doko> smoser, ok, I'll upload a workaround to not build with -Werror
[20:07] <smoser> ok. and then we'll try to drop taht in another upload.
[20:10] <doko> smoser, juju-mongodb needs attention too
[20:10] <smoser> ok. thanks.
[20:10] <doko> smoser, open-vm-tools too
[20:11] <doko> smoser, and ceph
[20:12] <smoser> you have a comprehensive list ?
[20:13] <doko> smoser, see slangasek's email to ubuntu-devel (and there are the various ruby packages in dep-wait status which need resolving)
[20:15] <smoser> k
[20:20] <Logan> could someone please help me figure out what's going wrong with this build? https://launchpad.net/ubuntu/+source/aqsis/1.8.2-1ubuntu1 I can't find a specific error message in the log...
[20:20] <Logan> the same upload built perfectly fine in my PPA: https://launchpad.net/~logan/+archive/ubuntu/ubuntu-tweak/+build/7778391
[20:22] <Logan> oh right, it's the parse error again
[20:41] <doko> smoser, LP: #1482777 needs bug subscribers, and filed LP: #1483400 for mongodb. the ceph ftbfs is LP: #1483403
[20:41] <ubottu> Launchpad bug 1482777 in xml-security-c (Ubuntu) "[MIR] open-vm-tools 9.10.2 build dependencies: xml-security-c and xerces-c" [Critical,New] https://launchpad.net/bugs/1482777
[20:41] <ubottu> Launchpad bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400
[20:41] <ubottu> Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403
[20:45] <smoser> thank you
[21:12] <smoser> anyone want to guess what would do this ?
[21:12] <smoser> please
[21:12] <smoser> http://paste.ubuntu.com/12051576/
[21:13] <smoser> for some reason the while loop there just does not read the second line.
[21:14] <slangasek> smoser: any chance that 'sudo cat /proc/net/route' gives different results? :)
[21:15] <doko> smoser, configured open-vm-tools without xmlsecurity and xerces support, seems to build
[21:15] <sarnold> smoser: how repeatable is that? it looks fine, runs fine on my system..
[21:16] <smoser> slangasek, no different
[21:16] <smoser> http://paste.ubuntu.com/12051601/
[21:16] <smoser> well, this system keeps repeating it.
[21:18] <doko> barry, 3.5 related: https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1483410
[21:18] <ubottu> Launchpad bug 1483410 in checkbox-support (Ubuntu) "checkbox-support FTBFS in wily" [High,Confirmed]
[21:18] <barry> doko: ack
[21:19] <smoser> http://paste.ubuntu.com/12051630/
[21:20] <smoser> slangasek, take a look at that.. .very odd. they're the same contetns. but behave differnetly.
[21:21] <slangasek> smoser: what are you meaning to show with that pastebin? you seem to be showing everything *except* the output of 'sudo cat /proc/net/route'
[21:39] <smoser> slangasek, ? cat /proc/net/route at the bottom
[21:39] <smoser> everything there is done as non-root
[21:40] <smoser> so it took the root suggestion out of the picture, but it didnt matter anyway.
[21:40] <slangasek> smoser: oh, because you see the same misbehavior even when running as non-root, check
[21:44] <slangasek> smoser: so it's gotta be either a kernel bug or a dash bug.  What does strace look like?
[21:46] <barry> slangasek: how terrible will it be to MIR libgeos-dev?  i'm more or less stuck between three not so great options for getting django buildable in wily.  libgeos-dev to main seems like the least painful option.  otherwise it's try to try to backport a huge diff from upstream (not sure it will apply and build to our version), or pull in django 1.8.3 from experimental, but i'm really not sure i want to start a django transition right now
[21:46] <barry> too :/  thoughts?
[21:47] <slangasek> barry: it seems like a reasonably self-contained library dep, shouldn't be too horrible IMHO?  But you probably want the MIR team's input
[21:49] <barry> maybe doko can weigh in?
[21:52] <doko> barry, but it doesn't build python bindings?
[21:52] <barry> doko: no, django's test suite uses it via ctypes
[21:53] <barry> the problem is, test discovery works differently on py2 and py3, and the latter picks up gis tests that py2 doesn't pick up.  but you can't just add some test skips because its during discovery that modules get imported which hit libgeos-dev
[21:54] <doko> Changes in 3.4.2
[21:54] <doko> 2013-08-25
[21:54] <doko> seems to be dead upstream
[21:56] <doko> https://github.com/libgeos/libgeos
[21:56] <barry> looks like they've got some recent-ish changes there
[21:56] <doko> but some activity at https://github.com/libgeos/libgeos/commits/svn-trunk
[21:57] <doko> yeah, no release. well, look at the other criteria for a MIR ...
[21:58] <barry> cross pocket b-ds bite again :/
[21:59] <barry> well, if mir of libgeos-dev is unlikely, we might just be stuck with a broken django stack for now
[22:00] <barry> i guess another option is to just ignore test failures for django
[22:12] <sarnold> just how bad is pulling in 1.8.3? iirc django is important to maas, openstack, probably elsewhere, and breaking those doesn't sound fun
[22:43] <infinity> smoser: Is that weird /proc behaviour in a namespace (ie: a container) by any chance?
[22:44] <infinity> smoser: Oh, no.  I can reproduce it here in my base system on my laptop.
[22:44] <infinity> WTF.
[22:46] <sarnold> I wondered if it might have anything to do with read block sizes, so I tried dd with different bs, but the 14 or 15 tests I ran all gave identical results on my computer
[22:46] <sarnold> for i in 1 2 4 8 16 32 64 128 256 512 1024 4096 8192 ; do dd if=/proc/net/route of=$i bs=$i ; done
[22:47] <infinity> I don't see any fishy non-printable chars in the file, which was my first guess.
[22:48] <infinity> Well, my second guess.  My first guess is the kernel just flat out not giving you that line in a pipe.  Which seems like the only plausible answer right now.
[22:48] <infinity> sarnold: You say it doesn't break for you?
[22:48] <infinity> sarnold: Do you have a default gateway on the machine you're trying on (that seems to be the line both smoser and I are missing)
[22:49] <sarnold> infinity: yeah, I do have a default gateway
[22:49] <sarnold> interesting...
[22:49] <sarnold> 3.13.0-57-generic here
[22:49] <infinity> 4.1.whatever here.
[22:50] <infinity> 4.1.0-3-generic
[22:50] <cyphermox> you're missing a default gateway?!
[22:50] <infinity> cyphermox: No.
[22:50] <infinity> cyphermox: Only when reading proc with a pipe.
[22:50] <cyphermox> ok
[22:50] <cyphermox> well, obviously, since you're online :P
[22:50] <infinity> cyphermox: Compare:
[22:50] <infinity> sh -c 'while read line; do echo line: $line; done' < /proc/net/route
[22:50] <infinity> cat /proc/net/route
[22:51] <infinity> And witness the bizarre missing line.
[22:51] <cyphermox> ah, interesting
[22:51] <sarnold> cyphermox: you too?
[22:51] <cyphermox> yeah
[22:51] <sarnold> o_O
[22:52] <cyphermox> http://paste.ubuntu.com/12052232/
[22:54] <cyphermox> 4.1.0-2-generic
[22:54] <infinity> Yep, same missing line.
[22:54] <infinity> It's always either the first route or the default.  Hard to say, since they're the first route on all the test systems.
[22:55] <cyphermox> it's also the one you're most likely to care about :)
[22:55] <infinity> smoser: Have you seen this on a stable kernel, or just on wily?
[22:55]  * infinity tests 4.2.
[22:56] <sarnold> how about "cat < /proc/net/route" ?
[22:56] <cyphermox> correct
[22:56] <infinity> sarnold: That's fine.
[22:58] <sarnold> gah. that hurts my head.
[23:03] <infinity> Same issue on 4.2, *and* confirmation that it's the default route.
[23:04] <infinity> Cause my machine came up with two defaults (on eth0 and wlan0), and both are removed from the piped list.
[23:04] <infinity> Weeeeeird.
[23:04] <infinity> http://paste.ubuntu.com/12052314/
[23:05] <infinity> apw: WTF is wrong with your kernel? :)
[23:07] <doko> tjaalton, no, suspend/restore doesn't help either
[23:23] <infinity> Bah.  Literally identical set of packages installed, still no failure.  Not we're in the realm of the bizarre.
[23:23] <infinity> Err, wrong window.
=== salem_ is now known as _salem
[23:48] <smoser> infinity, i have only ever seen that today
[23:49] <smoser> running on 4.1.0-2-generic
[23:49] <smoser> linux-image-4.1.0-2-generic
[23:49]  * smoser reboots taht system to -3 to see if it goes away
[23:50] <infinity> smoser: It's still broken in 4.1-3 and 4.2
[23:50] <infinity> smoser: Was curious if it was alright under 3.19 and earlier.
[23:50] <infinity> (sarnold says it's fine on 3.13)
[23:50] <infinity> Though, he also has different userspace, which is less helpful.
[23:50] <smoser> yeah, mine is not user namespace
[23:51] <infinity> No, neither was mine.  I got past that theory. :)
[23:53]  * smoser files a bug