[00:32] <robru> anybody from the release team around? i'm confused by the status of python2.7 in update_excuses. 2.7.6-2ubuntu1 fixes a big regression for us, we need that ASAP
[00:36] <rsalveti> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libffi failed autopkgtest
[00:36] <rsalveti> which seems to be holding python2.7
[00:38] <rsalveti> there was a sync from git-annex today, which is holding everyone
[00:39] <robru> rsalveti, is it something you can fix? who do we ping about this?
[00:40] <rsalveti> let me first try to understand why it's failing
[00:40] <robru> rsalveti, ok, brb. ping me if you need help testing anything.
[00:41] <rsalveti> seems the tests are all fine, but the ret code is not 0
[00:44] <xnox> rsalveti: let me look at annex failure.
[00:44] <xnox> rsalveti: i've fixed it before....
[00:45] <rsalveti> xnox: ok, cool
[00:47] <xnox> rsalveti: i see http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-git-annex/10/ARCH=amd64,label=adt/artifact/results/dsc0t-basics-stderr/*view*/ that no tests run, since new version was uploaded.
[00:48] <rsalveti> right https://jenkins.qa.ubuntu.com/job/trusty-adt-git-annex/ARCH=amd64,label=adt/10/console
[00:49] <rsalveti> indeed, was opening the last successful one
[00:50] <xnox> Laney: stgraber: can you mark up git-annex as bad tests? I've opened block-proposed bug #1256143 to make sure that git-annex doesn't migrate, but such that dependencies are unblock to migrate?
[00:50] <ubot2> Launchpad bug 1256143 in git-annex (Ubuntu) "adt tests borked in -proposed" [High,Triaged] https://launchpad.net/bugs/1256143
[00:52] <xnox> rsalveti: are you touch-release?
[00:52] <xnox> rsalveti: touch-release can also mark up git-annex as badtests
[00:52] <rsalveti> xnox: nops
[00:52] <rsalveti> cyphermox: ?
[00:53] <rsalveti> maybe even robru
[00:54] <xnox> rsalveti: hm, possibly britney will request git-annex trusty-release pocket adt tests and everything will work. this is what happened, last time i requested a block-proposed bug.
[00:56] <xnox> rsalveti: actually git-annex is not the only problem. libffi is out of date on powerpc
[00:56] <xnox> rsalveti: and python2.7 is invalidated by dependency on libffi.
[00:57] <rsalveti> yeah, ftbfs for ppc
[00:57] <robru> rsalveti, xnox: i dunno anything about that...
[00:58] <xnox> rsalveti: robru is not in https://launchpad.net/~ubuntu-touch-release/+members
[00:58] <xnox> rsalveti: anyway, libffi/powerpc should be fixed.
[00:58] <robru> cyphermox, you around? we need you ^^
[00:59] <rsalveti> there's no git-annext test anymore
[00:59] <xnox> robru: even if git-annex is forcedbad tests, libffi must be fixed, cause otherwise there will be huge archive skew.
[00:59] <rsalveti> seems they removed the test option with latest version
[01:00] <robru> xnox, any idea how to fix libffi? i've no idea
[01:00] <xnox> robru: rsalveti: well ffi has missing symbols. not sure why/how.
[01:57] <xnox> infinity: git-annex test-suite is pending more haskell "echo test suite currently disabled until haskell-tasty is out of NEW"
[01:58] <xnox> infinity: can you please mark git-annex as badtest? git-annex itself is blocked from migrating by my block-proposed bug, such that we will get new git-annex, only once it has autopackagetest again, but such that it doesn't block the world.
[01:58] <xnox> (well speficially python2.7 and libffi)
[01:59] <infinity> xnox: Can do.
[01:59] <xnox> infinity: thanks.
[02:00] <infinity> # git-annex is blocked with a migration bug, don't block its rdeps too:
[02:00] <infinity> force-badtest git-annex/5.20131127.1
[02:00] <infinity> ^-- That look sane?
[02:00] <xnox> coreect.
[02:00] <xnox> correct that is.
[02:01] <infinity> Test-building libffi out of paranaoia, but will upload shortly.
[02:06] <infinity> Alright, I'm not sure who between my ISP and Canonical is screwing with me, but this is unaccetable:
[02:06] <infinity> Fetched 23.0 MB in 4min 1s (95.4 kB/s)
[02:08]  * stgraber read that as MB/s for a second and wondered what infinity was complaining about again
[02:09] <infinity> stgraber: Yeah, no.  This is genuinely busted.
[02:11] <stgraber> infinity: I'm getting somewhere between 15MB/s and 20MB/s from archive.u.c from this side of the country
[02:12] <stgraber> entirely over Level3 from Montreal to the DC in London
[02:12] <infinity> stgraber: Yeah.  I'm getting decent saturation on my link to random speedtest.net servers, but all of archive/ports and us.archive/us.ports are a mess for me.
[02:12] <infinity> (Yes, even the US ones)
[02:13] <infinity> Not sure who to blame.  I'll care deeply if it persists after I move, and start whining.
[02:13] <robru> infinity, you on Shaw? Shaw I think has a vendetta against Ubuntu, they will often drop canonical's netblock right off the network (100% packet loss for days), and most of the rest of the time it's very slwo
[02:14] <stgraber> infinity: interestingly enough I'm only getting 1.5MB/s from us.archive.u.c over IPv4 but I get 50MB/s from the same servers over IPv6...
[02:15] <stgraber> ah, IPv4 from here to Boston goes through Level3 (same path as to London) but then jumps to Cogent in New York which gives me a final route longer than that to London and the speed that's typical for a Cogent provided link...
[02:16] <stgraber> infinity: weren't you using a server in the US for the *.ubuntu.com trafic before?
[02:19] <infinity> robru: I am indeed.
[02:20] <robru> infinity, it's a conspiracy. Microsoft pays Shaw to give us shit service.
[02:20] <infinity> stgraber: I was tunneling through San Jose for a long time, yeah.
[02:20] <infinity> stgraber: (Through the machine I'm IRCing from)
[02:20] <infinity> I may have to go back to doing that.
[02:20] <infinity> But things had been okay for so long.
[02:20] <infinity> *sigh*
[02:22]  * infinity tries to decipher gv.shawcable.net and gives up.
[02:22] <infinity> Greater Victoria?
[02:23] <infinity> Grungy Vatican?
[02:24] <stgraber> Vancouver (if so, you're not heading the right direction ;))?
[02:24] <infinity> stgraber: Vancouver is vc.
[02:24] <infinity> stgraber: But robru lives in Victoria, apparently, so my first guess might be close.
[02:25] <robru> infinity, greater vancouver?
[02:25] <robru> infinity, I used to live in Winnipeg and had problems with Shaw there, too
[02:25] <infinity> robru: If you mean the island and not the city, maybe.  (As I said, Vancouver itself is ".vc." in shaw routing speak)
[02:26] <infinity> Maybe granville.  The few, the proud, the drunk.
[02:26] <robru> infinity, gisland vancouver ;-)
[02:32] <infinity> Hrm.  Something very bad has happened to birch.
[02:32]  * infinity stabs it with a fork.
[02:34] <infinity> xnox: libffi fix uploaded.  Good thing I tested, I missed one spot the first time. :P
[02:35] <infinity> doko_: Feel free to sync my libffi changes to Debian at any point.  Fixes the FTBFS on both powerpc and ppc64.
[03:45] <infinity> final: gambas3,glib2.0,libffi,pypy,python2.7,ruby1.9.1,ruby2.0,witty/arm64
[03:46] <infinity> robru: ^
[06:26] <robru> infinity, sweet, thanks a ton
[10:52] <cjwatson> Could somebody review grub2/precise, please?  It's pretty urgent - there's an OEM deadline of 6 Dec for it to be in updates
[11:19] <xnox> cjwatson: uploaded ubiquity into precise-proposed, only changes are automatic dependency refresh, to pick up all the SRUs.
[11:19] <xnox> (netcfg + partman-*)
[11:20] <cjwatson> xnox: partman-* is broken right now, the discard thing
[11:21] <cjwatson> So I'd been holding off until I got round to fixing that
[11:21] <xnox> ah =(
[11:22] <xnox> then reject that upload.
[11:23]  * cjwatson goes to work on that in Debian
[11:23] <xnox> cjwatson: may then instead cherrypick just partman-auto 101ubuntu2.1 for bug #1065281 ? or shall it just wait for discard fixups?
[11:24] <ubot2> Launchpad bug 1065281 in OEM Priority Project quantal "Installer crashed when trying to partition 4k/4k sector hard disks" [High,In progress] https://launchpad.net/bugs/1065281
[11:24] <xnox> wrong bug number.
[11:24] <xnox> i meant cherry-pick for bug #1197766
[11:24] <ubot2> Launchpad bug 1197766 in OEM Priority Project "Different partition layout after recovery with keep home partition" [Critical,Confirmed] https://launchpad.net/bugs/1197766
[11:25] <cjwatson> Just wait, shouldn't take too long
[11:31] <apw> cjwatson, idly looking at the grub change for recovery mode, i note that in the menu entry itself the 'recovery mode' string isn't internationalised (and never has been) i wonder if it makes sense to use GRUB_RECOVERY_TITLE="$(getext...)"
[11:31] <cjwatson> It was internationalised before, and I did use gettext in the code that uses GRUB_RECOVERY_TITLE
[11:32] <apw> oh now i see that is only for hurd, ignore me :)
[11:32] <cjwatson> +             title="$(gettext_printf "%s, with Linux %s (%s)" "${os}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")" ;;
[11:32] <cjwatson> etc.
[11:32] <cjwatson> Yeah, that wasn't i18ned before in precise (it was in later releases) and I didn't bother to change that in the backport
[11:32] <apw> yeah i am just being dumb and ignoring the filename
[11:33] <apw> sensibly so, doh
[11:33] <cjwatson> xnox: in progress now, I'll just wait for the d-i i18n cron jobs to pick it up
[12:01] <apw> cjwatson, for what it is worth that grub2 diff looks to do what is claimed
[12:02] <cjwatson> Thanks.  Hopefully somebody in ~ubuntu-sru will have a look shortly ...
[12:03] <cjwatson> I dunno, fancy joining that team? :-)
[12:03] <doko> giving one finger, and taking the whole hand ... ;p
[12:03] <cjwatson> I prefer to call it "seeing an opportunity"
[12:04] <apw> :)
[12:28] <sil2100> seb128: thanks for the unity-voice review yesterday! We seemingly fixed all the issues if anything, so, once you have a quant of time... just a glance ;) Thank you and sorry for bothering!
[12:28] <seb128> sil2100, ok, sure, let me have another look
[12:35] <cjwatson> stgraber: queuebot seems ill
[12:35] <cjwatson> I'm sure it should have noticed my partman-basicfilesystems/precise upload from 25 minutes ago by now
[12:35] <apw> perhaps it is eating turkey
[12:41] <doko> cjwatson, pitti, jibel: looking at why gcc-4.8 doesn't migrate ... this looks like a broken 3dpict autopkg test
[12:43] <doko> same for python3.3, broken misaka autopkg test
[13:45] <jibel> doko, I forced results of misaka and 3depict to pass, they failed because their testsuite is broken.
[13:47] <xnox> jibel: i think i'll upload 3depict disabling it's tests. As it doesn't actually test as-installed binaries what's so ever. and if a package FTBFS we will notice it on updates / soname-transitions / archive rebuilds.
[13:49] <jibel> xnox, sounds good, and the maintainer said he wouldn't have time to fix it in the coming weeks.
[13:50] <xnox> jibel: adt compile tests make sense only for libfoo-dev packages, where actual as installed -dev package is test compiled.
[13:50] <xnox> jibel: jenkins does notice when adt tests removed?
[13:53] <jibel> xnox, no it must be removed manually
[13:53] <xnox> jibel: i guess it makes sence, removed adt tests may mean a regression.
[14:04] <jibel> xnox, indeed, there are more cases where adt tests have been removed by mistake than dropped on purpose.
[14:41] <cjwatson> ... ah, another KDE SC upload, that's why my builds aren't happening :-)
[14:49] <timchen119> hi, anyone in sru team can help me on this bug ? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1244065 I'd like this backport to precise.
[14:49] <ubot2> Launchpad bug 1244065 in OEM Priority Project "Add more options to the power settings menu" [Critical,Confirmed]
[15:23] <shadeslayer_> cjwatson: hehe
[15:23] <shadeslayer_> it's the time of KDE SC releases \o/
[15:44]  * ogra_ glares at trusty-changes ... hmmm, 169 mails in 1.5h
[15:44] <ogra_> ok, it's KDE day ...
[15:48] <xnox> wow we have multi-cpu fields =) that's nice
[15:49] <cjwatson> Yep, thanks to wgrant :-)
[15:49] <cjwatson> The queue lengths are wildly wrong now because they don't really know about that, but he said he was going to fix that next week
[15:53] <seb128> timchen119, I've sponsored that g-c-c SRU, with the template on launchpad/translations there, it should be doable as a SRU along the next langpack update
[15:54] <timchen119> seb128, awesome, thanks!
[17:12] <cjwatson> I would suggest not NEWing fakeroot
[17:12] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730792
[17:12] <ubot2> Debian bug 730792 in libfakeroot "libfakeroot: tries to overwrite libfakeroot-sysv.so, which is also in package fakeroot 1.20-1" [Serious,Fixed]
[17:13] <cjwatson> The next auto-sync should bring in -3 and fix it
[17:15] <cjwatson> in fact how about I just reject the binaries
[17:16] <infinity> libfakeroot?  multiarchified fakeroot?
[17:16] <cjwatson> Yeah
[17:16] <infinity> Fancy.
[17:17] <infinity> I wonder what that will end up breaking.
[17:28] <robru> infinity, cjwatson: hey, can you have a look at glib2.0 in update_excuses? there's a failure listed there, but when i click through to the jenkins log, it actually looks like the failure exists with the version already in main, not the version in -proposed. we need to get the version in -proposed released because it fixes a big regression on the phone.
[17:29] <sil2100> seb128: hello! I was browsing through and noticed that some of the glib2.0 autopkg tests seem to be failing - do you know anything about it ?
[17:29] <robru> sil2100, lol ;-)
[17:29] <sil2100> robru: ;D
[17:29] <ogra_> robru, see #ubuntu-desktop, Laney is on it
[17:29] <Laney> haha
[17:30] <sil2100> Laney: thanks!
[17:30] <sil2100> :)
[17:30] <robru> Laney, also thanks ;-)
[17:30] <Laney> Yeah, it doesn't really scale to ping release team guys btw
[17:30] <Laney> can you retry tests?
[17:30] <Laney> I think we should try it again in the hope that it gets the right version ...
[17:31] <robru> Laney, I confirmed on my device that the version in -proposed fixes the regression that got into main
[17:31] <Laney> I believe that part
[17:31] <Laney> the autopkgtests are testing the whole thing though
[17:32] <robru> Laney, i don't understand the failure though. looking here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=amd64,label=adt/ the only red one is 'trusty/main', all the 'trusty-proposed' ones are green
[17:32] <Laney> it tested an old version of the tests against the new library for some reason
[17:33] <infinity> robru: Hrm?  I see a red trusty-proposed/main
[17:33] <infinity> (But yes, the version mismatch thing is a weird oops)
[17:34] <robru> infinity, I see red trusty-proposed here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ but that's a different link
[17:34] <infinity> Also the link that's linked from excuses, so probably the one that matters here. :)
[17:35] <robru> infinity, yeah, but i clicked through to the red amd64 failure and that's where it says the failure is only in main
[17:36] <Laney> robru: do you have permission to retry them one more time?
[17:36] <robru> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=i386,label=adt/ even here the latest trusty-proposed is green
[17:37] <robru> Laney, nope, I only do q-jenkins, that's d-jenkins
[17:40] <cjwatson> BTW please stop saying "main" in opposition to "-proposed" - they're different categories and that's extra-confusing
[17:40] <Laney> Ok, I pinged cj ohnston to retry it once more - if the same happens again then someone can force-badtest it since it has now passed on both architectures
[17:40] <cjwatson> you probably mean "release"
[17:41] <robru> cjwatson, yes, that one
[17:41] <cjwatson> or "trusty" or "the release pocket" or something
[17:41] <cjwatson> "main" is in opposition to "restricted", "universe", "multiverse"
[17:41] <infinity> cjwatson: The confusion is likely because jenkins shows the component, so you see "trusty-proposed/main" and "trusty/main".
[17:41] <cjwatson> this has been a public service announcement on behalf of the commission for confusing terminological schemes
[17:43] <ogra_> lol
[17:43] <Laney> tune your radios to http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/23/ARCH=amd64,label=adt/console
[17:45] <Laney> Seems to have the right tests now
[17:51] <Laney> looks like it passed that time
[17:52] <Laney> if britney doesn't notice that for whatever reason then someone can force-badtest it
[17:52] <Laney> got to go now, see you
[17:53] <robru> Laney, thanks


