[09:37] <lordievader> Good morning.
[12:12] <BluesKaj> Hey all
[20:09] <daftykins> Jordan_U: mmm, by offering to help that user with their old hardware and releases too new / unapt for said hardware, it's undoing all the time i put in to point toward a sensible approach
[20:09] <daftykins> but ah well, i'm sure you have the time to guide them the full way with that course of action :)
[20:14] <Jordan_U> daftykins: There is still a driver for their hardware in the latest releasea of Ubuntu, I see no reason to expect that it can't be made to work.
[20:14] <daftykins> by that are you talking about radeon?
[20:15] <Jordan_U> daftykins: The negligent action is using an EOL release and possibly becoming a part of a botnet.
[20:16] <daftykins> ok well to spare you some time, it seems they're trying to make use of gnome 15.10 - so that means they're trying to use 3D apps on a DE that's already too much for a probably flakey open source driver
[20:16] <Jordan_U> daftykins: I don't know yet, I was hoping to determine that from the contents of their Xorg.0.log.
[20:16] <daftykins> thus the advice many times over of installing 14.04 lubuntu :)
[20:16] <daftykins> a second install was MATE on something else, but that didn't seem ideal either
[20:17] <daftykins> well it's not going to be fglrx for that card due to legacy status afaiui
[20:17] <daftykins> anyway, i shall hush
[20:17] <Jordan_U> Using LXDE/XFCE seems like an obvious choice, but their screenshot was showing graphical corruption in a 3D house layout app.
[20:20] <daftykins> yeah, screenshot in Mate also, probably Mint given the last comment too
[20:20] <daftykins> that user is impossible, i give up.
[20:30] <BluesKaj> i figured he was a troll when he replied to my tutorial post theit wasn't in his orbit....what?
[20:30] <BluesKaj> that it
[20:31] <daftykins> :D
[20:34] <BluesKaj> also could be a langauge/communication problem, he's in Nigeria
[20:38] <BluesKaj> ok time to close up shop for today.... take care gents
[20:41] <daftykins> heh well said


[09:31] <lool> ojn: I don't have info on the different DIP switches, albeit I expect them to be similar to babbage boards; I have access to babbage board info but it's inconvenient for me right now, and I have access to people with pegatron boards too
[09:32] <lool> I could look at this next week
[09:32] <lool> ojn: Would you mind pining JamieBennett / ogra on this topic?  They are both related to this kind of projects more than I am
[15:46] <ojn> lool: thanks, will do


