[00:04] <tomreyn> hi, i'm trying to understand why there is no libopenal1-dbg in trusty, but can't seem to find any info on it: http://packages.ubuntu.com/search?keywords=libopenal1-dbg
[00:15] <rbasak> tomreyn: looks like it's built without debug info before the package build stripping gets to it.
[00:15] <rbasak> Changing -DCMAKE_BUILD_TYPE=Release for -DCMAKE_BUILD_TYPE=RelWithDebInfo might help. I'm not sure though.
[00:16] <rbasak> "libopenal1 is already stripped, ignoring" is the hint I'm basing my hypothesis on.
[00:16] <tomreyn> rbasak: where do you see this?
[00:17] <rbasak> In the build logs.
[00:17] <rbasak> https://launchpadlibrarian.net/108030443/buildlog_ubuntu-quantal-amd64.openal-soft_1%3A1.14-4ubuntu1_BUILDING.txt.gz
[00:18] <tomreyn> thanks. i would not have known how to find this (how did you?)
[00:18] <tomreyn> this says "quantal" though?
[00:19] <tomreyn> same version as trusty though
[00:19] <rbasak> Start from https://launchpad.net/ubuntu/trusty/+package/libopenal1
[00:20] <rbasak> (since that's the information you know - release and binary package name)
[00:20] <rbasak> Click through to source package: https://launchpad.net/ubuntu/+source/openal-soft/1:1.14-4ubuntu1
[00:20] <rbasak> You can see the build information there, per architecture.
[00:21] <rbasak> It was built back during the Quantal development cycle, and the binary got copied forward through to Trusty since it didn't change since then.
[00:21] <rbasak> If the published version number is identical, the published binary is identical.
[00:22] <tomreyn> openal-soft (1:1.14-4ubuntu1) quantal; urgency=low
[00:22] <tomreyn>   * Merge from Debian testing.  Remaining changes:
[00:22] <tomreyn>     - Add a symbols file for libopenal1
[00:22] <tomreyn> :)
[00:22] <tomreyn> thanks for explaining
[00:23] <rbasak> That's different. A symbols file is to do with the symbols a shared library exports, not debugging information.
[00:23] <tomreyn> oh .a
[00:23] <rbasak> It would be reasonable to file a bug in Debian asking to use RelWithDebInfo instead of Release, assuming that fixes it.
[00:23] <rbasak> (as Debian calls dh_strip later anyway)
[00:24] <tomreyn> hmm yes looks like wheezy is lacking it, too
[00:25] <rbasak> Oh - looks like it's been fixed since. You get a -dbg package in Vivid.
[00:26] <tomreyn> yes later versions have it in either distro
[00:26] <tomreyn> (earlier, too)
[00:27] <rbasak> OK - so I think just rebuild locally with RelWithDebInfo and you should get them.
[00:27] <tomreyn> thanks
[00:28] <rbasak> No problem.
[00:41] <tomreyn> rbasak: could you hint me on what's the quickest way to rebuild the package with -DCMAKE_BUILD_TYPE=RelWithDebInfo ? i apt-get source libopenal1, edit CMakeLists and then...?
[00:47] <rbasak> tomreyn: probably with a PPA is the easiest. apt-get source, edit debian/rules (not CMakeLists), run dch and add a changelog entry, call the version number 1:1.14-4ubuntu1ppa1 or something so a security update will trump it.
[00:47] <rbasak> Then run dpkg-buildpackage -S -sd -nc. You'll need a gpg key set up.
[00:47] <tomreyn> rbasak: i'm just interested in trying it once now, it doesn't need to survive
[00:48] <rbasak> Set up a PPA on Launchpad, then eg. dput ppa:tomreyn on the source changes file.
[00:48] <rbasak> I suppose you could use apt-get build-dep libopenal1 to install all the build dependencies, then dpkg-buildpackage -us -uc to build locally.
[00:49] <rbasak> I tend not to install build deps locally for every package but it might make sense for you.
[00:50] <tomreyn> thanks again. the reason i'm trying to is this crash in supertuxkart: https://tomreyn.megaglest.org/stk_1e0a9022a30393a5af52cf2f5b5d222c6633aebd_quicksands_nitro_finish.txt
[00:50] <tomreyn> the developers suspect libopenal may not be thread safe
[00:51] <rbasak> Thank you for looking at it.
[00:51] <rbasak> Remember that if you rebuild the package you should use your new libopenal1, not the one from the archive, to make sure the debug symbols match up.
[00:53] <tomreyn> that's a good reminder
=== SpamapS_ is now known as SpamapS
=== slangase` is now known as slangasek
=== work_alkisg is now known as alkisg
[05:38] <alkisg> Good morning
=== Logan_ is now known as Logan
=== alkisg is now known as work_alkisg
[07:03] <darkxst> pitti, systemd init is getting stuck bringing up eth0 here now (its just a dhcp config in /etc/network/interfaces)
[07:30] <dholbach> good morning
=== work_alkisg is now known as alkisg
[07:54] <alkisg> mvo: hi, in LP #1415785 we've included a branch with the proposed patch, we put the appropriate [SRU headers] for the test case, regression potential etc, and assigned it to you. Could you have a look please and tell me if something is amiss, or sponsor it if it's OK? Thanks!
[07:54] <ubottu> Launchpad bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [High,Confirmed] https://launchpad.net/bugs/1415785
[07:55] <alkisg> It's only needed in 12.04, I think the whole dist-upgrade functionality got removed from update-manager in 14.04+, in any case ltsp isn't mentioned in -trunk at all anymore
[07:56] <mvo> alkisg: sure! thanks for doing this. so this just needs a sru into 12.04, correct?
[07:56] <alkisg> Correct
[07:56] <mvo> cool, I look at it in a bit
[07:56] <alkisg> Thank you
[08:05] <pitti> darkxst: stuck? which systemd version is that? can you please boot with debug shell (see /usr/share/doc/systemd/README.Debian) and see "systemctl jobs", and get me systemctl status -l <job> for the hanging ones?
[08:07] <darkxst> pitti, 218-6ubuntu1
[08:08] <darkxst> pitti, it just sits waiting for network, I'll reboot now
[08:11] <pitti> yay, there's a new version of patch which should fix the symlink mess (php, glibc, etc.)
[08:12] <pitti> rbasak, infinity ^ FYI; I'll retry the slew of failues
[08:30] <darkxst> pitti, http://pastebin.com/FPgYidgt
[08:31] <darkxst> though the message is something like 'a job is waiting on startup of ifup on eth0'
[08:32] <pitti> darkxst: oh, is "systemctl reload smbd.service" hanging?
[08:32] <LocutusOfBorg1> hi developers!
=== alkisg is now known as work_alkisg
[08:37] <pitti> rbasak: ok, the remaining regression is https://jenkins.qa.ubuntu.com/job/vivid-adt-php-horde-serialize/lastBuild/? which is real; the rest succeeds now
[08:37] <darkxst> pitti, maybe, and seems racy when I boot with systemd.debug-shell
[08:37] <pitti> darkxst: you mean it sometimes succeeds, sometimes not?
[08:38] <darkxst> yes it succeeds with that, but not without
[08:38] <pitti> darkxst: do you have some actual smbd config, or is that just installed with the defaults?
[08:38] <pitti> darkxst: oh, go heisenbug.. so in the pastebin you showed me it did not actually hang?
[08:38] <darkxst> pitti, it hung that time
[08:39] <darkxst> took a few boots to get it too hang tho
[08:40] <darkxst> smbd == samba? I do have some samba shares setup,
[08:40] <pitti> darkxst: ok, then I suspect some kind of dependency loop; would you mind filing a bug with the pastebin?
[08:41] <pitti> darkxst: I'll try to reproduce this in a bit; I don't know anything about samba, but perhaps it already reproduces with the default config
[08:42] <darkxst> pitti, ok will do
[08:42] <darkxst> I don't have anything special in my config, just a couple of shares defined
[08:45] <pitti> darkxst: ah, I think I understand why
[08:46]  * darkxst now hitting races in upstart boot ;(
[08:46] <darkxst> (completely unrelated of course)
[08:47] <pitti> so smbd hooks into DHCP hooks which reload samba which triggers /etc/init.d/smbd reload, which Requires: $network
[08:47] <pitti> but $network is precisely the thing that ifup@.service is trying to bring up..
[08:49] <darkxst> pitti, makes sense
[08:54] <darkxst_> pitti, bug 1417010
[08:54] <ubottu> bug 1417010 in systemd (Ubuntu) "systemd init gets stuck reloading smbd.service" [Undecided,New] https://launchpad.net/bugs/1417010
[08:54] <pitti> darkxst_: thanks
=== txspud is now known as txspud|sprint
=== txspud|sprint is now known as txspud
=== asac` is now known as asac
=== mthaddon` is now known as mthaddon
[09:00] <pitti> darkxst_: just to ensure, the boot should continue and finish after 2 mins of waiting, right?
[09:01] <darkxst_> pitti, no, I left if for 20mins early today
[09:01] <pitti> uh, that's a surprise
[09:01] <darkxst_> in face the message says "nolimit" or something
[09:01] <pitti> darkxst_: network-online comes up after 2 minutes, this should satisfy the smbd reload
[09:02] <pitti> darkxst_: could you give me the systemctl list-jobs after 2 minutes?
[09:03] <darkxst_> I think that pastebin would have been atleast after 2 minutes
=== darkxst_ is now known as darkxst
[09:03] <pitti> darkxst: ah, ok; thanks either way, I'll ponder this
[09:08] <darkxst> pitti, I've not hit in any of my VM's but they don't have samba installed
[09:14] <pitti> darkxst: yeah, it doesn't reproduce for me either, but I didn't really configure it
=== alkisg1 is now known as alkisg
=== kickinz1|afk is now known as kickinz1
[09:24] <cjwatson_> Noskcaj: unlikely; somebody who's interested should go for it
[09:24] <ogra_> pitti, do you think we could get this easily SRUed into utopic ? https://launchpad.net/ubuntu/+source/libmtp/1.1.8-1ubuntu2 (just adds HW support)
[09:25] <darkxst> pitti, I will try and reproduce in a VM tomorrow
[09:30] <Noskcaj> cjwatson_, I'll see if i can work a merge sometime this week then
[09:31] <cjwatson_> ok
=== dpm_ is now known as dpm
=== cjwatson_ is now known as cjwatson
[10:14] <pitti> ogra_: sure, that looks totally harmless
[10:14] <ogra_> yup it is ... and i dont want to have to set up a PPA for it
=== mariel is now known as aeoril
[10:41] <LocutusOfBorg1> hi developers, do you know why sqlmap is on debian unstable but not on vivid, neither in the new queue? Am I missing something=?
[10:46] <cjwatson> LocutusOfBorg1: because it was previously deleted and such things require manual action; I'll bring it back
[10:47] <cjwatson> (logged in http://people.canonical.com/~ubuntu-archive/auto-sync/current.log)
[10:52] <LocutusOfBorg1> thanks as usual cjwatson this is why I asked, because I was wondering about that manual hint ;)
=== ahasenac` is now known as ahasenack
[10:57] <rbasak> pitti: thanks. Looking.
=== roaksoax_ is now known as roaksaox
=== roaksaox is now known as roaksoax
[11:07] <sitter> TheMuso, didrocks: is it intentional that the pulseaudio from here has the flat-volume disabling disabled? https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions/+packages
[11:19] <didrocks> sitter: I'll let TheMuso answer, I have no clue about the changes besides bluetooth
[11:22] <sitter> I best leave this here for reference as well http://paste.ubuntu.com/10013864/ ^^
[11:38] <rbasak> pitti: I can't reproduce the php-horde-serialize failure locally (in adt-virt-lxc). What locale does the environment use, please? I tried C.UTF-8, still passing locally.
[11:50] <pitti> rbasak: trying to run here
[11:50] <rbasak> Thanks. I've since tried C as well. Also I realised I was rebuilding locally, but using -B doesn't help (still passes).
[11:50] <pitti> rbasak: C.UTF-8 is the default locale indeed
[11:51] <rbasak> There is https://bugs.launchpad.net/ubuntu/+source/php-json/+bug/1287726 which may be related. Also I see a new upstream release that changes some of the handling around the failure case, but of course that passes for me locally too so I can't tell if it fixes anything we need.
[11:51] <ubottu> Launchpad bug 1287726 in php-json (Ubuntu) "Wrong evaluation whether json is valid or not" [Medium,Triaged]
[11:53] <pitti> rbasak: I get the exact same failure in schroot
[11:53] <pitti> adt-run --apt-pocket=proposed -U php-horde-serialize --- schroot vivid
[11:53] <pitti> qemu is still running
[11:53]  * pitti runs in lxc too, for fun
[11:53] <pitti> rbasak: qemu failed too (adt-run --apt-pocket=proposed -U php-horde-serialize --- qemu /srv/vm/adt-vivid-amd64-cloud.img)
[11:53] <pitti> rbasak: ah, lxc doesn't currently work for me :/
[11:54] <rbasak> I've not been using --apt-pocket=proposed either. Seems obvious to me.
[11:55] <pitti> rbasak: ^ I can't interpret this -- don't you want to test with the php5 in -proposed?
[11:55] <rbasak> Thanks - I'll use adt-virt-schroot. I didn't know thta existed!
[11:55] <pitti> that's what triggers the regression, no?
[11:55] <rbasak> pitti: sorry. I mean that I failed to use --apt-pocket=proposed, when obviously I should be doing so.
[11:55] <pitti> ah :)
[11:55] <rbasak> I've got away with never using that option ever and not really knowing about it somehow.
[11:55] <rbasak> I shall amend my ways :)
[11:56] <pitti> rbasak: ah, lxc finished too, same failure; doesn't look sensitive to the build env
[11:56] <rbasak> adt-run --apt-pocket=proposed -B php-horde-serialize_2.0.2-5.dsc --- adt-virt-lxc -es vivid
[11:56] <rbasak> This passes for me :-/
[11:56] <pitti> rbasak: I suppose you could also give it some locally built 5.6 php debs to run with; if you them, that's faster than --apt-pocket + -U
[11:56] <pitti> rbasak: ah, you need -U (aka --apt-upgrade)
[11:57] <pitti> rbasak: apt-pocket merely fiddles with the apt sources; I figure that could be considered a bug
[11:57] <rbasak> I see.
[11:57] <rbasak> OK
[11:57]  * rbasak tries again
[11:57] <pitti> rbasak: so I guess schroot will be fastest
[11:58] <rbasak> I tend to use lxc so I don't have to worry about whether schroot is sufficient or not, since most of my work involves needing server daemons to work.
[11:58] <pitti> right, that shouldn't be noticeably slower
[11:58] <rbasak> I hadn't looked to see if this test is actually using it, but I did see it installing apache2
[11:58] <rbasak> Yeah the speed difference is only a few seconds per virt driver reset
[11:59] <rbasak> adt-run -U -B php-horde-serialize_2.0.2-5.dsc --- adt-virt-lxc -es vivid
[11:59] <rbasak> Still passes!
[11:59] <rbasak> I'll try schroot
[11:59] <pitti> rbasak: you forgot the --apt-pocket=proposed now :)
[11:59] <pitti> rbasak: you need both that and -U to actually upgrade
[11:59] <rbasak> Aargh. Sorry.
[12:00] <pitti> rbasak: and add -s while you're at it :)
[12:01] <rbasak> I don't use -s by "default" since I often use -o and that breaks it.
[12:01] <pitti> ogra_: smurfice!
[12:01] <ogra_> haha
[12:01] <rbasak> Usually I just poke at the source and rerun the whole thing.
[12:02] <pitti> rbasak: oh, I thought I fixed that
[12:02] <rbasak> Maybe you did.
[12:02] <rbasak> My habits may be a little outdated.
[12:03] <rbasak> BTW, while we're chatting, I usually use uvtool to create myself a qcow2 image to use against adt-virt-qemu, rather than your script.
[12:03] <rbasak> For that, I just need a cloud-init userdata that works.
[12:03] <rbasak> http://paste.ubuntu.com/10014410/ is what I use, adapted from your script.
[12:04] <rbasak> It'd be nice to maintain that independently in the autopkgtest source somewhere.
[12:04] <pitti> rbasak: ah, do you use /usr/share/autopkgtest/adt-setup-vm with that?
[12:04] <rbasak> Eventually I'd like to make it one command in uvtool to produce a VM image file based on a userdata file.
[12:04] <pitti> rbasak: that's where I keep all the actual VM setup now, so that it can be called from cloud-init, vmdebootstap, or even just manually if you have an arbitrary install
[12:04] <rbasak> pitti: no - I use uvtool instead, with the userdata separately.
[12:04] <pitti> rbasak: e. g. I can run that in a standard sid install and then use that VM for adt
[12:05] <pitti> rbasak: well, it's not an "instead" -- this is a script to run inside a VM, it's not about setting up the VM itself
[12:06] <rbasak> pitti: ah I see - I'm behind again and didn't know about that script - thanks.
[12:06] <rbasak> I'd like that to be one command using uvtool in the future too.
[12:07] <rbasak> pitti: OK, reproduced the failure now. Thanks!
[12:08] <pitti> rbasak: right, it's meant to be that shared resource; please let me know if it needs any adjustment for running under uvtool
[12:09] <rbasak> pitti: will do. It'll be a while before I can task switch to uvtool again though :-(
=== _salem is now known as salem_
=== ara is now known as Guest32645
[13:46] <tsdgeos> mitya57: Mirv: we can set https://bugs.launchpad.net/ubuntu/+source/gammaray/+bug/1395646 as fix commited since gammaray is compiling fine on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages no?
[13:46] <ubottu> Launchpad bug 1395646 in gammaray (Ubuntu) "gammaray fails to build against Qt 5.4.0 beta" [Undecided,Triaged]
[13:47] <mitya57> tsdgeos: done
[13:48] <tsdgeos> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.4 is looking not that bad :)
[13:53] <mitya57> tsdgeos: thanks for your work on that!
[13:53] <pitti> rbasak: oh, fixed now, nice work!
[13:54] <rbasak> pitti: no problem. Latest minor upstream release (not yet in Debian) already had a fix, so I just pulled that in.
[13:55] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 -> Valid candidate \o/
[13:55] <pitti> rbasak: nice work!
[13:55] <rbasak> :)
[13:55] <pitti> the patch thingy disrupted this quite a bit :/
[13:55] <rbasak> Two uninstallables left for migration. I just uploaded them. Hopefully it'll all migrate now, just waiting for it.
[13:57] <rbasak> For some reason "chdist bin2src vivid ..." gives me blank output on about three packages. No idea why and I haven't looked into it, but that's why I missed them the first time.
[14:03] <Mirv> tsdgeos: indeed
[14:06] <aeoril> How important is it that I get my PGP key signed via photo id in person?  What exactly will I need that step for?
[14:06] <tsdgeos> Mirv: mitya57: should we set https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1398372 as fix commited since the tests are being tracked on https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1403420 ?
[14:06] <ubottu> Launchpad bug 1398372 in ubuntu-system-settings-online-accounts (Ubuntu) "webbrowser + u-s-s-online-accounts + ubuntu-html5-theme fail to build against Qt 5.4" [Undecided,Triaged]
[14:06] <ubottu> Launchpad bug 1403420 in Online Accounts setup for Ubuntu Touch "u-s-s-online-accounts fails all UiProxyTest with Qt 5.4" [High,Triaged]
[14:07] <rbasak> aeoril: that depends. Why do you think you need to do that? For Ubuntu development, you don't. To be involved in Debian, you do (eventually).
[14:08] <Mirv> tsdgeos: yes, the former was about the private header usage
[14:08] <aeoril> rbasak I was just following this howto guide and it showed that step:  https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[14:09] <tsdgeos> Mirv: ok, done
[14:09] <aeoril> rbasak that is why I was asking, I didn't know if I needed to or not
[14:10] <aeoril> rbasak I was hoping eventually to do kernel/driver development.  Would I need it for that?
[14:10] <rbasak> aeoril: so just for general gpg use? It's useful to be able to find trust paths across the web, but I don't think that feature is used particularly often in practice.
[14:10] <rbasak> aeoril: you can contribute without having a trust path.
[14:11] <aeoril> rbasak I am planning on developing for the ubuntu community, in the kernel, driver, etc. areas
[14:11] <aeoril> rbasak ok, good to know
[14:11] <rbasak> It's fine then. You don't need it. I wouldn't worry about it. Take an opportunity to sign keys if the opportunity arises, but I wouldn't bother seeking it out.
[14:12] <aeoril> rbasak ok, thank you very much
[14:31] <pitti> tjaalton: latest mesa drops libopenvg1-mesa-dev, but qtbase-opensource-src{,-gles} still build dep on that; what's the replacement?
[14:34] <pitti> jibel: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zope.interface is a similar problem that we had last week: zodb always failed on amd64, succeeds on i386, but is regarded as a regression
[14:34] <pitti> jibel: did you happen to see what was wrong with those, or should I nudge it manually?
[14:44] <tjaalton> pitti: there is none, I'll check qtbase-opensource-src*..
[14:45] <pitti> tjaalton: ah, thanks
=== mwenning is now known as mwenning-wfh
[14:50] <jibel> pitti, I didn't find the reason yet, can you fix it manually please?
[14:51] <pitti> jibel: yep, done
[15:22] <tjaalton> pitti: looks like it takes quite a while to build.. hasn't failed after just dropping that BD
[15:22] <tjaalton> so far..
[15:23] <pitti> tjaalton: I wouldn't expect it to fail
[15:23] <pitti> tjaalton: it builds on hurd without it, but configure detects availability
[15:23] <pitti> OpenVG auto-detection... ()
[15:23] <pitti> [...]
[15:23] <tjaalton> ah, right
[15:23] <pitti> OpenVG enabled.
[15:24] <pitti> <https://launchpadlibrarian.net/195952397/buildlog_ubuntu-vivid-amd64.qtbase-opensource-src_5.3.2%2Bdfsg-4ubuntu9_UPLOADING.txt.gz>
[15:24] <tjaalton> well changelog doesn't tell why it was added
=== charles_ is now known as charles
[15:24] <pitti> so it's not really a question of "builds" but whether we actually need/want this?
[15:24] <pitti> Riddell: ^ do you happen to have an idea about this?
=== ken_ is now known as kenvandine
=== tyhicks` is now known as tyhicks
[16:11] <bdmurray> mvo: do you want to have a look at bug 1415785 or shall I?
[16:11] <ubottu> bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [High,Confirmed] https://launchpad.net/bugs/1415785
=== seelaman` is now known as seelaman
[16:20] <mvo> bdmurray: I uploded it to proposed already
[16:21] <bdmurray> mvo: okay, cool
[16:21] <mvo> bdmurray: thanks!
[16:32] <shadeslayer> mvo: synaptic poke?
[16:33] <mvo> shadeslayer: uploaded this morning, waiting in the proposed queue :)
[16:33] <shadeslayer> aha :)
[16:33] <ogra_> heh, a poke from the past
[16:33] <shadeslayer> thx
[16:33] <smoser> infinity, i dont really know how i'm going to test trusty + https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1374568
[16:33] <ubottu> Launchpad bug 1374568 in slof (Ubuntu Trusty) "network boot doesn't work (need newer slof.bin)" [Medium,Fix committed]
[16:34] <infinity> smoser: Install the trusty deb on utopic, if utopic is where you can actually test?
[16:34] <infinity> smoser: Have to be a bit creative when doing backport in steps like this. :/
[16:34] <infinity> s/backport/backports/
[16:34] <smoser> :)
[16:34] <smoser> well, it hardly is validating "trusty"
[16:34] <smoser> if i do the test on utopic.
[16:35] <smoser> the other path was to grab the utopic qemu-system-ppc , which i think has a chance here.
[16:36] <infinity> smoser: It's validating the binary in the deb.  In the case where its only use it to be sideloaded in a VM, that works.
[16:37] <infinity> smoser: qemu-system-ppc64 on x86 would work too, it's just slow.
[16:38] <smoser> i dont think it works.
[16:39] <infinity> smoser: I know it does.
[16:59] <xnox> didrocks: systemd[1]: Failed to populate transient preset unit settings, ignoring: Invalid argument
[16:59]  * xnox is =(
=== brendand is now known as road-slightly-ru
=== road-slightly-ru is now known as brendand
[17:05] <didrocks> xnox: that's on your experiment? I thought you didn't go on on it
[17:05] <xnox> didrocks: well, i'm trying to benchmark how slow it is.
[17:05] <xnox> didrocks: and it looks strange at the moment
[17:06] <didrocks> weird :/
[17:34] <nemo> hey Nexia, have you passed the situation on to them already?
[17:34] <Nexia> nope
[17:34] <nemo> ok
[17:35] <Nexia> I'd rather leave that to you who knows more of what you're talking about (:P)
[17:35] <nemo> so... briefly, Nexia here has an RT5390 wireless card messed up on his 64 bit ubuntu 14.10 install. Looking through forums and Launchpad, we see reports going back over 2 years, including a patch for 64 bit support showing up in a number of threads...
[17:35] <nemo> (patch to the manufacturer driver)
[17:36] <nemo> However, all the launchpad bugs I could find, even the ones where a comment described patching, were closed out for various reasons
[17:36] <nemo> the precise laptop in the bug was recalled, or the bug was just marked expired, or in one case the bug is there, but with no comments or followup (that one is a mint bug)
[17:37] <nemo> So... given that there seems to be a fix, and that this wireless card seems to still be broken, years later, I was wondering if one of the bugs could be resurrected...
[17:38] <nemo> Comment #14 on this bug describes patching... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759
[17:38] <ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
[17:38] <nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178545  similar bug that was marked won't fix due to the laptop model
[17:38] <ubottu> Launchpad bug 1178545 in linux (Ubuntu) "Wireless Card - Ralink RT5390 [1814:5390] does not work properly with Network manager" [Low,Won't fix]
[17:39] <nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759#yui_3_10_3_1_1422897152203_434  direct link to the comment.  Woooo! Launchpad has IDs on comments now!  Used to be there was no way to reference a comment in the scope of the bug.  Now I can do it, even if it requires inspecting the HTML :p
[17:39] <ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
[17:41] <sarnold> ooo
[17:41] <sarnold> nemo: aww, nuts, it doesn't appear to be 'stable' -- your url didn't work for me :(
[17:41] <rbasak> nemo: it's had that for a long time. Right click on the comment number on the right hand side, and save the link. Is this something newer on top of that that I'm missing?
[17:41] <rbasak> Eg. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759/comments/49
[17:41] <ubottu> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
[17:42] <sarnold> rbasak: the intention of the url is to -scroll- the main bug to the correct comment -- that's just _one_ comment, without context, and it's a bit annoying to see where it fits amongt he others
[17:42] <rbasak> Ah, I see.
[17:42] <sarnold> I know, I missed it at first too until I saw that the url was quite ugly :) hehe
[17:42] <TJ-> nemo: The patch you referred to; there's a newer version for kernel 3.15+ also, at http://gridlox.net/diff/rt5592sta_fix_64bit_3.15.patch. Might be worth adding that info to the bug report
[17:43] <nemo> sarnold: yeah, I'm used to that working on most forums and bug systems like bugzilla.  Never worked on launchpad which sucked.
[17:43] <nemo> sarnold: well, once upon a time browsers supported XPath syntax for that, but it got removed as one of those advanced features hardly anyone used
[17:43] <cjwatson> Could somebody file a bug against Launchpad itself for this, please?
[17:44] <nemo> sarnold: luckily most sites are pretty good w/ the IDs ☺
[17:44] <rbasak> That sounds pretty trivial to add though, for anybody inclined. The comments are already numbered, so just need to add an anchor tag.
[17:44] <nemo> rbasak: that'd be pretty cool, I've suffered this one for years ☺
[17:44] <cjwatson> Actually, hang on, maybe I found it
[17:44] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/627252
[17:44] <ubottu> Launchpad bug 627252 in Launchpad itself "no comment permalinks for issue comments" [Low,Triaged]
[17:44] <nemo> heh
[17:44] <cjwatson> See also https://bugs.launchpad.net/launchpad/+bug/124166
[17:44] <ubottu> Launchpad bug 124166 in Launchpad itself "browsing to bug comment permalink should show comment in context" [Low,Triaged]
[17:45] <nemo> Actually, I'd prefer that to direct link to the comment which is usually not nearly as useful
[17:45] <sarnold> nemo: direct link is the best/easiest/only? way to see the entire comment when it's quite long..
[17:45] <nemo> sarnold: oh. you guys trim long comments in-place? ☹
[17:45] <sarnold> nemo: yeah :/
[17:45] <nemo> sarnold: most systems don't do that. bugzilla etc.
[17:45] <nemo> sarnold: can't use JS expand/collapse?
[17:46] <cjwatson> We probably could, yes.
[17:46] <nemo> sarnold: heck. could auto-expand based on the #uniqueid in the URL
[17:46] <cjwatson> We'd also have to work out what to do about cases where bugs with very large numbers of comments are truncated to show only the first 40 and last 40 comments.
[17:47] <sarnold> heh, I've not noticed that before
[17:47] <cjwatson> So it's not quite trivial to put it all together.
[17:47] <nemo> cjwatson: ah, well, the # part does get passed in the request, so could get processed serverside to include it
[17:47] <nemo> hm
[17:47] <nemo> wait. I might be on crack on that front
[17:47]  * nemo doublechecks
[17:47] <cjwatson> I believe you're wrong.
[17:47] <sarnold> yeah I think only local javascript would know what's on the other side of the #
[17:47] <nemo> cjwatson: yep. I'm wrong. damn
[17:48] <nemo> cjwatson: meh... well, could still construct a URL w/ the UID in it, as well as the # part
[17:48] <sarnold> there's always some reason why it's never easy :) heh
[17:48] <nemo> sarnold: eh. that still works ;)
[17:48] <nemo> or just make the link have /all in it
[17:48] <nemo> er. +activity ? whatever
[17:49] <nemo> aaaaaanyway. thoroughly derailed the initial thing, which was seeking help for poor Nexia here
[17:49] <cjwatson> Sure, it's all possible
[17:49] <cjwatson> If I were Nexia I would just file a new bug and explain the history.
[17:49] <nemo> I'm gonna hazard a guess that he'd like to avoid building his own driver off the patch, even w/ exact instructions, given he's kinda new to Linux
[17:49] <cjwatson> Probably better than making some poor developer wade through a load of ancient stuff.
=== Nexia is now known as Nexiazz
[17:49] <nemo> hm
[17:49] <nemo> guess he's off to bed now
[17:50] <nemo> he's a... teenager? on indian time.
[17:50] <nemo> cjwatson: hm well. the others were closed incorrectly IMO
[17:50] <nemo> so reopening doesn't seem that inappropriate...
[17:50] <cjwatson> That's as may be, I haven't waded through them myself
[17:50] <nemo> but, eh, whatev.
[17:50] <ogra_> we're all teenagers !
[17:50] <ogra_> (inside)
[17:50] <Nexiazz> Good night, sorries. and all the help is appreciated :)
[17:50] <cjwatson> But new bugs are pretty cheap, and it's easier to mark a new bug as a duplicate than it is to split off a section of an existing bug
[17:50] <nemo> Nexiazz: so, yeah, cjwatson wants you to file a new bug and hope this one gets love ☺
[17:51] <cjwatson> (But I'm not a kernel developer, so.)
[17:51] <nemo> Nexiazz: maybe we can spam it here in #ubuntu-devel to raise the profile 😃
[17:51] <cjwatson> #ubuntu-kernel is more likely to actually be noticed by somebody useful.
[17:51] <nemo> Nexiazz: if you like, I can try to help you w/ those manual patch instructions from 2013...
[17:51] <nemo> ah
[17:51] <Nexiazz> hm, I'll think it over tomorrow (can't think properly even if I wanted to, tbh)
[17:51] <nemo> cjwatson: LocutusOfBorg1 fired us off to here ☺
[17:51] <Nexiazz> atm*
[17:51] <nemo> Nexiazz: 'k. gn
[17:51] <cjwatson> *shrug*
=== pgraner is now known as pgraner-afk
[18:02] <LocutusOfBorg1> I wasn't aware of #ubuntu-kernel :)
=== tlyu_ is now known as tlyu
[20:06] <Noskcaj> Can someone please look at bug 1417253
[20:06] <ubottu> bug 1417253 in rt-extension-assettracker (Ubuntu) "[RM] Please remove rt-extension-assettracker from the archive" [Undecided,New] https://launchpad.net/bugs/1417253
=== kickinz1 is now known as kickinz1|afk
[20:50] <TheMuso> sitter: Yes, we have had flat volumes disabled in pulse for several years now in Ubuntu. I suggest you search throught eh changelog to find the bug number where this was discussed.
[20:52] <TheMuso> sitter: Here, bug numbers where this is discussed: bug 403859 and bug #433209..
[20:52] <ubottu> bug 403859 in pulseaudio (Ubuntu) "Karmic - sound level gets lowered when opening new sound files" [Undecided,Fix released] https://launchpad.net/bugs/403859
[20:52] <ubottu> bug 433209 in pulseaudio (Ubuntu) "app volume muted when volume slider is non zero" [Undecided,Fix released] https://launchpad.net/bugs/433209
[20:54] <ari-tczew> I have a question to FTBFS and dep-waiting. If package "A" has got dep-waiting (architecture "X") on package B, but that package ("B") doesn't provide binaries for architecture "X". Can we just add missing architecture to package "B" and build it?
=== roadmr is now known as roadmr_afk
[21:19] <aeoril> I have a problem running Ubuntu 14.04.01 under VMWare *or* Hyper-V on a Windows 8.1 machine.  I have scripts that pop-up a new bash shell then run vi with the geometry different than default (e.g., gnome-terminal --geometry 156x48+80+50 -e "/usr/bin/vi .bashrc"
[21:19] <aeoril> This works fine on my native Ubuntu machine running 14.04 LTS, but when I do it in either of those VM environments on Windows 8.1 the text in vi is scrolled down approximately to the line just after what would be the line in a bash window that uses the default size, about one default window's worth of lines is displayed in vi, then I have to scroll line by line down until I see a full
[21:19] <aeoril> page worth of text and it works normally after that
[21:20] <aeoril> I have looked around quite a bit and cannot find any bug like this in google, and have looked a little in launchpad bug browser and so far have not seen this bug
[21:24] <aeoril> I want to report a bug and try to work on this problem.  I am having a hard time reducing the number of bugs reported in my searches for this bug on launchpad.  Is that normal?  Should I wade through all the bug reports before placing my own?  I guess whoever triaged the bug would have to do that anyway?
[21:29] <aeoril> searching further in launchpad bug browser, the search term "vim resize" found no similar bug - I think I am safe to file a bug report and will not find one like mine.  Should I go ahead and do that?  I have never filed a bug report before, so am a little hesitant
[21:48] <jderose> so i want to help test 14.04.2, but it seems the latest daily trusty ISO still doesn't have the *-lts-utopic packages pre-installed. is there some other location where these ISOs are getting staged?
=== roadmr_afk is now known as roadmr
[21:56] <aeoril> jderose what are the *-lts-utopic packages exactly?
[21:59] <ahoneybun> http://www.jupiterbroadcasting.com/76592/how-non-devs-can-help-linux-las-350/
[22:03] <dobey> jderose: i don't see any xorg packages in the archive yet. only the kernel seems to be in so far :-/
[22:06] <jderose> dobey: thanks. so the x and mesa packages are in proposed... and the daily iso has proposed enabled, for this reason i assume
[22:07] <jderose> dobey: but there's no magic, special place when ISOs are being staged? :)
[22:07] <dobey> jderose: cdimage.u.c is all i know
[22:08] <jderose> aeoril: the hardware enablement packages for 14.04.2... basically the utopic kernel, x, and mesa packages backported to trusty
[22:09] <aeoril> what are the mesa packages?
[22:09] <aeoril> (I understand what "kernel and x" are)
[22:09] <aeoril> jderose ^
[22:11] <jderose> aeoril: mesa is an open source opengl/egl implementation for 3d graphics - http://packages.ubuntu.com/trusty/libegl1-mesa-drivers
[22:13] <aeoril> jderose ahh, ok - thanks.  cdimage.ubuntu.com seems very slow for me right now
[22:13] <jderose> yeah, super slow for me today also. but i'm in the us, so maybe just the wrong side of the pond :)
[22:13] <aeoril> jderose I was just wondering about that - I am in USA too
[22:14] <dobey> slow in what sense?
[22:14] <jderose> dobey: slow as in downloading at like 14k or thereabouts
[22:15] <aeoril> dobey for me, there is latency in getting the directory listings.  I have not tried downloading yet today - it was plenty fast yesterday
[22:15] <dobey> i'm getting 2+ MB/s right now :)
[22:15] <aeoril> dobey *very* slow
[22:15] <aeoril> dobey where are you?
[22:15] <dobey> well, now down to 1, but i am streaming youtube hd at the same time too
[22:15] <dobey> usa
[22:15] <aeoril> where in the USA?
[22:16] <dobey> on 150Mbps fiber
[22:16] <dobey> east coast
[22:16] <aeoril> hmmm ... I am in the middle - going to ping ...
[22:18] <aeoril> dobey ping shows 131 ms
[22:18] <dobey> yeah
[22:19] <aeoril> ahoneybun I looked at your link and it seemed like a lot of ads ...
[22:19] <ahoneybun> aeoril, shows cost money
[22:23] <aeoril> dobey jderose it seems fine now (at least for browsing the listings)
[22:34] <Noskcaj_> Can someone please rebuild opensm's r-deps? allows it to migrate from proposed
=== salem_ is now known as _salem
[22:38] <Noskcaj_> stgraber: bdrung: Would you have time to vote on my MOTU and xubuntu-packageset application?
[22:55] <aeoril> Noskcaj We chatted yesterday.  I am new to Ubuntu development.  You mentioned you could help me with a bug if I found one I wanted to work on.  I have, and was wondering if the offer was still open