[00:19] <mwhudson> series_16 = lp.snappy_serieses.getByName(name='16')
[00:19] <mwhudson> series_16.preferred_distro_series is now None
[00:19] <mwhudson> what changed there?
[00:20] <mwhudson> i guess i should forum this, noone is going to be listening now :)
[07:21]  * davidcalle back from hol, morning all o/
[07:23] <Saviq> davidcalle: elo, should've disabled your IRC bouncer for when you were not around ;)
[07:23] <davidcalle> Saviq: hehe :)
[07:26] <Saviq> davidcalle: when you have time, please let us know if you need anything more from us on https://github.com/canonical-websites/developer.ubuntu.com/pull/305
[07:28] <davidcalle> Saviq: I'm going to do a round of testing on this before merging, but hopefully today
[07:52] <mwhudson> zyga-suse: o/
[07:52] <mwhudson> zyga-suse: did you see https://forum.snapcraft.io/t/updating-snapd-in-debian/1645
[07:52] <zyga-suse> hey hey
[07:52] <zyga-suse> no, just waking up and checking things
[07:52] <zyga-suse> agreed on all the exclusions
[07:52] <zyga-suse> looking at pastebin
[07:54] <zyga-suse> replied
[07:54] <mwhudson> thanks
[07:55]  * zyga-suse just edited the list to remove the obvious paste mistakes
[07:56] <mwhudson> i think the fedora packaging ships some of those files in the snap-confine package, unless i'm missing something
[07:56] <zyga-suse> that's legacy
[07:56] <zyga-suse> they should be merged into one package
[08:05] <mwhudson> zyga-suse: are we reasonably sure 2.27 fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872071 ?
[08:05] <mwhudson> zyga-suse: that's the 'hang on configuring core snap' thing
[08:05] <zyga-ubuntu> mwhudson: no, it doesn not
[08:05] <mwhudson> zyga-suse: boo
[08:05] <zyga-ubuntu> mwhudson: we have not identified the reason yet, I believe
[08:06] <zyga-ubuntu> but chose not to block on it because it is an existing bug, not a regression
[08:06] <mwhudson> zyga-suse: it looked like mvo had a favoured theory, did that not turn out to be it?
[08:07] <zyga-ubuntu> mwhudson: not sure I know the theory
[08:07] <mwhudson> zyga-suse: https://forum.snapcraft.io/t/debian-core-configure-hang-on-first-snap-install/1586/6?u=mwhudson
[08:07] <zyga-ubuntu> mwhudson: i think he posted about it
[08:07] <zyga-ubuntu> ah
[08:07]  * zyga-ubuntu reads
[08:07] <mwhudson> i guess i can add that to the changelog after i actually test the debs :)
[08:07] <zyga-ubuntu> ah
[08:08] <zyga-ubuntu> I hope it is asimple as that
[08:08] <mwhudson> oh haha this debian vm called 'debian-stretch-amd64' is actually sid
[08:08] <zyga-ubuntu> yes
[08:08] <zyga-ubuntu> the qemu one is realyl stretch
[08:08] <mwhudson> that saves a step
[08:08] <zyga-ubuntu> the linode one is sid
[08:08] <mwhudson> zyga-suse: no this is a local one
[08:08] <zyga-ubuntu> ah, I see :)
[08:09] <mwhudson> zyga-suse: i need to test https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851473 again too
[08:09] <zyga-ubuntu> I think it will still be the same
[08:09] <zyga-ubuntu> I don't think we took any action on it
[08:09] <mwhudson> probably
[08:11] <mwhudson> well it does this with 2.26.14 from the core snap:
[08:11] <mwhudson> debian@debian:~$ hello.universe
[08:11] <mwhudson> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[08:14] <zyga-ubuntu> that's a new bug, where snapd sees unpatched apparmor and choses not to enable the apparmor backend
[08:15] <zyga-ubuntu> and thus snap-confine does not get its own profile
[08:15] <zyga-ubuntu> but then snap-confine sees the kernel has apparmor enabled
[08:15] <zyga-ubuntu> and it is setuid root
[08:15] <zyga-ubuntu> but the profile is nowhere to be found, so it bails out
[08:21] <zyga-ubuntu> US seems to be a troubled land recently :/
[08:53] <mwhudson> zyga-suse: the hang on configure does indeed seem to be fixed \o/
[08:54] <mwhudson> root@debian:~# hello.universe
[08:54] <mwhudson> /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
[08:54] <mwhudson> wtf!!
[08:54] <zyga-suse> that is great news!!
[08:54] <zyga-suse> the libcap one is interesting
[08:54] <zyga-suse> is snap-confine linking libcap dynamically?
[08:55] <mwhudson> whut
[08:55] <zyga-suse> mwhudson: note that one way to test the hang reliably is to snap install hello while *not* having core
[08:55] <mwhudson> oh
[08:55] <mwhudson> no wait
[08:55] <mwhudson> zyga-suse: http://paste.ubuntu.com/25311128/
[08:56] <mwhudson> zyga-suse: could this be caused by the core that i just downloaded being older than the snapd i have installed?
[08:56] <mwhudson> no
[08:57] <mwhudson> open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[08:57] <mwhudson> i guess this is apparmor being potty again
[08:57] <mwhudson> yea
[08:57] <mwhudson> Aug 14 20:56:57 debian kernel: [ 3608.590506] audit: type=1400 audit(1502701017.760:10): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.25" pid=2365 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[08:57] <mwhudson> lets turn apparmor off for now...
[08:58] <zyga-suse> mwhudson: ah, I think this *is* apparmor
[08:58] <zyga-suse> but wait, didn't you say you disabled apparmor?
[08:58] <zyga-suse> ah, no you enabled it sorry
[08:58]  * zyga-suse is really sleepy still
[08:59] <zyga-suse> so, with older core you will not re-exec
[08:59] <mwhudson> i've disabled it *now* and it works
[08:59] <zyga-suse> and you will use snap-confine from debian
[08:59] <zyga-suse> and you may see profile incompatibility
[08:59] <mwhudson> ah yeah, i think i knew that once
[08:59] <zyga-suse> since snap-confine profile is written for more recent apparmor behavior
[09:02] <mwhudson> zyga-suse: any ideas for things i should test on this vm?
[09:04] <zyga-suse> mwhudson: did you try the "I have no core and I snap install hello" use-case?
[09:05] <mwhudson> zyga-suse: yes
[09:05] <mwhudson> that was the first thing i tried :)
[09:06] <zyga-suse> hmm, not sure then, just a random collection of snaps perhaps: ... one sec
[09:06] <zyga-suse> https://github.com/snapcore/snapd/pull/3692
[09:09] <mwhudson> zyga-suse: is there some easy way to run this on the vm?
[09:10] <zyga-suse> not sure, I think if you can just hand install the top three it would be a good test
[09:10] <mwhudson> heh heh good to see my only important snap on there :)
[09:14] <zyga-ubuntu> which one is that?
[09:14] <zyga-ubuntu> :)
[09:14] <zyga-ubuntu> mvo: welcome back
[09:14] <mvo> hey zyga-ubuntu
[09:16]  * zyga-ubuntu needs 2nd coffee
[09:16] <zyga-ubuntu> head.ache()
[09:17] <mvo> zyga-ubuntu: I get a cup of tea now too - I looked briefly at backporting asic control to 2.27.1 but there are quite a few changes to common interfaces that would also need backporting, it seemed overly broad for the scope of a .1
[09:18] <zyga-ubuntu> mvo: if you want I can make a simpler backport, with a custom interface type
[09:18] <mvo> zyga-ubuntu: lets
[09:18] <mvo> zyga-ubuntu: sorry, let see if we need a .2 and only do it if we do
[09:18] <zyga-ubuntu> mvo: ok, when will we know?
[09:19] <mwhudson> zyga-suse: go
[09:19] <mvo> zyga-ubuntu: hopefully soon, I will ask cachio to do the 2.27.1 validation today
[09:19] <zyga-ubuntu> ok
[09:20] <zyga-ubuntu> I'll do some more reviews for garry and work on 2.27.1 packaging
[09:20] <mvo> +1
[09:22] <mwhudson> heh i appear to have rocketchat installed on debian sid
[09:22] <zyga-ubuntu> the funny thing is it would also install on debian *stable*
[09:42] <zyga-ubuntu> hmm, mup is not reporting PRs
[09:49] <ikey> ok so github is seriously tripping right now
[09:49] <ogra> oh, while you mention github ...
[09:50] <ikey> zyga-ubuntu, https://ibin.co/3Wq1GWrSnkGi.png
[09:50] <zyga-suse> hey
[09:50] <zyga-suse> hmmm
[09:50] <zyga-suse> I merged master into your branch
[09:50] <zyga-suse> that should fix the fedora failures
[09:50] <ikey> yeah but look where you pushed
[09:50] <ikey> that shouldnt be possible
[09:50] <ikey> thats the forked repo
[09:50] <zyga-suse> yes
[09:51] <zyga-suse> it is, that's a github feature
[09:51] <ikey> then github is on crack
[09:51] <ikey> because repo permissions
[09:51] <ikey> lol
[09:51] <zyga-suse> I pushed that *into* your branch because when there's an active PR contributors can do that
[09:51] <zyga-suse> it's an opt-out feature for about 3 months
[09:51]  * ikey calls crack
[09:51] <zyga-suse> it does makes sense :)
[09:51] <ikey> meth then
[09:51] <ikey> :p
[09:51] <zyga-suse> it's weird but when you think about it
[09:51] <zyga-suse> people close the PR and reopen with more things
[09:52] <zyga-suse> but that's just a time waste
[09:52] <ikey> rebase/force push
[09:52] <zyga-suse> why?
[09:52] <ikey> i mean in response to "people close the PR"
[09:52] <zyga-suse> ah
[09:52] <mup> PR snapd#3724 opened: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[09:52] <zyga-suse> no, I mean people close the PR because they cannot push to it
[09:53] <ikey> oh others
[09:53] <zyga-suse> contributor comes along and makes a PR but then looses interest
[09:53] <ikey> ah
[09:53] <zyga-suse> maintainers are willing to fix so they close and reopen with their fixes
[09:53] <zyga-suse> this just cuts one step
[09:53] <zyga-suse> not saying that it happens all the time
[09:53] <zyga-suse> but even inside the core team we do that all the time
[09:53] <zyga-suse> esp timezones
[09:53] <zyga-suse> it helps
[09:54] <zyga-suse> btw, I'm curious -- what was that UI that showed me doing this?
[09:54] <zyga-suse> is that something I can use?
[09:55] <mup> PR snapd#3702 closed: interfaces: add missing test for camera interface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3702>
[09:56] <ikey> zyga-suse, that was just on my github front page
[09:56] <zyga-suse> aha
[09:56] <zyga-suse> interesting theme :)
[09:56]  * mwhudson uploads snapd_2.27.1-1_source.changes
[09:56] <ikey> https://ibin.co/3Wq3LA9vK99y.png
[09:59] <zyga-ubuntu> ikey: nice, is that a custom theme applied somehow or something I can toggle just on github?
[09:59] <ikey> i use userstyles extension in chrome
[09:59] <zyga-ubuntu> ah, right
[09:59] <ikey> or stylish
[09:59] <ikey> or h/e you call it .. lol
[10:00] <ikey> "GitHub Dark"
[10:00] <ikey> wth gdk-pixbuf
[10:00] <ikey> what kind of a mad man statically links libtiff
[10:00]  * zyga-suse ventures into /usr/lib/rpm
[10:01] <ikey> i feel i should say "It's dangerous to go alone!" and offer you a sword.
[10:02] <zyga-ubuntu> I think I'm already out, I was looking at how /usr/lib64/go vs /usr/lib/go can be abstracted
[10:03] <ikey> ah
[10:08] <pedronis> mvo: hi,  snapd#3710 is the thing that needs a review for 2.28 btw
[10:08] <mup> PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
[10:09] <mvo> pedronis: thanks, I have a look
[10:09] <Chipaca> zyga-ubuntu: any luck with a branch to disable sync in tests?
[10:10] <zyga-ubuntu> Chipaca: nope, I left it on a hanger last week
[10:10] <zyga-ubuntu> Chipaca: let me refresh it
[10:18] <Chipaca> zyga-ubuntu: no worries, just curious
[10:22] <Chipaca> huh, the autopkgtests run without a core snap
[10:27] <ogra> jospoortvliet, hey ho ... why does this section if the nextcloud install doc tell you to install debs alongside the snap ? https://docs.nextcloud.com/server/12/admin_manual/installation/source_installation.html#example-installation-on-ubuntu-16-04-lts-server
[10:28] <jospoortvliet> ogra: it is meant to be a choice
[10:28] <jospoortvliet> either install the snap
[10:28] <jospoortvliet> or go the 2nd way: install things manually
[10:28] <jospoortvliet> it isn't very clear
[10:28] <jospoortvliet> not at all :D
[10:28] <ogra> yeah :)
[10:29] <jospoortvliet> ogra: I would suggest to have a header "option 1" and "option 2"
[10:29] <jospoortvliet> if you want, you can propose the change: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst
[10:29] <jospoortvliet> edit the source of the documentation there
[10:30] <ogra> jospoortvliet, FYI  https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291222.html
[10:31] <jospoortvliet> ogra: if you happen to be on that list, replying to explain the problem would be welcome, I'm not a member...
[10:32] <jospoortvliet> and mention me ( @jospoortvliet ) if you make a pr for the documentation. Just use the web UI of github... or let me know if you can't figure out how to, I'd be happy to help!
[10:34]  * zyga-suse focuses on suse package again
[10:35] <jospoortvliet> +1 for that zyga-suse - I have moved to using the tarball but as openSUSE user I'd consider moving back to packages. Though then I can't help test RC's etc so easily. choices, choices... ;-)
[10:35] <zyga-suse> hmm?
[10:35] <zyga-suse> I mean suse package of snapd
[10:36] <jospoortvliet> aaah zyga-suse that is also cool :D
[10:36] <jospoortvliet> zyga-suse: esp on small devices that you don't want to maintain I think the snap is super useful
[10:36] <jospoortvliet> so +1 on that, too :D
[10:38] <ogra> jospoortvliet, https://github.com/nextcloud/documentation/pull/554
[10:38] <mup> PR nextcloud/documentation#554: make clearer that it is either snap or deb in the example <Created by ogra1> <https://github.com/nextcloud/documentation/pull/554>
[10:57]  * zyga-suse ponders
[10:57] <zyga-suse> https://paste.gnome.org/pasc7ndpu
[11:04]  * zyga-ubuntu -> lunch
[11:07] <ogra> zyga-ubuntu, thanks for merging the spi stuff in the pi3 gadget (i thought you said you wanted manual tests in your last comment on the PR, this is why i had not merged it yet)
[11:07] <zyga-ubuntu> it looked ok
[11:08] <ogra> yeah, and it goes to edge first anyway :)
[11:10] <Chipaca> ok, time for me to take a break (run + lunch + etc
[11:10] <Chipaca> )
[11:30]  * zyga-ubuntu resumes hacking
[11:53] <zyga-ubuntu> can someone please do a 2nd review for 3714
[11:57] <mup> PR snapd#3705 closed: interfaces: convert lxd_support to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3705>
[12:03] <ikey> i updated my PR to remove the mkversion changes
[12:04] <ikey> (and rebased it on master to drop the 30 odd pull requests on top of it :P)
[12:05] <zyga-ubuntu> ikey: ok,
[12:05] <ikey> it seemed to be the main sticking point of the PR
[12:05] <ikey> and it means changing all of 2 lines in my package.yml
[12:05] <ikey> so its a silly thing to keep around
[12:06] <ikey> actually no it just means adding one line, easier again
[12:06] <zyga-ubuntu> Thank you!
[12:06] <zyga-ubuntu> I asked jdstrand to review that PR
[12:06] <ikey> s'all good dude
[12:06] <ikey> i like streamlined :p
[12:12] <pedronis> ikey: notice that we tend to frown upon rebases once a PR has got comments
[12:13] <pedronis> at least that's what I always heard from niemeyer
[12:13]  * ikey blinks
[12:13] <ikey> i didnt exactly have a choice :p
[12:13] <ikey> zyga-ubuntu pushed a merged master on top of it, and the only way to edit my own patch was to rebase it back on top of master
[12:14] <zyga-ubuntu> that's fine
[12:14] <ikey> i wasn't going to dig through 30 merged PRs for my patch and then reapply them lol
[12:14] <niemeyer> ikey: You can just merge master in those cases, I believe
[12:14] <ikey> it was already merged
[12:14] <ikey> thats the problem
[12:14] <ikey> i couldnt amend my commit
[12:15] <niemeyer> ikey: You can just continue changing the content of the PR further.. no need to amend
[12:15] <niemeyer> This way reviews continue to make sense on the timeline
[12:15] <ikey> which means you would need to cherry-pick my commits and would lose my gpg signature
[12:15] <niemeyer> Otherwise all previous references to commits are lost
[12:15] <ikey> idk maybe we just git differently
[12:16] <ikey> github shows when a comment is for an outdated diff
[12:16] <pedronis> we have a slightly messy mainline
[12:16] <pedronis> but we don't care it seems, so yes we make different git choices I think
[12:16] <ikey> well, i know for future
[12:17] <niemeyer> The mainline is pretty clean, mainly because we squash merges
[12:17] <ikey> which then loses gpg signatures, etc
[12:17] <pedronis> often but not always
[12:17] <niemeyer> It does, yes
[12:17] <ikey> debian has been pushing for signed commits for some time
[12:17] <ikey> as well as signed tags
[12:18] <niemeyer> Thanks for the changes, and good morning btw :)
[12:18] <ikey> morning!
[12:18] <ikey> at times github is enough to make me miss gerrit
[12:18] <ikey> which is an awful thing to say
[12:20] <niemeyer> GitHub is pretty reasonable these days in terms of code reviews.. it used to be unacceptable for anything non trivial
[12:20] <ikey> yeah
[12:21] <ikey> at least its no longer trying to hide all the things
[12:21] <Son_Goku> beh
[12:21] <Son_Goku> signed commits and tags cause issues
[12:21] <ikey> update your git client?
[12:21] <ikey> dont use gitkraken?
[12:21] <ikey> etc. :p
[12:21] <Son_Goku> if GitHub throws 500 errors, there's not a lot I can do
[12:22] <ikey> github makes no attempt to verify signatures
[12:22] <Son_Goku> it's a known issue with how GitHub's gpgverify works
[12:22] <Son_Goku> yes it does
[12:22] <ikey> only that the issue belongs to an account
[12:22] <Son_Goku> it actually *does* attempt to verify them
[12:22] <ikey> because you have to upload your gpg key to github for it to do so
[12:22] <ikey> not to a keyserver
[12:22] <Son_Goku> well, yeah, not to hkp
[12:22] <Son_Goku> but it does actually attempt to verify them
[12:22] <ikey> right so its not doing **normal** verification is what im saying :p
[12:23] <Son_Goku> mvo, have you attempted to get this fixed yet? https://github.com/golang/go/issues/20556
[12:29] <Son_Goku> woo, someone fixed mongodb ftbfs on s390x :D
[12:29] <Son_Goku> that means I can finally build snapd on rawhide
[12:29] <zyga-suse> someone *cares* :D
[12:29] <zyga-suse> how is that related?
[12:33] <Son_Goku> snapd -> go mongodb driver -> mongodb-libs -> mongodb
[12:34] <Son_Goku> zyga-suse: it's really silly that snapd depends on mongodb transitively, but whatever
[12:36] <Son_Goku> god, I hate arm: https://koji.fedoraproject.org/koji/taskinfo?taskID=21222949
[12:36] <Son_Goku> it takes FOREVER...
[12:43] <ikey> "god, I hate arm" - which one? :trollface:
[12:43]  * ikey legs it
[12:43] <zyga-suse> Son_Goku: how is that possible?
[12:43] <zyga-suse> ah
[12:43] <zyga-suse> Son_Goku: mongodb driver is a part of golang?
[12:43] <Son_Goku> no, it's the mgo driver the niemeyer wrote
[12:47] <ogra> "the niemeyer" ... <highlander voice> there can be only one, my friend </highlander voice>
[12:47] <ogra> :)
[12:49] <niemeyer> How would snapd depend on it transitively? It definitely doesn't in general
[12:52] <Son_Goku> https://koji.fedoraproject.org/koji/rpminfo?rpmID=10629107
[12:52] <Son_Goku> if this is an error, then tell me, so I can poke someone to fix it
[12:53] <mvo> Son_Goku: thanks for the reminder, mwhudson offered to help me with pushing the patch from https://github.com/golang/go/issues/20556 to upstream, I had some problems with the account creation
[12:53] <Chipaca> niemeyer: o/
[12:53] <pedronis> niemeyer: we are using mgo.v2/bson  seems to bring in stuff on distros
[12:53] <Son_Goku> mvo, well, I noticed it when I audited the source tree to update dependencies
[12:54] <Son_Goku> when I see weird forks and stuff like that, I want to be sure I can avoid them :)
[12:55] <Chipaca> Son_Goku: that's because you hate freedom
[12:55] <Chipaca> oh wait no that was us
[12:55] <Son_Goku> :)
[12:56] <Chipaca> is spread on linode having a bad day?
[12:57] <niemeyer> pedronis: I see.. that doesn't make a lot of sense, in quite a few ways
[12:58] <niemeyer> First, it's a build dependency..
[12:58] <niemeyer> Then, it's a driver.. building something with a driver shouldn't bring in a database
[12:58] <Son_Goku> yeah, as a result, I can't build snapd
[12:59] <niemeyer> Son_Goku: How come?
[12:59] <Son_Goku> pulling that godep causes it to try to install mongo, and mongo wasn't rebuilt for new boost successfully because borkiness in test suite on s390x
[13:00] <pedronis> niemeyer: yea, but it's a problem in the mgo packages , not in snapd afaiu
[13:00] <Chipaca> I interrupt this fascinating documentary about how all packaging is broken all the time to bring you this bit of news: it's standup o'clock
[13:00] <pedronis> Chipaca: :)
[13:00] <Son_Goku> pedronis: yep
[13:00] <niemeyer> Son_Goku: That makes no sense on itself, even despite anything else, right?
[13:01] <Son_Goku> unless you expect to run the mgo unit tests in your build, I think it doesn't make sense to be a hard dep
[13:02] <Son_Goku> after all, the server could exist somewhere else, in theory
[13:02] <Son_Goku> unless the driver requires the mongodb C libs to build correctly
[13:10] <ogra> mvo, did you see the discussion on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 ?
[13:11] <ogra> (i guess we should pull the xdg fix into 2.27.1)
[13:15] <zyga-ubuntu> morphis: hey
[13:15] <zyga-ubuntu> morphis: around?
[13:15] <morphis> zyga-ubuntu: hey!
[13:16] <morphis> zyga-ubuntu: what's up?
[13:16] <zyga-ubuntu> morphis: would you have a moment for a opensuse package review?
[13:16] <morphis> sure
[13:16] <zyga-suse> excellent, I'll put the sync request up soon
[13:31] <zyga-suse> Chipaca: that's for you: https://github.com/snapcore/snapd/pull/3725
[13:31] <mup> PR snapd#3725: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
[13:31] <mup> PR snapd#3725 opened: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/3725>
[13:33] <Chipaca> zyga-suse: https://people.canonical.com/~john/howmanyvmsdoesittake
[13:33] <zyga-suse> hehe
[13:33] <Chipaca> zyga-suse: (also it's curl-able)
[13:34] <zyga-suse> Chipaca: oh, lovely, how did you do that?
[13:34] <Chipaca> zyga-suse: apache is magic
[13:34] <zyga-suse> ah, via apache
[13:34] <Chipaca> :-)
[13:35] <zyga-suse> I didn't know we can do that on p.c.c
[13:36] <zyga-suse> mvo: ok, I'll do your backport now
[13:45]  * zyga-ubuntu actually goes to eat something
[13:48] <mvo> zyga-ubuntu: \o/
[13:48] <Son_Goku> damn, I really should go to work now
[13:49] <zyga-suse> Son_Goku: thank you for the updates!
[13:49] <Son_Goku> np
[13:49] <Son_Goku> I suspect I'm going to have 2.27.2 soon, aren't I?
[13:50] <zyga-suse> yed
[13:50] <zyga-suse> yes*
[13:50] <zyga-suse> I need to backport one thing
[13:50] <zyga-suse> and we need two cherry picks from master
[13:50] <zyga-suse> sorry about that :(
[13:50]  * Son_Goku shrugs
[13:51] <Son_Goku> I'm only really annoyed when it's really close to making it into the repository
[13:51] <Son_Goku> because each update resets the counter
[13:52] <zyga-suse> we feel it the same way for ubuntu and elsewhere :/
[13:55] <Son_Goku> and because no one ever tests the Fedora snapd updates, it's aggravating
[13:55] <zyga-suse> I will start doing that again, sorry for letting you down there :/
[13:55] <Son_Goku> because I have to wait the full five days, and then it has to be reset :/
[13:55] <zyga-suse> what is the average rate of tests for a package?
[13:56]  * Son_Goku shrugs
[13:56] <zyga-suse> in bodhi I mean
[13:56] <Son_Goku> the stats are in Bodhi itself
[13:56] <Son_Goku> https://bodhi.fedoraproject.org/metrics
[13:56] <Son_Goku> https://bodhi.fedoraproject.org/releases/F26
[14:16] <niemeyer> mvo: Do we have a topic for the known issue with snapd reverts?
[14:16] <niemeyer> mvo: core revert leaving snapd unrestarted, that is
[14:18] <mvo> niemeyer: not yet, let me add it
[14:18] <niemeyer> mvo: Thanks!
[14:30] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3726
[14:30] <mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[14:30] <zyga-ubuntu> morphis: ^^
[14:31] <mup> PR snapd#3726 opened: interfaces: backport broadcom-asic-control interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[14:31] <mvo_> niemeyer: https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/
[14:33] <mup> PR snapd#3727 opened: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[14:33] <zyga-ubuntu> mvo_: anything else I can help with wrt 2.27?
[14:34] <mup> PR snapd#3728 opened: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
[14:35] <mup> PR snapd#3728 closed: tests: adding more debug information for the interfaces-cups-control test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3728>
[14:35]  * zyga-ubuntu reboots
[14:36] <mup> PR snapd#3729 opened: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3729>
[14:36] <ikey> i think the arch nvidia code might be broken
[14:37] <ikey> https://ibin.co/3WrQ0U7eu5Ao.png
[14:37] <ikey> getting the undefined symbol issues .. which i shouldnt be getting
[14:37] <ikey> unless its mercilessly copying across host side GL libs regardless of whether or not its nvidia
[14:37] <mvo_> zyga-suse: I think we are good otherwise
[14:39] <mup> PR snapd#3730 opened: tests: adding more debug information for the interfaces-cups-control … <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3730>
[14:40] <mup> PR snapd#3731 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3731>
[14:40] <mup> PR snapd#3732 opened: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3732>
[14:40] <ikey> ah
[14:40] <ikey> 	if (config->on_classic_distro) {
[14:40] <ikey> 		sc_mount_nvidia_driver(scratch_dir);
[14:40] <ikey> 	}
[14:40] <ikey> its unconditional
[14:40] <ikey> reality being it should only actually mount in the presence of the nvidia driver
[14:40] <ikey> that came out wrong..
[14:43] <ikey> we basically need this in mount-support-nvidia.c sc_mount_nvidia_driver:
[14:43] <ikey> 	if (access(SC_NVIDIA_DRIVER_VERSION_FILE, F_OK) != 0) {
[14:43] <ikey> 		return;
[14:43] <ikey> 	}
[14:43] <mvo_> zyga-suse: all 2.27 bits are now running tests, fingers crossed, once things are green I will work on 2.27.2
[14:43] <ikey> and make the define global, not limited purely to ubuntu impl
[14:47] <zyga-suse> mvo_: conflict on 3732
[14:48] <zyga-suse> ikey: aha, indeed - a similar check exists for the more-tested ubuntu path
[14:48] <zyga-suse> ikey: thank you for finding that
[14:48] <ogra> mvo_, since you didnt answer my pings, pinging again ... did you see the xdg-open discussion on the 2.27.1 thread ?
[14:48] <ikey> ill stick the patch into solus and build a VM with it zyga-suse
[14:48] <zyga-suse> ogra: I think he did
[14:48] <ikey> if that works ill submit the PR
[14:48] <ogra> (just want o make sure it doesnt get missed)
[14:48] <zyga-suse> ogra: that's why we are getting 2.27.2
[14:48] <ogra> awesome
[14:48] <zyga-suse> ikey: sounds good
[14:49] <ikey> looks like this atm https://hastebin.com/afozimumuv.swift
[14:49] <ogra> zyga-suse, i didnt want to be pushy ... just didnt know if he saw it
[14:50] <zyga-suse> it's all good :)
[14:50] <ogra> :)
[14:52] <chad_young> anyone free to help with snapcraft.yaml file issues?
[14:53] <zyga-ubuntu> chad_young: hey, what is the matteR?
[14:53] <chad_young> I am trying to snap mosquitto and the clients into one snap but I cant seem to put everything in it place
[14:53] <chad_young> I have a file on github - its the "clean" version
[14:54] <mup> PR snapd#3691 closed: tests: installing snapd for nested test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3691>
[14:54] <chad_young> i.e. default
[14:56] <chad_young> file is here: https://github.com/chadyoungdell/Ubuntu-Core/blob/master/IOT_Apps/Mosquitto/snapcraft.yaml
[14:57] <chad_young> when I snap the "mosquitto" service does start but after I try adding the client file the snap complete
[14:58] <tpatel> can I update my snap from my own snap, rather than waiting on auto refresh?
[15:02] <niemeyer> "We went looking everywhere, but couldn’t find those commits.
[15:02] <niemeyer> Sometimes commits can disappear after a force-push. Head back to the latest changes here."
[15:02] <niemeyer> That's why we don't force-push after reviews are up.. :/
[15:02] <niemeyer> (aka "rebase")
[15:04] <ogra> chad_young, why cant you use the existing snap package of mosquitto ?
[15:04] <ogra> is that missing anything ?
[15:05] <ogra> oh, sorry
[15:05] <ogra> missed that you want to bundle clients
[15:05] <chad_young> np :)
[15:06] <niemeyer> Irony: I went to add 10 more machines to our Linode pool, and found all 70 machines down right now.
[15:06] <niemeyer> As in, powered off..
[15:06] <Son_Goku> :D
[15:06] <niemeyer> I don't recall ever having seen all of them powered down at once :)
[15:07] <zyga-ubuntu> niemeyer: maybe we should have a dynamic scaling thing
[15:07] <zyga-ubuntu> niemeyer: at least 10, at most 150
[15:07] <zyga-ubuntu> not sure what the pricing model is
[15:07] <niemeyer> zyga-ubuntu: Right, that's the tricky bit
[15:08] <zyga-ubuntu> if that is competetive maybe linode should just make that easy
[15:08] <zyga-ubuntu> (it must be saving real stuff for them)
[15:08] <zyga-ubuntu> I wish they had as "dormant" pricing for powered off machines
[15:08] <niemeyer> zyga-ubuntu: They do make it easy, and they are also smart about it
[15:09] <niemeyer> zyga-ubuntu: The cost of holding one of those machines for a month is $10, but the price per hour is .015.. do the math
[15:09] <ogra> tpatel, yes you can by using a local snap file and the --dangerous flag for "snap install" but it wont auto-update anymore then
[15:09] <zyga-ubuntu> aww :D
[15:10] <zyga-ubuntu> niemeyer: that's both good and not good, I wish there was at least, say, 30% delta
[15:10] <zyga-ubuntu> worth the money to make our side smarter
[15:11] <niemeyer> zyga-ubuntu: In practice, it's cheap.. that level of machine is much more expensive on other providers
[15:12] <zyga-ubuntu> niemeyer: 30% of 100 is still 30 :D but I see the point
[15:12] <zyga-ubuntu> I wonder if we could marry spread and juju to be cross-cloud one day
[15:13] <tpatel> orga: can I issue 'snap refresh' which should pull it from store and update it?
[15:13] <niemeyer> zyga-ubuntu: spread is cross-cloud
[15:13] <ogra> not sure about that ... but i dont think so
[15:13] <niemeyer> zyga-ubuntu: and cross-your-disk too:)
[15:13] <zyga-ubuntu> niemeyer: well, arguably the disk image is something that is tricky but this feels like a problem somehow must have solved
[15:13] <niemeyer> zyga-ubuntu: But part of the point is having something that tends to work without us having to spend a lot of time on this
[15:13] <ogra> (note that --dangerous is rather for developers when testing locally built snaps before uploading to the store)
[15:14] <niemeyer> zyga-ubuntu: Your time has a cost, you know :)
[15:14] <mvo_> ogra: sorry, must have missed the earlier ping. I noticed the issue with xdg-open, I pushed a PR that shouöd fix it
[15:14] <ikey> yeah my gl patch works
[15:14] <ogra> mvo_, yeah, i saw that now ... sorry for the noise (though there is a conflict)
[15:14] <zyga-ubuntu> niemeyer: I know, hence me saying "worth the money to make our side smarter"
[15:15] <mvo_> ogra: thanks, looking into this one now
[15:17] <ikey> zyga-suse, should i add the new patch to my existing PR?
[15:18] <mup> PR snapd#3732 closed: interfaces: allow /usr/bin/xdg-open in unity7 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3732>
[15:19] <niemeyer> zyga-ubuntu: We now have 70 machines running (!).. how much would AWS charge for 70 machines running for 1h?  More than $3, and that's assuming no network, no local SSD, etc...
[15:19] <zyga-suse> Chipaca: FYI, I applied the unsafe-io patch for tests to opensuse and it's a fantastic improvement
[15:21] <mvo_> jdstrand: if you could do a quick sanity check of PR 3726, that would be great
[15:24] <pstolowski> niemeyer, should the 'upcoming' stories that already landed be tagged with 'done' now? (sorry, I missed the conclusion about the tag)
[15:25] <zyga-ubuntu> pstolowski: no, we should just drop the name and upcoming from the tags
[15:25] <pstolowski> zyga-ubuntu, ok, thx
[15:25] <mvo_> ogra: re pings> I had some network hickups today, my dsl provider seems to be unhappy, this is probably why I missed the pings
[15:26] <ogra> ah, k
[15:26] <niemeyer> 10 VMs added, please retry / let me know of issues
[15:26] <niemeyer> Note that some tests running moments ago may have failed
[15:26]  * niemeyer => lunch
[15:27] <ikey> anyone? re: pushing patch to existing PR..
[15:28] <jdstrand> mvo_: ok
[15:28] <mvo_> jdstrand: thanks! should be super trivial I hope, straight backport from master just the old layout instead of the new commonInterfaces code
[15:30] <mup> PR snapd#3729 closed: store: do not resume a download when we already have the whole thing  (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3729>
[15:33] <ahasenack> hi guys, I'm having a problem installing a snap: http://pastebin.ubuntu.com/25312811/
[15:33] <ahasenack> getting a 404
[15:33] <ahasenack> was getting the same 404 a few moments ago for an older revision, 117
[15:34] <ogra> ahasenack, https://forum.snapcraft.io/t/snap-install-refresh-fails-with-404/1676
[15:34] <ogra> ??
[15:34] <ahasenack> let me try re-login
[15:35] <ahasenack> ogra: logout/login fixed it for me
[15:35] <ogra> yeah, thought so
[15:39] <mvo_> pedronis: thanks a lot for your feedback on the ensureCore PR!
[15:40] <jdstrand> mvo_: done
[15:41]  * mvo_ hugs jdstrand
[15:41]  * jdstrand hugs mvo_ back :)
[15:42]  * mvo_ hugs zyga-ubuntu for making the PR in the first place
[15:42]  * zyga-ubuntu blushes :)
[15:42] <mvo_> just one more to go for 2.27.2 :)
[15:46] <pedronis> mvo_: np, I fear the move is a bit more complicated than we thought, also the code we had in api is okish for classic, but if we need to support based etc we will need to be more careful about failure modes
[15:46] <pedronis> s/based/bases/
[15:47] <zyga-suse> morphis: https://build.opensuse.org/request/show/516894
[15:47] <mvo_> pedronis: indeed, I ponder some more how to make it more robust in the morning, its good feedback :)
[15:47] <pedronis> niemeyer: we never tried but I suppose we do support waiting for tasks across changes? at least we they are different lanes?
[15:48] <pedronis> s/we they/if they/
[15:51] <zyga-ubuntu> mvo_: hmm
[15:51] <zyga-ubuntu> mvo_: the upgrade/basic test failed with "no registered handlers for hook "install"
[15:51] <zyga-ubuntu> mvo_: what was the resolution for that?
[15:51] <zyga-ubuntu> mvo_: was it just a silly test or do we need action?
[15:52] <mvo_> zyga-ubuntu: iirc this has only happend when we went "upgraded" from master to 2.27, i.e. when the versions are out of sync, iirc I did a PR for the 2.27.1 changelog?
[15:52]  * mvo_ looks
[15:53] <mvo_> zyga-ubuntu: hm, edge should be ok, i.e. master - where do you see this error?
[15:53] <mvo_> zyga-ubuntu: when pstolowski and I last looked at it we had this version issue but if you see it on a current branch then it might be something deeper
[15:53] <zyga-ubuntu> mvo_: here, on ppc https://github.com/snapcore/snapd/pull/3726
[15:53] <mup> PR snapd#3726: interfaces: backport broadcom-asic-control interface (2.27) <Created by zyga> <https://github.com/snapcore/snapd/pull/3726>
[15:53] <zyga-ubuntu> mvo_: on the backport branch
[15:54] <mvo_> zyga-ubuntu: aha, in autopkgtest
[15:55] <mvo_> zyga-ubuntu: I need to look but the version in the log look a bit bogus
[15:56] <mvo_> pedronis: InstallMany is a real problem, you are right
[15:56] <Chipaca> hmm... the work i'm doing for package names / cnf could just as well apply to sections
[15:58] <Chipaca> ogra: is /var/cache writable on core? (do you know without checking?)
[15:58] <Chipaca> otherwise i can check myself :-D
[15:59] <ogra> ogra@nanopi:~$ touch /var/cache/foo
[15:59] <ogra> touch: cannot touch '/var/cache/foo': Read-only file system
[15:59] <ogra> :P
[15:59] <ogra> i can check faster :P
[15:59] <ogra> Chipaca, /var/cache/apparmor is writable
[16:00] <Chipaca> /var/lib/snapd/cache it is then :-D
[16:00] <ogra> but nothing on the higher level
[16:00] <ogra> well, you could have /var/cache/snapd
[16:00] <ogra> if that feels cleaner
[16:00] <ogra> it is trivial to add
[16:01] <Chipaca> I'm not convinced it is better, but good to know -- i'll mention it in the PR
[16:02] <chad_young> looking for help on the mosquitto snap (all inclusive- broker and pub/sub)
[16:02] <chad_young> I have both parts working - just cant get the combined to work
[16:02] <chad_young> that is broker in one snap and pub/sub in another
[16:05] <Chipaca> chad_young: how is it not working? that is, what errors do you see?
[16:05] <ogra> whats the exact issue ?
[16:05] <ogra> the snapcraft.yaml you linked above looks okayish
[16:07] <chad_young> usually when I add the client portion the snap create fails as it cant find a "config.mk" - which is there in the folder
[16:08] <chad_young> there are two make files - one for the broker and one for the client - each using the same config.mk file
[16:10] <ogra> just add another part ?
[16:11] <chad_young> I did that but it still failed - I will update the yaml file on the github and comeback when its ready
[16:11] <ogra> well, show us code and errors ... :)
[16:11] <ogra> like Chipaca said
[16:13] <chad_young> will do
[16:38] <zyga-ubuntu> Chipaca: hey
[16:38] <zyga-ubuntu> Chipaca: can you hand-hold me with tab completion issues again please
[16:38] <zyga-ubuntu> Chipaca: on opensuse now, I'm shipping the various files
[16:38] <zyga-ubuntu> Chipaca: (better yet, write a forum post)
[16:38] <zyga-ubuntu> Chipaca: enough for "tab completion doesn't work, here's some debug data for you to understand"
[16:39] <chad_young> ok @orga and Chipaca - here is the update
[16:39] <chad_young> https://github.com/chadyoungdell/Ubuntu-Core/tree/master/IOT_Apps/mosquitto.snap/snap
[16:40] <Chipaca> zyga-ubuntu: i'll hand-hold you, and if a pattern emerges, forum post
[16:40] <zyga-ubuntu> Chipaca: probably packaged something incorrectly
[16:40] <Chipaca> zyga-ubuntu: but … what issues are you seeing
[16:41] <chad_young> will post error in a sec
[16:41] <zyga-ubuntu> Chipaca: http in beta, http -<tab> does nothing
[16:42] <Chipaca> zyga-ubuntu: ok, so first of all, start a new terminal and tell me what you see for "complete -p -D"
[16:42] <chad_young> here is the error https://pastebin.com/BjM6KHU7
[16:42] <zyga-suse> zyga@faroe:~> complete -p -D
[16:42] <zyga-suse> complete -F _completion_loader -D
[16:43] <Chipaca> zyga-suse: ok, so you aren't sourcing complete.sh
[16:43] <zyga-suse> Chipaca: what should be doing that?
[16:43] <Chipaca> zyga-suse: you :-)
[16:43] <zyga-suse> as in, my profile?
[16:43] <Chipaca> zyga-suse: the need to add that to your .bashrc is addressed by snapd#3724
[16:43] <mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[16:44] <Chipaca> zyga-suse: well, we tried to make it automagic but hit a wall
[16:44] <Chipaca> so, in the snapd you have, you need to do this
[16:46] <zyga-ubuntu> ...
[16:46]  * zyga-ubuntu waits for what "this" is
[16:46] <Chipaca> zyga-ubuntu: this == "source complete.sh"
[16:46] <zyga-suse> aha
[16:47] <zyga-suse> as in
[16:47] <zyga-suse> zyga@faroe:~> . /usr/lib/snapd/complete.sh
[16:47] <zyga-suse> did that
[16:47] <Chipaca> zyga-suse: or . /snap/core/current/usr/lib/snapd/complete.sh
[16:47] <zyga-suse> no effect
[16:47] <zyga-suse> zyga@faroe:~> complete -p -D
[16:47] <zyga-suse> complete -F _complete_from_snap_maybe -D
[16:47] <Chipaca> ok, good
[16:47] <Chipaca> now
[16:47] <Chipaca> complete -p http
[16:48] <zyga-suse> zyga@faroe:~> complete -p http
[16:48] <zyga-suse> complete -F _minimal http
[16:48] <Chipaca> right, so you did http -<tab> _before_ sourcing complete.sh
[16:48] <Chipaca> so that loaded a completer for http
[16:48] <Chipaca> you need to remove it: complete -r http
[16:48] <Chipaca> and try again
[16:49] <zyga-suse> zyga@faroe:~> complete -r http
[16:49] <zyga-suse> zyga@faroe:~> complete -p http
[16:49] <zyga-suse> bash: complete: http: brak definicji dla uzupełnienia
[16:49] <Chipaca> zyga-suse: ok, http -<tab>?
[16:49] <zyga-suse> yep
[16:49] <zyga-suse> that worked!
[16:49] <zyga-suse> ok
[16:49] <Chipaca> ok
[16:49] <zyga-suse> so what should I do in general
[16:49] <zyga-suse> is it a default in opensuse
[16:49] <zyga-suse> is it something I can tweak in packaging?
[16:50] <Chipaca> zyga-suse: it depends on whether suse's shells always source /etc/profile or if it's only for login shells
[16:50] <Chipaca> zyga-suse: on debian it's only login shells
[16:51] <Chipaca> zyga-suse: on fedora it's all of 'em
[16:51] <Chipaca> afaik
[16:51] <zyga-suse> https://paste.gnome.org/pxh1jvxfw
[16:51] <zyga-suse> this is /etc/profile
[16:51] <Chipaca> zyga-suse: which is why in debian there's bash completion loaded twice, once in /etc/profile.d, once in .bashrc
[16:51] <Chipaca> zyga-suse: what's in /etc/skel/.bashrc
[16:51] <Chipaca> zyga-suse: bah
[16:52] <Chipaca> zyga-suse: easy way of answering what's going on is to try it and see :-)
[16:52] <zyga-suse> note, this is tumbleweed
[16:52] <zyga-suse> as in "sid"
[16:52] <Chipaca> zyga-suse: _but_, snapd#3724 would fix this
[16:52] <mup> PR snapd#3724: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <https://github.com/snapcore/snapd/pull/3724>
[16:52] <zyga-suse> https://paste.gnome.org/phffmxefk
[16:53] <zyga-suse> Chipaca: aha, I may just review it then :D
[16:54] <Chipaca> zyga-suse: basically, in a default user on suse, in a default gnome terminal tab (say), is bash tab completion enabled? and if it is, is it via /etc/profile.d, and if it is, can we drop /etc/profile.d/zzz-sneaky-snapd-completion in there that overrides the default completer
[16:54] <Chipaca> and then if a user has modified stuff it'll still break
[16:54] <Chipaca> so that PR is really the best approach
[16:55] <Chipaca> even though it'll require packaging tweaks (to remove snap completion snippets on purge)
[16:55] <zyga-suse> mmm, no idea
[16:56] <zyga-suse> note
[16:56] <zyga-suse> we have a file in /etc/profile.d
[16:56] <zyga-suse> snapd.sh is there
[16:56] <zyga-suse> as is snapd-xdg.sh
[16:56] <zyga-suse> (I will merge them actually)
[16:56] <mup> PR snapd#3718 closed: tests: enable regression and completion suites for opensuse <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3718>
[16:57] <cachio> mvo_, do you know who should I contact to get a connection to the machines where the autopkgtest for each build on travis?
[16:57] <chad_young> @orga have you had a chance to look at my update
[16:57] <nothal_> chad_young: No such command!
[16:57] <cachio> mvo_, I need that to see why the refresh-all* tests are failing
[16:58] <chad_young> orga: have you had a chance to look at my update
[16:58] <chad_young> Chipaca: same Q to you
[16:59] <Chipaca> chad_young: I'm afraid if it's a snapcraft problem I'm not the right person to help you
[17:01] <Chipaca> chad_young: it looks like you're missing a configure step
[17:02] <Chipaca> chad_young: if you run a "make" in the checkout of that git repository, does it work?
[17:03] <chad_young> yes, if I run make/make install in each folder seperately they both build
[17:03] <Chipaca> chad_young: what's 'each folder'?
[17:04] <Chipaca> chad_young: i guess your problem is the last bit, the 'client' part, where you tell it to make using a source of ../client
[17:04] <chad_young> looking at the github there is a make file in "src" folder for the broker and another make file in the "client" folder that makes the pub/sub client
[17:04] <Chipaca> chad_young: that would pull just the client directory somewhere, and config.mk is in the parent directory which would not be where the make expects it?
[17:05] <Chipaca> pure speculation on my part
[17:05] <Chipaca> note what it's not finding is ../config.mk
[17:05] <Chipaca> which is in the repository root
[17:05] <chad_young> if I look at the github I see config.mk in the root folder
[17:06] <Chipaca> yes
[17:06] <Chipaca> but you're trying to build the client with just the "client" subdirectory, without the config.mk from the root folder
[17:06] <chad_young> I am ?
[17:06] <Chipaca> that's what "source: ../client" means, isn't it?
[17:07] <chad_young> I thought that putting in "../client" was just telling make where the Makefile was
[17:09] <chad_young> since I am starting the snapcraft from the folder "snap" I thought I would have to specify that the new make file (for the clients) is in the "../client" folder
[17:12] <zyga-suse> Chipaca: re, sorry
[17:12] <zyga-suse> Chipaca: I'm EOD, let's catch up tomorrow
[17:13] <Chipaca> zyga-suse: k
[17:14] <Chipaca> chad_young: you're going to have to find somebody who knows more snapcraft than myself, I'm afraid
[17:19] <chad_young> Ok, Thank you
[17:39] <Chipaca> ok, this works. tests are a thing for tomorrow.
[17:39]  * Chipaca EODs
[17:49] <niemeyer> ikey: Not sure if someone responded to you yet, but we try to split up patches as much as we can
[17:49] <niemeyer> ikey: Within reason, of course.. but different ideas generally belong on different patches
[17:50] <ikey> niemeyer, its still the same idea
[17:50] <ikey> "Initial Solus support"
[17:51] <ikey> but I had a feeling it *might* be one way or the other
[17:51] <ikey> Which is why I asked ages ago
[17:51] <niemeyer> ikey: Well, we can also say that "snapd" is an idea.. :P
[17:51] <niemeyer> ikey: I really mean in terms of the logical change instead of the overall goal
[17:51] <ikey> Ack
[17:51] <niemeyer> ikey: Thanks for asking
[17:51] <ikey> you can ignore the secondary commit and ill open a second PR for it
[17:52] <ikey> likely wont be happening tonight as that came up during QA and we're prepping a solus release here
[17:52] <ikey> so it was more "emergency patch"
[17:52] <niemeyer> ikey: It ends up being much easier to review and consequently to get things merged
[17:52] <ikey> aye
[17:52] <niemeyer> ikey: otherwise a small controversy on a tiny part blocks the whole
[17:52] <ikey> yeah thats why i blitzed the other yokey
[17:52] <ikey> the mkversion thingy
[17:53]  * ikey can't word
[18:33] <tpatel> can i check within my snap if the interface is connected?
[18:35] <tpatel> can i check within my snap if the interface is connected?
[18:37] <mup> PR snapd#3731 closed: interfaces: allow /usr/bin/xdg-open in unity7 (2.27) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3731>
[18:45] <niemeyer> zyga-ubuntu, ikey, mvo: Folks, let's please stop supporting mkversion.sh to take the version as an argument..
[18:45] <niemeyer> Actually, let me open a forum topic for that
[18:45] <ikey> well im not gonna support dpkg-parsechangelog :p
[18:46] <niemeyer> ikey: mkversion.sh encodes the version into the filesystem
[18:46] <ikey> shouldn't the "if git" stuff be more relevant, with a well defined in-tree version?
[18:46] <ikey> vs "i have a vendored tarball that should know what its own version is"
[18:46] <niemeyer> ikey: There shouldn't be any need to support the changelog
[18:46] <ikey> because mkversion is mostly about dirty trees
[18:46] <ikey> from what i can tell.
[18:47] <niemeyer> ikey: No, clean trees produce clean versions as well
[18:47] <ikey> not in a vendor tarball :D
[18:48] <niemeyer> Well, that's exactly the point.. it shouldn't ever be run in a tarball.. the tarball should contain the actual version instead
[18:49] <ikey> right
[19:04] <niemeyer> Topic in the forum..
[19:11] <zyga-suse> niemeyer: sounds ok
[19:11]  * zyga-suse returned from a long walk
[19:19] <niemeyer> I should go out as well.. it's been a while since I've taken some proper sunlight..
[19:21]  * niemeyer steps out for a while
[19:29] <tpatel> Does brand store include all public snaps by default? If not, can I select the needed public snaps to be included in brand store?
[19:42] <noise][> tpatel: it is possible to either include the entire contents of the default store or select individual snaps
[19:47] <tpatel> noise: thanks. Will the selected public snaps when updated on the public store, gets auto update on the brand store as well?
[19:48] <noise][> yes
[19:55] <tpatel> noise: Can i control the public snap update to be updated on brand store? Make sure all the snap in my brand store are working without any issue with updated public snaps and then release them to stable.
[20:08] <mup> PR snapcraft#1436 closed: cli: properly handle exceptions <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1436>
[20:08] <mup> PR snapcraft#1486 opened: core: improve source caching logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1486>
[20:59] <mup> PR snapcraft#1487 opened: python plugin: record manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1487>
[21:13] <mwhudson> woop https://buildd.debian.org/status/package.php?p=snapd
[21:47] <ahoneybun> anyone have example electron apps?
[21:47] <ahoneybun> looking to see if we can snap riot.im
[22:22] <Chipaca> ahoneybun: did you search the forum?
[22:35] <mup> PR snapd#3733 opened: switch to canonical path for gopkg.in/cheggaaa/pb.v1 <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3733>


[11:18] <virtuald> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/405226
[11:18] <virtuald> is this of any use to anyone?
[12:45] <tjaalton> Sarvatt: were there some problems with the fglrx/nvidia autoconfig patches?
[14:40] <lesshaste> I get " shm.c: mmap() failed: Cannot allocate memory" all the time when using pidgin.. is this a known problem?
[14:46] <tjaalton> lesshaste: no, and hardly related to X?
[14:47] <lesshaste> tjaalton, it's not?
[14:47] <lesshaste> ah ok :)
[14:47] <lesshaste> sorry
[14:47] <tjaalton> :)
[14:48] <tjaalton> feeling grumpy about all these silly bugreports
[14:48] <tjaalton> on lp
[14:48] <lesshaste> :)
[17:19] <Unggnu> hi all
[17:20] <Unggnu> KMS works great with Karmic and i915 but overlay video isn't possible anymore with it and the textured video still tears regularly while it is better than before
[17:20] <Unggnu> So I have to disable it.
[17:21] <Unggnu> Can anyone confirm this? Is it because of the performance of the i915 or a general problem. I got an error message on boot but except of the tearing everything seems to work fine.
[17:28] <virtuald> why does the drm module depend on i915? i have a radeon and have blacklisted i915 but it gets loaded anyway
[17:30] <jcristau> it doesn't.
[17:37] <jbarnes_> Unggnu: video shouldn't tear in the .28 driver
[17:37] <jbarnes_> fail
[17:37] <jbarnes_> 2.8 anyway
[17:44] <Ng> hey look at that, it is tear free. sweet!
[17:46] <virtuald> jcristau: lspci says it does
[17:48] <virtuald> lsmod
[18:35] <tjaalton> virtuald: you are reading it wrong
[18:39] <virtuald> ok
[18:39] <virtuald> its the other way around
[18:40] <virtuald> but why doesn't my blacklist work then? :>
[18:43] <tjaalton> where did you put it?
[19:09] <virtuald> /etc/modprobe.d/blacklist-local.conf
[19:10] <virtuald> oh it's the initramfs
[19:28] <tseliot> bryce: can you upload the debdiff in bug 402863 please?
[19:29] <bryce> tseliot, certainly
[19:29] <tseliot> bryce: thanks
[19:46] <bryce> tseliot, uploaded
[19:47] <tseliot> bryce: thanks again :-)
[20:19] <bryce> jbarnes, mind taking a look at https://bugs.freedesktop.org/show_bug.cgi?id=22969 - perf issue when screen is rotated
[20:29] <jbarnes> bryce: looking now
[20:30] <jbarnes> that could be a dupe of a more general rotation problem
[20:31] <jbarnes> keithp has a bug assigned to him to fix that
[20:31] <bryce> yeah it sounded familiar
[20:55]  * hyperair wonders how to debug the Xorg crash when starting wine 3d apps
[21:17]  * hyperair begins compiling mesa with noopt
[21:17] <hyperair> hopefully i'll get a nicer stack address
[21:25] <bryce> yeah good stack traces are key
[22:03] <tjaalton> wow, ~200 bugs vanished
[22:22] <seb128> tjaalton, how did you do that? ;-)
[22:23] <tjaalton> seb128: thank bryce, not me ;)
[22:23] <tjaalton> I did dupe some earlier today though
[22:26] <bryce> yep, a month ago I asked them to re-test with karmic, but there was never a response
[22:28] <bryce> now just to finish upstreaming the ones that did reply
[22:38] <seb128> could somebody review bug #401656?
[22:38] <seb128> I'm trying to clean the sponsoring queue it's out of control since dholbach is on holidays
[22:39] <seb128> I'm sure he would appreciate if we do some work on it before he comes back ;-)
[22:42] <tjaalton> commented
[22:44] <seb128> tjaalton, thanks
[22:45] <seb128> tjaalton, no need to go through a round trip with the submitter for those details, you can as well fix and upload and let the comment ;-)
[22:45] <tjaalton> heh, right
[22:50] <seb128> bug #404618 too if somebody wants to comment
[23:06] <tjaalton> Sarvatt: your openchrome debdiff has a 'debian/ch' which has the upstream changelog?
[23:09] <Sarvatt> that was in bryces package, want me to move it to ../ChangeLog and put a new debdiff up?
[23:10] <Sarvatt> ahh i'm sorry, have to run and do a job for a bit
[23:11] <tjaalton> I removed it, will upload now :)
[23:34] <bryce> jbarnes, you thinking it might be this bug?  https://bugs.freedesktop.org/show_bug.cgi?id=16612
[23:35] <jbarnes> yeah that sounds like the one
[23:50] <bryce> first bug upstreamed using my new send_upstream.cgi! https://bugs.freedesktop.org/show_bug.cgi?id=22976
[23:53] <bryce> jbarnes, any mitigation for the rotation/performance issue?  IIRC that one's been open for quite a while.
[23:54] <jbarnes> not at this point
[23:54] <jbarnes> it's really how the rotation feature was designed
[23:54] <jbarnes> I think keithp is planning to fix it by just pushing the job off to the compositing manager
[23:56] <bryce> any experimental branches available?
[23:57] <bryce> jbarnes, or is there a way to force it to accelerate?  I gather the customer has a demo coming up


