[02:05] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [06:13] <robru> alesage: is there something wrong with the deb in the PPA? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016
[06:14] <robru> alesage: citrain only has source packages in the server, and they're not exposed to the web (although I could reach in and tar one up if you wanted it). all the actual built debs are just in lp.
[06:15] <bzoltan_> robru: Mirv: is there any news about the Vivid landings?
[06:15] <robru> bzoltan_: what about vivid landings? normal as far as I know.
[06:16] <bzoltan_> robru:  normal? Yesterday there was a massive block because of the autopkgtest ...
[06:16] <Mirv> robru: vivid landings are stuck because autopkgtests fail
[06:16] <bzoltan_> robru:  the UITK is at least blocked
[06:16] <robru> bzoltan_: ah I wasn't aware, sorry. haven't heard anything
[06:16] <Mirv> robru: because of bug #1399597 that has no fix that wouldn't regress something else
[06:17] <Mirv> robru: so currently we can either a) break SDK, b) break many packages from migrating to vivid-release, c) bring oxide-qt-codecs-extra to desktop seed, none of which is wanted. we're currently again at b) after the last failed attempt
[06:17] <bzoltan_> Mirv:  why the c) is bad?
[06:18] <robru> Mirv: yikes, I've been so neck-deep in train code I haven't even noticed what's been happening in the archive
[06:18] <Mirv> bzoltan_: because it'd bring h.264 support to the cd images, which is a patent problem
[06:18] <Mirv> (or so I understood it)
[06:18] <robru> Mirv: how is the sdk broken by this? surely the least-bad option is to break just sdk temporarily until they can fix it?
[06:19] <Mirv> robru: click chroots fail to create, and we've just some Chinese SDK usage thing starting if I understood correctly. now it's working, but if we revert to the original situation then it will be broken.
[06:20] <Mirv> the technically correct thing would be to revert to the original situation, but no-one wants to break SDK either..
[06:20] <Mirv> so, currently unity-scope-click autopkgtest fails at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html which prevents at least UITK, but also things like Unity8 from migrating if they're published
[06:20] <robru> Mirv: technically correct is best correct ;-)
[06:22] <Mirv> and it seems apt problem really, since it tries to configure a package that dpkg already removed
[06:39] <Mirv> bzoltan_: I think chrisccoulson had an idea on how to fix the problem, but I'm not sure if he's having the time to do that. something about moving files around and using alternatives system.
[06:43] <bzoltan_> Mirv:  waiting for the magic wand when actually nobody has time time to fix the problem i snot really a good solution
[07:23] <bzoltan_> robru: breaking the SDK would mean no app development for Vivid target and no qmake support .. so technically it would roll back the SDK by 3 months
[07:24] <robru> bzoltan_: oh you wouldn't have to roll back 3 months. you'd just be blocked temporarily until you found a workaround.
[07:25] <bzoltan_> Mirv:  so what pulls the extras to the desktop?
[07:25] <bzoltan_> robru: We are looking for the workaround since Septermber ...
[07:28] <Mirv> bzoltan_: if the order is switched which picks the autopkgtests, the extra package is listed first so it gets installed on desktop too instead
[07:29] <Mirv> so this is what chris rejected but was temporarily in archives https://code.launchpad.net/~timo-jyrinki/oxide/prefer_codecs_extras_lp1399597/+merge/243946
[07:30] <Mirv> then this https://code.launchpad.net/~timo-jyrinki/oxide/arch_specific_replaces_lp1400275/+merge/244307 was the next attempt to keep chris happy but not break sdk or autopkgtests.. 50% succeeded, or not really, the arch specific replaces did not help apt to not break autopkgtests
[07:30] <Mirv> so we're essentially in the same place as after https://code.launchpad.net/~bzoltan/oxide/packaging.vivid-improved-conflicts/+merge/243515
[07:32] <Mirv> apparently Chris himself has not had time for working on this however, unfortunately
[07:32] <Mirv> he should be pinged today whether he could work on his newest idea today
[07:33] <Mirv> I'll free up that one silo that couldn't be landed anyway
[07:42] <bzoltan_> Mirv: it sounds like a super top priority issue ...
[07:49] <Mirv> I made the reopened bug Critical, and yes I agree it should be top priority
[08:45] <bzoltan_> Mirv:  what was the package what directly pulls the extra and confused the apt?
[08:46] <Mirv> bzoltan_: ubuntu-sdk-libs
[08:47] <Mirv> no idea if it would help if that dependency was optional too but the other way around. I don't know if the seeds support that.
[08:47] <bzoltan_> Mirv: why do not we remove that oxideqt-codecs-extra from the seeds then?
[08:47] <Mirv> bzoltan_: because that was the requirement to get it on the phone images. ogra_ would know more, and might also have a solution for us...
[08:48] <Mirv> like, could the dependency be pulled via other route, or would http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.vivid/view/head:/sdk-libs support "* oxideqt-codecs-extra | oxideqt-codecs" (in case that would help with the autopkgtests)
[08:48] <bzoltan_> Mirv:  OK.. so that is a fundamental _BUG_ we want a package directly burned on the phone image, but we do not want the same  package on the desktop image ... that is the mother of the whole conflict.
[08:49] <Mirv> oh but he's on vacation now
[08:49] <cjwatson> seeds can't do or-ed dependencies, no
[08:49] <cjwatson> doesn't really make sense, their purpose is to specify choices
[08:50] <Mirv> ok then that's not an option
[08:51] <Mirv> bzoltan_: we also have the problem that "SDK" is used as "what we want on images"
[08:51] <bzoltan_> Mirv:  true
[08:51] <Mirv> or I'm not sure if that's a problem, but slightly confusing at least
[08:52] <bzoltan_> Mirv:  that is a problem...  we force the extras on the phone image but do not want to see in on the desktop ... that does not sound good
[08:53] <Mirv> bzoltan_: one more thing: since it's unity-scope-click that's failing the autopkgtest, I wonder why it actually depends on ubuntu-sdk-libs as a whole
[08:53] <bzoltan_> Mirv:  if the oxideqt-codecs-extra is needed on the image then it should be pulled from other place than the sdk
[08:53] <Mirv> alecu: pstolowski: ^ unity-scope-click question
[08:55] <bzoltan_> Mirv:  that is a good question too.. I guess the sdk-libs is just a swiss army knife of solving missing dependencies :D
[08:56] <Mirv> bzoltan_: changelog says " Add runtime dependency on ubuntu-sdk-libs for the frameworks list." <- how this could be achieved otherwise?
[08:57] <bzoltan_> Mirv:  hmm... My guess was right .. let me check
[08:57] <Mirv> original bug filed by mvo in May https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1320975
[08:59] <Mirv> bzoltan_: holy... that meta package is not meta package, it's true what it says
[08:59] <Mirv> it includes all the framework files in /usr/share/click/frameworks/ :(
[08:59] <bzoltan_> Mirv:  baaaaah
[09:00] <bzoltan_> Mirv:  and that is aaaaal wrong
[09:00] <bzoltan_> llll
[09:01] <Mirv> I don't know the original reasoning, but what about splitting that to ubuntu-sdk-frameworks or something and fixing unity-scope-click dependency...
[09:02] <bzoltan_> Mirv:  at least that one
[09:02] <bzoltan_> Mirv:  that is an ugly crap ...
[09:13] <Mirv> bzoltan_: lool pstolowski alecu: https://code.launchpad.net/~timo-jyrinki/ubuntu/vivid/ubuntu-touch-meta/split_frameworks/+merge/245078 + https://code.launchpad.net/~timo-jyrinki/unity-scope-click/switch_to_frameworks_dependency/+merge/245080 - makes sense?
[09:13]  * Mirv coffee break before hangout
[09:14] <pstolowski> Mirv, click scope depends on sdk libs to get the list of frameworks, and pass them to the store server
[09:14] <bzoltan_> Mirv: SHIP IT
[09:14] <pstolowski|schoo> Mirv, i need to drop now to sort out some school stuff.. bbl if you need more info
[09:14] <bzoltan_> pstolowski|schoo: and now we fix that the way how it should have been done :)
[09:15] <pstolowski|schoo> bzoltan_, hmm ok, make sure to keep alecu in the loop, he may have more to say on that
[09:16] <bzoltan_> pstolowski|schoo: it was a mistake at the first place to overload the sdk-libs with the framework list
[09:18] <bzoltan_> Mirv:  do you have the rights to fix the seeds?
[09:20] <bzoltan_> Mirv:  it is safe to move the frameworks to an other package as no other package in Vivid depends on the ubuntu-sdk-libs
[09:21] <cjwatson> Mirv: the package that contains the framework declaration has to depend on the packages that actually satisfy the framework, otherwise it's utterly bogus
[09:22] <cjwatson> Mirv: so it might as well be part of ubuntu-sdk-libs, it doesn't really help to have it split
[09:23]  * cjwatson nacks that MP, sorry
[09:24] <cjwatson> pstolowski|schoo: that doesn't make sense - surely it should just use whatever frameworks are present on the system
[09:24] <cjwatson> pstolowski|schoo: ubuntu-sdk-libs is always going to be present on phone images; perhaps other images might have something else.  at any rate it is not unity-scope-click's job to specify that
[09:25] <Mirv> cjwatson: ok then.
[09:25] <cjwatson> pstolowski|schoo: you should clearly get the list of installed frameworks from click rather than hardcoding it; but I think you should drop the ubuntu-sdk-libs dep
[09:25] <Mirv> possibly the unity-scope-click could be made not to depend on it anyhow
[09:27] <Mirv> updated https://code.launchpad.net/~timo-jyrinki/unity-scope-click/switch_to_frameworks_dependency/+merge/245080 to drop it instead..
[09:30] <bzoltan_> cjwatson:  by the time this framework list was added (wrongly) to the sdk-libs the click have not yet provided the fw list
[09:31] <sil2100> jibel: hey! How's the testing looking sp far?
[09:32] <bzoltan_> Mirv:  yes, dropping that dependency is good ...I hope pstolowski|schoo can fix the unity-scope-click to use the click API instead
[09:32] <jibel> sil2100, so far it's okay
[09:32] <jibel> sil2100, nearly 60% complete, it should be finished by end of this afternoon
[09:33] <sil2100> Oh my!
[09:33] <cjwatson> bzoltan_: while it didn't have an API for it, I distinctly remember saying "just do the equivalent of readdir(/usr/share/click/frameworks/) until I provide one"
[09:33] <sil2100> You guys are awesome ;)
[09:33] <bzoltan_> cjwatson: yes, I do remember that
[09:34] <cjwatson> bzoltan_: which is basically all that click's API does, so while it would be better for unity-scope-click to use that, it is not a blocker here
[09:34] <bzoltan_> cjwatson:  yes
[09:39] <ogra_> bzoltan_, so when we talked, i asked you to talk to the webapps team to find out if -extras is actually a requitement of the framework ... did you ask them ?
[09:40] <ogra_> if it isnt, moving the package to touch and desktop-next (or only to touch) and just dropping it from sdk-libs is trivial ...
[09:40] <cjwatson> good point
[09:41] <bzoltan_> ogra_: Let me ask them again... I do not remember an exact answer.
[10:17] <cjwatson> sergiusens: did you run "crontab /srv/cdimage.ubuntu.com/etc/crontab" on nusakan?
[10:19] <bzoltan_> ogra_:  I just had a talk with dbarth about the codecs-extra. So they do need that package on the device image, because a bunch of webapps need it. But they do not specifically need it to be pulled from the ubuntu-sdk-libs. Could we move it to touch seed?
[10:29] <dbarth> ogra_: also, to explain: we don't strictly depend on oxide, since we still have that runtime switch that can take oxide or qtwebkit
[10:30] <dbarth> so at the moment, we still can't fix that with a normal dependency
[10:34] <jibel> Mirv, I had this gallery-app crash again first time I save a photo from the webbrowser. Next tries work fine.
[10:39] <Mirv> jibel: hmmkay
[10:40] <Mirv> bzoltan_: ogra_ is still on vacation, but I offer https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.vivid_move_oxideqt-codecs-extra_to_touch/+merge/245087 now...
[10:40] <jibel> Mirv, however I am still not sure it is caused by 1113 or it existed in previous versions and is just difficult to reproduce
[10:41] <jibel> I'll dig further
[10:41] <bzoltan_> Mirv:  That would satisfy my needs perfectly. Who's approval do we need to roll it out?
[10:45] <Mirv> bzoltan_: cjwatson rejected the previous one, so perhaps him
[10:46] <cjwatson> yes, I can do that
[10:47] <cjwatson> want me to deal with the upload?
[10:47] <bzoltan_> cjwatson: thank you for your help
[10:48] <bzoltan_> Mirv: ^^
[10:57] <Mirv> cjwatson: yes, that'd be welcome
[10:57] <cjwatson> ok, on its way
[10:58] <Mirv> thanks! I'll kick the autopkgtests after it has migrated and update the bug once again
[10:58] <cjwatson> you probably won't need to kick them manually
[10:58] <cjwatson> after all, this situation arises in part because packages depend on ubuntu-sdk-libs; so the automatic system should suffice
[10:58] <cjwatson> but I guess we'll see
[11:04] <Mirv> right probably it will sort out automatically
[11:07] <cjwatson> https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.207
[11:10] <sergiusens> cjwatson: yes :(
[11:13] <cjwatson> d'oh
[11:13] <cjwatson> don't suppose you have crontab -l output in history
[11:13] <cjwatson> failing that I think we resurrected most of it ...
[11:13] <cjwatson> the real problem here is IMO that system-image shouldn't be running as the cdimage user
[11:13] <cjwatson> if it were separate, it could more easily have its own crontab
[11:24] <sergiusens> cjwatson: no I don't, I foolishly trusted the first lines in the crontab that said that it should be in /srv/cdimage.ubuntu.com/etc/crontab if you wanted your changes to survive :-/
[11:25] <cjwatson> That doesn't quite imply the converse :-)
[11:44] <jibel> Mirv, there are 2 other problems with the gallery-app, cropping is broken for several testers, and the rotate action disappeared
[11:55] <Mirv> jibel: sounds bad
[12:45] <Mirv> ^ robru sil2100: the big vivid migration problem resolved, at least for now, via ubuntu-touch-meta package update. possible further actions in unity-scope-click & oxide-qt, but they are not critical to landing other stuff.
[12:48] <sil2100> Mirv: thanks!
[12:48] <sil2100> jibel: geh, are thosw promotion blockera? Can we somehow revert latest gallery from the store?
[12:50] <jibel> sil2100, so the new crop issue seems to be limited to wrong coordinates when you first crop an image. So the result is wrong, this is a regression. Crop not working at all has already been reported in 173
[12:51] <jibel> sil2100, the frequent crashes of gallery-app are more worrying. We should probably prepare for a revert of the gallery
[12:51] <sil2100> Ok...
[12:52] <sil2100> Its a click app so we need bfiller best to revert in trunk
[12:52] <sil2100> Or, hm, maybe theres a revert function in the store?
[12:52] <jibel> sil2100, the changelog doesn't say anything about an update of the crop feature
[12:58] <Mirv> jibel: because how the rtm branch was set up, in addition to the latest changes the branch had unreleased commits 1102-1111, of which 4 had actual changes other than translation updates. those don't seem to touch cropping either - only album changes in all of those.
[12:59] <Mirv> http://bazaar.launchpad.net/~phablet-team/gallery-app/rtm-14.09/changes
[13:00] <Mirv> that deducting from the previous version's version number including "1101", before rtm branch existed
[13:04] <Mirv> thanks cjwatson for making vivid + bzoltan + etc happy, all seems fine for now and I've noted on the bug on the possible further actions for unity-scope-click & oxide-qt but which are less critical
[13:06] <cjwatson> Mirv: cool
[13:08] <cjwatson> Mirv: I've clarified a couple of points
[13:11] <Mirv> thanks, better
[14:08] <jibel> Mirv, the crash of the gallery app could be due to the thumbnailer upload on the 16th
[14:09] <jibel> Mirv, om26er can reproduce it easily and will try previous version
[14:21] <Mirv> jibel: ok. the diff was this interesting http://launchpadlibrarian.net/191646180/thumbnailer_1.3%2B14.10.20141020-0ubuntu1_1.3%2B15.04.20141106~rtm-0ubuntu1.diff.gz together with qtubuntu-camera from rsalveti / jhodapp / satoris
[14:25] <Mirv> the qtubuntu-camera was huge: http://launchpadlibrarian.net/192809040/qtubuntu-camera_0.3.3%2B14.10.20141001-0ubuntu1_0.3.3%2B15.04.20141208.is.0.3.3%2B15.04.20141204~rtm-0ubuntu1.diff.gz (publishing history seems to confirm it's correct: https://launchpad.net/ubuntu-rtm/+source/qtubuntu-camera/+publishinghistory )
[14:25] <Mirv> I've updated the bug #1376500 which the landing fixed, which was also not updated to indicate it would have been fixed in the first place
[14:27] <Mirv> the trello comment on that landing does not seem to indicate the "silo-diff" (from brendand) was used to actually check the rtm diff, as it only mentions the silo fixing two bugs
[14:28] <Mirv> jibel: crash was also mentioned in the trello: https://trello.com/c/zpBMvnsD/443-ubuntu-rtm-landing-012-qtubuntu-camera-thumbnailer-jhodapp-satoris
[14:32] <jibel> bfiller, hey, the crash of the gallery app seems to be caused by the thumbnailer. brendand and om26er both confirmed that reverting this package fixes the issue
[14:32] <jibel> Mirv, bfiller what would be the impact of a revert of this package?
[14:33] <Mirv> jibel: see above for the diff:s. it would help if only thumbnailer needs to be reverted.
[14:34] <bfiller> Mirv: can you paste the diff link again
[14:34] <bfiller> Mirv, jibel: I would think we'd need to revert the qtubuntu-camera and thumbnailer together but need to see what changed
[14:35] <Mirv> bfiller: http://pastebin.ubuntu.com/9560672/
[14:35] <jibel> bfiller, http://launchpadlibrarian.net/191646180/thumbnailer_1.3%2B14.10.20141020-0ubuntu1_1.3%2B15.04.20141106~rtm-0ubuntu1.diff.gz
[14:36] <Mirv> both of the landings were some weird landings anyhow wrt changelogs
[14:36] <Mirv> qtubuntu-camera http://launchpadlibrarian.net/192809040/qtubuntu-camera_0.3.3%2B14.10.20141001-0ubuntu1_0.3.3%2B15.04.20141208.is.0.3.3%2B15.04.20141204~rtm-0ubuntu1.diff.gz
[14:38] <bfiller> jibel: is there a stack trace for the thumbnailer crash?
[14:38] <jibel> bfiller, no there is nothing
[14:39] <bfiller> jibel: how do we know it's thumbnailer then?
[14:39] <jibel> bfiller, there are several uploads to errors.u.c but none of them has been retraced successfully
[14:40] <jibel> bfiller, we started seeing the crash on 181 and the crash doesn't happens if you downgrade thumbnailer to 1.3+14.10.20141020-0ubuntu1
[14:40] <bfiller> jibel: if the crashes can't be reproduced with the old thumbnailer I would be in favor of reverting it. The change there is to use the thumbnail out of the exif file rather than generate it on it's own
[14:41] <bfiller> jibel: reverting it shouldn't have any major negative effect, should be like before. The thumbnail generation will be slow and memory intensive but that is what it's been up until now anyway
[14:41] <bfiller> I'd say this is a risky fix for not a huge gain right now
[14:41] <bfiller> +1 for revert
[14:41] <bfiller> I'm just not sure about qtubuntu-camera
[14:42] <om26er> bfiller, maybe ask jhodap about that ?
[14:42] <bfiller> om26er: yeah don't see him online
[14:43] <om26er> ugh
[14:43] <jibel> brendand, om26er Mirv okay to revert thumbnailer?
[14:44] <om26er> yes, makes sense to me.
[14:49] <Mirv> jibel: om26er brendand bfiller: I'm past my EOD and already late for a meeting, but landing line 40 / silo rtm-000 has revert of both. land either one or both, and please double check with silo-diff they are good to go of course + test. I've also filed bug #1403906 about it including the IRC discussions as description.
[14:49] <Mirv> I can peek back before going to sleep in 3-4h or so.
[14:50] <bfiller> Mirv: thank you
[14:50] <jibel> Mirv, thanks
[14:54] <jibel> Mirv, before you leave who can rebuild an image?
[14:54] <Mirv> jibel: I don't know, I think that was when we talked slangasek should be pinged if we don't know any better. for me it has always been just og_ra who handles it.
[14:54] <jibel> Mirv, ack
[15:23] <cjwatson> jibel: in general: intersection of ~ubuntu-cdimage and ~canonical
[15:24] <jibel> cjwatson, intersection of ~ubuntu-cdimage and ~canonical and ! on holidays :)
[15:24] <cjwatson> well yes
[15:24] <cjwatson> gonna be "nobody" pretty soon :P
[15:25] <cjwatson> I can do it for about the next two hours
[15:25] <jibel> om26er, ^ we need silo 000
[15:26] <om26er> jibel, I am in the process of installing it
[15:44] <jibel> brendand, reverting also fixes the problem with cropping in the gallery
[15:44] <brendand> jibel, reverting thumbnailer?
[15:45] <jibel> brendand, yes
[15:45] <brendand> jibel, that must have been the issue - the only time it worked for me was when i used a photo from interwebz
[15:51] <jibel> om26er, I checked camera, gallery, mediaplayer, photo and video scopes. checked that thumbnails are correctly generated, that apps don't crash on launch or switching between photos, and that editing features of the gallery work fine.
[15:55] <om26er> jibel, I can't crash it either
[15:56] <jibel> om26er, k, I marked it pass for upstream
[15:57] <jibel> om26er, do it for QA when you think it's good
[15:57] <slangasek> jibel, Mirv: fwiw I told sil2100 that I'm reachable by SMS if images need respun
[15:57]  * om26er resets multiples times just to be sure
[15:58] <jibel> slangasek, thanks, we'll need an image in less than an hour when silo 000 is verified and in the archive.
[15:59] <slangasek> jibel: ok; just ping me here or by phone when you're ready for the build
[15:59] <cjwatson> I'll still be here in an hour and am not yet on holiday
[15:59] <cjwatson> FWIW
[15:59] <slangasek> or cjwatson, since as he said he's around for the next hour
[15:59] <slangasek> right
[15:59] <slangasek> jibel: ^^ so just give it to cjwatson, and I'll go find my pillow again ;)
[16:00] <cjwatson> it's down the back of the sofa no wait
[16:00] <jibel> slangasek, heh, enjoy your pillow :)
[16:06] <sil2100> I'm back home now and waiting for my system to boot
[16:07] <sil2100> What component will be reverted? Gallery or something else?
[16:08] <sil2100> i.e. how much retesting will be needed on the new image?
[16:08] <jibel> sil2100, thumbnailer and qtubuntu-camera
[16:08] <jibel> sil2100, it's in silo 0
[16:08] <jibel> sil2100, they also broke cropping in the gallery app
[16:09] <om26er> jibel, sil2100 approved.
[16:09] <sil2100> oh, hm, so it was the landing that Ricardo was meddling with versions
[16:09] <sil2100> Ok, I'm on my PC now
[16:10] <sil2100> Let me publish
[16:11] <sil2100> jibel, om26er: ok, everyone sure I should publish 000?
[16:11] <jibel> sil2100, why wouldn't we?
[16:12] <om26er> if the revert diff is exact then yes ;)
[16:12] <sil2100> ...published
[16:12] <sil2100> qtubuntu-camera in the end is an revert that reverts another revert
[16:13] <jibel> sil2100, yeah, they should really try harder to land small fixes rather than this big syncs from vivid
[16:14] <sil2100> I think landing syncs that pull in more than one version should be automatically considered risky as well
[16:17] <sil2100> Ok, packages should migrate any minute
[16:18] <sil2100> jibel: will this mean we need to re-do the whole regression suite? Or will you only re-test the delta for those? (so anything with thumbnails and camera)
[16:18] <jibel> sil2100, anything with camera, thumbnails and which uses exif metadata
[16:21]  * sil2100 watches rmadison
[16:24] <sil2100> jibel: remember that LP is always a bit fast with migration info, so even if the queuebot says it migrated then there's still a few moments that we need to wait for it to be 100% true
[16:24] <jibel> sil2100, I'm checking with rmadison
[16:24] <sil2100> So let's wait for rmadison to properly register it
[16:30] <sil2100> Ok, qtubuntu-camera is in, now just thumbnailer is left
[16:35] <sil2100> jibel: ok, it seems that both packages migrated now, rmadison is happy, update_output as well
[16:36] <sil2100> cjwatson: hey! Can we ask you for a new ubuntu-rtm image? :)
[16:36] <cjwatson> sil2100: running
[16:36] <sil2100> cjwatson: thank you!
[16:36] <cjwatson> np
[16:36] <jibel> sil2100, cjwatson thanks
[16:37] <sil2100> jibel: so we should have a new image in ~1.5h - is the rest of regression tests finished?
[16:37] <sil2100> jibel: will you only have to re run the delta now?
[16:37] <jibel> sil2100, sanity tests + delta
[16:38] <sil2100> Fingers once again crossed that this revert won't cause any regressions
[16:40] <imgbot> [16:40] <dobey> cihelp: if the autopilot-testrunner-otto-vivid job is running tests with phablet-test-run, is the lxc the tests are being run in, creating a mir surface somehow and running adbd in the lxc?
[16:42] <dobey> tail: '/var/lib/lxc//vivid-amd64-20141218-1841/run/delta//home/ubuntu/.xsession-errors' has become accessible
[16:42] <dobey> hmm, i guess that's not mir
[16:42] <fginther> dobey, autopilot-testrunner-otto-vivid uses autopilot directly to run the tests. And it's not doing anything with mir, it essentially uses the vivid desktop ISO which would be unity7
[16:42] <dobey> fginther: oh ok
[16:45] <dobey> fginther: thanks. i'm trying to understand what's different there, versus running the autopilot tests via autopkgtest with adt-run under qemu (which is how the ubuntu autopkgtests jobs in jenkins run the autopkgtests)
[16:45] <dobey> because the autoplit tests seem to be very unstable for unity-scope-click at least
[16:46] <dobey> and of course it doesn't help that qemu seems to be getting SIGTERMed randomly for me locally
[16:47] <fginther> dobey, I've never had good luck with qemu, it's very unreliable IMHO
[16:48] <fginther> dobey, or at the very least, there are some things that just can't be done there (threads being one of them I think)
[16:48] <dobey> fginther: well, i think i've got the tests equally unreliable in both the autopilot-testrunner-otto-vivid job, and in my autopkgtests branch running under qemu now (save for the qemu being killed bit)
[16:50] <dobey> though, creating the user session or starting Xvfb sometimes fails for no reason in the qemu case too. but when the tests actually run, they seem to fail in the same way for me in both places, now, which is at least good
[16:50] <fginther> dobey, otto has it's own problems... It was built to quickly fill a need and did well, but we've discovered numerous things that just don't work well under lxc
[16:50] <dobey> but there's no way we can land my branch :(
[16:50] <dobey> fginther: yeah, lots of things don't work well there i'm sure
[16:51] <fginther> dobey, we've had to disable otto testing for some projects in CI simply because that environment doesn't work anymore
[16:51] <fginther> dobey, for the most projects, the phone is still the better test environment (Just not sure that applies in your case)
[16:53] <dobey> fginther: well, my task was to get autopilot tests running in autopkgtests for unity-scope-click
[16:53] <dobey> the problem is we can't actually run things in autopkgtests that aren't reliable and passing, because they will block things landing in archive, if they break
[16:54] <cjwatson> fginther: threads are unreliable under qemu-user-static; I've never heard of them being unreliable under full-system emulation
[16:54] <cjwatson> fginther: if they were then all virtualised PPAs would be basically entirely screwed
[16:54] <dobey> and our tests have been unreliable in the otto job as well for various reasons
[16:56] <dobey> but right now in this branch, i seem to have the tests themselves in the same state of unreliability in both places
[16:56] <dobey> which is both a good sign and a bad sign :)
[16:57] <dobey> unfortunately, i don't know how to improve them further at this point, or why qemu is being killed :-/
[16:58] <fginther> cjwatson, thanks for the clarification
[17:02] <cjwatson> I thought qemu was being killed because the autopkgtest nodes are overcommitted
[17:02] <cjwatson> IIRC anyway
[17:03] <davmor2> sil2100, jibel: meeting?
[17:06] <fginther> the plan is transition as much as possible to nova VMs, non x86 is still a bit of a question mark though
[17:07] <dobey> cjwatson: i don't know about that on the launchpad side. i'm running locally. i don't think the node being overcommitted is a problem for running one test suite locally
[17:07] <dobey> it's not like it's using all 8 of my cores or anything
[17:07] <cjwatson> dobey: (Launchpad doesn't run autopkgtests)
[17:07] <cjwatson> Indeed, though, I don't know what that would be
[17:07] <cjwatson> nova VMs> still qemu under the hood surely
[17:08] <davmor2> jibel: sil2100: we gave up on the meeting
[17:08] <dobey> well, s/launchpad/jenkins/ but not relevant to local running qemu
[17:08] <cjwatson> nova is making some progress on other arches (we need it for LP), so that's probably the right direction
[17:19] <dobey> oh well
[18:00] <imgbot> [18:00] <jibel> sil2100, 184 is ready, we restart the sanity tests and the delta
[18:00] <imgbot> [18:25] <iahmad> imgbot, help
[18:25] <imgbot> I am the firendly system-image watchbot !
[18:25] <imgbot> I know the following commands:
[18:25] <imgbot> help, stop, status, map, stunt
[18:25] <imgbot> for questions please mail<EMAIL_ADDRESS>[18:25] <iahmad> imgbot, status
[18:28] <iahmad> imgbot status
[18:30] <ogra_> iahmad, status needs an image number
[18:30] <ogra_> imgbot, status 180
[18:30] <imgbot> Status: succeeded, Started: 2014-12-16 03:02:06 UTC, Finished: 2014-12-16 03:50:48 UTC
[18:30] <imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/14095
[18:30] <imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/180.changes
[18:30] <ogra_> imgbot map 180
[18:30] <ogra_> imgbot,  map 180
[18:30] <ogra_> grr
[18:30] <ogra_> imgbot, map 180
[18:30] <imgbot> krillin rtm version: 180 maps to mako version: 151
[18:30] <imgbot> krillin rtm version: 180 maps to generic_x86 version: 145
[18:31] <iahmad> imgbot status 184
[18:31] <iahmad> ogra_, thanks
[18:31] <iahmad> imgbot,  status 184
[18:31] <ogra_> (i need to improve the pattern matching, needs the exact command (with comma and only one space)
[18:31] <iahmad> imgbot, status 184
[18:31] <imgbot> Status: succeeded, Started: 2014-12-18 16:36:36 UTC, Finished: 2014-12-18 17:27:28 UTC
[18:31] <imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/14358
[18:31] <imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/184.changes
[18:32] <ogra_> if you want vivid results just append vivid ...
[18:32] <ogra_> imgbot, map 57
[18:32] <ogra_> err
[18:32] <imgbot> krillin rtm version: 57 maps to mako version: 136
[18:32] <imgbot> krillin rtm version: 57 maps to generic_x86 version: 130
[18:32] <ogra_> imgbot, map 57 vivid
[18:32] <imgbot> mako ubuntu version: 57 maps to krillin version: 64
[18:32] <imgbot> mako ubuntu version: 57 maps to generic_x86 version: 58
[18:32] <ogra_> imgbot, status 58 vivid
[18:32] <imgbot> Status: succeeded, Started: 2014-12-18 02:02:06 UTC, Finished: 2014-12-18 02:59:01 UTC
[18:32] <imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/14289
[18:32] <imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/58.changes
[18:37] <oSoMoN> trainguards: can I have a silo for line 42, please?
[18:38] <robru> oSoMoN: vivid 6
[18:38] <oSoMoN> robru, thanks man!
[18:39] <robru> oSoMoN: you're welcome!
[18:58] <john-mcaleely> imgbot status 5
[18:58] <davmor2> john-mcaleely: you forgot the comma
[18:58] <john-mcaleely> imgbot, stunt
[18:58]  * imgbot rolls on its back and purrs
[18:58] <john-mcaleely> imgbot, status 5
[18:58] <imgbot> Error: There does not seem to be any build with the number 5
[18:58] <john-mcaleely> davmor2, :-)
[18:58] <john-mcaleely> imgbot, status 10
[18:58] <imgbot> Error: There does not seem to be any build with the number 10
[18:59] <john-mcaleely> :-)
[18:59] <john-mcaleely> imgbot, map 183
[18:59] <davmor2> john-mcaleely: I'm assuming it only points to -proposed too
[18:59] <imgbot> krillin rtm version: 183 maps to mako version: 153
[18:59] <imgbot> krillin rtm version: 183 maps to generic_x86 version: 147
[18:59] <john-mcaleely> davmor2, I guess so
[19:00] <john-mcaleely> cool though
[19:17] <robru> boiko: https://ci-train.ubuntu.com/job/prepare-silo/3556/console need MP, not branch
[19:18] <boiko> robru: oups, let me fix that
[19:20] <boiko> robru: fixed, sorry for that
[19:21] <robru> boiko: no problem, vivid 12
[19:36]  * Mirv back to check situation
[19:37] <Mirv> it seems the revert was done
[19:37] <Mirv> oh, and image too!
[19:38] <Mirv> thanks jibel sil2100 robru whoever involved in getting that publishing of my silo done and let's hope the image is now PERFECT! :)
[19:38] <jibel> Mirv, right revert of qtubuntu-camera + thumbnail even if the thumbnailer only was responsible for the crashes
[19:38] <robru> Mirv: don't thank me. I guess sil2100 and cjwatson handled that while I slept
[19:38] <jibel> Mirv, we are testing 184
[19:38] <Mirv> jibel: the qtubuntu-camera update was scary, so getting that back to more tested version sounds sane
[19:45] <Mirv> sil2100: qtubuntu-camera had a weird landing that sounded like revert but was really not. both of these reverts were practically speaking just "simple" reverts from the previous landings, but both had manual uploads and weird changelogs as part of the landing a few days ago
[19:48] <Mirv> sil2100: so this http://is.gd/jkvo7Z was really what landed the last time - a combination of actually a vivid sync and manual upload done to the landing PPA..
[19:49] <Mirv> sil2100: as seen from the publishing history https://launchpad.net/ubuntu-rtm/+source/qtubuntu-camera/+publishinghistory
[19:49] <dobey> anyone in here familiar with qemu and adt-run?
[19:53] <Mirv> I wish I was, I didn't get my setup working
[19:59]  * Mirv sleep, good luck
[20:25] <jibel> sil2100, bfiller, Mirv testing of 184 is almost done, we are waiting for the results of the battery drain test. No blockers found so far. I'll do a review of the bugs tomorrow morning and I think it's all good for this milestone.
[20:38] <bfiller> jibel: thanks
[20:40] <oSoMoN> trainguards: can silo 6 be published, please?
[21:10] <oSoMoN> thanks!
[21:17] <sil2100> jibel: great news then, thanks!
[21:18] <sil2100> jibel: excellent work, I think promoting tomorrow sounds feasible