[16:29]  * Mi` is away: Stripping and stuff
[16:31]  * Mi` is back (gone 00:01:50)
[16:31]  * Mi` is away:


[01:27] <profiler1982> join /elementary
[10:14]  * vladap is back (gone 00:01:28)
[10:15]  * vladap is away: off time


[01:31] <micahg> http://feedproxy.google.com/~r/GoogleChromeReleases/~3/l4YdTYhkmFU/dev-channel-update_17.html, nice
[09:37] <dpm> hey chrisccoulson, good morning. Do you think you could have a look at bug 542046 and merge the Traditional Chinese translation for ubufox?
[09:37] <ubot2> Launchpad bug 542046 in ubufox "Translation for zh_TW" [Undecided,In progress] https://launchpad.net/bugs/542046
[09:47] <chrisccoulson> dpm - sure. i'm just preparing for the first ff5.0 beta atm though
[10:04] <dpm> chrisccoulson, thanks. Yeah, no worries, it's not urgent, but I just wanted to give you a heads up, as the Chinese team pinged me to ask what was going on with their translation
[20:56] <m_conley> chrisccoulson: ping
[20:56] <chrisccoulson> hi m_conley
[20:56] <m_conley> chrisccoulson: hello!  Any chance of getting unitylauncher-extension in the PPAs today?
[20:57] <chrisccoulson> hi m_conley, perhaps not today. it's getting late here,and i've been busy preparing to upload the first firefox 5 beta
[20:57] <m_conley> chrisccoulson: alright. tomorrow then?  Also, what is required in order to get the appropriate quicklist entries into the .desktop file?
[20:58] <chrisccoulson> m_conley, i can do that. do the entries depend on the extension being installed too?
[20:58] <m_conley> chrisccoulson: no, not at all.
[20:58] <m_conley> chrisccoulson: I'm sure those entries would make many TB users very happy.  :)
[20:58] <chrisccoulson> m_conley, is the extension using a binary component too? (i can't remember now)
[20:58] <m_conley> chrisccoulson: no - actually, I recently updated it, and started using your LibUnity.jsm for it.
[20:58] <m_conley> chrisccoulson: I hope that's alright. :)
[20:58] <chrisccoulson> oh, cool :)
[20:59] <m_conley> chrisccoulson: so no compilation required.
[20:59] <chrisccoulson> that's good
[21:04] <chrisccoulson> m_conley, when are we going to start getting miramar beta builds? :)
[21:05] <m_conley> chrisccoulson: soon-ish - best to ask Standard8
[21:05] <chrisccoulson> m_conley, cool. i may as well put that in oneiric too
[21:09] <m_conley> chrisccoulson: excellent. :)
[22:14] <fta> chrisccoulson, are you on oneiric now?
[22:33] <BUGabundo> evening


[07:06] <ppisati> morning *
[13:29] <bjf> moin
[14:17]  * ogasawara back in 20
[15:13] <ogasawara> tgardner: bug 867679 - while you're at milbank, can you get a hold of clan's Thinkpad X200s and see if she's still having networking issues after suspend/resume
[15:13] <ubot2> Launchpad bug 867679 in linux "Network fails after suspend/resume" [Undecided,Incomplete] https://launchpad.net/bugs/867679
[15:13] <ogasawara> tgardner: I'm unable to reproduce here with a similar wifi card and I found another person who has an X200s and no issues either.
[15:13] <tgardner> ogasawara, I'm pretty sure she's not here.
[15:14] <ogasawara> tgardner: dammit, that's right, nm
[15:50] <brendand> bjf, sconklin - i appended a link to my notes from friday's brainstorm to the blueprint summary. if you want to have a look
[17:17] <LLStarks> hi. anyone want to help me trace a panic when using 3.1-rcX?
[19:38] <ppisati> :)


[07:25] <bassem> fenris-unity,
[08:46]  * bassem Upgrading the laptop to Natty
[08:58] <hadenx> Hello bassem, xnixan ,fenris-unity
[08:58] <bassem> hadenx, morning
[09:00] <bassem> hadenx, now it's good afternoon
[09:02] <hadenx> bassem,just realized that .. :)
[09:02] <hadenx> Omar didn't get back on the pizza plans ..
[09:03] <bassem> hadenx, so it's like that last time!
[09:03] <hadenx> We might just meet up for coffee...
[09:07] <bassem> hadenx, today you mean?
[09:07] <hadenx> bassem ,Yes.. The meetup is today right ?
[09:08] <bassem> hadenx, yeah! are you coming ?1
[09:09] <hadenx> Yes.. Ill be there ...
[09:14] <bassem> hadenx, who else? xnixan !!!
[09:15] <hadenx> bassem, from irc I think only bojicas will show up..
[09:39] <Toki> Hey guys, I need help regarding my waterlogged laptop, any of you have experience in such cases?
[09:40] <Toki> xnixan, Haden, bassem.
[09:41] <bassem> Toki,
[09:41] <Toki> Yes, bassem?
[09:41] <bassem> remove the battery
[09:41] <Toki> Battery's removed.
[09:42] <bassem> let it dry
[09:42] <Toki> Been drying since last night.
[09:43] <Toki> Another thing bugging me is that Sharjah's water are quite noticeably saltier. :/
[09:43] <bassem> Toki, not enough!
[09:43] <Toki> bassem: How long?
[09:43] <bassem> put it in dry and warm place
[09:43] <bassem> 2 or 3 days
[09:44] <bassem> and pray!
[09:44] <Toki> Can't do anything about warmth, but yeah it's a dry place.
[09:44] <Toki> Pray?! Not definete of it working again?
[09:44] <bassem> Toki, what about the sun!
[09:44] <Toki> Bassem, even balcony doesn't get too much sunlight.
[09:45] <Toki> And it's sandy all around (industrial area).
[09:46] <Toki> bassem: Is there anywhere I can buy distilled water?
[09:46] <bassem> Toki, no idea!
[09:46] <Toki> bassem: Salty water, eternal death chance increase. :'(
[09:47] <Toki> I need some compressed air as well, did not find in Mirdif City Centre yesterday.
[09:49] <Toki> By the way, how safe is it to clean desktops with water? On UF, quite a few people has apparently done it.
[09:49] <Toki> Welcome, fenris-unity!
[12:00] <bassem> bojicas, coming today?
[12:00] <bojicas> hi. yes, i'll be there
[12:01] <bojicas> bassem, what about you?
[12:01] <bassem> bojicas, yeah sure!
[15:02] <bassem> Haden, xnixan , move!
[16:33] <bassem_mobile> hi ejat- !
[17:21] <xnixan> bassem_mobile, LOL
[17:21] <bassem_mobile> xnixan: what?
[17:21] <xnixan> @ xnixan  move!
[17:22] <bassem_mobile> xnixan: and you didn't ?!!
[17:23] <xnixan> bassem_mobile, LOL again
[17:23] <xnixan> bassem_mobile, how are you?
[17:24] <bassem_mobile> xnixan: fine
[17:24] <bassem_mobile> xnixan: you?
[17:33] <bassem_mobile> xnixan:
[17:33] <bassem_mobile> nlsthzn:
[17:35] <nlsthzn> bassem_mobile: hello
[17:35] <bassem_mobile> nlsthzn: hey
[17:35] <nlsthzn> Good meeting?
[17:36] <bassem_mobile> nlsthzn: i don't know!
[17:39] <xnixan> bassem_mobile, yep!
[17:39] <bassem_mobile> xnixan: how are you?
[17:39] <nlsthzn> guess we have to wait from those that attended then
[17:40] <bassem_mobile> nlsthzn: define "Good" !
[17:40] <bassem_mobile> xnixan: we are talking about you right now!
[17:41] <xnixan> bassem_mobile, i am fine, thaks
[17:49] <xnixan> bassem_mobile, about what?
[17:50] <bassem_mobile> xnixan: sponsorship!
[17:50] <xnixan> bassem_mobile, very well
[17:50] <xnixan> bassem_mobile, but i did not get any reply till now!
[17:50] <xnixan> bassem_mobile, i was dreaming to host this month meeting!
[17:50] <bassem_mobile> cause you didn't attend!
[17:51] <xnixan> bassem_mobile, wow!
[17:51] <bassem_mobile> xnixan:
[17:51] <bassem_mobile> why you didn't attend?
[17:51] <xnixan> bassem_mobile, should'nt be at 6th
[17:52] <bassem_mobile> xnixan: ?!!
[17:52] <xnixan> bassem_mobile, i think, it confuses me with dubai tech nights!
[17:53] <bassem_mobile> xnixan: man it's today! right now!!
[17:53] <xnixan> bassem_mobile, :(
[17:54] <bassem_mobile> xnixan: if you were member of meetup, you will receive a notification
[17:54] <xnixan> bassem_mobile, i am
[17:54] <bassem_mobile> xnixan: !
[17:55] <xnixan> bassem_mobile, and i know it is in festival city!
[17:55] <xnixan> bassem_mobile, but i thought it will be tomorrow!
[17:55] <bassem_mobile> xnixan: next time isa
[17:55] <xnixan> bassem_mobile, isa
[17:56] <bassem_mobile> xnixan: omar is next to me, do you want me to tell him anything?
[17:56] <xnixan> bassem_mobile, sure!
[17:56] <bassem_mobile> xnixan: ?
[17:56] <xnixan> bassem_mobile, i have his business card, and i called him on the number mentioned there
[17:56] <nlsthzn> hehe...
[17:57] <bassem_mobile> xnixan: he said that he got voice mail from you
[17:57] <xnixan> bassem_mobile, i also left for him voice mail, but i did not get any reply
[17:57] <xnixan> bassem_mobile, hehe
[17:57] <xnixan> bassem_mobile, ok, then what?
[17:58] <bassem_mobile> xnixan: what?
[17:58] <nlsthzn> xnixan: say hi from me to all attending :p
[17:58] <xnixan> nlsthzn, 10000000^10000000 hi for you
[17:58] <bassem_mobile> nlsthzn: no, i will not do it!
[17:59] <nlsthzn> bassem_mobile: nobody asked you to do anything
[17:59] <nlsthzn> :p
[17:59] <bassem_mobile> ok
[18:00] <xnixan> bassem_mobile, anyway good luck to all of you
[18:00] <bassem_mobile> xnixan: so what to tell omar?
[18:00] <xnixan> bassem_mobile, tell them all i am really sorry that i missed that meeting
[18:01] <xnixan> bassem_mobile, i had already applied on the meetup site,for the sponsorship!
[18:01] <xnixan> bassem_mobile, did not he check it?
[18:01] <bassem_mobile> let me ask him
[18:01] <xnixan> bassem_mobile, ok
[18:02] <bassem_mobile> xnixan: he said yes he saw it
[18:02] <bassem_mobile> and we need to dicuss it
[18:02] <bassem_mobile> all
[18:03] <nlsthzn> bassem_mobile: oh, I got mixed up... your at the meeting now and xnixan missed it?
[18:03] <bassem_mobile> nlsthzn: yes
[18:03] <xnixan> nlsthzn, yes!
[18:03] <nlsthzn> bassem_mobile: hehe, my bad... please say hi to all attending please... and wish I could be there...
[18:04] <bassem_mobile> nlsthzn: no, i will not do it!
[18:04] <bassem_mobile> :-p
[18:04] <xnixan> bassem_mobile, tell him that he is most welcome, to come and discuss it, or if he wish, i will meet him!
[18:05] <xnixan> bassem_mobile, and if he can come with any number for the group, i will be my pleasure, and the management in Al Ahli too!
[18:06] <bassem_mobile> xnixan: he will call you tomorrow and prepare a small meeting!
[18:06] <xnixan> bassem_mobile, very good!
[18:06] <nlsthzn-work> bassem_mobile: where us your spirit of Ubuntu? :)
[18:06] <xnixan> nlsthzn-work, :)
[18:07] <bassem_mobile> nlsthzn-work: you are not human, you live in rwuais and use windoz!!!
[18:07] <xnixan> nlsthzn-work, it that true???
[18:08] <nlsthzn-work> I am on Windows at the moment at work, and I do use windows on my desktop to play games, I am running Kubuntu on my laptop and have openSUSE on my netbook however...
[18:14] <nlsthzn-work> ... not that I have to explain myself to anybody come to think about it :/
[18:15] <xnixan> nlsthzn-work, you have already done :p
[18:16] <xnixan> bbl
[18:55] <Haden> Hey guys..
[18:58] <bassem_mobile> Haden: hey man! did you reach home?
[19:04] <Haden> bassem_mobile,  Yes...
[19:04] <Haden> 10 mins back...
[19:06] <Haden> hello ejat-
[19:10] <bassem_mobile> Haden: i just left
[19:11] <bassem_mobile> Haden: i need 1 hour to be at home!!!
[19:11] <bassem_mobile> you live in ikea?
[19:19] <Haden> bassem_mobile, Lol.. I wish.. I live somewhere near festival city though.. takes me 10 mins..
[19:20] <bassem_mobile> Haden: great! so festival city is best meeting place for you!
[19:22] <Haden> bassem_mobile,  Well I got home by Taxi.. so I had to pay 20 bucks...
[19:22] <Haden> I came by Metro.. took me almost an hour..
[19:22] <bassem_mobile> Haden: 20 bucks!!! wow
[19:23] <bassem_mobile> i've took taxi to deira city center and then metro!
[19:23] <bassem_mobile> taxi costs me 12 only
[19:30] <Haden> bassem_mobile, I thought you stay in marina...
[19:31] <bassem_mobile> Haden: yes i'm in marina
[19:31] <bassem_mobile> i'm on my way now
[19:31] <Haden> bassem_mobile,  Sorry.. my bad.. got confused..
[19:32] <Haden> bassem_mobile, Install natty on my friends laptop... core dupo 1 gb ram, intel graphics.. really slow.. :(
[19:32] <bassem_mobile> Haden: we didn't discuss the party!
[19:33] <Haden> bassem_mobile, I had asked Omar.. I thought he would've have planned.. we can discuss something next IRC meet..
[19:52] <nlsthzn-work> Haden: with those specs even natty should be fast


[01:17] <damien_> hey
[02:05] <damien_> i have a relatively old laptop that has a p4 3ghz processor, 512mb of ram (it's an advent 7027) but playing flash videos is very laggy and after playing them for a while end up using 100% cpu and being unwatchable
[02:06] <damien_> any idea if this is something i can fix?


[00:41] <mup> PR snapcraft#1929 closed: sources: proper errors for invalid handlers <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1929>
[00:44] <mup> PR snapcraft#1942 opened: Release changelog for 2.39.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1942>
[01:05] <elopio> snappy-m-o autopkgtest 1926 xenial:armhf xenial:amd64 xenial:arm64
[01:05] <snappy-m-o> elopio: I've just triggered your test.
[01:52] <elopio> snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64
[01:52] <snappy-m-o> elopio: I've just triggered your test.
[03:39] <hego555> yo guys, my snaps seem to not have any internet connection... Spotify says no internet connection and so does Writefull
[03:40] <hego555> i made sure the network plug was enabled
[04:41] <sergiusens> snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf
[04:41] <snappy-m-o> sergiusens: I've just triggered your test.
[04:42] <mup> PR snapcraft#1943 opened: Release/2.39.2+18.04 (DO NOT MERGE) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>
[06:07] <mborzecki> morning
[06:24] <mborzecki> mvo: morning
[06:24] <mvo> hey mborzecki ! good morning
[06:25] <mborzecki> mvo: i noticed this in one of the travis jobs: https://paste.ubuntu.com/p/qYKjfqYdxF/ is this the restart on refresh mode thing?
[06:27] <mvo> mborzecki: yes - looks like a race, do you have the full log? there should be logging to syslog around this to help tracking this down
[06:28] <mborzecki> mvo: https://api.travis-ci.org/v3/job/343470218/log.txt
[06:35] <mvo> mborzecki: hm, hm, the log looks ok, the right restart reason and all that. puzzling
[06:38] <mborzecki> mvo: maybe the log comes from before the actual test action happened?
[06:39] <mvo> mborzecki: yeah, I wonder why
[06:41] <mborzecki> mvo: backend calls systemd.Restart(), that's implemented as stop & start
[06:43] <mvo> mborzecki: oh, thats an interessting clue, a restart with no restart reason. when is backend calling this?
[06:44] <mborzecki> mvo: i believe the path is ifacestate.setupSnapSecurity() -> backend.Setup() -> systemd.Restart()
[06:46] <mvo> ta
[07:45] <mborzecki> mvo: do you need any help with that issue?
[07:46] <mvo> mborzecki: help would be great, I'm still fighting with the 2.31.1 stable release and the oom error and the autopkgtests
[07:47] <mborzecki> mvo: oom error? you got me interested now
[07:47] <mvo> mborzecki: on bionic/i386 the interfaces-many tests triggers an oom error
[07:47] <mvo> mborzecki: its not a new bug, I can reproduce it with 2.29.x too
[07:48] <mvo> mborzecki: but its very unclear right now what is causing it
[07:48] <mvo> mborzecki: its reliable to reproduce on i386
[07:49] <mborzecki> mvo: is snapd getting killed?
[07:50] <mvo> mborzecki: everything is getting killed :) its also strange as htop does not show any user space grwoing like mad. also the swtich from ok(ish) to oom comes very fast
[07:50] <mvo> mborzecki: http://paste.ubuntu.com/p/gVgDtTqPBg/ this is the script
[07:51] <mvo> mborzecki: I can prepare a tar that includes the two snaps to run this
[07:53] <mborzecki> mvo: no need, if they are in tests/lib/snaps i can build them myself
[07:54] <mvo> mborzecki: I will do it anyway I think because I want to run it on an amd64 and compare the logs. it seems like th eoom condition is not triggered there
[07:54] <mvo> mborzecki: might be kernel, might be udev
[07:55] <mvo> mborzecki: each connect seems to take in the range of 12mb
[07:55] <mvo> mborzecki: it could be apparmor too, we load profiles on each connect
[07:55] <mborzecki> mvo: wow, that's a lot
[07:55] <mvo> mborzecki: well, thats what "free" tells me, its not clear (to me yet) where this memory actually goes
[07:56] <mborzecki> mvo: i'll try to play with pprof, see if anything comes up
[07:57] <mborzecki> mvo: there's a bunch of maps flying around in the code, also we may be collecing some output from processses that we run
[08:00] <mvo> mborzecki: my gut feeling is that its external to snapd, we need more data, but afaict this is fine on xenial/i386
[08:01] <mborzecki> mvo: interesting, is ti possible to say, disable apparmor and not call apparmor_parser?
[08:01] <mvo> mborzecki: yeah, that might be worth a shot
[08:02] <mvo> mborzecki: its puzzling, free telle me I have "479404" used and "784648" free - thats confusing (but memory reporting apparently is)
[08:03] <mvo> mborzecki: I also see a lot of kmalloc-8192 in slab-info
[08:03] <mvo> mborzecki: the objects there grow from 500 to 5000
[08:03] <mvo> (which is still not that much in total memory size about 40mb)
[08:06] <pstolowski> mornings
[08:09] <mvo> mborzecki: my current theory is that for some reason "normal" memory runs out on i386. there is plenty of "highmem" free but the normal memory falls below the threshold of 20mb
[08:10] <mborzecki> pstolowski: morning
[08:10] <mvo> hey pstolowski ! good morning
[08:12] <pstolowski> mvo, heya, is this re to the 'killed...' issue on connect from yesterday?
[08:15] <mvo> pstolowski: yes
[08:16] <pstolowski> interesting
[08:17] <mup> PR snapd#4676 closed: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4676>
[08:20] <mborzecki> mvo: hm the test only connects the interfaces, so maybe temporarily linking apparmor_parser to /bin/true would allow to skip this path if that's what you suspect
[08:23] <mborzecki> pstolowski: if you're up for reviews https://github.com/snapcore/snapd/pull/4695 needs looking at :)
[08:23] <mup> PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
[08:26] <mborzecki> mvo: xenial i386 vm is updating, meanwhile i'll look at refresh mode thing
[08:26] <pstolowski> mborzecki, sure!
[08:26] <mborzecki> pstolowski: great, thanks :)
[09:02] <mvo> mborzecki: I will write a forum post in a wee bit that summarizes my current findinds
[09:05] <sergiusens> snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64
[09:05] <snappy-m-o> sergiusens: I've just triggered your test.
[09:06] <Chipaca> sergiusens: morning! (?)
[09:06] <sergiusens> Chipaca: intermittent, just woke up to trigger these darn tests :-)
[09:12] <sergiusens> snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf
[09:12] <snappy-m-o> sergiusens: I've just triggered your test.
[09:31] <mup> PR snapd#4708 opened: overlord/snapstate: use spread in the default refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
[09:36] <mborzecki> mvo: so no apparmor no leak?
[09:37] <mvo> mborzecki: thats what it looks like to me at least
[09:39] <mborzecki> that's interesting observation
[09:39] <mborzecki> , udev/seccomp/cgroups is all there right?
[09:39] <mvo> mborzecki: yes, I just disabled this one
[09:42] <mup> PR snapd#4709 opened: tests: fixes for autopkgtest in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4709>
[09:43] <mborzecki> mvo: can you try with something more recent, like 4.15.4?
[09:43] <mborzecki> mvo: i mean the kernel ofc
[09:47] <mvo> mborzecki: yeah, I am preparing a more automatic thing now
[09:48] <mvo> mborzecki: I mean a tarfile so that one can just run ./test.sh
[09:48] <mvo> mborzecki: and then I can test on more systems (artful etc) to see when it started
[09:49] <mborzecki> mvo: i did not observe any issues on xenial, but that's a really old kernel
[09:51] <mvo> mborzecki: interessting
[09:53] <mborzecki> mvo: https://paste.ubuntu.com/p/bWVBw4Yp6v/
[09:53] <mborzecki> LowTotal:         858144 kB
[09:53] <mborzecki> LowFree:          723696 kB
[09:53] <mvo> mborzecki: this is xenial?
[09:54] <mborzecki> mvo: yes
[09:55] <mvo> mborzecki: it seems to have a different lowmem split
[09:55] <mvo> mborzecki: i.e. more available (my system only had ~400mb)
[09:55] <mvo> mborzecki: is it also shrinking fast?
[10:02] <mvo> mborzecki: same here, no craziness on 16.04-32
[10:03] <seb128> mvo, hey
[10:03] <seb128> mvo, can you help us? andyrock needs some input on changes he would like to suggest for snapd that he needs for his livepatch work
[10:04] <mborzecki> mvo: https://imgur.com/a/xDeVR
[10:04] <mvo> seb128: sure, what kind of changes does he have in mind?
[10:04] <mborzecki> mvo: the test script stars around 20s mark
[10:05] <andyrock> mvo: so we need to login  in snapd from the installer. The problem is that we can't talk with the to-be-installed snapd in ubiquity
[10:06] <andyrock> mvo: the chroot hack does not work (in a nutshell the chroot is not ready when we need it)
[10:06] <mvo> mborzecki: what is the y axis?
[10:06] <mborzecki> mvo: kB, LowFree
[10:06] <mvo> mborzecki: ta
[10:06] <andyrock> mvo: would be possible to have a way to seed the auth state? something like this: https://paste.ubuntu.com/p/sSbKstQ2Sy/
[10:08] <mvo> andyrock: interesting! pedronis, what do you think about the ability to put auth.json into the seed directory and import it on firstboot? this is for the desktop installer use-case
[10:10] <pedronis> mvo: I'm a bit missign the context
[10:11] <andyrock> pedronis: I've been asked to add snapd login in the installer
[10:11] <mvo> pedronis: they allow people to login into the store/snapd in the livecd session. but the snapd that is running in there is not the snapd that is copied to the hardisk. the harddisk snapd will have an empty state.json
[10:11] <mvo> pedronis: so the user would have to login again after the system was installed
[10:13] <pedronis> what is that auth.json?  the  one from the homedir?
[10:13] <pedronis> or something else
[10:13] <andyrock> something else
[10:13] <pedronis> the one in the homedir doesn't have all the data
[10:13] <andyrock> something we need to take from the livecd state.json
[10:14] <andyrock> we can take all under auth: {...}
[10:14] <pedronis> no you don't want everything
[10:14] <pedronis> because there's device info there
[10:14] <andyrock> kk
[10:14] <pedronis> and I think we are trying not to make livece session count the same wa
[10:14] <pedronis> as full installs
[10:18] <andyrock> pedronis: so last-id, users, and macaroon-key?
[10:18] <andyrock> or last-id and users are enough?
[10:27] <pedronis> andyrock: you need the macaroon-key as well, if you plan to port ~/.snap/auth.json over or the gnome-software equivalent
[10:27] <andyrock> kk
[10:28] <andyrock> pedronis: so are you willing to accept something like that?
[10:28] <pedronis> maybe, is not just my decision
[10:29] <pedronis> it needs also to be a bit more paranoid about checking the perms of that file
[10:29] <andyrock> kk who else should we ask?
[10:31] <pedronis> you need niemeyer +1 as well
[10:33] <pedronis> I'm mildly worried that it allows to clone the same creds on a lot of images, it's not your use case but it can be used that way
[10:36] <andyrock> pedronis: should we move the discussion the forum?
[10:36] <andyrock> *in the
[10:37] <pedronis> yes
[10:37] <pedronis> you should make a proposal there I suppose
[10:49] <mvo> pedronis, andyrock another option might be to join the standup as a guest
[10:50] <zyga_> o/
[10:50] <zyga_> I'm sick and I won't be around today
[10:50] <zyga_> I just got off the bed to let you guys know
[10:50] <zyga_> sorry about that :/
[10:50] <mvo> zyga_: get well
[10:50]  * mvo hugs zyga_
[10:50] <zyga_> thank you, I be back as soon as I can
[10:51] <mup> PR snapd#4704 closed: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4704>
[11:09] <mvo> mborzecki: fwiw, artful seems to show the same behavior
[11:10] <magicaltrout> random question, is there a pattern for dealing with migrating configs and stuff on a snap package upgrade?
[11:11] <magicaltrout> or do you just bake something into the start script?
[11:15] <popey> mvo: I'm told there's a PR in flight somewhere which will enable a snap (like gnome-calculator) to auto-download & install a platform snap (like the gnome one). Do you know what stage that's at?
[11:15] <mvo> popey: that is #4103
[11:15] <mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
[11:16] <mvo> popey: we want to get it in for 2.32, its a bit hard because there is some work to do still but its super important to us
[11:16] <popey> mvo: excellent, thanks.
[11:16] <popey> Yes, that would be awesome.
[11:32]  * pstolowski lunch
[11:35] <mborzecki> mvo: that problem with test-snapd-service endure, the only idea i have atm is that we do journalctl --rotate, but no journalctl --sync, if a test using test-snapd-service was run before that one, we could end up with a log from the previous run
[11:36] <mvo> mborzecki: interessting, that sounds like a good theory
[11:37] <mborzecki> funnily enough, looking at the source code of journalctl, you cannot use `journalctl --sync --rotate` in a single command, both flags are set to the same variable
[11:45] <mup> PR snapd#4710 opened: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4710>
[11:46] <mborzecki> mvo: ^^ a simple fix for now, let's see if this is enough
[11:46] <mup> PR snapd#4709 closed: tests: fixes for autopkgtest in bionic <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4709>
[11:47] <mvo> mborzecki: \o/
[12:00] <Chipaca> mborzecki: mvo: #4708 gtg
[12:00] <mup> PR #4708: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
[12:02] <mup> PR snapd#4708 closed: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
[12:07] <mvo> Chipaca, mborzecki thanks, cherry-picked into 2.31.1
[12:09] <cachio> mvo, hey
[12:10] <mvo> hey cachio
[12:10] <cachio> test-snapd-hello-classic in the store for s390x, stil waiting a review
[12:10] <cachio> mvo, updating the kernel in the qemu machine
[12:10] <mvo> cachio: aha, cool, I can do that after lunch
[12:30] <cachio> mvo, same issue with an old kernel
[12:30] <mborzecki> cachio: oom?
[12:31] <cachio> mborzecki, yes
[12:32] <mborzecki> cachio: how much ram are those vms getting?
[12:32] <cachio> mborzecki, well, I could not connect anymore
[12:32] <cachio> mborzecki, 3500 MB
[12:34] <mborzecki> cachio: tried this today on 16.04 32bit, with -mem 4096 and haven't observed any issues, lowmem did drop a bit though, see ~20s mark https://imgur.com/a/xDeVR
[12:36] <cachio> mborzecki, I ran some scripts yesterday and it is like in 18.04 i386 the garbage collections is not done
[12:37] <cachio> so you connect disconnect and do stuff and the memory is not release
[12:37] <cachio> d
[12:40] <mborzecki> cachio: can you try to collect this `while true; do echo "$(date +%s) $(awk '/LowFree/ {print $2}' < /proc/meminfo)"; sleep 1; done` while the test is run and paste is somewhere?
[12:40] <cachio> mborzecki, sure
[13:05] <cachio> mborzecki, https://paste.ubuntu.com/p/JTBkvh5PqN/
[13:14] <mborzecki> hmm it's really low to begin with
[13:21] <Chipaca> jdstrand: ping
[13:22] <jdstrand> hey Chipaca
[13:22] <Chipaca> jdstrand: pm
[13:23] <mvo> jdstrand: hey, https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 might be interessting for you guys, I suspect it is apparmor related (but maybe not)
[13:25] <sergiusens> stgraber: hi there, was wondering if there is a probe command in lxd to figure out that we have been `init'ed`
[13:54] <mborzecki> i'm experimenting with `snap set core refrsh.timer=<...>` and it's a bit weird, you see the current setting appear right away in `snap refresh --time` but it becomes effective only after restart or when the current next expires
[13:57] <pedronis> mborzecki: shouldn't be like that looking at the code, but it might take 5 minutes to take effect if we are not careful
[13:59] <mborzecki> pedronis: how often is autorefresh.Ensure() called?
[14:02] <cachio> mvo, mborzecki I ran with this kernel and I for the oom issue too https://paste.ubuntu.com/p/4X9s7jtybd/
[14:02] <pedronis> mborzecki: if nothing is going on, each 5 minutes
[14:02] <pedronis> that's where my 5 minutes comes from
[14:03] <mup> PR snapd#4710 closed: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4710>
[14:04] <mvo> cachio: oh, interessting.
[14:04] <pedronis> mborzecki: it's   ensureInterval  in overlord/overlord.go, probably worth getting familiar with that bit
[14:04] <mborzecki> pedronis: yup, looking at it now
[14:05] <pedronis> mborzecki: we have state.EnsureBefore  to trigger it earlier, various places use it
[14:05] <pedronis> some in taskrunner.go
[14:06] <mborzecki> right, i've seen this one before :)
[14:07] <cachio> mvo, is it any way to disable apparmor and make the tests work?
[14:07] <cachio> mvo, to discard that?
[14:09] <cachio> mvo, I'll try just removing it
[14:09] <mvo> cachio: I did: "mv /sbin/apparmor_parser /sbin/apparmor_parser.saved"
[14:09] <mborzecki> pedronis: there's a funny effect, that once a refresh runs as is successful, next becomes time.Time{}, so when you do `snap refresh --time`, next will be 'n/a'
[14:10] <mvo> cachio: cp /bin/true /sbin/apparmor_parser
[14:10] <jdstrand> mvo: interesting. As you said, this sounds like a kernel issue since you couldn't reproduce on 4.10 or lower
[14:11] <cachio> mvo, you already tried that and it didn't work?
[14:11] <jdstrand> mvo: you said 4.10 was not affected. 4.13 (artful) is? why are we only seeing this now? is it just now is when you decided to get to the bottom of artful and bionic issues?
[14:11] <mvo> jdstrand: take it with a grain of salt, cachio said he sees it with 4.10 too, I will double check
[14:11] <mvo> cachio: that worked for me
[14:11] <mvo> cachio: when I moved the apparmor_parser away I did not see the mem leak anymore
[14:11] <jdstrand> mvo: how much memory is in the vm?
[14:12] <mvo> jdstrand: I think its some factors: the interfaces-many test got added relatively recently, we don't run much on i386 and autopkgtest for 2.30 did not run because we had problems getting this snap accepted into the archive at all
[14:12] <mvo> jdstrand: the vm has 1500mb
[14:12] <mvo> jdstrand: but it seems like the LowMem is what triggers the oom on i386 which is just 400mb
[14:12] <jdstrand> mvo: this is i386 only/
[14:13] <jdstrand> ?
[14:13] <mvo> jdstrand: I suspect its amd64 too, it just takes a lot longer as it has the full 1500mb of memory
[14:13] <mvo> jdstrand: for some reason its the lowmem on i386 that runs out
[14:13] <mvo> jdstrand: the oom-test.tar.gz should have all that is needed to reproduce
[14:14] <mvo> jdstrand: let me run it (in a loop) on amd64 to see if it eventually also dies
[14:14] <jdstrand> mvo: yes. I'd like to remove snapd from the equation though so I commented in the topic
[14:15] <mvo> jdstrand: I see ~15mb per "snap connect" decrease in free memory with 4.13. maybe with 4.10 (and below) the leak is just smaller that is why cachio sees it (because he was looking harder) and I don't (because I was just looking for the oom to trigger)
[14:15] <Chipaca> mvo: the interfaces-many test is a bit of a hog, it has so many changes that towards the end it takes seconds to do each one
[14:16] <mvo> Chipaca: indeed
[14:16] <mvo> jdstrand: I run it now on amd64 in a loop just to see what will happen (bionic with 4.13)
[14:16] <mborzecki> mvo: what if you try to reload apparmor profiles in a loop?
[14:16] <jdstrand> mvo: note that an apparmor profile does take kernel memory. it should not take that much and it shouldn't lose 15mb with a replace operation
[14:17] <mvo> jdstrand: *nod*
[14:18] <mborzecki> off to pick up the kids
[14:26] <mvo> jdstrand: fwiw, it looks like amd64 is also affect, just takes longer because of the different memory available (1480 vs 390)
[14:28] <cachio> mvo, https://paste.ubuntu.com/p/YsCpXvfgNg/
[14:28] <cachio> 56MB free
[14:28] <cachio> preparing the suite
[14:36] <kalikiana> re
[14:49] <sergiusens> snappy-m-o autopkgtest 1942 xenial:armhf
[14:49] <snappy-m-o> sergiusens: I've just triggered your test.
[15:18] <mvo> cachio: yeah, same here, eventually amd64 also runs out of memory
[15:22] <cachio> mvo, I am gonna try with an older bionic image
[15:23] <mvo> cachio: thank you
[15:24] <jdstrand> mvo: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/5
[15:25] <jdstrand> oh heh, you already liked it
[15:25] <mvo> jdstrand: very much indeed! thanks for the reproducer
[15:25] <mvo> cachio: -^
[15:25] <mvo> cachio: looks like jdstrand has an even better reproducer that does not involve snapd, probably easy(ish) to bisect using this
[15:26] <brunosfer> Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem:
[15:26] <brunosfer> bluez.sdptool browse local
[15:26] <brunosfer> Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory
[15:26] <jdstrand> mvo: I think for now the test should be disabled on i386
[15:26] <brunosfer> Does anyone knows how can I solve this issue?
[15:26] <jdstrand> mvo: the test really only needs to be run on one arch imho
[15:27] <mvo> yes+
[15:27] <jdstrand> well
[15:27] <jdstrand> the snapd part of the test is only useful on one arch
[15:28]  * mvo nods
[15:28] <jdstrand> the fact that it showed an issue on i386 is certainly helpful :)
[15:38] <marcoceppi> o/ can anyone help me with this: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11
[15:39] <brunosfer> Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem: $bluez.sdptool browse local Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory
[15:39] <brunosfer> Does anyone knows how can I solve this issue?
[15:40] <ogra_> brunosfer, it is probably best to ask this on the forum ... koza can probably help but i think he is not around currently (so he can more easily pick up the question on the forum later)
[15:40] <ogra_> also make sure to describe what HW you run and if all your interfaces are connected properly etc
[15:41] <brunosfer> how much later? because I posted that issue since December 17th and so far I'm stuck and nobody replied...
[15:42] <ogra_> brunosfer, where did you post it ?
[15:42] <marcoceppi> Chipaca: o/
[15:42] <brunosfer> Everytime I make this question here people redirect me to the forum and it's a dead end...
[15:42] <ogra_> (got a link to the forum post ?)
[15:42] <brunosfer> https://forum.snapcraft.io/t/failed-to-connect-to-sdp-server-permission-problem/3085
[15:47] <mvo> hm, hm, today https://forum.snapcraft.io/t/all-revisions-of-snaps-are-mounted-when-they-dont-need-to-be/2294 came up, I wonder if anyone ever looked what is taking >500ms
[15:48] <jdstrand> mvo: fyi, jjohansen is aware of a profile replace memory leak and will continue to look into it
[15:55] <Chipaca> marcoceppi: o/!
[15:55] <Chipaca> marcoceppi: how's things?
[15:55] <Chipaca> marcoceppi: so, tell me more about this messed-up snapd you have
[15:55] <marcoceppi> great except for my broken snaps :(
[15:55] <marcoceppi> I mean, it's my laptop
[15:55] <Chipaca> marcoceppi: ok. Can you enabled debug, if you haven't already?
[15:56] <Chipaca> enable*
[15:56] <marcoceppi> 16.04 full patched, few days ago a new kubectl snap was published and since then it's not been well
[15:56] <Chipaca> marcoceppi: that's add SNAPD_DEBUG=1 to /etc/environment and 'systemctl restart snapd'
[15:56] <marcoceppi> yeah, restarting snapd hangs
[15:57] <Chipaca> niiice
[15:57] <Chipaca> marcoceppi: hangs how?
[15:57] <mvo> marcoceppi: what exactly is broken? does snapd itself misbehave? or one (or muliple) snaps?
[15:57] <marcoceppi> mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11
[15:57] <Chipaca> mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/7
[15:57] <marcoceppi> Chipaca: restart command blocks indefinitely
[15:57] <Chipaca> haha
[15:57] <Chipaca> youch
[15:57] <Chipaca> marcoceppi: what does 'journalctl -u snapd' show?
[15:57] <marcoceppi> I can straight up kill it
[15:58] <marcoceppi> Chipaca: https://paste.ubuntu.com/p/fDhqFCPGkC/
[15:59] <Chipaca> marcoceppi: is that the _end_ of the journal?
[15:59] <marcoceppi> yeah, I mean, I just did an -f and it's printing a few more things
[15:59] <marcoceppi> like sysctl just SIGKILL'd the proc
[15:59] <Chipaca> with the SNAPD_DEBUG, and it hanging, i'd expect lots of stuff
[15:59] <Chipaca> nnngh
[15:59] <marcoceppi> oh, no, still waiting for it to restart
[15:59] <marcoceppi> so it can get SNAPD_DEBUG
[16:00] <Chipaca> ok, so just kill it
[16:00] <Chipaca> something is bad
[16:00]  * marcoceppi nods
[16:00] <Chipaca> and the oom will kill one thread and leave go wondering
[16:00] <Chipaca> so when that happens you need to manually kill the whole thing
[16:00] <pedronis> kubectl is classic fwiw
[16:00] <Chipaca> ack
[16:01] <marcoceppi> yes, but lxd isnt pedronis and it has the same problem
[16:01] <Chipaca> pedronis: i mean, if it were just the snap misbehaving i'd kick it over to sergio :-)
[16:01] <Chipaca> pedronis: but this is snapd doing something weeeird
[16:01] <pedronis> but you said it started when you got the new kubectl
[16:01] <marcoceppi> that's when I noticed it exhibiting issues, yes
[16:01] <Chipaca> marcoceppi: how's the kill-everything-and-start-over going?
[16:01] <marcoceppi> it's started
[16:02] <marcoceppi> Chipaca: https://paste.ubuntu.com/p/vR9Nky4bhx/
[16:03] <Chipaca> marcoceppi: can you 'curl -s -N -0 --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all | python -m json.tool | pastebinit'?
[16:03] <Chipaca> marcoceppi: assuming you have pastebinit, otherwise you know what i mean
[16:03] <marcoceppi> that's a mouthful
[16:04] <marcoceppi> http://paste.ubuntu.com/p/nRTM6jyyvT/
[16:06] <Chipaca> marcoceppi: can you do a 'sudo du -sh /root/snap/* /home/user/snap/* /var/snap/*' ?
[16:06] <Chipaca> (depending on your permissions you might need to tweak that for the glob to expand everywhere)
[16:07] <marcoceppi> Chipaca: https://paste.ubuntu.com/p/HNq9hGGm66/
[16:08] <Chipaca> marcoceppi: if you say 'snap watch 481' does it still say it's copying stuff?
[16:08] <marcoceppi> yes
[16:08] <Chipaca> marcoceppi: that's kubefed, yes?
[16:08] <marcoceppi> correct
[16:08] <Chipaca> marcoceppi: so my question for you is, how does it take this long to copy 28k of data
[16:09] <marcoceppi> well, that's my question for you - isn't it :D
[16:09] <marcoceppi> SSD with over 60GB of free space on EXT4
[16:09] <Chipaca> marcoceppi: can you try copying that directory somewhere, by hand? ie 'cp -a /var/snap/kubefed /var/tmp' ?
[16:10] <marcoceppi> Chipaca:
[16:10] <marcoceppi> time cp -a /var/snap/kubefed /var/tmp/
[16:10] <marcoceppi> real	0m0.003s
[16:10] <marcoceppi> user	0m0.000s
[16:10] <marcoceppi> sys	0m0.000s
[16:10] <marcoceppi> worked without issue
[16:11] <cachio> mvo, using an 2 months old bionic image I see the same oom error
[16:11] <mvo> cachio: ta
[16:11] <Chipaca> marcoceppi: the other one you had in doing was copying the lxd data
[16:11] <Chipaca> marcoceppi: that one could take a bit longer, it being 5 gigs
[16:12] <mvo> cachio: jdstrand told me the memory leak is something that jjohansen is investigating. maybe he knows (roughly) when this started ? if not we might be able to help bisecting
[16:12] <marcoceppi> yeah, but it's been over 24 hours
[16:12] <marcoceppi> and LXD was a problem after 24 hours of the kubectl issue
[16:12] <marcoceppi> I feel like snapd is unable to perform this action
[16:13] <Chipaca> marcoceppi: is there anything new in the logs?
[16:13] <marcoceppi> Feb 20 11:03:59 T430 snapd[28114]: 2018/02/20 11:03:59.146915 daemon.go:233: DEBUG: pid=28499;uid=1000;@ GET /v2/changes?select=all 1.369681ms 200
[16:13] <marcoceppi> that is the only new line
[16:13] <Chipaca> that's you
[16:14] <marcoceppi> yes, I realize that, but wanted to be complete in my reporting
[16:14] <Chipaca> yes yes, i was just confirming
[16:14] <Chipaca> I don't understand what it thinks it's doing
[16:14] <marcoceppi> can I - like delete this change attempt and just start over?
[16:15] <marcoceppi> I really /really/ DO not want to lose my lxd containers
[16:15] <marcoceppi> but kubectl has no userdata
[16:15] <Chipaca> marcoceppi: i mean, you could, but it'd be hairy
[16:15] <Chipaca> marcoceppi: can you stop snapd, and start it straced?
[16:16] <marcoceppi> you got what I should invoke for snapd to be strace'd?
[16:17] <Chipaca> marcoceppi: so, first, systemctl stop snapd.\*
[16:18] <cachio> mvo, so, are you preparing 2.31.1 today, or we need to wait until this is fixed?
[16:18] <Chipaca> marcoceppi: and then: sudo strace -E SNAPD_DEBUG=1 -f -s 9999 -o /tmp/snapd.trace /usr/lib/snapd/snapd
[16:18] <cachio> mvo, or any other fix?
[16:20] <pedronis> Chipaca: 5G in versioned data, that's a problem in itself, we though common is for that
[16:20] <Chipaca> pedronis: is it versioned?
[16:20] <pedronis> well if it's being copied
[16:20] <pedronis> we don't copy common data, no?
[16:20] <Chipaca> we don't
[16:20] <Chipaca> but I don't know if that's what it's doing
[16:20] <Chipaca> it says it's copying a 28k directory, also
[16:20] <pedronis> ok, ignore me
[16:20] <Chipaca> for hours
[16:20] <Chipaca> pedronis: no, no, i need ideas :-)
[16:21] <Chipaca> pedronis: especially if nothing turns up in the trace
[16:21] <pedronis> anyway both these snaps are classic I suppose
[16:21] <marcoceppi> Chipaca: so, I can't start snapd manually , says socket is in use but no other proc is really running
[16:21] <pedronis> so they could do strange stuff on their own
[16:21] <pedronis> fwiw
[16:21] <pedronis> though hooks have timeouts
[16:21] <pedronis> in theory
[16:21] <marcoceppi> Chipaca: nvm, fixed it
[16:21] <Chipaca> marcoceppi: what was it?
[16:22] <marcoceppi> I have like 100% lack of chill right now, heh
[16:22] <marcoceppi> how long do you want me to collect strace data?
[16:22] <mvo> cachio: today
[16:23] <mvo> cachio: it looks like we need test-snapd-password-manager-consumer for s390x
[16:23] <mvo> cachio: I'm just inspecting the s390x autopkgtest failure
[16:23] <Chipaca> marcoceppi: a couple of minutes after it says 'Running task 5559 on Doing: Copy snap "kubefed" data'
[16:23] <mvo> cachio: but no blocker, I will go ahead with 2.31.1 onw
[16:23] <marcoceppi> Chipaca: cool, it's been doing that, I'll let it run a wee bit
[16:24] <Chipaca> marcoceppi: you can tail /tmp/snapd.trace if you're anxious (i know i'd be)
[16:25] <cachio> mvo, ok, I can't update the snap recipe
[16:25] <mvo> cachio: oh, ok. let me check
[16:25] <cachio> to generate the snap fo s390x
[16:26] <mup> PR snapd#4711 opened: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/4711>
[16:26] <cachio> mvo, it is yours
[16:26] <marcoceppi> Chipaca: Okay 5 mins of strace data since copy message
[16:26] <mvo> cachio: *cough* indeed - fixed
[16:27] <marcoceppi> Chipaca: https://paste.ubuntu.com/p/4CphPf7stb/
[16:28] <Chipaca> marcoceppi: and /tmp/snapd.trace ?
[16:28] <marcoceppi> Chipaca: yeah, let me paste it
[16:28] <Chipaca> ah :-)
[16:28] <Chipaca> i was worried and perplexed, there
[16:28] <marcoceppi> although - heh - I can't get the proc to interrupt
[16:29] <marcoceppi> Chipaca: http://paste.ubuntu.com/p/7bCBVTMMTV/
[16:29] <marcoceppi> I hope I didn't crash pastebin
[16:30] <Chipaca> marcoceppi: you're probably going to have to sudo killall strace
[16:30] <marcoceppi> sure, I'll also gz upload that file
[16:30] <Chipaca> can confirm that pastebin is not a happy bunny
[16:32] <marcoceppi> Chipaca: http://marcoceppi.com/snapd.trace.gz
[16:33] <mup> PR snapcraft#1944 opened: tests: split the plugins tests in the same directory <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1944>
[16:33] <cachio> mvo, I see several errors on the arm64 execution for autopkgtest
[16:33] <cachio> mvo, should I fix them?
[16:34] <marcoceppi> Chipaca: interestingly, I have a bunch of orphaned sync commands like in the paste above
[16:34] <mvo> cachio: yeah, but not high priority, it was not green before so it will not be a blocker
[16:35] <cachio> mvo, yes, smae for ppc64el and s390x
[16:35] <mvo> cachio: the issues on ppc64el and s390x are considered regressions by adt so that is higher priority
[16:35] <mvo> cachio: afaict ppc64el is mostly good
[16:35] <mvo> cachio: and s390x has some snaps missing, then we need to retrigger and see
[16:36] <cachio> ppc64el just 4 errors
[16:36] <mvo> cachio: its "funny", s390x was considered working before because we skipped it because it was only a lxd container
[16:36] <mvo> cachio: the timezone ones, right?
[16:36] <marcoceppi> brb, going to restart
[16:36] <mvo> cachio: those are fixed with the systemd in -propsoed
[16:37] <cachio> mvo, yes and confinement-classic because the snap was not relased
[16:37] <cachio> released
[16:37] <mvo> cachio: indeed
[16:38] <mvo> cachio: apparently it is possible to retrigger the adt with &trigger=systemd/proposed&trigger=snapd/proposed at the end of the retrigger url - this will cause snapd to be tested with the right systemd version
[16:38] <cachio> mvo, perfect
[16:40] <pedronis> Chipaca: the copies are cp -av afaict
[16:41] <Chipaca> yep, "cp", "-av", "/home/marco/snap/kubectl/303", "/home/marco/snap/kubectl/328"
[16:41] <pedronis> so ps should tell use which one is taking forever?
[16:41] <mvo> cachio: I uploaded snapd 2.31.1 to the ppa, if all goes well you should have a beta core in ~45min or so
[16:42] <cachio> mvo, great, thanks
[16:43] <pedronis> mvo: I just noticed that this bit of test  mock := testutil.MockCommand(c, "kdialog", "sleep 9999999") seems to leave around the sleep
[16:43] <Chipaca> pedronis: it looks like the cp's finished
[16:43] <cachio> mvo, we need test-snapd-wayland for arm64 in edge
[16:44] <cachio> mvo, could you please share it to me?
[16:44] <cachio> tx
[16:44] <Chipaca> pedronis: lxd and kubectl at least, looking at the other two
[16:44] <marcoceppi> Chipaca: I restarted my machine and everything's fixed
[16:45] <Chipaca> marcoceppi: oh no
[16:45] <pedronis> for a bit, usually snapd will restart doing what it was doing before
[16:45] <marcoceppi> I mean, the changes are all flushed, and the snaps are enabled and the currect current versions
[16:45] <marcoceppi> ID   Status  Spawn                 Ready                 Summary
[16:45] <marcoceppi> 481  Done    2018-02-17T01:48:48Z  2018-02-20T16:39:28Z
[16:45] <marcoceppi> 482  Done    2018-02-19T05:32:01Z  2018-02-20T16:39:45Z  Refresh snaps "lxd", "go"
[16:45] <marcoceppi> 483  Done    2018-02-20T16:39:41Z  2018-02-20T16:40:23Z  Auto-refresh snap "core"
[16:46] <marcoceppi> Only problem is debug is stillenabled despite removing the environment line and restart snapd
[16:46] <Chipaca> marcoceppi: what's "snap tasks 481"?
[16:47] <marcoceppi> that was the first one that got stuck, the kubectl and kubefed one
[16:47] <pedronis> Chipaca: we had a bug when you refreshed some exact number of snaps the summary would come out empty
[16:47] <Chipaca> ah ok
[16:47] <Chipaca> marcoceppi: this wasn't the first time you restarted since this started, right?
[16:47] <pedronis> it's fixed, I don't remember what the magic number was
[16:48] <marcoceppi> no, this was the first time
[16:48] <pedronis> it was a confusion bug around go switch stmt != C switch stmt
[16:48] <marcoceppi> I don't like restarting, messes up my state
[16:48] <Chipaca> pedronis: heh
[16:48] <Chipaca> marcoceppi: fair enough
[16:48] <pedronis> Chipaca: a missing fallthough
[16:48] <pedronis> or something like that
[16:48] <Chipaca> marcoceppi: I hate losing state, and i hate problems that disappear without me learning from them
[16:48] <marcoceppi> I suppose I should have done so earlier; either way it seems something about sync getting stuck causing a backup
[16:48] <Chipaca> marcoceppi: but, you're fixed, so yay :-)
[16:49] <marcoceppi> hah, yes, back to work now
[16:49] <Chipaca> marcoceppi: does running 'sync' hang, for you?
[16:49] <marcoceppi> not anymore
[16:49] <marcoceppi> but I should have tested earlier
[16:49] <Chipaca> marcoceppi: was it doing so before the reboot/
[16:49] <Chipaca> ?
[16:49] <marcoceppi> did not test that
[16:49] <Chipaca> ah
[16:50] <Chipaca> if it was, I'd start shopping for SSDs
[16:50] <marcoceppi> considering there were sync processes from days ago, I'm inclined to believe that may be the problem
[16:50] <Chipaca> but ¯\_(ツ)_/¯
[16:51] <marcoceppi> hum, I don't have any smart errors
[16:51] <marcoceppi> but I'll start a disk copy anyways
[16:52] <Chipaca> marcoceppi: it might be something weirder, some corner case in the mount handling code that we're tripping up
[16:52] <Chipaca> marcoceppi: (we've fixed so many of those already...)
[16:53] <Chipaca> marcoceppi: if it ever happens again, jump on here
[16:53] <Chipaca> marcoceppi: glad you're unstuck, and good luck
[16:53] <marcoceppi> Chipaca: I'll keep an eye out - thanks!
[16:58] <marcoceppi> Chipaca: any way to get rid of the debug output?
[16:58] <Chipaca> marcoceppi: if should be enough to remove it from /etc/environment and restart
[16:59] <marcoceppi> yeah, did that :|
[16:59] <Chipaca> marcoceppi: but, note you'll still have it in your shell and stuff
[16:59] <marcoceppi> oh, yeah, it's in my shell
[16:59] <marcoceppi> DUH
[16:59] <Chipaca> marcoceppi: but systemctl shouldn't pass them to the units
[16:59] <Chipaca> marcoceppi: but if you're running it by hand because that's cool, then there's why
[17:00] <marcoceppi> I mean, it's showing in all my snap commands
[17:00] <marcoceppi> but because snap_debug was in my shell
[17:00] <marcoceppi> so unset and ready to go!
[17:00] <Chipaca> ah, i thought you were seeing it in the journal
[17:00] <Chipaca> :-) ok
[17:02] <mvo> jdstrand: I noticed something curious - it looks like c1093d46437a33d60d7378b1c6676818655bc359 is not in master currently, I noticed when merging back the changes from 2.31.1
[17:02] <mup> PR snapd#4712 opened: release: version 2.31.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4712>
[17:06] <cachio> mvo, in fact I can't see where the test-snapd-wayland code is? do you know?
[17:06] <cachio> mvo, I found it
[17:10] <cachio> jdstrand, hey, we need the test-snapd-wayland for arm64
[17:11] <cachio> to make autopkgtests pass
[17:11] <cachio> jdstrand, could you please create the snap?
[17:28]  * kalikiana wrapping up for the day
[18:14] <mvo> cachio: i386/amd64 core 2.31.1 ready in beta
[18:16] <mvo> cachio: arm* should be ready in ~1h or so
[18:22] <mup> PR snapd#4711 closed: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4711>
[18:46] <mvo> cachio: hrm, hrm, armhf/arm64 does not give me a built slot, maybe the 1h was too optimistic - I keep an eye on things
[18:50] <phoenix_firebrd> what version of intel vaapi driver is present in snappy core package in stable channel
[18:54] <niemeyer> jdstrand: Looks like the review tools need to learn about the "adapter" field:
[18:55] <niemeyer>   - unknown fields for app 'jmes': 'adapter'
[19:01] <jdstrand> niemeyer: ack, noted. I'll get that fixed
[19:02] <niemeyer> jdstrand: Thanks!
[19:02] <niemeyer> jdstrand: I just added a note to the original topic, btw: https://forum.snapcraft.io/t/telling-snapcraft-to-skip-generating-wrapper-scripts/1635
[19:04] <jdstrand> thanks
[19:05] <niemeyer> jdstrand: Meanwhile, would you mind to unblock the review and let it through.. it's a pretty boring snap otherwise
[19:05] <niemeyer> strict, no interfaces, etc
[19:05] <jdstrand> yes, I was heading over there
[19:05] <niemeyer> Thanks!
[19:09] <jdstrand> niemeyer: done. you'll need to release it to a channel
[19:09] <niemeyer> jdstrand: Thanks again!
[19:10] <jdstrand> np :)
[19:43] <mvo> cachio: all arches for 2.31.1 in beta now
[19:43] <cachio> great, 32 and 64 bits already running
[19:43] <cachio> mvo, no errors so far
[19:43] <mvo> cachio: \o/
[19:44] <mvo> cachio: 32bit is 2.31.1? I think I did something wrong with the promotion before but its correct now (sorry for that)
[19:45] <cachio> yes, 2.31.1
[20:45] <cmars> I'm trying to use this sockets feature in a snap, doesn't seem to be supported by snapcraft. it is supported yet? https://docs.snapcraft.io/build-snaps/syntax#sockets
[20:48] <niemeyer> cmars: It is supported, but not with that syntax.. this documentation is out of date as of a couple of years ago :)
[20:48] <cmars> niemeyer: gotcha.. do you have an example of how it's supposed to look?
[20:49] <niemeyer> cmars: It took us a while to reimplement support for it, but it's now in.. let me provide you with something you can go forward with.. just a sec
[20:49] <cmars> niemeyer: awesome to hear, thanks!
[20:51] <niemeyer> cmars: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/socket-activation/meta/snap.yaml
[20:52] <cmars> trying..
[20:53] <cmars> hmm
[20:54] <jdstrand> niemeyer: hey, so looking at adapter. this seems to be a snapcraft.yaml thing and not a snap.yaml thing. I don't see anything for processing adapter in snapd. shouldn't snapcraft remove adpater when generating snap.yaml?
[20:54] <cmars> snapcraft still doesn't accept it, https://paste.ubuntu.com/p/8FKdbnHmTt/
[20:54] <cmars> i guess i'll open a bug?
[20:55] <niemeyer> jdstrand: Waaait
[20:55] <niemeyer> jdstrand: Yes!
[20:55] <niemeyer> jdstrand: Good catch.. it makes no sense to have this in snap.yaml
[20:55] <jdstrand> niemeyer: ok, I'll file a snapcraft bug then and follow up in the forum
[20:56] <niemeyer> jdstrand: Thanks!
[20:56] <niemeyer> cmars: :/
[20:57] <niemeyer> cmars: It's been there for a few months.. let me find the topic..
[20:57] <niemeyer> cmars: https://forum.snapcraft.io/t/socket-activation-support/2050
[21:09] <niemeyer> cmars: Meanwhile, after you get the snap fully cooked, you can workaround the problem by changing the meta/snap.yaml in prime/ and then packing the snap
[21:13] <cmars> niemeyer: interesting, ok, thanks
[21:31] <phoenix_firebrd> how to know what version of intel vaapi driver is used in ubuntu snap core in stable channel?
[21:33] <popey> phoenix_firebrd: I dont believe we ship vaapi drivers in core
[21:35] <phoenix_firebrd> popey: so vlc snap uses driver from the host?
[21:36] <popey> yes
[21:36] <phoenix_firebrd> popey: in general how can you find the versions of software used in a core snap?
[21:36] <popey> it uses whatever the right driver is for the gpu
[21:36] <popey> that's a question for someone who works on the core snap I think
[21:37] <popey> (not me)
[21:37] <popey> (I imagine ogra_ knows) :D
[21:37] <popey> the yaml is probably somewhere abouts
[21:37] <phoenix_firebrd> popey: I patched my vaapi driver, the normal install of software reflects that, but it has no effect on the snap version of vlc
[21:38] <ogra_> phoenix_firebrd, http://people.canonical.com/~ogra/core-builds/ has links to manifest files for all auto-built core snaps
[21:38] <phoenix_firebrd> ogra_: thanks, I will take a look at that
[21:39] <ogra_> and no, i dont think vaapi from the host is used, the vlc snap definitely uses something it ships itself
[21:40] <ogra_> (my laptop has no working vaapi setup yet, i can configure vlc from the snap with the vaapi driver and get accelerated playback)
[21:42] <ogra_> libva info: VA-API version 0.39.0
[21:42] <ogra_> libva info: va_getDriverName() returns 0
[21:42] <ogra_> libva info: Trying to open /snap/vlc/158/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[21:42] <ogra_> libva info: Found init function __vaDriverInit_0_39
[21:42] <ogra_> libva info: va_openDriver() returns 0
[21:42] <ogra_> [00007f3ced0781c0] avcodec decoder: Using Intel i965 driver for Intel(R) Ivybridge Mobile - 1.7.0 for hardware decoding
[21:43] <ogra_> this pretty clearly points to the in-snap driver ...
[21:43] <phoenix_firebrd> ogra_: vainfo from where?
[21:43] <ogra_> thats simply from starting vlc in a terminal
[21:44] <popey> oh, it depends :)
[21:44] <phoenix_firebrd> ogra_: ok. can you show me a link to the manifist of this package ubuntu-core-libs
[21:44] <ogra_> yeah, probably different on non-intel
[21:44] <popey> yeah
[21:44] <ogra_> phoenix_firebrd, no, i have no idea where a manifest for the vlc snap would live
[21:45] <ogra_> phoenix_firebrd, the vaapi lib is included in the vlc snap ... not anywhere in core
[21:45] <popey> for intel, yeah, and it builds using the 16.04 archive, so whatever is in 16.04
[21:45] <ogra_> cant be
[21:45] <ogra_> the vaapi in the archive is broken
[21:46] <phoenix_firebrd> ogra_: thats right
[21:46] <ogra_> i assume the vlc snap builds some upstream version
[21:46] <popey> (I made that bit of the vlc snap)
[21:47] <phoenix_firebrd> ogra_: who maintains the vlc snap, the vlan team or a ubuntu dev?
[21:47] <popey> vlc
[21:47] <popey> https://github.com/videolan/vlc/blob/master/extras/package/snap/snapcraft.yaml
[21:47] <ogra_> $ snap info vlc|grep publisher
[21:47] <ogra_> publisher: videolan
[21:47] <phoenix_firebrd> ogra_: it cant be an upsteam version, you version as you saw is pretty old
[21:47] <popey> note the libva stage packages
[21:47] <phoenix_firebrd> popey: the latest is version 2.1.0
[21:48] <popey> the latest version of what?
[21:48] <phoenix_firebrd> ogra_: may be i show file a bug report to ask them to bump the version
[21:49] <popey> What's up with the one it ships?
[21:49] <phoenix_firebrd> popey: libva
[21:49]  * ogra_ hasnt had any issues with in on ivybridge and kybylake HW
[21:49] <popey> ok, well currently it's using the one from 16.04
[21:50] <phoenix_firebrd> popey: it has bug that when playing a vp9 codec video (4k videos from youtube) shows some corrupted video frames
[21:50] <ogra_> i still dont get why i cant get vaapi to work at all with the archive version while vlc just bundles it and it works ... very weird
[21:50] <popey> phoenix_firebrd: interesting, I'd file a bug upstream in vlc
[21:50] <ogra_> yeah
[21:50] <phoenix_firebrd> popey: niced
[21:50] <popey> thresh: is the maintainer of the vlc snap, maybe they can comment :)
[21:50] <phoenix_firebrd> nice
[21:51] <ogra_> note that bumping such a version is quite some work ... (the snap would have to build a newer upstream version at build time)
[21:51] <phoenix_firebrd> ogra_: popey let me find the upstream bug report and the official patch , so that we can have some idea
[21:53] <ogra_> note that snaps are currently bound to 16.04 versions of the dependencies they use ...
[21:53] <ogra_> regardless where they are executed
[21:54] <ogra_> (this is about to change in 18.04 at some point but currently it means if you want to patch a dependency it gets kind of awkward)
[21:55] <phoenix_firebrd> https://github.com/intel/intel-vaapi-driver/issues/297
[21:55] <phoenix_firebrd> https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
[21:56] <phoenix_firebrd> thats the bug report and the next is the patch
[21:56] <ogra_> fun, a one liner
[21:56] <phoenix_firebrd> ogra_: what about in the edge channel?
[21:56] <phoenix_firebrd> ya
[21:56] <ogra_> that has nothing to do with channels
[21:56] <ogra_> snaps use deb packages ass build dependencies and as runtime deps
[21:57] <phoenix_firebrd> ogra_: both stable and edge are 16.04?
[21:57] <ogra_> with the current design thies debs have to be 16.04 ones
[21:57] <ogra_> yes
[21:57] <ogra_> all snaps are 16.04 based currenty
[21:57] <phoenix_firebrd> I understand
[21:57] <ogra_> you *can* build your deps from source
[21:58] <phoenix_firebrd> you mean for snaps or normal packages?
[21:58] <ogra_> or you can maintain a PPA with backports of newer debs for your dependencies and hack usage of that PPA into your snapcraft.yaml
[21:58] <ogra_> for snaps
[21:58] <ogra_> they usually ship their dependencies ...
[21:58] <phoenix_firebrd> ogra_: I did that, but the point is i dont this issue to be present in 18.04
[21:59] <ogra_> if you read the snapcraft.yaml popey linked above you see "build-packages" and "stage-packages" ... these are typically 16,04 deb packages
[21:59] <ogra_> yes, i understand
[22:00] <ogra_> but the version in the snap is 16.04 ... unless someone backports the fix into the ubuntu archive or the vlc maintainer jumps through some hoops (build vaapi from source or backport the 18.04 version in a PPA and maintain it there ... (and hack the snapcraft.yaml of vlc to use that PPA))
[22:01] <ogra_> there is no easy solution for this atm ...
[22:01] <phoenix_firebrd> ok
[22:02] <ogra_> the design is changing  to allow newer dependencies via "base snaps" in the future (then your whole snap can be built against i.e. 18.04 but still run on 14.04 or 16.04)
[22:02] <ogra_> but thats not done yet
[22:02] <ogra_> so for now its a big amount of extra work for the snap packager to include such a patch
[22:03] <phoenix_firebrd> ok
[22:03] <phoenix_firebrd> what happens in case of a security patch for a dependency?
[22:04] <popey> the developer rebuilds the snap
[22:04] <popey> (or it's automatic)
[22:05] <phoenix_firebrd> if the core snap is rebuilt does the vlc snap for example have to be rebuilt?
[22:05] <ogra_> no
[22:05] <phoenix_firebrd> ok
[22:05] <phoenix_firebrd> vlc snap is like a static executable?
[22:06] <ogra_> not really :)
[22:06] <phoenix_firebrd> ok
[22:06] <ogra_> it is a dynamically linked executable that ships all the libs it is linked against and sets a library path pointing to them
[22:07] <phoenix_firebrd> ogra_: understood
[22:08] <phoenix_firebrd> ogra_: do you know/guess what version of libva will be shipped during release of 18.04?
[22:08] <ogra_> nope
[22:09] <ogra_> and until there is snap support for 18.04 (beyond the 16.04 base we have today) it will still take some time
[22:09] <ogra_> so for a while snaps will still be 16.04 based ... even in 18.04 ... until the base snap spec is fully implemented
[22:10] <ogra_> (which will likely happen within the 18.10 timeframe)
[22:11] <phoenix_firebrd> ogra_: If a snap is strictly confined, is it denied of gpu access?, I read in a forum. Is that true?
[22:11] <ogra_> it needs to define an interface for access
[22:11] <popey> https://docs.snapcraft.io/reference/interfaces
[22:12] <popey> there's an opengl interface
[22:12] <ogra_> right
[22:12] <ogra_> and an x11 one ... and a wayland one
[22:12] <ogra_> (and various others)
[22:13] <phoenix_firebrd> popey: Its like policykit
[22:16] <ogra_> lol
[22:16] <phoenix_firebrd> :)
[22:16] <ogra_> thats quite a simplification :)
[22:18] <phoenix_firebrd> ogra_: Can a theme be installed to be used for snaps?
[22:18] <ogra_> currently only if you ship it along with your app
[22:18] <ogra_> there is work going on to solve this though ...
[22:19] <phoenix_firebrd> ogra_: oh o_O
[22:19] <phoenix_firebrd> ok
[22:26] <phoenix_firebrd> popey: ogra_ thanks for the support
[22:27] <ogra_> np :)
[22:27] <popey> no problem
[23:38] <elopio> snappy-m-o autopkgtest 1943 xenial:armhf xenial:amd64 xenial:arm64
[23:38] <snappy-m-o> elopio: I've just triggered your test.