[01:02] <shattingduck> hi! I just installed xbmc (media server) and it totally destroyed my panel... I don't have a start menu anymore and it even changed my dual monitor setup. I got the dual monitor thing working again, but my panel is still gone.... how can I fix it?
[01:02] <shattingduck> this sux
[01:04] <rocco> shattingduck:
[01:05] <rocco> right click:- add a default panel*
[01:05] <shattingduck> hmmm.. this is strange..
[01:06] <shattingduck>  I added a new panel on the top, then removed the panel on the bottom and now I have my old panel on the bottom again
[01:06] <shattingduck> but the panel on my right sided screen is still gone
[01:06] <shattingduck> this is crazy
[01:15] <rocco> damn
[01:16] <rocco> you need a new* right panel
[01:16] <rocco> i lose my panel frequently...
[01:24] <shattingduck> why do you lose it?
[02:03] <TheFakeazneD525> How does one lose a panel?
[03:00] <mahesh> I've uninstalled bluedevil and can not reinstall it with following note The "bluedevil" package could not be marked for installation or upgrade: Depends: bluedevil, but it is not installable any help?
[09:48] <lordievader> Good morning.
[10:00] <anukul> good evening
[10:01] <lordievader> Hey anukul, how are you?
[10:02] <anukul> I'm fine.
[10:50] <BluesKaj> 'Morning folks
[11:12] <michel> I have no sound on Kubuntu 14.04 I tried all the ajustement I could try but I had to change for an other version. I rely like Kubuntu someone can tell me what does not work with the sound of kubuntu?
[11:14] <yuitimothy> do you have a video card that supports HDMI sound?
[11:14] <michel> Yes with
[11:14] <michel> yes with they other version I have no problem
[11:15] <yuitimothy> what brand/model sound cad do you have?
[11:16] <yuitimothy> oh and laptop or desktop?
[11:19] <michel> desktop gf 116 high definition
[11:29] <michel> I found somme info here http://wiki.linuxmce.org/index.php/Audio_over_HDMI I will try again
[12:33] <ARM9> is it possible to make a bootable live USB without removing stuff that's already on it?
[12:34] <lordievader> I think most, if not all, automatic tools will format it. But you can do it manually.
[12:35] <ARM9> any decent guides for the latter?
[12:37] <lordievader> ARM9: This might help you: http://askubuntu.com/questions/325073/how-to-create-ubuntu-liveusb-manually
[12:38] <lordievader> Though I think it is easier to copy the contents of the stick to another place. Perform the live-usb creation and then put the files back.
[12:39] <ARM9> yeah
[12:40] <ARM9> only problem is I've got like 20GiB of stuff on my only >1GiB usb drive
[12:40] <ARM9> and it's pretty slow even for USB 2
[12:41] <lordievader> Maybe a good time to move it to a more permanent/faster storage?
[12:41] <ARM9> yeah, about time
[16:33] <reffcap09> would anyone care to help me im trying to install mesa drivers for kubuntu 23.04
[16:33] <reffcap09> 12.04 sorry
[18:20] <micha_> Hi, I have a problem with my headset, a logitech g930. It's an usb headset with a microphone. Whenever I plug it in I either get the microphone or the speakers but never both. Any ideas?
[18:21] <micha_> thought alsamixer does show both as beeing available
[18:28] <micha_> Phonon seems to randomly load either the mono-input or the output profile but never both.
[18:32] <BluesKaj> micha_, install pavucontrol, it might give more control over the inputs and outputs
[18:36] <micha_> nope, it does show my headphones as beeing unplugged for playback, but picks up my headset microphone.