[04:01] <desrt> hey
[04:01] <desrt> seeing some weird issues with ubiquity on the 08-20 daily
[04:01] <desrt> at first the X server came up with a totally black screen (on boot)
[04:02] <desrt> and i have Xorg.log for displays 0 and 1 (which seems odd)
[04:02] <desrt> killing X and restarting ubiquity (via /etc/init.d/ubiquity) gets me an X server with a wallpaper but not much else
[04:03] <desrt> and looking at ps it seems that this makes sense -- the 'wallpaper' program is running (as well as a11y stuff, dconf, dbus, etc) but no installer
[04:06] <desrt> manually invoking DISPLAY=:0 sudo ubiquity gets me the installer
[04:06] <desrt> but it seems that i shouldn't have to do this... :)
[04:09] <TheMuso> desrt: Yeah the a11y stuff is from prior to GTK3 using atk-bridge. It was brought up to facilitate the easy use of orca during install. That code needs removing... I might actually take care of that now.
[04:15] <desrt> TheMuso: is that the explanation for why the installer is not started?
[04:24] <desrt> well.. i managed to get it installed
[04:24] <desrt> i'll be around if anyone wants me to try to reproduce the problem
[04:25] <TheMuso> desrt: No its not, but you mentioned it so I thought I'd clarrify.
[04:29] <desrt> i considered it a good thing that a11y was running
[04:29] <desrt> it meant that there were _some_ signs of life :)
[04:40] <TheMuso> heh ok.
[17:53] <xnox> Now that there is no desktop on the livecd's in quantal in virtual machines (since unity-2d is removed) I propose we default to ubiquity debconf interface
[17:54] <xnox> ... or on second thought I will use an old daily / alpha to continue development work.
[18:51] <njin> cjwatson, today's quantal amd64,  running oem modality, is possible to choose to encrypt disk during the installation, is this a new antitheft ?
[19:04] <xnox> njin: this is LUKS full disk encryption
[19:04] <xnox> njin: it's available in 'normal' user mode as well.
[19:05] <xnox> njin: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-ubiquity-lvm-luks
[19:22] <njin> xnox, ok, but is not clear to me what mean during an oem installation, but as is decided so, will accept. again a question, in the end-user setup step is ubiquity-dm running or ubiquity (nothing starts, only background, so I want to know if it is again the ubiquity-dm bug or a new one). thanks
[19:23] <xnox> njin: do you have the screenshot which is confusing for you?
[19:24] <xnox> njin: note, if  you are in a VM and do not have 3D accelaration, you will not get desktop at all.
[19:26] <njin> xnox, i've run it in real hardware and in virtualbox, but same behavior, everythings good (in real hardware) till the end of ship to end user, reboot, then nothing
[19:27] <xnox> njin: what hardware? intel graphics?
[19:27] <xnox> njin: or nvidia?
[19:27] <xnox> njin: did you tick install proprietary drivers in the installer?
[19:28] <njin> in real hardware nvidia with only nouveau but starting from the live sessio from the splash screen because ubiquity-dm bug
[19:37] <infinity> njin: First boot in oem-config mode will still be ubiquity-dm, so it's probably the same bug.
[19:38] <njin> infinity, I'm talking about the first boot of the end user, where it setup the system
[19:38] <infinity> njin: Yes, so am I.
[19:38] <njin> ok, thanks