[07:49] <dholbach> good morning
[08:14]  * dholbach relocates to the office, brb
[09:00] <popey> Good morning
[09:19] <davidcalle> Good morning :)
[09:20] <svij> morning all
[09:25] <czajkowski> aloha
[15:09] <jose> weehee, only 4 hours till the GSOC applications period closes!
[15:11] <MooDoo> :)
[15:52] <dpm> jose wohoo! :)
[15:53] <dpm> balloons, it seems alex-abreu in ubuntu-webapps is interested in becoming a mentor
[15:54] <dpm> you might want to ping him if he didn't ping you already
[15:54] <balloons> will do, thank you
[15:54] <dpm> ah, it seems jose is onto it now :)
[16:05] <balloons> dpm and popey, did you guys manage to have a glance at the doc??
[16:06] <dpm> balloons, ah, I saw the link this morning but didn't have the chance to. I've got time now, so opening it
[16:07] <popey> doc?
[16:07] <popey> link me pls
[16:07] <dpm> "Community Core apps QA"
[16:20] <popey> jcastro: if someone wants to join slack but doesn't have an @ubuntu address, how can we invite them?
[16:22] <jcastro> You can send them an invite from the UI iirc
[16:22] <jcastro> by the "Ubuntu" top left there is a down arrow
[16:22] <jcastro> click "Invite people"
[16:24] <popey> ah
[16:52] <dholbach> all right my friends... I call it a day
[16:52] <dholbach> have a great weekend everyone!
[16:55] <balloons> so conceptually is are you on board popey and dpm? If so, we can do the cleanups on the doc and update the workflow image. But I'd like to get started on the actual work today too :-)
[16:59] <popey> balloons: dpm i just hit "resolv" on one of dpm's comments by mistake, sorry
[16:59] <popey> I have _no_ idea how to get it back
[16:59] <popey> found it!  😃
[17:00] <dpm> I'm sure it was one involving a work item for you :)
[17:00] <balloons> :-0
[17:00] <dpm> balloons, +1
[17:00] <popey> hehe
[17:00] <popey> +1 from me too balloons
[17:00] <popey> thank you for pulling this together
[17:01] <popey> Be aware I'll be afk most of next week (Embedded World in .de) and I don't know what my connectivity will be like, but I'll have telegram, and get notifications when people ping me on IRC.
[17:01] <balloons> brillant. So I'll finish it up and start hacking away
[17:03] <dpm> balloons, although I've just added a comment that might mean a bit more of work, but perhaps it's more on the "cleanup doc" department


