[07:43] <dholbach> good morning
=== hikiko-lpt is now known as hikiko
=== greyback__ is now known as greyback
=== spineau is now known as spineau_afk
=== marcusto_ is now known as marcustomlinson
=== ikonia_ is now known as ikonia
[10:35] <tsimonq2> o/
=== spineau_afk is now known as spineau
=== cjwatson_ is now known as cjwatson
=== marcusto_ is now known as marcustomlinson
=== _salem is now known as salem_
=== hikiko__ is now known as hikiko|ln
[12:52] <doko> Riddell, sitter: fixing kdepim, updating symbols files
[13:02] <smoser> pitti, did you see i opened and subscribed you to bug https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1501033
[13:02] <ubottu> Launchpad bug 1501033 in open-iscsi (Ubuntu) "transient error results in /etc/resolv.conf not populated in iscsi root" [High,Confirmed]
[13:31] <mardy> seb128: hi! What is your opinion on bug 1453549? Shall we continue waiting for Yorba, or should we create a facebook key for Shotwell in Ubuntu and distro-patch?
[13:31] <ubottu> bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Confirmed] https://launchpad.net/bugs/1453549
[13:32] <seb128> mardy, hey, I mentioned it during the desktop team meeting yesterday
[13:32] <seb128> willcooke, ^ opinion? I'm unsure you stated one yesterday
[13:32] <willcooke> seb128, I didnt
[13:33] <seb128> mardy, I think the consensus was to try to find somebody to get in touch with the unactive maintainers and talk to GNOME about taking over if needed and creating a new key
[13:33] <seb128> if that fails then make our own
[13:41] <seb128> mardy, k, I guess willcooke doesn't want to get involved in that and other felt like we should wait more on upstream/GNOME so I guess that's what we are doing...
[13:48] <mardy> seb128: fine by me
[13:48] <seb128> mardy, not so much by me, I'm going to wait another week and nag again, would be a shame to get wily out with that bug
[13:50] <willcooke> seb128, mardy - sorry was otp and didn't read the log properly
[13:51] <willcooke> Feels like if u/s is not going to get a new key etc arranged in short order then, as seb128 says, it would be bad to go out without that feature.  mardy, do we have a key from OA that we can use?
=== juliank0 is now known as juliank
[13:59] <mardy> willcooke: not really, I recently registered a key with the same permissions for our Facebook webapp, but it says "Ubuntu Web App"
[13:59] <mardy> willcooke: we should register one specifically for shotwell
[14:00] <willcooke> mardy, ack.  Can you remember the process of registering one, and who keeps the credentials and all that sort of thing?
[14:00] <mardy> willcooke: but if the hidden question is whether I can register a Facebook key for shotwell, then the answer is yes :-)
[14:01] <mardy> willcooke: the simplest thing is if I register the key myself, and then transfer it to IS
[14:02] <willcooke> thanks mardy!  I don't think there is any problem with going ahead and registering a key anyway and then if something changes in the next few days we can simply not use it.  seb128 what do you think?>
[14:04] <mardy> willcooke, seb128: the best scenario would be is Yorba can add me as an admin for their key, so I update it as needed, and then they can remove me when done
[14:04] <mardy> s/is/if/
[14:04] <seb128> mardy, did you try to email them directly about that? maybe they would say yes
[14:05] <mardy> seb128: no, I didn't
[14:05] <seb128> can you try that?
[14:05] <mardy> seb128: sure
[14:05] <seb128> thanks
[14:14] <mardy> seb128: I wrote to Jim Nelson, let's see
[14:14] <seb128> mardy, thanks
[14:15] <seb128> Laney, larsu, ^
[14:15] <larsu> \o/
[14:15] <larsu> thanks
[14:24] <Laney> nice
[14:29] <kenvandine> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[14:29] <kenvandine> whoops :)
[14:56] <arges> cyphermox: bug 1486931, i'm not completely clear where that patch comes from. Can you make the patch match the upstream commits?
[14:56] <ubottu> bug 1486931 in ipmitool (Ubuntu Trusty) "[LTCTest][Opal][OP810] ipmitool 1.8.13-1ubuntu0.3 version is still not working for in-band HPM upgrade" [High,In progress] https://launchpad.net/bugs/1486931
[14:57] <cyphermox> not really
[14:57] <cyphermox> it's been ported for us from later commits by an upstream developer.
[14:58] <cyphermox> (comment 5 points out it's from David Wise, he posted it at https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1481780/comments/16)
[14:58] <ubottu> Launchpad bug 1481780 in ipmitool (Ubuntu Vivid) "ipmitool 1.8.13 needs 2 patches for OpenPower systems" [High,Fix released]
[14:59] <arges> cyphermox: so the existing patch only had some features? and why wasn't it added as a new patch?
[15:00] <cyphermox> the previous patch was incomplete in some way. it was missing integration in some other features of ipmitool
[15:00] <cyphermox> arges: I'm mostly sponsoring this fix for someone else; leitao would know much more about it than I would
[15:01] <arges> cyphermox: ok. I'll look into it more, and ask questions on the bug if necessary
[15:01] <cyphermox> arges: alright
[15:01] <cyphermox> sorry I couldn't be more helpful outright
[15:01] <arges> cyphermox: its always nice to know where a patch comes from , is it upstream, and if it matches what upstream actually committed etc
[15:01] <arges> and in this case it wasn't readily obvious, so I'll keep digging
[15:01] <arges> thanks
[15:02] <cyphermox> for that, like I said David Wise is an upstream ipmitool developer working for AMI AIUI
[15:02] <arges> ok makes sense
[15:02] <cyphermox> I agree perhaps we should list the specific commits this matches
[15:02] <cyphermox> (but I have no idea which those are)
[15:02] <arges> yea if i can't find it in 5-10m, i'll just ask on the bug
[15:02] <cyphermox> ack
[15:11] <Riddell> pitti: kdeplasma-addons false regression? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sonnet
[15:12] <pitti> Riddell: thanks, will fix
[15:32]  * arges thanks autoconf for making debdiffs easy to read
[15:38] <doko> arges, use dh-autoreconf ;p
[15:39] <arges> doko: unfortunately, I'm reviewing others packages so I don't have control of it
[15:41] <juliank> arges: you can still encourage it :)
=== pat_ is now known as Guest33589
=== ogra_ is now known as ogra
=== dude is now known as Guest18590
=== dosaboy_ is now known as dosaboy
[16:15] <doko> cjwatson, cyphermox:  o biosdevname: biosdevname-udeb  ... wants to demote. is this ok?
[16:16] <doko> same for o grub-efi-arm64-signed                                        {grub2-signed}
[16:17] <pitti> doko: biosdevname demote is okay (I was talking to cyphermox about it)
[16:17] <pitti> I don't know about grub-efi-arm64-signed
[16:22] <smb> pitti, can I distract you with an adt question... well I guess I can with the distract part... https://launchpad.net/ubuntu/+source/dahdi-linux/1:2.5.0.1+dfsg-1ubuntu4~14.04.3/+build/7933332/+files/dahdi-linux_2.5.0.1%2Bdfsg-1ubuntu4%7E14.04.3_all.deb
[16:23] <smb> pitti, Somehow that dkms build is failing but any local run I do is working ok... I wondered whether that testbed could be running somewhere which has external downloads blocked
[16:24] <smb> Weirdly the build that behaves the same for wily does work, which is a bit odd
[16:26] <smb> slangasek, and while in whine mode... any luck I may have with dpdk progressing?
[16:26] <pitti> smb: your URL was for a .deb -- you mean http://autopkgtest.ubuntu.com/packages/d/dahdi-linux/ on trusty?
[16:27] <smb> pitti, yes the pure trusty run, vivid on trusty would be broken for different reasons right now
[16:27] <jtaylor> does -fno-stack-smashing not work in 15.10?
[16:28] <jtaylor> I compiled with that flag but the program still aborts with stack smashed ...
[16:28] <jtaylor> no-stack-protector I mean
[16:30] <smb> pitti, Unfortunately the whole package is a bit nasty since the dkms build wgets some firmware on build time. But since it was working for wily I assumed it should be ok for adt testing in trusty, too
[16:36] <tdaitx> sil2100, are you working on squid3? I have the required patches for building it against libecap2, but I need to transition libecap2
[16:37] <tdaitx> you cant build squid using libecap3 because we are still running squid 3.3
[16:37] <sil2100> tdaitx: hey! I could work on that if I'm not getting in your way ;) I just think we can't leave it build-depping on libecap2
[16:38] <sil2100> tdaitx: I would just like to investigate how much effort would be needed to get it working with libecap3 - if too much, then the only option I see is to pull in the latest squid3 from debian
[16:38] <sil2100> But as I said, I might be wrong with my reasoning
[16:38] <tdaitx> sil2100, http://wiki.squid-cache.org/Features/eCAP#line-54
[16:38] <tdaitx> ops, wrong page
[16:38] <smb> pitti, anyhow, not super urgent and your day is running as late as mine. :) I am just puzzled why this failed and you got a bit more insight in the physical layout of the testbeds. I would not rule out that both (w and t) runs may have ended up on different hosts with different fw rules in place...
[16:39] <pitti> smb: sorry, sprint..
[16:39] <smb> pitti, even worse...
[16:41] <smb> arges, btw, I pushed the copyright file change up to the git repo, so just in case we get an ok for the rest, you could rebundle the package after pulling from there
[16:42] <arges> smb: so does that need to get re-sponsored?
[16:42] <pitti> smb: it fails for me locally as well
[16:43] <smb> arges, yes but there might also be further changes I do not know of yet
[16:43] <pitti> smb: but my output is different from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/amd64/d/dahdi-linux/20150923_172802@/log.gz
[16:44] <smb> pitti, huh... I just did an adt-run and in a vm and both worked
[16:44] <pitti> adt-run dahdi-linux --- qemu /srv/vm/adt-trusty-amd64-cloud.img
[16:44] <pitti> smb: is what I ran
[16:45] <tdaitx> sil2100, found it: http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/eCAP#Build_eCAP_library
[16:45] <smb> pitti, if proposed is not enabled it would fail I believe because the status is not without warnings
[16:45] <smb> pitti, actually arges may just have released the version where I added proper dep-8 code to the updates
[16:45] <tdaitx> sil2100, maybe you can help me figure out one vtable symbol that is missing from libecap2
[16:46] <sil2100> tdaitx: ok, so it seems there's more changes required - so I think we need to pull in the latest squid3 version from debian then
[16:46] <arges> smb: i have not yet
[16:46] <pitti> smb: ah, I didn't run against -proposed, let me retry
[16:46] <sil2100> tdaitx: otherwise libecap3 will be forever blocked in -proposed
[16:47] <tdaitx> sil2100, rbasak was working on that
[16:47] <smb> arges, yes sorry that was dkms itself which I saw
[17:03] <pitti> smb: indeed, passes in -proposed
[17:06] <smb> pitti, ah cool. Som my "plan" right now would be to ask arges to let that version out into the wilds so we can follow up with fixes to handle the vivid lts kernel and try to figure out the odd failure somewhat while that is still waiting in proposed
[17:07] <pitti> smb: but then it shold have succeeded on the production infrastructure too
[17:07] <pitti> smb: let's investigate this another time, dinner o'clock..
[17:08] <smb> pitti, well if that production environment allows external downloads
[17:08] <smb> but ok dinner o'clock indeed
[17:08] <pitti> smb: it does, but through a proxy
[17:09] <pitti> smb: so if the download thingy doesn't respect $http_proxy → lose
=== lamont is now known as lamont`
=== lamont` is now known as lamont
=== lamont is now known as lamont_
=== lamont_ is now known as lamont
=== lamont is now known as lamont2
=== lamont2 is now known as lamont
=== lamont is now known as lamont__
=== lamont__ is now known as lamont
[17:43] <doko> seb128, Laney: could you tell SweetShark that he has to subscribe the release team to his FFE reports?
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[18:45] <rcj> infinity, Can you take a look tzdata/pytz issue we have on trusty -> wily... http://pad.lv/1501456
[18:45] <ubottu> Launchpad bug 1501456 in tzdata (Ubuntu) "pytz.country_names UnicodeDecodeError exception" [Undecided,New]
[18:46] <rcj> infinity, it has been silently (our fault) breaking simplestreams image indexing since tzdata version 2015f-0ubuntu0.14.04 (mid-aug)
[18:47] <Shock> Hello folks. I'm seeing some weirdness with ubuntu updates: I got a warning that I'm installing unsigned packages even though that shouldn't have been the case. I managed to get rid of the error by deleting and re-adding it to software sources,.
[18:48] <Shock> Is it possible that the ppa key was changed?
=== alvesadrian is now known as adrian
[18:48] <Shock> I got a bit spooked after reading this: https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-appears-to-be-compromised/e96a0834-a9e9-4f03-a187-bef8ee62725e
[18:49] <mdeslaur> Shock: you probably just needed to refresh your sources list with "apt-get update"
=== adrian is now known as Guest20317
[18:49] <Shock> mdeslaur: did that
[18:49] <Shock> several times
[18:49] <mdeslaur> Shock: hrm, not sure then. perhaps your key went missing
[18:50] <Shock> mdeslaur: why would it tell me that I'm installing unsigned packages since the packages in the ppa are signed?
=== Guest20317 is now known as adrian
[18:50] <mdeslaur> Shock: because the key was no longer present in your apt keychain for some reason?
[18:51] <mdeslaur> how did you put the ppa back? manually or with apt-add-repository?
[18:51] <Shock> mdeslaur: software-sources-gtk
[18:51] <mdeslaur> Shock: ok, so that reinstalled the key from the ppa
[18:51] <mdeslaur> well, the ppa key from the keyserver rather
[18:52] <Shock> mdeslaur: I assume so, but that weirds me out because the ppa has been on my system for a while
[18:52] <Shock> mdeslaur: and I can see no reason for the key to go missing
=== ljp is now known as lpotter
[18:52] <mdeslaur> sorry, I can't either
[18:53] <Shock> mdeslaur: I also got 404s from two mirrors when doing apt-get update
[18:54] <infinity> rcj: Oh, fun.
[18:55] <TJ-> Shock: I often witness that when the package list is out of date, and doing "apt-get update" usually solves it.
[18:55] <infinity> rcj: The most "correct" answer would probably be to make wily's pytz assume utf-8, and hack backports of tzdata to force the file back to ascii.  Maybe.
[18:55] <Shock> TJ-: thanks
[18:56] <infinity> rcj: I consider it broken by design that the file was ever ascii, and extra special that pytz cares, but I suppose we should shoot for maximum compat.
[18:56] <TJ-> Shock: mirror 404s sometimes happen when there's an archive update in progress, and other times when there's a HTTP proxy in the loop
[18:56] <infinity> rcj: But I'm actually asleep right now, so I'll form a better opinion on it $later.
[18:57] <rcj> infinity, okay.  Thanks for the quick look.  I'll defer to $later
[18:59] <sarnold> Shock: the PPA page on launchpad should have a "technical details about this PPA" drop-down triangle thing that shows the signing key, when you click on the keyid it shows details about when that key was generated
[19:01] <Shock> sarnold: generated in 2009
[19:02] <sarnold> Shock: hunh. that's not what I expected. :)
[19:05] <Shock> sarnold: call me paranoid but I think the "easy" way to compromise a linux system is via a mitm attack on the update system
[19:06] <sarnold> Shock: I think most common is still people using guessable passwords and allowing ssh to use passwords like it's 1994 :)
[19:07] <sarnold> Shock: but you're right, it's an easy invitation for code to be downloaded and run..
[19:14] <TJ-> Shock: how would a MITM attack work?
[19:17] <mdeslaur> Shock: you can't, packages are cryptographically signed
[19:18] <mdeslaur> unless you accept to install packages that aren't, but the graphical tools won't allow that
[19:21] <sarnold> TJ-: the "best" that I think a MITM could do against a PPA is to return old package lists to apt-get update requests to prevent or delay the clients from finding updated packages.
[19:21] <sarnold> TJ-: I honestly don't know if apt will eventually complain "these package lists are two months old" or ont
[19:24] <TJ-> sarnold: Yes, I've been wishing for a while all the archive servers use HTTPS, even if mirrors won't/don't. It'd also help minimise the captive-portal/proxy issues
[19:34] <cjwatson> sarnold,TJ-: https://bugs.launchpad.net/launchpad/+bug/716535
[19:34] <ubottu> Launchpad bug 716535 in Launchpad itself "Please support Valid-Until in release files for security.ubuntu.com" [Low,Triaged]
[19:34] <cjwatson> (the thing that needs thought there is that we don't currently republish Release files for stable releases at all, so we need to do something non-trivial about that)
[19:36] <TJ-> cjwatson: looking at the dates in that report it'd be faster to switch to HTTPS :)
[19:36] <sarnold> cjwatson: heh, there's always something, isn't there? :)
[19:37] <cjwatson> TJ-: My understanding is that that would be pretty expensive.
[19:38] <cjwatson> (Though my understanding is perhaps a couple of years old)
[19:38] <TJ-> cjwatson: really? in what way? Most organisations that have evaluated it have found that the perceived additional CPU costs are actually relatively small
[19:38] <cjwatson> TJ-: I'm only going on sysadmin estimates from a while back
[19:38] <TJ-> I do wonder if the HTTP Headers could be used for the Valid-Until part
[19:39] <sarnold> TJ-: iff you use https, sure
[19:40] <TJ-> sarnold: it can be done with HTTP if there's a signature header too
[19:41] <sarnold> TJ-: wouldn't that require more work server-side? i think those are currently apache boxes behind squids
[19:42] <TJ-> sarnold: precisely; any solution requires some work somewhere.
[19:44] <sarnold> true :)
=== mnepton is now known as mneptok
[20:07] <mdeslaur> cjwatson: the Valid-Until headers are problematic if all you need to do is send files from an earlier ubuntu release, no?
[20:08] <mdeslaur> and I assume the issue with mirrors is certs, not the extra cpu cost
[20:15] <elmo> the idea that SSL is "cheap" or even "free" from a CPU perspective is deeply flawed
[20:16] <elmo> for a site like security.u.c, it would absolutely not work with the current hardware allocation and the cost to beef it up to where it would need to be is significant
=== mako_ is now known as mako
[21:21] <cjwatson> mdeslaur: apt checks Codename (or similar) and will complain if it doesn't match what it expects; the send-files-from-earlier-release attack doesn't work
=== salem_ is now known as _salem
[22:01] <mdeslaur> cjwatson: oh! interesting, thanks
[22:02] <cjwatson> mdeslaur: I ran into this experimentally recently when testing InRelease support :-)
[22:03] <cjwatson> mdeslaur: Hm, or I may be misremembering what it did.  I should probably recheck before making grand claims
[22:03] <mdeslaur> cjwatson: I seem to recall this being the issue every time I've discussed it with infinity
[22:03] <mdeslaur> but I've been known to misremember stuff :P
=== Elimin8r is now known as Elimin8er
[22:23] <tdaitx> slangasek, infinity: I need a hand to figure out what to do with a missing vtable symbol in libecap2 (I'm working on its gcc5 transition), so far I haven't been able to find good documentation on how to decide whether this is ok or why it is now missing
[22:29] <doko> robert_ancell, just the ppc64el ftbfs left ;)
[22:30] <doko> tdaitx, please could you paste the issue?
[22:35] <tdaitx> doko, line 48-49 http://paste.ubuntu.com/12627595/
[22:39] <doko> tdaitx, libecap already had a soname transition upstream, and none of the rdepends were able to build
[22:39] <doko> just delete the symbol
[22:39] <doko> and make sure that the rdepends build
[22:39] <tdaitx> ok
[22:39] <tdaitx> doko, thanks
[22:40] <doko> np
[22:40] <doko> just CC me, highlight issues like these please
=== mnepton is now known as mneptok