[00:19] <qengho> Someone on recent Saucy help me check if I'm sane.
[00:20] <qengho> $ grep ^DAEMON /etc/init.d/lightdm
[00:20] <qengho> $ ls -l /usr/*bin/lightdm
[00:24] <robru> $ grep ^DAEMON /etc/init.d/lightdm
[00:24] <robru> DAEMON=/usr/bin/lightdm
[00:24] <robru> $ ls -l /usr/*bin/lightdm
[00:24] <robru> -rwxr-xr-x 1 root root 176368 Jul 22 16:43 /usr/sbin/lightdm
[00:24] <robru> qengho, ^
[00:26] <qengho> robru: thanks.  I'm trying to figure out if that's as bogus as it looks.  I rebooted one machine, and it didn't launch a greeter until I set those to /usr/sbin .
[00:27] <robru> qengho, are you saying it's not safe to reboot my current saucy system? shit
[00:27] <qengho> robru: I'm still looking.  It's not perilous.  You'll recover.
[00:28] <robru> check if the init script changed recently?
[00:32] <qengho> robru: If I'm reading this "etckeeper" diff right, no etc change since May. Maybe the binary moved.
[00:33] <qengho> I don't really trust this machine now. Could another /etc/init.d/ script start another greeter?
[00:33] <qengho> on yours?
[00:33] <qengho> robru: ^
[00:34] <robru> qengho, not sure, how would I check that? last time I booted (7 days ago) I saw lightdm without any issue
[00:35] <robru> qengho, try running 'debsums -as', will make sure that all the files on the system match the checksums from their respective packages. helps improve confidence in a system i find
[00:35] <qengho> robru: Yep. Add "cruft" to your toolkit, too.
[00:37] <sarnold> qengho: ooh, cruft looks useful. thanks.
[00:38] <robru> interesting, running it now
[04:46] <pitti> Good morning
[04:49] <larsu> pitti: Guten Morgen!
[04:50] <pitti> hey larsu, wie gehts?
[04:50] <larsu> pitti: gut! War endlich mal früher hier als du :P  Und dir?
[04:51] <pitti> larsu: danke, ein bisschen muede; noch lange gehackt gestern :)
[04:53] <jbicha> larsu: do you use the same alarm clock setting as pitti? ;)
[04:54] <pitti> I don't have an alarm clock even -- my wife gets up at 5 normally, then I sleep for a bit longer and then just wake up
[04:54] <larsu> jbicha: no, I don't have an alarm clock. Just happened to wake up early today
[04:55] <larsu> well, technically I _do_ have an alarm clock on my phone, but I never set it :)
[04:55] <jbicha> hmm, maybe it's just something about Germany then :)
[04:55] <larsu> jbicha: land of the early risers!
[04:55] <pitti> jbicha: well, I go to bed at 10 pm, so it's only natural that I don't sleep that long
[04:56] <pitti> and it's actually quite nice in summer, you can spend the better part of the work day in the cooler hours
[04:59] <TheMuso> You Europeans are lucky with your summers and sunlight well into the evening, although I guess you pay for it in Winter. :)
[05:01] <RAOF> You don't need to go all the way to Europe for that :)
[05:02] <TheMuso> Oh ok, wasn't sure just how things are in Tassy. :)
[05:04] <didrocks> well, in Winter, it's the night starting 4:30/5PM
[05:05] <larsu> didrocks: salut!
[05:05] <didrocks> hey larsu! how are you?
[05:06] <larsu> didrocks: very good, thanks. You?
[05:09] <didrocks> larsu: I'm fine, thanks :)
[05:13] <pitti> bonjour didrocks!
[05:13] <didrocks> hey pitti!
[05:14] <jbicha> didrocks: hey could we have someone look at the notify-osd autopkgtest failure since it's holding up gtk+3.0
[05:15] <jbicha> I didn't even see enough information in the build log for me to know what exactly is failing
[05:16] <pitti> yeah, "fun" wit the parallel test runner again
[05:16] <pitti> but I recently learned a trick
[05:16] <pitti> put VERBOSE=yes into TEST_ENVIRONMENT
[05:17] <jbicha> oh and the tests seem to pass locally here
[05:17] <didrocks> jbicha: I won't have the time honestly, but try with macslow? he's upstream for it
[05:19]  * pitti runs it in run-adt-test
[05:23] <pitti> reproduces fine
[05:27] <pitti> a simple package build and 'xvfb-run --server-args="-screen 0 800x600x8" make check' reproduces it, too
[05:28] <pitti> ** (./test-modules:18204): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
[05:28] <pitti> apparently the test suite uses fatal-criticals or so?
[05:29] <jbicha> oh yeah, I forgot that autopkgtests have to be run separately, right?
[05:29] <pitti> what do you mean?
[05:29] <jbicha> I really don't know much about them
[05:29] <pitti> jbicha: I just unpacked the package, dpkg-buildpackage -b, and run make check under xvfb
[05:30] <pitti> (which is essentially what happens in n-osd's autopkgtest)
[05:30] <jbicha> I did bzr bd  on lp:notify-osd without errors
[05:30] <pitti> jbicha: yes, but the package doesn't run tests during buuild
[05:30] <pitti> which is unfortunate
[05:30] <jbicha> ^ that's what I mean
[05:35] <jbicha> pitti: is it as simple as a missing dependency on at-spi2-core ?
[05:35] <pitti> could be
[05:35]  * pitti tries
[05:54] <pitti> jbicha: hm, if I install at-spi-core "make check" hangs indefinitely
[05:54] <pitti> spi2
[05:55] <pitti> and under dbus-launch I get even more errors
[05:55] <pitti> /bubble/can set bubble attributes: loading icon 'notification-/usr/share/icons/Human/scalable/status/notification-message-im.svg' caused error: 'Icon 'notification-/usr/share/icons/Human/scalable/status/notification-message-im.svg' not present in theme'
[05:55] <pitti> ** (./test-modules:13683): WARNING **: AT-SPI: Could not obtain desktop path or name
[07:29] <jibel> good morning
[07:36] <sil2100> Morning!
[07:47] <sil2100> seb128: morning!
[07:47] <seb128> sil2100, hey, how are you?
[07:47] <seb128> good morning desktopers!
[07:47] <sil2100> seb128: fine, how about you? Do you have a moment for some packaging ACKs?
[07:47] <seb128> sil2100, sure
[07:47] <sil2100> seb128: since I'd like to publish something but didrocks is not around ;)
[07:47] <seb128> no didrocks today?
[07:48] <sil2100> He was here, but got disconnected and didn't appear again
[07:48] <seb128> ok
[07:48] <sil2100> seb128: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Settings/job/cu2d-settings-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gsettings-qt_0.0+13.10.20130725-0ubuntu1.diff <- your changes ;p
[07:48] <sil2100> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Settings/job/cu2d-settings-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1+13.10.20130725-0ubuntu1.diff <- same here ;p
[07:48] <sil2100> I guess it's an ACK?
[07:49] <seb128> sil2100, it sure is ;-)
[07:49] <sil2100> Publishing then
[07:49] <seb128> thanks!
[07:50] <sil2100> seb128: now for the other... do you know if url-dispatcher and gsettings-ubuntu-touch-schemas got preNEWed?
[07:52] <seb128> sil2100, what stack is that? I just got an email from didrocks, he says the tech from his provider is at his place setting up his new connection and that you can publish misc
[07:52] <sil2100> Ah, it's in misc
[07:52] <sil2100> Ok ;)
[07:52] <sil2100> So I guess it's ok
[07:52] <seb128> he has some comments but nothing blocking
[07:52] <seb128> I had preNEWed the schemas one
[07:52] <sil2100> seb128: and another one (the rest is still pending): webcreds http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/WebCreds/job/cu2d-webcred-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_accounts-qml-module_0.1+13.10.20130725-0ubuntu1.diff
[07:52] <seb128> I guess didrocks did the dispatcher
[07:53] <seb128> sil2100, +1
[07:53] <sil2100> seb128: thanks!
[07:53] <sil2100> I'll wait for the rest to finish, as we were blocked by the long unity testing again, so some other stacks might also need ACKing once they're done
[07:59] <sil2100> didrocks: hi!
[07:59] <didrocks> hey sil2100!
[07:59] <sil2100> didrocks: internet back? ;)
[07:59] <didrocks> I'm on a 3G connexion
[07:59] <didrocks> sil2100: not yet
[08:00] <sil2100> Ah
[08:00] <sil2100> didrocks: I published misc, but
[08:00] <didrocks> ah great :)
[08:00] <didrocks> on url_dispatcher:
[08:00] <didrocks> - needs a symbol files
[08:00] <didrocks> - short description of -dev and the lib are the same
[08:00] <didrocks> - url-dispatcher needs to be multiarched (in a multiarch path)
[08:00] <didrocks> (that's my notes ;))
[08:00] <sil2100> didrocks: I hope you don't mind I published indicators a bit 'strangely'
[08:00] <sil2100> didrocks: ok, will do :)
[08:00] <didrocks> sil2100: what about indicators? :p
[08:01] <sil2100> didrocks: since the thing was, the tests passed but build job failed (chroot problems with armhf on the PPA)
[08:01] <Laney> morning
[08:01] <sil2100> didrocks: so I rebuilt it and then ran the publish job manually as I was doing in the past
[08:01] <didrocks> sil2100: hum, that should work
[08:01] <didrocks> hey Laney
[08:01] <sil2100> didrocks: but it suddenly published it normally and now the head job is still red ;p
[08:01] <didrocks> sil2100: interesting
[08:01] <didrocks> sil2100: I'll have a look when being on a stable connection
[08:02] <sil2100> didrocks: so all is published ok just the head job is red, as I was running publish job manually - since I didn't want to force publication, just wanted to see the result
[08:02] <sil2100> And I didn't want to have the check job ran
[08:02] <sil2100> And I didn't want to play around with switches
[08:02] <sil2100> ;)
[08:02] <didrocks> sil2100: you're right ;)
[08:02] <didrocks> sil2100: so don't touch anything
[08:02] <didrocks> I'll have a look :)
[08:03] <sil2100> didrocks: oh, and one thing I noticed
[08:03] <sil2100> didrocks: I ran ./cu2d-run -P misc on the misc stack, and I see it's as if it's rebuilding everything from scratch
[08:03] <sil2100> didrocks: since it's waiting on the build job again ;/
[08:04] <seb128> hey didrocks Laney
[08:04] <didrocks> sil2100: oh, it should skip it
[08:04] <didrocks> sil2100: ok, don't touch misc/indicators, I'll have a look :)
[08:08] <sil2100> ;)
[08:09] <larsu> pitti: I'm hitting that upowerd hanging bug almost daily now :(  Do you know the status on that?
[08:10] <pitti> larsu: I don't, no; do you have an idea how to get this? I haven't run into it here yet
[08:10] <pitti> larsu: also, do you know if there's a bug report for this already?
[08:11] <larsu> pitti: I only ever notice it when the machine comes back from suspend. I can't reproduce it though, it doesn't happen on every suspend.
[08:11] <larsu> pitti: bug is #1203655
[08:11] <larsu> pitti: I've attached a stacktrace there. Let me know if I can provide more info
[08:16] <sil2100> Eh
[08:16] <sil2100> A bad day for didrocks to not have internet
[08:17] <sil2100> There's a problem with stack publication after yesterdays changes
[08:18] <sil2100> Need to wait with publication for Didier, as the stacks unnecessarily re-run the AP testing ;/
[08:20] <seb128> sil2100, well, publication of indicators and settings worked ... which one is the problem?
[08:22] <pitti> bonjour seb128
[08:23] <seb128> pitti, salut, ca va bien ?
[08:23] <pitti> seb128: je vais bien, merci ! et toi ?
[08:24] <sil2100> seb128: misc and SDK was working strange
[08:24] <sil2100> seb128: I forced a publication, but this only re-ran the stack and they're in manual publication again
[08:25] <sil2100> I could re-try, but I guess it's best if Didier could see what was going on
[08:25] <larsu> sil2100: is this why I got emails for unapproved MRs for i-sound and i-power?
[08:26]  * larsu was wondering what he should do with these
[08:26] <sil2100> larsu: hm, I think those are unrelated - which MRs were those?
[08:27] <Laney> Selecting previously unselected package libmaliit-plugins0.^M
[08:27] <Laney> Unpacking libmaliit-plugins0 (from .../libmaliit-plugins0_0.99.0+git20130615+97e8335-0ubuntu1_amd64.deb) ...^M
[08:27] <Laney> dpkg: error processing /var/cache/apt/archives/libmaliit-plugins0_0.99.0+git20130615+97e8335-0ubuntu1_amd64.deb (--unpack):^M trying to overwrite '/usr/lib/libmaliit-plugins.so.0', which is also in package maliit-framework 0.94.2-0ubuntu1b1^M
[08:27] <seb128> pitti, je vais bien merci, il fait frais ;-)
[08:27]  * Laney coughs
[08:28] <pitti> seb128: oui, il a plu à nouveau après troix semaines \o/
[08:28] <seb128> Laney, missing replaces?
[08:28] <larsu> sil2100: this one for example: https://code.launchpad.net/~ps-jenkins/indicator-sound/latestsnapshot-12.10.2+13.10.20130725-0ubuntu1/+merge/176886
[08:28] <Laney> more than likely
[08:28] <larsu> sil2100: ah, it's on merged now. Nevermind then :)
[08:28]  * larsu was confused because indicator-applet-developers is still on "Pending"
[08:29] <Laney> why does it do an mp for that instead of just pushing it?
[08:30] <seb128> larsu, that's how it has been for months? e.g https://code.launchpad.net/~ps-jenkins/indicator-session/latestsnapshot-12.10.5daily<IP_ADDRESS>-0ubuntu1/+merge/162660
[08:31] <larsu> seb128: yeah, I'm very confused :)  I'm still on a just-got-the-keys-to-my-appartment high
[08:31] <seb128> Laney, not sure, I guess it's safer to handle conflicts if somebody pushed to trunk in between
[08:31] <seb128> larsu, oh, congrats! ;-)
[08:31] <Laney> woo
[08:31] <seb128> larsu, is that the nice one you were visiting on monday?
[08:32] <larsu> seb128: yep :)
[08:32] <seb128> nice!
[08:32] <larsu> seb128: fairly close to dholbach, too. And to his office (where we're hanging out right now)
[08:32] <seb128> larsu, no homeless jokes anymore for you then :p
[08:33] <seb128> oh, nice
[08:33] <larsu> seb128: \o/
[08:33] <seb128> say hello to him from me ;-)
[08:33] <Laney> I saw a post somehwere, there's quite a lot of people in that office today isn't there?
[08:34] <larsu> seb128: he still doesn't quite believe you'll make it to Berlin :)
[08:34] <larsu> seb128: but he's hopeful
[08:34] <seb128> lol
[08:35] <seb128> larsu, good to know you have a place as well, if I come and Daniel decide to kick me out, I've another place close by ;-)
[08:35] <larsu> seb128: for sure!
[08:35]  * seb128 hugs larsu
[08:36]  * larsu hugs seb128 back
[09:15]  * seb128 just got the new qtcreator
[09:16] <seb128> nice to have easy access to the sdk api in the sidebar and to have click packages in there ;-)
[09:16] <seb128> (a bit weird to have main UI space taken for pastebin and IRC though)
[09:16]  * Laney arghs at cdbs
[09:16]  * sil2100 needs didrocks
[09:16] <sil2100> I *need* him
[09:16] <Laney> how can I run a testsuite under xvfb-run in cdbs?
[09:16] <sil2100> ;)
[09:17] <Laney> sil2100: don't we all?
[09:17] <seb128> sil2100, still cu2d issues?
[09:17] <seb128> Laney, convert to dh9 :p
[09:17] <Laney> seb128: they just converted it from dh to cdbs ... :P
[09:17] <seb128> wth?
[09:18] <Laney> told you, packaging rewrite
[09:18] <Laney> trying to bring back one or two things that it did before
[09:18] <seb128> that's ridiculous... I didn't know they changed the build system
[09:18] <seb128> you should just overwrite their changes
[09:18] <Laney> rewrote the copyright file and everything
[09:18] <seb128> take back your packaging
[09:18] <Laney> well there are some actual changes in there
[09:18] <seb128> and bring back maybe their control for the new build-depends/binaries
[09:18] <Laney> so it would require untangling those
[09:19] <seb128> :-(
[09:19] <Laney> I think I got something
[09:19] <seb128> well, cdbs to dh9 should be easy
[09:19] <Laney> DEB_MAKE_CHECK_TARGET := -f debian/rules run-tests
[09:19]  * Laney coughs
[09:24] <didrocks> (still on 3G for now)
[09:24] <Laney> didrocks: moving to something new and super fast?
[09:25] <didrocks> Laney: right! but for that, has to fight a little bit apparently with the infra ;)
[09:25] <Laney> yeah that's usually the way
[09:25] <didrocks> and no, 300Mb/s won't make me the official libroffice uploaders :p
[09:26] <Laney> wow that /is/ quite fast
[09:26] <didrocks> I don't think it will be a big change in day-to-day though
[09:26] <Laney> I don't think my internal network at home could push such speeds :P
[09:26] <didrocks> as we are more relying on the latency
[09:26] <Laney> slow powerline is slow
[09:26] <Laney> yeah
[09:26] <didrocks> yeah, indeed
[09:27] <Laney> you'll be a good iso tester
[09:27] <didrocks> ahah ;)
[09:27] <seb128> sil2100, ^ grab him while he's here!
[09:28] <didrocks> seb128: I saw his email about the ./cu2d-run -P running tests
[09:28] <didrocks> if that's the question
[09:28] <didrocks> or should I worry more? ;)
[09:28] <seb128> didrocks, I don't know he just wrote
[09:28] <seb128>  sil2100 needs didrocks
 I *need* him
[09:32] <seb128> Laney, I've an easy enough u-s-s review waiting if you feel like doing it ;-)
[09:32] <Laney> Status: successful
[09:32] <Laney> finally
[09:32] <Laney> let me do a test upgrade and then upload that, then i can see about reviews
[09:32] <didrocks> sil2100: I think you do run cupstream2distro with the latest rev, right?
[09:33] <seb128> Laney, thanks
[09:33] <didrocks> jibel: FYI, the ati machine was down this morning
[09:33] <didrocks> thomi was around to restart it electrically
[09:34] <didrocks> (also, we had some launchpad chroot issues, I relaunched some)
[09:34] <didrocks> sil2100: it seems that misc stack was republished
[09:34] <didrocks> redeployed*
[09:34] <didrocks> without my changes in trunk
[09:34] <jibel> didrocks, down, like yesterday or down like powered down?
[09:34] <didrocks> so you don't have the parameter to force publicaiton
[09:34] <didrocks> sil2100: I think that's why you see the tests running :p
[09:34] <didrocks> sil2100: do you mind redeploying when adding them? :)
[09:35] <didrocks> jibel: apparently, thomi told me the UI was stuck
[09:35] <didrocks> jibel: I couldn't even ssh to it
[09:35] <didrocks> sil2100: when redeploying a stack, always ensure if you do that from your own branch that you are in sync with trunk, please ;)
[09:36] <sil2100> !
[09:36] <didrocks> sil2100: I'll let you fix that? (I think media as well can be published)
[09:36] <sil2100> didrocks: I didn't redeploy anything yesterday besides unity8
[09:36] <didrocks> sil2100: also, did you ask someone to refresh the white list on the server?
[09:36] <didrocks> hum
[09:36] <didrocks> someone did redeploy misc…
[09:36] <didrocks> obviously
[09:36] <didrocks> for the new components
[09:37] <sil2100> didrocks: seb128 said that you said that I can publish misc
[09:37] <sil2100> So I did
[09:37] <didrocks> sil2100: yeah, but it seems the guy deploying it wasn't sync with trunk
[09:37] <sil2100> geh
[09:37] <didrocks> (to add the new components)
[09:37] <didrocks> sil2100: mind doing that? then I think your -P should work as excepted
[09:37] <jibel> didrocks, okay maybe I'll reinstall it completely too when I'll install the nvidia box
[09:37] <didrocks> no build/tests step
[09:37] <didrocks> just publishing
[09:38] <didrocks> jibel: ok ;)
[09:38] <sil2100> Let me backlog completely
[09:39] <sil2100> didrocks: ok, so - I'll redeploy misc from trunk, ensuring that the two packages are added and republish
[09:39] <sil2100> didrocks: SDK also suffered from the same proble IIRC
[09:40] <sil2100> So maybe it wasn't redeployed after your changes?
[09:40] <sil2100> geh, and now the check job failed...
[09:41] <asac> pitti: you tested media player on mako/n4?
[09:42] <pitti> asac: yes, but only from starting from unity; I think that's known-broken, one needs to launch it with a video as argument
[09:42] <asac> pitti: hmm. can you check with ogra how to test it properly?
[09:42] <pitti> asac: I read somewhere that it ought to be possible to launch it from the file lens, but I copied a video into ~/Videos and don't see it anywhere
[09:42] <asac> pitti: he has no mako ... we know its really working for maguro and really broken for grouper
[09:43] <asac> so from that pov our dashboard is indeed correct
[09:43] <ogra_> i think we should wait for jhodapp to get up
[09:43] <asac> now if i knewe that mako is really officially not working
[09:43] <ogra_> the currently shipped media stack is deprecated
[09:43] <ogra_> there is a new one that isnt in the archive yet
[09:43] <asac> i dont care bout the future
[09:44] <asac> i want to know if our mediaplayer is broken on todays image :)
[09:44] <ogra_> and i dont know exactly wheer it lives ... i think there is a PPA somewhere
[09:44] <asac> on mako....maguro i have on my own
[09:44] <ogra_> asac, well, popey is usually my mako tester ... but he is at oscon this week
[09:44] <ogra_> (we're really short on mako and manta ... dunno why)
[09:45] <didrocks> sil2100: I did a script
[09:45] <didrocks> sil2100: so everything should be redeployde
[09:45] <sil2100> didrocks: oh, so just re-publishing now? ;)
[09:46] <didrocks> sil2100: I mean, I ran a script the other day
[09:46] <didrocks> so everything should be working
[09:46] <asac> ogra_: order a mako please
[09:46] <asac> and expense
[09:46] <ogra_> will do
[09:46] <asac> ogra_: if you dont do it today let me know so i can see what the official PO route would be
[09:46] <asac> ogra_: you can still buy N4, right?
[09:46] <ogra_> asac, it would also make sense if someone in an EU TZ could have a manta
[09:47] <ogra_> (i dont owant one, though ... give it wo some other team :) )
[09:47] <ogra_> yeah, you can
[09:47] <pitti> well, the app doesn't even have an icon (emmpty frame) and does nothing when clicking on it, which seems to be a problem even before the media API?
[09:48] <ogra_> pitti, so how did you start it ? by clicking on one of the three shipped movies ?
[09:48] <pitti> ogra_: I read somewhere that one needs to copy a video to ~/Video and then find that on the dash
[09:48] <ogra_> Sintel should always work i think
[09:49] <pitti> ogra_: there are a gazillion dummy movies in the dash, which ones are working?
[09:49] <ogra_> just go to the video lens
[09:49] <ogra_> try the first movie there
[09:49] <ogra_> the first three should work
[09:49] <sil2100> didrocks: hmmm
[09:49] <pitti> ogra_: oh, nice; wasn't aware of that
[09:49] <pitti> ogra_: that does work, yes
[09:49] <sil2100> didrocks: eh, I just tried to redeploy misc and got an error!
[09:49] <ogra_> good
[09:49] <pitti> ogra_: so it's not showing my own videos anywhere, but the MP works
[09:50] <ogra_> likely an encoding problem
[09:50] <ogra_> you might use a codec this medai api doesnt support
[09:50] <ogra_> *media
[09:50] <ogra_> lets swait for jhodapp ... he can tell us more
[09:52] <ogra_> asac, so the daily tests are fine (they either use the shipped videos or something with similar codec)
[09:54] <asac> ogra_: on dashboard we see maguro succeed, mako and others failing
[09:54] <asac> i flile that as "its really the case" now
[09:54]  * ogra_ checks the logs
[09:55] <ogra_> asac, both failing tests are UI related
[09:56] <asac> ogra_: so do we measure that our apps are busted or not?
[09:56] <seb128> ogra_, can I see the date of the image I'm using from somewhere on the device?
[09:56] <ogra_> contol visibility and playback button states
[09:56] <ogra_> seb128, /var/log/installer/media-info
[09:56] <seb128> ogra_, thanks
[09:56] <ogra_> like in all other ubuntu installs :)
[09:56] <seb128> 20130722
[09:56] <seb128> hum
[09:56] <seb128> that's outdated :p
[09:57]  * seb128 updates system-settings manually
[09:57] <ogra_> ogra@chromebook:~$ get-touch-img-ver --current
[09:57] <ogra_> 20130722
[09:57] <ogra_> seb128, no, it isnt :)
[09:57] <sil2100> didrocks: something's badly broken
[09:57] <ogra_> that the last one that passed testing
[09:57] <seb128> ogra_, let's say it doesn't have what I want to test :p
[09:57] <sil2100> didrocks: I tried to force publish of media and it's running the AP tests ;/
[09:58] <ogra_> seb128, use phablet-flash --pending
[09:58] <sil2100> didrocks: maybe I should use jenkins UI for that?
[09:58] <ogra_> ogra@chromebook:~$ get-touch-img-ver --pending
[09:58] <ogra_> 20130724
[09:58] <seb128> ogra_, no that's ok, I dist-upgraded, no need to reinstall, I'm just testing settings stuff
[09:58] <seb128> ogra_, but thanks
[09:59] <ogra_> http://paste.ubuntu.com/5910631/ ... in caase you want the get-touch-image-ver script
[10:00] <seb128>  thanks
[10:01] <didrocks> sil2100: ok, I'll have a look soon
[10:14]  * didrocks on fiber \o/
[10:17] <ogra_> didrocks, dont fall ... thats thin
[10:18] <didrocks> ;)
[10:18] <Sweetsha1k> bdrung: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=shortlog;h=refs/heads/ubuntu-saucy-4.1
[10:19] <mlankhorst> hm h ow do I start the onscreen keyboard manually?
[10:19] <didrocks> Laney: can we have ~ubuntu-unity as part of ~system-settings-touch please?
[10:20] <didrocks> Laney: that would help to deploy the changes ;)
[10:20] <Laney> didrocks: ask seb128
[10:20] <didrocks> seb128: ^
[10:20] <Laney> how would it help?
[10:21] <seb128> didrocks, hum, why is that needed? (things seem to work fine today)
[10:21] <didrocks> seb128: we can't deploy the stack, like sil2100 isn't in the team
[10:21] <didrocks> so when trying to "fix" the branch config, he's rejected
[10:21] <sil2100> :<
[10:22] <seb128> I guess I don't understand the issue or what is "deploy the stack", settings is properly configured and landing today no?
[10:22] <seb128> didrocks, sorry, answer is yes, but I would like to understand what's going on as well
[10:22] <seb128> ;-)
[10:22] <didrocks> seb128: when you ./cu2d-update-stack -U ../stacks/head/misc.cfg
[10:23] <didrocks> we bzr config every branches
[10:23] <didrocks> so that lp-propose destination is "trunk"
[10:23] <didrocks> otherwise, it can be that the config is incorrect
[10:23] <didrocks> so, we use the deploy step command (cu2d-update-stack) to do that
[10:23] <didrocks> but this config ask people to have write rights on the branch
[10:24] <didrocks> so if sil2100 tries to deploy misc, he won't be able to do that writing
[10:24] <seb128> settings should be in their own stack (settings), not in misc?
[10:24]  * seb128 didn't even know you could bzr config branches like that
[10:25] <didrocks> seb128: IIRC from the discussion from the other day we told misc
[10:25] <didrocks> but that won't change the need to be able to configure it :)
[10:25] <seb128> that was the schemas right?
[10:25] <didrocks> yep
[10:25] <seb128> ok,makes sense ... added
[10:25] <didrocks> thanks!
[10:25] <seb128> thanks for the context! ;-)
[10:25] <didrocks> yw ;)
[10:26] <didrocks> do you want that to be moved in another stack?
[10:26] <didrocks> in the near future?
[10:26] <seb128> no
[10:26] <didrocks> ok
[10:26] <seb128> the schemas still makes sense in misc
[10:26] <seb128> I was confused, I though you were speaking about the settings app
[10:26] <seb128> which is in settings ;-)
[10:26] <didrocks> sil2100: I'm redeploying, but you should be able as well
[10:26] <didrocks> ah ;)
[10:26] <didrocks> yeah, the gsettings-ubuntu-touch-schemas
[10:26] <seb128> right, I got it now ;-)
[10:26] <Laney> are we uploading the schemas now?
[10:27] <didrocks> Laney: as soon as the deploy is finished
[10:27] <didrocks> and that sil2100 runs publish then
[10:27]  * didrocks pulls on the archive admin machine the whitelist
[10:27] <Laney> seb128: Do you think we should confirm these keys are wanted in the system schema before upuloading?
[10:28] <seb128> Laney, no, we can still change the schemas later if needed
[10:28] <Laney> it's some kind of API
[10:28] <seb128> Laney, no need to block on it imho
[10:28] <seb128> well, unused api
[10:28] <seb128> but yeah, better to confirm sooner than later
[10:28] <didrocks> hum, weird, it's like it can't set the config…
[10:28]  * didrocks tries manually
[10:29] <seb128> Laney, btw testing the tz stuff on the touch image, for some reason the action doesn't work
[10:29] <Laney> which action?
[10:30] <seb128> Laney, I installed policykit-desktop-privileges (which is not on the touch image) but it still doesn't work, (which is not a surprise , /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla doesn't list org.freedesktop.timedate1)
[10:30] <seb128> Laney, clicking on a tz
[10:30] <Laney> why does it work on the desktop?
[10:30] <seb128> it doesn't?
[10:30] <didrocks> sil2100: around? mind trying to publish misc now?
[10:30] <Laney> does for me
[10:30] <seb128> I though it did
[10:30] <seb128> Laney, right, that's my point, work on the desktop and not on the touch image ... I wonder if the polkit acl are configured differently
[10:31] <seb128> Laney, policykit-desktop-privileges is missing on the touch image, which I though would be the issue, but it still doesn't work
[10:31] <Laney> are denials logged somewhere?
[10:31] <seb128> pitti, ^ does polkit log credential issues somewhere?
[10:31] <Laney> hoho
[10:32] <seb128> Laney, other issue (going to be fun), the panel takes a good 3-4s to load after you click on it, I guess it's the time it takes to load the list of cities
[10:32] <seb128> Laney, it's polish for later but it's long enough that we should probably display a spinner or something while it's loading
[10:33] <didrocks> hum no sil2100
[10:33] <didrocks> I think I'll publish misc
[10:33] <Laney> I should probably delay initialising it until the first request at least
[10:34] <sil2100> eh, had a phone call
[10:34] <sil2100> Publishing
[10:34] <sil2100> didrocks: you published already?
[10:34] <didrocks> sil2100: yeah, just did
[10:34] <didrocks> sil2100: it works :)
[10:34] <sil2100> \o/
[10:34] <didrocks> sil2100: so, now, let's try to redeploy with my fix media
[10:35] <sil2100> didrocks: will you redeploy?
[10:35] <didrocks> sil2100: it shouldn't run the check, right?
[10:35] <sil2100> (which branch?)
[10:35] <didrocks> sil2100: media is fine to publish?
[10:35] <sil2100> It shouldn't, I just want it to publish ;P
[10:35] <didrocks> ok
[10:35] <sil2100> It was fine before
[10:35] <sil2100> But check failed now
[10:35] <sil2100> ;/
[10:35] <didrocks> sil2100: please, try to publish it now (I repdeployed)
[10:35] <pitti> seb128: you can try running it in the foreground, but polkitd isn't very verbose unfortunately
[10:36] <sil2100> didrocks: ok, publishing anyway, as it's a single failure on one machine and the last run was fine
[10:36] <didrocks> sil2100: ok, let's see, the check job shouldn't trigger the tests (well, one kick test with nothing done)
[10:37] <sil2100> didrocks: publish made, let's see
[10:37] <sil2100> didrocks: works \o/
[10:37] <sil2100> didrocks: publish job blinking
[10:37] <sil2100> didrocks: publishing apps as well
[10:37] <Laney> seb128: calling the method manually shows that it is denied
[10:37] <didrocks> sil2100: no no
[10:37] <sil2100> didrocks: does it need a redeploy as well?
[10:37] <didrocks> sil2100: to skip tests, I made a fix :)
[10:37] <sil2100> ;)
[10:38] <didrocks> sil2100: right, only misc was in the bad case because someone redeployed :p
[10:38] <didrocks> (without syncing in trunk)
[10:38] <didrocks> for the tests not running, it was actually a bug
[10:38] <didrocks> (well, running, when they shouldn't)
[10:38] <didrocks> sil2100: I'm redeploying everything, will tell you once apps ok
[10:38] <seb128> Laney, how/where do you call it?
[10:39] <seb128> Laney, I think those action are allowed for the default local user, that might not be the case over ssh or adb
[10:39] <didrocks> sil2100: apps done, do you have others that I should prioritize?
[10:39] <Laney> seb128: I made a shell script to call it and ran that from the terminal on the device to check that
[10:40] <seb128> Laney, ok ... does it say why it's refused ... and did you install policykit-desktop-privileges ?
[10:40] <Laney> no and yes
[10:40] <mlankhorst> oh looks like onboard crashes in saucy..
[10:40] <seb128> I don't get how it's working on the desktop
[10:40] <Laney> also it works over ssh to the desktop
[10:40] <seb128> /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla doesn't list timedate1
[10:41] <sil2100> didrocks: what about unity8? ;) Would that also be affected?
[10:41] <seb128> Laney, I wonder if polkit works at all on the touch image
[10:41] <seb128> pitti, ^ do you know
[10:41] <didrocks> sil2100: right
[10:41] <didrocks> Saviq: should we unblock unity8 now that you have some integration tests?
[10:41] <seb128> Laney, but I think cjwatson is using it for click installs, so it should be working
[10:41] <Saviq> didrocks, see #ubuntu-unity
[10:41] <Saviq> didrocks, yes
[10:42] <didrocks> Saviq: was on 3G, so dropped quite often ;)
[10:42] <didrocks> Saviq: ok, next, right?
[10:42] <Saviq> didrocks, yes
[10:42] <didrocks> sil2100: unity8 redeployed, I'm removing the lock
[10:43] <Laney> seb128: it's in /usr/share/polkit-1/actions/
[10:43] <Laney> let me try allow_active yes
[10:44] <seb128>                         <allow_any>auth_admin_keep</allow_any>
[10:44] <seb128>                         <allow_inactive>auth_admin_keep</allow_inactive>
[10:44] <seb128>                         <allow_active>auth_admin_keep</allow_active>
[10:44] <seb128> I don't know how to read those
[10:45] <seb128> hum
[10:45] <seb128> does it mean auth is required (e.g asking a password)
[10:45] <seb128> ?
[10:45] <Laney> yes, but i don't know how the authorisation is provided on the desktop
[10:45] <Laney> obviously doesn't ask for a password there
[10:45] <seb128> right
[10:46] <seb128> well /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla has
[10:46] <seb128> Action=org.gnome.clockapplet.mechanism.*;org.gnome.controlcenter.datetime.configure;org.kde.kcontrol.kcmclock.save
[10:46] <seb128> I wonder if the indicator still use one of the old interfaces listed there
[10:46] <Laney> u-s-s doesn't
[10:46] <seb128> or is timedate should be added
[10:46] <seb128> oh, right
[10:46] <seb128> puzzling
[10:46] <seb128> the phablet user is in the admin group
[10:46] <pitti> seb128: in principle yes, but I get a "not authorized' e. g. on pkcheck --action-id org.freedesktop.upower.suspend --process $$ in ssh (as that's not a local session)
[10:48] <sil2100> didrocks: \o/ Will publish further in a moment
[10:48] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1196324
[10:48] <ubot2`> Ubuntu bug 1196324 in onboard (Ubuntu) "onboard crashed with SIGSEGV in PyUnicode_InternInPlace()" [Medium,Confirmed]
[10:48] <mlankhorst> boo
[10:48] <didrocks> sil2100: all head redeployed FYI
[10:48] <didrocks> sil2100: lock on unity8 removed
[10:48] <didrocks> Saviq: ^
[10:48] <Saviq> didrocks, yay!
[10:49] <Saviq> didrocks, can we please trigger the stack?
[10:49] <didrocks> Saviq: oh, something needed from this morning since the last daily release?
[10:50] <Laney> pitti: hmm, it didn't work to set allow_active=yes but allow_any did
[10:50] <Saviq> didrocks, well, we never pushed to next?
[10:50] <Saviq> didrocks, or did we now?
[10:50] <Laney> even from terminal on the device
[10:50] <pitti> Laney: loginctl show-session <session-name> shows it as active/local?
[10:50] <didrocks> Saviq: we'll get that night dailies now that we have the green flag :)
[10:50] <didrocks> Saviq: as everything built still in daily-build-next
[10:50] <Laney> pitti: State: active
[10:50] <Saviq> didrocks, yeah, but we want to push through smoke asap
[10:51] <Saviq> didrocks, so we need it in next
[10:51] <didrocks> Saviq: yeah, that's why I asked sil2100 to publish it ;)
[10:51] <Saviq> didrocks, ah ;)
[10:51] <Saviq> didrocks, didn't see that
[10:51] <didrocks> Saviq: so, you will get it in a ppa publisher round I guess
[10:52] <Saviq> didrocks, and it will merge back the changelog bump?
[10:52] <didrocks> Saviq: right
[10:52] <Saviq> didrocks, thanks
[10:52] <didrocks> yw ;)
[10:52] <didrocks> Saviq: and raring release redeployed as well
[10:53] <didrocks> argh
[10:53] <didrocks> sil2100: ^
[10:53] <Saviq> didrocks, raring? ;)
[10:54] <didrocks> Saviq: yeah, daily releases are used in both raring and saucy
[10:54] <didrocks> (for SRUs)
[10:54] <Saviq> didrocks, k
[10:56] <sil2100> didrocks, Saviq: just one more moment guys, barraged by phones ;/
[10:56] <didrocks> sil2100: i'm publishing unity8, don't worry
[10:56] <didrocks> done
[11:08] <Laney> bah I don't understand
[11:08] <Laney> as far as I can see polkit should consider the phablet user an admin
[11:08] <seb128> right
[11:08] <seb128> it's in the admin group
[11:08] <seb128> Laney, it doesn't?
[11:08] <Laney> /etc/polkit-1/51-ubuntu-admin.conf
[11:09] <Laney> err add a localauthority.conf.d in there
[11:09] <Laney> don't know, that's my assumption from this failure
[11:36] <mlankhorst> tkamppeter_: ping
[11:46] <jbicha> how exactly do I run the autopkgtests?
[11:49] <seb128> jbicha, http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[11:49] <seb128> run-adt-test
[12:21] <jbicha> Sweetsha1k: ooh, AOO and LO do their releases in the same week now?
[12:22] <jbicha> cadence ftw :)
[12:25] <Sweetsha1k> jbicha: <quote="Linus Torvalds">... completely unintended sideeffect ...</quote>
[12:27] <Sweetsha1k> jbicha: no, really: That we release this week has been set for a long time -- why AOO considered it a wise choice to go head-to-head with us is a mistery to me ...
[12:29] <jbicha> well it encourages journalists to do a AOO vs. LO comparison, not sure if that helps them much though
[12:51] <sil2100> didrocks: related to url-dispatcher!
[12:52] <sil2100> didrocks: since you said you want url-dispatcher in multiarch directory
[12:52] <didrocks> sil2100: no, I meant, it was in a multiarch directory
[12:52] <didrocks> without multiarch tags
[12:52] <sil2100> Ah
[12:53] <sil2100> Then it's done
[12:53] <sil2100> https://code.launchpad.net/~sil2100/url-dispatcher/packaging_additions/+merge/176927
[12:53] <sil2100> I thought you wanted something moar
[12:53] <sil2100> ;p
[12:53] <didrocks> +Multi-Arch: same
[12:53] <didrocks> miss the pre-depends
[12:54] <didrocks> sil2100: apart from that, the rest looks good :)
[12:54] <sil2100> Ah ;)
[12:55] <sil2100> didrocks: pushed
[12:56] <didrocks> sil2100: approved
[13:23] <Sweetshark> Heh, LibreOffice 4.1.0 downloads from the ppa: 1 for saucy, 170 for raring, 360 for precise ;)
[13:24] <Sweetshark> I should switch with ricotz and only work on precise from now on ;)
[14:33] <sil2100> didrocks: in some free time, could you also take a look here? https://code.launchpad.net/~sil2100/otto/fix_1203809/+merge/176692
[14:33] <didrocks> sil2100: can you have a look with jibel? i'm under too many requests
[14:33] <sil2100> didrocks: ok, already poked him, but he seems to be a fan of bash -e which I hate!
[14:34] <didrocks> he's right
[14:34] <didrocks> it's useful
[14:34] <sil2100> But what's the point if you expect some command to return false to do error handling?
[14:34] <sil2100> It's useful if the script is wrongly written
[14:35] <didrocks> hum? you always have a good way to get that in
[14:35] <didrocks> assign defaults
[14:35] <didrocks> and so on
[14:35] <didrocks> please check with him, I really have no time for it now and I think this merge isn't the way to fix it :/
[14:36] <sil2100> geh, could someone give me rationale why?
[14:36] <sil2100> I'll poke jibel about that
[14:36] <sil2100> Since I see no sense in it frankly
[14:37] <sil2100> jibel: ping
[14:37] <sil2100> jibel: what do you use the bash -e flag for?
[14:38] <sil2100> jibel: since I think that having that would mean that if any of the commands fail during execution, we have no means to trigger a reaction
[14:39] <jibel> sil2100, pong
[14:40] <sil2100> jibel: one way could be moving the set +e before the otto-run command
[14:40] <jibel> sil2100, yes, -e exit on error, without -e it would continue on unhandled errors leading to unexpected results
[14:40] <sil2100> jibel: yes, but only this one script has -e
[14:40] <jibel> sil2100, it would be like ignoring all the exceptions in python
[14:41] <sil2100> jibel: but what about handling those errors? Simply bailing out sometimes is not enough, as in this case
[14:41] <jibel> it should be a default of bash :)
[14:41] <sil2100> jibel: then what if you want to handle the case of a command failing yourself?
[14:41] <sil2100> jibel: since you want to perform cleanup, for instance?
[14:43] <jibel> sil2100, in that case add a trap on exit. As I said I'll have a look at this script, the only problem this -e causes for the moment is that the message telling where to download the archive from is not displayed
[14:43] <sil2100> jibel: as I said, we can move the "set +e" command one line up, before the /bin/otto-run setup, as in this case we know that there are no operations besides that
[14:44] <sil2100> Since anyway /bin/otto-run is the almost-last thing that gets executed
[14:44] <sil2100> And show_dl_addr $CONTAINER
[14:44] <sil2100> Anyway has -e disabled
[14:45] <sil2100> I'll modify the merge request with this other change
[14:53] <jibel> sil2100, I'd rather use a form like :  sudo -E $HOME/bin/otto-run $CONTAINER $TS_EXPORT || echo "E: otto-run exited with status $?"
[14:53] <jibel> instead of disabling error checking
[14:57] <sil2100> jibel: will that work?
[14:57] <sil2100> hm
[14:58] <sil2100> It seems to work indeed
[14:58] <jibel> :)
[15:00] <sil2100> jibel: looks more friendly indeed now, didn't know that feeding the status further quiets it down, I think I had a bad understanding of it
[15:00] <jibel> sil2100, the logic here is to check the value of the logical expression, and echo always exit with 0. When otto fails it is equivalent to 1||0
[15:01] <sil2100> jibel: sweet!
[15:01] <sil2100> ;)
[15:01] <jibel> sil2100, in this case we don't really care about the exit status of otto-run because we use the junit files to interpret the result not the exit status of the runner
[15:02] <sil2100> Right, well, works for me as well - if you find it ok, I'll fix up my merge with thanks and let's get it in then ;)
[15:06] <sil2100> jibel: pushed, with the commit message modified to the new approach - thanks!
[15:16] <seb128> Laney, larsu: just as a fyi (and if you want to have a quick look for stupid errors I might have made): https://code.launchpad.net/~seb128/phone-app/ringtone-in-gsettings/+merge/176968
[15:17] <larsu> seb128: will have a look later. Thanks
[15:20] <Laney> seb128: you didn't describe the message sound

[15:21] <seb128> Laney, oh, good catch ;-)
[15:22] <Laney> does this imply that u-s-s will have to depend on phone-app?
[15:26] <seb128> Laney, the phone settings panel is, yes...
[15:26] <seb128> larsu, can we have gsettings-qt qml bindings not abort on missing schemas?
[15:26] <Laney> hmm
[15:27] <seb128> larsu, or an api to check if a schemas is installed?
[15:27] <seb128> Laney, you think that phone-app specific settings should rather be in the shared schemas set?
[15:27] <Laney> I don't know
[15:27] <Laney> I see the depends becoming large
[15:28] <seb128> well, it's supposed to be part of the full image
[15:28] <seb128> not a standalone app
[15:28] <Laney> Not sure if there's a reason, other than maybe to allow other implementations of phone apps?
[15:28] <larsu> seb128: sure, but that will take a bit. Can you open a bug and assign it to me?
[15:28] <seb128> that sucks a bit for desktop testing
[15:28] <larsu> seb128: please :)
[15:28] <seb128> larsu, sure, thanks
[15:29] <seb128> Laney, my main goal there is to ensure the phone-app is robust, having the schemas with the app seemed a bit more resistant to potential issues
[15:30] <seb128> Laney, I'm still not convinced I like to use something that's going to call abort() for you if there is a problem with the ringtone config, I would rather the code to just fallback to the default sound if that ever happens
[15:32] <Laney> seb128: well if there's a problem then it'd be good to log it and show the user somehow too
[15:32] <Laney> while not breaking stuff if we don't have to
[15:33] <Laney> it probably points to something pretty badly wrong
[15:34] <czajkowski> *stabs* upower! now it's not even telling me if it's charging when plugged in :(
[15:35] <seb128> Laney, well, anyway it's up for review, I'm fine moving the schemas around
[15:35] <seb128> czajkowski, kill it, and restart indicator-power-service?
[15:36] <czajkowski> seb128: see that would have been the smarter move, I just restarted the machine instead.
[15:39] <seb128> Laney, btw https://bugs.launchpad.net/phone-app/+bug/1202253/comments/1
[15:39] <ubot2`> Ubuntu bug 1202253 in phone-app "the ringtone sound should be a setting and not hardcoded" [Undecided,In progress]
[15:39] <seb128> Laney, I asked about the namespace/key location there ... I'm happy to change it if they think it would be better
[15:40] <Laney> seb128: yep
[15:40] <Laney> I don't have a good feeling about this really yet
[15:40] <seb128> Laney, I don't think we are going to end up with more than system settings and phone-app using that key, at least for 13.10
[15:41] <seb128> so we can move it later if needed
[15:41] <seb128> the transition is easy to handle
[15:41] <Laney> ok
[15:42] <seb128> qengho, hey
[15:44] <seb128> qengho, did you see that chromium-browser/saucy is build unhappy?
[15:44] <seb128> https://launchpadlibrarian.net/145781144/buildlog_ubuntu-saucy-i386.chromium-browser_28.0.1500.71-0ubuntu<IP_ADDRESS>_FAILEDTOBUILD.txt.gz
[15:44] <seb128> /usr/bin/ld.bfd.real: out/Release/obj.target/net/libnet.so: undefined reference to symbol 'SSL_ForceHandshake'
[15:44] <seb128> weird that it worked on amd64 though
[15:45] <larsu> seb128: reviewed. Good work, just a few minor issues
[15:46] <larsu> seb128: let me know when you want a re-review
[15:47] <seb128> larsu, thanks ... do you have a pkgconfig file for gsettings-qt?
[15:47] <Laney> I think you do want an absolute path there
[15:47] <Laney> it might be any random sound on the system
[15:47] <larsu> seb128: yes :)
[15:47] <seb128> $ dpkg -L libgsettings-qt-dev | grep config
[15:47] <seb128> $
[15:47] <seb128> larsu, since when?
[15:47] <larsu> Laney: yeah that's what I thought... just wanted to make sure
[15:48] <larsu> seb128: it's in my locally built package... let me check
[15:48] <seb128> larsu, right, they had a define which hardcoded the sound dir, I dropped for a absolute path on purpose there
[15:48] <Laney> it is there
[15:48] <Laney> gsettings-qt.pc
[15:48] <larsu> right, I have it as well
[15:49] <larsu> seb128: grep pkgconfig ;)
[15:49] <rickspencer3> seb128, Laney fyi ... larsu is sitting right next to me, if you need me to give him a dope slap, or a pat on the back, just let me know
[15:49] <qengho> seb128: Yes, saw it yesterday. Working on it.
[15:49] <seb128> $ LC_ALL=C dpkg -S gsettings-qt.pc
[15:49] <seb128> dpkg-query: no path found matching pattern *gsettings-qt.pc*
[15:49] <larsu> rickspencer3: pat on the back!
[15:49] <seb128> qengho, great
[15:49] <seb128> rickspencer3, yeah, definitively pat on the back, buy the man an icecream if you have the chance, he really deserves one ;-)
[15:49] <didrocks> rickspencer3: I'll go for the dope slape if you tempt us :p
[15:49] <Laney> rickspencer3: Yeah, buy him an ice cream instead :P
[15:49] <rickspencer3> icecream would be called for
[15:50] <Laney> rickspencer3: seb128 is the one using wrong versions of the package and blaming larsu ;-)
[15:50] <rickspencer3> it's hot here
[15:50] <larsu> didrocks: dude!
[15:50] <rickspencer3> lol
[15:50] <qengho> seb128: Though, it build elsewhere with no trouble, and now it's a linking error. I don't know what changed.
[15:50]  * didrocks hugs larsu
[15:50] <larsu> didrocks: :)
[15:50] <didrocks> larsu: see how rickspencer3 is mean? ;)
[15:50] <didrocks> it's not us |o|
[15:50] <seb128> qengho, toolchain I guess :/
[15:50] <rickspencer3> didrocks is remembering his first sprint in Paris, I guess?
[15:51] <Laney> rickspencer3: bist du ein Berliner?
[15:51] <rickspencer3> to make UNR?
[15:51] <rickspencer3> Laney, yes, I am a donut
[15:51] <didrocks> rickspencer3: still have scars ;)
[15:51] <Laney> yum yum
[15:52] <seb128> Laney, larsu: ok, I don't understand what's going on
[15:52] <Laney> apt-cache policy libgsettings-qt-dev?
[15:53] <seb128> Laney,
[15:53] <seb128>  *** 0.0+13.10.20130717-0ubuntu1 0
[15:53] <seb128>         100 /var/lib/dpkg/status
[15:53] <Laney> get 25
[15:53] <seb128> but I updated/upgraded this morning
[15:53] <Laney> I bet it was in proposed
[15:53] <seb128> Laney, well I don't get why it's not showing up for me
[15:53] <Laney> https://launchpad.net/ubuntu/+source/gsettings-qt/+publishinghistory
[15:53] <seb128> oh ok
[15:54] <Laney> but if you upgraded this morning you should have had 20 at least ...
[15:54] <seb128> Laney, larsu: ok, I got the update... it has only been published today
[15:54] <Laney> oh well
[15:54] <seb128> yeah, not sure what was going on there
[15:55] <larsu> seb128: wait, you've got the update but still no .pc file?
[15:55] <Laney> I think it's fixed now
[15:55] <larsu> ah okay. /me is not thinking very fast with this heat
[15:56] <seb128> larsu, no, it's all good, I just don't understand why I didn't get that update or the previous one before now ... oh well, at least I got it
[15:56] <Laney> cash in the ice cream promise
[15:56] <larsu> seb128: glad it works now
[15:56] <seb128> now to figure out how to use pkgconfig in cmake
[15:56] <seb128> the lib stuff was working :p
[15:57] <Laney> FindPkgConfig I think
[15:57] <larsu> Laney: cmake is so awesome *sigh*
[15:57] <seb128> I kind of like qmake
[15:58] <seb128> at least for simple stuff
[15:58] <seb128> SOURCES += source.cpp
[15:58] <seb128> qmake; make
[15:58] <seb128> just work (with a qt program)
[15:58] <seb128> well, that line in a .pro
[15:58]  * Laney gets a PKG_CHECK_MODULES 4eva tattoo across his face
[15:59] <larsu> seb128: ya, that's what gsettings-qt is using :)
[15:59] <Laney> actually it was quite easy to make qmake use pkgconfig too
[15:59] <larsu> ya, even creating .pc files is easy
[15:59] <larsu> (even though barely documented)
[15:59] <Laney> but then again I liked wielding autotools for the schemas package too
[15:59]  * Laney is weird
[16:03] <czajkowski> Laney: yes we know :) but we keep you around all the same
[16:03] <Laney> like a blind old dog
[16:03]  * Laney stumbles around knocking things over
[16:04] <czajkowski> Laney: it's that hair in your eyes again isn't it :)
[16:04] <Laney> the fan is currently causing me trouble in that department, it's true
[16:15] <rsalveti> Laney: seb128: iirc the cdbs transition was a leftover to get it built for both qt4 and qt5, but later on just qt5 was supported
[16:15] <rsalveti> and updated copyright was actually adding more missing info there
[16:16] <rsalveti> not breaking anything
[16:17] <seb128> rsalveti, yeah, having an update changing from dh to cdbs seems un-necessary and backward ... it would be nice if you guys just pinged us next time, we can help rebasing/updating in such cases
[16:18] <rsalveti> I don't see as a backward thing there, but I agree it should have kept dh instead
[16:18] <rsalveti> Laney: test was disabled because it was broken in some revs, thanks for adding that back
[16:19] <rsalveti> seb128: that package was a special case, which was forked which tons of changes, and upstream changed completely as well
[16:20] <seb128> rsalveti, anyway just a small glitch, nothing worth arguing over for days
[16:20] <seb128> rsalveti, thanks for the hard work ;-)
[16:21] <rsalveti> seb128: we're getting there, getting rid of the ppa is our first priority, we'll be cleaning and improving things over time
[16:22] <rsalveti> and this wasn't a critical package at all
[16:22] <rsalveti> at least not at this moment, for saucy
[16:41] <seb128> time for some exercice, bbl
[19:04] <jbicha> mpt: https://launchpadlibrarian.net/145855565/Sound%20Menu.png from bug 1202933 :)
[19:04] <ubot2`> Launchpad bug 1202933 in The Sound Menu "Rhythmbox widget always shows after rev. 353" [Undecided,Fix committed] https://launchpad.net/bugs/1202933
[20:08] <Saviq> jdstrand, https://code.launchpad.net/~saviq/qtubuntu/respect-path/+merge/176904
[20:08] <Saviq> jdstrand, https://code.launchpad.net/~saviq/qtubuntu/more-robust-desktop-parsing/+merge/176931
[20:39] <jdstrand> Saviq: thanks! :)
[21:20] <desrt> seb128: hey seb.  late night?
[21:21] <seb128> desrt, yeah, warm summer time, I tend to fall asleep late, wake up late, work up late
[21:21] <seb128> desrt, spanish way :p
[21:21] <desrt> not a bad system
[21:22] <desrt> although the spanish have a pretty good excuse for it
[21:22] <desrt> being in the wrong timezone by 2-3 hours and all....
[21:22] <seb128> getting too hot during the day? same here this week
[21:22] <seb128> that as well...
[21:23]  * seb128 wants 25°C, not 35
[21:23] <desrt> http://weather.gc.ca/city/pages/on-128_metric_e.html
[21:24] <desrt> it's been 22-25 for the past week or two, and forecasted again for the next week
[21:24] <seb128> nice!
[21:24] <desrt> gloriously so.
[21:24] <desrt> larsu picked the wrong time to leave ;)
[21:24] <desrt> (or maybe it got better because he left... hmmm...)
[21:24] <seb128> desrt, http://www.weather.com/weather/tenday/Brno+Czech+Republic+EZXX0002
[21:25] <seb128> desrt, welcome to europe
[21:25] <seb128> desrt, when do you fly?
[21:25] <desrt> what is this 81 degrees
[21:25]  * desrt looks for a enable-sanity button
[21:25] <seb128> it's in C° here
[21:25] <desrt> weird...
[21:25] <desrt> perhaps you have a cookie that i don't
[21:25] <seb128> they consider .ca as being F weirdos :p
[21:25] <desrt> ah.  found it.
[21:26] <seb128> or that
[21:26] <desrt> okay.  that's just stupid.
[21:26] <desrt> 38?
[21:26] <seb128> yeah, welcome to our current weather
[21:26] <desrt> looks like the rain predicted for monday will cool things off 10 degrees or so, at least
[21:27] <seb128> when do you arrive?
[21:27] <desrt> i think i leave here on the 30.  so, 31?
[21:27] <seb128> you should be good then ;-)
[21:28]  * desrt spent all day shaving yaks...
[21:28] <seb128> this week sucks, then hopefully we are back to normal summer
[21:28] <desrt> felt good though: http://modfarmer.wpengine.netdna-cdn.com/wp-content/uploads/2013/07/Shrek2.jpg
[21:29] <seb128> lol
[21:29] <seb128> desrt, because you need warm coats when it's 38°C? ;-)
[21:29] <desrt> nah.... because the file monitor code in GIO is in shambles
[21:29] <desrt> still is, in fact
[21:29] <desrt> but slightly less so now
[21:30] <seb128> desrt, you like file stuff, you should write a qml binding to get the size of a directory... ;-)
[21:30] <desrt> i got onto that particular yak shave as part of my goal to make desktop files efficient.... we currently do a lot of stat() to try and guess if we had any changes...
[21:31] <desrt> mostly because using file monitors from inside of glib itself was almost impossible.  that part is much better after today.
[21:31]  * seb128 is pondering doing system("du DIR")
[21:31] <desrt> not a bad approach, honestly
[21:31] <desrt> did you look at the baobab code?
[21:31] <seb128> I'm half joking
[21:31] <seb128> not yet, I've been busy on other things
[21:32] <desrt> i actually wrote the algorithm several times
[21:32] <seb128> but I think I'm going to do the "du" thing just to get something with real datas
[21:32] <seb128> with a FIXME in the code for later
[21:32] <desrt> once blocking, once threaded, once async
[21:32] <desrt> pbor picked the one he thought was best.  i forget which it was :)
[21:32] <seb128> I don't care about dynamic update
[21:32] <seb128> I just want to put a spinner there
[21:32] <seb128> and replace by the value when it's done
[21:32] <desrt> ah.  he went with threaded.
[21:32] <seb128> so I don't need progress report
[21:33] <desrt> boring :p
[21:33] <seb128> boring is good ;-)
[21:33] <desrt> but ya... that's what you should do then: spin up a thread and have it basically do 'du'
[21:33] <desrt> that's not difficult
[21:33] <seb128> right
[21:33] <seb128> that's what I'm going to do, as a first approch
[21:33] <desrt> you could probably beat du at its game if you used multiple threads
[21:33] <desrt> do some latency hiding....
[21:34] <seb128> it's by far the easiest way to get something
[21:34] <desrt> colin had gotten some hilariously good results out of that kind of thing using gio asyncs
[21:34] <desrt> he also caused the kernel to grind to a halt on processing requests from anything that wasn't his program.... but oh well
[21:34] <desrt> pretty impressive, in any case
[21:34] <seb128> I'm amazed though that this problem is not one that has been solved for ages
[21:35] <seb128> I was sort of expecting that the issue was old enough that most toolkit would have a reference implementation to use by now
[21:36] <seb128> it's also something fairly frequent needed...
[21:36] <seb128> (would it be only by file managers)
[21:36] <desrt> maybe you should ask for gio to grow such a feature
[21:36] <desrt> it might make sense
[21:37] <desrt> if you didn't need progress reports, it would be a pretty simple API
[21:37] <desrt> maybe even could be part of GFileInfo
[21:38]  * seb128 checks if there is already a wishlist about that
[21:40] <seb128> none that I can found, I guess I can open one


[02:13] <LiuKangWins> hey guys, is this where i could get some assistance with lubuntu arm?
[02:16] <LiuKangWins> anyone? bueller?
[02:24] <LiuKangWins> i have a login loop problem with my arm lubuntu on a tab, anyone else had this problem?
[06:56] <yairabr> hii im trying to wrine ubunu on an sd card for beaglboard-xm (new user), but after unzipping the image file i get an .raw file shouldnt i get .img file?
[07:01] <yairabr> ?
[07:01] <yairabr> hii im trying to wrine ubunu on an sd card for beaglboard-xm (new user), but after unzipping the image file i get an .raw file shouldnt i get .img file?
[07:10] <infinity> yairabr: Not really an Ubuntu question, since I assume that image didn't come from us.
[07:10] <infinity> yairabr: But the filename really doesn't matter.


[16:16] <Birk___> I'm trying to set up a cloud enviroment with OpenStack. I have a VM running in a machine located in a local network. I'm trying to ssh this VM from the gateway machine, but I'm getting this erro: Permission denied (publickey). I'm using a .priv archive with this command: ssh -i archive.priv<EMAIL_ADDRESS>[16:16] <Birk___> Anyone have a suggestion on how to solve this problem?


[18:18] <ari-tczew> hi
[18:19] <ari-tczew> I've proposed to merge (update) a bzr branch of sane-backends, would be nice to get it reviewed


[09:39] <rmg51> Morning
[09:47] <JonathanD> Morning rmg51
[09:47] <rmg51> o/
[09:48] <JonathanD> How goes?
[09:50] <rmg51> so far so good
[09:51] <rmg51> just another typical morning
[12:07] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[12:42] <jedijf> rmg51: teddy-dbear free up aug 10th - it's confirmed
[12:42] <teddy-dbear> k
[12:43] <rmg51> ok
[12:43] <jedijf> perfect
[12:43] <jedijf> ChinnoDog: plan to be in PA that weekend
[12:48] <jedijf> ChinnoDog: aug 10th
[13:03] <InHisName> Good Sunny Bacon Morning
[14:24] <waltman> mmm, bacon
[15:28] <bts3685|vps> R2Pi2: jthan_hassling++
[15:29] <jthan> I didn't know we had a bot here
[15:29] <bts3685|vps> i don't know if we do or not
[15:29] <bts3685|vps> but it was the most likely nick
[15:29] <jthan> lol
[15:29] <bts3685|vps> it might be a R-Pi pleia2 just uses for irc though. heh
[15:36] <jthan> How does everyone feel about zsh? Does anyone use it that can compare its resource usage to bash?
[15:39] <jedijf> zsh is the PLUG choice shell
[15:39] <jthan> What's that supposed to mean?
[15:39] <jedijf> grep PLUG ml for info and possibly meeting notes
[15:40] <jedijf> if you can't figure it out - stick with a gui
[15:40] <jthan> Well I'm talking about my linode
[15:40] <jthan> so there's that
[15:40] <jthan> oh.. are ou talking about the grep?
[15:40] <jedijf> wow
[15:40] <jthan> Stop saying things
[15:40] <jthan> I mean to be fair I'm in class
[15:44] <andrew> ... Hi jthan
[15:48] <jthan> andrew: hey
[16:14] <jthan> Was that all..? ? :-p
[16:40] <andrew> Did you want more?
[16:47] <jthan> No
[18:34] <MutantTurkey> multithreaded hell!


[07:10] <xubuntunoob> Wow! Hey everybody! I've been playing with Xubuntu for the past month or so and I've been all alone! So cool to see the usernames of so many Xubuntu fans!
[07:16] <xubuntunoob> Folks - I wonder if you can help me go back to plain old Xubuntu after I tried installing Kubuntu for a short while. I had an ordinary installation of Xubuntu 20.xxx LTS and I installed Kubuntu ... I think it was with the command "sudo apt install kubuntu-desktop". I tried it, thought it was cool and everything, but decided to stay with Xubuntu's
[07:16] <xubuntunoob> interface. I think I removed all the Kubuntu stuff ... but there's still this gigantic awful login screen that only appeared after I installed Kubuntu. How can I go back to the default login screen?
[07:21] <pmjdebruijn> I'm guessing you want to go back to lightdm
[07:21]  * pmjdebruijn has never messed with that
[07:21] <pmjdebruijn> stick around someone might know
[07:23] <xubuntunoob> Argh - I dunno what happened but I got disconnected
[07:24] <xubuntunoob> One guy responded saying that I probably want to go back to LightDM and that I should wait for someone to help me
[07:24] <xubuntunoob> that's the last thing I saw
[07:24] <well_laid_lawn> maybe try   dpkg-reconfigure lightdm
[07:26] <xubuntunoob> I think I tried that last night at like 3am but I'm not sure. Let me try again to see if it does anything
[07:28] <xubuntunoob> Okay - I did it and it still gives me an absolutely enormous greeter - I don't think this is the original greeter, either
[07:50] <well_laid_lawn> xubuntunoob: that sounds like you have the kdm greeter in action - try removing it in the pacage manager
[07:50] <xubuntunoob> i removed all KDE related things
[07:51] <xubuntunoob> i think i got back to the default xubuntu greeter
[07:51] <xubuntunoob> now i just need to figure out how to resize it
[07:51] <xubuntunoob> I followed instructions here: https://wiki.archlinux.org/index.php/LightDM#Greeter
[08:02] <well_laid_lawn> xubuntunoob: so it was lightdm you were using. Well done
[08:18] <xubuntunoob> Thanks, man! Still can't find out how to resize the greeter - any ideas?
[08:19] <well_laid_lawn> not offhand
[08:22] <diogenes_> xubuntunoob, greeter?
[08:23] <well_laid_lawn> yes he has a too large greeter and wants to resize it
[08:24] <well_laid_lawn> settings in /etc/lightdm/lightdm.conf
[08:24] <diogenes_> i suspect nvidia driver.
[08:29] <xubuntunoob> i don't have an nvidia card - intel graphics
[08:33] <diogenes_> xubuntunoob, see if there's anything useful in lightdm-gtk-greeter-settings gui.
[08:38] <xubuntunoob> unfortunately resizing is not in there :(
[08:38] <xubuntunoob> Just tried this and I can't get in my machine - have to ssh in: https://askubuntu.com/questions/1092699/how-to-adjust-display-settings-for-lightdm-greeter-on-18-04
[08:39] <xubuntunoob> had to reverse those changes via ssh. i'm back in with the desktop whew
[08:40] <diogenes_> xubuntunoob, maybe it will make sense to reinstall lightdm.
[08:40] <xubuntunoob> how would you recommend i do that?
[08:43] <xubuntunoob> with: dpkg-reconfigure lightdm
[08:43] <xubuntunoob> ?
[08:44] <diogenes_> sudo apt reinstall lightdm lightdm-gtk-greeter
[08:44] <diogenes_> then reconfigure
[08:46] <xubuntunoob> I see. thank you
[08:47] <xubuntunoob> i'll try this now
[08:50] <xubuntunoob> besides restarting the machine, how do I reload lightdm to reflect these changes?
[08:50] <xubuntunoob> systemctl restart lightdm.service ???
[08:50] <diogenes_> yes
[09:02] <xubuntunoob> well,that was fun
[09:02] <xubuntunoob> still trying to resize the greeter
[09:02] <xubuntunoob> thanks for your help so far, diogenes
[17:22] <coconut> yes! xubuntu 20.04.1 got released!
[17:22] <coconut> http://cdimage.ubuntu.com/xubuntu/releases/20.04.1/release/
[18:28] <professor-mad> hello how can use gtkpod to transfer mp3 to an iphone 6s
[18:31] <professor-mad> when i try to mount it i get this error
[18:31] <professor-mad> https://www.picpasteplus.com/v.php?i=061c3a3b83
[18:31] <professor-mad> any help
[18:31] <professor-mad> ?
[18:33] <diogenes_> professor-mad, if you really desperately need to mount ithings then try a live iso of MX-Linux, it has a builtin tool.
[18:40] <professor-mad> diogenes_, so is not possible in xubuntu
[18:40] <professor-mad> ?
[18:41] <diogenes_> professor-mad, i didn't say it's not possible, it's that i've never had any ithing and i will never touch one, i only presented you with a quick workaround in case you really need it badly.


[00:15] <mup> Bug #1619245 changed: console-conf does not allow to create a user for offline devices <Snappy:Fix Released> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1619245>
[00:55] <mwhudson> um why am i waiting for cloud-init to time out today
[01:02] <ahoneybun> mhall119: popey still kicking?
[02:56] <Brad__> Hello
[06:05] <mup> PR snapcraft#865 opened: Add `init-plugin`  <Created by jaymell> <https://github.com/snapcore/snapcraft/pull/865>
[06:12] <dholbach> good morning
[06:33] <dholbach> didrocks, davidcalle, do you think we could steal a bit of the playpen CI and document it so we can explain upstreams how to set up a build/publication run with CI in a doc somewhere?
[06:34] <dholbach> ethercalc just merged my snapcraft.yaml and they seem interested
[06:35] <didrocks> dholbach: sure, but it only produces amd64 snaps
[06:35] <didrocks> dholbach: I'm going to go to a dark hole (recording some videos)
[06:35] <didrocks> but we can discuss afterwards
[06:36] <dholbach> didrocks, sure, let's chat later
[06:42] <mup> PR snapd#2137 opened: tests: run ubuntu-core-upgrade on own machine <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2137>
[07:59] <mup> PR snapd#2136 closed: tests/lib: prepare ubuntu-core with core from beta <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2136>
[08:04] <om26er> where to find latest all-snap for RPi2 that is not 4gb in size ?
[08:38] <pitti> ogra_, morphis, slangasek: nplan is now in xenial-updates, including all NM and systemd fixes; so you should be able to drop these from the overlay PPA
[08:38] <pitti> (it also includes that NM naming hack)
[08:40] <om26er> does static ip + custom dns work now ? (I remember there was an issue with that)
[09:08] <ogra_> pitti, YAY !
[09:38] <dr1337_> ogra_: what's the best place to start to build a system image for an IoT device using snappy core?
[09:39] <ogra_> dr1337_, what hardware ?
[09:39] <dr1337_> ogra_: ARMv7a
[09:39] <dr1337_> ogra_: BSP is kind of working at the moment
[09:39] <ogra_> is it supported by a kernel we have ? (linke linux-generic)
[09:39] <dr1337_> ogra_: I'm using mainline at the moment
[09:40] <ogra_> no patches ?
[09:40] <dr1337_> ogra_: 4.8.1 so I guess I could just merge the patches
[09:40] <dr1337_> ogra_: no patches
[09:40] <ogra_> ok, so kernel side you might be able to just use the arhive kernel. that makes it easier
[09:40] <ogra_> *archive
[09:41] <ogra_> dr1337_, http://bazaar.launchpad.net/~ogra/+junk/linux-generic-bbb/files this is what i use to build the beaglebone kernel snap from the archive kernel deb
[09:41] <dr1337_> you mean this? - https://github.com/snapcore/sample-kernels/tree/master
[09:42] <ogra_> you might need to switch it to yakkety somehow
[09:43] <ogra_> once you have this done you need to create a proper bootloader setup ... we only support uboot and grub atm
[09:43] <dr1337_> ogra_ isn't xenial supported yet?
[09:43] <ogra_> xenial doesnt have 4.8 debs
[09:43] <dr1337_> ogra_: I have uboot and kernel loading
[09:43] <ogra_> right, you will need to make some adjustments to the build time config of uboot
[09:44] <dr1337_> ogra_: I actually have a rootfs running 16.04.1 core base
[09:44] <ogra_> we load our environment from a binary blob file and only support raw kernel and initrd loading .... these three things need to be enabled in your uboot binary
[09:45] <ogra_> then you need to create the binary blob from your default uboot env and add the snappy specific script and variables
[09:46] <ogra_> once you have all this working, you wrap it together with image partitioning info into a gadget snap
[09:46] <dr1337_> ogra_ what's the binary blob file for?
[09:46] <dr1337_> could you point me in the direction of some documentation?
[09:47] <ogra_> it is similar to uEnv.txt ... but since it has a fixed size you can not corrupt it easily when the filesystem underneath gets issues ...
[09:47] <ogra_> not yet, i have to write some :)
[09:48] <dr1337_> ogra_ is that similar to a boot.scr file?
[09:48] <ogra_> during the boot process both, uboot itself as well as the booted OS can write to the config ... if you use a uEnv.txt file on top of a fat system things can get shuffled around and at some point your file gets corrupt
[09:49] <ogra_> no, it is an actually binary blob, imagine a raw partition for the config ... now take the content and put it into a img file ... that is more how it works
[09:50] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/
[09:50] <ogra_> that are our gadget snap source trees
[09:51] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/beagleblack/README explains how the binary blob gets created
[09:51] <ogra_> and here is an example of the uboot config changes we use http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi3/uboot.patch
[09:56] <om26er> pitti: in netplan world how can I disable wireless power management, any pointers ?
[09:56] <pitti> om26er: that's outside of netplan or even NM; I suggest starting with powertop
[09:57] <pitti> that has toggles for everything, and also shows you which sysfs attribute to toggle
[09:57] <dr1337_> ogra_: thanks mate
[09:57] <pitti> (for scripting it)
[09:57] <ogra_> dr1337_, i'll most likely do a series of blog posts soon and work with the doc team on a proper porting guide
[09:57] <ogra_> just need to find some time :)
[09:58] <dr1337_> ogra_ would love to find out more - we have plans on putting ubuntu core on our "hub" for production
[09:58] <om26er> ... if I can get that running on a Pi
[09:59] <dr1337_> essentially it's a resurrected ninja sphere ;)
[09:59] <ogra_> awesome ... !
[09:59] <dr1337_> ogra_: a bit painful though - working with more exotic hardware this time
[10:00] <ogra_> well, that shouldnt get in your way for doing a basic port
[10:00] <ogra_> and since there is a beaglebone setup deriving from it shouldnt be to hard for your setup
[10:01] <dr1337_> ogra_ well I did spend a whole day banging my head against the table why i couldn't get a UART TTY working with a core rootfs
[10:01] <dr1337_> turns out it was missing udev
[10:01] <ogra_> you mean a base rootfs ?
[10:01] <dr1337_> which is kind of understandable if you're running core fore cloud VMs
[10:01] <dr1337_> yeah
[10:01] <ogra_> (core definitely has udev ;) )
[10:03] <dr1337_> ogra_ not this guy - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-arm64.tar.gz
[10:04] <dr1337_> actually i meant this one - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-armhf.tar.gz
[10:06] <ogra_> dr1337_, well, the core in there is wrong :)
[10:06] <ogra_> (in the name i mean)
[10:07] <dr1337_> ogra_: erm....wtf?
[10:07] <ogra_> http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04.1-base-armhf.tar.gz
[10:07] <ogra_> the "core" named image is just for backwards compatibility ... technically the core name is now reserved for snappy
[10:08] <ogra_> and the old "core" was completely renamed to "base"
[10:08] <dr1337_> ogra_: omg...if only i had known
[10:08] <ogra_> and base is a way smaller packageset
[10:09] <ogra_> (it is pretty much exactly what you get with "debootstrap --minbase")
[10:10] <dr1337_> ogra_ yeah makes sense now
[10:17] <om26er> pitti: I was able to disable wifi power management from classic environment on all-snap. (iwconfig, the friend :)
[10:18] <om26er> ogra_: it adds lxd group but lxd still does not start, AFAIK, lxd needs to be a system group
[10:19] <om26er> zyga: 'home' interface does not connect automatically when I install my snap, is that a bug ?
[10:20] <om26er> my snapcraft.yaml looks like this http://bazaar.launchpad.net/~om26er/+junk/crossbar-snap-pkg/revision/1
[10:20] <om26er> network and network-bind connect automatically however.
[10:34] <ogra_> om26er, so make it one
[10:35] <ogra_> (the -r option to groupadd makes it one)
[10:39] <om26er> ogra_: how can I delete the previously added lxd group ?
[10:40] <ogra_> om26er, hmm, i guess that only works manually
[10:41] <om26er> ogra_: know the filename/location ?
[10:41] <ogra_> (remove it from /var/lib/extrausers/group and /var/lib/extrausers/gshadow)
[11:44] <Brad_> Hello
[11:45] <Brad_> Hi John.
[11:47] <Brad_> Is anyone creating snaps, here?
[11:53] <mup> PR snapcraft#863 closed: history/status alignment fixes <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/863>
[11:56] <mup> PR snapcraft#864 closed: Update documentation links to developer.ubuntu.com that now redirect … <Created by robert-ancell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/864>
[13:04] <liuxg> sergiusens, ping
[13:08] <sergiusens> liuxg just ask the question ;-)
[13:09] <liuxg> sergiusens, last time, I reported a bug regarding installing a local debian package. https://bugs.launchpad.net/snapcraft/+bug/1604669, it was fixed. My question is that how I can make use of it. is there any example for it? thanks
[13:09] <mup> Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1604669>
[13:09] <sergiusens> liuxg just do source: <path to source>
[13:10] <liuxg> sergiusens, what plugin should I use?
[13:10] <sergiusens> liuxg sources and plugins are orthogonal
[13:11] <sergiusens> liuxg but I guess if you just want to unpack, use dump
[13:12] <liuxg> sergiusens,  yes, I just want to install a local debian only. OK. I will have a try. thanks. so "orthogonal" should also work, right?
[13:15] <sergiusens> liuxg USE dump
[13:15] <liuxg> sergiusens, many thanks
[13:44] <rharper> ogra_: hi, I've been trying to find out which part of the build process (using ubuntu-image and my own provided core snap I rebuilt with a PPA to inject a new cloud-init with some snappy changes for system-user assertion);  injects the /etc/cloud/cloud-init.disabled into the system-data partition ... I didn't see anything in the core snap, nor in the pc.gadget or ubuntu-image tool ...
[13:45] <ogra_> rharper, it is actually snap prepare-image i think ... it will create the file if it finds no cloud-init stuff inside the gadget ... then ubuntu-image just blindly copies /etc inot the img
[13:46] <ogra_> so to have it not created you need to ship your cloud-init configuration in the gadget snap ... now ... i dont exactly know how the format has to be ... you have to ask someone from the snapd team .... mvo perhaps
[13:46] <rharper> ogra_: ok, is prepare image part of ubuntu-build ?   a quick grep through mvo's git repo of ubuntu-build didn't hit any lines with cloud-init.disabled
[13:47] <ogra_> prepare-image is a snap command ... "snap prepare-image"
[13:47] <rharper> ah
[13:47] <ogra_> ubuntu-image just calls it
[13:47] <rharper> there's a whole lot of indirection here =)
[13:47] <ogra_> yeah
[13:47]  * rharper goes to read snapd prepare-image code
[13:47] <ogra_> rharper, https://github.com/snapcore/snapd/pull/2101
[13:47] <mup> PR snapd#2101: image: support gadget specific cloud.conf file <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2101>
[13:47] <rharper> ogra_: thanks
[13:47] <ogra_> that looks relevant
[13:48] <ogra_> for deeper insight ask niemeyer or mvo
[13:49] <ogra_> (i.e. i have no clue whats the expected format inside that file, where it lands on the filesystem etc etc)
[13:49] <rharper> right
[13:50]  * rharper goes to make his own gadget snap
[13:50] <ogra_> snappidisnap
[13:51]  * ogra_ sticks his head back into wifiSD card code
[13:52] <mup> PR snapd#2138 opened: many: removed frameworks target, and some leftover frameworks helpers… <Created by chipaca> <https://github.com/snapcore/snapd/pull/2138>
[14:12] <attente> pitti: hey, about #1580740, i see two problems. one is the fake xdg-open script can't be found by the script (which i think is a problem with the snap itself), the other is that nothing is pulling in snapd-xdg-open on the iso
[14:12] <mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-done> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
[14:16] <ogra_> attente, i thought the first one was a snap-confine issue
[14:19] <attente> ogra_: i think the problem is that we don't have the fake xdg-open script anywhere that the snap can find it
[14:19] <ogra_> it should be in /usr/lical/bin inside of the ubuntu-core snap
[14:19] <ogra_> *local
[14:19] <seb128> it's in the ubuntu-core snap no?
[14:20] <seb128> that dir is not in the path though
[14:20] <attente> ogra_: seb128: i did a strace, but it doesn't find it at all
[14:20] <ogra_> (or in future-speak ... in the core snap :)
[14:20] <seb128> attente, is the binary there on disk?
[14:20] <seb128> dunno if ubuntu-core got updated to have it
[14:20] <ogra_> ogra@styx:~$ ls /snap/ubuntu-core/current/usr/local/bin/
[14:20] <ogra_> apt  apt-cache  apt-get  no-apt  xdg-open
[14:20] <seb128> it was outdated for a while, I had to change channel to get it
[14:20] <seb128> but that was like in august
[14:21] <seb128> it might be because that dir is not in PATH
[14:21] <attente> so the telegram snap needs to add it to the path then?
[14:21] <ogra_> it should be ... but to be sure you can indeed add it to PATH in your wrapper
[14:21] <seb128> dunno
[14:22] <seb128> but j_dstrand said it was weird to have in /usr/local anyway
[14:22] <sergiusens> attente what is the path?
[14:22] <seb128> we should probably just move it to /usr/bin
[14:22] <sergiusens> the path I need to add that is
[14:22] <ogra_> seb128, tricky ... since the original lives there
[14:22] <sergiusens> yeah, that would be best seb128
[14:22] <attente> sergiusens: /snap/ubuntu-core/current/usr/local/bin
[14:22] <seb128> ogra_, but the original is not in the ubuntu-core snap
[14:22] <ogra_> so on pd based systems you would have a clash
[14:23] <sergiusens> ogra_ welcome dpkg divert ;-)
[14:23] <ogra_> i.e. it would require quite some dpkg-divert hackery if you want to use similar build scripts for both snaps
[14:23] <attente> the other problem still exists too. nothing pulls in snapd-xdg-open on the iso and it isn't seeded
[14:23] <ogra_> which is awful
[14:23] <seb128> attente, sergiusens, is that snap trying to call xdg-open directly? we have a .desktop that makes the mimetype association so gio functions should work
[14:24] <seb128> attente, right, snapd should probably recommends it?
[14:24] <seb128> but that's up to mvo I guess
[14:24] <ogra_> attente, i think it was supposed to be merged into either snaapd or snap-confine
[14:24] <sergiusens> seb128 honestly have no idea; but I have seen direct calls in some other code
[14:24] <attente> seb128: strace seems to show it looking for the xdg-open binary
[14:24] <seb128> k
[14:24] <ogra_> the sepearate package was an interim afaik
[14:24] <seb128> well try the PATH thing
[14:24] <ogra_> yeah
[14:25] <ogra_> ogra@styx:~$ hello-world.env |grep ^PATH
[14:25] <ogra_> PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[14:25] <ogra_> ogra@styx:~$
[14:25] <ogra_> yeah, not in PATH by default ... but i think the desktop launchers add it
[14:25] <seb128> is that snap using the desktop launcher?
[14:26] <ogra_> (we could just stuff it into /usr/games instead of /usr/local :P )
[15:05] <rharper> created an updated pc gadget to include some cloud-init config, build the gadget snap, updated my model to use the new gadget, signed the model and now building, I get a prepare-image failure, http://paste.ubuntu.com/23313239/
[15:05] <rharper> anyone ever debug a "ERROR:ubuntu-image:Crash in state machine" with prepare-image ?
[15:14] <ogra_> rharper, well, it says it cant find your gadget snap
[15:16] <iliv> how can I donwload source of package (snapcraft.yaml, etc.) for a package that can be installed with snap install $SNAP?
[15:18] <mup> PR snapd#2137 closed: tests: run ubuntu-core-upgrade on isolated machine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2137>
[15:20] <ogra_> iliv, you ahve to ask the packager for it
[15:20] <ogra_> *have
[15:24] <iliv> ogra_, okay, thanks!
[15:32] <rharper> ogra_: hrm, I thought the syntax for a local gadget snap was the name of the snap (without the .snap) extension?
[15:33] <ogra_> in the assertion, yeah
[15:33] <rharper> right
[15:35] <rharper> ogra_: here's the model assertion I have http://paste.ubuntu.com/23313336/
[15:36] <ogra_> rharper, everything after the underscore is a version string ... drop it
[15:36] <ogra_> you only want the name (pc)
[15:37] <rharper> ok, but the .snap file I pass via --extra-snaps is OK to include that string? or just rename it all ?
[15:37] <ogra_> i think it doesnt matter
[15:38] <rharper> got it working now; thanks !
[15:38] <ogra_> :)
[15:54] <om26er> Hi! One of the projects that I am snapping reads /var/lib/dbus/machine-id, in strict mode it gives me permission denied, what's the remedy ?
[15:55] <nacc> om26er: presumably an interface to dbus / that file
[16:01] <mup> PR snapd#2135 closed: cmd/snap: simplify auto-import mountinfo parsing <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2135>
[16:03] <mup> Bug #1632453 opened: snapd won't start on dragonboard <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1632453>
[16:18] <om26er> nacc: right, so it seems instead of permission denied, the issue is that it cannot find that file within its path. So as you say an interface might help here (not sure though what the solution would be).
[16:18] <om26er> http://paste.ubuntu.com/23313607/
[16:18] <nacc> om26er: right, in the snap itself, i doubt that file exists
[16:18] <nacc> om26er: /var/lib/dbus may not exist either, possibly
[16:19] <nacc> om26er: you may want to look at adding a 'shell' application to drop to a shell in your snap's environment to debug
[16:19] <nacc> om26er: and then you could see if adding appropriate pacakge dependencies would fix it (i doubt it, as that's a runtime file)
[16:19] <nacc> om26er: by default, i don't think your snap has any dbus connection
[16:20] <sergiusens> narc om26er snap run --shell <snap-name.app-name>
[16:20] <nacc> sergiusens: ah cool, thanks!
[16:20] <sergiusens> narc ^
[16:20] <nacc> sergiusens: i thought it might exist, but couldn't recall :)
[16:20] <sergiusens> darn. Double fail
[16:20] <nacc> heh
[16:21] <sergiusens> Autocorrect kills me with irc handles
[16:22] <om26er> nacc: sergiusens right, so whats the solution :)
[16:23] <sergiusens> om26er simple one is to make it not depend on /var/lib/dbus
[16:23] <nacc> om26er: i'm guessing either remove that dep, or add an interface that provides it to snaps
[16:24] <om26er> sergiusens: hmm, that's an upstream project that I don't control.
[16:24] <om26er> to be precise: https://github.com/crossbario/crossbar
[16:25] <nacc> om26er: it falls back though?
[16:26] <nacc> om26er: in the code, if it can't read machine-id, it falls back to socket.gethostname()
[16:26]  * sergiusens wonders why everyone is so afraid of forking
[16:26] <sergiusens> it is the BETTER patching afer all
[16:27] <nacc> "On Linux, it is universally available, given that "
[16:27] <nacc> sergiusens: snaps do violate some public blog posts :)
[16:27] <nacc> http://0pointer.de/blog/projects/ids.html
[16:28] <nacc> fwiw, that's the link in crossbar's source as to why they picked that file
[16:28] <om26er> nacc: not sure if it fallbacks, it rather just skips, so the config file ultimately does not have machine_id. I have seen multiple times that causing some kind of error from crossbar
[16:28] <om26er> adding the machine id manually fixes that, so its a bug
[16:28] <nacc> om26er: oh it might be that socket.gethostname() returns nothing? depends on where it's run, i guess
[16:29] <nacc> om26er: a bug in what? i'd say it's a bug in your snap :)
[16:29] <sergiusens> nacc I bet you can use /proc/self/sessionid
[16:29] <nacc> sergiusens: ack
[16:29] <nacc> it seems to be just an arbitrary string to uniquely identify the machine
[16:29] <om26er> nacc: yes, thats that I mean :)
[16:30] <nacc> om26er: so i'd fork and try with something that is available to snaps (just point to your github tree instead of upstream) -- probably can even do a PR to update upstream eventually? Or add an actual interface (if you want), but the latter is probably slower
[16:31] <om26er> nacc: any thing that requires changes upstream is a deal breaker IMO. So would try the slower path but I think there have been conversations on @snapcraft about accessing files from other system directories, so I'll keep a close eye on that.
[16:32] <nacc> om26er: why? you can fork trivially in github and build against your fork?
[16:32] <sergiusens> om26er I disagree about changing upstream
[16:32] <sergiusens> with that mind set nothing new would ever happen
[16:34] <om26er> nacc: I am working with upstream to get their package officially uploaded. this whole app-my_name scheme is what I am trying to avoid.
[16:35] <nacc> om26er: right, but it's not reasonable to say you can snap your application without any modifications
[16:35] <nacc> afaict
[16:35] <nacc> there are assumptions being made, such as this one assumign d-bus is present in the snap
[16:35] <nacc> *accessible perhaps
[16:39] <om26er> sergiusens: historically its been proved that not all upstreams feel excited to change their code to work with a specific project, so the status-quo does exist. Something that cannot be denied.
[16:39] <om26er> nacc: assumption based on suggestions from people working on systemd and pulseaudio and probably dbus.
[16:40] <nacc> om26er: yes, still an assumption
[16:57] <sergiusens> om26er the discussion for me is over as you are not even trying
[16:57] <om26er> sure
[17:55] <ogra_> niemeyer, dude !
[18:05]  * ogra_ goes offline
[20:10] <Croepha> hi, is anyone familiar with an issue where running /snap/bin/ubuntu-image fails when calling snap prepare-image with a complaint about opening the model assertion with no such file or directory, but when I run snap prepare-image directly with the same arguments it works?
[23:21] <mup> Bug #1632886 opened: [Feature Request] Per App Firewall Settings <Snappy:New> <https://launchpad.net/bugs/1632886>