[00:00] <jdong> ok will do
[00:06] <lool> jdong, persia: updated the bug
[00:06] <jdong> thanks
[00:06] <persia> lool: jdong: Thanks
[00:07] <lool> Hmm but jdong wasn't upgrading from karmic
[00:07] <lool> Which is precisely the code path which the SRU addresses
[00:07] <persia> jeandaniel: Was your install an upgrade from karmic?
[00:08] <jdong> lool: ah, that makes a difference?
[00:09] <zul_> persia: ping
[00:09] <persia> zul_: Your name was mentioned to help verify bug #576662
[00:10] <persia> zul_: Your machine doesn't happen to be an upgrade from karmic, does it?
[00:10] <zul> persia: no i upgraded fine
[00:10] <persia> OK, I'm feeling a lot more comfortable.
[00:11] <mdeslaur> zul: did you upgrade to the latest grub2 update?
[00:11] <mdeslaur> zul: actually, are you using grub2?
[00:11] <lool> jdong: Yup
[00:11] <lool> persia: I mailed cjwatson now
[00:11] <zul> mdeslaur: yeah im not sure which version of grub im using...gimme a sec
[00:11] <zul> assuming this is on the mac right?
[00:12] <jdong> yes
[00:12] <lool> persia: Fwed to you
[00:12] <lool> Not sure whether I should forward to TB
[00:12] <persia> lool: Thanks.
[00:12] <lool> Seems overkill
[00:12] <persia> I think it's overkill with the chourus of negative replication attempts.
[00:12] <zul> persia: 1.98-1ubuntu6 but im not running it from a MBR
[00:13] <persia> zul: I didn't think you *had* an MBR on a MacBook.
[00:13] <lool> persia: Dont you need to tag one bug regression-update?
[00:13] <jdong> lool: if everyone were reproducing it, then I'd panic and get the TB involved. Right now, that does not seem to be the case.
[00:13] <persia> sbeattie told me to tag it verification-failed
[00:13] <lool> Hmm I fantasy that regression-update tag I think
[00:14]  * lool => bed &
[00:14] <jdong> persia: is it still in -proposed?
[00:14] <jdong> or -updates already?
[00:15] <jdong> it's in -updates
[00:15] <persia> jdong: -updates
[00:15] <jdong> it's a regression-update, not a verification-failed
[00:15] <persia> Ah.
[00:15] <jdong> v-f is for -proposed packages not working
[00:15] <persia> sbeattie: ^^
[00:15] <persia> Does that tag go against the new bug or the old bug?
[00:18] <jdong> errrrr it should go against the old bug, the actual SRU
[00:18] <jdong> and probably this bug should be tagged dupe of the original SRU as well, if we're 100% sure the SRU is the cause.
[00:19]  * persia got very different instructions in #ubuntu-testing a while back, and suspects there would be benefit to an ubuntu-sru+sru-verification meeting
[00:20] <persia> regression-update added to 508173
[00:33] <cnd> I have a new package in debian sid, and I'd like to do a sync request to have it synced to lucid
[00:33] <cnd> should I be using the -e option of requestsync in this instance?
[00:35] <xnox> cnd, it should go at SRU
[00:35] <xnox> !SRU
[00:35] <xnox> cnd, i don't know whether requestsync supports that =)
[00:36] <xnox> cnd, try it and change the resulting bug report to match SRU requirements
[00:36] <cnd> xnox: are you sure? this wouldn't be an update to an existing package
[00:36] <persia> cnd: Can't do it.
[00:36] <xnox> cnd, we have released lucid already you can't add *new* packages
[00:37] <cnd> persia: oh, I thought you could
[00:37] <persia> cnd: New packages have to appear in new releases.  Once it's in maverick, it can be backported.
[00:37] <cnd> ok, nm then
[00:37] <cnd> thanks!
[00:37] <persia> So you can get it into lucid-backports, but not lucid.
[00:37] <YokoZar> oh snap I think I found a genuine dpkg bug
[00:37] <cnd> yeah
[00:37] <persia> (and not lucid-updates)
[00:38] <xnox> YokoZar, what about?
[00:40] <YokoZar> xnox: https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/571999  -- it seems to be using the wrong Conflicts information.  wine (karmic) user upgrades, wine (lucid) is a dummy package that installs wine1.2 (lucid).  wine1.2 (karmic) conflicts with wine, but wine1.2 (lucid) doesn't conflict.  dpkg refuses to upgrade, saying that wine1.2(lucid) conflicts with wine.
[00:41] <xnox> hmmm shouldn't wine (lucid) have Conflicts wine << version.in.karmic?
[00:41] <xnox> that way you make sure that wine karmic is removed first and then lucid's wine1.2 is installed
[00:41] <xnox> ?
[00:41] <YokoZar> xnox: err yeah, it does
[00:42] <xnox> huh
[00:42] <xnox> now this is strange
[00:42] <xnox> let me look
[00:42] <YokoZar> xnox: if you look at the log it upgrades wine(karmic) to wine(lucid)
[00:45] <lifeless> maxb: https://code.launchpad.net/~maxb/ubuntu/maverick/junitperf/ari-tczew-lp-521390/+merge/24868 - are you entirely happy with the diff that bzr is generating ?
[00:46] <lifeless> maxb: I'm looking at the mail that was sent out and wondering if we can make what you're doing more obvious
[00:46] <maxb> Well, what I was trying to do was to discover whether playing with prerequisite branches could make LP generate a nicer diff, and the answer seemed to be no
[00:48] <maxb> I think the one absolute that can be agreed on is that there is no single diff that is appropriate for all merges
[00:48] <xnox> YokoZar, I've added useful comment to that bug.
[00:51] <lifeless> maxb: we can try.
[00:51] <lifeless> maxb: so what structure of pre-req branches did you use?
[00:51] <maxb> I just tried pointing it at lp:debian/junitperf. It conflicted horridly
[00:52] <xnox> maxb, I've tried using prerequisite branches before and it seems like the merge generation uses 3-way diff instead of actually performing bzr diff --old --new. I've tried to represent debian sid, ubuntu-merge (my) & ubuntu-current branches for a package and both diffs on the merge proposal
[00:52] <xnox> had conflict markers although if you pull the branches in order on your machine they are fully merged and have no conflicts
[00:53] <xnox> there is a bug about it tagged with "udd" but i can't be asked to search for it now =)
[00:55] <lifeless> maxb: what did you expect/want it to do ?
[00:56] <maxb> I expected it to not do what I wanted. I vaguely hoped it might do something useful :-)
[00:56] <xnox> I was expecting pre-requisite to generate: debdiff between candidate version and current debian. debdiff between candidate and current ubuntu version =)
[00:57] <ajmitch> maxb: I was able to diff the branch there against the debian branch locally without any issues
[00:57] <xnox> I failed to achieve that =)
[00:57] <maxb> Ultimately I think there needs to be a special merge proposal mode specifically for ubuntu merges
[00:59] <maxb> You really want to see two diffs: (1) common-ancestor(merge-source, debian-equivalent-of-ubuntu-merge-target)..merge-source  and (2) result-of-merge as we have now, but only the debian/ directory
[01:05] <lifeless> maxb: lets try for better labels
[01:05] <lifeless> maxb: I think you mean 'code changes' and 'packaging changes' as separate diffs
[01:06] <maxb> The thing about my (1) is that it is *not* 'change introduced by this merge', it is 'ubuntu delta remaining after this merge'
[01:10] <lifeless> maxb: thus why we want better labels.
[01:10] <lifeless> maxb: so there are three things that may be interesting in a merge from debian:
[01:11] <lifeless>  - upstream changes, debian[code and packaging] changes, ubuntu[code and packaging] changes we're discarding, ubuntu[code and packaging] changes being altered by the merge
[01:11] <lifeless> perhaps
[01:12] <lifeless> I'm going to write a coverall bug on this; I certainly agree that we need more sophisticated review diffs; I don't necessarily agree that we can't come up with a single sane one (as an umbrella thing with sections or something)
[01:18] <psusi> bah!  damn kernel apparently ignores the fact that blocks are in the buffer cache from being read on the raw block device, and reads them again when you read the file
[01:18] <ion> Ouch
[01:19] <psusi> I got ureadahead reworked to read on the raw block device rather than going through the filesystem.... so it finishes real fast and gets peak disk throughput.. but then everything gets read again slowly as the buffer cache is totally ignored
[01:20] <ion> Heh
[01:31] <jdong> psusi: hahahaha!
[01:31] <psusi> I HAVE A PLAN!
[01:31]  * psusi codes like the wind
[01:33] <psusi> I'm going to try reading only the directories through the raw block device, and go back to opening and reading files normally
[01:40] <blendmaster1024> when is DIF for the next release?
[01:40] <blendmaster1024> whatever it's called
[01:44] <virtuald> blendmaster1024: https://wiki.ubuntu.com/MaverickReleaseSchedule
[01:44] <blendmaster1024> thank you
[01:45] <blendmaster1024> i have a game i'm working on that i'd like to see a demo of in maverick
[01:45] <virtuald> :>
[01:45] <blendmaster1024> so i need to have an idea of when to have the demo done by
[01:46] <blendmaster1024> woah i only have till june ...
[01:48] <lifeless> maxb: https://bugs.edge.launchpad.net/launchpad-code/+bug/509901
[01:50] <virtuald> do you guys know of any app for todo lists?
[01:50] <blendmaster1024> is it just me, or is ubottu all-powerful?
[01:50] <blendmaster1024> (j/k)
[01:50] <blendmaster1024> seems like it can do everything any other information bot can, plus a lot
[01:50] <blendmaster1024> is it custom for ubuntu?
[01:51] <virtuald> i don't know much about it, maybe ask in #ubuntu-bots
[01:51] <blendmaster1024> the people there ignore the channel :/
[01:51] <virtuald> ok
[02:19] <imbrandon> blendmaster1024: yes its custom for Ubuntu, originaly written by Seveas , you can find the code for it ( and the other bots ) on Launchpad, they are opensource
[02:19] <blendmaster1024> cool
[04:45]  * ScottK had forgotten how long boost takes to build.
[05:14] <ajmitch> ScottK: will earlier versions of boost be removed from maverick?
[05:14] <ScottK> ajmitch: That would be the goal.  Same as usual.
[05:16]  * ajmitch was just wondering if it was still worth doing the boost1.40 merge
[05:17] <ScottK> ajmitch: I'd vote no.
[05:17] <ScottK> Better spend the time on getting stuff on 1.42 after it's in.
[05:18] <ajmitch> ok
[05:19] <ScottK> pitti: boost1.42 is in source New.  If we can get that through New (source and binary) and into Main and boost-defaults sync'ed before the first autosync run, I think it will save us rebuilds later and make the boost transition easier.
[05:19] <ScottK> That or maybe slangasek will have insomnia and take care of it....
[05:45] <MTecknology> I'm trying to figure this out - how do I use aptitude-run-state-bundle?
[05:45] <MTecknology> If I run it on the file I generated from its counterpart it opens aptitude after working for a while and making a temp directory- but I can't restore teh packages state from it
[05:49] <MTecknology> or am I just using it wrong?
[08:10] <dholbach> good morning
[08:15] <zyga> good morning
[08:57] <arand> andersk: I was thinking of updating my ppa packages with your patch for mountall, just to make sure, your patch replaces Tero Mononen's right?
[08:59] <arand> (I really don't trust my lacking know of code, one bit)
[09:16] <andersk> arand: Yes, my patch replaces all the previous mountall patches. (Plymouth still needs to be patched separately.)
[09:17] <arand> andersk: Okay, I'll slap the new mountall up to my ppa then.
[09:40] <joaopinto> good morning
[11:55] <elleuca> was the "find and replace" OO.o dialog customized in 10.04?
[12:13] <unimatrix> why is fitts's law broken in ubuntu 10.04 again?
[12:13] <unimatrix> doesn't anyone care about this?
[12:13] <Tm_T> unimatrix: is there bug report about this?
[12:13] <unimatrix> Tm_T i've reported one for karmic
[12:13] <unimatrix> and nobody gave a damn
[12:13] <unimatrix> in lucid it's even worse
[12:16] <Tm_T> unimatrix: then you should update that bugreport with new details
[12:16] <unimatrix> Tm_T it's a new bug
[12:17] <unimatrix> https://bugs.launchpad.net/ubuntu/+source/human-theme/+bug/436066 <-- this is the old one (still present in lucid, since karmic)
[12:17] <unimatrix> now i need to open yet another one for the buttons
[12:17] <unimatrix> but what's the point when nobody is going to look at it for the next 5 years
[12:18] <Tm_T> I'd say more than complaining in irc (:
[12:28] <ScottK> asac: I've uploaded the new boost for Maverick (1.42) and it's in New.  The build system changed since 1.40 (no longer using CMake) and so I'm not certain my port of the thumb patch to the new version is complete.  Would you please have someone take a look at it? https://launchpad.net/ubuntu/maverick/+queue?queue_state=0
[12:29] <ScottK> unimatrix: The design group is on #ayatana, so possibly more luck there.
[12:29] <unimatrix> ScottK thanks
[13:13] <pitti> jdstrand: firefox> no, I had a server outage which ate my IRC proxy scrollback
[13:15] <pitti> ScottK: boost1.42 source NEWed to main
[13:16]  * pitti -> back to conference
[13:19] <jdstrand> pitti: k, here you go:
[13:20] <jdstrand> 10:03 < jdstrand> pitti: hi! can I have you opinion on http://people.canonical.com/~jamie/ff36-apparmor.diff.txt? background: there is a pending firefox update and there are these 4 bug fixes to the apparmor profile. the aa profile is disabled by default and no chance of regression (plus, me and several other people use the profile with these commits)
[13:20] <jdstrand> 10:04 < jdstrand> pitti: the question is whether to SRU these separately, with all the associated archive churn, or push them with the pending security update
[13:20] <jdstrand> 10:05 < jdstrand> pitti: I wouldn't normally ask, but in the case of firefox, upstream adds features and bug fixes beyond security fixes, so these low regression potential items seemed kinda gray...
[13:21] <jdstrand> (don't worry about Chris' changelog entry-- it is unrelated)
[13:21] <pitti> jdstrand: looks safe to me, I think it's fine to include it
[13:24] <ogra> hmm, is the archive usable now ?
[13:24]  * ogra wonders why uploads still end up in unapproved
[13:25] <pitti> ogra: I asked for thawing
[13:25] <pitti> (yesterday and today)
[13:25] <ogra> thanks :)
[13:25] <jdstrand> pitti: thanks!
[13:25] <pitti> but I can't be on IRC very often during the conference
[13:25] <ogra> indeed
[13:36] <nigelbabu> lool: so whats the final call on the MIR?
[13:55] <ScottK> pitti, doko: dpkg-checkbuilddeps: Unmet build dependencies: build-essential <-- boost1.42 - It sure didn't do that when I test built it last night .....
[13:56] <doko> ScottK: yes, there are other strange things: see the binutils build failure on i386 ...
[13:57] <ScottK> doko: OK.  I'll be patient then.
[14:24] <wgrant> doko: Those build failures are some pretty odd maverick brokenness.
[14:24] <wgrant> http://paste.ubuntu.com/429514/ looks reasonably bad.
[14:24] <wgrant> ScottK: ^^
[14:25] <ScottK> Thanks.
[14:25] <ScottK> Some kind of in completeness in the switch to 4.5 then.
[14:25] <wgrant> Looks like it.
[14:26] <ScottK> pretend that space wasn't there...
[14:26] <wgrant> Well, I can't see gcc 4.5 anywhere, except in some dependency lines.
[14:39]  * StevenK twitches at ScottK's sync package name
[14:40] <ScottK> The boost-defaults one?
[14:40] <StevenK> ScottK: python-django-djblets
[14:40] <ScottK> Ah.  Yes.
[14:40] <StevenK> It has djb in it. Worse, implications of more of them. Noooooooooooooooo.
[14:40] <ScottK> Stuff like that you just can't make up.
[14:44] <soren> ScottK: Why is it called djblets? I don't see any references to djb in there. :-/
[14:45] <ScottK> soren: I just fixed it.  I didn't name it.
[14:45] <soren> ScottK: I just thought you might know.
[14:45] <StevenK> I think I'd rather blacklist it, than sync it
[14:45] <ScottK> You'd have to remove it too.
[14:46] <ScottK> And that still wouldn't remove the history.
[14:46] <StevenK> No, I can do them seperately
[14:46] <StevenK> blacklisting just means it can't be synced
[14:46] <StevenK> It is able to exist in the archive while being blacklisted
[15:08] <ryan22> ive decided to fork ubuntu
[15:09] <ejat> ?
[15:09] <ryan22> I have serious concerns about the release system employed by Ubuntu and feel that the sound system it uses is inadequate for the needs of the average user (it can stream music to your kitchen but can't play games...). The proposals I posted on the Ubuntu developer mailing lists were rejected so I will be taking infinityOS, my distribution, in a different direction then Ubuntu. infinityOS will remain 100% binary compatible with Ubuntu. My go
[15:09] <ryan22> for infinityOS to become the Firefox to Ubuntu's Mozilla.
[15:10] <ryan22> My distribution will be switching from PulseAudio to OSS4 as it provides per-application volume controls while remaining compatible with existing applications and code.
[15:11] <ryan22> I find the notion that existing application should modify their code to work PulseAudio ridiculous, especially when OSS4 works without modification
[15:12] <ryan22> *with
[15:13] <ScottK> ryan22: Off topic for this channel.
[15:13] <ryan22> alright
[15:13] <ryan22> sorry
[15:14] <ryan22> i have told the ubuntu developers that will remain in contact with upstream
[15:14] <ryan22> *I
[15:39] <dholbach> Last day of https://wiki.ubuntu.com/UbuntuOpenWeek starts in 21m in #ubuntu-classroom with "Introduction to Ubuntu Development"
[15:40] <nigelbabu> Can someone moderate my mail to ubuntu-devel titled "patch day success"?
[15:54] <nigelbabu> cjohnston: ^^^
[15:54] <nigelbabu> cjwatson: ^^^
[15:54] <nigelbabu> cjohnston: sorry ;)
[15:55] <cjohnston> uh huh
[15:56] <nigelbabu> tabfail :/
[17:27] <lool> nigelbabu: No final call on the MIR; as I noted, I'm not sure it's needed anymore
[17:38] <zul> lool: is this the MIR for backuppc?
[17:38] <lool> zul: Yes and know
[17:38] <lool> zul: backuppc is in main already
[17:38] <lool> zul: It's the MIR on a dep
[17:38] <lool> a perl lib
[17:38] <zul> lool: ah ok
[17:39] <lool> https://bugs.launchpad.net/ubuntu/+source/libtime-modules-perl/+bug/525512
[17:39] <bulettin> хм
[18:22] <nigelbabu> lool: ok :)
[18:25] <ccheney> if printing under gnome thinks your printer is out of paper but it isn't is there any way to fix it without rebooting?
[18:26] <ccheney> i tried restarting cups but it doesn't seem to help
[18:26] <ccheney> is there some cups command to reinit the printer?
[18:31]  * ccheney decided to just yank the usb cable, couldn't find a way to make it work otherwise :-\
[19:18] <Azoff> &wc
[19:23] <ScottK> ccheney: You obviously didn't read enough Ubersoft recently.  If you had, you'd know that printing never works.
[19:23] <ccheney> ScottK: heh
[19:24] <ccheney> apparently for the hp printers if the printer ever runs out of paper it doesn't have the ability to determine you put more in, you have to reset the printer by yanking the cable
[19:25] <ScottK> Weird.
[19:25] <ScottK> I don't have that problem (HP printers, but KDE).
[19:37] <psusi> I hate HP printers... used to do IT desktop support at a big company that used HP network printers... we had to keep two different windows drivers for the thing and swap people back and forth because one version supported printing on the front and back of a page, and the other supported printing 2 or 4 pages on on.. but for some reason hp couldn't just put both features in one driver
[19:37] <psusi> that and their drivers always seem to busy wait, pegging the cpu to 100% while printing
[19:39] <psusi> and they seemed to be growing by leaps and bounds every year... probably up to a gigabyte download these days just for a damn driver... heh.
[19:42] <jdong> psusi: my experience with HP printers has been far worse in a diffrent way.
[19:42] <jdong> psusi: almost all of them accept unauthenticated magical packets to put "FEED ME" on the screen and other cute office pranks...
[19:43] <jdong> psusi: but some of them are insane enough to have a Java VM and 128MB RAM onboard
[19:43] <psusi> lol
[19:43] <jdong> once I've found a *NESSUS SCANNER* running on an HP printer on our network
[19:43] <jdong> no idea how it was put on there, but probably there's a magical kiss of death packet for loading your own fun toys onto the printers.
[19:43] <psusi> a what?
[19:43] <jdong> psusi: metasploit-type vulnerability scanner
[19:43] <psusi> oh dear
[19:44] <jdong> e.g. kinda like nmap but it can tell you "<IP_ADDRESS> is vulnerable to CVE-...."
[19:44] <jdong> yeah....
[19:44] <psusi> rootkit on a printer... damn... heh
[19:44] <jdong> I have to give the kid creativity points though. Who'd check the printer's traffic as a suspect for foul play?
[19:44] <psusi> yea
[19:46] <psusi> heh, reminds me of an exploit I found in highschool on our netware server... found out that the print server had an object in the netware bindery it logged in as that was supervisor equivalent... with no password... patched the login program to change the type id from user to printer when logging in and presto, instant all access pass ;)
[19:46] <psusi> nobody ever noticed that the print server had supervisory access... never expected anyone to be able to log in as one
[19:47] <jdong> haha yeah, high school exploits are the most amusing
[19:47] <psusi> hehe.... I had a real cool teacher for a few years... his policy was if you're smart enough to get one by him, you're smart enough to keep it and be trusted not to muck things up
[19:48] <jdong> yeah I had a good relationship like that too. I found ways around their proxy for SSH'ing to my machine and doing other benevolent things, and they let me do it as long as it didn't disrupt the network or get used for malicious purposes
[19:51] <topfs2> I have abit of a problem. Can anyone confirm UPower sleeping signal working in ubuntu? it should be in UPower 0.9.1 but it doesn't work for me
[20:17] <ScottK> doko: Any thoughts on fixing build essential?
[20:27] <gangil> is there an alternative of dkio.h in ubuntu ?
[21:04] <zaytsev> hi! could someone please advise me on why my package build fail on ubuntu < karmic. I'm changing permissions for some files in lib in  binary-post-install and it works for karmic and lucid, but others can't find the file
[21:04] <zaytsev> https://launchpad.net/~zyv/+archive/ppa/+packages <-- the whole series is here
[21:08] <Redache> 8
[21:10] <zaytsev> Very confusing
[21:10] <zaytsev> It seems that although the builds do not fail, the permissions are on changed even on karmic / lucid
[21:10] <zaytsev> -rwxr-xr-x root/root     10472 2010-05-07 19:53 ./usr/lib/mc/cons.saver <-- supposed to be root:tty and sgid
[21:12] <Laney> you should use dpkg-statoverride to do that
[21:13] <Laney> that'll be dh_fixperms resetting it
[21:14] <zaytsev> Laney, google tells me that statoverride is to override the permissions of the maintainer??? I am the maintainer :)
[21:15] <zaytsev> Is there any package that I can refer to see an example on how to use it?
[21:16] <zaytsev> Also, now I use ifeq ($(DEB_HOST_ARCH_OS), linux) to do this changes, because they are linux kernel specific. I am not sure how this will fit
[21:16] <Laney> yes, mediatomb does it
[21:22] <zaytsev> Laney, wow!!! that looks complicated. Is it possible to use DEB_HOST_ARCH_OS in postinst then?
[21:23] <zaytsev> If yes, I guess I have to rewrite it this way
[21:43] <ajmitch>
[22:06] <zaytsev> Laney, I've found a compelling advice while googling that I can put my permissions reset in package.postinst / configure
[22:07] <zaytsev> This looks hundred times easier than the crazy mediatomb stuff, considering that I have to do overrides for ~10 files
[22:11]  * Laney shrugs
[22:11] <Laney> I don't think it's particularly crazy
[22:11] <Laney> you could also pass -X blah to dh_fixperms if you like
[22:11] <Laney> see the man page
[22:11] <zaytsev> This would be an option if the package wouldn't be CDBS based
[22:11] <zaytsev> Do you think I will blow up something if I do it in postints :) ?
[22:12] <Laney> you have to take care not to stomp over end user changes
[22:15] <zaytsev> Ah, if this is the only trick, who the hell cares :) these scripts are intended to have these permissions and there is no sane scenario when they would have to be changes. Screw the users :) let THEY use dpkg-statoverride :)
[22:16] <Laney> but if they do, you'll override them when your postinst is run
[22:16] <Laney> must go to bed anyway, night
[22:26] <Dandre1> hello,
[22:27] <Dandre1> I have created a local repository with reprepro containing my ow deb files and I get errors when I try to update:
[22:27] <Dandre1> apt-get update gives lines like:
[22:27] <Dandre1> Ign file: lucid/main Packages
[22:27] <Dandre1> how could I see what's going wrong?
[22:43] <ScottK> doko, pitti, etc: gcc-4.5-base | 4.5.0-2ubuntu2 | maverick/universe | amd64, i386 <-- would explain why build-essential is uninstallable.
[22:44] <slangasek> ScottK: fixed
[22:45] <ScottK> Thanks.
[22:45] <ScottK> wgrant: ^^^ Thanks.
[23:51] <xnox> Halarious I broke binutils on my machine =) time to go to bed?