[11:06] <rvr> ogra_: Still no wifi on the Raspi 3
[11:30] <ogra_> rvr, yes, likely a kernel issue
[11:44] <mup> Bug #1637981 opened: failed snap refresh removes security profiles <Snappy:New> <https://launchpad.net/bugs/1637981>
[11:47] <mup> PR snapd#2231 opened: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <https://github.com/snapcore/snapd/pull/2231>
[11:53] <bzoltan> elopio: I would need some help with the snapcraft tests
[11:54] <zyga> Pharaoh_Atem: hey, how are you?
[11:54] <Son_Goku> zyga: yo
[11:56] <Son_Goku> zyga: I just pushed a commit to (theoretically) grant homedir access: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/0e2c1fb73a520b348254142347bb7f4b8445b63a
[12:07] <kalikiana_> Hrm
[12:07] <kalikiana_> Cannot allocate qemu:ubuntu-16.10-64: cannot launch qemu qemu:ubuntu-16.10-64: exec: "kvm": executable file not found in $PATH
[12:08] <kalikiana_> Trying to run 'spread -v qemu' as suggested by HACKING.md
[12:08] <kalikiana_> Tried to add a symlink in /snap but even that's not helping
[12:08] <kalikiana_> It goes without saying I've installed what was asked for, and I do have a working kvm command on the host
[12:15] <kalikiana_> Also: I do have the image in ~/snap/spread/23/.spread/qemu because I realized that's where spread is looking for it, even though it's not clearly stated and spread's readme actually talks about ~/.spread/qemu
[12:16] <sitter> We're having some problems with dbus confinement. KDE has lots of apps that (semi-implicitly; as in: devs might not even know dbus is involved) access the session bus and claim a service name on it. For all intents and purposes these are like dbus service-daemons with a well defined service name of the form org.kde.$appname.
[12:16] <sitter> This is how we implement unique application behavior (e.g. user starts foo, foo claims org.kde.foo, when foo is invoked again by whatever means it will first check if org.kde.foo is claimed and if so send a raiseWindow to that instead of starting a second instance of foo).
[12:16] <sitter> This also can be the case with multiple apps registering org.kde.$appname-* where * can be $pid or $pid-$randomstuff.
[12:16] <sitter> I am wondering if it would be possible to have a common interface which allows a snap to connect to the session bus and interact with a specific service name there (i.e. its own).
[12:16] <sitter> I did see a bus-name property in snapd's app validator, that doesn't seem to be supported as per snapcraft's validator though.
[12:16] <sitter> zyga, popey ^
[12:16] <ogra_> grrr, reconnect ...
[12:17] <ogra_> kalikiana_, all necessary interfaces connected ?
[12:17] <kalikiana_> ogra_: I have no idea. There's 0 information on what I might need :-)
[12:17] <sitter> popey: also, I just filed reservation requests for kcalc, kruler and ktuberling when you find a minute to approve them :)
[12:17] <ogra_> kalikiana_, snap interfaces ... check if there are unconnected ones for the spread snap
[12:18] <kalikiana_> ogra_: it has home,network,network-bind
[12:19] <ogra_> well, was worth a try :)
[12:19] <kalikiana_> it's also running in --devmode as per instructions, but I can't see that here
[12:19] <ogra_> snap list should show that
[12:19] <kalikiana_> Ah, it does indeed
[12:20] <popey> sitter: will do
[12:20] <kalikiana_> ogra_: So you have the same ones? I feel I might be missing some kind of magic OR the snap itself has the wrong version - although it doesn't say anything about needing an edge channel version
[12:20] <Son_Goku> zyga, I wish snapd failed gracefully when it can't write files in protected places rather than hanging
[12:21] <ogra_> kalikiana_, i never used spread before ...
[12:21] <kalikiana_> Aha, okay.
[12:22] <ogra_> seems edge and stable have th same revision though
[12:22] <kalikiana_> I'd have to say I'm suspicious how it should be able to access "kvm" on my host, it'd be the first snap I see that can run anything from /usr/bin
[12:22] <kalikiana_> And there's no such script inside it
[12:23] <ogra_> well, --devmode should allow it to do anything it likes
[12:23] <ogra_> (but spam your syslog like crazy)
[12:23] <Son_Goku> zyga, does snapd use FUSE for something?
[12:23] <kalikiana_> Except accessing /usr/bin - even if it was in its PATH, it will see the core's /usr/bin
[12:24] <ogra_> hmm, indeed
[12:24] <kalikiana_> I don't see how that could ever work
[12:24] <kalikiana_> So... there must be some other trick to it
[12:24] <bzoltan> ogra_:  do you know who could be around this time who has some understanding of the snapcraft tests?
[12:24] <ogra_> snap-confine does some bind mount magic here ... though i'm nmot sure how much of /usr/bin
[12:25] <ogra_> bzoltan, fgimenez perhaps
[12:25] <bzoltan> ogra_:  thanks
[12:25] <bzoltan> fgimenez:  I would need some help with the snapcraft tests. How to run individual tests?
[12:26] <kalikiana_> ogra_: I can see via snap run --shell that it's got a bunch of stuff but none of the qemu or kvm bits
[12:26] <kalikiana_> (awesome command to have for debugging, sadly I'm still poking in the dark)
[12:29] <ogra_> kalikiana_, i fear you need to wait for niemeyer
[12:31] <niemeyer> kalikiana_: If it is in --devmode, it should see the host filesystem in /var/lib/snapd/hostfs
[12:31] <niemeyer> kalikiana_: We're also working on a feature that will enable you to see that in / soon
[12:36] <kalikiana_> Aha that's good to know
[12:37] <kalikiana_> niemeyer: Would you know anything about using spread to run snapd tests? I can't get past 'Cannot allocate qemu:ubuntu-16.04-64: cannot launch qemu qemu:ubuntu-16.04-64: exec: "kvm": executable file not found in $PATH'
[12:41] <fgimenez> hey bzoltan, i don't know too much about snapcraft testing, probably elopio can explain accurately, but according to https://github.com/snapcore/snapcraft/blob/master/runtests.sh#L70 you can execute individual integration tests passing the name of the file, same goes for unit tests, hope this helps
[12:41] <bzoltan> fgimenez: thanks. i will check that out
[12:41] <mup> PR snapd#2232 opened: tests: add test for incorrect security files generation on undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2232>
[12:45] <Son_Goku> niemeyer, does snapd have its own SSL cert loader?
[12:46] <niemeyer> Son_Goku: Hi
[12:46] <niemeyer> Son_Goku: What's the context?
[12:46] <zyga> Son_Goku: no, but it can control fuse through an interface somehow AFAIK
[12:46] <zyga> ogra_: what was the question about snap-confine?
[12:47] <Son_Goku> niemeyer, I'm writing the snapd selinux policy, and I got to the point where now it throws errors instead of hanging on enforcing...
[12:47] <Son_Goku> this is what I get: https://paste.fedoraproject.org/466809/47791801/
[12:49] <kalikiana_> fgimenez: Any idea on the 'kvm: executable not found' error? I'm out of ideas on how to run the spread tests
[12:52] <mup> PR snapd#2231 closed: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2231>
[12:58] <Son_Goku> niemeyer, why does snapd download the /tmp instead of downloading to /var/lib/snapd/snaps?
[13:03] <niemeyer> Son_Goku: Hmm.. the former issue looks like snapd cannot open the local certificate on the host system
[13:03] <Son_Goku> yeah, I fixed that
[13:04] <niemeyer> Son_Goku: Ah, ok.. after you asked the previous question (SSL cert loader), or was that a different question?
[13:04] <Son_Goku> after I asked the SSL question, I pretty much guessed it does its own HTTPS stuff
[13:04] <Son_Goku> so I added rules for it: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/3b7e03c4428f8908e1d21a22cea9a78b522694fe
[13:05] <Son_Goku> niemeyer, now I want to know why snapd downloads snaps to /tmp instead of /var/lib/snapd/snaps
[13:05] <Son_Goku> it doesn't make much sense to me
[13:05] <niemeyer> Son_Goku: Yeah, it can talk to remote systems using TLS so it needs a proper db of certs indeed
[13:05] <niemeyer> Son_Goku: Yeah, we've fixed that already
[13:06] <niemeyer> Son_Goku: 2.17 will have that corrected
[13:06] <Son_Goku> ah, so it doesn't do this anymore, good
[13:06] <Son_Goku> because I wasn't sure how to handle the context transition case when files get moved around
[13:06] <Son_Goku> from /tmp to /var/lib/snapd
[13:07] <niemeyer> Son_Goku: Yeah, 2.17 will write .partial files on a download directory and then rename them in place, which is much nicer for multiple reasons
[13:07] <Son_Goku> yep
[13:07] <Son_Goku> and it neatly solves an selinux problem I wasn't sure how to solve
[13:08] <Son_Goku> and the practical problem of systems having ramdisk /tmp run out of space
[13:08] <Son_Goku> niemeyer, the download directory is in /var/lib/snapd?
[13:09] <Son_Goku> as long as it's in there, I don't need to do anything to handle it
[13:14] <ogra_> zyga, already answered (/var/lib/snapd/hostfs)
[13:23] <zyga> ogra_: ah, thanks
[13:23] <Son_Goku> zyga, why does snapd need to read the dbus config dir?
[13:27] <lorenzo__> Hello
[13:28] <lorenzo__> Quick question, does anyone know how to install snapd on CentOS?
[13:34] <zyga> Son_Goku: it needs to read it to remove stale files it creates
[13:34] <zyga> Son_Goku: in all those cases it manages a subset of "snap-*"
[13:34] <niemeyer> Son_Goku: Yes, it will be in there for sure
[13:35] <Son_Goku> zyga: so it needs read/write access there
[13:35] <niemeyer> Son_Goku: Not sure if under .../partial or .../snaps yet.. we're likely touching this today/tomorrow for making it nicer
[13:35] <Son_Goku> niemeyer, as long as it's in /var/lib/snapd, I don't care :)
[13:36] <niemeyer> Son_Goku: So you're good :)
[13:36] <Son_Goku> niemeyer, I'd probably suggest /partial or /snaps/partial
[13:36] <Son_Goku> the latter is more intuitive
[13:36] <niemeyer> Son_Goku: That's what we have in master, but it creates some non-obvious consequences
[13:36] <Son_Goku> oh?
[13:36] <niemeyer> Son_Goku: e.g. on "snap download foo", we want foo.snap.partial in $CWD
[13:37] <niemeyer> Son_Goku: We're still figuring the details, but we want to make sure the same code path works nicely both on snapd and on snap download, etc
[13:38] <Son_Goku> snap download doesn't use snapd?
[13:40] <niemeyer> Son_Goku: It does, but not for everything.. we don't want plain users fiddling with content that goes into sensitive directories
[13:41] <niemeyer> Son_Goku: IOW, anyone in the system can do "snap download".. only root can put content into snapd/...
[13:47] <Son_Goku> niemeyer, what does snapd depend on fusedevice for?
[14:20] <mhall119> sitter: I've approved your app name registrations
[14:21] <bzoltan> elopio: ping
[14:23] <elopio> bzoltan: pong
[14:24] <bzoltan> elopio: yo man :) I need some help with snapcraft plugin/tests
[14:24] <elopio> bzoltan: sure. Unit or integration?
[14:24] <bzoltan> elopio:  whatever needed. I guess unit
[14:25] <elopio> bzoltan: well, if you are adding a plugin you need the two types :) I first need to take a look at the ones from Pharaoh_Atem, and then I have all the time for you. How can I help you?
[14:25] <elopio> pitti: ping. Any idea about "No annotated tags can describe 'cdefe0fc2dda29b4290eb4a054dbe607b61da21b'."<EMAIL_ADDRESS>[14:26] <bzoltan> elopio:  I made a simple plugin what zips up the staging space after build. This is for development use. For example when we build the qt-ubuntu content interface we will need a tar.gz with the  .h and .so files. Like -dev package in deb world.
[14:27] <bzoltan> elopio:  the plugin is ready (super simple) and I want to make nice tests for it... I am not familiar with the test framework of the snapcraft.
[14:30] <elopio> bzoltan: we have unit tests for full line coverage, and integration tests where you call the snapcraft command in a real snapcraft.yaml
[14:31] <kalikiana_> balloons: Did you have a chance to check out the lxd-client interface?
[14:31] <elopio> bzoltan: your plugin sounds really similar to dump, so you can probably start copying the initial tests from snapcraft/tests/test_plugin_dump.py
[14:31] <elopio> and integration_tests/test_dump_plugin.py
[14:32] <elopio> I see a naming inconsistency there :/
[14:33] <ogra_> mvo, !
[14:33] <mvo> hey ogra_
[14:34] <ogra_> mvo, do you mind if we kill the arch: all pi3 gadget in the store (seems there was an old one that used to be arch: all, not armhf ... people can actually download it on x86 machines)
[14:34] <mvo> ogra_: sure, lets do that
[14:34] <bzoltan> elopio:  the problem is that the dump is done before the build... my plugin needs a built snapcraft project.
[14:34]  * ogra_ goes ahead
[14:34] <mvo> ogra_: aynthing new on the pi3 wifi issue? if not I will try to get pitti to have a look at it too
[14:35] <ogra_> mvo, i suspect there is also a relared kernel issue here ... sadly ppisati fried his pi3 during the sprint :(
[14:35] <ogra_> (and now he is on vacation)
[14:36] <ogra_> mvo, but having pitti aboard might help (if there is no bank holiday for him today (reformationstag))
[14:36] <ogra_> bah ... so i cant just uncheck all channels for pi3 rev2
[14:37] <elopio> bzoltan: I thought your plugin would be dump + zip. Do you need it as a post-step for all the existing plugins?
[14:37] <ogra_> but at least i can unpublish
[14:37] <ogra_> sigh
[14:37] <bzoltan> elopio: it is just a zip
[14:38] <ogra_> and the store automatically went back to publish rev1 instead
[14:38]  * ogra_ unpublishes that too
[14:38] <ogra_> ok, thats better, only rev6 now ... and armhf only
[14:41] <bzoltan> elopio:  it will look like this: http://pastebin.ubuntu.com/23407202/ and the project produces the qt-ubuntu.snap and the qt-ubuntu-api.tar.gz files
[14:43] <elopio> bzoltan: to me, that sounds like a new step in the lifecycle, probably handled with a new attribute in the yaml. But Sergio and kyrofa are the ones that decide about that kind of design.
[14:44] <elopio> Sergio is in a sprint. You can find him in rocket or telegram.
[14:46] <bzoltan> elopio:  well... i am doing the plugin and will offer to upstream :) But my problem is that I do not understand the unit test structure
[14:46] <sitter> mhall119: thanks
[14:50] <elopio> bzoltan: put a simplified version of your paste into integration_tests/snaps, and in integration_tests/test_development_plugin.py write a test that calls snapcraft and checks that it creates the zip file.
[14:52] <bzoltan> elopio: ok, that is the integration test part. That sounds doable. What about the unit test?
[14:55] <elopio> bzoltan: on the unit tests, it really depends on the code you write. I imagine a test like this one: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_plugin_dump.py#L42 but called something like test_build_creates_zip
[14:56] <bzoltan> elopio:  Okey, thanks. I will pull together something and we'll see if it does the job.
[14:56] <bzoltan> elopio:  my problem with the  unit test is that I do not know how to create a stage space from a template yaml
[14:57] <bzoltan> elopio:  the integration test you suggest will do the trick...
[14:57] <elopio> but I'm confused about your code. I'm not really sure how you would enforce that there are contentes in stage, or how to make sure that it's the last to run.
[14:57] <elopio> bzoltan: but if you want, push the code to a PR, and comment on it that's work in progress. It will make the discussion easier.
[14:58] <elopio> bzoltan: in unit tests, you don't always need a yaml. You just mkdir stage, and put some files in there.
[15:00] <bzoltan> elopio: ahh... mkdir and file creation... cool
[15:01] <balloons> kalikiana_, is the interface ready?
[15:01] <balloons> kalikiana_, I can definitely try it out if it's ready
[15:03] <kalikiana_> balloons: It's in the branch, https://github.com/snapcore/snapd/pull/2225
[15:03] <mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
[15:05] <balloons> kalikiana_, awesome. I've got release work to do today and tomorrow, but I will definitely try it this week. If you want to vet it out yourself, feel free to try adding it to juju and building a snap: https://github.com/juju/juju/blob/staging/snapcraft.yaml
[15:06] <sitter> mhall119: something that puzzles me about the store. I upload something -> it gets auto rejected on account of being crap quality -> I upload a new revision with fix -> new revision is now queued for automatic checks saying "Revision waiting for review of a previous upload." and that previous upload is in status "Manual review pending". is that intentional?
[15:06] <sitter> because that is fairly screwing with my productivity just now :/
[15:26] <mhall119> nessita: ^^ can you answer that? It sounds like a bug in the workflow to me
[16:26] <kalikiana_> stgraber, jdstrand: wrt lxd-client being all-powerful, is that a shortcoming in apparmor/seccomp? or the lxd API being unrestricted?
[16:27] <kalikiana_> Wondering where to take that discussion, presuming the current unconfined state is temporary
[17:21] <stgraber> kalikiana_: nothing to do with apparmor/seccomp limitations, it's just that LXD has legitimate use for all of that access
[17:21] <stgraber> kalikiana_: the LXD API lets you define containers that have raw access to disks, PCI devices, USB devices, specific kernel modules and intefrace, ...
[17:21] <stgraber> and things like Juju actually use that to pass through access to openvswitch for OpenStack or even /dev/mem in some cases
[17:24] <stgraber> kalikiana_: we may at some point add the concept of tenants to LXD and could then in theory have security profiles or something to restrict what those tenants can pass to containers and then build a snapd interface on top of that to allow for auto-connect to lxd. But that's not on our roadmap for this cycle nor even for the next one, so right now, the LXD API is very much privileged and can't be given to
[17:24] <stgraber> any random user/snap.
[17:27] <Sweet5hark> "cannot bind mount nvidia driver /usr/lib/nvidia-340 -> /tmp/snap.rootfs_OKbiYH/var/lib/snapd/lib/gl. errmsg: No such file or directory" <- anyone has an idea what that is?
[17:29] <ogra_> Sweet5hark, some leftover nvidia driver cruft ?
[17:30] <ogra_> does /usr/lib/nvidia-340 exist and does it have the GL libs inside ?
[17:30] <Sweet5hark> ogra_: yes and yes
[17:31] <ogra_> any other nvidia-* dirs in /usr/lib ?
[17:33] <Sweet5hark> FWIW, /tmp/snap.rootfs_OKbiYH/ exists, is owned by root:bjoern and is empty -- the paths below it do not exist.
[17:35] <Sweet5hark> Also for context: I tried to install libreoffice from edge, aborted the dl, which FUBARed snap state. Thus I ran https://raw.githubusercontent.com/zyga/devtools/master/reset-state -- retried, it installed fine, but doesnt start because of the above ....
[17:36] <Sweet5hark> ogra_: There is nvidia-340 and nvidia-340-prime in /usr/lib
[17:36] <ogra_> the message comes from inside the core snap, i dont think you can see anything when looking from the outside
[17:37] <ogra_> probably it chokes on -prime ...
[17:37] <ogra_> zyga, ^^ any known remaining bugs with snap-confine and nvidia ?
[17:59] <kyrofa> Isn't the core snap supposed to handle GL access?
[18:12] <kyrofa> ogra_, do you know anything about that? I have an app dying because it can't access libGL.so.1
[18:12] <ogra_> nop
[18:12] <ogra_> e
[18:13] <ogra_> it isnt so much the core snap, rather snap-confine that bind mounts the libGL stuff from the host into the core snap and provides the gl interface
[18:15] <cwayne> kyrofa: ISTR having to  have something like this in my wrapper script: export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/$ARCH/dri
[18:18] <kyrofa> Huh... I just ran `snap run --shell` and it's not in there anywhere, so it must not be bind-mounted in. zyga, any ideas?
[18:25] <kyrofa> Oh my. I completely missed that opengl was an interface now
[18:25] <kyrofa> I'm sure that's it
[18:29] <kyrofa> Nope, nevermind. Changes nothing
[18:32] <kyrofa> Looking at the interface, looks like something should be contained within /var/lib/snapd/lib/gl, but it's not
[18:45] <ogra_> kyrofa, well, snap-confine should mount your hosts GL libs there
[18:45] <kyrofa> ogra_, yeah, that doesn't seem to be working
[18:46] <ogra_> (on demand i think)
[20:07] <kyrofa> Man it's quiet around here
[20:46] <femme> Did a snappy security audit happen (yet)?
[20:50] <femme> We're considering using snaps for tor as distros tend to not update after a while and so I just joined to get caught up on the snap ongoings and discussions and maybe someone would like to help
[20:54] <qengho> femme: Hi hi. I can't answer about an audit, but I would like to be a bridge between Tor and snappy communities. I think it's a great fit. I made the tor-middle-relay snap, and am on the OFTC channel too.
[20:55] <qengho> femme: I would love to contribute what I know to make snaps a side-effect of building the official builds for deb packages.
[20:56] <femme> qengho: great, I didn't know there was a middle relay snap
[20:58]  * qengho moves to that dev channel.
[21:16] <kyrofa> femme, I'll point you to the security team -> tyhicks?
[21:19] <kyrofa> femme, qengho please let me know if you run into difficulties from a packaging perspective
[21:19] <tyhicks> femme: hey - there's not been an independent security audit of snappy as a whole but the Ubuntu security team is active in the development of snappy
[21:21] <tyhicks> femme: for example, we review all that changes that go into the snap launcher (snap-confine) and we also review and/or author the changes to the interfaces (security policy)
[21:27] <zyga> tyhicks, femme: suse security team did review snappy security
[21:28] <zyga> and found a few issues that were since fixed
[21:28] <zyga> you can count that as indepdentend security review i think
[21:28] <tyhicks> oh, good point
[21:28] <zyga> kyrofa: it's been a long day :)
[21:28] <tyhicks> I had forgotten about that
[21:28] <kyrofa> zyga, yeah I bet! How's the sprint?
[21:28] <zyga> kyrofa: hey, so wha'ts about nvidia that you have issues with?
[21:29] <zyga> kyrofa: and which distro are we talking about as each one is different
[21:29] <kyrofa> zyga, I've got an app that wants libGL.so.1, and it's not finding it. Neither am I, using snap run --shell
[21:29] <zyga> kyrofa: sprint is tense :) we're working on the release again
[21:29] <kyrofa> zyga, classic
[21:29] <zyga> libGL.so.1 you say?
[21:29] <kyrofa> Yep
[21:30] <femme> tyhicks: thanks for the response, so I'm having a glance and the parts wiki page jumps out at me. It seems more complicated than it has to be when a (signed) repo would have been better.
[21:30] <femme> zyga: great to hear
[21:30] <zyga> kyrofa: do you see it in /usr/lib/nvidia-/ anywhere?
[21:30] <femme> would love to read a writeup if there was one
[21:30] <zyga> femme: signed repo of what?
[21:31] <femme> https://wiki.ubuntu.com/snapcraft/parts
[21:31] <kyrofa> zyga, indeed, both /usr/lib/nvidia-340/libGL.so.1 and /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
[21:31] <zyga> femme: you do relise the whole idea is that that we don't review actual code, just the sandbox
[21:31] <kyrofa> femme, those are just build-time parts for users to utilize when building snaps. It has nothing to do with snapd itself
[21:31] <zyga> kyrofa: the latter is not something we handle, the former, hmm, is this a hybrid system?
[21:31] <femme> I know
[21:32] <zyga> kyrofa: can you do snap-confine --version by any chance (or just tell me the version from dpkg)
[21:32] <kyrofa> zyga, yes, it's one of those monstrosities. Never do it!
[21:32] <zyga> s/relise/realise/
[21:32] <kyrofa> zyga, 1.0.43-0ubuntu1~16.04.1
[21:32] <zyga> kyrofa: is it a hybrid system?
[21:32] <kyrofa> zyga, yes
[21:33] <zyga> kyrofa: if it is, then what you may be observing is that a) we have a bug (maybe) b) nvidia driver is not really loaded yet
[21:33] <kyrofa> zyga, indeed, the nvidia driver isn't loaded
[21:33] <zyga> kyrofa: please collect as much data as you can and report a new bug
[21:33] <kyrofa> zyga, well, I'm using the intel side
[21:33] <zyga> kyrofa: for hybrid systmes I bet we need more smarts
[21:33] <kyrofa> zyga, but I shouldn't HAVE to be using nvidia...
[21:33] <femme> I realize it's not directly snapd related but it's a single point of failure for those using the parts, which seems to be recommended
[21:34] <kyrofa> femme, no need to use them, they just help sometimes when snapping things
[21:34] <zyga> kyrofa: I agree, I just need data to know how to fix it
[21:34] <kyrofa> zyga, sounds good, happy to help
[21:34] <zyga> femme: snaps should be okay to use even if you use none of the shared parts
[21:35] <kyrofa> Even the shared parts get confined the same if used
[21:35] <zyga> kyrofa: look at /sys/module/nvidia/version
[21:35] <zyga> kyrofa: do you have it?
[21:35] <zyga> kyrofa: and if so, what's in it?
[21:35] <kyrofa> zyga, it seems I don't have it when using intel
[21:36] <zyga> kyrofa: right, then what I think is happening is that the app expects a particular GL.so but the snap is not providing it
[21:36] <zyga> kyrofa: typically snaps seem to bundle all FOSS userspace side drivers
[21:36] <nacc> femme: i think what you're referring to is that if the shared parts were to change/break in some way, there's not really a way to fix it in your current build; but that only matters for building a new version, the existing snaps don't depend on the parts any longer (the shared parts were integrated during the build, aiui)
[21:36] <zyga> kyrofa: maybe that's just missing
[21:36] <femme> With the whole Startcom thing and whoever else has access to SSL CA certs I wouldn't want to wait until something goes wrong to say "you could have not used it"
[21:36] <kyrofa> nacc, you understand correctly
[21:37] <nacc> kyrofa: thanks
[21:37] <zyga> kyrofa: I need to sleep, please report a new bug and let's work together on solving this
[21:37] <femme> nacc: yes, which makes the developer a target
[21:37] <zyga> kyrofa: I'm so sleepy now, sorry
[21:37] <kyrofa> zyga, yeah, go away, I'm sorry I pinged you, I forgot about the sprint ;)
[21:37] <zyga> kyrofa: no worries, it' the (wink wink) last one this year
[21:37] <kyrofa> zyga, ha!
[21:38] <zyga> (conditions apply, your mileage may vary)
[21:38] <nacc> femme: depends on how you mean that -- the developer is expressing a dependency by relying on the external code (which is really what the shared part is); so yes, the developer is a 'target' if that external code breaks
[21:38] <kyrofa> femme, that's an argument against any dependencies
[21:39] <femme> It's an argument against not checking the integrity of dependencies, aka relying on https as your only line of defense
[21:40] <nacc> femme: so are you arguing purely against how the shared parts are currently distributed?
[21:40] <femme> if the developer's connection is mitm'ed by someone who can issue valid wiki.ubuntu.com ssl certs they can put whatever they want on that parts page
[21:41] <femme> and it gets built into the binary and distributed to everyone
[21:42] <kyrofa> femme, if an attacker has that power I feel like that's the least of the dev's worries
[21:42] <zyga> femme: isn't that true in general
[21:42] <zyga> femme: your ubuntu.iso was fetched over https
[21:43] <zyga> femme: and we can do better but at some point you have to have some way to bootstrap trust
[21:43] <femme> kyrofa: that's a step above what the ubuntu security team said when I told them years ago that they should have ssl certs on ubuntu.com but they closed the ticket as WONTFIX
[21:43] <zyga> femme: remember that when this happes, the most you can exploit is what that single snap could do
[21:43] <femme> but hey, they turned around on that too, only took them a few years.
[21:44] <kyrofa> femme, even if we could integrity check the contents of the wiki, it's just a dict pointing elsewhere. The code comes from github etc
[21:45] <nacc> iirc, the ubuntu isos are actually served over http; the md5sums are served over https. We just had this argument a few days ago on #ubuntu. :)
[21:45] <kyrofa> femme, if an attacker can impersonate https-protected websites they can just impersonate that one
[21:46] <femme> kyrofa: that would've been the next point, there should be some signing mechanism implemented
[21:46] <nacc> if all https sites are compromised (potentially), it does feel like there is a large issue at hand
[21:46] <kyrofa> nacc, exactly
[21:46] <femme> if all https sites are compromised I'm fine because I'm using tor
[21:46] <kyrofa> femme, how do you check a svn repo? Or git?
[21:55] <femme> A few measures I would take are: 1) enable and test key pinning with wiki.ubuntu.com's key in snapd 2) have every snap developer keep a key with which they sign the tar of the sources and include the md5 of it in the yaml
[21:55] <femme> s/md5/sha256/
[21:55] <kyrofa> femme, they aren't necessarily tarballs, that's my point
[21:56] <femme> kyrofa: they can be tarred on the developers machine
[21:57] <kyrofa> femme, how are they verified then if the build recipe itself pulls from git?
[21:59] <femme> https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Securing_Updates
[22:01] <femme> kyrofa: they are made by ubuntu they can just be signed by a key already trusted
[22:02] <kyrofa> What are made by ubuntu? How is the signature of the tarball verified if the tarball isn't downloaded?
[22:03] <femme> if the tarball isn't downloaded what is the dev planning on building the sources with?
[22:03] <kyrofa> femme, git cloned sources. Or svn. Or hg. Or any of the myriad of source types supported by snapcraft
[22:03] <femme> kyrofa: which can be tarred?
[22:04] <femme> the tarring bit is just a technicality
[22:04] <kyrofa> femme, so your recommendation is to get rid of all source types except tarballs?
[22:04] <femme> no
[22:06] <femme> I'm kinda done with this conversation for now
[22:06] <femme> I'll gladly write a report if someone pays me ;)
[22:07] <mup> PR snapd#2233 opened: docs: update the name of the command for the cross-build <Created by elopio> <https://github.com/snapcore/snapd/pull/2233>
[22:08] <kyrofa> Alright, have a nice day femme
[22:09] <femme> (speaking of keys already trusted by ubuntu, it's kinda scary with two keys from 2004 still there)
[22:36] <femme> kyrofa: the idea is that the sha256 of every source is included (and if it's not a single file, tar them and sha256) and that it's signed by the developers private key (the public part which is also included)
[22:38] <femme> It could be implemented for parts which was my main example but I don't know much about the key infrastructure of ubuntu and if it would make sense to suggest for example pinning the key for parts in snapd alongside the pinning of the ssl cert of the URL, because if both keys are kept at the same place it doesn't matter but otherwise it is an improvement
[22:40] <femme> And it would use trust-on-first-use on a per snap basis for other keys


[02:12] <MarkDude> http://twit.tv/show/know-how/5
[02:12] <darthrobot> Title: [Know How... 5 | TWiT.TV]
[02:12] <MarkDude> Podcast- help an old pc with Linux


[00:00] <SamB_MacG5> whoops, I reported a bug against bzr when I meant to report it against qbzr ...
[00:00]  * SamB_MacG5 fixes
[00:12] <gumnos> Is there an easy way to just get bzr to spit out the hash of the current checkout?
[00:13] <gumnos> (something like "git rev-parse HEAD")
[00:21] <SamB_MacG5> gumnos: have you checked "bzr help hidden-commands"?
[00:22] <gumnos> I just stumbled across it and am fighting with "version-info" which seems to be my best bet.  However it's spewing lots of unneeded detail
[00:22] <SamB_MacG5> gumnos: look at the help for that command, I think you'll find what you want ;-)
[00:23] <gumnos> I keep poking at it, but can't get it to just give the ID.  Lots of other stuff keeps coming along for the ride.  Trying bzr version-info --template='{revision_id}'
[00:23] <gumnos> ah...I'm missing "--custom"
[00:24] <SamB_MacG5> yeah, I have no clue why --template doesn't imply --custom ...
[00:25] <gumnos> okay, it's working now with version-info --custom --template '{revision_id}'
[00:25] <gumnos> thanks for prodding me along until I got it
[00:26] <SamB_MacG5> you're welcome
[00:27]  * SamB_MacG5 wonders if the FSF Europe admits requires Fellowship applicants to be european
[23:54]  * SamB_MacG5 notices that all these ".html" hyperlinks in the documentation work *really* well in the PDF output ...


[13:07] <chdslv> Touchpad doesn't work in Medion laptop
[14:07] <bobafett> hello guys
[17:47] <penguin_linux> hello, I have a very old laptop, about 11 years old, runs on Intel Celeron M Single core 1.5 Ghz cpu and 2 gb ram and has 40 gbs hdd. Would Lubuntu be suitable for it?
[17:47] <wxl> yep
[17:48] <penguin_linux> 16.04.2?
[17:48] <penguin_linux> the laptop is a 32 bit machine.
[17:49] <wxl> any version
[17:49] <wxl> as long as you get 32 bit
[17:49] <penguin_linux> how about Lxle? how is that different from Lubuntu?
[17:49] <wxl> it's lubuntu + a bunch of extra stuff = relatively bloated
[17:49] <wxl> it's also not supported by lubuntu, so you'd need to ask them
[17:50] <penguin_linux> so, you wouldn't recommend it?
[17:50] <wxl> i don't see the reason, personally, although it obviously exists because some people like it
[17:52] <penguin_linux> ok
[17:53] <penguin_linux> btw, how is Antix Linux compared to Lubuntu?
[17:53] <wxl> no clue
[17:53] <penguin_linux> I just checked it in Distrowatch.com.
[17:54] <wxl> distrowatch is full of little tiny distros that have ultimately singular puproses with really limited support
[17:54] <penguin_linux> ok
[17:55] <wxl> if you want something that works, that has a team of people surrounding it, that have lots of support, you probably want a major distro
[17:55] <penguin_linux> Debian with lxde?
[17:55] <wxl> that would certainly work
[17:55] <penguin_linux> since my laptop runs on single core Intel Celeron M cpu, I am a little apprehensive.
[17:55] <wxl> i wouldn't be
[17:56] <penguin_linux> what advantage does Lubuntu have over Debian Lxde?
[17:56] <wxl> the same advantages ubuntu has over debian
[17:57] <penguin_linux> please elaborate. I am a newbie.
[17:57] <wxl> also lubuntu is a whole system. EVERYTHING was chosen to be lightweight, not just the desktop environment
[17:57] <penguin_linux> ok
[17:57] <wxl> ubuntu was originally started to make debian easy and approachable
[17:57] <penguin_linux> ok
[17:57] <wxl> it's based on debian but often has additional changes/improvements relative to it
[17:57] <wxl> it's based on debian unstable so it tends to have newer packages
[17:58] <penguin_linux> newer packages? great.
[17:59] <wxl> also, i think the community's great
[17:59] <wxl> and that means the support is great too
[17:59] <penguin_linux> ok
[18:00] <wxl> at least in the cloud world, ubuntu is the #1 distro used
[18:00] <penguin_linux> would Lubuntu be fine on a laptop with single core cpu?
[18:00] <wxl> that said, there's a loooooooooooot of support out there
[18:00] <wxl> yes
[18:00] <wxl> you can read the system requirements on the wiki. they're pretty darn low.
[18:00] <penguin_linux> I am just thinking which version I should choose.
[18:01] <wxl> you should probably get an LTS version
[18:01] <wxl> it will eb more stable
[18:01] <penguin_linux> 17.10. How about that.
[18:01] <wxl> getting the most recent will make the most sense
[18:01] <wxl> !lts
[18:01] <penguin_linux> which one is the laterst LTS version?
[18:02] <wxl> ^^
[18:02] <penguin_linux> ok. sorry.
[18:03] <penguin_linux> when will the final release of 17.10 going to happen?
[18:03] <penguin_linux> is alpha safe to use?
[18:03] <wxl> generally, yes
[18:03] <penguin_linux> I mean could it have some serious bugs?
[18:03] <wxl> unless there's sweeping chanegs
[18:03] <wxl> none of which i know right now
[18:03] <wxl> but
[18:03] <penguin_linux> ok
[18:04] <wxl> you could always wait too
[18:04] <wxl> i'll explain the version number scheme which will explain when they come out
[18:04] <penguin_linux> ok
[18:04] <wxl> the first number is the year
[18:04] <wxl> the second number is the month XD
[18:04] <penguin_linux> ok
[18:04] <wxl> so you could wait until october
[18:05] <wxl> or just install xenial. you'll get offered an upgrade to the next lts when it's available
[18:05] <penguin_linux> can I upgrade smoothly from 17.04 to 17.10?
[18:06] <wxl> yeah but the problem with doing a non-LTS version is that you'll be stuck in the upgrade cycle for each new version rather than sticking to the more stable LTS
[18:06] <penguin_linux> or will I have to reinstall?
[18:06] <wxl> there's ways around that, but if you want the "easy" route, just get 16.04 and upgrade to 17.10
[18:07] <penguin_linux> oh. is that possible?
[18:07] <wxl> yep
[18:07] <penguin_linux> then ok
[18:07] <wxl> that's what i was suggesting above
[18:07] <penguin_linux> I will download LTS only then.
[18:07] <penguin_linux> thanks for the info.
[18:08] <wxl> np
[18:09] <penguin_linux> bye. have a good day.
[18:09] <wxl> u2
[19:47] <Jbmorris289> Hello
[19:47] <wxl> what's up?
[19:50] <Jbmorris289> Nothing much..
[19:50] <wxl> need some help or just hanging out?
[19:51] <Jbmorris289> A little bit of both, more of the first thing actually
[19:52] <wxl> in that case, carry on but #lubuntu-offtopic is mostly for the idle chatter :)
[19:52] <Jbmorris289> I have a computer with Lubuntu... Let's just say that my parents use Skype, and I cannot install it
[19:52] <wxl> why not?
[19:53] <Jbmorris289> I'm afraid that my computer isn't a 64 bit and I found some 32 bit version, however there is a package that can't be satisfied
[19:54] <Jbmorris289> Some webkit or qt
[19:54] <wxl> are you sure the computer isn't 64 bit capable?
[19:54] <Jbmorris289> Also, okay.. (for your other message)
[19:54] <Jbmorris289> Ehh.
[19:55] <Jbmorris289> Out only has 2 gigs of ram or so
[19:56] <wxl> if this returns something, you can reinstall using your old home with a new version in 64 bit:
[19:56] <wxl> grep ' lw ' /proc/cpuinfo
[19:57] <Jbmorris289> I'm not on the computer right now but I will do that once I get on it
[19:57] <Jbmorris289> Too bad I can't ssh
[19:57] <Jbmorris289> Because of my rout
[19:57] <Jbmorris289> Router*
[19:58] <Jbmorris289> No, it's my ISP modem
[20:12] <wxl> Jbmorris289: actually this will require less interpretation:
[20:13] <wxl> grep ' lm ' /proc/cpuinfo >/dev/null && echo 64 capable || echo 32 only
[20:15] <Jbmorris289> Okay sorry for taking a while
[20:16] <Jbmorris289> One sec
[20:16] <wxl> no prob, i'm working so
[20:17] <Jbmorris289> It gives me 64 capable
[20:17] <wxl> yay
[20:18] <wxl> so you can reinstall a 64 bit
[20:18] <wxl> it will give an option to use your old home
[20:18] <Jbmorris289> Oh okay
[20:18] <wxl> if you're worried about having everything installed, you can get a package list with dpkg -l
[20:18] <Jbmorris289> What is erased
[20:18] <Jbmorris289> ?
[20:18] <wxl> you might want to grab /etc too in case you made any system wide changes
[20:18] <wxl> essentially everything else
[20:19] <Jbmorris289> Oh ok
[20:39] <Jbmorris289> Well thanks... I might install it
[22:19] <Sxmsung> I'm looking to view the contents of an efl file. Specifically a file named abl.elf from an android img. I'm on a linux box running lubuntu. Any help is appreciated.
[23:22] <iBiscuit> Hello
[23:22] <iBiscuit> I'm a n00b to Linux but I've been using it for about 4 years now


[16:13] <busybox_> I am trying to create a rootfs following the instructions at  -  https://wiki.ubuntu.com/ARM/RootfsFromScratch
[16:15] <busybox_>  sudo ./rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 3G --seed ubuntu-desktop
[16:15] <busybox_> command finishines with saying - I: Running on a i686 machine
[16:15] <busybox_> I: Creating temporary qemu Image to be used as rootfs
[16:15] <busybox_> I: Mounting temporary Image
[16:16] <busybox_> where does it mount the temporary image? Should not it create a tarball? I can't find that
[16:16] <busybox_> I am trying this for the first time
[16:37] <busybox_> lets put it another way
[16:37] <busybox_> how can I build a root fs on ubuntu 13.04 to use with qemu-arm
[16:37] <busybox_> ?
[19:46] <Valduare> hi guys got question, I got an mk802iiis device running ubuntu but the kernel apparently is configured to look in 3.0.8 dir in /lib/modules and the rootfs has 3.0.36 folder
[19:46] <Valduare> can I do a symblink and reboot and all will work?
[19:46] <Valduare> trying to get wifi found
[19:47] <infinity> Erm, if the kernel is 3.0.8 and the modules you have are 3.0.36, you absolutely can't just symlink, no.
[19:47] <infinity> You need modules that match your running kernel.
[19:47] <infinity> Or a kernel that matches that rootfs.
[19:47] <infinity> Pick one. :P
[19:47] <Valduare> hmm
[19:47] <Valduare> off to google heh
[19:48] <infinity> Or, off to the people who provided you the kernel and rootfs.
[19:48] <infinity> Since it wasn't us.
[19:50] <Valduare> aye thats what I'm trying to do
[19:50] <Valduare> any idea if ubuntu is planning to support all winner soc?
[19:50] <Valduare> there's a lot of these little arm devices flooding the market
[19:51] <ogra_> probably once they start supporting devicetree
[19:52] <ogra_> (which they refuse to ... and which keeps them from getting their stuff into linux proper)
[19:54] <infinity> ogra_: Not true, there's (finally) allwinner support landing upstream in a sane multiplatform way.
[19:54] <ogra_> oh !
[19:54] <infinity> Though, mostly too late for trusty's kernel, I believe.
[19:55] <ogra_> so they finally saw the light ?
[19:55] <ogra_> or is that a community effort
[19:55] <infinity> I think the light might have been forced on them, but yes.
[19:55] <ogra_> heh, cool
[19:55] <infinity> I've not gone patch hunting myself, but I heard promising things at Connect.
[19:55] <ogra_> i saw the deiscussions on the debian-arm ML ...
[19:56] <Valduare> interesting
[19:56] <ogra_> but there it didnt look like they would get to some final conclusion
[19:56] <ogra_> and discussions with luke kenneth lehighton involved get a bit stressful over time
[19:57] <infinity> Oh, he's a twit. :P
[19:57] <ogra_> definitely
[19:57] <Valduare> I'm in my hotel room right now got my mk device plugged into the hotel room tv trying to get its wifi up and running lol
[20:32] <Valduare> hmm what do I type to get dmesg to run in the terminal 15 seconds after I hit enter
[20:33] <infinity> Valduare: sleep 15 && dmesg
[20:33] <Valduare> ty


[14:46] <pmatulis> ballot, you better file a bug for that. juju got confused due to the presence of bundle.yaml?
[14:47] <ballot> pmatulis: yes
[14:47] <ballot> an empty one
[14:47] <ballot> I already filled https://bugs.launchpad.net/juju/+bug/1930191 about it
[14:51] <pmatulis> right on


[00:23] <jack198282882> hey i have a hp KU-0316  keyboard how do i sync the led indicator lights on the keyboard with my laptop
[00:30] <jack198282882> .
[00:32] <Unit193> jack198282882: You were told <removed> basketball: so you either left before someone answered or no one knows. alternately, you can use askubuntu or the ubuntu forum
[00:33] <Unit193> !forums | jack198282882
[00:33] <Unit193> !askubuntu | jack198282882
[00:33] <jack198282882> Unit193,  http://askubuntu.com/questions/430110/two-keyboards-in-ubuntu-13-10
[00:34] <ianorlin> do you have another computer?
[00:34] <basktball> yes
[00:34] <Unit193> basktball: Good, now wait for an answer there.
[00:35] <ianorlin> I have an idea boot other comp plug in usb keyboard hit capslock
[00:35] <ianorlin> unplug put back in this comp
[01:09] <phillw> hmmm.... is this ground-hog day? I'm sure we did all of this yesterday?
[01:11] <phillw> Unit193: you'll be far faster than me... can you pull up the ubuntulog link ?
[01:11] <Unit193> DOesn't matter, he doesn't read.
[12:16] <xsaidx> heyy guys
[12:17] <xsaidx> i ve an azerty keyboard and thats cool for writin i cant dind out how to type some symbols like star
[12:17] <xsaidx> i ve tried many combo  but still the same
[14:58] <Mikaela> Is there some reason why opening links in LXTerminal requires Ctrl to be pressed.
[14:58] <Mikaela> ?
[15:33] <holstein> Mikaela: ive just always done it that way.. thought it was something about escaping the terminal
[15:34] <Mikaela> I haven't done so anywhere else and other terminals seem to work just by clicking.
[15:38] <holstein> !proaudio
[15:39] <holstein> control click here in terminator
[15:40] <holstein> same in lxterminal
[15:41] <holstein> same in guake
[15:42] <holstein> dont have any others installed here to test with, but, to answer the question, id say the reason is a default preference..
[17:29] <wxl> Mikaela: not the same in urxvt
[17:31] <Mikaela> Weird. I have always clicked links in Terminator and urxvt and they have opened.
[17:34] <wxl> Mikaela: that's what i mean
[17:35] <wxl> Mikaela: honestly i prefer urxvt and i guess i'm not alone because urxvt is used as the example to create .desktop files in the lubuntu dox ;)
[17:35] <Mikaela> Oh
[17:35] <wxl> Mikaela: of course, all things being open source i'm sure you could rewrite lxterminal to your liking if you wanted ;)
[17:36]  * Mikaela is missing abilities to do so :(
[17:36] <wxl> Mikaela: so just use urxvt. especially if you're familiar with it already, more better.
[17:37] <Mikaela> I just haven't created the .desktop file yet.
[17:37] <wxl> it's in the dox. let me know if you need a link
[17:39] <Mikaela> I think that I found it. Thanks :)
[19:40] <skjones> what's the latest with lubuntu changing to QT desktop?  is lubuntu still going to be associated with ubuntu?
[19:41] <wxl> skjones: don't fret. you'll never notice the difference. lubuntu is still a part of ubuntu.
[19:41] <holstein> associated? lubuntu *is* ubuntu
[19:41] <holstein> qt is in the ubuntu repos.. upstream lxde would come in...
[19:42] <skjones> so lubuntu is still going to be around as a main flavor of ubuntu as it's been for years?
[19:43] <wxl> skjones: yep
[19:43] <skjones> reason i asked, saw an article lately that read "Lightweight LXDE-based spin Lubuntu is also hoping to jump aboard — but with it planning to switch to the Qt-based desktop in the near future it’s not yet clear what sort of commitment, if any, will ultimately be offered."
[19:44] <skjones> wasn't sure what that meant?
[19:46] <holstein> skjones: lubuntu *is* ubuntu
[19:47] <holstein> skjones: it doesnt need to "jump aboard".. if you have a link you are welcome to let them know what *is* going  on there
[19:47] <holstein> skjones: from what i read, lxde is planning to switch
[19:48] <holstein> skjones: regardless, as i said, and you can research and confirm, qt is in the ubuntu repos.. so, going qt doesnt mean you are not with ubuntu, or have to leave the ubuntu core
[19:48] <skjones> excuse my ignorance, but is QT better than what lubuntu is using now (which is what?)
[19:49] <holstein> skjones: "better" is always a matter of opinion and use case
[19:49] <holstein> !qt
[19:49] <holstein> !gtk
[19:50] <holstein> AFAIK, unity will be going qt as well
[19:50] <skjones> when is unity going qt?  14.04?
[19:51] <holstein> skjones: definitely *not* 14.04
[19:51] <holstein> skjones: and, im not sure.. and you shouldnt say i said it was
[19:51] <holstein> skjones: i didnt.. i said "AFAIK" which = "as far as i know", but i just heard that on a news show
[19:52] <holstein> skjones: i dont personally follow unity development.. could have been talking about the touch UI for all i know
[19:52] <skjones> thanks guys for the info
[19:52] <holstein> skjones: the fact is, lubuntu is ubuntu, and part of ubuntu, and using the same official sources.. going qt or gtk doesnt mean you cant be an ubuntu core.. lubuntu uses lxde, which, as i read is doing the qt switch upstream
[20:19] <skjones> i notice lubuntu offers a Mac version for download, do the other ubuntu distros do this as well?
[20:20] <wxl> skjones: most do, but they're all community supported. none are "official"
[20:28] <phillw> skjones: +Mac64 is offered by most distros. for ppc machines... it is pretty much only lubuntu now.
[20:31] <phillw> skjones: https://wiki.ubuntu.com/Lubuntu/Testing/14.04 has the details of our head of dev.
[20:32] <phillw> s/of/from/
[21:49] <dvora> hi
[21:50] <Unit193> Howdy.
[21:51] <dvora> i have a simple question- i have lubuntu. what is the easiest way to upgrade to the newst version?
[21:59] <phillw> dvora: which version of lubuntu have you got?
[22:00] <dvora> phillw: i think 12.10
[22:02] <phillw> dvora: my best advice would be to make a seperate /home area (https://help.ubuntu.com/community/Partitioning/Home/Moving ) and then simply install 14.04 in a couple of weeks. It is pretty darn stable now if you do not use fire fox etc!
[22:03] <phillw> doing a clean install with your /home area protected will keep all your data and give you shiny new install :)
[22:03] <Unit193> IIRC 12.10 was a special case that could upgrade to saucy then trusty.
[22:03] <phillw> going 12.10 --> 13.04 --> 13.10 --> 14.04
[22:04] <phillw> Unit193: lubuntu has never had an upgrade route other than release to release. As Julien himself said, one less thing for us to test :)
[22:05] <Unit193> 13.04 is EOL before 13.10 with 12.10 being supported, thus exception.
[22:06] <phillw> Unit193:  there is still no way to upgrade 12.10 to 14.04 via lubuntu... We only support 13.10 --> 14.04
[22:06] <phillw> do not forget that until this release lubuntu has not followed lts etc.
[22:06] <Unit193> Sure, and thus you can do 12.10 -> 13.10 -> 14.04...
[22:06] <Unit193> I know..
[22:07] <phillw> Unit193: so, the better advice to someone is https://help.ubuntu.com/community/Partitioning/Home/Moving and a clean install.
[22:07] <Unit193> Do what you like.
[22:08] <ianorlin> won't doing multiple updgrades like that take a while with lots of bandwidth for each one
[22:08] <phillw> Unit193: btw... it is 12.10 --> 12.04 --> 13.04 --> 13.10 --> 14.04.....
[22:08] <Unit193> phillw: Again, no.
[22:09] <phillw> remove the 12.04
[22:09] <Unit193> phillw: You can't downgrade either, and it's not a upgrade path (to downgrade before upgrade?)
[22:09] <Unit193> phillw: And 13.04.
[22:09] <Unit193> !raring
[22:09] <Unit193> YOu don't upgrade to EOL.
[22:09] <phillw> btw... it is 12.10  --> 13.04 --> 13.10 --> 14.04.
[22:09] <Unit193> Anyway, I'm done, I've said what I've said.
[22:10] <phillw> and you are suggesting that doing four upgrades is actually easier / quicker than a seperate /home and a clean install?
[22:11] <phillw> indeed... as I think that advice is tosh.
[22:16] <dvora> phillw: do i need to install the iso? or can i do it from terminal? because "sudo do-release-upgrade" says "No new release found"
[22:17] <dvora> i don't want to wait, i just backed-up everything.. :P
[22:20] <phillw> dvora: Unit193 will talk you through how to upgrade, he does not approve of my method and I know of no other method.
[22:20] <Unit193> 1. No, busy as I've said.  2. I've said how to, it's not that much different...............
[22:21] <phillw> Unit193: nope, you have not said
[22:21] <phillw> wiki page?