[10:03] <daftykins> good morning campers!
[13:00] <zxmpi> o/
[13:01] <daftykins> my my, island wide power dip a moment ago - every client UPS reported in
[13:03] <zxmpi> this winter has seen 2 powercuts so far. most ever in time i've been in dublin barring the strike of leccy workers
[13:04] <daftykins> :O
[13:08] <daftykins> had a few a year when i was a lad!
[13:11] <zxmpi> to be expected on an island i supose. house i grew up in was 2min walk from a hospital and on same circut so when power went out for rest of town we still had it
[13:11] <daftykins> ooh nice
[13:12] <daftykins> yeah we used to be run from the local oil/petrol/diesel maybe power station only, but there's the undersea link cable to France nowadays
[13:18] <zxmpi> yeah, ireland is looking to link up with france as uk power is less reliable these days
[13:19] <zxmpi> ireland is still of course anti nuke power
[13:26] <daftykins> not sure on my thoughts on that one, only seems to go wrong when greediness weighs in / regulatory fails
[13:29] <zxmpi> i remember the protests when ireland considered nuke power plant in 70s-80s. we just didn't trust government enough to put real lead in radiation shielding. still don't :-)
[13:32] <zxmpi> we have a tonne of untapped wind, solar, water, wave i'd like to see before we dabble with nuke. nuke has come on a long way but still bad when accidents happen
[13:32] <daftykins> wow that good eh? is it even that expensive o0
[13:32] <zxmpi> you know what the scrap value of lead is? it'd be gone in a month :-P
[13:35] <daftykins> not a clue!
[13:54] <zxmpi> that and our government likes going with lowest bidder on such things. it's why we're having power cuts right now.
[13:58] <daftykins> mmm that figures
[14:07] <zxmpi> i swear if russia were offering a free chernobyl style reactor to anyone who picked it up we'd find government wanting it
[14:09] <daftykins> can't think of a better documented design ;D
[14:12] <zxmpi> as long as you don't run safety tests on it, sure what could go wrong?
[14:22] <daftykins> we'll call 'em "unsafety" tests!
[14:23] <zxmpi> brilliant! that's the type of management we expect
[14:28] <daftykins> i've been known to drink Guinness, what more do i need to get a job in Irish gov? ;)
[14:30] <zxmpi> a dad in irish governemnt
[14:30] <zxmpi> really helps
[14:32] <daftykins> hmm, well my cat is my child!
[14:32] <daftykins> oh right that way around
[14:32] <daftykins> derp
[15:59] <zxmpi> yeah but cats are communists, well known that :-P


[08:21] <dholbach> good morning
[08:43] <dholbach> dpm, thanks for the review of https://code.launchpad.net/~dholbach/help-app/1434125/+merge/253526 - apart from the other comments, did it generally make sense from a I-don't-write-shell-scripts-every-day point of view?
[08:44] <dpm> dholbach, it makes sense to me from my I-try-not-to-touch-shell-scripts-with-a-stick point of view
[08:46] <dholbach> ok
[08:46] <dholbach> any shell experts who want to help out with the merge proposal above? ^
[08:46] <dholbach> it's not very long or complicated, but I would appreciate a review :)
[10:17] <faenil> any "Clock" developer in here?
[10:18] <faenil> opened clock app -> press on the + to open an alarm ---> UI gets stuck ---> clock app crashes after 30 secs
[10:18] <faenil> it worked on r150 last night, today I upgraded to r151, and it's broken
[10:27] <dholbach> dpm, nice work on lp:~dpm/help-app/metadata-fixes
[10:33] <popey> faenil: that's nik90
[10:33] <popey> faenil: can you file a bug?
[10:51] <faenil> popey: ok, let me grab some log
[10:58] <faenil> https://bugs.launchpad.net/ubuntu-clock-app/+bug/1434504
[11:01] <popey> thanks faenil
[11:05] <faenil> popey: np :)
[12:21] <dholbach> dpm, balloons: please re-propose your branches against the new lp:help-app
[12:21] <dholbach> https://code.launchpad.net/help-app/+activereviews
[12:21] <dholbach> we now have ~help-app-dev
[12:25] <nik90> zsombi, t1mp: Hi, can any of you check https://code.launchpad.net/~nik90/ubuntu-ui-toolkit/fix-slider-bubble-width/+merge/253620 when you are free to see if it is good to go?
[12:27] <dholbach> dpm, https://code.launchpad.net/~dholbach/help-app/1434125/+merge/253658
[12:35] <t1mp> nik90: sure, I'll check it in a few hours
[12:35] <nik90> faenil: bug confirmed. thanks for reporting it. (although I am having a tough time trying to figure out how to fix it)
[12:35] <nik90> t1mp: thnx
[13:04] <dholbach> dpm, not sure if you've seen it yet, but maybe you can merge https://code.launchpad.net/~dholbach/help-app/metadata-fixes.fixes/+merge/253646 into your branch too?
[13:10] <dpm> done, thanks dholbach!
[13:10] <dholbach> dpm, rock on
[13:24] <faenil> nik90: np
[13:35] <balloons> nik90, btw thanks for the feedback on the ci docs, and for pointing out the bugs you did
[13:40] <dholbach> dpm, balloons: https://code.launchpad.net/~dholbach/help-app/1434125/+merge/253658
[13:49] <balloons> dholbach, ack, I'll have a look in a bit
[13:50] <dholbach> thanks balloons
[14:02] <nik90> balloons: np, you're welcome :)
[14:03] <nik90> balloons: when you find time, could you approve https://code.launchpad.net/~nik90/ubuntu-clock-app/reenable-alarm-tests/+merge/253291 .. I am basically enabling a test on the device which was disabled before
[14:05] <dholbach> balloons, make sure you reload the page - mvo helped me a bit with the shell script, so I just pushed a new revision
[14:05] <balloons> nik90, nice! done
[14:05] <balloons> dholbach, refreshing
[14:05] <nik90> balloons: thnx
[14:16] <balloons> dholbach, bzr import --help bzr: ERROR: unknown command "import"
[14:17] <balloons> needs bzrtools eh?
[14:17] <dholbach> ah, yes
[14:17] <dholbach> let me add that to the list
[14:18] <dholbach> done
[14:44] <balloons> dholbach, outputdir_web=$(cd .. && make print-OUTPUTDIR_WEB | cut -d'=' -f2) fails for me in your script
[14:44] <dholbach> does the following work?
[14:44] <dholbach> make print-OUTPUTDIR_WEB
[14:44] <balloons> running standalone it's fine, but the cut fails when running inside the script
[14:44] <balloons> OUTPUTDIR_WEB=/home/nskaggs/projects/ubuntutouch/merges/1429896/build/web/wwwmake[1]: Leaving directory '/home/nskaggs/projects/ubuntutouch/merges/1429896'
[14:45] <dholbach> can you run "sh -x web-publish"
[14:45] <dholbach> ?
[14:45] <dholbach> and pastebin the output?
[14:45] <balloons> dholbach, sure so you can see it
[14:45] <dholbach> thanks
[14:49] <balloons> dholbach, here I think this shows it: http://paste.ubuntu.com/10635176/
[14:50] <dholbach> hah, no
[14:50] <dholbach> it fails because it runs the second time
[14:50] <dholbach> and there are no changes to commit/push
[14:50] <balloons> dholbach, look closely.. see what outputdir_web is set to?
[14:51] <balloons> See the bzr import error? bzr import make[1]: Entering directory '/home/nskaggs/projects/ubuntutouch/merges/1429896'
[14:51] <balloons> /home/nskaggs/projects/ubuntutouch/merges/1429896/build/web/wwwmake[1]: Leaving directory '/home/nskaggs/projects/ubuntutouch/merges/1429896'
[14:51] <balloons> bzr: ERROR: No such file: u"make[1]: Entering directory '/home/nskaggs/projects/ubuntutouch/merges/1429896'\n/home/nskaggs/projects/ubuntutouch/merges/1429896/build/web/wwwmake[1]: Leaving directory '/home/nskaggs/projects/ubuntutouch/merges/1429896'"
[14:51] <balloons> wow, sorry
[14:51] <dholbach> bizarre
[14:51] <dholbach> ok, looks like I won't merge the change today
[14:51] <dholbach> thanks for testing it
[14:51] <dholbach> I'll leave your pastebin in the comments
[14:52] <balloons> dholbach, yes it is bizarre. I was working on trying to fix your magic foo to grab the proper string for outputdir_web
[14:53] <balloons> better to not use '='
[14:55] <dholbach> what would you propose?
[14:59] <kunal21> hi dear developers.... I just want to know how to develop an app to read or write files on ubuntu phone using qml
[15:05] <balloons> dholbach, not sure just yet, I played with it a little but I'll have to step away for now
[15:05] <dholbach> ok
[15:09] <nik90> zsombi: hey, when you get time, can you push the multi-page alarm sample app to your junk branch? I am trying to debug the clock app crash due to the alarm manager and cannot seem to find the cause of it.
[15:10] <zsombi> nik90: ok, I will do that with teh alarm ID exposed
[15:10] <zsombi> nik90: btw, I was planning to add the app ID as well tothether with the same MR
[15:13] <nik90> zsombi: ok, I am not up to date with what exactly we planned on doing with that yet. But I will work on that when I get past this crasher and AP issues first.
[15:14] <zsombi> nik90: I thought that both would be encoded in a tag, and alarm ID would be an uuid
[15:14] <zsombi> nik90: a string
[15:15] <kunal21> hi dear developers.... I just want to know how to develop an app to read or write files on ubuntu phone using qml
[15:15] <nik90> ack.
[15:16] <nik90> zsombi: ok. and that would be the url which the i-dt will send the clock app which can then be used to open the alarm. ack.
[15:16] <nik90> kunal21: you can't do read/write files using just qml. You will need to implement a c++ plugin.
[15:16] <nik90> kunal21: what's your use caes?
[15:16] <nik90> s/caes/case
[15:18] <kunal21> hii thanks.....
[15:19] <kunal21> do i need to use c++ in my qml app.... to read write files on ubuntu phone??? isn't there any more way in javascript or in html5?
[15:20] <nik90> kunal21: Javascript doesn't have a native way of writing files..search google for yourself to confirm that.
[15:20] <kunal21> nik90: please tell me where can I find proper documentation for required C++ plugin..... ?? please help
[15:21] <nik90> kunal21: check out https://www.youtube.com/watch?v=WsW52Iq2aPQ which shows how to make a sample c++ plugin for your qml app.
[15:22] <kunal21> Yes, I know that about java script..... What about Corodova?? Please tell me....
[15:22] <nik90> kunal21: You will need to search the qt docs online to find the appropriate Qt c++ class to use..It should be QFile if I recall correctly
[15:22] <nik90> I dont know about Cordova.
[15:23] <popey> hey nik90 how are you doing?
[15:24] <nik90> popey: hey, its going good. Busy but trying my best to sort out issues in the clock app.
[15:24] <popey> yeah, saw the alarms bug come in.
[15:27] <nik90> the problem is that the alarm model is loaded at app start up and thereby it is causing crashes pretty much at any part of the clock app. The user doesn't even need to add an alarm to crash the clock app.. Opening and closing the settings page a couple of times is enough to cause it to crash.
[15:27] <nik90> no wonder I am hating on vivid atm :P
[15:28] <popey> hah
[17:06] <LangeOortjes> is there a reference implementation of the bottom edge, I tried the one from UCS but that gives warnings that Pages shouldn't be nested
[17:10] <nik90> LangeOortjes: nope. The one from UCS is the one that all the apps including clock, address book etc are using. Its pretty much the official one for now
[17:10] <AskUbuntu_> What type of developer can build this eLearning platform? | http://askubuntu.com/q/599214
[17:16] <LangeOortjes> nik90, alright, so I'll just ignore the warning then :)
[20:48] <t1mp> nik90: I left a tiny comment on https://code.launchpad.net/~nik90/ubuntu-ui-toolkit/fix-slider-bubble-width/+merge/253620
[20:48] <t1mp> nik90: it works well for me
[20:59] <nik90> t1mp: thnx for the review, sure I will add the example.
[22:57] <nik90> zsombi: hey I finally figured out what's causing the crash :) ... it seems the bottom edge title which shows "Next active alarm in 3h 28m" etc.. is receiving that info by calling the get() function just like in the edit alarm page. We fixed that in the edit alarm page but didnt so for the bottom edge one.
[22:58] <nik90> zsombi: I am still trying to figure out how to fix this issue though.
[22:58] <nik90> anyways I am done for the day now.


