=== james_ is now known as Guest6142
=== jono is now known as Guest55880
=== Nisstyre-laptop is now known as Nisstyre
=== hggdh_ is now known as hggdh
[03:29] <pitti> Good morning
=== Kk2 is now known as kk2
[06:50] <dholbach> good morning
=== oSoMoN_ is now known as oSoMoN
=== ara_ is now known as ara
=== oSoMoN_ is now known as oSoMoN
[09:28] <xnox> cyphermox: I got a conf prompt from network manager upgrade..... not sure what to answer =)
[09:28] <xnox> cyphermox: also, i'm not sure all ubuntu desktop users know what to answer.
[09:28] <Laney> I doubt he'll be online for a few hours
[09:29] <xnox> Laney: ok, filing a bug report with a..... screenshot! =)
[09:29] <Laney> attach the relevant files
[09:29] <Laney> blah.dpkg-whateveritis
[09:30] <xnox> Laney: have you seen the new conf prompts? https://launchpadlibrarian.net/144145563/Screenshot%20from%202013-07-04%2010%3A26%3A58.png
[09:30] <Laney> pfft, GUIs :P
[09:30] <Laney> is that no-auto-default something you added though?
[09:30] <Laney> I got no prompt
[09:30] <infinity> xnox: Are you sure you didn't change that locally?
[09:30] <xnox> Laney: after mpt, fixed the update-manager it's actually pleasant to use even for heavy traffic updates in saucy.
[09:31] <infinity> xnox: I don't have the offending line, and I suspect there's no maintainer script that's jamming your MAC in there.
[09:31] <xnox> infinity: editing network manager by hand no..... unless it's me poking in the network-indicator that results in that.
[09:31] <mpt> xnox, that prompt design isn't changed afaik
=== Daviey_ is now known as Daviey
[09:32] <infinity> xnox: Maybe you added that at some point and forgot? :P
[09:32] <Laney> I bet you added that at some point way back
[09:32]  * xnox blames removing etckeeper from my machine.
[09:32] <xnox> i wish I had that now =)
[09:33] <mpt> xnox, if it had been changed it probably wouldn't have the lame title "update-manager"
[09:34] <ogra_> well, the MAC address in there is surely not default
[09:35] <infinity> ogra_: No, obviously not.  But he thinks a tool may have added it, I'm guessing he did it himself on the advice of someone telling him how to disable management of an interface and then forgot. ;)
[09:35] <ogra_> yeah
[09:35] <infinity> (I tend to configure an interface as 'manual' in interfaces(5) when I want NM to leave it alone, personally)
[09:36] <ogra_> yeah, same here
[09:37] <xnox> infinity: well manpages, describes that option as "NetworkManager shouldn't create default wired connections.." "When  the  default wired connection is deleted or saved to a new persistent connection by a plugin, the MAC address of the  wired device  is  automatically added to this list to prevent creating the default connection  for  that  device  again."
[09:37] <ogra_> i even used that as a workaround for 3G data on the touch images (until NM is fixed to ignore the devices itself)
[09:38] <xnox> Laney: infinity: are you using wired ethernet with VPN, with auto-connect and allow all users to use?
[09:39] <infinity> xnox: The wording of that sure is suspicious.  If it really is mangling that file at runtime, either it needs to stop, or it needs to not be a conffile.
[09:39] <xnox> "If you don't know why the file is there already, it is usually safe to replace it." Let's do what it says, right mpt?!
[09:40] <ogra_> did you try something like
[09:40] <ogra_> grep auto-default /var/lib/dpkg/info/*.postinst
[09:40] <mpt> xnox, if it's usually safe to replace it, why is the default "Keep"?
[09:40] <infinity> ogra_: Based on his manpage snippet, it sounds like NM *might* be mangling that at runtime, not in maintainer scripts.
[09:40] <ogra_> oh, urgh
[09:41] <infinity> xnox: It's safe to replace it if you have no idea what you're doing (cause you probably changed it by accident, or based on being a HOWTO-following zombie), for everyone else, keep is the safe default, cause we effin' edited it on purpose. :P
[09:41] <infinity> mpt: ^ misfire.
[09:41] <xnox> mpt: because otherwise, things get broken and I would be using a fine Merkel term to describe the situation: http://www.bbc.co.uk/news/world-europe-23142660
[09:42] <mpt> xnox, keeping it by accident is as likely to be bad though, right?
[09:42] <mpt> So if you're concerned about accidents, *neither* action should be default
[09:42] <xnox> mpt: 3-way merge should be the default. Cause ofono got added, and other options should be preserved and they are non-conflicting.
[09:43] <xnox> mpt: but it's hard to do such a thing generically....
[09:43] <infinity> mpt: keeping by accident usually just means missing out on a maintainer's new features/defaults.  Except in the case of complete conffile overhauls from a very different new upstream version.
[09:43] <infinity> mpt: And people not getting ofono (in this case) would hardly be desribed as "broken".
[09:43] <infinity> *however*, if NM is editing a conffile *at runtime*, that's a bug.
[09:44] <infinity> And the wording or default buttons on the dialog don't come into play here.  The bug should be fixed.
[09:44] <infinity> The goal is to make sure that dialog only ever appears if a user actually edited the file, at which point defaults are slightly less important, cause you should know you edited it.
[09:44] <infinity> In theory.
[09:44] <infinity> If you're not a forum reader.
[09:46] <mpt> xnox, most of the time when I've seen I've this prompt, it's because the maintainer has decided to reorder something. A three-way merge in that case would probably work but produce repetition.
[09:46] <infinity> xnox: Saner merging of conffiles has been on the dpkg maintainer's TODO list for, like, a decade.  I wouldn't hold my breath on it happening without some force of will imposed.
[09:47] <ogra_> mpt, just a maintainer reordering wont cause the prompt ... it is only triggered if the file was touched by you or a script
[09:48] <Laney> or by bugs
[09:48] <Laney> maybe that's covered by the latter though :P
[09:48] <ogra_> nah, there are no bugs
[09:48] <ogra_> :P
[09:48] <mpt> ogra_, yes, so the diff shows both the part you changed and the maintainer's reordering
[09:48] <ogra_> right
[09:48] <infinity> Yeah, that sort of thing kinda demands a by-hand merge.
[09:48] <mpt> Proximate cause and underlying cause. :-)
[09:49] <infinity> But elimination of run-time editing of conffile bugs solves most of the problem, and the second thing is making sure most "normal" users should never need to edit a conffile.
[09:49] <mpt> xnox, I reported bug 1197727 based on your screenshot.
[09:49] <ubottu> bug 1197727 in aptdaemon (Ubuntu) ""Replace your changes in ... configuration file" prompt is unattractive" [Undecided,New] https://launchpad.net/bugs/1197727
[09:50] <infinity> Then it's only the "power users" and server admins and such who edit conffiles, and if we can't do simple text merges, we suck at computers and should switch hobbies.
[09:51] <infinity> ie: I think people screaming for better dpkg conffile handling and merging are solving the wrong problem.  Yes, it would be nice to present me with a prettier merge, but I'm not the user who needs that.
[09:51] <xnox> infinity: i don't count myself a "power user" when it comes to default desktop configs. I couldn't care less what network manager is doing. I want to be a "normal user" for once =)
[09:51] <infinity> xnox: Right, and if "normal use" is mangling that file behind your back, that'sa bug, please hunt, report, and optionally fix.
[09:52] <ogra_> infinity, well, ideally the prompt would just prompt and only show the diff on demand though (have a button "show diff" would already improve it imho)
[09:52] <infinity> xnox: And if you edited it yourself and forgot, it's a slightly more minor but still irritating bug that a "normal user" might need to edit that file to achieve what you did.
[09:52] <ogra_> *having
[09:52] <xnox> infinity: i replaced, and will check if i still have internets after reboot.
[09:52] <infinity> ogra_: Well, that's what the text prompt does, though I'm not sure I agree.  I think once you're in a situation where there *is* a diff to ask about, hiding it behind a friendly "would you like to replace/keep this without knowing why" isn't actually helpful.
[09:53] <mpt> agreed
[09:53] <ogra_> thats what you have the "details" expander for :)
[09:54] <mpt> There's little point having an expander if you nearly always need to expand it to have a hope of knowing what it's about.
[09:54] <ogra_> i think you can beautify it without stealing functionality
[09:54] <mpt> iTunes does it beautifully.
[09:54]  * ogra_ never tried to upgrade iTunes on ubuntu :P
[09:55] <xnox> mpt: i think it was expanded by default, i had to resize the window to fit the whole diff though.
[09:56] <mpt> Not necessarily *efficiently*, but beautifully
[09:57] <mpt> Example: http://www.flickr.com/photos/factoryjoe/1973866433/
[09:57] <mpt> (a change in contact photo)
[09:57] <xnox> mpt: it's much better than before.... these prompts used to not get throught to GUI at all, and instead be "displayed" in the terminal of the update-manager, hidden in details expander.....
[09:57] <xnox> so, I'm not complaining per se =)
[09:57] <mpt> http://jameslow.com/wordpress/wp-content/uploads/2009/11/syncconflict.png (a change in text)
[09:58] <xnox> mpt: I'm still confused how the same guy, from same company can have two different faces..... identity theft? =)
[09:59] <xnox> mpt: is it just me or they are the same?
[09:59] <mpt> xnox, it's like that scene in "Man of Steel" where Superman leaves the buried ship. He is suddenly and mysteriously shaved.
[10:00] <mpt> But otherwise the same guy.
[10:01] <xnox> mpt: was buried ship sponsored by Gillette?
[10:01] <mpt> xnox, I think in the notes example you'd need to scroll down to see the difference.
[10:01] <ogra_> dude ! he is superman .... doesnt need to shave ...
[10:01] <xnox> it must be fun going to movies with mpt - "look shaved again!"
[10:02]  * infinity should get some sleep.
[10:09] <xnox> infinity: or you can quickly tell me why my stage2 cross-compiler does not want to find target libc/cr from where it should =) somehow it searches ${gcc-stage-two-build-tree}/./gcc/ instead of like {path-to-stage-1-install}/bin/../lib/${target-triplet}/
[10:23] <doko> jodh, did you make progress with that upstart pic issue?
[10:28] <xnox> doko: kind of, opted to use external gettext instead of having included copy of code and thus "solving" the issue, by avoiding it.
[10:28] <jodh> doko: right. does look like some sort of gettext bug though.
[10:29] <xnox> doko: is there a way to pass alternative runtime library directory to second stage xgcc? something like LDFLAGS_FOR_TARGET but only during build...?!
[10:29] <doko> jodh, xnox: ok, but the proper fix would be to build that with -fPIC, if you want to link it against the shared lib
[10:29] <jodh> doko: the point is that the behaviour of the autools was different between 32-bit and 64-bit systems and we don't know why.
[10:30] <xnox> doko: yeah, and I'd also expect gettext to do so by it self.... e.g. we get gettext from autoreconf -f -i without touching it.
[10:30] <doko> xnox, not aware of that. why would you need that?
[10:31] <xnox> doko: good point. I think I got prefix wrong. And i'm building without sys-root.
[10:32] <doko> ahh, there is --wist-sysroot and --with-build-sysroot for that
[10:32] <xnox> doko: that sounds like what I want. thanks.
[10:32] <doko> xnox, there are patches needed if you want to set it to /
=== oSoMoN_ is now known as oSoMoN
=== MacSlow is now known as MacSlow|lunch
=== Fudgey is now known as Fudge
[11:46] <xnox> doko: it builds and it boots =)
[11:46] <xnox> \o/
[11:46] <doko> ?
[11:47] <xnox> doko: cross-toolchain built, using pure linaro sources, installled, then do full ubuntu touch build for grouper, flash to device and boot.
[11:47] <doko> ahh, nice
[11:47] <doko> so now trying to update binutils?
[11:47] <xnox> doko: will clean up and push to ppa today. And will poke ogra_ to test builds of other devices & flipped.
[11:47] <ogra_> whee !
[11:48] <xnox> doko: after i make a "release" into ppa, i can work on using our binutils/gcc, yeah.
[11:49] <xnox> ogra_: what's the best way? just me building locally for: mako,maguro,manta,grouper and tossing all .zip & .images onto people.canonical.com for folks to test?
[11:49] <xnox> ogra_: do you have all 4? i only have grouper for testing.
[11:49] <ogra_> that would eb a good start
[11:49] <wookey> xnox: which arch? And which sources?
[11:49] <ogra_> next you should talk to sergiusens
[11:49] <ogra_> to get it into the build process
[11:50] <jibel> hallyn, WRT. bug 1196518, I can reproduce it but only then 1rst time I start the container when /sys/fs/cgroup/devices/lxc/<NAME>/ doesn't already exist
[11:50] <ogra_> wookey, bionic :)
[11:50] <ubottu> bug 1196518 in lxc (Ubuntu) "lxc-start failed with lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc/<NAME>/devices.deny : Invalid argument with kernel 3.10" [High,Incomplete] https://launchpad.net/bugs/1196518
[11:50] <jibel> hallyn, any idea how I can debug it further?
[11:50] <wookey> ah :-(
[11:50] <xnox> wookey: linaro-gcc and linaro-binutils based cross toolchain to androideabi. nothing interesting, armel v5......
[11:50] <xnox> wookey: yeah, with bionic.
[11:50] <wookey> I have a need to either munge linaro binary releases into a fake deb or rebuild to get a 'latest'
[11:50] <wookey> not sure which will be least painful...
[11:51] <xnox> wookey: unpack binary tarball. add a fake DEBIAN/ directory with control file. and then call: dpkg-deb -b . to create binary .deb.
[11:51] <wookey> I cam ehere to ask who do I hassle about nobbling a problem with linaro-maintainers PPA uploads
[11:52] <wookey> xnox: yes, and add some links to make it look about right
[11:52] <xnox> wookey: you could make it a debian source package, which simply copies the binaries around. But that is against Launchpad PPA terms and conditions ;-)
[11:53] <wookey> This .deb will only be used for CI, not for launchpad PPAs
[11:53] <xnox> wookey: than either method is fine.
[11:54] <xnox> wookey: can't checkinstall help here at all? Add a makefile that installs everyting into /usr and call checkinstall on it to generate a deb?
=== sraue_ is now known as sraue
[11:54] <wookey> My PPA issue is that http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu does not have sbuild_0.64.0.orig.tar.gz in it, but uploads there get 'Rejected': File sbuild_0.64.0.orig.tar.gz already exists in Linaro Tools PPA, but uploaded version has different contents.
[11:55] <wookey> I don't know who to hassle to help work out what's wrong.
[11:55] <xnox> wookey: download sbuild_0.64.0.orig.tar.gz from the ppa, take your package and rebuild source package against that tarball.
[11:55] <xnox> wookey: reupload.
[11:55] <doko> wookey, most likely it was there before, and removed
[11:56] <wookey> a) it's not in the PPA - it's lying about that and b) such a build will _always_ fail as the configure gets added in a patch and so is not executable
[11:56] <wookey> It has indeed been wrongly uploaded and removed
[11:56] <wookey> but apparently the correct one can;t be re-uploaded even after removal
[11:57] <wookey> (the original tarball had configure missing due to git-buildpackage not doing the right thing)
[11:59] <wookey> and that can't be fixed in a diff
[11:59] <xnox> ogra_: launched to build all 4 products. Off to lunch =)
[12:00]  * ogra_ crosses fingers
=== MacSlow|lunch is now known as MacSlow
[12:00] <wookey> So, who knows about launchpad enough to get it to forget about the wrong one so a re-upload will be allowed?
[12:02] <xnox> wookey: deleting it from ppa would be a good start
[12:02] <xnox> wookey: https://launchpad.net/~linaro-maintainers/+archive/tools/+packages?field.name_filter=sbuild&field.status_filter=&field.series_filter=
[12:02] <xnox> wookey: there should be delete button near "copy packages" link
=== chuck__ is now known as zul
[12:14] <wookey> xnox: aha. How come it appears there but is not present in http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/pool/main/s/sbuild/ ?
[12:15] <wookey> and if I use that 'delete packages' link it only shows sbuild - 0.63.1-1ubuntu2 , not sbuild - 0.64.0
[12:17] <geser> not sure it's possible to let LP forget about the checksums for the latest uploaded versions (without using SQL)
[12:18] <geser> can't you upload it as 0.64.0+repack1 or something?
[12:20] <wookey> How do I tell dpkg-buildpackage to look for sbuild_0.64.0+repack1.orig.tar.gz? instead of sbuild_0.64.0.orig.tar.gz? I didn't think that the base tarball name could be changed?
[12:22] <geser> you would have to change the version also in the changelog
[12:23] <wookey> Ah I see. got it.
=== oSoMoN_ is now known as oSoMoN
[13:06] <mdeslaur> siretart: are you planning a libav 0.8.7 merge to saucy soon?
[13:15] <siretart> mdeslaur: actually, I am hoping that we can go with libav 9 for saucy
[13:16] <mdeslaur> siretart: ok, I'll push 0.8.7 out to the stable releases then
[13:16] <siretart> mdeslaur: if we get a decision to not go for libav 9, then I would of course merge 0.8.7. however, I'd rather work on a 0.8.8 release upstream before that (which is scheduled for this weekend)
[13:17] <mdeslaur> oh! I'll wait for it :)
[13:17] <siretart> mdeslaur: yes, that makes very much sense to me :-)
[13:17] <mdeslaur> siretart: thanks!
[13:17] <siretart> mdeslaur: I am announcing new release intends to libav-devel. maybe it makes sense to copy these 'intentional' scheduling mails somewhere where you read it? what would be a good destination for that?
[13:19] <mdeslaur> siretart: hrm, I was going to just subscribe, but it seems to be a high-traffic list
[13:19] <mdeslaur> siretart: perhaps just cc security@ubuntu.com?
[13:20] <siretart> mdeslaur: okay, I'll try to not forget that on the next releases :-)
[13:20] <siretart> yes, libav-devel is quite high traffic
[13:20] <mdeslaur> siretart: thanks
=== _salem is now known as salem_
[13:38] <cyphermox> xnox: I'm aware of the issue. you'll likely want to answer Y, to overwrite the file, but I'll be fixing this stuff permanently soonish
[13:39] <ogra_> cyphermox, any idea wheer that MAC entry comes from though ?
[13:39] <cyphermox> xnox: ultimately the actual answer is not a big deal, the addition was to add a plugin for ofono
[13:39] <ogra_> (just out of curiosity)
[13:39] <cyphermox> ogra_: yeah, if you changed your automatic ethernet connection, it writes it there to remember not to create a new automatic dhcp connection for the device
[13:40] <cyphermox> ogra_: and *that* is the source of all the issues
[13:40] <ogra_> yeah
[13:40] <cyphermox> ogra_: and is what I'll move to somewhere else that users don't see/touch
[13:40] <ogra_> thanks :)
[13:42] <ev> ogra_, rsalveti: with the flipped chroot and the latest kernel (3.1.10-6-grouper), it looks like we're back at not being able to get core dumps at all.
[13:43] <ogra_> ev, hmm, there were some config changes recently, you might need to talk to the kernel team to get it back i guess
[13:44] <xnox> cyphermox: ok, sigh. You can close or mark as dupe my bug report then. bug #1197712
[13:44] <ubottu> bug 1197712 in network-manager (Ubuntu) "0.9.8.0-0ubuntu13 is causing conf prompt" [Undecided,New] https://launchpad.net/bugs/1197712
[13:44] <ev> ogra_: *nods*
[13:44] <cyphermox> xnox: probably not a dupe
[13:45] <ogra_> apw, ^^^ any idea if any debugging options were dropped from grouper ?
[13:45] <ev> thanks
[13:46] <ev> ah, it's disabled
[13:46] <ev> debian.grouper/config/config.common.ubuntu:# CONFIG_ELF_CORE is not set
[13:48] <ogra_> ah, yeah, that would be it ... apw  or rtg sould be able to help then
[13:50] <ogra_> ev, so do i sense a whoopsie seeding in ubuntu-tuch soon ? :)
[13:51] <ev> ogra_: as soon as we can get the kernel shovelling through the core pipe, yes :)
[13:52]  * ogra_ is really eager to finally have ubuntu touch options at errors.u.c 
[13:52] <ogra_> due to the fact that we still have PPA packages we are still not filing bugs in the normal tracker ... :(
[13:52] <ogra_> that really needs to change
=== oSoMoN_ is now known as oSoMoN
[13:56] <ev> ogra_: that only prevents it from going to Launchpad
[13:56] <ev> they should still send to daisy.u.c without issue
[13:56] <ogra_> ah, cool
[14:02] <jdstrand> zul: hey, I guess you are aware of apache2 breaking stuff: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html?
[14:03] <zul> jdstrand:  yep
[14:03] <jdstrand> zul: I'm handling apparmor atm
[14:03] <jdstrand> zul: what is the plan for the rest?
[14:04] <zul> jdstrand:  cool ill look at it this afternoon
[14:04] <jdstrand> ok. there is a lot that is preventing migration afaics
[14:07] <xnox> jdstrand: i wonder if it makes sense to send an email out to ubuntu-devel@ "apache2.4 transition is in progress please help out, here is how, or be patient with things not migrating"
[14:07]  * xnox goes to draft something.
[14:09] <jbicha> xnox: if it's just switching dependencies and checking if the package builds that's easy, but if we need to test whether obscure apache modules still work...
[14:10] <xnox> jbicha: it needs switch to dh-apache helper, changes to packaging policy, change how modules are enabled, porting to apache2.4 api.
[14:11] <xnox> so a bit elaborate.
[14:12] <apw> ogra_, dropped no, wrong most likely
[14:12] <apw> whats missing
[14:13] <ogra_> apw, CONFIG_ELF_CORE
[14:13] <ogra_> we used to have it set for a while
[14:15] <apw> ogra_, in which kernel, they are not all the same for sure
[14:16] <ogra_> apw, i would guess in all of them (we used to have it on in grouper before i think)
=== tvoss is now known as tvoss|errands
[14:16] <ogra_> apw, since whoopsie needs it for bugreports
[14:17] <apw> ogra_, well i was assuming someone had found it missing in something specific
[14:17] <ogra_> apw, ev found it missing when trying to make whoopsie work on grouper
[14:19] <ev> o/
[14:20] <ev> I sent a mail to ubuntu-kernel@l.u.c about it
[14:29] <apw> ev ack
[14:30] <cjwatson> wookey: you could fix the configure-not-executable problem by just sticking chmod +x configure at the start of the build target in debian/rules.  That's probably the most pragmatic approach.
[14:30] <wookey> cjwatson: right yes. I didn't think of that until after I'd uploaded a repack version
[14:31] <wookey> also there _is_ a real sbuild 0.64.0 orig.tar.gz so having a broken version of that available anywhere seems like a bad plan
=== smb` is now known as smb
[14:40] <jibel> hallyn, I commented on 1196518 but I'm blocked on finding out why write fails with "invalid argument"
[14:57] <rsalveti> xnox: did you need any extra patch for the android sources to make it build with 4.8?
[14:58] <xnox> rsalveti: so the cross-toolchain is 4.7 based, build with host's 4.8. A 4.8 cross-toolchain does build android sources, if a couple -Werror -Wall are removed in 2 or 3 modules (have a branch of those somewhere)
[14:58] <xnox> rsalveti: so no patches at the moment.
[15:07] <pitti> cjwatson: thanks for the very nice britney/autopkgtest announcement!
[15:08] <cjwatson> yw
[15:21] <xnox> rsalveti: atm for the host tools a prebuild toolchain is also used, and there were failures from moving that to gcc4.8.
[15:21] <xnox> rsalveti: those will need fixing to package android as a debian package.
=== oSoMoN_ is now known as oSoMoN
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[15:31] <ev> thanks for looking into it, apw
[15:35] <rsalveti> xnox: alright, good
[15:35] <rsalveti> thought we'd have more issues
[15:36] <xnox> rsalveti: well, I am compiling using "-O2" without any standard ubuntu hardening flags, everything fails when building with those enabled.....
[15:38] <rsalveti> sure, that's fine
[15:53] <xnox> was there a script or something that can rebuild .pc directory given unpacked tree and quilt series?
[15:53] <xnox> because the patches are "pre-applied"
[15:54] <cjwatson> xnox: http://people.canonical.com/~cjwatson/dpkg-quilt-setup
[15:55] <Laney> xnox: The way I know is to reverse apply using a loop over quilt series | tac and then reapply them
[15:55] <Laney> yeah that
[15:57] <xnox> cjwatson: can we like add that to quilt package in debian?! =)
[15:58] <cjwatson> xnox: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
[15:58] <ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
[16:12] <ev> apw: I think I've finally gotten to the bottom of why we're not seeing kernel oopses on https://errors.ubuntu.com. The version of apport we have deployed to production doesn't have the signature generation code for kernel oopses. Testing apport tip in a canonistack deployment, then I'll file an RT to get that out for all future crashes and work on a back population job to iterate and bucket the existing kernel oopses in the database.
[16:12] <apw> ev, sounds good indeed
=== ikonia_ is now known as ikonia
[16:32] <apw> ev, how urgent is this ELF_CORE thing, it is enabled in the other three kernels, do you have one of those, would a test kernel do for now
[16:32] <apw> ev, trying to work out if i really have to upload it right now or not
[16:32] <ev> you mean in another device?
[16:32] <ev> I only have the nexus 7
[16:32] <apw> ok
[16:33] <ev> getting something to test would be fine
[16:55] <apw> ev http://people.canonical.com/~apw/grouper-saucy/
[16:59] <ev> apw: I don't suppose you have linux-grouper-headers-3.1.10-6 as well?
[17:00] <apw> ev,  on its way
[17:01] <ev> thanks
[17:16] <rbasak> Can someone with ruby packaging experience please look at bug 1197894 for me? I can't figure out why dh_ruby --test doesn't run the test suite. An override_dh_auto_test to call rspec works, but I'm not sure that's the right fix.
[17:16] <ubottu> bug 1197894 in ruby-indentation (Ubuntu) "Test suite not run on build" [Undecided,New] https://launchpad.net/bugs/1197894
=== Nisstyre-laptop is now known as Nisstyre
=== yofel_ is now known as yofel
=== Trevinho_ is now known as Trevinho
=== Lutin is now known as Guest34726
=== iulian_ is now known as iulian
=== halfie_ is now known as halfie
=== Guest34726 is now known as Lutin
=== robru_ is now known as robru
=== _ffio_ is now known as ffio
=== s1aden is now known as sladen
=== kk2 is now known as Kk2
=== RAOF_ is now known as RAOF