[11:56] <MadsRH> Hi. Does anyone know if there's any progress to the Deviant competition???
[11:58] <MadsRH> https://blueprints.launchpad.net/ubuntu/+spec/deviantart-theme-competition
[22:53] <zerwas> Hi


[09:15] <hbibz> good morning
[09:21] <nzoueidi> hey hbibz welcome \o/
[09:22] <hbibz> i think i will be here from now on
[09:22] <hbibz> i want to thank you again for yesterday
[09:22] <hbibz> so i have a lot of ideas i want to share with you
[09:25] <nzoueidi> Glad to hear that :D Thank you.
[09:25] <nzoueidi> Yeah sure
[09:25] <hbibz> i think that it is of great importance that we start geeting people to know about ubuntu tn
[09:26] <hbibz> why not post some articles in the name of ubuntu tn (guides/tutorials)
[09:26] <hbibz> in a blog ... maybe blog.ubuntu-tn.org
[09:27] <hbibz> and get people to know about OSS movement
[09:28] <hbibz> i am not asking you to dedicate a lot of time
[09:29] <hbibz> but to start an initiation and everyone can contribute
[09:29] <nzoueidi> Good idea, why not we discuss it on the maillist. So many people can see your ideas and contribute
[09:29] <hbibz> and assign moderators to review and post
[09:29] <hbibz> just like cybrary.it
[09:29] <hbibz> how can i join the mailist ?
[09:30] <nzoueidi> https://lists.ubuntu.com/mailman/listinfo/ubuntu-tn
[09:30] <hbibz> thank you
[09:30] <nzoueidi> And basically, any other needed infos are here ;) https://wiki.ubuntu.com/TunisianTeam/En
[09:35] <hbibz> greatt :D
[09:36] <hbibz> there is the willing to help and the technical skills
[09:36] <hbibz> some PR and everything will be just great
[09:37] <nzoueidi> Indeed :D
[09:58] <hbibz> good morning
[10:05] <elacheche> Morning nizarus! The CC want to discuss the migration of LoCos from the wiki to the HUB (Pros, Cons) so we're traying to find some active people who are used to both or one of those plateforms to discuss that and see if we should migrate or not.. It's just a discussion, nothing more, are you in? This may interests theShirbiny & pavlushka too :)
[10:05] <elacheche> Sorry for ping you again theShirbiny pavlushka x)
[10:06] <pavlushka> sure np, :)
[10:09] <elacheche> Hey hbibz !
[10:11] <nizarus> bonjour elacheche, bonjour à tous
[10:12] <nizarus> c'est quoi ce HUB ?
[10:12] <hbibz> yes what is it ?
[10:16] <elacheche> nizarus: This → https://community.ubuntu.com
[10:16] <u-la-la> [ Ubuntu Community Hub ] - https://community.ubuntu.com
[10:20] <nizarus> c'est une sorte de forum non ?
[10:20] <nizarus> alors que le wiki est plutôt pour la documentation
[10:24] <elacheche> Kind of.. Yes.. But because of the decreasing nember of active wiki contributors for locos, some folks think that the locos can use the hub instead of the wiki for reporting and others.. So we're trying to strat a discussion around this subject, by asking wiki users & the hub users theire thoughts about the idea.. I'm not in charge of this, just trayingto find some wiki lovers x) to add them to the
[10:24] <elacheche> discussion when it starts :D
[10:31] <nizarus> Il ne faut pas oublier que le wiki permet aussi d'héberger les pages des LoCo pour ceux qui, comme u-tn, n'ont pas un site web
[10:32] <nizarus> ubuntu-tn.org fait la redirection vers https://wiki.ubuntu.com/TunisianTeam
[10:32] <u-la-la> [ TunisianTeam - Ubuntu Wiki ] - https://wiki.ubuntu.com
[10:35] <elacheche> yep.. I'm a WIKI guy, others are not :D
[10:37] <Dro> Hello world
[10:37] <elacheche> Hello Dro :)
[10:40] <Dro> How are u elacheche
[10:41] <elacheche> Good Dro
[12:52] <elacheche> https://lkml.org/lkml/2017/11/17/423
[12:52] <u-la-la> [ LKML: Linus Torvalds: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1 ] - https://lkml.org
[14:18] <hbibz> Hello
[14:47] <hbibz> Can you check your emails ? Thanks
[14:49] <elacheche> hbibz: OK, in meanwhile read this → https://freenode.net/kb/answer/cloaks ;-)
[14:49] <u-la-la> [ User and project cloaks - freenode ] - https://freenode.net
[14:50] <hbibz> Okay thanks
[17:44] <Hbibz> hello again