[05:26] <Verterok> hi
[05:27] <Verterok> a quick Q: is there a way to recover from a failed upgrade to a launchpad hosted branch?
[05:48] <krow> Is there an open bug on the "not everyone getting all email" issue with LP right now?
[05:50] <wgrant> krow: On mailing lists or otherwise?
[06:26] <ToyKeeper> Verterok: You could probably delete the affected branch and re-push it, though the delete branch function seems to be missing ever since the last UI change.
[06:31] <Verterok> ToyKeeper: thanks, that sounds ok.
[06:31] <ToyKeeper> A 'push' with some other options may do it too.
[06:31] <wgrant> No need to delete it.
[06:31] <wgrant> bzr push --overwrite or so.
[06:32] <Verterok> wgrant: nice :), I'll try it
[06:32] <Verterok> thanks
[06:35] <Verterok> wgrant: it worked like a charm, thanks
[11:39] <ion_> Any of the links to resulting binaries at https://edge.launchpad.net/ubuntu/+source/linux/2.6.26-5.13/+build/677140 do not seem to work.
[11:42] <jpds> ion_: It was built 11 hours ago. I believe it thinks time for the binaries to move around.
[11:43] <wgrant> ion_, jpds: It's in NEW.
[11:43] <wgrant> Otherwise the binaries will be there as soon as the links are.
[11:43] <ion_> I was hoping to get the binaries no matter whether it’s in NEW or not. :-)
[11:43] <wgrant> ion_: You'll have to hunt the queue for that.
[11:44] <ion_> Ah, will do.
[11:44] <ion_> Would be nice if those links pointed to the binaries in the queue. :-)
[12:57] <vadi2> Hello. What is the name of the string that Launchpad makes when people translate your app? I couldn't locate it in the help files
[12:58] <vadi2> (a string with the translators names)
[17:15] <Bowasilu> Is it possible to host a project that has a BSD-like licensed GUI and a LGPLed module as one project on launchpad?
[17:16] <beuno> Bowasilu, yeap, as long as they're free, absolutely
[17:17] <Bowasilu> beuno: Thanks.
[17:17] <Bowasilu> I found little comparison between Google Code and Launchpad. Why am I better off with Launchpad? :)
[17:19] <beuno> Bowasilu, well, Launchpad has bugs, answers, PPA's for your own debs, etc
[17:19] <beuno> google uses svn, which is sub-optimal for open source development (VCS vs DVCS)
[17:20] <mdke> in a document describing Launchpad, is there any way to generically link to a person's homepage so that the link will be valid for whoever clicks on it? e.g. launchpad.net/~myaccount?
[17:21] <Bowasilu> beuno: svn is suboptimal for open-source?
[17:22] <beuno> mdke, there is a URL...
[17:22]  * beuno tries to remember
[17:22] <beuno> it was something like +me
[17:22] <beuno> which doesn't work
[17:22] <mdke> i tried that one :)
[17:23] <beuno> Bowasilu, well, centralized version control
[17:23] <beuno> distributed gives you so much additional liberty...
[17:23] <Bowasilu> beuno: I'll read up on this topic, thanks. :)
[17:23] <beuno> mdke, I can't remember
[17:24] <mdke> beuno: no worries, thanks
[17:24] <stgraber> beuno: /people/+me/
[17:25] <beuno> stgraber, that's it, thanks. mdke ^
[17:29] <mdke> stgraber: thanks very much
[17:29] <mdke> very useful
[17:30] <vadi2> What is the name of the translation string that contains all people who helped translate?
[17:33] <mdke> translation-credits?
[17:33] <mdke> or something like that
[17:41] <Laibsch> What does "RF 5324" stand for?
[17:42] <Laibsch> https://bugs.launchpad.net/soyuz/+bug/139619
[17:46] <mdke> Laibsch: it means that the bug was fixed in code version 5324 of launchpad
[17:47] <mdke> see https://help.launchpad.net/LaunchpadReleases for more info
[18:34] <Laibsch> thanks mdke
[18:34] <Laibsch> rf?
[18:34] <Laibsch> what does it stand for exactly
[18:35] <Laibsch> release $something?
[18:35] <LarstiQ> fersion? :)
[18:35] <elmo> RocketFuel
[18:35] <elmo> which is the nick/codename for the Launchpad source code
[18:36] <Laibsch> so many names ;-)
[18:36] <Laibsch> LarstiQ: I like the "fersion"
[18:36] <Laibsch> pronounced in a way you need a wischmop to clean up afterwards
[18:36] <Laibsch> ;-)
[18:51] <afflux> Is it possible to rename a project to avoid a name conflict? I registered pyotr a while ago and noticed that there seems to be a sourceforge project called pyotr (though it does not seem too popular, as was unable to find it using google).
[18:52] <zyx386> هح
[18:52] <zyx386> hi
[18:53] <zyx386> anyone from translation team her?
[19:08] <Laibsch> zyx386: ping jtv when he is around
[19:08] <Laibsch> bye
[19:15] <vadi2> Is there a help file somewhere on how to use 'translator-credits' in rosetta? I can't find any information.
[19:18] <vadi2> Nevermind, I figured it out. It's a special string in the GtkAboutDialog.
[20:02] <warren> Hmm, http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/changes
[20:02] <warren> one person pushed 882 but I don't see it
[20:04] <beuno> warren, it takes a minute
[20:04] <beuno> it's up now
[20:07] <warren>     push branch<EMAIL_ADDRESS>[20:07] <warren>   parent branch<EMAIL_ADDRESS>[20:07] <warren>   submit branch: /home/warren/work/k12linux/ldm-glibc
[20:07] <warren> hmm, what does submit branch mean?
[20:13] <Peng_> The default branch to diff against when you run "bzr send".
[22:04] <zeth> Erm, no offence, but when did the new launchpad site design happen?
[22:05] <ScottK> ;-)
[22:06] <zeth> It looks like a 1980s tape player
[22:06] <zeth> which is cool or not cool depending on your perspective
[22:06] <zeth> but I personally don't like the buttons
[22:07] <ion_> I like the new color scheme much more.
[22:08] <zeth> okay, I just went to a big screen, and it looks ok on large monitor; but on my little 1024x800 subnotebook, it looks bad
[22:09] <zeth> Well I liit that below the buttons is more minimal, although the "Report a bug" etc buttons at the bottom of some pages are still in old button format
[22:10] <zeth> maybe I get used to it
[22:10] <zeth> I give it a chance
[22:43] <_steven_> I keep getting connection timeout when attempting to push a bzr branch to launchpad. Anyone have any ideas?
[22:45] <_steven_> are there server problems? Or am I doing something wrong?
[22:47] <afflux> _steven_: looks like I can't connect either
[22:48] <_steven_> I've been trying for 3-4 days to push a branch with the same thing
[22:49] <afflux> oh. well, It has worked quite well for me about 3 hours ago
[22:50] <_steven_> so it's only down when I try I guess :D