[03:37] <mup> PR snapcraft#2326 closed: plugins: remove implicit source <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2326>
[05:09] <mborzecki> morning
[05:29] <mup> PR core18#74 opened: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <https://github.com/snapcore/core18/pull/74>
[05:45] <mup> PR core18#74 closed: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/74>
[05:48] <mup> PR snapd#5910 closed: snapshotstate: restore to current revision <Snapshots 📸> <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5910>
[05:54] <mup> PR core18#75 opened: static: show snapd firstboot messages on /dev/console  <Created by mvo5> <https://github.com/snapcore/core18/pull/75>
[05:56] <mup> PR core18#75 closed: static: show snapd firstboot messages on /dev/console  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/75>
[06:23] <zyga> o/
[06:25] <mborzecki> zyga: hey
[06:28] <mvo> hey zyga and mborzecki
[06:29] <mup> PR core18#76 opened: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <https://github.com/snapcore/core18/pull/76>
[06:29] <zyga> :-)
[06:46] <mup> PR core18#76 closed: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/76>
[07:05] <mvo> uh, on the pi I get "backend.go:319: cannot create host snap-confine apparmor configuration: cannot s
[07:05] <mvo> ynchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/
[07:05] <mvo> snap-confine.snapd.1122.m8GcXdqQ5cDR~: no such file or directory" quite often
[07:05] <mvo> at firstboot seeding
[07:05]  * mvo wonders what is going on there
[07:05] <pstolowski> mornings
[07:05] <mvo> hey pstolowski
[07:15] <zyga> mvo: didn't we fix that?
[07:15] <zyga> mvo: is the pi using anything modern or is this the release image?
[07:15] <zyga> (release as in 16.04)
[07:16] <mvo> zyga: let me check, it should use master
[07:17] <mvo> zyga: rev is 2.35.4+git1480.gdb577fc
[07:17] <mvo> from 7h ago
[07:18] <zyga> hmm, then it looks real
[07:19] <mvo> I'm debugging a different issue right now, we look after this but it looks scary as it breaks first boot seeding
[07:19] <zyga> k
[07:20] <mvo> its a race most likely
[07:20] <mvo> does not happen all the time
[07:20] <mvo> and I think not at all on quick HW like amd64
[07:20] <mvo> plus it is (currently) mask by this other bug that console-conf runs too early
[07:31] <zyga> mvo: is https://github.com/snapcore/snapd/pull/5917 still something we want (AFAIK you want to branch master so back ports are not needed)
[07:31] <mup> PR #5917: cmd/snap: attempt to start the document portal if running with a sess… <Created by zyga> <https://github.com/snapcore/snapd/pull/5917>
[07:31] <mup> PR snapd#5927 closed: cmd/snap-update-ns: remove empty placeholders used for mounting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5927>
[07:32] <mvo> zyga: I think its something we want
[07:32] <zyga> k, just land it then
[07:32] <zyga> note, the master version landed already
[07:32] <mvo> zyga: I will branch again once 2.35.4 is in candidate
[07:32] <mvo> zyga: aha, ok
[07:32] <zyga> this is just a back port
[07:32] <mvo> ok
[07:35] <pedronis> mvo: I still have a small image.go PR to do (now that everything in snapd itself has landed), can be backported after the main branching tough
[07:36] <mvo> pedronis: ok, thank you
[07:48] <mvo> zyga: I think I have an idea about the bug, will go full force once I am finished with the current console-conf sync issue
[07:48] <zyga> let me know what you find
[07:55] <mup> PR snapd#5951 opened: spread-shellcheck: fix interleaved error messages, tweaks <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
[08:12] <mborzecki> anyone wishing to review #5947 and #5948 ? feel free to do one or both
[08:12] <mup> PR #5947: many: cleanup remaining parallel installs TODOs <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947>
[08:12] <mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
[08:12] <mborzecki> pstolowski: any of your hotplug PRs need attention?
[08:12] <mborzecki> pstolowski: i have #5860 open
[08:12] <mup> PR #5860: interfaces/hotplug: helpers and struct updates <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
[08:15] <zyga> mborzecki: I can do after noon
[08:15] <pstolowski> mborzecki: you can review that one, yes; i generally miss Gustavo's reviews on all of them. i'll have new PRs today I think, i'm going to split my code and propose complete feature in 2-3 pieces, so there will be new material to review. thanks for asking!
[08:15] <zyga> still fighting that test
[08:28] <mup> PR core18#77 opened: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <https://github.com/snapcore/core18/pull/77>
[08:42] <niemeyer> pstolowski: Sorry, haven't managed to get to the rest of them yesterday (did get to the key gen one).. will put the others at the top of my queue today
[08:43] <pstolowski> niemeyer: sure, thanks for the device key review, addressed your feedback and trying to land (travis is not cooperating, again)
[08:50] <mup> PR core18#77 closed: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/77>
[09:07] <mup> PR core-build#36 closed: initramfs: fix shellchecks on bionic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/36>
[09:21]  * zyga -> small break
[09:25]  * zyga is about to throw the towel on the overlayfs test
[09:29] <ogra> cjwatson, did the builders become stricter with the recent changes ? i just did manual re-builds of some of my snaps that never had probs building and all of a sudden they fail to release ... there are warnings about host libs being pulled in but i think they were there before and did not make the snap get stuck
[09:29] <cjwatson> ogra: no
[09:29] <ogra> weird
[09:29] <cjwatson> ogra: "failed to release" is from the store, not from the builders, anyway
[09:30] <ogra> yeah, but i dont even see the re-built snaps in the store ... like they never arrived
[09:30] <cjwatson> so this is either due to snapcraft or due to the review tools, probably; unlikely to be the builders
[09:31] <cjwatson> ogra: it's not fair to ask me to speculate on this without giving me a link
[09:32] <ogra> https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860
[09:32] <ogra> aha !
[09:32] <ogra> Temporary failure in name resolution
[09:32] <ogra> looks liek some internal DC thing
[09:33] <ogra> (sorry, i only looked at build.s.io ... could have checked LP directly)
[09:33] <cjwatson> That's the ENOMEM issue on ackee
[09:33] <cjwatson> It is SUPER WEIRD
[09:34] <ogra> are there chances clicking retry will work (else i'll just leave it as is for the moment, there were no important snaps re-built, only because of security notifications)
[09:35] <cjwatson> We have three workers that run various jobs such as store uploads; as of a few weeks ago, occasionally one of them gets into a state where it starts getting ENOMEM for all attempts to allocate memory, despite there being loads of memory free and all the other usual things you might check in this situation
[09:35] <cjwatson> This results in a bunch of things failing, including DNS resolution
[09:35] <ogra> weird indeed ...
[09:35] <ogra> yeah
[09:36] <cjwatson> Hmm, one of the workers is in that state right now
[09:36] <ogra> it might be a good idea to forward the error message to the build.snapcraft.io log or some such
[09:37] <ogra> especially since the only link to look at LP is at the top of the log iself ... not sure how many people will actually use that to find out more
[09:39] <cjwatson> The BSI log is just the build log
[09:39] <cjwatson> Can't do that
[09:40] <cjwatson> I have a spec for improvements to LP's store upload process
[09:40] <cjwatson> It's probably not next on my list but maybe the one after that
[09:40] <ogra> well, this is mostly about the UI of build.s.io ... not even sure thats in your area of things :)
[09:42] <ogra> having some direct link to the LP build or some more info than a bland "Failed to release" with no further info on the page would help
[09:50] <cjwatson> Evan says we're not allowed :P
[09:50] <ogra> haha
[09:50] <cjwatson> (to have a direct link to LP)
[09:50] <ogra> yeah ... i got that
[09:51] <mup> PR core18#78 opened: static: show seed progress on console on firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/78>
[09:55] <mup> PR core18#78 closed: static: show seed progress on console on firstboot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/78>
[09:56] <cjwatson> ogra: Bug in the BSI UI, I think - it's meant to show it but there's a confusion about ![] not being true in JS
[09:56] <ogra> ah
[10:05] <mup> PR snapd#5952 opened: tests/ifacestate: moved asserts-related mocking into helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
[10:07] <mborzecki> why are timers/sockets enabled in StartServices() rather than AddSnapServices() ?
[10:07] <pstolowski> pedronis: can you take a look ^ ?
[10:07] <pedronis> pstolowski: yes, after lunch
[10:09] <cjwatson> ogra: Anyway, you can try using Retry, though due to the various problems outlined in https://docs.google.com/document/d/1vabN2wBNtGdBqShN1xi9a-osfGPtmA8EARdXfs2kfDI it's possible that it will require a full rebuild in order to be uploadable
[10:10] <ogra> cjwatson, well, i just tried retry and got a permission error
[10:10] <ogra> seemingly i'm not allowed to retry
[10:11] <cjwatson> A permission error saying what precisely?
[10:11] <cjwatson> Oh, from https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860 ?  Yeah, LP doesn't know that you own the snap on BSI.
[10:11] <ogra> right
[10:11] <cjwatson> I've hit Retry but it probably won't work
[10:12] <ogra> well, that particular snap is less important anyway ... and i'll trigger rebuilds for the others
[10:14] <cjwatson> Yeah, that hit the silly duplicate-snap-content error from the store
[10:14] <cjwatson> Which is one of the things my spec covers
[10:37] <mup> PR core18#79 opened: snap-snapd-from-snap: remove all debug output <Created by mvo5> <https://github.com/snapcore/core18/pull/79>
[10:57] <Chipaca> if/when you spot a unit test on travis taking ages talking to the apt mirror, please let me know
[10:58] <Chipaca> I want those logs
[10:59] <Chipaca> e.g. https://travis-ci.org/snapcore/snapd/jobs/439058232
[11:09] <mup> PR snapd#5953 opened: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <https://github.com/snapcore/snapd/pull/5953>
[11:11] <ogra> ppisati, hmm, 4.4.0-1099-raspi2 doesnt have the modules fix yet ? (i just had an upgrade on my pi's and the splashes went away)
[11:15] <ogra> cjwatson, hmm, are we short on arm builders again (all my retried builds now sit in "building soon" state for all amr arches)
[11:15] <ogra> *arm
[11:16] <cjwatson> ogra: see #is-outage please
[11:16] <cjwatson> work in progress
[11:16] <ogra> ok
[11:25] <mborzecki> https://paste.ubuntu.com/p/gTn99BMxhg/ snap services with sockets and timers
[11:36] <niemeyer> pstolowski|lunch: Nitpick (and optional, obviously):
[11:36] <niemeyer>  			// attribute name and value are separated by null character
[11:37] <niemeyer> That's exactly what the code below it says
[11:37] <niemeyer> more clearly
[11:38] <dot-tobias> zyga: re: https://forum.snapcraft.io/t/snap-layouts/7207/4?u=tobias → Added an answer, but it seems there's something else going on there. I'm running a command in my install hook to copy files over from $SNAP/folder/subfolder/* to $SNAP_DATA/subfolder, could it be that? This happens even when I completely remove the “partly duplicated file name” section from the layout stanza.
[11:39] <niemeyer> pstolowski|lunch: Ah, there's something else.. will comment on the PR
[11:40] <zyga> dot-tobias: I don't think the hook is a factor, it runs after the setup process, in any case, if you can share a snap that I can play with (even a dummy one that has this bug) it would help as I was unable to reproduce this
[11:41] <dot-tobias> zyga: Will cook up something, thanks
[11:56] <cachio> pstolowski|lunch, hey, already working in nested suite
[12:04] <mborzecki> Chipaca: niemeyer: i see you've discussed including timers in snap services commands, i've posted a note in the topic https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/33 feel free to provide suggestions
[12:06] <mborzecki> cachio: hey, https://github.com/snapcore/spread-images/pull/17 had to execute those manually, but afaict the host after those changes appears to work fine
[12:06] <mup> PR spread-images#17: tasks/google/update-arch-linux: tweak Arch image update <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/17>
[12:09] <cachio> mborzecki, nice, checking
[12:20] <mup> PR snapcraft#2323 closed: go plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323>
[12:21] <niemeyer> mborzecki: Thanks!
[12:23] <Chipaca> oh, what a surprise, opensuse failing agian :-((((((
[12:24] <Chipaca> can we add a rule, "to be supported by snapd, your distro's mirror archive must be *this* available"?
[12:26] <mup> PR snapcraft#2327 opened: pluginhandler: remove prepare, build and install scriptlets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2327>
[12:29] <cachio> mborzecki, works!!
[12:34] <niemeyer> mborzecki: Responded
[12:38] <mup> PR snapcraft#2328 opened: godeps plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328>
[12:38] <rbasak> mvo_: I put a reproducer in bug 1796017
[12:39] <mup> Bug #1796017: git ubuntu build-source fails with missing libreadline.so.6 <usd-importer:In Progress by racb> <https://launchpad.net/bugs/1796017>
[12:39] <rbasak> I'm a bit baffled as to why this doesn't work. Is there anything else going on eg. seccomp?
[12:39] <rbasak> Or other necessary environment changes that I missed?
[12:55] <cachio> mborzecki,
[12:58] <mup> PR core18#79 closed: snap-snapd-from-snap: remove all debug output <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/79>
[13:10] <ogra> argh
[13:10] <ogra> sergiusens, !!!
[13:10] <ogra> Snapping 'pi-kiosk' |
[13:10] <ogra> Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap
[13:10] <ogra> Stopping local:snapcraft-sadly-choice-amoeba
[13:10] <ogra> Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap"
[13:11] <ogra> sergiusens, thats a snapcraft cleanbuild of a snap using build-on/run-on ...
[13:11] <ijohnson> ogra: stop naming your snap "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')])"
[13:11] <sergiusens> ogra: we'll get kyrofa to take a look when he gets in
[13:11] <ogra> i'd kind of expect the resulting snap file not to contain python code in its name
[13:12] <sergiusens> but, cleanbuild is also deprecated to a baseless world
[13:12] <ogra> so how do i build my snaps now ?
[13:15] <sergiusens> ogra: if you set a base, you get a build vm
[13:15] <ogra> sergiusens, so i need to touich all the snaps i have ?
[13:15] <ogra> (for re-builds when getting security notifications ??)
[13:15] <sergiusens> ogra: no, if you do not change anything, you don't need to touch anything
[13:17] <ogra> cjwatson, i know you are busy with the outage ... but i see some weird cross build behaviour on the builders that i can not reproduce locally either with a plain build or withz a snapcraft cleanbuild
[13:17] <ogra> checking for arm-linux-gcc... /usr/bin/arm-linux-gnueabihf-gcc
[13:17] <ogra> checking whether the C compiler works... no
[13:17] <ogra> configure: error: in `/build/pi-kiosk/parts/psplash/build':
[13:17] <ogra> configure: error: C compiler cannot create executables
[13:17] <mup> PR snapcraft#2329 opened: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329>
[13:18] <ogra> the fun part is that theer is a part before that just used /usr/bin/arm-linux-gnueabihf-gcc to build a binary
[13:18] <cjwatson> ogra: I have no idea, sorry.  Try catting config.log after the failure to get more details
[13:19] <ogra> hmm., k
[13:30] <mborzecki> Chipaca: can you take a quick look at https://github.com/snapcore/snapd/pull/5951 ?
[13:30] <mup> PR #5951: spread-shellcheck: fix interleaved error messages, tweaks <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
[13:37] <Chipaca> mborzecki: what do you think about my 'activator' comment?
[13:38] <mup> PR snapcraft#2330 opened: pluginhandler: remove big solidus workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330>
[13:44]  * Chipaca ~> school run*
[13:44] <Chipaca> * wee (maybe)
[13:51] <ackk> hi, is there a way to specify the container image/release when running "snapcraft cleanbuild"?
[13:52] <mup> PR snapd#5759 closed: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5759>
[14:01] <ogra> cjwatson, here we go https://launchpadlibrarian.net/392453534/buildlog_snap_ubuntu_xenial_amd64_ae16fdc83ee020a5817d7f0243e105b5-xenial_BUILDING.txt.gz seems while my desktop and cleanbuild automatically install binutils-arm-linux-gnueabihf when i add a "build-packages" entry for gcc-arm-linux-gnueabihf, the LP builder doesnt do so
[14:01] <ogra> at least thats my guess for:
[14:01] <ogra> configure:2973: /usr/bin/arm-linux-gnueabihf-gcc    conftest.c  >&5
[14:01] <ogra> collect2: error: ld returned 1 exit status
[14:01] <ogra> grrr ! IRC
[14:02] <ogra> configure:2973: /usr/bin/arm-linux-gnueabihf-gcc    conftest.c  >&5
[14:02] <ogra> /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory
[14:02] <ogra> /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory
[14:02] <ogra> collect2: error: ld returned 1 exit status
[14:02] <ackk> sergiusens, hi, maybe you have insights on my question above?
[14:04] <ogra> aha !
[14:04] <ogra> libc6-dev-armhf-cross iss a recommends ... ok
[14:04] <ogra> *is
[14:05] <ogra> cjwatson, thanks for pointing in the right direction i think i got a workaround for that one (though it is still weird that cleanbuild doesnt expose that issue)
[14:15] <niemeyer> Hey folks.. I'm back
[14:26] <ogra> whee ! a properly cross built gadget snap on build.snapcraft.io !!!!
[14:26] <ogra> https://launchpad.net/~build.snapcraft.io/+snap/ae16fdc83ee020a5817d7f0243e105b5-xenial/+build/349077
[14:27] <ogra> very nice !
[14:44] <sergiusens> ackk: no, there is not; we are moving to a new model which will be trickled by the use of bases.
[14:45] <mup> PR snapd#5954 opened: [wayland] explicitly permit file locking for wayland lock <Created by gerboland> <https://github.com/snapcore/snapd/pull/5954>
[15:00] <ogra> jdstrand, so i have https://dashboard.snapcraft.io/snaps/dashkiosk-client-image-config/revisions/11/ ... using a self-provuded udisks2 interface, is there any chance you would approve that or should i rip out the code using that interface ?
[15:02] <ogra> jdstrand, source is at: https://github.com/ogra1/dashkiosk-client-image-config
[15:03] <ackk> sergiusens, I see, so there's currently no way of cleanbuilding a core18 snap
[15:18] <ondra> kyrofa ping
[15:19] <sergiusens> ackk: no, for that you probably want to be on edge and set SNAPCRAFT_BUILD_ENVIRONMENT=multipass (and set base: core18)
[15:19] <kyrofa> ondra, hey there
[15:20] <ackk> sergiusens, ah I see. I do use edge and core18 base
[15:20] <ackk> sergiusens, so this will only be available on multipass?
[15:21] <sergiusens> ackk: just missing the env then, but edge should switch to creating the VM by default real soon
[15:21] <ackk> sergiusens, thanks
[15:21] <sergiusens> ackk: for the time being yes, it what was agreed to during the roadmap sprint. Next cycle we will bring back lxd
[15:22] <ondra> kyrofa hey
[15:22] <ondra> kyrofa can you please check https://code.launchpad.net/~ondrak/+snap/toolbox
[15:22] <ondra> kyrofa for whatever reason on arm64 it breaks when priming
[15:23] <cjwatson> ogra: mm, may be the sort of thing that gets ironed out by moving to a common build container/VM/whatever
[15:24] <ogra> cjwatson, well, fallout of --no-install-recommends i think
[15:25] <ogra> apparently the cleanbuild lxd container installs recommends by default
[15:25] <cjwatson> ogra: which is in the LP build chroots' apt.conf
[15:25] <cjwatson> ogra: hence my comment
[15:25] <ogra> right
[15:26]  * cachio lunch
[15:29] <kyrofa> ondra, is peekfd an app?
[15:30] <ondra> kyrofa yep
[15:30] <kyrofa> ondra, looks like you're using usr/bin/peekfd as an app, but for whatever reason on arm64 it doesn't exist (not that the traceback is turned into a nicer error on edge)
[15:30] <ondra> kyrofa unless it exist only on armhf and x86 and not on arm64
[15:30] <kyrofa> s/not/note/
[15:31] <kyrofa> Yeah not sure why, but that's the issue
[15:32] <ondra> kyrofa can one define app per arch in this case?
[15:35] <kyrofa> ondra, I'm afraid not
[15:35] <ondra> kyrofa damn, so need to remove it from all, or bug against package I guess
[15:41] <kyrofa> ondra, or add a wrapper that can handle it not being there and error out
[15:41] <kyrofa> But yeah, I'd look into why it's not there
[15:43] <ondra> kyrofa unrelated question, I have project which has two flavours. Ideally I'd like to build it from same branch, but that means two different snapcraft.yaml files, is there easy way to handle this?
[15:46] <kyrofa> ondra, snapcraft doesn't have a way to consume two snapcraft.yamls, if that's what you're asking. Launchpad doesn't support it, either
[15:47] <ondra> kyrofa yep, something along those lines
[15:55] <roadmr> sergiusens: hi! what are the implications of https://bugs.launchpad.net/snapcraft/+bug/1794805 for the snapcraft parts service? https://parts.snapcraft.io/v1/parts.yaml
[15:56] <mup> Bug #1794805: Remove wiki parts <18.10-build-vm> <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1794805>
[15:56] <joc> hehe was just about ask my own question :)
[15:59] <joc> sergiusens: with the remote parts wiki going, will there be some other method of re-using parts definitions across snaps? and what timescales are we looking at for this being unavailable?
[15:59] <mup> PR core18#80 opened: static: show some progress during firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/80>
[16:01] <sergiusens> roadmr: should keep on working, you use the deb, correct?
[16:01] <sergiusens> joc: https://forum.snapcraft.io/t/proposal-templates/6019
[16:01] <sergiusens> joc: if you are using bases, they are gone
[16:01] <roadmr> sergiusens: I mean for the service itself - will it still be used or do we need to sunset it?
[16:02] <roadmr> sergiusens: (but if it's expected to keep working for people using the .deb or something else, not a problem, it can stay up as long as needed)
[16:02] <sergiusens> roadmr: when no one else builds with no base defined is the time we can put it to sleep
[16:02] <roadmr> sergiusens: gotcha, that's exactly what I wanted to know. Thanks!
[16:03] <roadmr> (sounds like that might be a long time in coming, but that's ok - parts service is quite lightweight, it can stay there indefinitely)
[16:04] <joc> sergiusens: by "using bases" do you mean having e.g. "base: core18" in my snapcraft.yaml?
[16:04] <sergiusens> joc: yes
[16:04] <joc> oof
[16:05] <mvo> Chipaca: so I would like to have a way to make "progress.Spin()" show stuff even when `snap watch` is not run from a terminal. the easiest way seems to be to add Spin() to quiteProgress but I wonder if that is the right option. maybe an option to waitMixin?
[16:05] <mvo> Chipaca: wdyt?
[16:05] <mup> PR snapcraft#2329 closed: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329>
[16:05] <Chipaca> mvo: 1 sec
[16:06] <mvo> Chipaca: no rush :)
[16:06] <Chipaca> mvo: I like it (in fact I thought it did that already)
[16:06] <Chipaca> mvo: maybe only show the message if it changes?
[16:06] <mup> PR core18#80 closed: static: show some progress during firstboot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/80>
[16:06] <mvo> Chipaca: aha, ok - so far it is doing a print on Notify() but not on Spin(msg)
[16:06] <Chipaca> not sure how often we're calling Spin with the same message
[16:06] <mvo> Chipaca: +1
[16:06] <Chipaca> mvo: yep, just saw that
[16:06] <mvo> Chipaca: awesome, I will make it happen (and +1 on checking if the message changes)
[16:07] <sergiusens> joc: the deb will not break, it is essentially frozen; which means it will get no new features either
[16:07] <Chipaca> mvo: OTOH, if this is for running it on /dev/console, is that not a tty? (or are we checking stdin instead of stdout?)
[16:07] <mvo> Chipaca: we check stdin
[16:07] <Chipaca> mvo: isn't that a bit silly?
[16:07] <mvo> Chipaca: of course we could simply check stdout
[16:07] <mvo> Chipaca: I guess :)
[16:08] <Chipaca> of course by now there are people depending on us checking stdin
[16:08] <Chipaca> but we could check both :)
[16:08] <Chipaca> bah, dunno
[16:08] <Chipaca> wtyt?
[16:08] <Chipaca> we could also switch to checking stdin, and warn people via the forum
[16:08] <mvo> Chipaca: one slightly complication is that my code does "snap watch --last=seed | tee -a /dev/console"
[16:08] <Chipaca> "this was silly, we fixed it, sorry if we broke you but surely you agree it's less silly now"
[16:08] <Chipaca> mvo: boo :-)
[16:08] <Chipaca> er
[16:08] <mvo> Chipaca: because we still want these messages in journalctl -u
[16:09] <Chipaca> mvo: so why not 'snap watch --last=seed < /dev/console | tee -a /dev/console?
[16:09] <mvo> Chipaca: aha, nice
[16:09] <Chipaca> s/\?/'?/
[16:09] <mvo> Chipaca: yeah, that should work, let me quickly test
[16:09] <Chipaca> mvo: also, I'd recommend writing it '--last=seed?'
[16:10] <Chipaca> unless you know for sure there is a seed change already
[16:10] <mvo> Chipaca: yeah, I totally know
[16:10] <Chipaca> k
[16:10] <mvo> Chipaca: but good advice, thanks
[16:11] <jdstrand> ogra: does it honor the slot side of the contract for udisks2? in other words, does it ship udisks2 such that other snaps can connect to it and use udisks2?
[16:11]  * zyga resumes work on user-mounts
[16:12] <zyga> hey jdstrand, how are you?
[16:12] <ogra> jdstrand, well, it runs a daemon that spawns udisksd when a USB key is plugged in ...
[16:12] <jdstrand> zyga: hey, pretty good. very busy :) how are you?
[16:13] <zyga> jdstrand: had an interrupt but made a lot of progress for user mounts today
[16:13] <zyga> jdstrand: expect some patches relatively quickly :)
[16:14] <ogra> jdstrand, not sure what else the udisks2 "contract" requires ... the daemon-script is rather specifc to import a neplan yaml file if it exists ... and since this is for embedded systems it a) has an install hook check that prevents it from being installed on non-core and b) does not run udisksd permanently
[16:15] <jdstrand> ogra: if you slots udisks2, then your snap is expected to provide the udisks2 service
[16:16] <jdstrand> ogra: why are you slotting udisks2?
[16:16] <ogra> jdstrand, well, how else would i get mounting to work from a snap ?
[16:17] <jdstrand> ogra: I don't know what your snap does. have it plugs udisks2 and then talk to udisks2 to do that for you?
[16:17] <ogra> i'd just use a udev monitor script and call mount driectly, but there are no interfaces offering that
[16:17] <mup> PR core18#81 opened: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <https://github.com/snapcore/core18/pull/81>
[16:17] <jdstrand> ogra: this sounds like a conversation for the forum. I suggest stating what it is your snap requires, and how you'd like to get there
[16:18] <ogra> jdstrand, https://github.com/ogra1/dashkiosk-client-image-config/blob/master/netplan-import ... thats the daemon script ... it watched udev for udb block device plug events ... if one is there, it mounts the usb block device and looks for a netplan config
[16:18] <ogra> *watches
[16:18] <ogra> s/udb/usb/
[16:19] <mup> PR core18#81 closed: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/81>
[16:19] <ogra> jdstrand, well, i need the snap for a demo at IoT worldcongress next week, i'll just rip out that feature, i doubt i'll have the time to re-implement it differently in time
[16:20] <ogra> effectively i just need an interface that allows me to run mount/umount and we dont have that
[16:20] <jdstrand> ogra: you are calling udisckstl, why not plugs: [ udisks2 ] and have the udisks2 snap installed?
[16:21] <jdstrand> then just talk to that other snap
[16:21] <ogra> do we have that for all arches ?
[16:21]  * ogra checks
[16:21] <ogra> hmm, k
[16:21] <jdstrand> ogra: I see an armhf in edge
[16:21] <kyrofa> Hey ogra, any ideas on this? https://askubuntu.com/questions/1082277/socketcan-device-on-ubuntu-core
[16:21] <jdstrand> it's old, but it is there
[16:21] <ogra> edge ... hmm
[16:21] <zyga> roadmr: hey
[16:22] <roadmr> hehey zyga ! how goes it!
[16:22] <zyga> I need a hand in debugging a store side bug (presumably)
[16:22] <zyga> remember that snap?
[16:22] <zyga> I tried it again
[16:22] <ogra> ah, also in stable
[16:22] <jdstrand> ogra: looks like morphis did it. that would be the ce team now I guess
[16:22] <zyga> first time I kept the hack with chmod
[16:22] <zyga> it passed
[16:22] <zyga> second time it did not
[16:22] <zyga> I think something else is wonky
[16:22] <jdstrand> yes, and stable
[16:22] <zyga> I can show you the error I'm getting, it's very terse though
[16:23] <ogra> jdstrand, thanks, i'll try to use that one ... effectively simply having snapd allow you to import a netplan config (like we allow system-user assertions) would be the proper solution after all
[16:23] <roadmr> zyga: sure, error would be nice
[16:23] <zyga> roadmr: let me re-make it, I also had issues with snapcraft in that run
[16:24] <ogra> jdstrand, trying to create appliance images that do not force you to attach a serial cable to configure wlan ... (and that already have the screen occupied, so you cant use console-conf there)
[16:24] <ogra> jdstrand, if i reject the held snap, i should be capable to upoad again without them getting stuck in the sotre review ?
[16:25] <ogra> *store
[16:25] <ogra> kyrofa, i think thats actually one for awe, i dont have moch experience with CAN bus stuff (but he has)
[16:26] <jdstrand> ogra: yes
[16:26] <ogra> kyrofa, but it looks like we are lacking an interface to even use them on core
[16:27] <ogra> jdstrand, my prob with adding more snaps to the image is that snapd takes 3-5 min per snap on first boot btw ... i'm already at a 20min first boot with this image
[16:28] <ogra> but i guess i'll ave to bit that bullet for now
[16:28] <ogra> *bite
[16:28] <zyga> roadmr: got them
[16:28] <zyga> The store was unable to accept this snap.
[16:28] <zyga>   - __all__: The upload does not appear to be a valid package.
[16:28] <roadmr> \o/
[16:28] <zyga> that's all I got
[16:28] <roadmr> yeay
[16:28] <zyga> the package can be installed locally obviously
[16:29] <zyga> note: I did the upload as root
[16:29] <zyga> as a user snapcraft crashes
[16:29] <zyga> kyrofa: ^ wanna see?
[16:29] <roadmr> zyga: hm, can you either run the review tools on the package locally to see what they say, or shoot me a copy of the built snap?
[16:30] <zyga> roadmr: could I just send you the snap please?
[16:30] <roadmr> zyga: sure thing
[16:32] <kyrofa> zyga, I'm missing context, what are you doing?
[16:32] <zyga> kyrofa: I'm using snapcraft push *.snap
[16:32] <zyga> and it crashes with ...
[16:33] <zyga> https://www.irccloud.com/pastebin/164aZPmQ/
[16:33] <ogra> kyrofa, i forwarded the question to tony now ...
[16:33] <ogra> kyrofa, did you see my issue with the architectures build-on/run-on thing under cleanbuild above ?
[16:34] <ogra> kyrofa, :
[16:34] <ogra> <ogra> Snapping 'pi-kiosk' |
[16:34] <ogra> <ogra> Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap
[16:34] <ogra> <ogra> Stopping local:snapcraft-sadly-choice-amoeba
[16:34] <ogra> <ogra> Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap"
[16:34] <ogra> it somehow includes python code snippets in the final snap name
[16:38] <roadmr> zyga: hm we may need jdstrand's help on this
[16:38] <zyga> oh/
[16:39] <zyga> roadmr: what's the error from the review tools?
[16:39] <roadmr> zyga: https://pastebin.canonical.com/p/8Sj2fXx5M4/
[16:40] <zyga> hmm, wasn't this the same error as before?
[16:40] <roadmr> zyga: I think that python traceback from the failure to rm is causing the store to barf (because it expects the tools output to be json - even if I say --json it has that Python thing at the end)
[16:40] <zyga> those as not writable by owner
[16:40] <roadmr> zyga: yes, I fixed that store-side, but IIRC your earlier snap didn't show this output from the tools
[16:40] <zyga> ahh
[16:40] <zyga> I See
[16:40] <roadmr> if the tools can't clean up and barf like this, I can't fix that store-side directly :/
[16:41] <jdstrand> zyga: where is this snap?
[16:41] <zyga> jdstrand: sent via wormhole to roadmr
[16:41] <roadmr> jdstrand: the top-level dir ias this mode drwx------
[16:41] <zyga> it's just a fedora base I was sending before
[16:42] <jdstrand> I'd need the snap if I'm going to look at fixing the review tools
[16:42] <zyga> jdstrand: I can wormhole it to you as well if you don't mind
[16:42] <jdstrand> that's fine
[16:42] <roadmr> it's not huge, only 18 MB
[16:43] <zyga> sent
[16:43] <jdstrand> ok, I'll take a look at it
[16:43] <roadmr> jdstrand: I suspect the fix will be similar to what I did store-side https://bazaar.launchpad.net/~ubuntuone-pqm-team/software-center-agent/trunk/revision/5055
[16:43] <jdstrand> zyga: while I have you. can I get your opinion on something
[16:43] <jdstrand> roadmr: ack, thanks
[16:44] <jdstrand> zyga: so, I need to add 'unsafe' to the default template
[16:44] <zyga> sure, I'm all ears
[16:44] <jdstrand> zyga: but it fails spread cause apparently opensuse 42.3 has a too old apparmor_parser
[16:44] <kyrofa> ogra, yuck, that's interesting
[16:44] <zyga> right, I remember that branch
[16:44] <jdstrand> zyga: that doesn't know what 'unsafe' is
[16:44] <roadmr> actually - the review tools' recursive_rm appears to be identical to what we have in the store, so pretty sure my fix will apply :D
[16:45] <jdstrand> zyga: so, I think the most correct solution is to use apparmor_parser from the core snap. however, I don't want to do that in this PR because whenever we move to this sort of scenario, it has a long tail of little fixes
[16:45] <jdstrand> zyga: we can do that in a future pr
[16:45] <zyga> would a parser from core produce binary compatible with the host kernel?
[16:46] <jdstrand> zyga: sure, why not?
[16:46] <jdstrand> the parser is fully aware of the kernel
[16:46] <zyga> that's good
[16:46] <jdstrand> using the parser in core would mean we could update apparmor in Ubuntu only to fix parser bugs, enhancements, etc, etc
[16:47] <jdstrand> kinda like how we pulled back xenial's apparmor to trusty
[16:47] <jdstrand> we could do that 'forever'
[16:47] <zyga> ok
[16:47] <jdstrand> and not worry about other distro's apparmor
[16:47] <jdstrand> anyhoo
[16:47] <zyga> so that's the preferred solution
[16:47] <jdstrand> that is the ideal
[16:47] <zyga> and in the meantime?
[16:47] <jdstrand> but, again, I don't want to do that, so we have some choices
[16:48] <jdstrand> I explored the idea of having a parser features list and populating it, just like we do with the features dir
[16:48] <zyga> oh, that's interesting
[16:48] <jdstrand> it works, but there are a number of test case mockings which got me wondering if there is another way
[16:49] <jdstrand> (especially since if we go the apparmor_parser from core route, we just rip out this code)
[16:49] <zyga> btw, what is the unsafe vs safe transition about?
[16:49] <jdstrand> secure_exec
[16:49] <jdstrand> ie, stripping LD_LIBRARY_PATH
[16:49] <jdstrand> it is explained in the pr
[16:50] <jdstrand> so the other option is, if we are PartialAppArmor already, we know we don't have a new enough parser, so don't use unsafe if PartialAppArmor
[16:50] <zyga> ah
[16:50] <zyga> ok
[16:50] <jdstrand> this is cheap, but mildly inaccurate, but since the code is going to be ripped out soon, who cares?
[16:50] <zyga> that would partially regress arch and opensuse tumbleweed though
[16:50] <jdstrand> so... do you care?
[16:50] <jdstrand> :)
[16:50] <zyga> ha
[16:50] <zyga> so that's the question
[16:51] <zyga> I think that's fine if you are really going to do the full deal
[16:51] <zyga> as in schedule wise
[16:51] <zyga> I'm sure you would
[16:51] <jdstrand> zyga: that's the thing, arch and tumbleweed should have a new enough apparmor_parser, so I can special case them or do something with downgradeConfinement, etc so they get unsafe
[16:52] <zyga> in that case I think we're good
[16:52] <jdstrand> or not, and just say that they don't get unsafe until we use the parser from core
[16:53] <jdstrand> well, as it happens, I have a new manager now and slowly coming out from the last couple months
[16:53] <jdstrand> I can add moving apparmor_parser from core to the roadmap
[16:53] <jdstrand> err
[16:53] <jdstrand> moving to apparmor_parser from core to the roadmap
[16:53] <zyga> +1
[16:53] <zyga> we should do the same for snap-seccomp
[16:53] <jdstrand> I mean, this has a ton of benefits way beyond this
[16:53] <zyga> for statx and the lkike
[16:53] <zyga> *like
[16:54] <jdstrand> yeah
[16:54] <zyga> we should also answer the question of reexec=0 distros
[16:54] <jdstrand> sure, but to me, we would always use the apparmor from core, regardless of reexec
[16:54] <jdstrand> or do you see a problem with that?
[16:55] <zyga> technically no
[16:55] <zyga> but policy wise it could be borderline iffy
[16:55] <jdstrand> who's policy?
[16:55] <jdstrand> fedora shouldn't care-- they don't have apparmor
[16:56] <zyga> but they have seccomp
[16:56] <zyga> I imagine this is the same deal
[16:57] <zyga> but anyway, we don't have to discuss this now,  I think technically we are in agreement
[16:57] <zyga> and we can keep the code that uses distribution tools
[16:58] <jdstrand> zyga: well, if we are planning on keeping the code, probably need parserFeatures
[16:58] <jdstrand> we don't necessarily need to downgrade to PartialConfinement though
[16:59] <jdstrand> that's a 3rd option. I check to see if the parser supports a syntax we know older ones don't have, and then populate something in snapd (other than PartialAppArmor) that we can query when using that one rule
[17:00] <jdstrand> sorta sounds like based on this conversation that is possibly the best path forward
[17:00] <zyga> jdstrand: we can probably use system key for that
[17:00] <zyga> or a combination of system key and locally held state in AppArmor backend
[17:00] <jdstrand> right, I was initially thinking of that
[17:00] <jdstrand> ok, I'll just go that route for now
[17:01] <zyga> ok
[17:01] <jdstrand> zyga: thanks
[17:02] <zyga> my pleasure :)
[17:08] <ogra> jdstrand, fyi, works very nicely with the udidks2 snap, thanks for the hint (if only the firstboot wouldnt be 5min longer now)
[17:10] <jdstrand> ogra: nice! :)
[17:11] <jdstrand> ogra: I wonder why it takes so long... that seems like a bug?
[17:12] <ogra> jdstrand, yeah, its a known go bug with checksumming sha256 stuff on arm ... snapd uses that when installing a snap for the first time ... so each snap delays the firstboot
[17:13] <ogra> jdstrand, ijohnson has sent a fix upstream some months ago but that has still not been included
[17:13] <ogra> (go upstream)
[17:13] <ogra> picking sha256 for snaps was a bit overzealous ;)
[17:14] <ijohnson> it's actually sha3 hashing
[17:14] <ogra> ah, i thought it was 256
[17:14] <ogra> some sha :P
[17:14] <ijohnson> well it's sha3 with length 256
[17:14] <ogra> sha-la-la :)
[17:14] <zyga> ha
[17:14] <zyga> I was _just_ typing that
[17:14] <ijohnson> (although I thought that snapd used 384, but my fix fixes all sha3)
[17:14] <ogra> (sorry, hard day ... tired and silly)
[17:15] <ogra> zyga, welcome to my level of sillyness then :)
[17:15] <zyga> ogra: I'm always silly
[17:15] <zyga> I feel quite at home
[17:15] <ogra> heh
[17:19] <ogra> mvo, i saw yu landed the password expiry stuff ... any chance that goes into some non-edge channel before the weekend ?
[17:19] <ogra> (likely not, but i thought i'd ask at least)
[17:46] <mvo> ogra: there is a good chance actually - to hit beta, once the current beta moves to candidate I will do a new 2.36~pre2
[17:46] <mvo> ogra: and that will move to beta
[17:47] <ogra> beta sounds perfect ...
[17:50] <mvo> sil2100: the various races for the pi firstboot (and dragon) are hopefully all under control now, I guess we just need to dig into the probert issue (and someone needs to test on a dragonboard)
[17:50] <mvo> sil2100: I will push new test images later tonight or early tomorrow but nothing special about them, just current edge (and soon beta) for core18 and friends
[17:50] <mvo> sil2100: (mostly just fyi)
[17:56] <zyga> jdstrand: I subscribed you to https://bugs.launchpad.net/snappy/+bug/1796362
[17:56] <zyga> please check my last comment there
[17:56] <mup> Bug #1796362: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:Incomplete> <https://launchpad.net/bugs/1796362>
[17:56] <zyga> mvo: is dragonboard fixed now? I can test it if you need that
[17:57] <jdstrand> roadmr: can you pull r1132. it has the fix for zyga's snap
[17:57] <zyga> mvo: do you want to do a simple boring review with a function rename
[17:57] <zyga> jdstrand: oh, that was quick, thank you!
[18:08] <mvo> zyga: dragonboard - I'm not sure its fixed, let me build a new test image. I fixed some firstboot races
[18:08] <zyga> k
[18:21] <mup> PR snapd#5955 opened:  cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[18:51] <sil2100> mvo: thanks! I'm usually just building images myself to always have the latest core, but I know there are others that were doing some tests on the pre-built ones
[18:51] <sil2100> mvo: I saw a lot of good fixes getting merged today, thanks for those!
[18:52] <sil2100> mvo: we're still working on some bits and pieces to enable dailies, but now with the official assertions we can push things a bit more forward
[19:21] <mvo> sil2100: great, thank you. building them yourself is fine of course :)
[19:21] <mvo> zyga: dragonboard is up at http://people.canonical.com/~mvo/core18/
[19:21] <mvo> zyga: but no rush
[19:22] <mvo> zyga: also I'm not sure things will be better than at the sprint, but you never know :)
[19:22] <mvo> sil2100: fixes> yeah, nothing beats testing on real HW there were some races
[19:29] <mup> PR snapcraft#2331 opened: meson plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2331>
[19:58] <jdstrand> zyga: hey, can you add this to your list: https://github.com/snapcore/snapd/pull/5739 (waiting for spread tests to finish)
[19:58] <mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739>
[20:12] <mup> PR snapcraft#2332 opened: waf plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2332>
[20:24] <mup> PR snapcraft#2328 closed: godeps plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328>
[20:29] <thresh> popey, pingie "download button" art
[20:35] <roadmr> jdstrand: hi! sure will do
[20:45] <mup> PR snapcraft#2330 closed: pluginhandler: remove big solidus workaround <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330>
[21:03] <popey> thresh: i pinged design about that yesterday, and was told it's in the lawyers queue for licensing.
[21:03] <popey> thresh: thanks for the ping :)
[22:12] <mup> PR snapcraft#2333 opened: catkin, catkin-tools: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2333>
[22:15] <mup> PR snapcraft#2248 closed: plugin: update catkin plugin to support melodic <do-not-merge-yet> <Created by NickZ> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2248>
[23:10] <mup> PR snapd#5861 closed: cmd/libsnap: add functions for handling facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5861>
[23:35] <mup> PR snapd#5859 closed: many: introduce facts, export experimental features as facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5859>


[21:06] <Unit193> Maybe someone here will get this one. http://warehousecomic.com/comics/2013-03-13-theWAREHOUSE_comic_808-Stick-the-Landing.jpg  :P


[03:16] <blahdeblah> Repeating earlier question now that my IRC bouncer isn't bouncing up & down:
[03:16] <blahdeblah> Anyone able to comment on what's current best/easiest practice when setting up a VM host with VMs bridged onto multiple VLANs?
[03:16] <blahdeblah> I know the Linux kernel bridging code grew VLAN filtering in semi-recent kernels - is there an easy configuration method for it exposed in userland?
[08:41] <crohmann> coreycb: jamespage: May I kindly nag you about triggering a package update for UCA for neutron-vpnaas? - see https://bugs.launchpad.net/cloud-archive/+bug/1995861
[08:41] -ubottu:#ubuntu-server- Launchpad bug 1995861 in Ubuntu Cloud Archive "[SRU] neutron-vpnaas packages need updates as they are missing two critical patches" [Undecided, New]
[14:19] <sdeziel> blahdeblah: apparently systemd-networkd supports it but netplan doesn't yet (it's be asked for via https://bugs.launchpad.net/netplan/+bug/1793128 though)
[14:19] -ubottu:#ubuntu-server- Launchpad bug 1793128 in netplan "support vlan-aware bridges (vlan-filtering)" [Wishlist, Triaged]
[17:19] <foo> teward: when you say "i would NOT have things live in your home directory" (and sdeziel agrees) - you're referring to web code? Or socket only?
[17:19] <foo> sdeziel: thanks, didn't think about strace
[17:29] <tds> blahdeblah: ifupdown2 has good support for it
[17:34] <tds> ah, though looks like ifupdown2 is missing from recent ubuntu releases :(
[18:43] <Kehet> hi, is it possible to dump crashlog from ubuntu-server installer to usb stick I use for booting?
[18:43] <Kehet> or some other way to transfer logs
[18:48] <teward> foo: technically speaking *both* because if there's a leak in your code it can traverse into your home directory and steal information.  but your socket should probably sit in a runtime directory space like was suggested by me and sdeziel like we said yesterday/overnight
[18:48] <sarnold> Kehet: when I was troubleshooting some booting problems a few years ago, I did a fair amount of copying of those crash dumps onto a different USB stick
[18:49] <sarnold> Kehet: depending upon how far you made it into the installer, you could configure the networking up, and use nc to move things around that way
[18:50] <Kehet> ohh I can drop to shell ofc, I'm dumb
[19:04] <blahdeblah> sdeziel, tds: thanks
[19:34] <foo> teward: thank you, that makes sense. I didn't consider this.
[19:34] <foo> teward: appreciate you sharing, thank you
[19:35] <teward> foo: you're welcome, but at the very least consider a runtimedirectory via systemd in /run/ for the socket at the least so www-data is guaranteed to access it proper
[19:36] <teward> i never trust www-data to work with sub/alt groups proper in daemons for the reasons you ran into - sometimes being in a secondary group doesnt work ;)
[19:38] <adac> effendy[m], I tried to remove the mount in the kubernetes env. That alone didn"t resolve the slow htop/iotop. However I also upgraded the packages on my machine and then docker got restarted. After that htop and iotop run fast again.
[19:39] <adac> So i suspect it you probably were still right. It might about this mount that stuff was slow on the machine. For whatever reason
[19:45] <effendy[m]> adac: interesting, yeah. Maybe there was something hanging there, even on the remote share
[20:03] <foo> teward: I like that.


[00:26] <jbicha> I'm having problems with gconf & edubuntu-artwork in Maverick
[00:30] <dinda> isakill:  there are some general lesson plans and resources that use free software
[00:30] <dinda> isakill: let see if I can find some links for you
[00:31] <mhall119> isakill: would you settle for a locally-hosted webapp?
[00:31] <dinda> isakill: if you post your query to the ubuntu educators list, I'm sure others can help you find good sources
[00:31] <isakill> dinda, ubuntu educators list?
[00:32] <dinda> https://lists.ubuntu.com/mailman/listinfo/ubuntu-education
[00:36] <dinda> gotta run, bbl
[02:11] <coz_> hey guys do I need akonaditray  or akonadi at all on edubuntu?
[15:08] <alkisg> !info virtualbox-ose maverick
[19:48] <kurt__> hi
[19:49] <kurt__> Is anyone here able to help me with a Microphone problem I have on 64-Bit ubuntu 10.04 ?
[19:50] <alkisg> Hi kurt__, you can ask here of course, but I don't know if you'll get any answers, this channel is for edubuntu-specific topics, for general ubuntu topics #ubuntu is preferred...
[19:51] <kurt__> ahh I tried in there :/
[19:51] <kurt__> it was impossible lol
[19:51] <kurt__> couldnt get a straight answer and no one would stick with me, im completly new to this and had no idea what i was supposed to do :(
[19:52] <alkisg> Heh, yeah, #ubuntu can be overwhealming.... maybe try some forum or mailing list instead?
[19:52] <kurt__> but basically when i record with my microphone and play back or use my mic with skype the sound produced from my microphone seems to have some interference playing quite loud in the background and the actual sound of my voice is broke up and hard to hear i dunno why its like that :(
[19:54] <kurt__> im trying a forumn only had one reply so far which was explaining what an alsa driver is and why its needed etc but didnt really say to install gnome pulse audio was just kinda saying it was needed so i installed it...now what lol >.< nothing ha changed apart from i hada  new volume control lol so i unstalled it since it didnt seem to do anything
[19:56] <kurt__> so was hoping i could get some help in here
[19:58] <kurt__> from the silence im guessing nobody here can help with my problem to lol ? :P


[00:35] <hggdh> only one thing about the server factoid -- it now uses the same kernel as the desktop
[03:02] <phunyguy> @mark #ubuntu Tin_man offtopic youtube videos
[20:50] <kcj> Hello, got +q in #ubuntu-offtopic because my flatmates drunken friends are idiots.
[21:06] <kcj> Anyone around?
[21:27] <zacwalls> i was banned from #ubuntu. it was a misunderstanding. can i go back now.
[22:00] <Lukas1321> I haven't joined to #ubuntu for a very long time; now I can't because I'm banned. Can anyone please tell me the reason?
[22:05] <ikonia> I'll take a look for you
[22:05] <ikonia> give me a moment please.
[22:07] <ikonia> Lukas1321: I don't see any reason you'd be banned
[22:08] <Lukas1321> ikonia, I only know that I'm banned
[22:08] <Lukas1321> If there's no reason, can someone unban me from there please?
[22:09] <ikonia> I'm just trying to find your ban
[22:09] <ikonia> find out what and sort it out with you
[22:11] <tsimpson> Match: *21!*21@* by k1l_ in #ubuntu on Jul 18 2014 23:10:31 (ID: 63266)
[22:11] <tsimpson> seems a bit wide to me
[22:11] <ikonia> yes,
[22:11] <ikonia> good spot tsimpson
[22:12] <ikonia> tsimpson: are you sorting it ?
[22:12] <tsimpson> yeah, I'll remove it
[22:12] <ikonia> thanks
[22:12] <Lukas1321> thank you
[22:13] <tsimpson> you should be able to join now Lukas1321
[22:13] <Lukas1321> Thank you tsimpson
[22:13] <tsimpson> you're welcome :)
[22:13] <Lukas1321> anyway, what does "*21!*21@*" mean?
[22:14] <tsimpson> it's a ban mask, it matches anyone with a nick or ident that ends in 21
[22:15] <tsimpson> and Lukas1321 does indeed end in 21, so you got matched by the ban
[22:16] <Lukas1321> oh. thank you
[22:21] <k1l> if the linkspam starts again you got tricked again by the spammer. that was the reason fir that wide ban.
[22:24] <tsimpson> sorry, too wide
[22:25] <tsimpson> or too wide for a ban without a short-ish duration set
[22:28] <IdleOne> they been spamming for the past week or two at least
[22:29] <IdleOne> those Nick21 nicks
[22:29] <IdleOne> ahh they switched to Nick22
[22:30] <IdleOne> so that ban was not any good anymore anyway
[22:30] <tsimpson> I really don't want to manually manage ban exemptions, because that's just not going to work
[22:30] <IdleOne> agreed
[22:30] <tsimpson> so settings such a wide ban for an extended period is not cool
[22:31] <IdleOne> the ban isn't serving its intended purpose anymore so good to remove it
[22:31] <tsimpson> sucks for us, but hey we volunteered for this!


[12:25] <crimsun> newz2000: that changeset hasn't been merged yet
[12:26] <crimsun> newz2000: that's why it's still marked "Fix Committed" instead of "Fix Released"
[12:27] <crimsun> newz2000: furthermore, although the changesets I've been emailing to Ben have been trivial, they don't exactly fix critical regressions, so I don't know if they'll make it into Feisty.
[12:34] <maks_> crimsun: is it a known trouble that after suspend of an intel ich6 audio controller the micro is no longer working?
[12:35] <maks_> that is since 2.6.18 for sure until latest linus
[12:35] <maks_> have seen it on a dell inspiron and on a ibm x41
[01:08] <crimsun> maks_: audio on my x41-2527 works fine across suspends-to-* and resumes
[01:08] <crimsun> maks_: I'm running the latest bios on the x41-2527
[01:12] <maks_> ok that might make the diff
[01:13] <crimsun> I can provide you with a diff that reverts the "aggressive power saving" commit for AC'97-based codecs
[01:14] <maks_> no idea if it ever worked crimsun?
[01:15] <maks_> didn't use the mic back then
[01:15] <crimsun> it definitely worked on the system I mentioned above
[01:16] <maks_> mine is not far off x41-2525
[01:16] <maks_> shall i test boot 2.6.17 or older to test?
[01:16] <maks_> have almost any kernel up to 2.6.14 installed
[01:17] <crimsun> sure.
[01:17] <crimsun> actually, CONFIG_SND_AC97_POWER_SAVE isn't even enabled, so it's definitely not the audio subsystem's fault
[01:18] <crimsun> not to mention even when it is enabled, it defaults to "off" (although it can be enabled via sysfs)
[01:22] <maks_> "(Fix) The LCD display may not turn on after the display off/on operation."
[01:22] <maks_> i guess i do want latest bios crimsun :)
[03:15] <rmjb> Hello, I'd like to get someone's input on a possible kernel bug: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655
[03:15] <rmjb> it's related to the dmraid package, to enable use of fakeraid arrays
[03:16] <rmjb> I want to find out if the bug makes sense, i.e. is true, and if it is I guess dmraid is broken in feisty for raid5 arrays
[03:16] <rmjb> if not then it can still be fixed since universe is not yet frozen
[03:20] <rmjb> ... anyone here tonight?
[03:20] <crimsun> only in rare circumstances, since many people will be observing the Good Friday holiday
[03:21] <rmjb> I'm observing it too... by bug fixing :)
[03:22] <crimsun> it's funny how regardless whether there's a holiday, people still expect us to fix bugs. :-)
[03:22] <rmjb> I don't want it fixed... just some advice on it
[03:22] <rmjb> should I email some list if no one is here?
[03:24] <crimsun> I have no such configuration, so you'll need to get more details from the original reporter.
[03:25] <crimsun> apparently he wants someone else to do the work, which is fine, but it likely won't happen for feisty.
[03:25] <rmjb> I know, the kernel is frozen solid...
[10:13] <rouzic> sacater: hi
[11:28] <anikras> hello
[11:28] <mrec> hi
[11:28] <mrec> can anyone have a look at: http://mcentral.de/pipermail/em28xx/2007-April/000213.html
[11:28] <anikras> howto i can have interface http://newbiedoc.sourceforge.net/system/kernel-pkg.html
[11:28] <mrec> is there any special patch in that ubuntu kernel regarding sysfs?
[11:29] <anikras> i have kernel 2.6.20
[11:29] <mrec> the same works with a vanilla <IP_ADDRESS> kernel
[11:29] <mrec> http://mcentral.de/pipermail/em28xx/2007-April/000220.html
[11:30] <mrec> the problem seems to occure when calling request_firmware()
[11:33] <sacater> rouzic: hi,
[11:33] <sacater> rouzic: check your email
[11:33] <sacater> i translated into espanol using google translate
[11:33] <rouzic> sacater: you speak spanish?
[11:34] <sacater> rouzic: nope
[11:34] <sacater> i only know 2 words
[11:34] <sacater> uno momento
[11:34] <rouzic> :)
[11:34] <sacater> im better in french
[11:34] <rouzic> uno is one
[11:34] <rouzic> momento is momment
[11:34] <sacater> yep
[11:34] <sacater> i know!
[11:34] <rouzic> :p
[11:35] <sacater> je parle parfait francais pour a
[11:35] <sacater> poissons
[11:36] <sacater> i speak perfect french for a fish*
[11:36] <sacater> :D
[11:36] <rouzic> no :(
[11:36] <rouzic> i don't speak frech
[11:36] <sacater> meh
[11:36] <rouzic> french*
[11:36] <sacater> im looking at that video now
[11:38] <sacater> rouzic: after reviewing you video, i have come to a conclusion
[11:38] <sacater> i dosnt like your wifi
[11:39] <sacater> it even complains in boot-up
[11:39] <sacater> oh, and like the poster
[11:39] <rouzic> sacater: Wanted! :p
[11:39] <rouzic> Clippo :p
[11:39] <sacater> yeh
[11:39] <sacater> right
[11:40] <sacater> simple what you have to do
[11:40] <sacater> disable your wireless adaptors
[11:40] <rouzic> :p
[11:41] <rouzic> sacater: But already it is deactivated
[11:41] <sacater> oh
[11:41] <sacater> thats pooey then
[11:42] <sacater> rouzic: my blog dosnt support indexing, can you put that video on youtube for us
[11:42] <rouzic> i don't have account in youtube
[11:42] <rouzic> wait
[11:42] <sacater> google videos?
[11:45] <rouzic> sacater: youtube
[11:49] <rouzic> sacater: i don't use youtube :(
[11:49] <rouzic> What do you think about the problem of the sound and the earphones?
[11:51] <crimsun> the what?
[11:57] <rouzic> crimsun: http://rouzic.net/files/sacater.tar.gz
[11:57] <rouzic> look this video ;)
[11:57] <crimsun> I can't play video here
[11:57] <crimsun> text files work best.
[12:03] <stgraber> rouzic: I've also had this bug, it's quite easy to fix
[12:03] <rouzic> stgraber: :p
[12:04] <sacater> Who controls the nvidia-glx development
[12:04] <sacater> ?
[12:05] <stgraber> Simply a broken /etc/network/interfaces, at boot time the networking script try to ifup all the interfaces and then start dhclient on an interface without anything connected, that takes a while till the timeout make the system continue booting
[12:05] <stgraber> cleaning the /etc/network/interfaces and removing everything but "lo" fix it
[12:05] <rouzic> command
[12:05] <rouzic> remove all?
[12:06] <stgraber> stgraber@laptop:~/sacater$ cat /etc/network/interfaces
[12:06] <stgraber> auto lo
[12:06] <stgraber> iface lo inet loopback
[12:06] <stgraber> NetworkManager now takes care of the rest, so simply keep those two lines is enough
[12:08] <rouzic> thanks stgraber
[12:08] <stgraber> np
[12:08] <rouzic> rebooting :)
[12:12] <rouzic_ausente> stgraber: THANKS!!! :)
[12:12] <stgraber> no problem :)
[12:13] <rouzic> stgraber: i have a problem with a sound
[12:13] <rouzic> wait a moment
[12:15] <rouzic> stgraber: http://rouzic.net/?q=node/37
[12:16] <rouzic> appears a red light where the earphones connect, and is not listened on
[12:16] <rouzic> having had the earphones put
[12:19] <stgraber> Did you try updating bootcamp ? (I've just read from a website talking about this issue with Windows)
[12:19] <stgraber> "I noted that the red light was also coming out when I used windows (bootcamp). I wasn't able to listen through my earphones, but after one of the bootcamp updates it was gone."
[12:20] <rouzic> stgraber: Only it spends to me in the kernel 2.6.20-14, before he was using 2.6.20-9 and was working correctly
[12:22] <stgraber> oh, I've maybe got a solution
[12:22] <stgraber> check if you can mute something like IEC958
[12:22] <stgraber> using alsamixer and the "m" key
[01:06] <rouzic> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/94055
[01:06] <rouzic> please, disabled the touchpad in the macbook :(
[04:50] <hyper_ch> hiho, I'm trying to setup dm-crypt and LUKS following a guide for debian but I already fail at step 6 (which I think is related to step 2 - altering the kernel options). It says to enable a few things if they aren't already but I don't know how to do that. Can anyone help me on that issue? Here's the guide:  http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian
[04:54] <hyper_ch> sorry, I just closed Kconversation :)
[05:40] <hyper_ch> help :)


[01:32] <wallyworld> axw: standup?
[01:33] <axw> oops
[01:33] <axw> wallyworld: brt
[02:41] <waigani> wallyworld: doc/hacking-state.txt:49 talks about mgo/txn's "transactions"
[02:41] <wallyworld> yeah, i read that way back when
[02:42] <waigani> but they are not really transactions?
[02:43] <waigani> just sets/slices of db opps ?
[02:44] <wallyworld> yep
[02:44] <wallyworld> that's how i see it
[02:45] <waigani> okay, just double checking
[02:45] <waigani> thanks
[02:45] <wallyworld> i guess each slice of ops is a txn
[02:45] <wallyworld> but there are limitations compared with what you might expect from using other dbs
[07:58] <dimitern> morning all
[08:02] <waigani> axw: can I bother you?
[08:03] <axw> waigani: yep?
[08:03] <axw> morning dimitern
[08:05] <hatch> hello all, has anyone ever run into a situation where juju-core (1.17.2 precise( thinks an environment is bootstrapped but can't destroy it because there are no instances? I tried removing the environments/ folder but no luck
[08:06] <axw> hatch: the provider-state file is probably in cloud storage
[08:06] <axw> what provider?
[08:06] <hatch> ec2, I'll take a look
[08:07] <waigani> axw: sync-tools. quick hangout?
[08:07] <axw> hatch: if it happens again, try destroy-environment --force
[08:07] <axw> waigani: sure
[08:08] <hatch> axw that was it! Thanks, I didn't know that it did that, I have been switching between trunk and devel a bunch so I wasn't sure if I broke something big :D
[08:08] <axw> no worries
[08:09] <axw> would be good to know why it happened, but that'd be difficult to figure out with no instances :)
[08:09] <hatch> I'll keep an eye open to see if it happens again
[08:10] <hatch> if the machines were destroyed out from under Juju (in the ec2 control panel) could that cause it?
[08:17] <axw> hatch: that would cause it I think, but I can't tell if that's *the* cause
[08:18] <hatch> well after I'm done doing what I'm doing I can give it a try...might not be until later int he week though :)
[08:20] <axw> no problems, thanks
[08:33] <hazmat> axw, fwiw filed some new manual provider issues over the weekend (https://bugs.launchpad.net/juju-core/+bugs?field.tag=manual-provider&orderby=-date_last_updated&start=0)
[08:34] <axw> hazmat: thanks, will take a look
[08:34] <hazmat> hatch, yanking the provider-state in control-bucket should do the trick, there's an outstanding bug for this issue. basically juju should sanity check the instance id in object storage.
[08:35] <axw> oy, I thought the reverse lookup was fixed
[08:35] <hazmat> hatch, https://bugs.launchpad.net/juju-core/+bug/1176961
[08:35] <hatch> ahhh thanks
[08:35] <hazmat> axw, hmm.. i was going back and forth from trunk to 1.17.2 .. that one might have been against 1.17.2
[08:35] <hatch> I had used --force
[08:35] <hatch> but good to know there is a known issue around this
[08:37] <axw> hazmat: nah there's still a lookup in there, just in a different spot from before
[08:40] <axw> hazmat: is https://bugs.launchpad.net/juju-core/+bug/1280432 on trunk?
[08:41] <hazmat> axw, yes, but your pending branches may address
[08:41] <axw> hazmat: https://bugs.launchpad.net/juju-core/+bug/1279259
[08:41] <axw> yeah
[08:41] <axw> ok
[08:41] <hazmat> axw, it looked like on upload-tools it was hardcoded to use ubuntu user before user was setup
[08:41] <hazmat> modifying it to use configured bootstrap-user resolved it for me.. your fixes look more comprehensive
[08:42] <axw> hazmat: what should happen is the ubuntu user gets initialised before any other ssh attempts are made; then ubuntu@ is hard-coded for everything else
[08:42] <axw> only the ubuntu user init should use bootstrap-user
[08:43] <hazmat> axw, i saw the logic, just not the reasoning, ie say we support centos ;-)
[08:43] <axw> heh
[08:47] <axw> hazmat: fwiw, the reasoning is: limit the number of times we request passwords from the user to one time during bootstrap
[08:47] <hazmat> axw, btw, i was able to use some of the recent manual feature api additions to give a slick demo, of creating 50 lxc containers as env machines in under a minute, all offline
[08:47] <axw> (once for ssh, once for sudo)
[08:47] <axw> nice :)
[08:47] <axw> oh, without apt-get stuff... very cool
[08:48] <hazmat> axw, it needs a little setup (base images, btrfs) but the core comes out to just being roughly 20 lines.. https://github.com/kapilt/juju-lxc/blob/master/juju_lxc/add.py#L29
[08:48] <hazmat> axw, yeah.. it  is pretty awesome, thanks :-)
[08:49] <axw> oo, I hadn't seen juju-lxc
[08:49] <axw> this looks like it'd be useful for my testing
[08:51] <hazmat> axw, yeah.. its what i do dev with.. its not really cleaned up for easy consumption though, hoping to push some of it to tim's push to make local provider moar awesome.
[08:51] <axw> hazmat: ah right, hence the talk of a plugin rather than local-specific.
[08:52] <hazmat> axw, yup.. burnt my free time hacking on making digital ocean manual plugin easily consumable.. curious where that goes... i'll clean up the lxc plugin next time around.. but back to client work for the next few weeks.
[08:53] <axw> enjoy ;)
[09:01] <rogpeppe> jam: standup?
[09:01] <jam> rogpeppe: yeah, 1:1 I was just making some lunch
[09:06] <dimitern> rogpeppe, it's a little early to be standing up :P
[09:21] <rogpeppe> dimitern: you're right, i'm sitting down
[09:36] <mattyw> rogpeppe, can you ping me when you're done? I've got questions/ need some help when you have a moment
[09:39] <dimitern> jamespage, ping
[09:40] <jamespage> dimitern, hello
[09:40] <dimitern> jamespage, did you get my last few messages?
[09:40] <dimitern> jamespage, hey
[10:00] <fwereade> axw, waigani: just responded to https://codereview.appspot.com/61520045/ -- thoughts?
[10:10] <waigani> fwereade: sorry dude, my only thought right now is that I can't keep my eyes open. I'll take a look in the morning.
[10:10] <fwereade> waigani, np, sleep tight :)
[10:32] <TheMue> fwereade: https://codereview.appspot.com/58510045/ is the current approach to debug-log, with support for local provider
[10:35] <fwereade> TheMue, nice coincidence, I literally just got to that point in the review queue, probably won't do it until after standup though
[10:36] <TheMue> fwereade: ok, have a new task where I have to read a lot first
[10:36] <fwereade> TheMue, cool :)
[10:47] <dimitern> rogpeppe, now's the time to stand up
[10:47] <dimitern> ;)
[10:50] <rogpeppe> wallyworld: are you coming back? we miss you!
[11:41]  * dimitern is out for 2h
[13:01] <rogpeppe> trivial code review anyone? https://codereview.appspot.com/65050043/
[13:01] <rogpeppe> (it just sorts all imports consistently throughout the code base)
[13:01] <rogpeppe> fwereade: ^
[13:10]  * fwereade looks
[13:11] <fwereade> rogpeppe, LGTM
[13:11] <rogpeppe> fwereade: thanks
[13:35] <fwereade> TheMue, half-reviewed https://codereview.appspot.com/58510045/ -- rogpeppe, would you take a look as well please?
[13:38] <TheMue> fwereade: thx
[13:43] <TheMue> fwereade: regarding the public or internal params if I ask two of you I get three opinions. :)
[13:44] <TheMue> fwereade: and all are one package, only different files. maybe a more general conceptual problem?
[13:45] <fwereade> TheMue, haha
[13:45] <fwereade> TheMue, what's the case for calling them internal?
[13:45] <fwereade> TheMue, IMO if we expose them over the public API they're, well, public
[13:46] <fwereade> TheMue, re files -- yeah, it's just convention I guess, but I think there's some value to spreading things out by file even if it's not compiler-enforced
[13:46] <TheMue> fwereade: I had it in public before
[13:48] <TheMue> fwereade: see https://codereview.appspot.com/58510045/diff/60001/state/api/params/params.go#newcode570 :)
[13:48] <fwereade> TheMue, cheers
[13:50] <fwereade> TheMue, I read that a bit differently to you, I think -- both the debug bits and the charms response should be in params, because they're both public api
[13:52] <TheMue> fwereade: So you mean it should be moved inside the internal.go file? Otherwise, what does "Also, please move this in internal.go, where ..." mean?
[13:52] <fwereade> TheMue, I think there was agreement in dimitern's second comment that they should both go in params, not internal
[13:53] <fwereade> TheMue, he said params is fine, but please more CharmResponse
[13:53] <fwereade> s/more/move/
[13:54] <TheMue> fwereade: OK, ic.
[13:54] <TheMue> fwereade: But I won't move CharmResponse as the refactoring of those two extra handlers should be an extra CL. This one is already too large.
[14:01] <rogpeppe> fwereade: i responded to some of your comments on  https://codereview.appspot.com/58510045/
[14:14] <TheMue> rogpeppe: your way of letting all providers explicitly set the log location is less convenient but sounds logical and save
[16:29] <dimitern> rogpeppe, hey, are you aware of the status of schema upgrades using the new upgrade framework?
[16:29] <rogpeppe> dimitern: mongo schema upgrades?
[16:29] <dimitern> rogpeppe, yep
[16:29] <rogpeppe> dimitern: i think they're planned for, but i don't know when
[16:29] <dimitern> rogpeppe, I know wallyworld did some work on upgrades in general, but is it usable?
[16:29] <rogpeppe> dimitern: it only covers upgrades to stuff on a given machine
[16:30] <dimitern> rogpeppe, hmm ok, so no schema upgrades yet
[16:30] <rogpeppe> dimitern: the upgrades doc talks about mongo schema upgrades, but there's quite a bit of stuff yet to design
[16:31] <dimitern> rogpeppe, i'm asking because of bug 1174610 which I've just fixed, but it involves some schema changes
[16:31] <_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1174610>
[16:32] <rogpeppe> dimitern: schema changes are essentially major-version upgrades
[16:32] <dimitern> rogpeppe, I'll propose it provisionally for now, pending what needs to be done re schema upgrades
[16:33] <rogpeppe> dimitern: how are you proposing to fix the problem?
[16:34] <dimitern> rogpeppe, by using the sequence collection for unit ids, as we do for pretty much all other ids (machines, containers, etc.)
[16:35] <rogpeppe> dimitern: so if you deploy wordpress, then deploy mysql, the first mysql unit is mysql/1 ?
[16:35] <dimitern> rogpeppe, no
[16:35] <dimitern> rogpeppe, the sequence name is "s#servicename#unit", so any service named "mysql" will have its units starting from 0
[16:36] <rogpeppe> dimitern: what happens now?
[16:36] <dimitern> rogpeppe, e.g. if you deploy wordpress as mysql, then add a unit, it will be mysql/0, then destroy the service and deploy mysql with name "mysql", add a unit - it will be mysql/1
[16:36] <dimitern> rogpeppe, now unit ids start from 0 for each service
[16:37] <rogpeppe> dimitern: ok, that's a little better
[16:37] <rogpeppe> dimitern: it feels a little bit like a hack to get around the fact that our *service* names aren't unique though
[16:37] <dimitern> rogpeppe, and apparently that's a regression from before, and some charms depend on using unit ids and them being unique
[16:38] <rogpeppe> dimitern: the problem is that some other charms might depend on having a unit 0.
[16:38] <rogpeppe> dimitern: (not that they should, of course)
[16:39] <dimitern> rogpeppe, if there are any, it's not mentioned
[16:44] <dimitern> hazmat, you'd be happy to know a fix for bug 1174610 is land very soon
[16:44] <_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1174610>
[16:44] <dimitern> rogpeppe, there it is https://codereview.appspot.com/64890044
[16:46] <dimitern> hazmat, s/is land/will land/
[16:48] <rogpeppe> dimitern: if it's not backwardly compatible without a schema change, i don't see how it can land
[16:49] <dimitern> rogpeppe, it is compatible i think
[16:49] <dimitern> rogpeppe, the problem is to update the sequences collection during the upgrade, so new units won't get ids starting from 0
[16:50] <rogpeppe> dimitern: exactly
[16:50] <rogpeppe> dimitern: it's a major-version issue
[16:51] <rogpeppe> dimitern: i'm wondering if there's a way to do it without the schema change
[16:51] <rogpeppe> dimitern: or, without needing to synchronously update the schema anyway
[16:54] <hazmat> dimitern, woot!
[16:56] <rogpeppe> dimitern: for example, when a service is created, you could mark it with a "uses global sequence numbering" flag
[16:56] <dimitern> rogpeppe, yeah?
[16:56] <rogpeppe> dimitern: when a service is destroyed that doesn't have that flag set, it could update the sequences collection with the most recent unit number for that service
[16:56] <dimitern> rogpeppe, isn't that a schema change as well?
[16:57] <rogpeppe> dimitern: when a unit is created, if allocates it from the service sequence number unless the "uses global sequence" flag is set
[16:57] <dimitern> rogpeppe, ah, one of those flags where false is default
[16:57] <rogpeppe> dimitern: yes
[16:57] <rogpeppe> dimitern: in that way, you can remain compatible with the old schema but update to the new schema over time
[16:57] <dimitern> rogpeppe, well, that could work, but how about service creation? we always create services with this flag=true
[16:58] <rogpeppe> dimitern: yes
[16:58] <dimitern> rogpeppe, ok, i'll look into it tomorrow, i'd appreciate these comments in the review please :)
[16:58] <rogpeppe> dimitern: so only legacy services will have that flag==false
[16:58] <rogpeppe> dimitern: ok, will do
[16:58] <dimitern> rogpeppe, ta!
[17:44] <jamespage> davecheney, btw a new gccgo-4.9 snapshot is working its way into trusty; I've rebuilt gccgo-go and juju-core using this new version
[17:44] <jamespage> its the default (gccgo -> gccgo-4.9)
[18:27] <rogpeppe> trivial code review, anyone? https://codereview.appspot.com/65160043/
[18:37] <mgz> rogpeppe: will look in a sec
[18:37] <rogpeppe> mgz: ta


[16:25] <RampartIT> Is there any status on what's going on with banjo.canonical.com?
[17:03] <sajoupa> RampartIT: there's an outage on one of our main mirror servers. We're working on it, sorry for the inconvenience.
[17:19] <GardinersBay> Seeing that on the main us.archive.ubuntu.com repo sajoupa
[18:25] <RampartIT> Thank you!


[13:18] <zyga> ogasawara, jjohansen: I was wondering if you had the time to look at that small MS_BIND patch I've posted earlier on IRC
[13:19] <rtg> zyga, you need to email it to<EMAIL_ADDRESS>[13:20] <zyga> rtg: thanks for the tip, will do
[13:20] <zyga> rtg: any suggestions on how to format the patch in gmail?
[13:20] <zyga> should the simple attachment work?
[13:21] <rtg> zyga, use 'git send-email'
[13:21] <zyga> okay
[13:21] <rtg> though an attachment ought to work as well
[17:16] <slangasek> jsalisbury: just fyi, the source package for grub in Ubuntu is grub2, not grub
[17:16] <jsalisbury> slangasek, ahh, ok.  must have made  a typo
[19:19] <Amis> Hello! I'm battling frequent OOMs. First OOM: http://pastebin.com/R1SfbBCu Nothing sticks out to me though I'm not an expert. What is the exact reason or source for the OOM? There seems to be plenty of RAM remaining. Is it fragmentation? Am I missing something here? (Ubuntu server 16.04 LTS, 8GB, 8 core, 4.4.0-59-generic)
[19:44] <jjohansen> zyga, ogasawara: yes I will look at it


[07:22] <Kilos> helloooo africa
[12:01] <MarwenDo> hi Kilos , how are u doing
[12:01] <Kilos> ok ty MarwenDo and you?
[12:01] <MarwenDo> Fine :)
[12:54] <Kilos> who is ashabadi


[00:21]  * JackyAlcine rolls in.
[04:37] <xiong> Hi, I'm not looking to start a debate but I'm searching for a way to disable Unity completely in favor of GNOME 2. I get many conflicting hits when searching.
[04:50] <kklimonda> xiong: we don't ship gnome2 anymore
[04:50] <kklimonda> xiong: you'd have to install MATE from some repository
[04:50] <xiong> kklimonda, Understood. For that matter, the GNOME people aren't shipping GNOME 2 anymore.
[04:51] <kklimonda> (MATE is a fork of GNOME 2)
[04:51] <xiong> I don't think I'll have trouble either installing MATE or disabling Unity. But I've learned humility and the wisdom of asking around.
[04:52] <kklimonda> disabling unity isn't hard, but I don't know how stable are MATE packages - the amount of work to fork G2 is astounding
[04:55] <xiong> Well, here I am between a rock and a hard place. If I'm going to jump hard, it's likely to be in favor of straight Debian running Xfce. I don't want to do anything rash.
[04:56] <xiong> erm...
[04:56] <xiong> Well, here I am between a rock and a hard place. If I'm going to jump hard,...
[04:57] <xiong> I'm going to try Unity but I'd like to cover my exit. I hope that's not offensive.
[05:00] <kklimonda> xfce seems like the best option if you want... experience similar to what you had with gnome 2
[05:01] <kklimonda> (I don
[05:01] <kklimonda> I don't give MATE more than 12 months before developers decide it's not worth it
[05:01] <kklimonda> the amount of work to be done is just too big to keep it going
[05:02] <kklimonda> so if you really want experience similar to gnome2 then Xfce seems like the best option
[05:02] <kklimonda> although I'd still give Unity a try, at least few weeks of using it every day
[05:02] <kklimonda> it may surprise you
[05:04] <xiong> I need more hardware. I have an older version of Ubuntu running and I'm bringing up a new machine to replace the older one. I should have two or three new machines so I can compare distros and working styles.
[05:05] <xiong> My fear is having to stick with the old machine for a long time while I fool around with the new one. Which will happen anyway.
[05:20] <xiong> Thanks for your comments, kklimonda. I'm downloading and it'll be awhile; so I'm headed out the door.
[05:53] <snadge> someone with some kind of authority/convincing powers pls make the case for adding dodge active windows back ;)
[05:53] <snadge> at least as a ccsm option
[05:54] <snadge> i dont care if the default is to always show the dock.. thats fine
[05:54] <snadge> but autohide kind of sucks
[11:05] <kklimonda> hmm, some of my apps are disappearing from alt-tab even when not minimalized - is there a bug about it?
[18:39] <Andy80> tomorrow is the beta1 day?
[18:50] <krnekhelesh> hello everyone
[18:50] <krnekhelesh> may I ask how do you sign up for the ayatana mailing list?
[18:51] <krnekhelesh> I tried finding links on launchpad page for ayatana but couldn't
[19:40] <Andy80> krnekhelesh: just a moment and I tell you
[19:40] <Andy80> krnekhelesh: the ML has been renamed to unity-devel or something similar wait...
[19:41] <Andy80> krnekhelesh: https://launchpad.net/~unity-dev
[19:53] <krnekhelesh> Andy80: ty
[21:42] <Andy80> just installed 12.04 on my Asus 1215P. uhm.... is it a known bug that when yoou are in the desktop and you go on the menu that appears on top and you try to click nothing happens?
[21:53] <mhall119> Andy80: I've not experienced that before
[21:54] <Andy80> and there is also a bad designed part
[21:54] <Andy80> in the top-left
[21:54] <Andy80> the X button is bad designed
[21:57] <Andy80> I'll provide some screenshots
[22:13] <mhall119> Andy80: please provide some mockups of what you think would be better
[22:14] <ppd> hi. maybe someone can clarify this. I'm testing precise and thus the latest unity on my multi monitor setup. Whenever I fullscreen an app, everything works nicely. However if that window looses focus, the launcher and panel reappear over the window. Is this the intended behaviour? I'm asking because the "normal" case of a fullscreen window for e.g  a movie player works just fine
[22:14] <Andy80> mhall119: I'm twitting the image right now, I'll give yuu the link
[22:15] <Andy80> mhall119: here you have https://twitter.com/#!/andreagrandi/status/171357025547198464/photo/1
[22:15] <Andy80> mhall119: as you can see the X button in the top-left is not well designed, it's clearly a regression
[22:16] <Andy80> maybe I could know why.... let me give a try... wait..
[22:18] <Andy80> uhm.... no, no success.. since I'm using an icon size of 36 I tried resetting to 48 but I still have the same problem
[22:20] <mhall119> Andy80: file a bug on Launchpad and attach your image so the Unity developers will see it tomorrow
[22:21] <mhall119> Andy80: what exactly is wrong with the close button?
[22:21] <Andy80> mhall119: uhm.... can't you see it, really?
[22:22] <Andy80> the orange circle of the X window button
[22:22] <Andy80> is not a circle
[22:22] <Andy80> it has at least 3 or 4 pixel in the left side more
[22:22] <Andy80> maybe I should enlarge the image...
[22:22] <mhall119> Andy80: ok, I wasn't sure if that was a jpg compression artifact or what you actually saw
[22:23] <mhall119> FWIW, I don't see that on mine, so it's not the way it should look
[22:23] <Andy80> if you zoom the pic you can see it
[22:23] <mhall119> yeah, I see it now
[22:27] <Andy80> just a note: it's not a clean installation, I upgraded from 11.10, but I had installed 11.10 few days ago, I didn't customize anything except setting the icon size to 36 and keeping the Launcher always visible
[22:28] <Andy80> how is the correct name for a similar bug? "UI glitch" ?
[22:30] <Andy80> mmm.... I see the more texts have the same problem
[22:30] <Andy80> for example pressing "Super" key, and showing the help, every word is "bolded" in the left part of the first character