[13:32] -SwissBot:#ubuntu-news- ::Planet:: Timo Aaltonen: Status of Ubuntu Mesa backports @ https://tjaalton.wordpress.com/2018/06/13/status-of-ubuntu-mesa-backports/
[14:58] -SwissBot:#ubuntu-news- ::Planet:: Stuart Langridge: FOSS Talk LiveÂ 2018 @ http://www.kryogenix.org/days/2018/06/11/foss-talk-live-2018/
[14:58] -SwissBot:#ubuntu-news- ::Planet:: Stuart Langridge: Little communityÂ conferences @ http://www.kryogenix.org/days/2018/06/12/little-community-conferences/
[16:41] -SwissBot:#ubuntu-news- ::Softpedia:: Ubuntu 18.04 LTS Users Can Now Install Mesa 18.1.1 to Improve Their Linux Gaming @ https://news.softpedia.com/news/ubuntu-18-04-lts-users-can-now-install-mesa-18-1-1-to-improve-their-linux-gaming-521543.shtml (by Marius Nestor)
[19:45] <Bashing-om> Who is Timo Aaltonen : https://tjaalton.wordpress.com/2018/06/13/status-of-ubuntu-mesa-backports/ ? Personal blog, where in UWN to place ?
[19:46] <krytarik> Like I said yesterday, if it comes via Planet, it goes to its section or even higher up - but not lower.
[19:48] <Unit193> Bashing-om: He's the guy that takes care of the graphical stack.
[20:04] <Bashing-om> Unit193: I did look and seen some inpressive credentials .. was not sure they matched to this person :)
[21:52] -SwissBot:#ubuntu-news- ::Softpedia:: Red Hat Responds to New Speculative Execution Vulnerability, Patches Coming Soon @ https://news.softpedia.com/news/red-hat-responds-to-new-speculative-execution-vulnerability-patches-coming-soon-521545.shtml (by Marius Nestor)
[23:51] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: The Linux Foundation Says We Should ‘Celebrate’ Microsoft Buying GitHub @ https://www.omgubuntu.co.uk/?p=132336 (by Joey Sneddon)