[00:23] <siretart> Laney: I've forwarded it upstream. ideally we'd have libav10 in trusty, but oh well...
[01:45] <ypwong> slangasek, hi Steve, about the ubuntu kylin archive, are there anything outstanding?
[01:52] <slangasek> ypwong: I need to reply to JackYu regarding the mirroring setup, and get final confirmation from IS; I'll make sure to push that forward this evening
[01:53] <slangasek> psusi: why did you reassign bug #1308254 to the kernel?  That looks to me like a broken /etc/fstab (referencing devmapper devices by uuid instead of name)
[01:53] <ypwong> slangasek, thanks, about the mirror, I think rsync should be fine
[01:53] <ubottu> bug 1308254 in linux (Ubuntu) "Resume mounts /dev/mapper/${dst}_unformatted, breaks GRUB and Apt" [Undecided,Incomplete] https://launchpad.net/bugs/1308254
[01:55] <JackYu> slangasek, thanks, we will upload packages to the PPA today.
[01:55] <slangasek> JackYu: ok, perfect
[01:56] <psusi> slangasek, he said that the output of /proc/mounts changed during suspend
[01:56] <psusi> slangasek, also the uuid of the device even changed... that looks like a kernel bug
[01:58] <slangasek> psusi: ah.  yeah, that could be a kernel bug, but it's more likely that when he says "suspend" he means "hibernate"
[01:58] <psusi> had one name, suspend, resume, and now /proc/mounts says the device name has a _unformatted suffix ( as does the uuid ), when in fact, the device name did not change
[01:58] <slangasek> because the _unformatted suffix comes from cryptsetup's userspace scripts, which only run on boot
[01:59] <psusi> does that matter?  if the device is mounted when you hibernate, it's still mounted when you resume and its name should not change
[01:59] <psusi> and in fact, it didn't sound like the /dev name really did change.. just what /proc/mounts shows
[02:00] <slangasek> psusi: well, I replied to the bug and marked it invalid with what I believed was a plausible analysis... if it turns out I'm mistaken, we'll reopen.
[02:00] <slangasek> psusi: but mountall is not triggered at all ever on suspend/resume or hibernate/resume
[02:00] <slangasek> so the bug report itself is a bit suspect
[02:00] <psusi> I didn't think so
[02:01] <slangasek> if I'm wrong, we'll find out
[02:01] <psusi> it certainly was not a bug in grub, and apt, and cryptsetup ;)
[02:02] <slangasek> indeed!
[02:02] <psusi> nn o/
=== cmagina_ is now known as cmagina
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
[04:40] <fhassan> is Trusty ETA decided in advance or could be anytime during the day?
[04:59] <pitti> Good morning
[05:14] <RAOF> fhassan: It's typically delayed by an hour each time someone asks :)
[05:19] <fhassan> RAOF: lol. looks like I should zip my mouth for 24-48 hours :)
[05:20] <tarpman> fhassan: test the installer a few times, to help pass the time :)
[05:22] <fhassan> tarpman: I'll see what I can do. Thx.
=== sz0` is now known as sz0
[06:32] <dholbach> good morning
[08:19] <hyperair> oh god, chromium looks so goddamned fugly now
[08:19]  * hyperair wonders if aura can be disabled.
[08:20] <pitti> our supported default browser looks fine, FWIW (just sayin')
[08:20] <hyperair> yeah it also hangs like hell
[08:21] <hyperair> and the crappy ol gecko inspector thing renders with such tiny font sizes
[08:21] <hyperair> what's it made for, ants?
[08:21] <pitti> hm, I must be doing entirely different stuff than you then
[08:22] <Unit193> Indeed, and I've got it on a single core.
[08:22] <rww> hyperair: the font is webscale
=== tkamppeter_ is now known as tkamppeter
[08:24] <hyperair> rww: what's webscale?
[08:26] <hyperair> http://imgur.com/RtnYqpR <-- this
[08:26] <hyperair> this *cannot* possibly be normal
[08:26]  * hyperair reins in the expletives
[08:40] <jibel> xnox, I reopened bug 1307983 and filed 1308396
[08:40] <ubottu> bug 1307983 in ubiquity (Ubuntu Trusty) "System not localized after an OEM or offline installation" [High,Triaged] https://launchpad.net/bugs/1307983
[08:40] <jibel> bug 1308396
[08:40] <ubottu> bug 1308396 in language-selector (Ubuntu) "gnome-language-selector crashed with SIGSEGV in pkgCache::ReMap()" [Medium,New] https://launchpad.net/bugs/1308396
[08:41] <jamesh> mardy: would you be a good person to talk to about the online accounts infrastructure?
[08:42] <mardy> jamesh: I'm afraid so :-)
[08:42] <mvo> jibel: is that crash reproducible?
[08:43] <jibel> mvo, apparently no
[08:43] <mvo> :(
[08:44] <jamesh> mardy: I was trying to set up a new service using the generic-oauth plugin.  I think I got something wrong, since the auth page isn't loading in the embedded web browser.  Is there an easy way to check what requests are being made, or even what URL the embedded web browser requested?
[08:45] <mardy> jamesh: yes, start with "killall signon-ui"
[08:45] <mardy> jamesh: then:
[08:45] <mardy> export SSOUI_LOGGING_LEVEL=2
[08:45] <mardy> export SSOUI_DAEMON_TIMEOUT=9000
[08:45] <mardy> signon-ui
[08:46] <mardy> jamesh: then you'll see some logs in the console, including the URL which was requested
[08:46] <jamesh> okay.  I'll give that a shot
[08:50] <mvo> jibel: so you run the language-selector again and it does no longer crash?
[08:51] <jamesh> mardy: thanks.  That made all the difference.
[08:51] <jibel> mvo, yes, I ran it several times and it didn't crash. I'm redoing a full installation
[08:53] <mardy> jamesh: good! Out of curiosity, what service is it?
[08:53] <jamesh> mardy: soundcloud
[08:53] <jamesh> mardy: I'd set AuthPath to "/connect", when it should have been "connect"
[08:54] <mardy> jamesh: yes, these things should probably be made more flexible
[08:54] <jamesh> the former led to the web browser trying to display https://api.soundcloud.com//connect, which gave a 404 error
[08:54] <jamesh> removing the extra slash, and I have an access token
[08:55] <jamesh> mardy: also, if I want to access the accounts service from a language without a binding, would it make sense to use direct D-Bus access?
[08:56] <mardy> jamesh: the D-Bus API hasn't changed for a long time, but we plan to do some changes someday
[08:56] <mardy> jamesh: I wouldn't recommend using that
[08:57] <mardy> jamesh: there are glib bindings, I think they can be easily wrapped in any language, can't they?
[08:58] <jamesh> mardy: this is for Go.  I could probably go via the C API, but if D-Bus was similar complexity that would be easier to hook up
[08:59] <jamesh> (Not actually using any other glib APIs at present)
[09:01] <mardy> jamesh: for the authentication, you could probably use the D-Bus API, it would be a matter of a couple of D-Bus calls only
[09:01] <mardy> jamesh: however, for the accounts part (finding the account to use), there is no D-Bus API, just a glib-based library
[09:02] <mardy> jamesh: so you'd have to wrap at least that one
[09:02] <jamesh> mardy: I basically just want to check for the existence of an account and get the access token if it exists.  If that's easier to do from glib, then that's what I'll do.
[09:03] <jamesh> thanks again for the help.
[09:26] <jibel> mvo, it seems to be a one time crash, I couldn't reproduce it.
[09:28] <pitti> . o O { copying files in ubiquity is fun if your target virtio drive is on a tmpfs }
[09:58] <Laibsch1> As an almost decade-long contributor to Ubuntu and DM who is overqualified and contributing too much (yep, I was denied recognition as @ubuntu.com contributor for THAT reason!) I was wondering if upload privileges that others are apparently granted easily are ever revoked in case of gross neglect?
=== Laibsch1 is now known as Laibsch
[09:59] <Laibsch> Such as sync'ing a package that obviously needed a merge and failing to even run the single command the sync'd package provides before making the upload (or else one would have realized the command fails to run due to the missing merge introduced in karmic)
[10:00] <Laibsch> bug 1239912 seems to me to be such a case
[10:00] <ubottu> bug 1239912 in system-config-lvm (Ubuntu) "system-config-lvm fails to start citing missing /etc/init.d/lvm2" [High,Confirmed] https://launchpad.net/bugs/1239912
[10:24] <xnox> Laibsch: that bug report is valid. Upload priviledges are granted by Developer Membership Board these days, please see documentation on the wiki pages.
[10:24] <cjwatson> Laibsch: might be worth a note to the DMB
[10:24] <cjwatson> I'll see about getting that patch reintroduced
[10:25] <cjwatson> (appreciate the heads-up)
[10:25] <Laibsch> thanks, cjwatson
[10:26] <Laibsch> I was just wondering if someone keeps on eye on if an individual had a history of doing things like this.  I don't actually thing any measure is needed if it was a simple mistake and certainly not for someone doing a lot of uploads.  I was simply honestly curious if there was a process in place and whether or not it is actually being used in practice.
[10:26] <Laibsch> s/thing\ any/think\ any/
[10:27] <xnox> Laibsch: there is email address you can contact DBM only via developer-membership-board@lists.ubuntu.com
[10:28] <Laibsch> thanks, I'll consider using it if ever I came across a similar instance by the same individual.  It's my first time to see his name.
[10:38] <pitti> infinity: hm, are we building ubuntu-core for arm64? http://iso.qa.ubuntu.com/qatracker/milestones/314/builds/66886/downloads has no links
[10:38] <pitti> infinity: (worked fine on i386, amd64, and ppc64el)
[10:39] <pitti> infinity: nevermind, found it; that just seems to be a problem in the ISO tracker
[10:39] <pitti> i. e. the download link isn't set
=== MacSlow is now known as MacSlow|lunch
=== pete-woods is now known as pete-woods-lunch
[11:16] <pitti> jibel: http://iso.qa.ubuntu.com/qatracker/milestones/314/builds/66886/downloads has no links, but there is a http://cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-arm64.tar.gz
[11:16] <pitti> jibel: can this be added to the tracker?
[11:16] <pitti> jibel: (I realized that I can't actually test that as I don't have root access to arm64 or powerpc hardware, but it caught my eye anyway)
[11:17] <jibel> pitti, thanks for pointing this out, I'll add the link
[11:19] <infinity> tjaalton: *poke*
[11:20] <infinity> tjaalton: I think dropping the transitional packages from intel-vaapi-driver was premature.  We probably want them in 14.04
[11:31] <rbasak> xnox: just had a dupe of bug 1273462 and I noticed that it's still open. Is this not being fixed for Trusty now?
[11:31] <ubottu> bug 1273462 in upstart (Ubuntu) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [Critical,Triaged] https://launchpad.net/bugs/1273462
[11:31] <xnox> rbasak: i don't have it ready, i will push to sru it though.
[11:31] <xnox> rbasak: not this week, i don't think.
[11:32] <xnox> rbasak: there are ~160 affected scripts i believe
[11:42] <rbasak> xnox: OK, thanks!
[11:48] <tjaalton> infinity: oh..
[11:53] <int_ua> Is it possible to package a click package for Tabbed UI + C++ backend?
[11:56] <rickspencer3> int_ua, I  suspec that #ubuntu-app-devel may have an easier time answering your question
[11:57] <int_ua> rickspencer3: Thanks a lot :)
[11:57] <rickspencer3> np
=== MacSlow|lunch is now known as MacSlow
=== Sweetsha1k is now known as Sweetshark
[13:09] <doko> Logan_, librep: you need to call dh_autoreconf after applying the patch ...
[13:09] <doko> and b-d on it
[13:10] <cjwatson> doko: infinity was dealing with that
[13:10] <cjwatson> Logan_: ^-
[13:10] <doko> ahh, ok
[13:11] <cjwatson> (since it's actually a bit more complicated, with an insane stack growth direction check that's misfiring)
[13:11] <infinity> Yeah, I'm on top of that, after we get the next respin going.
[13:12] <doko> now preparing the openjdk-7 security update ...
[13:13] <infinity> doko: post-release, I assume.
[13:13] <doko> infinity, hmm, ok ... can I already upload?
[13:14] <infinity> tjaalton: Can you do an upload that reintroduces those transitional packages, then you can drop them in 14.10.
[13:14] <cjwatson> doko: your gts sync failed to build on ppc64el
[13:14] <infinity> doko: Stage it in the security PPA with the security team, IMO.
[13:14] <doko> yes, seen
[13:14] <infinity> doko: Then they can release it post-release.
=== _salem is now known as salem_
[13:24] <infinity> doko: You're aware you've had a build going (hung, I assume) on kelsey01 since Mar28? :P
[13:25] <doko> no?
=== nhayashi is now known as zz_nhayashi
[13:28] <infinity> doko: Well, now you are. :)
[13:32] <infinity> Logan_: librep fixed for you, you can stop worrying about it.
=== pete-woods-lunch is now known as pete-woods
=== JanC_ is now known as JanC
[14:29] <Elv1313> xnox: ping
[14:29] <xnox> Elv1313: hi.
[14:29] <Elv1313> hi, 2 weeks ago we talked about #1303897 and #1299967
[14:30] <xnox> bug #1303897
[14:30] <Elv1313> you said that we could eventually apply the patches if nobody stepped in, is this still the case?
[14:30] <ubottu> bug 1303897 in sflphone (Ubuntu Trusty) "sflphone-kde may hang on startup with some contact topologies" [High,Triaged] https://launchpad.net/bugs/1303897
[14:30] <xnox> bug #1299967
[14:30] <ubottu> bug 1299967 in sflphone (Ubuntu Trusty) "sflphone do not start" [High,Confirmed] https://launchpad.net/bugs/1299967
[14:37] <Elv1313> we get a lot of emails for this, and this is understandably quite critical, so it would be nice if the patches could be merged
[14:58] <infinity> tjaalton: Ideally soon. :P
[15:34] <tjaalton> infinity: not before maybe 2200utc when i should be back home :/
[15:42] <k1l> hi
[15:42] <k1l> will the 12.04 LTS to 14.04 LTS upgrade path opened right tomorrow on the 14.04 release or will that wait until 14.04.1 (like it was on 10.04 to 12.04)?
[15:45] <infinity> k1l: The latter.
[15:46] <k1l> infinity: ok, thanks. than we will brief the #ubuntu team for the "but i dont see the LTS upgrade nofication" concerns tomorrow :)
[15:51] <jodh> bdmurray: hi - could you take a look at bug 1300235 (and dups)? - apport is marking them as Upstart bugs, yet all the core files relate to chrome.
[15:51] <ubottu> bug 1300235 in upstart (Ubuntu) "init crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/1300235
[15:53] <bdmurray> jodh: yeah, I'll have a look
[15:53] <jodh> bdmurray: thanks!
[16:04] <bdmurray> jodh: it'd be neat if UpstartRunningSystemJobs was sorted
[16:09] <pitti> jodh, bdmurray: ExecutablePath: /sbin/init
[16:10] <jodh> pitti: sure, but try running file on the gunzip'd core file.
[16:10] <pitti> jodh, bdmurray: /opt/google/chrome-unstable/chrome  -> that's not something we ship, is it?
[16:11] <pitti> jodh, bdmurray: might the above actually be a symlink to upstart, or might that execve(upstart) for its session management?
[16:12] <pitti> https://launchpadlibrarian.net/171353712/ProcMaps.txt looks fairly much like upstart
[16:12] <jodh> pitti: ProcCmdline is "/sbin/init", and not "/sbin/init --user" so unless all these folk are running chrome as pid 1...
[16:12] <jodh> pitti: agreed.
[16:13] <pitti> jodh: so, this is clearly an invalid bug as it's something utterly funky
[16:14] <jodh> pitti: but it's consistently funky. apport bug?
[16:14] <pitti> I suppose /opt/google/chrome-beta/chrome is the upstream chrome installer
[16:14] <pitti> well, it gets called on /sbin/init
[16:15] <pitti> I'm really curious what kind of black magic /opt/google/chrome-unstable/chrome is
[16:15] <pitti> (but then again, not curious enough to actually find and install chrome.. -- that's not even the packaged chromium-browser)
[16:16] <pitti> jodh: also, it's clearly pid 1
[16:16] <pitti> (see ProcStatus.txt)
[16:16] <pitti> jodh: so it's system upstart indeed, not session
[16:16] <jodh> pitti: right, so where have these core files come from?
[16:17] <jodh> pitti: none of them has a system job that runs chrome so I'm confused
[16:17] <pitti> jodh: yes, so am I
[16:18] <pitti> jodh: I don't know where file takes the program from, supposedly from some memory block of the core dump
[16:18] <pitti> jodh: probably best to ask the reporter for an ls -l of that chrome thing, whether it's reproducible, and an strace; like that the data isn't very helpful
[16:18] <pitti> jodh: or just invalidate it, given that it's unsupported sw
=== bfiller is now known as bfiller_afk
[16:32] <Logan_> infinity: thanks :)
[16:33] <Logan_> odd that I skipped over configure
=== maclin__ is now known as maclin
=== dpm is now known as dpm-afk
=== psivaa_ is now known as psivaa
[16:55] <alkisg> Hi, I downloaded the trusty daily x64 iso today, and dd'ed it to a usb stick, and it failed to load with "tried to read past end of file" and "invalid pointer" etc... should I file a bug, or is it a known one, or is it too late?
[16:55] <alkisg> *on an uefi pc
[16:55] <alkisg> Grub showed up fine, but it couldn't load the kernel
[16:58] <shadeslayer> alkisg: sounds like a broken ISO
[16:58] <shadeslayer> did you md5sum it?
[16:58] <alkisg> Let me check...
[16:59] <alkisg> $ md5sum trusty-desktop-amd64.iso
[16:59] <alkisg> 0a884e0fe10f703493a4f8ff993be5fd  trusty-desktop-amd64.iso
[16:59] <alkisg> http://cdimage.ubuntu.com/daily-live/current/MD5SUMS => same
[16:59] <alkisg> It's ok...
[17:00] <shadeslayer> okay, did you run the self check on the ISO?
[17:00] <alkisg> It's on a USB stick, I don't think it's likely that it wasn't written ok,
[17:00] <alkisg> ...I can do it in 3 hours, because I'm copying a big disk via USB and it'll take 3h to finish...
[17:01] <alkisg> Ah, I can use a different PC, moment...
[17:02] <alkisg> First, the error: attempt to read or write outside of disk `hd1'.
[17:02] <alkisg> unaligned pointer 0xd804ac68
[17:02] <alkisg> Aborted. Press any key to exit.
[17:03] <alkisg> The memory test produces the same error on UEFI, let me disable it so that syslinux loads...
[17:09] <alkisg> Hrm it does the check and then powers off without showing me the result, even without 'quiet splash'... /me tries to launch it in text mode...
[17:13] <alkisg> ...nothing with "Boot: check" either... /me will md5sum the contents manually...
[17:23] <doko> stgraber, can you update the package sets before release please? cjwatson pointed me to you (as a tb member), e.g. the core set still lists gccxml and emacs23
[17:24] <stgraber> doko: we can't do automated updates at this point because the script is doing a lot of things that are wrong and need fixing, so if you give me a specific list of changes I can do it, otherwise it'll have to wait until at some point post-release
[17:25] <stgraber> doko: note that core isn't tied to any upload privilege, so having it not entirely accurate isn't preventing anyone from uploading those
[17:25] <doko> stgraber, well, I see these two ones at least. llvm-toolchain-3.3 too
[17:26] <doko> looking at http://qa.ubuntuwire.com/ftbfs/ where these sets are used too
[17:27] <doko> stgraber, can you make a note for the release process (wiki page?) that this isn't forgotten the next time?
[17:29] <alkisg> shadeslayer: the md5sum of /dev/sdb was not the same as the .iso, thanks + sorry for the noise
[17:31] <bdmurray> jodh: its also interesting that bug 1300235 and all its duplicates are using an old version of upstart
[17:31] <ubottu> bug 1300235 in upstart (Ubuntu) "init crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/1300235
[17:32] <seb128> bdmurray, jodh: is chrome(os?) shipping a copy of upstart or what?
[17:36] <stgraber> doko: core is usually generated from the seeds so they should be all fine once we get the script to work properly
=== roadmr is now known as roadmr_afk
=== oSoMoN is now known as oSoMoN|afk
=== psivaa is now known as psivaa-afk
[18:01] <arges> bdmurray: can I have a review of pacemaker in the precise upload queue? I uploaded so I belive I'm not supposed to accept it.
[18:12] <bdmurray> arges: I'll have a look today
[18:12] <arges> bdmurray: thanks
[18:13] <dobey> what image build am i supposed to get if i flash right now? flashing to trusty is giving me 294, and trusty-devel says my device is not found on the server
=== roadmr_afk is now known as roadmr
=== dpm-afk is now known as dpm
[18:28] <bdmurray> arges: accepted
[18:28] <arges> bdmurray: thanks
[18:33] <alkisg> Ouch the trusty .iso doesn't fit on a 1 GB USB stick...
=== bfiller_afk is now known as bfiller
[18:42] <cjwatson> alkisg: unfortunate, but probably too late to fix
[18:42] <Logan_> cjwatson: is it worth keeping trafshow if it's dead upstream?
[18:42] <Logan_> ...lol
[18:44] <cjwatson> Logan_: there was no mention of that in the removal request
[18:44] <cjwatson> I'm not going to research upstream status for all of these :)
[18:45] <alkisg> cjwatson: sure I don't think it'll be an issue, I just didn't notice the `dd` stderr the first time, and it took me a while to figure out why I had boot errors... :)
[18:46] <Logan_> cjwatson: no, of course not - I wouldn't expect that
[18:46] <Logan_> my "lol" was at the fact that we spoke within a second of each other
[18:46] <Logan_> I added a comment to the bug :)
=== dpm is now known as dpm-afk
=== oSoMoN_ is now known as oSoMoN
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== salem_ is now known as _salem
=== Ursinha is now known as Ursinha-afk
=== psivaa-afk is now known as psivaa
=== Ursinha-afk is now known as Ursinha
[21:37] <tjaalton> infinity: ok I'm here
[21:45] <tjaalton> uploaded
[22:06] <infinity> tjaalton: Ta.